Two numbers that were never going to match
Ask a shift manager why the deposit doesn't match the POS close-out report, and the honest answer is that it was never supposed to. The POS reports gross card sales for the shift. The deposit reflects what the processor actually paid out, days later, after its own cut and any refunds or disputes that landed in between.
Add tips into the picture and a second, separate mismatch appears: credit-card tips ride inside the same batch as the sale, but cash tips never touch either number. A tip pool built from whichever total happens to be handy — the POS report, the deposit, or a manager's memory of the shift — 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 batch report and a processor statement are produced by two different systems on two different schedules, using two different vocabularies for the same shift. The POS calls it a batch; the processor calls it a settlement. Matching them by eye means holding both open at once and tracking which lines on one side explain the gap on the other.
Multiply that by seven nights a week, or by a dozen locations each running their own POS terminal, and the lookup that took ten minutes for one shift becomes an afternoon that nobody has time to protect every week.
What a POS batch actually is
A POS batch is the group of card transactions a point-of-sale system closes out and submits to its processor at the end of a shift or a business day — every sale, tip and refund entered during that window, bundled into one settlement request.
The batch total is a gross figure: it's what customers were charged, not what the restaurant will actually receive. The gap between that gross figure and the net deposit is where processing fees, refunds and chargebacks live.
What sits between the batch and the deposit
Processing fees — sometimes called the discount rate — are deducted before the deposit lands, typically a percentage of the batch plus a small per-transaction fee. Refunds issued after the original sale reduce a later deposit rather than the batch that contained the sale. Chargebacks, when a customer disputes a charge with their card issuer, can be deducted weeks after the original transaction.
| What it does | When it hits |
|---|---|
| Processing fee / discount rate | Deducted from the deposit for that batch |
| Refund | Deducted from a later deposit, not the original batch |
| Chargeback | Deducted weeks after the original sale, sometimes with a fee |
| Split settlement | One batch pays out across two or more deposits |
None of these four are errors. They're the ordinary mechanics of how card processing works — but only if each one is accounted for explicitly. Left unaccounted for, they look identical to a missing deposit or a batch that vanished.
How tip pooling actually works
Tip pooling aggregates tips collected across a shift — sometimes across an entire location — and redistributes them by a formula the house sets: hours worked, a points system that weights front-of-house roles differently, or a flat split among everyone on the floor.
The formula only produces a fair result if the total being distributed is accurate to begin with. A tip pool built from an undercounted or overcounted total doesn't just misallocate one shift's tips — it sets a pattern that compounds every time the same undercounted source gets used again.
Card tips and cash tips travel different paths
A credit-card tip is entered at the point of sale, rides inside the batch alongside the sale amount, and arrives in the deposit net of the same processing fee that applies to the sale itself. A cash tip is handed over at the table and never touches the POS batch or the bank account at all.
Reconciling “total tips for the night” means adding a number that came through the batch to a number that came through a separate cash log — two sources with entirely different levels of verifiability, combined into one figure that a tip pool then relies on.
What gets read
From a POS batch report: batch date and reference number, gross sale total, credit-card tip total, and any refunds or voids recorded against that batch. From a processor statement: net deposit amount, deposit date, processing fees, chargebacks, and the batch reference each deposit ties back to.
A field that can't be read with confidence — a smudged total, an ambiguous reference number — 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 batch reports and statements
POS batch reports and processor statements for the period, from any location.
Each document is read
Batch totals, tip amounts, deposit figures, fees and reference numbers.
Batches matched to deposits
By amount, date proximity and reference number where available.
Gaps flagged, not guessed
A batch with no clear matching deposit, or vice versa, is marked for review.
Exported
Excel, CSV or JSON, with every batch and deposit traceable to its source document.
A night, settled
A Friday dinner shift closes its POS batch at $4,218.60 in card sales, including $612.40 in credit-card tips. Three days later, the processor deposits $4,061.40.
| Line | Amount |
|---|---|
| Batch gross total | $4,218.60 |
| Processing fee (2.9% + $0.10 × 118 transactions) | -$134.10 |
| Refund (prior night, settled this deposit) | -$23.10 |
| Net deposit | $4,061.40 |
Every dollar of the $157.20 gap is accounted for — a processing fee and a refund from a different night that happened to settle in this deposit. The $612.40 in card tips is tracked separately from the sale total throughout, so the tip pool for the shift is built from a verified figure rather than a number pulled from whichever report was open.
When there's more than one POS system
A restaurant group that grew by acquisition often ends up running two or three different POS vendors across its locations, each with its own batch report format and its own processor relationship. Reconciling all of them by hand means learning three different report layouts and keeping them straight.
Documents are read for what they say, not for which system produced them — a Toast batch report and a Clover batch report are read the same way, matched to their own location's deposits, without needing a separate process per POS vendor.
Handling a discrepancy with method
A batch with no matching deposit after a reasonable window, or a deposit that doesn't correspond to any known batch, gets flagged rather than assumed to be an eventual match. The first step is confirming the batch was actually submitted — a batch that failed to close properly never generates a deposit at all.
The second step is checking for a split settlement, where one batch pays out across two smaller deposits — a common pattern that looks like a shortfall until both deposits are added together.
Manual vs. automatic
| Manual | Automatic |
|---|---|
| A manager re-types batch totals into a spreadsheet | Batch totals read directly from the source document |
| Deposits matched by memory of which nights were busy | Deposits matched by amount, date and reference number |
| Fees estimated as a flat percentage | Fees read as the actual line item from the statement |
| A missed deposit surfaces weeks later, if at all | A missing match is flagged the same week |
From one night to a full month
A single location closes seven batches a week — manageable by hand, if tedious. A restaurant group running twelve locations closes eighty-four. The reconciliation work doesn't scale linearly by hand; it scales by however many people can be pulled onto the task before it becomes the whole job.
Reading and matching each batch the same way regardless of volume means the effort per batch 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
Restaurant controllers
One matched view of batches and deposits across every location, without a manual reconciliation each week.
General managers
A tip pool built from a verified card-tip total, not a printed report someone grabbed off the counter.
Restaurant groups and franchises
The same matching method applied across every POS system in the portfolio.
Bookkeepers serving restaurant clients
Batch and deposit data exported in a format that drops straight into the ledger.
Edge cases worth knowing
A holiday or weekend batch sometimes settles together with the following business day's batch when a bank is closed, producing one deposit that covers two nights instead of one — handled by matching against the combined total rather than expecting a one-to-one split.
A voided transaction that never actually settled shouldn't appear in either the batch total or the deposit — if it shows up in a printed batch report anyway, it's excluded from the matched total rather than treated as a phantom discrepancy.
A batch that closes right at midnight sometimes gets dated to the following day by the processor even though the POS system logs it under the original date — worth checking before assuming a one-day gap is a missing match.
Why a flagged batch beats a guessed one
A dashboard that shows only matched totals, without the reasoning behind each match, is easy to trust until someone asks why a specific batch was paired with a specific deposit. 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 someone asks.
Bringing a new location or POS system online
A newly acquired location, or a location switching to a new POS system, starts with no prior reconciliation history — nothing to compare a first batch against. That first batch and its deposit still get read and matched the same way as any other, since the matching relies on the documents themselves rather than a location's history.
What's worth watching closely in those first few weeks is whether the new location's batch report format holds any surprises — a fee structure the rest of the group doesn't use, a settlement timing that differs from the group's usual pattern — the kind of detail that only becomes visible once real batches start flowing through.
None of that requires a separate setup step before the first reconciliation can run — the new location's documents are read the same way from the very first upload.
What this doesn't do
Doesn't process payroll or tip payouts
It provides the verified totals a tip pool or payroll run should use — the actual payout stays with your payroll system.
Doesn't file sales tax
Batch and deposit totals are read and reconciled, not submitted to any tax authority.
Doesn't dispute chargebacks
Chargebacks are read and flagged from the processor statement; disputing one is a step you or your processor handles.
Doesn't set your tip-pool formula
It verifies the total being distributed — how that total is split among staff stays a house policy decision.
What it does fits in one sentence: turn POS batch reports and processor statements into matched, traceable rows, so the question “why doesn't this add up” has an answer before anyone 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 back-office teams handling statements for multiple restaurant clients, that matters — details are on the security page.