A parallel payroll run calculates the same pay period in your existing payroll system and your proposed system, then compares the results before the new system becomes the payment source. A useful test goes beyond matching the company total: it explains differences in each employee’s hours, earnings, deductions and net pay.
This guide gives payroll managers a repeatable comparison process, a worked example and a sign-off checklist. Use it when changing providers, replacing a timekeeping integration or introducing a major pay-rule change.
1. Set the test boundary before calculating
Write down the pay-period dates, payment date, employee population, currencies and system configuration versions. Select an approved period with enough variety to exercise the rules you actually use. A period containing only regular hourly pay will tell you little about premiums, leave or one-time deductions.
Assign three roles: an operator to prepare and calculate, a payroll reviewer to investigate differences, and an approver to accept the evidence. In a small team, record who performed the independent review even if people cover several responsibilities.
Agree with your implementation team how the test environment prevents payment files, direct deposits, employee notices and tax submissions from being released. Retain a clear owner for the real payroll and its deadlines throughout testing. Label all comparison exports with a test-run ID.
Choose scenarios deliberately
- Hourly and salaried employees, where both are used.
- Overtime, shift premiums and multiple rates.
- Paid leave and unpaid time.
- New hires, pay changes and employees with no payable hours.
- Benefit deductions, reimbursements and relevant opening balances.
- Department or job splits needed for accounting.
Use controlled supplemental cases for important scenarios absent from the selected period. Clearly distinguish those cases from actual employee payroll.
There is no single test-cycle count that proves every implementation is ready. Set the plan around your payroll complexity, scenario coverage, outstanding defects and reviewer acceptance.
2. Match inputs before comparing outputs
Create a frozen comparison pack. Include the approved time export, employee identifier mapping, effective pay rates, earnings and deduction definitions, tax settings, leave inputs and year-to-date balances relevant to the test. Record the export time and version. Use employee IDs for matching; names alone can produce false matches.
Define how an old pay code maps to a new one. A code called “OT” may represent total overtime earnings in one export and only the premium in another. Compare equivalent components before calling the difference a calculation error. Check time units too: 7 hours 30 minutes is 7.5 decimal hours, not 7.30.
| Input | What must align | Evidence to retain |
|---|---|---|
| People and dates | Employee IDs, population, period and payment date | Roster and run header |
| Time and earnings | Approved hours, units, codes and effective rates | Time export and code map |
| Deductions and tax | Elections, calculation basis and applicable settings | Configuration comparison |
| Opening balances | Relevant year-to-date amounts and limits | Balance reconciliation |
If an input changes after the freeze, issue a new version and rerun both calculations. Comparing a corrected timesheet in one system with the old timesheet in the other creates a misleading variance.
3. Compare in an order that reveals the cause
Start with employee counts and missing or duplicate IDs. Then compare hours and earnings by pay code, gross pay, taxable bases and withholding, employee deductions, net pay, employer costs and accounting allocations. Later results depend on earlier ones: a net-pay difference may begin with an incorrect earnings input.
For each comparable field, use variance = new-system amount − baseline amount. Keep the signed amount so the reviewer can see the direction. Also review absolute differences; a positive amount for one employee can cancel a negative amount for another.
Record the employee ID, field or code, both values, variance, likely cause, owner, corrective action and retest result. Add the source evidence and reviewer decision. A useful cause list includes input mismatch, code mapping, effective date, configuration, opening balance, rounding or an error in the old baseline.
A legacy result is a comparison point, not proof of correctness. If the systems differ, check approved source records and the applicable calculation requirements. Have qualified payroll staff resolve tax or wage-rule questions using current jurisdiction-specific guidance.
4. Worked example: a $15 net-pay difference
The following fictional comparison uses the same approved 40 hours at $25 per hour. Withholding and deduction figures are illustrative fixed inputs, not tax estimates or a statement of required deductions. There are no reimbursements or other net-pay adjustments in this simplified example.
| Field | Baseline | New run | Variance |
|---|---|---|---|
| Regular earnings | $1,000 | $1,000 | $0 |
| Employee withholding | $180 | $180 | $0 |
| Benefit deduction | $50 | $35 | −$15 |
| Net pay | $770 | $785 | +$15 |
The arithmetic is $1,000 − $180 − $50 = $770 in the baseline and $1,000 − $180 − $35 = $785 in the new run. Gross pay agrees. The benefit deduction explains the entire net-pay difference.
The reviewer checks the approved benefit setup and discovers that a $15 additional deduction was omitted from the new configuration. After correcting the setup, the operator reruns the test. The deduction becomes $50 and net pay becomes $770. The evidence log links the configuration correction, new run ID and reviewer acceptance.
Now imagine a second employee has a −$15 net variance. The company net-pay total would match even before either issue was fixed. Employee-level review exposes both errors. This is why a grand-total match cannot replace line-by-line reconciliation.
5. Parallel payroll run sign-off checklist
Use these checks during review. Tick marks are a reading aid for this page; record approvals and supporting files in your controlled payroll records.
Keep unresolved material differences open. Decide whether they block cutover based on their cause and impact, with explicit payroll-owner approval. Record any accepted difference precisely, including the reason, affected population and follow-up owner.
Before the first live run, confirm which system will pay, who releases payments, who owns filings, and how approved test corrections reach the production configuration. Preserve the comparison history according to your records policy and provider guidance. Confirm how test data is isolated or cleared without changing genuine payroll records.
Connect the timekeeping review to payroll
TimeTrex combines payroll processing with scheduling and attendance, and provides digital pay stubs and reporting. During implementation, use your test plan to check that approved time, mapped pay codes and payroll results remain aligned. Confirm the reporting and configuration options appropriate to your edition and deployment.
TimeTrex’s implementation and setup services include assistance with data migration and initial configuration. Bring your employee scenarios, code map and variance log to the implementation discussion so the review addresses your actual payroll process.
Plan a payroll comparison with clear evidence
Discuss your timekeeping, payroll and migration requirements with TimeTrex before setting the cutover date.
Talk to TimeTrexParallel payroll run FAQs
How many parallel payroll runs should we complete?
Choose enough cycles and controlled scenarios to cover your pay rules, employee groups and downstream reports. Track coverage and unresolved defects. A fixed count alone cannot establish readiness; agree the acceptance criteria with your payroll owner and implementation team.
What if gross pay matches but net pay differs?
Compare taxable bases, employee withholding, deductions and reimbursements separately. Check settings, opening balances and rounding methods. Follow the difference back to evidence instead of manually adjusting net pay to force a match.
Should the old payroll system always be treated as correct?
No. It provides the baseline for comparison. Validate disputed results against approved inputs and the applicable rules. A migration can reveal an existing error that needs its own correction process.
Does a parallel run mean paying employees twice?
No. The comparison calculates test results while the designated live system remains responsible for actual payroll. Confirm test controls with the providers so test outputs cannot trigger duplicate payments or submissions.
