Two numbers that were never going to match
A site closes at ten and produces a figure: this is what we sold today. Some days later a different figure appears on the bank statement: this is what arrived. Between those two numbers sits a set of entirely legitimate reasons why they differ, and one possible reason why they should not.
With one location, the difference is small enough to eyeball and someone usually does. With eleven locations, there are eleven differences every day, they are all slightly different, and nobody eyeballs anything. What happens instead is that the figures get added up at head office, the total looks about right, and the arithmetic stops there.
That is the failure this page is about. A group total can be correct while four sites underneath it are wrong in ways that cancel out. The total gives no warning, because a total has no idea it is hiding anything.
The fix is not more control over the sites. It is reconciling at the level where the difference actually exists — one site, one day — and accepting that most differences will turn out to be timing rather than trouble.
What this is not
Not group consolidation
This is many trading locations inside one business. Separate legal entities with their own books are a different exercise — that lives on multi-entity bank reconciliation.
Not a till integration
There is nothing to connect. FlowParse reads the reports your sites already produce, which is the only approach that works when six of your eleven sites run different equipment.
Not cost allocation
Splitting shared overhead across locations is a separate question with its own page. Here we only care what each site sold and what arrived.
Not an accusation
The overwhelming majority of differences are settlement timing and banking routine. A process that treats every gap as suspicion burns out in a fortnight and finds nothing.
Why the gap is normal, and why that is the problem
If tills and banks matched daily, nobody would need this. The reason they do not is structural, and understanding it is what separates a useful reconciliation from a witch hunt.
Card takings do not arrive the same day. Cash arrives when somebody physically goes to the bank, which in practice means Tuesdays and Fridays, or whenever the manager has a spare twenty minutes. Delivery platforms pay on their own fortnightly cycle, net of a commission the site never sees. Refunds land whenever the customer's bank decides.
So on any given day, for any given site, the two figures are different — legitimately, predictably, boringly different. And because everybody knows that, everybody stops looking.
That is precisely the cover a real problem needs. A site that is genuinely short by two hundred a week does not stand out against a background of daily differences; it looks like more of the same. It only becomes visible when the legitimate differences are modelled and removed, leaving the residue.
Which is the whole trick: not finding differences, but explaining away the ones that are supposed to be there.
Read a week of site reports now
Upload daily summaries, Z-reports, banking slips or settlement statements and see them come back as rows. Free tier, no registration.
Upload a document
Drop your documents here
or browse to upload
Free: 10 pages / month · Upgrade for more
Files encrypted in transit · auto-deleted after processing · GDPR compliant
The columns this needs
| Column | Comes from | Without it |
|---|---|---|
| Site | You | Everything collapses to a group total |
| Trading date | The site's report | No day-level comparison at all |
| Banking date | The paying-in slip | A slow routine looks like missing money |
| Gross takings | The site's report | Nothing to reconcile from |
| Split by tender | The site's report | Card lag and cash lag get mixed together |
| Platform gross and net | The settlement statement | The commission shows as a permanent shortfall |
| Refunds | The site's report | Refund days look like short days |
| Source file and page | The read | No way to answer a query six months later |
The two date columns are the ones most often merged, and merging them is the single most expensive shortcut on this list. With both, a site that banks late looks like a site that banks late. With one, it looks like a site that is short — and gets treated accordingly, which is both unfair and useless.
The tender split matters for the same reason. Card and cash arrive on completely different rhythms; added together, neither rhythm is visible and the combined difference looks like noise.
The four honest lags
Model these and most of your differences disappear. What is left is worth looking at.
Card settlement
Typically a day or two behind the trading date, and often bundled across a weekend into one Monday credit. Predictable per acquirer, so once you know the pattern for a site it holds.
Cash banking
The least predictable, because it depends on a human going somewhere. A site that banks twice weekly will show three days of apparent shortfall and one day of apparent surplus, every week, forever.
Platform settlement
Its own cycle, and net of commission. The gross the site reports and the net that arrives differ by a percentage that is entirely correct and looks exactly like leakage.
Refunds and chargebacks
Land whenever they land, sometimes weeks later, and reduce a day that had nothing to do with the original sale.
The second is the one that generates the most wasted argument. A manager who banks on Tuesday and Friday is not doing anything wrong, but their site will show a sawtooth pattern that looks alarming to anyone comparing single days.
The practical answer is to reconcile a site over a rolling week rather than a day, and to keep the daily rows underneath. The week smooths the banking routine; the days stay available for when something real turns up.
The site that reports differently
Every multi-site operator has at least one. It is usually the oldest site, or the newest, or the one that was acquired rather than opened — and its daily report has a different layout, different labels and sometimes a different definition of what counts as a sale.
The typical response is to ask that site to change. This almost never works, for a reason worth naming: the report comes out of equipment somebody bought in 2019, the manager did not choose the format, and changing it is a capital decision dressed up as an admin request.
What works instead is to stop requiring uniform input. If eleven different layouts can all be read into the same eight columns, the difference stops being a problem to solve and becomes a fact to accommodate.
This is the actual reason document reading beats an integration here. An integration needs every site on the same system; reading needs every site to produce a document, which they already do because they have to.
There is one thing worth checking rather than accommodating, though — whether the odd site means the same thing by the same word. If its “total” is net of refunds and everyone else's is gross, no amount of clean reading will make the numbers comparable. That question belongs to location rollup.
Cash sites and banking days
Where a meaningful share of takings is cash, the reconciliation changes shape. Card money moves itself; cash sits in a safe until someone carries it somewhere.
That introduces a third quantity between the till and the bank: cash on hand at the site. Ignore it and every unbanked day looks like a shortfall. Track it and the picture becomes simple — takings go in, banking takes out, and the balance should never be negative or wildly larger than the site's float.
Two checks earn their keep here. A running cash position per site that never goes below zero, and a ceiling — if a site is holding four days of takings, that is a security question before it is an accounting one.
Both are simple to compute once takings and banking are separate columns, and impossible if they were merged. Which is the third time on this page that the same shortcut causes the same trouble.
Delivery platforms, and the commission that looks like theft
A site takes an order through a platform. The customer pays the platform. Two weeks later the platform pays the operator, minus a commission that can be a substantial share of the order value.
On the site's report, that order shows at its full value — the food went out of the door at that price. On the bank statement, a materially smaller number arrives, and on a different day, bundled with dozens of other orders.
A reconciliation that does not model this shows a permanent, growing shortfall on exactly the sites doing the most delivery business. Which is the worst possible signal, because it points at the busiest locations.
The fix is to keep gross and net as separate fields from the settlement statement, and to reconcile the platform leg on its own: platform gross against platform net plus commission. That is a self-contained check, and it also happens to be the only way to notice when a commission rate quietly changes.
One site, one week, worked through
Invented numbers, ordinary shape. A single site, Monday to Sunday, banking on Tuesday and Friday.
| Day | Reported | Banked | Looks like |
|---|---|---|---|
| Mon | 2,140 | 0 | A disaster |
| Tue | 1,980 | 3,900 | A miracle |
| Wed | 2,050 | 0 | A disaster |
| Thu | 2,310 | 0 | A disaster |
| Fri | 3,640 | 6,410 | A miracle |
| Sat | 3,890 | 0 | A disaster |
| Sun | 1,720 | 0 | A disaster |
Day by day this site is alternately catastrophic and impossible. Nothing is wrong with it — it banks twice a week, and the cash from several days arrives in one deposit.
Over the week, reported takings are 17,730 and banked cash is 10,310. That gap is not a shortfall either: most of the difference is card, which settles separately and never touches a paying-in slip.
Only once card is modelled separately does a real question appear. Cash reported over the week was, say, 10,480 against 10,310 banked — a difference of 170 that is small, persistent and worth a conversation, and which was completely invisible at every other level of aggregation.
That is the argument for the whole exercise in one table. Daily comparison produces nonsense, weekly totals produce noise, and only weekly comparison split by tender produces the number that means something.
The site that has just joined
A newly opened or newly acquired site is the one most likely to produce apparent problems, and almost all of them are administrative rather than financial.
Its banking reference may not be set up yet, so deposits land in a general pool and cannot be attributed. Its acquirer may be different, so card settlement arrives on a different lag from every other site. Its manager may not know which report to send, so the first three weeks come in a format nobody expected.
Every one of those looks like a reconciliation failure and none of them is. The practical answer is to treat a site's first two months as onboarding rather than as trading — reconcile it, but investigate its differences separately and do not let them sit on the same exception list as the mature estate.
It is also the best possible moment to fix the things that are painful later: a distinct paying-in reference, a known report format, and a written note of what that site means by its sales figure. Nobody minds being asked in week one; asking in year three reads as suspicion.
Daily, weekly or monthly
| Cadence | Finds | Costs |
|---|---|---|
| Daily | Almost nothing real — mostly lag | A lot of attention for a lot of noise |
| Weekly | Banking-routine problems, a short site, a rate change | About an hour across all sites |
| Monthly | Only the large and the persistent | Cheap, and four weeks late |
Weekly is the sweet spot for most operators, and the reason is not effort — it is memory. A question asked seven days later gets an answer. The same question asked five weeks later gets a shrug, and a shrug is indistinguishable from a problem.
Daily has a specific and narrow use: a site already under suspicion. As a standing routine it produces so much lag-driven noise that people stop reading it, which leaves you worse off than monthly.
Working the unmatched list
The output of a run is not a verdict, it is a short list. What makes the list useful is the order you work it in.
Largest first, always
A hundred small differences are usually one rounding convention. One large difference is one event, and it is the one with an explanation attached.
Then persistent, not large
A site that is forty short every single Monday is a process, not an accident. Small and regular beats large and one-off as a signal.
Then whole-day absences
A day with a banking figure and no site report, or the reverse. Almost always a missing document rather than missing money.
Ignore anything inside the rounding band
Set a threshold and hold to it. Without one, somebody spends an afternoon on £1.40 and the list stops being worked at all.
The second entry is the one people get wrong. Instinct says chase the big number; experience says the big number usually has a boring answer within a minute, while the small persistent one has been running for eight months and nobody noticed.
Six traps
Reconciling the group total instead of each site. Errors cancel, the total looks fine, and nothing is learned.
Merging the trading date and the banking date. A slow banking routine then looks exactly like missing cash.
Reconciling platform gross against the bank. The commission shows as a shortfall on your busiest sites.
Comparing single days on a cash-heavy site. The banking rhythm produces a sawtooth that means nothing.
Asking the odd site to change its report format. It is equipment, not stubbornness, and the request will not be met.
Treating every difference as suspicion. The process gets resented, then quietly dropped, and the real problem stays.
Who actually does this
The site manager produces the report and banks the takings. That is the whole of their part, and it should stay that way — anything more competes with running the site and loses.
One person at head office runs the read and works the unmatched list. For eleven sites this is a morning a week, most of it spent on four or five rows.
The operations lead gets the persistent items, because a site that is short every Monday is an operational question rather than an accounting one.
Nobody, if it is a monthly PDF that goes to everyone. A reconciliation with no named owner becomes a report that is produced and not read, which is the most common ending for this exercise.
Where to start
Take one week, every site, and read all of it — daily reports, banking slips, settlement statements. Do not fix anything yet. Just get the rows into one table with the site and both dates on each.
Then model the lags: shift card takings by the settlement delay, group cash by banking date, treat platforms separately. What is left after that is your actual exception list, and for most operators it is between two and six rows.
Two to six rows is a conversation. Eleven sites times seven days of raw differences is a spreadsheet nobody opens twice — and the difference between those two outcomes is entirely in the modelling, not in the effort.
Making the sites comparable in the first place is the other half of this, and it is on location rollup. The full weekly routine is in how to compare performance across locations.