Parallel payroll testing: how to run it and what to do when a run misses

A parallel payroll test means running the same pay period in your old system and your new one, then comparing the results. It is the one test in an HR system rollout where a failure reaches every employee's bank account. It deserves more planning than it usually gets.

What a parallel run proves

User acceptance testing shows that individual features work. A parallel run shows that everything works together on real data: migrated employee records, pay codes, deductions, tax setup, time and absence feeding in, and benefits elections. If any one of those is wrong, pay will be wrong, and the comparison will show it.

Before the first run

• Pick the pay period. Use a period that has already been paid from the old system, so you have final figures to compare against. Choose a normal one for the first run.
• Freeze the inputs. Both systems must use the same hours, the same rates and the same employee list. If someone was hired or left mid-period, make sure both systems know.
• Decide what you will compare. At a minimum: gross pay, each tax, each deduction and net pay, per employee and in total.
• Set the tolerance now. Write it down before anyone sees a number.
• Name the people. Someone runs payroll in the new system, someone produces the comparison, and someone from Finance signs the result.

How to set a tolerance

A tolerance is the variance you will accept without further work. Set it before the run, because a tolerance chosen after you have seen the result is only a justification.

Two levels are useful:

1. Total net pay. The percentage difference between total net pay in the new system and the old one. A tight starting point is plus or minus 0.1%. On a $400,000 payroll, that is $400.
2. Per employee. A total can look fine while two errors cancel out. Set a small per-employee threshold, often a few cents to allow for rounding, and list everyone outside it.

The formula for the total is simple:

variance % = (new net pay − old net pay) ÷ old net pay × 100

Here is a made-up example. The old system paid $412,300.00 net. The new system calculates $412,918.45. The difference is $618.45, which is 0.15%. Against a tolerance of plus or minus 0.1%, that run misses.

The tolerance is a trigger for sign-off. It does not excuse differences you cannot explain. Even when a run is inside tolerance, every per-employee difference above your rounding threshold should have a written reason.

Running it

1. Load the frozen inputs into the new system.
2. Run payroll in the new system to the point just before payment. Do not submit it.
3. Export results from both systems at the same level of detail.
4. Compare line by line: gross, taxes, deductions, net.
5. Record the total net-pay variance and the list of employees outside the per-employee threshold.
6. Sort the differences by cause.

When a run misses

A missed run is useful. It has found something before employees did. Work through it in this order.

1. Sort the differences into causes

Sort each difference into one of these groups:

Cause	What it looks like	Fix
Data	A handful of employees with wrong rates, missing deductions or wrong tax details	Correct the records and find out why the migration missed them
Configuration	A whole group is off in the same way, such as everyone with overtime	Change the rule, then retest that group
Timing	A change took effect on different dates in each system	Align effective dates and rerun
Rounding	Cents per employee, spread evenly	Document the method and accept it if Finance agrees
The old system was wrong	The new figure is correct and the old one was not	Document it, tell Finance, and decide how to handle the correction

Do not rule out the last row. A parallel run tests both systems.

2. Log each cause as an issue

Give each one a severity and an owner. Anything that would pay people wrongly at go-live is critical.

3. Fix, then rerun

Do not adjust the results by hand and call the run passed. Fix the cause and run another period. The second run should use a different period where you can, ideally one with more going on: bonuses, a new hire, a termination, a retroactive change.

4. Decide what a pass means

A workable rule: two runs within tolerance, with every remaining per-employee difference explained in writing and accepted by Finance. If the second run misses, add a third. Moving the go-live date costs less than a wrong first payroll.

Common mistakes

• Running only one parallel. One clean run can be luck. Two is a pattern.
• Comparing totals only. Offsetting errors hide inside a clean total.
• Testing only a quiet period. A plain month does not exercise bonuses, retroactive pay or terminations.
• Leaving it too late. If the first run happens two weeks before go-live, there is no time to fix and rerun.
• Nobody signs. Without a named person accepting the result, the pass is informal and will be questioned later.

Keep pay data out of your project tool

The comparison file contains every employee's pay. Keep it inside your payroll and finance systems. Your project plan only needs the outcome: which run, what variance, pass or miss, and who signed.

Where HRjects fits

HRjects has a parallel payroll tracker inside its go-live readiness workspace. You record the net-pay variance percentage for each run, and it is checked against a tolerance of plus or minus 0.1%. The readiness score cannot show Go until every run is within tolerance and no critical issue is open. It stores the percentage only, never pay data, and it does not do the comparison for you. The steps are in the help article on readiness and payroll runs, and the payroll provider switch page shows how the rest of the project fits around it.