Two people can read the same pay run and ask it opposite questions. A lender underwriting a mortgage opens one employee’s paystub and asks what this person earns. A controller closing the month opens the payroll register for the whole company and asks where every dollar of that run belongs in the books. The first question ends at a person. The second ends at a general ledger account, and it is the one this article is about.
The payroll register is the employer’s own record of a pay run: one row per employee, one column per earnings code, deduction and tax, and a footer that totals every column. Payroll providers each render it differently, but every version exists to be posted. Its job is to become a journal entry, and later to tie out against the quarterly return the employer files. A register that has been read perfectly, field by field, can still post to the wrong accounts — and the journal will balance anyway.
That last point is why extracting a register is a different problem from extracting a paystub. Reading the numbers correctly is necessary. It is not the test that tells you the close is right.
The columns a paystub never shows
A paystub is written for the employee, so it shows what the employee earned and what was withheld from them. The register is written for the employer, so it carries everything the employer owes because of the same pay run, including amounts that never appear on anyone’s stub.
- Employer payroll taxes — the employer’s share of Social Security and Medicare, plus federal and state unemployment contributions. These are an expense of the company, not a deduction from the employee.
- Employer benefit contributions — the company’s share of health premiums, retirement matches and similar costs, which accrue as liabilities until they are remitted.
- Department or cost-center codes — the labels that decide which expense line absorbs each person’s pay.
- Taxable-wage columns — wages subject to each tax, which stop matching gross wages as soon as a pre-tax deduction or a wage cap enters the picture.
The quarterly return makes the employer side impossible to ignore. On Form 941 (Rev. March 2026), line 5a multiplies taxable Social Security wages by 0.124 and line 5c multiplies taxable Medicare wages by 0.029. Those rates are the employee and employer halves added together. A reconciliation that only reads what was withheld from employees is reconciling half of the liability the return reports.
A register is a journal entry waiting for a map
Posting a register means translating every column into a ledger account, a side of the entry and, for expense lines, a department. That translation is a mapping table, and the mapping table is where the accounting judgement lives. The illustration below is a simplified example, not a chart of accounts anyone should copy — the account names are exactly the part each company defines for itself.
| Register column | Ledger account (example) | Side | Split by department? |
|---|---|---|---|
| Regular earnings | Salaries and wages expense | Debit | Yes |
| Overtime earnings | Salaries and wages expense, or a separate overtime account | Debit | Yes |
| Federal income tax withheld | Federal withholding payable | Credit | No |
| Employee Social Security and Medicare | FICA payable | Credit | No |
| Employer Social Security and Medicare | Payroll tax expense (debit) and FICA payable (credit) | Both | Expense side, yes |
| Employee retirement deferral | Retirement contributions payable | Credit | No |
| Employer health premium share | Benefits expense (debit) and benefits payable (credit) | Both | Expense side, yes |
| Net pay | Payroll clearing or cash | Credit | No |
Two properties of this table matter more than its rows. First, it is keyed by the code the payroll provider prints, not by a column position or a heading guessed from layout, because the same heading can hide two codes and two headings can mean one. Second, it has a version. When the finance team moves overtime into its own account, every run posted after that date follows the new row, and every run posted before it still has to be explainable by the old one.
This is the same separation that runs through any document that feeds a decision: extraction produces facts, a written rule turns facts into an outcome. Here the facts are code, amount, employee, department and pay date. The outcome is a journal line. Keep the rule out of the extractor and a new chart of accounts is a configuration change instead of a retraining project.
A balanced journal proves almost nothing
The instinctive control on a payroll posting is that debits equal credits. It is a real control, and it catches arithmetic errors, but it is structurally blind to the failure that actually happens in production: a new earnings code.
Suppose the payroll provider adds a retention bonus code in March. The register prints it in a new column, and the mapping table has no row for it. A permissive pipeline sends unmapped codes to a catch-all account, or folds them into the nearest match by name, and posts. The entry balances to the cent, because the bonus was debited somewhere and credited to net pay. The trial balance looks fine. Three months later someone asks why miscellaneous expense tripled, or why the bonus accrual never reversed.
So the closing test has three parts, and only one of them is arithmetic:
- Footing — the sum of the extracted rows in each column equals the register’s own printed footer for that column. This proves the extraction read every row.
- Coverage — every code present in the register has a row in the current version of the mapping table. An unmapped code fails the posting; it does not route to a default.
- Balance — the generated entry has equal debits and credits, including the employer-side lines that appear only on the register.
The coverage test is the one that turns a silent misposting into a question with an owner. “Code RETBON appeared for the first time in this run; which account does it post to?” is a two-minute decision for an accountant. Discovering the same thing at quarter end is an afternoon of reversing entries.
It does not close per employee
The most counterintuitive reconciliation difference in payroll is also the smallest. Employer taxes are calculated per employee, per paycheck, and rounded to the cent each time. The quarterly return calculates the same taxes from quarterly totals multiplied by a rate. The two methods almost never agree exactly, and the return anticipates it: line 7 of Form 941 is the “current quarter’s adjustment for fractions of cents.”
That line is a useful reminder of what a register reconciliation is for. Summing hundreds of individually rounded amounts will drift from rate × total by a few cents, and that drift is correct. A reconciliation that insists on per-employee recomputation matching the quarterly figure exactly will raise a false exception every quarter, and teams quickly learn to ignore it — along with the real ones that arrive in the same queue.
The practical rule is to reconcile at the level where the numbers are authoritative. Use the register’s printed totals as the source of each pay run’s liability, sum pay runs to the quarter, and treat a rounding difference inside a stated tolerance as an expected adjustment, recorded as such. Anything larger is an exception worth a person’s time.
Tying the quarter out
The quarterly return is the external check on everything the registers said during the quarter. Each of its core lines has a register total behind it.
| Form 941 line | What it reports | Register source | Why it can differ from gross pay |
|---|---|---|---|
| Line 2 | Wages, tips and other compensation | Federal wages column, summed across the quarter’s pay runs | Pre-tax deductions such as retirement deferrals reduce it |
| Line 3 | Federal income tax withheld | Federal withholding column | Off-cycle and void runs belong to the quarter they were paid in |
| Line 5a | Taxable Social Security wages | Social Security taxable wages column | Wages above the annual wage base stop being taxable |
| Line 5c | Taxable Medicare wages and tips | Medicare taxable wages column | No wage base: it keeps growing after Social Security wages stop |
| Line 7 | Fractions-of-cents adjustment | Difference between per-paycheck tax and rate × total | Rounding, by design |
The right-hand column is the argument for extracting taxable-wage columns as printed rather than recomputing them from gross pay. The payroll system already applied the wage base, the pre-tax deductions and the treatment of each benefit when it ran. An extractor that recomputes taxable wages from gross is re-implementing payroll tax logic from a PDF, and it will be wrong precisely for the highest-paid employees in the fourth quarter, when the Social Security wage base starts to bind.
Timing is the other trap. The quarter a wage belongs to is decided by the date it was paid, not the period it was earned in, so a pay run covering the last week of June and paid on the second of July belongs to the third quarter. A register carries both dates. The extraction has to return both, labelled, and the reconciliation has to use the check date.
Where the cost center comes from
Department allocation is the part of payroll posting most likely to be guessed, and guessing is where expense lands in the wrong budget. Registers handle it in different ways: a home department printed on each employee row, subtotals by department, or a separate labor distribution report that splits one person’s hours across several cost centers.
The extraction contract should reflect whichever of those the document actually carries, and nothing more. If the register prints a department per row, return it per row. If it prints department subtotals, return those as subtotals, so they can be checked against the sum of rows. If it prints neither, return the absence, and let the allocation come from the HR system or a split table the finance team maintains. What the extraction must not do is infer a department from a job title, because an inferred department and a printed one arrive in the ledger looking identical.
What the extraction has to deliver
Put together, the contract between the register and the posting engine is a set of facts with evidence, and no accounting decisions.
- Every code, as printed — earnings, deductions, employee taxes and employer taxes, each keyed by the provider’s code and label, including codes seen for the first time.
- Row-level amounts and printed totals — both, so the footing test can compare them instead of trusting either.
- Taxable-wage columns as printed — never recomputed from gross pay.
- Pay period and check date, labelled — the period for accrual, the check date for the quarter.
- Department as printed, or its absence — never inferred.
- A citable origin for each value — page and region under the same coordinate contract any reviewable extraction owes, so an accountant can jump from an exception to the cell that caused it.
On the other side of that contract sit the mapping table, the tolerance for rounding and the three closing tests, all versioned and owned by finance. A failed posting then says which code, which column or which total failed, and under which version of the map.
Not income verification, not invoice matching
Two neighbouring problems use the same documents or the same vocabulary and should stay separate from this one.
Verifying a borrower’s income reads payroll from the other side: one person’s paystub, W-2 and deposits, reconciled against each other to establish what that person earns. The income verification article covers why those three documents rarely show the same number. None of the employer-side columns above appear there, and none of its per-person questions appear here. When payroll data feeds a credit analysis of the employer itself, it becomes one input among several in a financial spread.
Matching a supplier invoice to a purchase order and a goods receipt is also a reconciliation, but between three external documents. A payroll register reconciles against the company’s own books and its own tax return, and the three-way match article covers the other case.
Close to the ledger, not to the person
A payroll register is not a stack of paystubs with a total at the bottom. It is the employer’s statement of what a pay run cost, written so that it can be posted, and its correctness is judged by the ledger and the quarterly return rather than by any single employee’s pay.
So read it for what the posting needs: every code as printed, every total as printed, the taxable wages the payroll system already computed and the dates that decide the quarter. Keep the chart of accounts in a versioned map outside the extractor. Then test coverage before balance, expect the fractions of cents the return itself expects, and let a new earnings code stop the close with a question instead of passing it with a plausible number.