Where payroll switches go wrong
Picture a small accounting firm that runs payroll for a dozen local clients. The firm has picked a new payroll system and plans to move everyone at the start of next quarter. The setup screens look right, the employee list imported cleanly, and the vendor's checklist is all green. Then the first live pay date arrives, and one client's net pay is off for three employees because a deduction was set up as pre-tax in one system and after-tax in the other. That scene is an illustration, not a TwoQM client.
A switch is safest when the new system has already produced the same paychecks as the old one, side by side, before anyone is paid from it. That side-by-side run is a payroll parallel test. This piece is about running one as an organized, reviewable process instead of a few spot checks on a spreadsheet.
This is an operations article, not payroll, tax, or accounting advice. Your firm, your clients' agreements, and the official guidance decide how wages, deductions, and taxes are set up and reported. Nothing here is advice for any specific client.
TwoQM has already written about recurring bookkeeping task boards by close date and about trainer payroll built from classes taught and packs sold, which is about calculating pay inputs. This piece is different: proving that a new payroll system matches the old one before the cutover.
Here is an original example, not a measured result. Firms moving clients between payroll systems usually run into the same gaps:
Setup is checked, output is not. Screens are reviewed field by field, but nobody compares a finished paycheck.
Year-to-date balances are loaded late or partly. Wage bases, limits, and accrued time off depend on them.
Deductions map loosely. A benefit, garnishment, or retirement deduction lands in the wrong category.
Edge cases are skipped. The test period happens to have no new hire, no termination, no bonus, and no mid-period rate change.
Differences are fixed silently. Someone adjusts the new system until the number matches, and nobody records why.
Nobody signs off. The go-live date arrives by default, not by decision.
Decide what the test compares
Before the first test run, the payroll lead agrees on what gets compared for each client, employee by employee:
Gross pay by earning type, such as regular, overtime, bonus, and commission.
Each deduction, pre-tax and after-tax, by its own line.
Each withholding and employer tax line as both systems calculate them.
Net pay and the direct deposit split.
Year-to-date totals after the run, including time-off balances if the new system tracks them.
The employer's total cost for the period.
Then the firm writes down its own tolerance and go-live rule, for example "every line matches, or every difference has an explained and approved reason." The firm sets that rule; software does not.
Run it on real periods, without paying anyone twice
Run the same pay period through both systems using the same hours and changes. The old system stays the system of record and pays employees. The new system's run stays a test: no direct deposits, no filings, and no payments leave it. Repeat for more than one period when the firm decides that is needed, and choose at least one period that includes the edge cases your clients actually have.
Keep a variance log, not a pile of fixes
Every difference goes on a variance log with the client, employee, line, both amounts, the cause, who resolved it, and whether the fix was to the old setup, the new setup, or the imported data. A reviewer other than the preparer approves each resolution. When the log is empty or fully explained, the reviewer signs off on the cutover for that client.
Plan for the old records too. The IRS employment tax recordkeeping guidance says to keep all records of employment taxes for at least four years after filing the fourth quarter for the year, so decide before the switch how the firm will keep access to the old system's reports. The IRS Publication 15 (Circular E), Employer's Tax Guide is the general federal reference your reviewers can check setups against.
Where automation and connected systems help
Connected systems can pull the payroll register export from both systems and line them up by employee and pay item, even when the two systems name things differently. A mapping table, reviewed once by the payroll lead, translates one system's items to the other's.
Ordinary business automation can then do the routine checks:
Comparison report built after each test run, flagging only the lines outside the firm's tolerance.
Variance log entries created for each flagged line and assigned to a preparer.
Reviewer queue for resolutions waiting on approval.
Sign-off status per client, so the owner can see which clients are ready and which are not.
When the firm's clients and systems need something more specific, custom software can hold the whole test record in one place.
Where AI helps, and where it stops
AI can match item names between two exports for the payroll lead to confirm, draft a plain explanation of a variance for the reviewer, and summarize what is still open across all clients this week, in English or Spanish. A person reviews every draft. AI does not decide which number is correct, change a tax or deduction setup, approve a variance, or approve a cutover.
Where to start this quarter
Pick the client with the most complicated payroll. Write down the compare list and the go-live rule above, then run one past period through the new system as a test. Whatever the variance log shows is what your setup review missed.
TwoQM builds connected systems, automation, and custom software for accounting and tax firms. If your next payroll switch depends on spot checks, TwoQM can scope a parallel test workflow around the payroll tools your firm already uses. Pricing explains how business apps, systems, and custom software are scoped.
Describe Your Payroll Switch Workflow · Explore TwoQM connected systems