Two documents, one shift
A POS batch and a processor deposit describe the same shift 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 side explains the gap on the other.
Batch matching does that pairing automatically — reading both documents, matching batches to the deposits they produced, and flagging the ones that don't line up instead of leaving the question open.
Why this isn't a simple lookup
A batch and its deposit rarely share an obvious, single identifier that makes the match trivial. Amounts are close but not identical once fees are deducted. Dates are close but not identical once settlement timing 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, night after night, 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 batch: date, reference number, gross total, tip total, and any refunds or voids recorded against it. From the deposit statement: net amount, deposit date, processing fees, chargebacks, and — where the processor includes it — the batch reference the deposit corresponds to.
Not every field is present on every document — a smaller processor's statement might omit a batch reference number entirely, while a POS system's batch report might not break out tips as a separate line. The reading adapts to whatever fields a given document actually provides, rather than assuming a fixed template every source has to match.
How a batch gets matched to a deposit
The match starts with the processor reference number when the statement includes one — the strongest possible signal, since it's the processor's own link between the two documents. Where that's absent, matching falls back to amount and date proximity: a deposit that's close to the batch total, net of a plausible fee, arriving within the processor's usual settlement window.
Neither signal alone is treated as certain. A close amount on its own could be coincidence; a plausible date on its own could apply to several batches. 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: sequence. Batches tend to settle in roughly the order they closed, so a deposit that fits the amount and date window for two candidate batches is more likely to belong to whichever one closed first, all else being equal.
Confidence and what gets flagged
A match built on a reference 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 batch with no plausible matching deposit at all — not even a low-confidence one — is flagged as unmatched, which is usually the first sign worth investigating: either the batch never settled, or the deposit is 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 batch-and-deposit pairs across many restaurants, 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 weeks later.
How it works
Upload batch reports and deposit statements
From any POS system and any processor, for the period you're reconciling.
Each document is read
Amounts, dates, reference numbers and fee lines extracted from both sides.
Batches matched to deposits
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 batch, matched
A batch closes at $2,940.15 on a Tuesday. Two candidate deposits land later that week: one for $2,847.20, three days out, and one for $1,410.00, five days out. The reference number on the $2,847.20 deposit ties it directly to Tuesday's batch — a high-confidence match. The $1,410.00 deposit corresponds to a different batch entirely and is matched separately.
Without the reference number acting as a tiebreaker, the amount alone could plausibly point to either deposit depending on how fees were estimated — exactly the kind of ambiguity that a confidence score exists to surface rather than resolve silently.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| Batches matched by eyeballing amounts | Batches matched by reference number, amount and date together |
| A missed match discovered weeks later | An unmatched batch flagged the same week |
| Confidence isn't tracked at all | Every match carries a confidence level and its basis |
| Redone from scratch for a new POS vendor | Same method applies regardless of POS vendor |
From one batch to a full month
One batch a night is a quick lookup. Thirty batches a month across one location is a chore. Three hundred batches a month across a ten-location group 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 batch one and batch 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-batch curve is what makes the difference between a task someone squeezes in and a task that needs a full-time hire once a group 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 batch.
Who uses this
Restaurant controllers reconciling a portfolio of locations, bookkeepers closing out a client's month, and general managers who need to confirm a deposit landed before running payroll all rely on the same matched view — built once, read by whoever needs it.
Owners negotiating a new processor contract use the same matched history as evidence — a real, verified effective rate to compare against a competing quote, rather than a number pulled from an old fee schedule that may no longer reflect current volume.
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 batch that closes just before midnight sometimes gets dated to the following business day by the processor, even though the POS system logs it under the original date — a one-day offset that's easy to mistake for a missing match if the matching window is too narrow.
A deposit that arrives on a Monday after a weekend of closed batches often represents three days of settlements combined into one figure — matched against the sum of Friday, Saturday and Sunday's batches rather than any single one.
When one batch produces two deposits
Some processors split a large batch across two settlements — a portion deposited on the usual schedule and a remainder held and deposited a day or two later, often tied to a processor's own risk or volume thresholds.
Both deposits get matched back to the same originating batch, with the split itself recorded rather than treated as two unrelated deposits that happen to add up close to the batch total.
A split is more likely on an unusually large batch — a holiday weekend, a private event — which is precisely when a manual reconciliation is most likely to be rushed and most likely to mismatch the pieces.
Different POS systems, one method
A restaurant group that has grown by acquisition often inherits whatever POS system each location came with — Toast at one, Square at another, a legacy terminal at a third. Each produces a batch report with its own layout and its own terminology for the same underlying data.
Reading each report for its content rather than its format means the same matching logic applies across every location, without maintaining a separate parsing rule for every POS vendor in the portfolio. The processor side works the same way — see credit card processor statement to Excel for how a dense merchant statement gets read into the same structured rows before matching begins.
Why a flagged batch 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 batch was paired with a specific deposit during an audit or a dispute with a processor.
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.
Matching a backlog, not just the current week
A location that's never reconciled before, or one that's fallen months 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 month-old batches as on this week'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 location settles into the ordinary weekly 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-out
For a restaurant group with its own internal tooling, batch matching doesn't have to be a manual upload-and-review step — the same reading and matching is available through an API, so a nightly close-out process can pull batch reports and processor statements automatically and surface only the flagged items for a human to look at the next morning.
That removes the last manual step from the routine entirely for groups that already have a system pulling POS exports on a schedule — matching happens as part of that pipeline rather than as a separate task someone has to remember to run.
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. A reviewer looking at a match from three months ago doesn't need 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 processing fees independently
Reads the fee the processor actually charged; it doesn't recompute what a fee should have been.
Doesn't dispute a chargeback or file a claim
Surfaces the chargeback clearly. Disputing it stays with you or your processor.