The first parallel run I ever signed off on matched to the cent in Germany. Net pay, 412 employees, zero variance. It went into the steering committee deck with a green box around it.
Two things were wrong in that run and neither one touched net. The shift premium had been mapped into base salary, so total gross matched while gross by element did not, which broke the variable-pay average feeding holiday pay and hit the wrong GL account. Separately, the U2 maternity levy was charged at the wrong rate. That is employer-only money. An employee’s net pay cannot see it.
We had reconciled the single number that was structurally incapable of telling us anything.
Kainos, which implements Workday payroll for its clients, puts the principle plainly: a parallel is “a confirmation that your configuration is correct, not an initial investigation.” If you are still learning how the system behaves during your parallel, you started it too late. Here is how I would run one across eight countries.
Three parallels, and each one hunts a different error
One cycle is not a parallel run. It is a smoke test with good PR. IRIS Software Group puts it more politely: one cycle is enough to get started, but two or three give you accurate data. Rizing, which works on SAP implementations, describes what happens when you plan two: nearly all the stabilisation lands in cycle one, and cycle two gets squeezed into validation under time pressure.
Three cycles, and give each one a job before you start.
Cycle one finds configuration errors. Wrong rates, wrong bases, elements mapped to the wrong tax treatment, a component that is taxable in the legacy system and exempt in the new one. Expect it to be ugly. If cycle one comes back at 99 percent match on your first attempt in a new country, be suspicious rather than pleased: usually the test population is too clean or the comparison is too shallow.
Cycle two finds data errors, and only works if you deliberately break it. Seed the cases nobody volunteers for. Run it on a population that includes, at minimum:
- A new hire starting mid-period, and a second starting on the last working day
- A leaver with final pay: accrued leave payout, notice, statutory settlement
- A retro increase backdated two periods, so retro tax and retro employer contributions both recalculate
- Part-period unpaid leave, which exposes proration differences faster than anything else
- A maternity case (in the UK, six weeks at 90 percent of average weekly earnings, then up to 33 weeks at the 2026/27 standard rate of £194.32, with the lower earnings limit at £129 a week)
- A bonus that pushes someone across a ceiling: the 2026 US Social Security wage base at $184,500, the UK upper earnings limit still frozen at £50,270 for 2026/27, the German pension ceiling at €101,400 for 2026
- A mid-period cost-centre change, to see whether the GL splits by day or dumps the whole cost on the closing centre
- A negative net, to learn whether the system carries it forward or silently zeroes it
Kainos also recommends reviewing twelve months of legacy results before picking the population: the thirteenth-month payment and the once-a-year union deduction never appear in a March parallel.
Cycle three proves stability. Same configuration, no changes beyond signed-off fixes, and a flat, explainable variance report. It is not hunting new defects. It is evidence that the earlier fixes did not move something else. If cycle three produces a new category of error, you do not have a go-live. You have a cycle four.
Reconcile in this order. Net pay is the last thing you look at.
Net-only reconciliation is the classic mistake because net is a difference of two large numbers. Any two offsetting errors produce a matching net: taxable gross too high by 300 and a relief too generous by 300, and net ties while the tax remittance and the statutory return are both wrong. Work up from the inputs instead:
1. Gross by pay element, element by element, not gross in total
2. Taxable gross, plus each separate statutory base where a country uses different ones (in Germany the tax base, the pension base and the health base are three different numbers)
3. Employee statutory deductions, by contribution type
4. Employer contributions, by contribution type
5. Net pay
6. Total employer cost, where employer-only levies finally become visible
7. GL by cost centre and account, posted, not just reported
8. Bank file total and payment count, against the payroll register
The last two get skipped constantly, because finance and treasury are not in the meeting. Invite them. A payroll that calculates correctly and posts to the wrong cost centre still produces the Thursday email from the CFO asking why one business unit is up 4 percent.
Zero tolerance on statutory, and a variance report sorted by absolute difference
The tolerance policy is two sentences. Statutory amounts match exactly, employee and employer, every country. Everything else has a documented tolerance agreed in advance.
Some rounding differences are legitimate and you will never close them. Systems round in different orders: per element then sum, versus sum then round. The Netherlands calculates social insurance cumulatively, voortschrijdend cumulatief rekenen, so a mid-year comparison against a per-period legacy calculation drifts by cents by design. France applies the monthly ceiling month by month, €4,005 in 2026, while some legacy setups regularise annually against the €48,060 annual ceiling. Those differences are correct. Chase them for three weeks and you will still have them.
Write them down instead: an accepted variance register with country, element, mechanism, maximum expected difference, and the name of the person who accepted it. Anything not on it is a defect.
Build the report at employee level and sort it by absolute difference, never by percentage and never by signed difference. Then read it twice, once top down and once bottom up. A single 400 variance on one senior hire is usually a one-off input difference. A 0.02 variance on 3,000 employees is a rounding rule that is wrong in every payslip you will ever produce, and wrong in the annual filing too. Summary-level reports hide exactly this: 3,000 employees at plus 0.02 and 300 at minus 0.20 nets to zero at the top.
HR Blizz applies the same logic in production. Its AI checks run twice per period, and the pass before calculation compares the run against the last 12 periods: duplicates, a pay element that has vanished, a new one that has appeared, a figure more than 30 percent off its own history. A parallel run is that comparison with the previous system standing in for history.
A mid-year cutover doubles the work, and the ceilings are why
A January or April cutover validates one thing, the calculation. A mid-year cutover validates the calculation and the opening balances, and the second job is bigger.
Every cumulative position has to arrive intact. UK PAYE is cumulative, so tax code, tax basis, previous-employment pay and tax, and year-to-date taxable pay and tax must all land correctly or the first live payslip produces a refund nobody can explain. UK employee National Insurance is per earnings period, which sounds easier until you remember that directors sit on an annual earnings period under HMRC’s CA44 rules, so their year-to-date NIC-able pay must migrate too. In the US, the $184,500 Social Security wage base for 2026 does not restart because you changed provider; if year-to-date subject wages do not load, you over-withhold from your highest earners and get to explain a W-2 that will not reconcile to the 941s. German ceilings run annually and separately: for 2026, €101,400 for pension and unemployment, €69,750 for health and care.
There is a UK reporting trap here that has nothing to do with calculation. If payroll IDs change during the move and the FPS does not carry the old payroll ID with the payroll ID changed indicator set, HMRC can create a second employment for the same person and issue emergency or duplicate tax codes against it. You find out when employees start calling. Agree the payroll ID strategy in cycle one and test the FPS output, not only the payslip.
Reconcile the opening balances as a separate exercise with its own sign-off, before cycle three: year-to-date gross, taxable gross, each statutory base, each deduction, employer contributions, ceiling counters. Compare against the legacy year-to-date report and against the last filed statutory return. Those two do not always agree, and finding that out during a parallel beats finding it out at year end.
What goes in writing before cycle one starts
Define “pass” in a document, get it signed, and date it before any comparison exists. Once you have a variance report in front of you, the definition of pass becomes negotiable and it always negotiates downward.
Mine reads roughly: 100 percent match on statutory amounts, employee and employer, per country. Zero unexplained employee-level net variances. Every remaining variance either on the accepted register or closed with root cause. GL posted and reconciled by cost centre. Bank file total and record count matching the register. Statutory outputs generated and reviewed for format. Country payroll lead, group payroll manager, finance controller and treasury each sign for their own scope. One signature from one project manager is not sign-off, it is a formality.
Settle the data question the same week. You are about to hand real salary data for eight countries to a vendor, which needs an executed, specific Article 28 processor agreement rather than a purchase order and a promise, with sub-processors named and transfers out of the EEA documented. Read the SOC 1 and SOC 2 reports instead of filing the certificates. Then decide whether the parallel population needs names at all: mostly it does not, and pseudonymised extracts keyed on employee ID cost nothing in validation quality. Set a deletion date and a named owner for the parallel data set. In Germany and the Netherlands, check the works council position early. A new payroll system is not something you mention in week eleven.
Where to start on Monday
Open the last twelve periods of legacy results for your two hardest countries and build the seeded population from real employees, before you look at a configuration screen. Then write the pass criteria, circulate it, and collect four signatures while nobody has anything to defend yet.
If you are still choosing a platform rather than validating one, ask how the parallel gets evidenced: whether every change during the run is captured with old value, new value and source, and whether statutory outputs are produced inside the run rather than assembled afterwards. HR Blizz was built that way, with a 30-column audit trail and country filings generated in the cycle, because the parallel is where an implementation stops being a plan and becomes a number somebody has to sign.
The rates, ceilings and reporting rules quoted above are here as general information, not as tax advice, and they are only current as at publication.
FAQ
Q: How many parallel payroll cycles should you run before go-live?
Three is the honest answer for a multi-country implementation. Cycle one surfaces configuration errors, cycle two surfaces data errors once you deliberately seed edge cases, and cycle three proves the fixes did not break anything else. IRIS Software Group’s testing guidance notes that one cycle is a starting point but two or three produce reliable data.
Q: Why is reconciling net pay alone not enough in a payroll parallel run?
Because net is a difference of two large numbers, so any two offsetting errors produce a matching net. Taxable gross overstated by 300 with a relief overstated by 300 gives an identical net while the tax remittance and statutory filing are both wrong, and employer-only levies never appear in net at all. Reconcile gross by pay element, each statutory base, employee deductions and employer contributions before you look at net.
Q: What variance tolerance should a payroll parallel run allow?
Zero on statutory amounts, employee and employer side, in every country. Legitimate rounding differences from different rounding order or per-period versus cumulative calculation should be documented in an accepted variance register with the mechanism, the maximum expected difference and a named approver, and anything not on that register is treated as a defect.
Q: What extra validation does a mid-year payroll cutover require?
Every cumulative position has to migrate and be reconciled separately: year-to-date taxable pay and tax for cumulative systems like UK PAYE, and the ceiling counters for capped contributions such as the $184,500 US Social Security wage base in 2026 or the €101,400 German pension ceiling. In the UK you also need the FPS to carry the old payroll ID with the payroll ID changed indicator set, or HMRC may create a duplicate employment record and issue incorrect tax codes.