Guide
Payroll parallel testing means running the same pay period through your current and your new payroll system, then comparing the results employee by employee and pay code by pay code. This guide covers the method, a parallel run checklist, the problems that usually produce false variances, and how to read what comes back.
A parallel test (also called a parallel run) processes the same employees, with the same inputs, for the same period in two payroll systems: the source, usually the system you run today, and the target, the system you are moving to. You then compare the two sets of results line by line. Where they differ, someone has to explain why.
The comparison is only as good as its join. To line up results you need to know which source employee is which target employee, and which source pay code (and tax authority) corresponds to which target pay code. Most of the effort in a parallel test goes into building and checking those two mappings, not into the arithmetic.
A new payroll system can pass every unit test and still pay people differently. Earnings, deductions, taxes, employer costs and converted employee data all interact, and the fastest way to see the combined effect is to pay a real period both ways.
A parallel test also gives the project a record. When sign-off comes, the payroll lead, the implementation partner and finance can point to what was compared, what differed, what was fixed, and which differences were accepted and why.
This method works whatever tool you use to compare. You can follow it with spreadsheets alone; a later section shows how SmartCompaire supports the comparison steps.
Write down which pay groups, countries and periods are in scope, who signs off, and what “done” means: for example, every variance either within tolerance, fixed, or documented as a known or accepted difference. Agree this before the first comparison, not after.
Pick periods that exercise the rules you changed, and make sure both systems receive the same inputs for them: the same hours, new hires, terminations, rate changes and one-off payments. A difference caused by a missing input in one system looks exactly like a configuration error.
Export one row per employee, tax authority and pay code, with the amount and, where available, the number (hours or units) and rate. Keep payroll area and period fields so you can tell runs apart. Compare like with like: current-period amounts against current-period amounts.
Map every source employee number to its target employee number. Each number should appear once on each side. Check for employees who are paid in one system but missing from the crosswalk, and keep employee numbers as text so leading zeros survive.
Map each source pay code, together with its tax authority where one applies, to the target pay code, and assign each mapping to a category such as earnings, pre-tax deductions, employee taxes, employer taxes or net pay. Expect many-to-one mappings where one system splits what the other combines.
Decide how large a difference is acceptable for each category, and agree it with finance or audit. Tolerances keep rounding noise out of the review, but set them too wide and real errors disappear inside them.
Before you compare, count the pay rows that will not join: pay codes with no mapping, employees with no crosswalk entry, rows with no tax authority, and cells holding spreadsheet errors. Fix these first. Each can produce a false variance or an unintended total.
Sum amounts per employee and mapping group on each side, then subtract. Use a join that keeps rows found in only one system: a pay code that exists only in the target is a finding, and a lookup that silently drops it hides the problem.
Give each over-tolerance row an outcome: a defect to fix (with an owner, priority and due date), a known or accepted difference with a written justification, or a mapping correction. Record the decision against the row so the next reviewer does not start again.
Apply the fixes, rerun the comparison and confirm the count of over-tolerance rows is falling. Keep each run to show the trend, and sign off on a run whose variances you have actually triaged.
Most early variances are not pay errors but comparison problems. Check these before you raise a defect.
Start with the counts, not the rows. Separate exact matches, rows within tolerance, rows over tolerance, rows with no tolerance, and rows that could not be paired because the employee or pay code had no mapping. Clear the mapping gaps first: they are comparison problems, and they distort every other number.
Next, group over-tolerance rows by category and pay code. A single configuration error usually shows up as the same pay code differing for many employees, so one fix can clear dozens of rows. Differences spread across many codes for one employee usually point to that employee’s data: a missing rate change, a different work location, or an input that reached only one system.
Look at the direction and the components. A consistent sign suggests a rule difference; mixed signs suggest timing or input differences. Where you have number and rate, check which one moved.
Review net pay last. It is what employees notice, but it is the sum of everything above it.
Finally, track the over-tolerance count across runs. If it rises after a fix, the fix moved the problem rather than solving it.
SmartCompaire works from files exported from your source and target systems, so it needs no connection to either one.
Upload .xlsx, .xls or .csv files, or paste rows. File imports keep leading zeros and read $ signs, commas and bracketed negatives. Payroll area and period are stored but do not separate rows: a project’s pay data is totalled together.
Learn moreA mapping left without a tax authority applies to that pay code under every authority, so fill in authorities wherever one pay code exists under several. Before a run, the readiness check lists unmatched pay codes and unmapped employees.
Runs keep one-sided rows and grade the amount difference against absolute thresholds. Reviewers link defects or KD/AD records to rows. Decisions stay on the run they were made in; a rerun produces fresh rows, so link accepted differences again.
Six report types come as PDF or Excel. The Comparison report lists up to the 500 largest over-threshold rows; export the results grid to Excel for every row.
Learn moreHirra, in beta, works with your own permissions: it can read your data and, if your role allows, raise defects or update review fields; it cannot run comparisons or imports from chat yet.
Learn moreA short checklist to keep beside the method. Each item should be true before you sign off.
The terms are used interchangeably. Both mean processing the same period in the current and the new system and comparing the results. Some teams use “parallel run” for one cycle and “parallel testing” for the whole exercise.
There is no fixed number. Choose enough periods to exercise the rules that changed and the events your population has, and keep going until the variance count is stable and explained. In SmartCompaire, each project totals all of its pay data, so create one project per period you want to compare separately. Each project needs its own employee and pay code mappings, so upload the same mapping files to each.
No. SmartCompaire runs a parallel test from files exported from your source and target systems, in .xlsx, .xls or .csv format, or from rows you type or paste. It has no live connection to any payroll or time system and does not write anything back.
Partly. A time project uses the same file layout and engine as payroll. Only the Amount difference is graded; hours or units in the Number column are compared and shown but not graded, so include amounts if you need pass or fail. There are no time-specific rules such as shifts, overtime or punches.
A known or accepted difference: a variance the team has investigated and decided is expected, such as a deliberate rule change in the new system. In SmartCompaire, a KD/AD record holds the description, a link to the justification document, an assignee and an approval status, and you link it to result rows one at a time.
Bring a source and a target extract from your parallel run; we will walk through the comparison with you.
Request a demo