The Package That Has Only One Version
An employee's pay package here is designed as a dated series — draft, active, superseded, each with a start and an end. In practice every employee has exactly one of them, created the first time somebody opens the screen and edited in place from then on.
There are two questions about somebody's pay, and organisations tend to assume that answering the first one answers the second. What are they paid? And what were they paid in March?
The first is a fact about now and every system holds it. The second is a fact about a date, and it needs the package to have a history rather than a state.
A design with dates in it
The storage here was drawn by somebody who had thought about this properly. A compensation package can be a draft, the active one, or superseded by a later one. It carries a date it takes effect from and a date it stops. The history is defined as a list ordered by effective date, newest first — which is the shape of a series, not of a setting.
The payroll calculation reads it that way too: when it runs a period, it looks for the active package whose effective date falls on or before the end of that period, taking the latest one that qualifies. That query only makes sense if there are several rows spanning different dates.
There is one. There has only ever been one per employee.
The first time anybody opens the compensation screen for a person, a row is created. Every change from then on edits that row.
What actually happens when pay changes
An allowance is added, or removed, or its amount is changed. The single package absorbs the change. Its effective date still says the day it was first opened. Its end date is still empty. Its status is still active, and no earlier version exists to be superseded, because none was ever created.
The three states and the end date describe a mechanism that has never run.
What this does and does not put at risk
This is the part worth being exact about, because the obvious fear is the wrong one.
An issued payslip does not change. A payslip stores its own figures — the basic, the prorated basic, the gross, the taxable and pensionable bases, both deduction totals, the net, and the moment it was calculated, with the individual lines beneath it. Editing somebody's allowances today does not reach backwards and alter a payslip produced in March. That is the right design and it is properly done.
What moves is everything around the payslip.
- The link back to the reasoning. A payslip records which package it was computed from. Following that link gives you today's package, so the figures are frozen and the explanation is not. You can see that somebody received an allowance and cannot see the allowance they were on.
- Any recalculation. Re-running a period, or correcting one, uses the package as it stands now rather than as it stood then. The two runs differ and nothing says why.
- A removed allowance disappears entirely. Deleting an item takes it out of the only record there is. The payslips that included it keep their numbers; the reason those numbers were what they were is gone.
- The question "when did this change". There is no answer, because there is no before.
And base pay is handled properly, which is the interesting part
The basic salary does not live in the package at all. It lives on the employment contract, and contracts here are genuinely versioned — dated, signed, with the signature and the moment recorded, and a new contract rather than an edit when terms change.
So the architecture already contains the correct pattern, applied to the number people think of first. What sits on top of it — the allowances, the car, the housing, the transport, the shift premium — is a single row that gets edited.
That asymmetry is worth naming because of who it affects. For a salaried employee whose pay is one number, base pay versioning is the whole story and nothing here matters. For anybody whose package is a base plus several moving parts — which in a lot of European organisations is most people above a certain level, and in many sectors is everybody — the versioned half is the smaller half.
Working with it as it stands
-
Keep the letter, not just the change
Whatever document told the employee their package changed — the review letter, the offer, the agreement — file it against them. It is the dated record the system is not keeping, and it is the one they will produce.
-
Export the package before you change it
Thirty seconds before a review round, and it is the only snapshot of what everybody was on beforehand. Doing it for the whole workforce at once is easier than doing it per person later.
-
Treat a recalculation as a new decision
If you re-run a closed period, check the package first. It is the difference between correcting an error and quietly applying today's terms to an old month.
-
Never delete an allowance you might have to explain
Set it to zero instead if the screen allows, so the line survives even when the amount does not. Removal is the one action here with no trace at all.
Four questions for any payroll system
What was this person's package on a date last year?
What you will hear
Confidence, then a search.
How to read it
The question. Ask for a specific person and a specific date during the demonstration. A system with versioned packages answers in one screen; one without it produces today's figures and an explanation.
If I change an allowance, what happens to last month's payslip?
What you will hear
"Nothing."
How to read it
Usually true and worth confirming, because a system that recomputes payslips on read rather than storing them is a genuinely different and much worse product. Ours stores them.
If I re-run a closed period, which package does it use?
What you will hear
A pause.
How to read it
The follow-up that separates a stored payslip from a versioned package. Both are needed, and most systems that have the first are assumed to have the second.
Where does base pay live, and is it versioned separately?
What you will hear
Often on the contract.
How to read it
A good sign when it is, and it is ours. Then ask the same question about everything else in the package, because that is usually where the versioning stops.
What AWRA OpsHub does today
- Base pay versioned on the employment contract, dated and signed, with a new contract rather than an edit when terms change — and the contract is the only source of truth payroll reads for it.
- Payslips that freeze their own figures — basic, prorated basic, gross, taxable and pensionable bases, both deduction totals, net and the moment of calculation — with the individual lines kept beneath them.
- A compensation package of dated items on top of the contract, resolved by payroll against the period being run.
- A payroll rule layer versioned separately, frozen once real payslips have used a version, so a statutory change cannot rewrite a period that was already run.
More we can add to your workspace
- A new dated version of a package when it changes, leaving the previous one superseded and readable — the three states and the end date are defined and waiting for the action that creates one.
- A payslip that links back to the package as it stood when the payslip was produced, rather than to the package as it stands now.
- A history of what an allowance was worth over time, so a removed line survives its removal.
- A record of who changed a package and when, which is the smallest of these and the one an employee dispute asks for first.
- A warning on a recalculation that the package has changed since the original run.
Where we point you to a specialist
- Payslips stay frozen once produced and we would argue hard for that against any request to recompute them on read. A payslip is a statement to an individual about a period, and a document that quietly agrees with today is worth nothing to the person holding it.
- What an employee is entitled to be told about a change to their package, and how long you must keep the record, is a matter for your own advisers and any agreement you operate under. We would keep the history and would decline to set the retention or the notification rule for you.
- We would decline to reconstruct a past package by working backwards from payslip figures. It is arithmetically possible in simple cases and wrong in exactly the complicated ones, and a reconstructed history presented as a record is worse than none.
Versioned compensation packages, a payslip that links to the version it used, and change attribution are one piece of work we can scope and quote on.
Three, and the storage is already shaped for the first
The states, the dates and the history relation all exist. What is missing is the action that closes one version and opens the next.
A new version on change
Changing a package ends the current one on a stated date and opens a new one from the next, leaving the old readable and marked superseded. Payroll already queries by effective date, so it would consume these correctly the day they exist.
A payslip tied to the version it used
So the figures and the reasoning stay together, and following a payslip back explains it rather than describing today.
Who changed it, and when
Attribution on a package change. The smallest item here and the one an employee dispute reaches for before any of the others.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you run an annual review cycle, the right moment to raise this is before the round rather than after it.
Talk to us about payroll historyThe short version
A stored payslip and a versioned package are two different things, and having the first makes it very easy to assume the second. Ours freezes every payslip properly and versions base pay through the contract; the allowances on top of it are a single row that gets edited, so the numbers survive and the reasons do not. Ask your own system what somebody was paid on a date last year, for a named person, and see whether you get an answer or a search.
Ask for one person on one past date
Their full package as it stood twelve months ago, not their pay now. It is the question a dispute, an audit or a review round will eventually ask, and it is worth knowing today whether your records can answer it.
Talk to us about HR and payroll