Payroll

What are the inputs to a payroll run?

Four streams feed a run, and each has a different owner. Master data says who is employed, on what terms, in which location and to which bank account. Time data says how many days were worked and how many were absent. Transaction data carries the one-off items: reimbursements, recoveries, arrears, incentive payouts and deductions instructed by an external party. Statutory parameters carry the rules applying in each place the employer operates. A run is only as sound as the weakest of the four, and the transaction stream is usually the one that arrives late, in an inconsistent format, from whoever remembered. Naming an owner for each stream is what turns a missing input into somebody's responsibility rather than a shared surprise.

Why does payroll need a formal approval step?

Money that has left the account and reached individual bank accounts is difficult to retrieve. Recovering an overpayment means asking employees to return money they have already received, which is slow, awkward and in some circumstances restricted. Approval exists to force somebody accountable to look at the run before it is released. The version of that review which actually catches things is not a line-by-line read but a comparison: what changed since the last period, who is new, who has left, whose net moved sharply, and who is being paid who should not be. Approval also fixes the moment after which the run counts as final, which is what makes any later correction traceable as a correction.

What does payroll owe after the money leaves?

Disbursement is the midpoint of the process rather than its end. The employer still has to remit amounts withheld along with its own contributions, file the returns each authority requires, issue every employee a statement of what was paid and what was taken, post the cost into the accounts against the right period and cost centre, and retain the underlying records. Which filings apply, in what form and on what timetable differs by jurisdiction and changes, so confirm the current position with a qualified advisor or the relevant authority rather than repeating last year's calendar. Treating these obligations as part of the run, rather than as follow-up work, is what keeps them from slipping into the following period.

Where does a payroll run actually break?

Rarely in the calculation. A configured [payroll software](/payroll-software) applies the same rules the same way every period; what varies is what it is handed. The recurring failure is an input that never arrived - a resignation recorded in the people system but not passed on before the cut-off, an approved claim sitting unread, an attendance file uploaded the day after close. The second failure is an input that arrived in the wrong shape: a transposed bank digit, a location code that has been retired, a component added to one person's structure without the rule that reads it being updated. Both produce a run that completes without error and pays the wrong amount. The system reports success because nothing it was asked to check was violated, and the check that would have caught the problem was never expressed anywhere in the first place.

Making inputs visible before the run rather than after it is the design response. A pre-run checklist naming each feeding system, its owner and whether the file has landed turns a silent omission into a blocking one, which is the whole point: an absent input should stop the run instead of being processed as a zero. Exception reports covering anyone whose pay moved materially, anyone with no attendance record and anyone joining or leaving give a reviewer somewhere specific to look, in a document short enough to read properly. Teams that spend the least time on corrections rarely have the most elaborate [payroll management](/payroll-management) configuration; they are the ones who stopped treating the cut-off as a suggestion, and who accepted the small amount of unpopularity that comes with holding it every period.

Who owns payroll, and what does the owner actually do?

Ownership is genuinely contested, because the process sits between two functions with different instincts. Human resources holds the employment facts and the relationship with the person. Finance holds the bank mandate, the ledger and the answer owed to the auditor. Splitting the work between them without naming one accountable owner produces the familiar situation where a query about a deduction travels back and forth and nobody closes it, while the employee waits and draws their own conclusions. The arrangement that holds names a single owner for the run, usually whoever is answerable for it being right and on time, and casts the other function as a control rather than a co-driver. Written that way, the split stops being a matter of goodwill between two teams that reorganise independently.

Day to day the owner's job is sequence rather than calculation. They publish the calendar, chase the inputs, hold the cut-off, run the exception review, obtain sign-off, release the payment, confirm the remittances, and answer what comes back. Nearly all of that is coordination across people who do not report to them, which is why standing inside the organisation matters more in the role than technical depth does. An administrator with no authority to hold a cut-off will lose it every period to whoever escalates hardest, and the corrections that follow will land on the same desk, which is how a capable person ends up permanently behind. Giving the role explicit backing from whoever approves the run costs nothing and changes the outcome of every difficult conversation it involves.

How does payroll stay auditable?

By being reconstructable. An auditor, an authority or an employee with a grievance will eventually ask why a named person received a particular amount in a particular period, and the answer has to be assembled from records rather than memory. That requires keeping the inputs as they stood at the cut-off rather than as they stand now, keeping the calculated output of each run, keeping evidence of who approved it, and keeping the remittance confirmations together with it. Systems that let historical data be edited in place quietly destroy this, because what they then show is the current answer, not the one that was acted on. The distinction only becomes visible when somebody asks, by which point the original is gone and nobody can prove what it said.

Agreement between sources is the other half. What the run calculated should reconcile to what left the bank, to what was posted in the ledger and to what was reported to the authorities. Differences are ordinary - timing, rounding, items paid outside the run - but each should be identified and described while somebody still remembers what it was and why it arose. An unexplained difference carried forward does not stay the size it started at; it compounds quietly across periods, and the version discovered at year end takes somebody a week to unpick under time pressure. Reconciling every period is the cheaper habit precisely because it keeps the number of candidate explanations small enough to work through in an afternoon.

What changes as headcount grows or spreads across states?

Scale changes the character of the work, not only its volume. A small population can be reviewed line by line, so mistakes are caught by reading. Beyond a certain size nobody reads every line, and the process has to move from inspection to control: validation that prevents bad input, exception reports that surface the few records worth attention, and separation between whoever prepares a run and whoever releases the money. Employers running [combined HR and payroll software](/hr-payroll-software) inherit some of that separation from the system, but the discipline of acting on the exceptions is not something software supplies. The transition is rarely noticed while it happens, which is why most teams discover it retrospectively, in the period where something was missed that reading would once have caught.

Geography introduces a different problem entirely. Employment, wage and social security obligations vary between states and countries, so an employer present in several is subject to several sets of rules at once, each able to change on its own timetable and none of them coordinated with the others. Registrations, filings and thresholds do not travel, and an assumption carried across from one location is a frequent source of error in the next, particularly where the two use similar vocabulary for different things. Treat every jurisdiction where people are paid as its own compliance perimeter, and confirm the current requirements there with a qualified advisor or the relevant authority. Deciding who watches for changes in each location is part of the design rather than an afterthought.