Two documents, one pay run
A payroll register and a bank statement describe the same pay run from two different vantage points, produced by two different systems on two different schedules. Matching them by hand means holding both open and tracking, line by line, which bank transaction explains which part of the register.
Payroll run matching does that pairing automatically — reading both documents, matching each register to the transactions it produced, and flagging the ones that don't line up instead of leaving the question open until an auditor asks it.
Why this isn't a simple lookup
A register and its bank transactions rarely share an obvious, single identifier that makes the match trivial. Amounts are close but not identical once a provider fee is netted out. Dates are close but not identical once ACH clearing time is factored in. The match has to be inferred from several imperfect signals at once, not read off a shared reference number that's always present.
Doing that inference by hand, pay period after pay period, is exactly the kind of repetitive judgment call that's easy to get right once and tedious to get right every single time.
What gets read from each side
From the register: pay period, gross pay total, net pay total, tax withholding totals, benefits deduction totals, and the employee count. From the bank statement: each debit amount, its posting date, and — where the bank or provider includes it — a reference or trace number the transaction corresponds to.
Not every field is present on every document — a smaller provider's register might not break tax withholdings out by jurisdiction, while a bank statement might truncate a reference number. The reading adapts to whatever fields a given document actually provides, rather than assuming a fixed template every source has to match.
How a register gets matched to bank transactions
The match starts with a reference or trace number when the bank statement includes one — the strongest possible signal, since it's the bank's own link between the transaction and the payroll run that produced it. Where that's absent, matching falls back to amount and date proximity: a debit that's close to a register's net-pay figure, arriving within the provider's usual clearing window.
Neither signal alone is treated as certain. A close amount on its own could be coincidence, especially across pay periods of similar size; a plausible date on its own could apply to more than one run. It's the combination — and how strong each signal is — that determines the confidence assigned to a match.
A third, weaker signal comes into play when the first two leave ambiguity: category. A tax remittance and a net-pay batch clear through different channels even when they post on the same day, so knowing which category a debit belongs to narrows down which register line it's actually explaining.
Confidence and what gets flagged
A match built on a trace number and a consistent amount is marked high-confidence and needs no further look. A match built only on a rough amount and a wide date window is marked lower-confidence and surfaced for review, rather than silently accepted as equally certain.
A register line with no plausible matching transaction at all — not even a low-confidence one — is flagged as unmatched, which is usually the first sign worth investigating: either the remittance never processed, or it's still in transit.
Where the confidence threshold sits
A threshold set too loosely accepts weak matches without review, which risks a wrong pairing slipping through unnoticed. A threshold set too tightly flags nearly everything for review, which defeats the purpose of automating the matching in the first place.
The threshold used here is tuned from real register-and-transaction pairs across many companies, favoring flagging a genuinely ambiguous match over silently accepting one — a false flag costs a few seconds of review; a false match costs a much harder-to-trace error at audit time.
How it works
Upload registers and bank statements
From any payroll provider and any bank, for the period you're reconciling.
Each document is read
Amounts, dates, reference numbers and deduction lines extracted from both sides.
Registers matched to bank transactions
By reference number where available, otherwise by amount and date proximity.
Confidence assigned per match
Strong matches need no review; weak or missing matches are flagged.
Exported
Excel, CSV or JSON, with every matched pair traceable to its source documents.
A pay run, matched
A register closes at $58,410 in net pay on a Thursday. Two candidate debits land the following week: one for $58,410.00, one business day out, and one for $19,850.00, two business days out. The trace number on the $58,410.00 debit ties it directly to Thursday's register — a high-confidence match. The $19,850.00 debit corresponds to the same run's tax remittance and is matched separately, as its own category.
Without the trace number acting as a tiebreaker, the amount alone would still point clearly to the net-pay match here — but in a busier period with several similarly sized runs, that same ambiguity is exactly what a confidence score exists to surface rather than resolve silently.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Registers matched by eyeballing amounts | Registers matched by reference number, amount and date together |
| A missed remittance discovered at tax time | An unmatched register line flagged the same pay period |
| Confidence isn't tracked at all | Every match carries a confidence level and its basis |
| Redone from scratch for a new payroll provider | Same method applies regardless of provider |
From one pay run to a full year
One pay run a period is a quick lookup. Twenty-six pay runs a year across one entity is a chore. Several hundred across a multi-entity company on different pay schedules is a job someone has to be assigned to full-time if it's done by hand.
The matching logic doesn't change with volume — the same reference-number-first, amount-and-date-fallback approach applies to run one and run three hundred. What changes is how much of that volume needs a human look, which stays small as long as the confidence threshold is doing its job.
That flat effort-per-run curve is what makes the difference between a task someone squeezes in and a task that needs a dedicated hire once a company crosses a certain size — the volume grows, but the human attention it requires doesn't grow at the same rate. That gap between volume growth and attention growth is where the real time savings live, not in any single pay run.
Who uses this
Controllers reconciling a portfolio of entities, bookkeepers closing out a client's month, and HR teams who need to confirm a remittance landed before closing out a benefits period all rely on the same matched view — built once, read by whoever needs it.
Finance leaders preparing for an audit use the same matched history as evidence — a real, verified record of what moved and when, rather than a spreadsheet reconstructed under time pressure once the audit request arrives.
Each of these roles reads the same underlying matched data differently, for a different purpose — which is exactly why keeping it structured and traceable matters more than any single use case on its own, since none of these roles can predict which detail a future question will actually need.
Edge cases worth knowing
A pay run submitted just before a bank holiday sometimes clears a day early or a day late, even though the register logs it under the original pay date — a one-day offset that's easy to mistake for a missing match if the matching window is too narrow.
A benefits remittance that batches several pay periods into one monthly transaction, rather than clearing per period, gets matched against the sum of the relevant periods' deduction totals rather than any single register on its own.
When one register produces several transactions
Most payroll providers split a single register into several separate bank transactions — net pay, tax remittance, benefits and provider fee each clearing on their own schedule, sometimes days apart from each other.
All of those transactions get matched back to the same originating register, with the split itself recorded rather than treated as several unrelated debits that happen to add up close to the register total.
A split is more visible on a larger pay run — end-of-quarter bonuses, a new hire cohort starting together — which is precisely when a manual reconciliation is most likely to be rushed and most likely to mismatch the pieces.
Different payroll providers, one method
A company that has grown by acquisition often inherits whatever payroll provider each entity came with — ADP at one, Gusto at another, an in-house system at a third. Each produces a register with its own layout and its own terminology for the same underlying data.
Reading each register for its content rather than its format means the same matching logic applies across every entity, without maintaining a separate parsing rule for every provider in the portfolio. The bank side works the same way — see timesheet to payroll reconciliation for how hours data gets read into the same structured rows before matching begins.
Why a flagged run beats a guessed one
A match that's silently accepted without a confidence level looks identical whether it's certain or a coin flip. That distinction matters the moment someone has to explain, months later, why a specific register line was paired with a specific bank transaction during an audit.
Carrying the confidence level and its basis with every match from the start means that explanation already exists, rather than needing to be reconstructed under time pressure while an auditor waits.
Matching a backlog, not just the current period
An entity that's never reconciled payroll to the bank before, or one that's fallen a year behind, doesn't need a different tool — it needs the same matching logic applied across a much larger batch of documents at once, with the same reference-number-first, amount-and-date-fallback approach working just as well on year-old registers as on this period's.
The volume of unmatched items is naturally higher on a first pass through a backlog, simply because nothing has been checked yet — not because the matching itself is any less reliable on older documents than on current ones.
Once the backlog is cleared, the same entity settles into the ordinary per-period volume, with no lingering effect from having started months behind — the matching logic doesn't treat catch-up work any differently from steady-state reconciliation.
Feeding this into an automated close
For a company with its own internal tooling, payroll run matching doesn't have to be a manual upload-and-review step — the same reading and matching is available through an API, so a monthly close process can pull registers and bank statements automatically and surface only the flagged items for a human to look at.
That removes the last manual step from the routine entirely for companies that already have a system pulling payroll and bank data on a schedule — matching happens as part of that pipeline rather than as a separate task someone has to remember to run each period.
The API returns the same match record structure a manual review would see — amount, date, matching basis, confidence — so an automated pipeline and a human reviewer are always looking at the same underlying data, never two different versions of the truth.
What a match record actually contains
Beyond the matched amount and date, each record keeps the specific basis for the match — which reference number, or which combination of amount and date window, produced the pairing — along with the confidence level assigned to it.
That level of detail is what makes a match record useful months later, not just at the moment it's created. An auditor looking at a match from two quarters ago doesn't need anyone to re-derive why it was made — the reasoning is already attached to the record itself.
A manually re-matched record, corrected after a review flagged it, keeps the original automatic guess alongside the human correction — so a later audit can see both what the system proposed and what a person actually confirmed, rather than only the final, edited answer.
What it doesn't do
Doesn't decide a mismatch alone
Flags the most likely matches and surfaces ambiguous ones — final confirmation comes from a human check against the actual documents.
Doesn't calculate payroll taxes independently
Reads the tax amount the register actually reports; it doesn't recompute what a withholding should have been.
Doesn't correct a payroll error or file an amendment
Surfaces a discrepancy clearly. Correcting it stays with you, your payroll provider or your accountant.