Ask anyone who has run payroll for a few years about their worst month, and you will almost never hear a story about arithmetic. The calculation was right. It was given the wrong input, and nothing stood between that input and a finalized run.
What actually goes wrong
Payroll errors cluster into a small number of shapes, and they share a cause: the figure was computed correctly from something that was not true.
- Hours that drifted. A shift filed under the wrong calendar day moves hours across a period boundary, so a month is short and the next one is long.
- An overtime rule that did not apply. The policy was correct in principle and not configured in the system, so it was applied from memory — or not at all.
- A currency that got assumed. An employee paid in a different currency appears correct numerically and is wrong by the exchange rate.
- A stale salary. The raise was agreed in a conversation and recorded a week after the cycle closed.
- A missing timesheet. Nothing objected to the absence, so the hours were simply not there.
Notice that no better formula prevents any of these. They are all failures of visibility: something was wrong, and the system had no moment at which a person was shown it.
Why the moment matters more than the math
A payroll error is unusually expensive relative to its size. An employee underpaid by a hundred dollars does not file a ticket and move on — they lose a measure of confidence in the company, and that is not refundable with the correction. An employee overpaid has to be asked to return money, which damages the relationship in a different direction and creates work for everyone.
The asymmetry is the argument for a review step. Reading a prepared run takes minutes. Correcting a finalized one costs a conversation with every affected person, an adjustment in the next cycle, and a small permanent dent in trust.
What a review step is, and is not
A review step is a stage in the process: the run exists, it is fully calculated, and it is not final. You read it, and then you finalize it. The important part is that it is a stage rather than a report, because an optional report is one someone eventually stops opening.
It is not an approval chain. Adding three signatures to a payroll run does not make it more correct; it makes it slower and spreads responsibility thin enough that nobody reads it carefully. One person reading the run properly beats three people clicking approve.
And it is not a preview that shows only totals. A total tells you whether the number is roughly what you expected, which catches an error of a thousand and misses an error of fifty across four people. The review has to show the lines, with their breakdowns.
How it works in OneclickHR
Payroll in OneclickHR is built as a run with a review step in front of finalization. You build the run, read it in full, and then finalize it. Nothing is final until you have looked at it.
The run reads its inputs from the rest of the workspace rather than from a separate payroll data entry step. Hours come from the attendance records and the approved timesheets. The overtime rule comes from the policy configured in workspace settings, written down once rather than remembered each cycle. Salary and currency come from the employee record. Pay schedules follow the cadence your organization actually pays on.
Each payslip shows its components rather than a single net figure, which does two things. During review, a line that looks wrong can be traced to the part of it that is wrong. And after finalization, an employee asking why a number is what it is has the answer on their own document rather than having to ask.
The inputs have to be trustworthy too
A review step catches what a human notices. It is not a substitute for inputs that are correct in the first place, and the most common bad input is subtle enough to survive a careful read.
Attendance dates are the usual culprit. If a clock-in’s calendar day is computed in the server’s timezone rather than your organization’s, hours can sit in the wrong period, and the resulting total looks entirely plausible — just slightly wrong. OneclickHR derives the calendar day from your organization timezone precisely so that the hours a run consumes belong to the days you think they do.
Approval state is the other one. Approved timesheet hours are the hours a run reads; unapproved hours stay out. That means a missing week shows up as missing rather than silently contributing nothing, which is the difference between a question and an undetected error.
A practical review routine
The review step is only as good as what you do with it. Four checks catch most of what goes wrong, and none of them takes long.
- Compare the run total against last cycle. A change you cannot explain in one sentence is the thing to look at first.
- Scan for anyone whose figure moved. New joiners, leavers, raises and anyone who took leave are where movement should be — and anyone else who moved is a question.
- Check the hours on anyone who bills time. Cross-reference against their approved timesheets rather than trusting the total, especially near a period boundary.
- Confirm currencies on anyone paid outside your default. This is the error least likely to look wrong and most likely to be wrong.
The most valuable feature in a payroll module is not the calculation. It is the moment before the calculation becomes final.
Finalized payslips go straight to each employee’s self-service portal as PDFs, in whichever of the two formats matches where they are paid, carrying your brand color. By then the figures have been read by someone — which is the only part of the process that was ever going to catch an input nobody questioned.