What it is
A parallel run is the safety check before you trust a new payroll: you run the same period through Hexis and through your existing system, then compare the results worker by worker. The parallel-run ledger records each comparison as a durable verdict — identical, within tolerance, or divergent — with the counts of matched, close and mismatched workers, and a hash of each side so you know nothing changed underneath you.
This is the evidence that lets ops sign off a cutover. Rather than spot-checking a few payslips and hoping, you get a precise, repeatable verdict per period that says exactly how close the two systems are and where they differ — so go-live is a decision, not a leap of faith.
When to use it
- You’re preparing to move payroll onto Hexis and need cutover evidence
- You want to compare a period’s results against your legacy system
- Ops needs a sign-off verdict before going live
- A previous parallel showed divergence and you’re re-checking after fixes
How it works
Step by step.
- 1
Open the parallel-run ledger
It shows the latest verdict per period — identical, within tolerance or divergent — for the comparison runs you’ve recorded.
- 2
Read the verdict pill
The pill is the headline: identical means every worker matched, within tolerance means small expected differences, divergent means something needs investigation.
- 3
Check the counts
Read the matched, within-tolerance, mismatched and missing counts to see how many workers agree and how many don’t.
- 4
Investigate mismatches
For a divergent or partly-mismatched period, drill into the workers who differ — usually a rounding rule, a classification, or a timing difference.
- 5
Confirm the hashes
Both sides carry a byte-hash; matching them across re-runs confirms neither input changed under you between comparisons.
- 6
Sign off the cutover
When the verdict is identical, or within tolerance for differences you understand, you have the evidence to go live.
Worked example
Follow it through.
The scenario
Northwind Workforce is validating a final fortnight before cutting over from its old payroll.
- 1 Open the parallel-run ledger; the “FN · 26 May–8 Jun” period reads “Within tolerance”.
- 2 Counts show 36 matched, 2 within tolerance, 0 mismatched, 0 missing.
- 3 The two tolerance cases are sub-cent rounding differences on penalty lines — expected and acceptable.
- 4 Both side hashes match the prior comparison, so nothing changed between runs.
- 5 You record the verdict as cutover evidence and sign off go-live.
The result
A “within tolerance” verdict with 36 exact matches and two understood rounding differences gives ops the evidence to go live.
Tips & notes
Good to know.
- Within tolerance is a pass when the differences are explained — usually sub-cent rounding; divergent always needs a root cause before sign-off.
- A “missing” count means a worker appeared in one system but not the other — check for a starter or leaver timing difference.
- Matching the byte-hashes across re-runs proves your inputs were stable, so a changed verdict reflects a real fix, not shifting data.
- Re-run the comparison after each fix; the ledger keeps the latest verdict per period so you always read the current state.
When you’re done
A recorded, defensible parallel-run verdict per period that lets ops sign off the payroll cutover with confidence.