Two documents, one pay run
Ask a controller why the bank statement doesn't match the payroll register, and the honest answer is that it was never supposed to, at least not line for line. The register reports gross wages and every deduction for the pay period as one summary. The bank shows what actually left the account — usually as several separate withdrawals, on several dates.
Net pay moves as one batch. Federal and state tax withholdings move as another, often to a different agency on a different day. Benefits deductions, garnishments and any third-party payments each have their own timing. A reconciliation built from whichever number happens to be handy — the register total, the largest bank debit, or a controller's memory of the pay run — is built on a foundation that shifts depending on which document someone grabbed.
None of this means the numbers are wrong. It means they answer different questions, and reconciling them means reading both sides and matching them deliberately instead of assuming one stands in for the other.
Why this isn't a simple lookup
A payroll register and a bank statement are produced by two different systems on two different schedules, using two different vocabularies for the same pay run. The payroll provider calls it a pay run; the bank shows a series of ACH debits with reference codes that mean nothing without the register open beside them.
Multiply that by twenty-six pay periods a year, or by several legal entities each running payroll through a different provider, and the lookup that took twenty minutes for one pay run becomes a recurring task nobody has time to protect every period.
What a payroll register actually is
A payroll register is the summary report a payroll provider or in-house system produces for each pay run, listing every employee's gross pay, every deduction — taxes, benefits, garnishments, retirement contributions — and the resulting net pay, for that period.
The register total is a summary figure: it's what the payroll system calculated should happen, not a record of what actually moved through the bank. The gap between the register and the bank statement is where remittance timing, provider fees and manual adjustments live.
What actually leaves the bank on payday
Net pay for all employees typically moves as a single ACH batch, sometimes as several batches if payroll splits by pay group or department. Federal and state tax withholdings are remitted separately, often through the payroll provider's own tax-payment service, on a different day than net pay itself. Benefits premiums, 401(k) contributions and any wage garnishments each have their own remittance schedule to their own third party.
| What it does | When it hits |
|---|---|
| Net pay ACH batch | Debited on or just before payday |
| Tax remittance | Debited separately, often a day before or after net pay |
| Benefits and 401(k) remittance | Debited on the provider's own schedule, sometimes monthly not per-period |
| Payroll provider fee | Debited separately, sometimes bundled with the net pay batch |
None of these four are errors. They're the ordinary mechanics of how payroll processing works — but only if each one is accounted for explicitly. Left unaccounted for, they look identical to a missing remittance or a register that doesn't tie to the bank at all.
The gross-to-net waterfall
Every payroll register follows the same logical shape: gross pay, minus pre-tax deductions, minus taxes, minus post-tax deductions, equals net pay. Reconciling to the bank means confirming that waterfall adds up internally on the register itself, before checking that the resulting net-pay figure matches what actually left the account.
An error anywhere in that waterfall — a benefits deduction applied twice, a tax rate that didn't update after a jurisdiction change — shows up as a register that's internally inconsistent even before the bank side enters the picture, which is why checking the waterfall first narrows down where a discrepancy actually lives.
Why the register date and the bank date rarely match
A payroll register is typically dated to the pay period it covers or the date it was processed, not the date money actually moves. Direct deposit takes one to two business days to clear after a payroll run is submitted, and tax remittances often lag net pay by a day or more depending on the provider's own remittance schedule.
Matching by date alone, without allowing for this lag, produces false mismatches — a net-pay debit that lands two days after the register date isn't a missing payment, it's the normal clearing window for that provider.
What gets read
From a payroll register: pay period dates, total gross pay, total net pay, tax withholding totals by jurisdiction, benefits and retirement deduction totals, and the employee count for the run. From a bank statement: each ACH debit amount, its posting date, and any reference or trace number the bank or provider includes.
A field that can't be read with confidence — a truncated reference number, an ambiguous total — is flagged rather than filled in with a best guess, so a review focuses on the handful of fields that genuinely need a second look.
How it works
Upload registers and statements
Payroll registers and bank statements for the period, from any provider or entity.
Each document is read
Gross pay, net pay, tax totals, deduction totals and bank transaction details.
Register lines matched to bank transactions
By amount, date proximity and reference number where available.
Gaps flagged, not guessed
A register line with no clear matching transaction, or vice versa, is marked for review.
Exported
Excel, CSV or JSON, with every matched line traceable to its source document.
A pay run, reconciled
A biweekly pay run closes its register at $186,420 in gross pay across 42 employees, with $142,850 in net pay after taxes and deductions. Over the following three days, four separate bank debits account for the full amount.
| Line | Amount |
|---|---|
| Net pay ACH batch | $142,850.00 |
| Federal and state tax remittance | -$38,910.00 |
| 401(k) and benefits remittance | -$4,210.00 |
| Payroll provider fee | -$450.00 |
Every debit ties back to the same register, even though they landed on three different dates and through two different remittance channels. The provider fee, easy to overlook as an unexplained small debit, is read and matched the same way as the larger lines instead of sitting unreconciled at the end of the month.
When there's more than one legal entity or provider
A company that grew through acquisition often ends up running payroll for different entities through different providers, each with its own register format and its own bank account. Reconciling all of them by hand means learning several report layouts and keeping them straight, entity by entity.
Documents are read for what they say, not for which provider produced them — an ADP register and a Gusto register are read the same way, matched to their own entity's bank account, without needing a separate process per provider.
Handling a discrepancy with method
A register line with no matching bank transaction after a reasonable window, or a bank debit that doesn't correspond to any known register, gets flagged rather than assumed to be an eventual match. The first step is confirming the payroll run was actually submitted and processed — a run that failed partway through never generates the expected debits at all.
The second step is checking for a split remittance, where one register produces two or more smaller bank transactions for the same category — a common pattern that looks like a shortfall until every related transaction is added together.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| A controller re-types register totals into a spreadsheet | Register totals read directly from the source document |
| Bank transactions matched by memory of pay run size | Bank transactions matched by amount, date and reference |
| Provider fees estimated or ignored | Fees read as the actual line item from the bank statement |
| A missed remittance surfaces at tax time, if at all | A missing match is flagged the same pay period |
From one pay run to a full year
A single entity on a biweekly schedule closes twenty-six pay runs a year — manageable by hand, if tedious. A company running four entities on different schedules closes well over a hundred. The reconciliation work doesn't scale linearly by hand; it scales by however many people can be pulled onto the task before it becomes someone's whole job.
Reading and matching each pay run the same way regardless of volume means the effort per run stays flat as the count grows — what changes is only how many need a human look, which a well-tuned confidence threshold keeps small.
Who uses this
Controllers and finance teams
One matched view of every pay run against the bank, without a manual reconciliation each period.
HR and payroll teams
A verified record of what was supposed to move and what actually moved, ready before an auditor asks.
Multi-entity companies
The same matching method applied across every legal entity and payroll provider in the group.
Bookkeepers serving multiple clients
Register and bank data exported in a format that drops straight into each client's ledger.
Edge cases worth knowing
A pay run that falls on or near a bank holiday sometimes settles a day early or a day late, shifting the entire batch of transactions relative to the register date — handled by widening the matching window around known holidays rather than expecting every run to land exactly on schedule.
An off-cycle correction run, issued to fix an underpayment from a prior period, shouldn't be matched against the current period's regular register — it gets its own line and its own match, tied back to the period it's actually correcting.
A payroll provider that bundles its fee into the net-pay debit, rather than billing it separately, produces a bank transaction that's slightly smaller than the register's net-pay total — worth checking before assuming that gap is an error rather than a bundled fee.
Why a flagged line beats a guessed one
A dashboard that shows only matched totals, without the reasoning behind each match, is easy to trust until an auditor asks why a specific register line was paired with a specific bank transaction. Reconstructing that reasoning later means going back to both source documents and starting over.
Keeping the confidence level and the matching basis attached to every pair — amount, date proximity, reference number — turns that reconstruction from a future scramble into a detail already sitting in the data, ready the moment an auditor asks.
Bringing a new provider or entity online
A newly acquired entity, or a company switching payroll providers, starts with no prior reconciliation history — nothing to compare a first pay run against. That first register and its bank transactions still get read and matched the same way as any other, since the matching relies on the documents themselves rather than an entity's history.
What's worth watching closely in those first few pay runs is whether the new provider's register format holds any surprises — a deduction category the rest of the group doesn't use, a remittance timing that differs from the group's usual pattern — the kind of detail that only becomes visible once real pay runs start flowing through.
None of that requires a separate setup step before the first reconciliation can run — the new entity's documents are read the same way from the very first upload.
What this doesn't do
Doesn't run payroll
It provides the verified reconciliation a controller or auditor needs — running the actual payroll stays with your provider.
Doesn't file payroll taxes
Register and bank totals are read and reconciled, not submitted to any tax authority.
Doesn't calculate gross-to-net
It checks that the waterfall on the register is internally consistent — the payroll calculation itself stays with your payroll system.
Doesn't replace an audit
It builds the traceable record an auditor needs faster — the audit judgment itself stays with your auditor.
What it does fits in one sentence: turn payroll registers and bank statements into matched, traceable rows, so the question “why doesn't this add up” has an answer before an auditor has to ask it twice.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For bookkeepers and finance teams handling payroll data for multiple entities, that matters — details are on the security page.