How a food hall takes one payment across five kitchens

A food hall sells like one shop and settles like several businesses. The guest wants a taco from one counter, a pint from another and a doughnut from a third, and they want to pay once. Every kitchen in that transaction is a separate company with its own bank account, its own VAT position and — usually — its own opinion about whether the number they were paid is right.

That gap between how it feels to buy and how it has to settle is the whole technical problem of a food hall. It is worth being precise about it, because most of the ways people solve it create a mess that only shows up at month end.

The three ways people do it, and what each one costs

One till, one merchant account, split later on a spreadsheet

The hall takes all the money and pays the vendors out. Simple on day one. By week three somebody is reconciling card settlements against a spreadsheet by hand, a refund has come out of the wrong kitchen, and a vendor is asking why their number does not match their own count. The hall has also, quietly, become a payment business — it is holding other companies' money.

A till per vendor

Clean settlement, because each business takes its own money. But the guest now queues three times and pays three times, which is the experience a food hall exists to avoid. It also makes hall-wide things — a meal deal across two counters, a stamp card, a single wait time on a screen — impossible rather than merely difficult.

One basket, several orders

The guest sees one basket and one payment. Underneath, the system writes one ordinary order per vendor and groups them. Each kitchen's order is a normal order: it prints on their screen, appears in their reports, moves their stock, and belongs to them. The group holds only what the guest experienced — one basket, one payment, one collection number.

This is the approach HelchPOS takes, and the reason is not elegance. Every report, Z-report, kitchen route, refund and stock movement in a POS is written per site and per order. An order that spans several sites means changing every one of them, and each change is a place where one kitchen's money can silently land in another's. A group of ordinary orders changes none of them.

The arithmetic nobody thinks about until it is wrong

Once one payment covers several businesses, a set of small decisions decide whether vendors trust the numbers. None of them are hard. All of them are wrong somewhere.

A discount has to be apportioned, and pennies do not divide by three

Ten pounds off a basket shared by three kitchens is not £3.33 each — that is £9.99, and a penny has gone missing. It has to be 333, 333 and 334, with the extra penny handed to a specific kitchen for a stated reason (largest share first is the usual one) and handed to the same kitchen every time the same basket is recalculated. A vendor who asks why they got the odd penny deserves an answer better than "rounding".

A refund comes out of the kitchen that was paid for it

If a guest sends back a burger, that money comes off the burger stall. Not pro-rata across everyone who happened to be in the basket. This sounds obvious and is routinely got wrong, because the payment was taken as one number and the easiest thing to do is reverse it as one number.

A tip follows the food unless somebody says otherwise

A guest tipping on a basket is usually tipping the people who made the food. Splitting it by share of the basket is the sane default; a hall may want a different rule, and either way the rule has to be written down somewhere a vendor can read.

Nothing is apportioned across a zero

A basket where one kitchen's line came to nothing — comped, or fully discounted — must not receive a share of anything. Dividing by a zero total is the classic way to turn a quiet evening into an error nobody can explain.

What to ask a supplier

1. When a guest buys from three of my vendors and pays once, how many orders exist in your system afterwards?
2. Whose merchant account does the money land in, and when does each vendor get theirs?
3. Show me a refund on a multi-vendor basket. Which vendor is out of pocket?
4. Show me a £10 discount split three ways. Where does the odd penny go, and can you tell a vendor why?
5. Can a vendor pull their own numbers without asking the hall for them?

If you run a food hall and want to compare notes on any of the above, we are building this in a working one — Helch Market Winchester — and would rather talk to operators than write another feature list.