The payroll accuracy guide.

Payroll errors are almost never arithmetic. The maths of tax and deductions is mechanical, and computers do not mistype it. Errors come from the inputs: the salary change that never reached the payroll file, the overtime claimed but not recorded, the leaver paid a full month, the starter missed entirely. In other words, payroll is usually wrong because it is fed from copies of data rather than the data itself, and the copies were already stale by payday.

The cost is larger than the correction. An underpaid employee experiences the error as a breach of the most basic promise employment makes, and trust spent on payday is rebuilt slowly, one correct month at a time. Overpayments are quieter and often worse: awkward to claw back, sometimes legally constrained, occasionally never noticed at all. And every error found by an employee rather than a control is also a signal, to everyone they tell, about how the company is run.

Most payroll processes still involve a human carrying numbers between systems: exporting hours from one tool, editing a spreadsheet, pasting into another, uploading to a bureau. Every one of those hops is a place where a digit transposes, a row slips or a stale file wins. Call it the re-keying tax: a defect rate paid every month, in proportion to how many times the same fact is retyped on its journey from where it happened to where it is paid.

The tax compounds with tempo. Month end is a deadline, deadlines invite shortcuts, and shortcut edits made directly in the payroll file are precisely the ones that never flow back to the source system, so the two drift further apart and next month’s reconciliation starts deeper in the hole. Any serious accuracy programme begins by counting the hops and then eliminating them, not by asking people to retype more carefully.

Errors get cheaper the earlier they are caught, and the cheapest moment is before processing. Pre-run validation is a gate that checks the inputs while fixing them is still trivial: missing bank details, missing hours for hourly staff, duplicate records, starters without pay data, leavers still active, pay below zero or below the legal floor. None of these checks is sophisticated; their power is that every one runs on every cycle, mechanically, so the run starts from inputs known to be complete.

The alternative is the correction loop everyone recognises: the payslip lands, the employee spots the problem, a ticket is raised, an off-cycle payment is arranged, and the ledger carries the scar. One month of that loop consumes more effort than a year of validation gates. Payroll teams that seem calm are not braver; they have simply moved the error-finding to the point in the cycle where errors are still cheap.

Validation catches broken inputs; it cannot catch plausible ones. A salary entered as 41,000 instead of 14,000 passes every completeness check. The control for plausible errors is comparison against the person’s own history: flag any line that moves sharply against the previous cycle, a net pay jumping by a large fraction, overtime suddenly doubling, a deduction vanishing, and require a human to confirm each flagged line before anything pays out. Most flags will be legitimate, a raise, a bonus, a return from leave, and confirming them takes seconds.

The value is in the asymmetry. Reviewing a dozen flagged lines costs minutes; the unreviewed anomaly that reaches a bank account costs a clawback conversation at best. Thresholds need tuning, because a threshold set too tight buries the reviewer in noise and teaches them to click through, which quietly disables the control. A sensible starting point is flagging variances beyond a set percentage against the prior cycle, then adjusting with experience.

In a spreadsheet payroll, one person often edits the numbers and approves the payment. That concentration is exactly what control frameworks exist to prevent, not because payroll staff are dishonest but because unreviewed work is where both fraud and honest error live. Dual control is the minimum standard: the person who prepares a run cannot be the person who approves it, and payment requires two named sign-offs, recorded, with the approvers shown what changed and why.

Done properly, dual control also protects the payroll team. A sole payroll administrator carries unshared risk: every error is theirs alone, and holidays become impossible because the process lives in their head. Splitting preparation from approval spreads the knowledge, creates a natural review conversation each cycle, and means the audit answer to "who authorised this payment" is two names and a timestamp rather than a shrug.

Each control above treats a symptom. The cause, in most organisations, is that payroll runs on a copy: a file assembled monthly from exports of systems that have already moved on. The structural fix is for payroll to read the same record HR maintains, so that a salary change, a new joiner, a leaver or an approved overtime sheet is already in the next run, because there is nowhere else for it to be. Reconciliation disappears not because someone does it faster but because there are no longer two versions to reconcile.

One record does not remove the need for the gates; validation, anomaly review and dual control still run, because inputs can be wrong at source and people still make plausible mistakes. What it removes is the class of error that no amount of care can beat: the copy that was stale before anyone touched it. Accuracy stops being a monthly achievement and becomes a property of the architecture.