Every pay change, dated and explained

May carried 316 pay change events. Merit awards account for 298, promotions for six, market adjustments for eleven, and one backdated April correction of 3,200.00 arrived as retro. The change ledger holds all of them, each with a reason and two dates.

RuleKeep every pay change as an event: old value, new value, reason, effective date, entry date. The two dates differ, and that gap is where every retro lives.

Neveroverwrite pay in place. A table that only knows current pay cannot answer what changed, when, or what the cycle did.

◆ May 2026, the events316 changes, four reasons, one ledger.

Reason	Events
Merit award, effective 1 May	298
Promotion with grade move	6
Market adjustment	11
Backdated correction into April	1
Pay change events in May	316

The 298 merit rows are the cycle; the six promotions have their own report; the eleven market adjustments are the between-cycle cases every quarter carries. Sample values are illustrative, never client data.

◆ The two dateseffective versus entered, and the retro between them.

The backdated row is the interesting one: a 3,200.00 correction entered in May, effective in April. Its effective date puts the cost in a closed month, which is exactly the restatement the payroll module versions, and its entry date explains why nobody saw it at the April close.

Every event carries both dates. Sorted by effective date the ledger is economic history; sorted by entry date it is the audit trail. A change history that keeps only one of the two is half a ledger, and the change ledger pattern applies to pay before anything else.

◆ The owned answeran append-only event fact.

Changes append; nothing updates in place. The current state is just the latest event per worker, and any past state rebuilds by replaying events to a date.

-- the May ledger, newest first
SELECT e.worker_id, e.reason,
       e.old_base, e.new_base,
       e.effective_date, e.entry_date
FROM fct_comp_event e
WHERE e.entry_date BETWEEN '2026-05-01' AND '2026-05-31'
ORDER BY e.entry_date DESC

Use case

Problem

Pay history exists as screenshots and memory: changes overwrite in place, backdated corrections surface as surprises, and cycle effects cannot be isolated.

What we build

An append-only pay change event fact with old value, new value, reason, effective date, and entry date, feeding the cycle, promotion, and budget reports.

What you get

One ledger that answers what changed, when, why, and on whose entry, with backdated corrections visible the day they are keyed instead of at the next close.

Can you list every May pay change with its reason?

We build the append-only change ledger the whole module reads from.

Talk to us

Terms on this page

event: One pay change: old value, new value, reason, and two dates.
effective date: When the change takes economic effect; may sit in a closed month.
entry date: When the change was keyed; the audit trail’s date.
reason code: Merit, promotion, market adjustment, correction; the why, coded.
retro: A change whose effective date precedes its entry month.
append-only: New rows only, no updates; history that cannot be silently rewritten.