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, 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 guides describe its steps carefully. None of them says the thing that makes the job smaller: the three numbers disagree for structural reasons that have nothing to do with errors, and the reasons can be removed.

Six minutes, three decisions. Everything on screen is a mock demo with sample data: an invented company, invented people, invented figures. The time system records what people did: hours, by day, by person, sometimes by project, approved by a manager on the manager's schedule. The payroll system records what people are paid: gross and net, by pay period, with the rules for overtime, allowances and deductions 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 by pay period and person, the ledger by period and cost centre, so a person who moved teams on the fifteenth is one row in payroll, two in the ledger and twenty in time. They differ in timing: a pay period ending on the twenty-fifth, a time cut-off on the twenty-eighth and a ledger period ending on the thirty-first give three different totals, all right.

And they differ in owner: operations owns time, people or a bureau owns payroll, finance owns the ledger, and each can change its record without the others knowing. 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 sitting 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 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 overpayment 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 as a warehouse with three stock counts, where 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.

So the question to ask before the vendor demo is not what the new system does, but who will write the mapping, because a company that cannot write it is not ready for the system either, however the demo looked. 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 the three periods reconcile 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 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 table.

And changes to a person, a start, a move, a leaver, flowing from one record to all three, which is the onboarding chain in our earlier video. Whether the systems are Zoho People, Zoho Payroll and Zoho Books, or a mix the company arrived at over ten years, the wires are the same engineering work. 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 reconciles 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. Where to start is last month's reconciliation, sorted into two piles, structural and error. 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.

The mapping table is written from the structural pile, and that table is most of the design. Three records of one month differ in grain, timing and owner before anyone makes a mistake, and the real errors hide inside that gap. Write the mapping once, agree the cut-off, give each fact one owner, and wire the three systems so the facts flow one way. The spreadsheet proves it for three months and then retires. We are CodeStringers, a Zoho authorised consulting partner. The wires are integration work under a guaranteed estimate, and discovery is no-risk: we sort one month's reconciliation with you, and you pay only if you go ahead.

The post and the onboarding video are linked below.