Detection versus protection

There are two ways to run a compliant payroll. You can check afterwards and correct what you find, or you can prevent the thing happening in the first place. Both are described as compliance. They are not remotely equivalent.

What detection actually costs

A detected error is not one piece of work. It is a correction, a re-run, an adjustment on the next payslip, a conversation with a worker, possibly a conversation with an agency, an amended submission, and a note somewhere explaining what happened. The original error took a moment to make and takes considerably longer than that to unwind.

• It is reactive - the trigger is someone noticing.
• It requires manual review and investigation, which is the scarcest resource in a payroll team.
• It is time-consuming and lands in the window after a pay run, which is exactly when the team has least capacity.
• It carries higher risk, because some errors are only visible once money has left the account.

What protection looks like

Protection means the control runs as part of the payroll process, not alongside it. A missing right-to-work document is not a report you read on Monday; it is a condition that stops the calculation and asks someone to resolve it.

• Issues are prevented before they arise rather than identified after they occur.
• Controls are automated and consistent, so they do not depend on who is on shift.
• Checks are proactive and continuous rather than periodic.
• Risk is lower and assurance is stronger, because the evidence is a by-product of the process.

The cheapest error is the one the system would not let you make.

The trade-off is real: a system that blocks will occasionally block something you wanted to proceed. That is why an exception route with named approval matters as much as the control itself. A control nobody can override gets worked around; a control anyone can override is decoration. The useful middle is an override that is easy, logged, and attributed.