Three tills, one bank account, one number on the statement. That's the setup in most multi-site cafes, salons, market traders and small retail chains — and it's also where a specific, entirely avoidable admin cost hides, because nobody has ever sat down and named it as a task.
The pattern is always the same. Each site runs its own card reader — Zettle, SumUp, Square, Dojo, whichever the site manager picked up first — and each one produces its own end-of-day summary. The bank, meanwhile, doesn't see three sites. It sees one batched settlement, sometimes two days later, sometimes with two sites' takings merged into a single credit because the acquirer happened to process them together. Someone has to turn those into the same number, and right now that someone is doing it by hand, most likely on a Monday morning, most likely the person who can least afford to lose the time.
What actually lands on the bank statement
A card payment taken on a Tuesday afternoon doesn't appear in the bank on Tuesday. Card acquirers settle on a lag — commonly next working day, sometimes two days over a weekend — and they settle net of their own fees, which are taken off before the money ever reaches the account. So the bank line for "Wednesday's takings" is actually Tuesday's card sales, minus a fee percentage that varies by card type, minus any refunds processed that day, and it may well be one lump sum covering more than one site if they share a merchant account or the acquirer batches by settlement window rather than by location.
None of that is wrong or unusual. It's simply how UK card acquiring works. The problem is that nobody designed a way to see it — the till says one thing, the bank says a different thing on a different day for a different reason, and reconciling the two requires holding three or four facts in your head at once: which day's trading this settlement actually represents, which sites it covers, what the fee should have been, and whether a refund or a chargeback has quietly eaten into it.
The manual version, step by step
This is what actually happens most weeks in a business with three tills and no automation, because it's worth being specific rather than gesturing at "reconciliation".
- Pull three Z-reports. One per site, either printed or exported from each till's own app, each with its own login and its own export format.
- Add them up by hand or in a spreadsheet, adjusting for the settlement lag so the totals line up with the right bank date.
- Estimate the fee that should have been deducted, because the acquirer's fee statement usually arrives separately, often monthly, and rarely in time to check a specific day against it.
- Compare the adjusted total to the bank line and go looking for whatever accounts for the gap: a refund, a disputed transaction, a card type with a higher fee than assumed, or one site's numbers accidentally left out.
- Chase or write off whatever's left unexplained, because after twenty minutes most businesses stop looking and either accept the variance or flag it for the accountant to find at month-end, by which point nobody remembers what happened that Tuesday.
None of those five steps needs judgement. All five need attention, and all five are exactly the kind of task that a tired manager does last, at the end of a long week, which is precisely when mistakes get missed rather than caught.
A three-site coffee shop group, illustrative figures: 25 minutes a day, six days a week, to pull and reconcile three tills against the bank feed. That's 2.5 hours a week, 130 hours a year, at a loaded cost of £28 an hour for whoever does it — £3,640 a year in time alone.
On top of that, unexplained variances that get written off rather than chased: say £35 a week across three sites, mostly small card-fee misestimates and the odd missed refund — another £1,820 a year, and that's before counting the one or two proper disputes a year that go unclaimed because nobody had the patience to trace them back to a specific transaction.
Call it roughly £5,400 a year for a task that has never once appeared on an invoice, because it isn't a purchase — it's just Monday morning.
Why this reconciliation is harder than ordinary bookkeeping
Most reconciliation is one-to-one: a bank line matches an invoice, or it doesn't. Multi-till reconciliation is many-to-one, sometimes many-to-many, and the "one" moves — a settlement can cover one site or three depending on how the acquirer happened to batch it that week, which nobody controls and which can change without warning if the business switches provider or adds a site.
It's also fee-sensitive in a way plain reconciliation isn't. Debit cards, credit cards, contactless under the small-transaction threshold and foreign cards are commonly charged at different rates by the same acquirer, so two days with identical takings can settle at meaningfully different net amounts — and a manager estimating "the usual percentage" will be wrong on any day with an unusual mix of card types, which is most days.
And it's the kind of gap that compounds silently. A variance that's individually too small to chase — £8 here, £12 there — is exactly the sort of thing our piece on why most integrations break describes: nothing fails loudly, so nobody notices that the small stuff has been adding up for a year.
Where automation genuinely helps, and where it doesn't
The part worth automating is entirely mechanical: pulling each till's daily totals via its API rather than a manual export, applying the acquirer's actual published fee schedule rather than an estimated percentage, matching the adjusted totals to the correct bank line even when settlement is delayed or batched across sites, and flagging only the genuine gap — the bit that isn't explained by fees, timing or a known refund.
That last part is the whole point. A manager doesn't need to see three Z-reports and a bank statement every morning. They need to see one line: "all three sites reconciled cleanly" or "Site 2, Tuesday, £34 unexplained — here's what it isn't." That's a five-second read instead of a twenty-five-minute chase, and it's the same shift our piece on the real cost of doing it manually for now describes for any recurring task: automate the assembly, keep a person on the exceptions.
What doesn't get automated, and shouldn't, is the judgement call on a genuine dispute — whether to fight a chargeback, whether a refund was handled correctly, whether a customer's complaint about a duplicate charge is real. Those need a person who can see the transaction in context. The automation's job is to make sure that's the only thing left for them to do.
A reasonable first step
Before building anything, spend one week doing the manual version properly and writing down, for each site, which fields you pull from the till and which line you match them to in the bank feed. Most businesses discover at this point that one till's export doesn't include a fee breakdown at all, or that the acquirer's settlement report groups sites differently from how the tills report them — and that's worth knowing before anyone starts connecting systems, not after.
Then check whether each till and the bank feed itself can be read programmatically rather than exported by hand. Zettle, SumUp and Square all have APIs; most UK business bank accounts now support Open Banking feeds. If both sides are readable, the reconciliation itself is a modest, well-understood build — the kind of thing that takes days rather than months, because nobody has to invent the logic, just automate the checklist above.
If one till genuinely can't be read — an older standalone terminal with no export at all — that's a reason to reconsider that one piece of kit at its next renewal, not a reason to abandon the rest. Two sites reconciling themselves and one still done by hand is still most of the saving, for a fraction of the ongoing admin.
Common questions
We only have two tills, not three — does this still apply?
Yes, the number of tills isn't really the trigger, the number of settlement lines you have to hold in your head at once is. Two sites on different card readers settling into one account has exactly the same shape as three: a batched bank line, a settlement lag, and a fee that has to be estimated rather than read. The arithmetic in this article scales down roughly in proportion, but the manual process — pull, adjust, compare, chase — doesn't get any quicker just because there's one fewer report to pull.
Our accountant reconciles the bank account already — isn't this their job?
They reconcile what lands in the accounting software against the bank statement, which is a different and later check, usually done monthly, from the bank line back to a batch of invoices or a sales day-book entry. What they're not doing, and don't have the till-level data to do, is checking that Tuesday's three Z-reports genuinely add up to Wednesday's bank credit once the right fee is deducted. That daily, till-level match is the one that catches a missed refund or a wrong fee assumption while it's still a five-minute fix rather than a mystery in next month's accounts.
How do we know if our card machine provider's API is any good?
Ask two questions before anything else: can it return each day's transactions with the fee already itemised per transaction, and can it be queried for a specific date range rather than only "today". Zettle, SumUp and Square all pass both tests for most account types, though some older or resold terminal contracts run on white-label systems with far thinner APIs. The honest way to find out is to ask the provider directly for their API documentation before assuming anything — a surprising number of small-business owners have never asked, because it never occurred to them that it was a reasonable question.
Is it worth doing this if the variance we write off is genuinely small?
Run the arithmetic from the callout above with your own numbers before deciding. If the honest total — time spent plus what actually gets written off — comes to a few hundred pounds a year, leave it; a bespoke reconciliation feed isn't worth building for that small a saving. It's usually the time cost that changes the answer, not the variance, because the twenty-five minutes a day rarely shows up as a number anyone has written down until they're specifically asked to put one on it, and once it does, the case tends to make itself.