Why last month’s labor cost changed

You closed April, reported the labor cost, and moved on. In May a backdated raise processes, the system recalculates April, and the number you presented is quietly no longer the number the system holds.

RuleVersion every period: keep it as first reported and as restated after retro, with the delta stored, dated, and explained.

Neverlet a retro change overwrite a closed period in place. A trend that shifts under a presented number is how trust in the books erodes.

Earned in a closed period, paid in the current one. The delivered path shows only the new total; the owned model keeps both and names the difference.

◆ What retro pay does to a closed perioda change to the past, applied without a mark.

A merit increase effective the first of April, entered in May. A corrected time card for a period already reported. Each one makes the payroll engine recalculate a period that finance has closed, and the delivered report simply shows the new, higher number. What you reported at close and what the system now believes are different, and nothing on screen says by how much.

Off-cycle payments handle corrections going forward. Retro is the other direction: it reaches back. The off-cycle page covers the first; this page covers the restatement of a period you already trusted.

◆ The restatement, workedApril, as reported and as restated.

April 2026	Labor cost
As reported at close	4,551,330.00
Retro merit increase, effective April, processed in May	3,200.00
As restated	4,554,530.00

April closed at the same 4,551,330.00 the labor cost report carries. The 3,200.00 retro increase is earned in April but paid in the May run, so it belongs to two periods at once: cash in May, cost in April. The delivered report assigns it to one of them silently; the restatement above assigns it on purpose. Sample values are illustrative, never client data.

◆ The owned answerversion the period, name the delta.

The build keeps every period in two versions: as first reported, and as it stands after any retro. The restatement is a stored delta with a reason and a date, not a silent overwrite, so a trend never quietly changes underneath a number someone already presented. The ledger tie runs against the restated version; the as-reported version stays for the audit question, what did we say at the time.

-- April labor cost: as reported vs as restated, from the versioned fact
SELECT period, version_label, SUM(amount) AS labor_cost
FROM fct_payroll_line_versioned
WHERE period = '2026-04'
GROUP BY 1, 2
ORDER BY 2

The difference between the two rows is the retro impact, explained line by line beneath it. Paid-versus-earned becomes two columns a controller can reconcile, instead of one number that moved.

Use case

Problem

Retroactive pay silently recalculates closed periods, so last month’s reported labor cost changes after the fact with nothing naming the difference.

What we build

A versioned payroll fact that keeps every period as-reported and as-restated, with each retro stored as a dated, explained delta.

What you get

Numbers that stay what you presented, a restatement you can explain line by line, and paid-versus-earned reconciled instead of conflated.

Did last month’s payroll number change after you closed it?

We ship the versioned model that keeps both numbers and names the delta.

Talk to us

Terms on this page

retro pay: A pay change effective in a period already processed, applied afterward.
effective date: The date a change takes economic effect, which may sit in a closed period.
closed period: An accounting period finance has reported and locked.
restatement: A closed period recalculated after the fact.
as-reported: The figure as it stood when the period closed.
as-restated: The figure after retro changes are applied.
earned vs paid: The period a cost belongs to versus the run that disburses it.
versioned fact: A fact table keeping each period in its successive versions.