Payroll automation

Most business systems can absorb an occasional error. A wrong figure in a report is corrected in the next report; a mis-routed enquiry is re-routed. Payroll cannot. An error is felt by a specific person, in their bank account, on a date they were relying on, and correcting it in the next cycle does not undo the month they had.

That property should drive the design, and it usually does not. Payroll systems are typically specified around calculation features and speed of processing, when the properties that matter are whether an error can be caught before the run and explained afterwards.

Reconcile before, not correct after

The most valuable thing an automated payroll can do is refuse to run cleanly when something is unresolved.

• Unapproved attendance exceptions — a missing clock-out, an unexplained absence — should block or flag the run rather than being computed as zero or as a full day.
• A salary that changed since the last cycle should be surfaced, not silently applied. Most are legitimate; the one that is not is the one this catches.
• A variance check against the previous cycle catches the largest class of error cheaply: this person's pay moved by more than a threshold, is that expected?
• A new joiner with no complete record, or a leaver still present, should both be flagged before rather than discovered after.
• Totals should be checked against the previous period at department and company level, because an individual error can hide inside a plausible individual figure and shows up in the aggregate.

Everything has to be explainable

When someone queries their pay, the answer has to be reconstructable — not recomputed, reconstructed as it was at the time. Those are different, and the difference matters when rules have changed since.

1. 1

   Store the inputs to each run, not only the outputs

   The hours, the rates, the rule versions and the deductions as they stood. A payslip that can only be regenerated by re-running today's rules cannot explain a payment made under last quarter's.

2. 2

   Version the rules

   Tax bands, overtime multipliers and allowances change. A rule change should apply from a date rather than retroactively rewriting what already happened.

3. 3

   Log every manual adjustment with a reason and an approver

   Adjustments are legitimate and frequent. Unattributed adjustments are what make a payroll impossible to defend when questioned.

4. 4

   Keep runs immutable once approved

   A correction is a new adjustment in a later run, not an edit to a closed one. Editing history removes the ability to explain what was actually paid.

5. 5

   Make the payslip show its own working

   Hours, rate, overtime and each deduction as separate lines. A single net figure generates queries that a breakdown answers without anyone being involved.

Segregation, at a small scale

Payroll is the clearest case in a growing business for separating who can do what, and the most common place it is ignored because the same person does everything.

The combination that matters is the ability to change what someone is paid and approve the payment. One person holding both, with no independent review, is the standard fraud pattern in small organisations — not because the person is untrustworthy, but because the control that would detect a mistake or a compromise of their account does not exist.

• Separate the person who enters changes from the person who approves the run, even in a small team. The approver does not need to be senior, only different.
• Where that is genuinely impossible, compensate with independent after-the-fact review of the variance report, and record why the compensating control was chosen.
• Restrict who can see payroll figures by role. Salary data is among the most damaging internal data to leak, and it is frequently readable by whoever administers the system.
• Log access to payroll records, not only changes to them.

What should stay manual

Automation belongs in the calculation and the checking, not in the judgement.

• Approving the run. A human should confirm they have seen the variance report and accept it.
• Approving exceptions and adjustments. These are decisions with reasons, and the reason is the record.
• Interpreting a rule that is ambiguous. An ambiguous rule should be resolved in writing and then encoded, not encoded with a guess.
• Anything the business has not written down. Encoding an unwritten policy fixes one interpretation of it permanently, and payroll is the worst place to discover that the interpretation was wrong.

Where the data has to be protected

Payroll data is a small volume of extremely sensitive records, which makes it easy to protect properly and easy to overlook because it does not look large.

• Access on a named short list by role, with viewing logged, not only editing.
• Encrypted at rest, and reports not left in shared locations after distribution.
• Payslips delivered to individuals rather than to a shared mailbox or drive.
• Retention set deliberately, balanced against whatever statutory retention applies where you operate.
• Backups included in the access reasoning — a payroll backup readable by everyone who administers backups undoes the access control on the system itself.