Payroll Reconciliation: Why the Hours, the Pay Run and the Ledger Never Agree.
In most companies between fifty and five hundred people there is a person who, in the last week of every month, makes three numbers agree. The hours from the time system, the gross from the payroll run and the salary line in the general ledger. They never agree when they arrive. The person knows why, in the way a mechanic knows a particular engine, and the knowledge lives in a spreadsheet with tabs named after months.
That job is called payroll reconciliation, and the how-to articles describe its steps carefully. None of them says the thing that would make the job smaller: the three numbers disagree for structural reasons that have nothing to do with errors, and the reasons can be removed.
The time system records what people did: hours, by day, by person, sometimes by project, approved by a manager on a schedule the manager keeps. The payroll system records what people are paid: gross and net, by pay period, with the rules for overtime, allowances, deductions and the dozen adjustments that payroll knows and nobody else does. The ledger records what the company spent: a salary expense by cost centre, posted when the payroll journal arrives, in the accounting period.
Three systems, each holding a version of the same month, and the versions differ in three ways before anyone makes a mistake.
They differ in grain. Time is by day and project; payroll is by pay period and person; the ledger is by period and cost centre. A person who moved teams on the 15th is one row in payroll, two rows in the ledger, and twenty rows in time.
They differ in timing. A pay period ending on the 25th, a time approval cut-off on the 28th, and a ledger period ending on the 31st produce three different totals for the same people, and all three are right.
They differ in owner. Operations owns time, HR or an outsourced bureau owns payroll, finance owns the ledger, and each one can change its record without the others knowing. We described the general version of this in system of record versus source of truth: the trouble starts when more than one system may write the same fact.
The reconciliation is the monthly act of translating between the three grains, the three timings and the three owners. It is not finding errors. It is doing by hand the mapping that nobody built.
Because the structural differences produce a gap every month, the real errors hide inside the gap. An overpayment to a leaver whose time stopped but whose payroll did not. A contractor on the ledger as salary. An overtime rule applied in payroll that the time system does not know about, so the hours look wrong and are not. A cost centre that the ledger split and payroll did not.
The reconciler finds some of these every month and explains the rest as the usual differences, because the usual differences are real and there is a deadline. An over- or under-payment that falls inside the usual difference is found a quarter later, when the person leaves or the auditor asks. That is the cost of the job: not the hours it takes, but the errors that look like the gap.
It is the same mechanism we described in the warehouse, where three inventory counts are never right and the discrepancy that matters hides behind the ones that are expected.
Companies at this size often try to end the reconciliation by changing the payroll system, and discover the gap again in the first month on the new one. The new system has its own grain and its own cut-off, and it receives the hours the same way the old one did, from an export somebody prepares. The translation moved; it did not disappear. A payroll system is the record for pay. It is not the mapping between hours, pay and cost, and the mapping is what the reconciler was doing.
Not a bigger spreadsheet, and not, on its own, a new HR or payroll system. The job is removed by three decisions and one piece of integration.
The first decision is the mapping: which time rows roll into which payroll line, which payroll lines post to which ledger account and cost centre, written once as a table the systems share rather than once a month in a person's head. The second is the timing: one cut-off, or an agreed rule for the difference, so that the three periods are reconciled by construction rather than by explanation. The third is the write rule: time is the record for hours, payroll is the record for pay, the ledger is the record for cost, and each one receives the others' facts rather than retyping them.
The integration is the wire that carries them. Approved time to payroll, as the input to the run, with the overtime and allowance rules applied in one place. The payroll journal to the ledger, by cost centre, from the same mapping. Changes to a person, a start, a move, a leaver, flowing from one record to all three, which is the onboarding chain we wrote about in this series. When the mapping is shared and the facts flow one way, the three totals agree before the month ends, and the only differences left are errors, which is what reconciliation was supposed to find in the first place.
The spreadsheet does not disappear on day one. It becomes the test. For the first three months after the wires are in, the reconciler runs the old spreadsheet alongside the new totals, and the difference between them is the list of mapping rules the person knew and the table did not. Each one is added to the table. By the third month the spreadsheet is reconciling to zero, and the person who ran it is the person who understands the company's cost structure better than anyone, which is a far better use of them than translating grains.
That is also the honest measure of whether the work succeeded: not that a system was installed, but that the monthly gap went to zero and stayed there. It is the number we would be held to.
Take last month's reconciliation and sort the differences into two piles: structural, meaning grain, timing and owner, and errors. Most companies find the first pile is nine-tenths of the work and that the errors in the second pile were larger than they expected, because the first pile was hiding them.
Then write the mapping table from the structural pile. That table is most of the design, and a company that cannot write it is not ready for a payroll system change either, however the vendor's demo looked. Whether the systems are Zoho People and Zoho Payroll and Books, or a mix the company arrived at over ten years, the wires are integration work by engineers, done under a guaranteed estimate. Discovery is no-risk: we sort one month's reconciliation with you, and you pay only if you go ahead.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.