Between the Punch and the Payslip

The clock records two timestamps. The payslip shows hours and amounts. Between them sits a set of rules that transform one into the other, and that layer is where most of the unexplained differences in this subject are created.

The practical lesson in “Between the Punch and the Payslip” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring self report bias, read the provider overview can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

It is also the part nobody has read. The rules were configured at implementation, extended when something changed, and are now a set of interacting conditions that no single person in the organisation can describe.

For a separate benchmark relevant to “Between the Punch and the Payslip”, consult the ICAEW audit resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

What the layer does

Rounds the punch times, by some increment, in some direction, at some point in the chain.

Applies the shift pattern, matching the punches to a scheduled shift and deciding what to do with the difference.

Deducts breaks, by rule or by punch.

Classifies the hours: standard, overtime, premium, unsocial, night, weekend, holiday.

Applies thresholds: hours over a daily or weekly figure, hours after a time of day, hours on a particular day.

And produces pay elements, which are what reach payroll.

Five or six steps, each with settings, each capable of being right in isolation and wrong in combination.

Why the order matters

Rounding before break deduction gives a different answer from rounding after. Applying a daily overtime threshold before a weekly one gives a different answer from the reverse.

These are not edge cases: they affect every shift that is not exactly standard, which in most operations is most of them.

The order is a configuration decision, it was made once, and it is almost never documented. Asking what order the rules apply in is a question that produces silence in a surprising number of organisations.

The documentation that should exist

One page: the rules in order, with their settings, in plain language.

Rounding: increment, direction, applied to each punch or to the daily total.

Break: fixed or punched, threshold, amount, applied once or per threshold.

Overtime: daily threshold, weekly threshold, which applies first, what rate.

Premiums: what triggers each, at what rate, whether they stack.

Written like that it fits on a page and it can be checked against the contract, which is the thing nobody does.

Checking it against the contract

The contract or collective agreement says what people are paid for. The configuration says what the system calculates. They are written by different people at different times and they disagree more often than not.

Take five real shifts of different shapes — a standard day, a long day, a night, a weekend, one with an overrun — and calculate each by hand from the contract. Then compare with what the system produced.

Half a day. It finds real discrepancies in most organisations that try it, and it finds them before somebody else does.

Where the person's view comes in

The payslip shows the output. The time system shows the input. Nothing shows the steps.

A worker who thinks they are owed more cannot check, which means the only route available is to raise it, which means a dispute where a self-service explanation would have done.

Systems that can show a worker their own calculation — these punches, this rounding, this deduction, these hours at these rates — remove a substantial share of pay queries. The capability is common and the configuration is rare.

The change nobody records

The most dangerous property of this layer is that it can be changed silently. A setting adjusted during an upgrade changes every subsequent calculation and leaves no trace in the output.

Any change to a rule in this layer should be a dated, documented decision with a named owner and a statement of the before and after, held with the payroll records.

Without that, an unexplained shift in paid hours across a population has no cause anybody can find, and the search for it starts with the assumption that the people changed rather than the configuration.

Why a spreadsheet is the wrong place for it

On a surprising number of sites part of the translation happens outside the system: a sheet that applies an adjustment, a monthly manual correction, a formula somebody built when a rule could not be configured.

Those are the parts with no audit trail, no version history and one person who understands them. Bringing them inside the configured rules is worth doing even where the configuration is uglier, because a rule that is visible can be checked and a spreadsheet on one laptop cannot. Where it genuinely cannot move, it needs the same documentation as a pay rule and a second person who can run it.