A leaver paid, a starter missed
The payroll for a restaurant group is processed. The checker opens the variance report: every employee, every element, this period against last. It is long. They scan for anything odd, see nothing obvious, and sign it off.
On pay day, a chef who left last month has been paid again, a new waiter has not been paid at all, and a manager's bonus went through twice because it was entered in two elements. All three were in the report. None stood out among the hundreds of lines.
Why checking by eye misses things
Variance reports show everything, and most of it is normal. The unusual lines, which are the whole point of checking, look the same as the normal ones. Checkers get used to certain clients always having big variances and start skimming. And in crunch weeks, the time for checking is squeezed while the number of runs to check goes up.
Some errors do not show as variances at all. An employee missing from this run simply has no line, and a starter the client mentioned in an email but never set up does not appear anywhere.
What errors that reach pay day cost
Every pay error means a correction, often an off-cycle payment or a recovery from the next run, which is more work than getting it right. Overpayments are awkward to recover. Underpayments hurt employees immediately. Clients judge the bureau on pay day, and a few visible errors can undo years of quiet accuracy.
| Check | What it catches |
|---|---|
| Employee present last period, missing now | Unprocessed hours or an unnotified leaver |
| Leaver still being paid | Leaver date not applied |
| Net pay change beyond a threshold | Keying errors, duplicated elements |
| Element used for the first time | Wrong element chosen |
| Starters in intake not in the run | Starters not set up |
| Hours far above normal for the role | Typing extra digits |
How we build variance checks for a bureau
- When a run is processed, its results are read from your payroll software and compared with previous periods for the same client.
- A standard set of checks runs, like those in the table, plus any client-specific checks you add, such as a cap on overtime hours or an alert when a particular element is used.
- The inputs the client sent for this period are compared with the run, so a starter, leaver or change that arrived but was not processed is caught.
- The checker sees a short list of flagged items with the reason for each, rather than the full report, although the full report is one click away.
- Each flag must be cleared with a note, or sent back to the processor, before the run can be marked checked in your workflow.
- Thresholds are tuned per client over time, so clients with naturally variable pay do not generate a flood of flags.
The checks point to things worth looking at. The checker decides whether each is right.
Checking that finds the problems
Checkers spend their time on the handful of lines that matter. Missing employees and unprocessed starters are caught before pay day. Crunch weeks stop meaning weaker checks. And every run has a record of what was flagged and how it was cleared, which is useful when a client asks how you make sure payroll is right.
Do errors slip past your checks?
- Checkers read long variance reports line by line.
- Leavers have been paid after their leaving date.
- Starters have been missed because they were never set up.
- Checking gets rushed in the busiest weeks.
- You have no record of what a checker looked at.