Effective-dated rules
How statutory rules resolve by pay date, and how historical payslips are corrected without losing the original record.
Status
This capability is being rolled out (Phase 21G). The data model is in place and payroll now resolves its statutory rule by pay date (21G-C). Leave and workweek resolution and the historical correction workflow are being delivered in later stages. This page describes the intended behaviour and will be marked Live when complete.
Why effective dating
A statutory rule is data with a validity window, resolved by the date of the event being computed — not a hand-toggled "current" flag. A 2024 payslip must compute on 2024 rules forever; a backdated leave request must use the policy that was in force on the request date.
- Payroll resolves by the pay date.
- Leave resolves by the request start date.
- Workweek / weekend resolves by the work date (tenant-configurable, not hardcoded to Sat/Sun).
A new national budget — or a new country — is one dated rule row, not a code change.
How payroll resolves its rule
LivePayrollWhen you create a payroll run, Heimdallone resolves the country payroll
profile whose validity window contains the period's pay date (falling back to
the period end date) and pins that profile to the run, recording a
human-readable rule version (for example, GY 2026 (from 2026-01-01)).
- Generation honours the pin. Every payslip in the run computes under the pinned profile, so re-previewing a run never silently switches it to a newer rule that was published after the run was created.
- Resolution is by date, not a toggle. A profile is selectable when it is published and its window contains the date. Publishing a 2027 profile in advance does not change how a 2026 run computes.
- Older runs are handled. A run created before this change carries no pinned profile; the first time it is generated, Heimdallone resolves the rule by its pay date and records the pin going forward.
- Ad-hoc previews and pay projections (which are not tied to a run) resolve the rule in force on the relevant period's pay date.
Historical payslips don't change on their own
Issued payslips are never recomputed as a side effect of viewing them or of a newer rule being published. Changing a historical result is an explicit, audited correction — see below.
Historical payslip correction
When a historical payslip was computed under the wrong or missing rule, it can be corrected — but never silently and never destructively.
The original is never lost
The originally issued payslip is preserved as an immutable audit record. The corrected figures become the corrected historical truth, linked to the original with a per-component breakdown. Every correction is explicit, auditable, and tied to the correct effective-dated rule.
Status
The correction engine is Live: recompute-by-pay-date, the per-component diff, the admin-only transactional apply, the immutable original, and the recorded GL adjustment obligation all work via the payroll API. The general-ledger entry is posted through the Finance/GL module (payroll records the obligation but never writes the ledger). In the product, a corrected payslip shows an original → corrected → change breakdown with the reason, the historical rule used, and the ledger-adjustment status, and the payroll run shows the statutory rule version it was pinned to. Running a correction from a button in the payslip screen is the remaining UI step.
What you'll see
Run corrections from the payroll area: review the preview, approve, and apply. The payslip detail shows original vs corrected, the reason, who corrected it, the rule used, and the ledger adjustment status.
If one of your payslips was corrected, you'll see both the originally issued figures and the corrected figures, with the correction date and reason.
Read-only access to the full correction history — original, corrected, deltas, reason, actor, and rule — for review and compliance.