Reconcile before release, not after. Check headcount movement against the register, then produce a month-on-month variance by employee and require a written reason for every mover. Tie deduction totals to what you are about to remit, tie the bank file total to the register, and clear the exception list to nil before anyone approves.
Because you are not verifying a calculation, you are verifying a change. The computation was performed by a system that will perform it the same way every time; what you cannot assume is that the inputs were right. Comparing this period against the last turns thousands of numbers into a short list of people whose pay moved, and every mover has either a reason you can name or a problem you have just found. A promotion, a deduction for unpaid leave, a new joiner, an exit, a recovery that started or ended. Anything that moved without a reason is the finding. This discipline is what keeps [payroll management](/payroll-management) honest without reading every line.
Start with people, because a payroll that pays the wrong set of employees cannot be rescued by correct arithmetic. Take the closing headcount from the previous period, add the joiners you have documented, subtract the exits, and compare the result against the count of employees in this run. Then compare the two name lists rather than the two counts, since an addition and an omission cancel out numerically and look perfectly fine. Employees on unpaid leave, on notice, on suspension or transferred between entities usually break the tie, so keep them on a standing exceptions list. Your [employee database](/employee-database-software) should be the source here, not a recruiter's spreadsheet or a manager's recollection.
One row per employee, the previous period's net, this period's net, the difference, and enough component detail to explain it without opening another report. Sort by the size of the movement in both directions, since a large increase deserves the same attention as a large decrease. Include a separate count of employees whose pay did not move, so the population adds up. Add a column for the explanation and require it to be completed by the person accepting the row rather than the person who prepared it. Keep the report after release, because next month's queries almost always concern last month's movements.
Expected: a revision with an effective date you approved, proration for a partial period, unpaid leave that matches the attendance record, a recovery instalment, an incentive from a scheme with a documented calculation, a statutory change applied across a group. Unexpected: a movement for someone whose record nobody touched, a group of employees all moving by an identical amount for no stated reason, a deduction appearing for the first time, or a component dropping to nothing. Trace the unexpected ones back to the input rather than to the calculation. Where the input was attendance, check it in the [attendance management system](/attendance-management-software) rather than in the payroll extract, since a bad sync looks consistent in both.
Take the deduction totals from the register, obligation by obligation, and compare them against the amounts you are preparing to remit and the employee lists behind them. The check is arithmetic; the value is in the mismatch. An employee who should be covered and is not, someone still being deducted for after their exit, a group whose totals shifted because a configuration changed. Do this before release rather than at remittance time, because a correction is far easier while the salary has not yet left the account. Where an obligation is unclear, or a state's treatment differs from what you expected, confirm the current position with a qualified advisor or the relevant authority instead of making the register fit an assumption.
The register says what people should be paid. The bank file says what will actually leave the account, and the two can diverge without either being obviously wrong. Compare the file total and its line count against the approved register, and reconcile any difference to a named list, usually people held back for missing or failed bank details. Look for duplicate account numbers, since two employees sharing an account is occasionally legitimate and more often a data error. Confirm nobody in the file has a nil or negative net. Then confirm the file was generated after the last correction rather than before it, which is the mistake that survives every other check.
Anything the run flagged and anything the reviewers could not explain: negative net pay, an employee with no attendance record, a structure missing a component, a recovery larger than the amount payable, a joiner without a bank account, a leaver still in the run. The list must be cleared to nil before approval, where cleared means resolved or consciously accepted with a recorded reason, not quietly ignored. Give it one owner rather than distributing it, because a shared list is an unowned list. Keep the cleared version with the run; when somebody asks months later why a payslip looked odd, the answer is usually already written there.
Pitch N Hire is an applicant tracking system built for recruiters and hiring teams. If this answer described something you want to run properly, the ATS is where it lives.
Free for 1 user · No credit card · Talk to a real hiring expert
Get a personalized walkthrough of Pitch N Hire on your own roles and workflow. No slides, no obligation.
Prefer to talk? Book a demo · Talk to sales · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
