Payroll data: why it's always late

Every month, the same scene. Someone in HR or management control messages an operations manager: "you haven't sent your payroll data." Then a second message. Then they ring. And once the inputs arrive, they spot an anomaly: "you haven't put a bonus for so-and-so, is that right?" Answer: "oh no, that's an oversight."

That conversation is expensive, and it repeats twelve times a year.

Lateness isn't negligence#

You have to start there, because the instinctive answer — "we need to remind them of the deadline" — is the one that has been failing for years.

An operations manager who has to submit inputs by the 10th has, on that day, teams to place, an unhappy customer and a late delivery. Payroll data has no visible consequence on the 10th; they have one on the 28th, and for somebody else. A task whose cost of delay is borne by another department always comes last. That isn't bad faith, it's rational prioritization.

Two further mechanisms pile on#

• You have to remember what happened three weeks ago. The completion bonus for the job on the 18th is written down nowhere. It's in somebody's head, and they have to reconstruct it.
• The format changes by line of business. A matrix per activity, more or less standardized, more or less up to date. Every month you have to work out again how to fill it in.

The oversight costs more than the delay#

A delay postpones work. An oversight gets paid for three times.

The first time, when somebody spots it#

If they spot it — which assumes management control knows the field well enough to find a missing bonus abnormal.

The second, in the adjustment#

The following month: an extra line, an explanation to write, a pay stub that becomes unreadable.

The third, and dearest: the conversation#

With the employee. Explaining to someone that their bonus was forgotten is a conversation that damages trust lastingly, however good the explanation.

We explain it was an oversight. The employee hears that we don't keep track of what they do.

What fixes it: removing the reconstruction#

The real culprit is memory. You're asking someone, once a month, to remember everything that happened. No amount of chasing corrects that.

How do you stop reconstructing inputs from memory? the variable input is recorded when it happens, not when it's declared.#

When a job finishes with its associated bonus, when an on-call shift is worked, when a trip takes place — the information already exists somewhere, in a schedule, a job report or a timesheet. There is no reason to re-enter it three weeks later from memory.

The four steps, in practice#

1. The event creates the line. A completed timesheet, a closed job, a recorded on-call shift feed the month's summary directly.
2. The manager no longer enters: they check. They receive a pre-filled statement and approve, or correct. Going from "fill in" to "verify" completely changes the time required, and therefore where the task sits in their priorities.
3. Anomalies are caught before submission, not after. An employee who worked on a bonus-bearing job and has no bonus: the gap is flagged to the manager, not to the controller three days later.
4. Whatever is still incomplete escalates by itself, by name, with the detail of what's missing. No more "you haven't sent your inputs" — instead, "the on-call shift on the 12th is missing for two people".

The automatic check that pays best#

Just one, and it's worth all the others: comparison with the previous month, line by line, per employee.

A bonus present eleven months out of twelve and absent this month: flagged. A number of hours more than twenty percent off the average: flagged. An employee assigned to a bonus-bearing activity with no bonus: flagged.

This check is trivial to write and catches nearly every oversight, because an oversight is almost always a break from a habit. It doesn't replace the manager's judgment — it asks them the three right questions instead of leaving them thirty to ask themselves.

What not to automate#

Sending without human approval#

A wrong input sent automatically becomes a wrong pay stub, and a wrong pay stub is very hard to correct. Approval must remain a conscious act, even if it takes ten seconds.

Calculating a discretionary bonus#

If the amount depends on judgment, leave the judgment to a human. The tool can flag that a bonus is expected; it must not decide the amount.

Silent correction#

A discrepancy corrected without anyone knowing is a discrepancy nobody will understand at close. Anything changed after approval must be dated and attributed.

How we get them in on time#

Payroll data arrive late because they are gathered at month end, from four different places. What we install collects them as they happen: hours, spans, bonuses and absences recorded at the moment they occur.

At close there is nothing left to gather. The export goes to your payroll software or your accountant, in their format, and nobody retypes a file. We do not run payroll: we prepare what the people who do run it are waiting for. See the hours and payroll preparation module.

Payroll data: what to remember#

Lateness comes from the task costing the person who does it and benefiting somebody else. No amount of chasing changes that asymmetry.

Create the input at the moment of the event, and turn the manager's monthly work into verification rather than reconstruction from memory.

Then add a single piece of automation: comparison with the previous month. That's what catches the oversights — and it's the oversight, not the delay, that costs the most.