Multi-Outlet F&B Daily Close: Automating the Nightly Sales and Stock Reconciliation

If your F&B group runs three or more outlets in Singapore and the daily close still means WhatsApp photos of Z-readings sent to a head-office admin who rebuilds a spreadsheet each morning, the fix is not a new POS. It is a nightly reconciliation routine that pulls POS sales, payment settlements and stock movement into one consolidated file automatically, and asks a human to look only at the exceptions. Done properly, an outlet manager spends under ten minutes at lockup and head office has a group-wide position by 9am the next day — not in the third week of the following month, when nothing can be done about it.

What actually happens during a multi-outlet daily close today?

The typical sequence in a four-outlet group looks like this. At lockup, the duty manager prints the Z-reading, counts the cash drawer, photographs both, and sends them to a group chat. Somewhere in that chat are also the day's void slips, a staff meal tally, and a note that the chiller at one outlet was down for two hours. The next morning an admin opens the POS back office, exports yesterday's sales per outlet, keys the cash count into a spreadsheet, and starts chasing whoever forgot to send their photo.

Delivery aggregator sales sit in a separate place entirely. Grab, foodpanda and Deliveroo each report in their own merchant portal on their own settlement cycle, and the money arrives days later net of commission — typically a quarter to a third of gross order value — plus adjustments for cancellations and customer refunds. Very few groups reconcile those settlements line by line. They check that money arrived and move on.

Stock is usually worse. Most multi-outlet groups do not count anything daily. They count key items weekly, full stock monthly, and discover variance long after the shift that caused it. By then nobody remembers whether it was theft, over-portioning, an unrecorded transfer between outlets, or a supplier short-delivery that was signed for without checking.

The result is a close that consumes real admin hours every single morning and still produces numbers too late and too coarse to change anyone's behaviour.

Which numbers should the close produce every night?

Before automating anything, fix what the close is for. A useful nightly output for each outlet contains six things and nothing else:

• Gross sales by channel — dine-in, takeaway, and each aggregator separately. Blending them hides the fact that one channel is growing on margin you do not actually earn.
• Payment breakdown versus expected — cash counted against cash sales, and card, PayNow and NETS totals against what the POS says was tendered. Any gap above a set threshold is an exception.
• Voids, discounts and staff meals — as a count and a dollar value, with the approving manager's name attached.
• Key-item stock movement — not everything. Ten to fifteen high-cost or high-theft SKUs, counted at close, compared against theoretical usage derived from items sold.
• Labour hours against sales — actual clocked hours for the day divided into net sales, so a bad roster shows up the next morning rather than at month end.
• Exceptions only — a short list of what fell outside tolerance, which is the only part a human should have to read.

If your current close does not produce these, adding software will simply make you wrong faster.

How do you automate the close without replacing your POS?

You almost certainly do not need to change POS. Nearly every system used by Singapore F&B groups can either export daily sales on a schedule or expose an API. The automation sits above it.

The pattern that works is a nightly job that runs after close and does four things in sequence. First, it pulls sales data per outlet from the POS — by API if one exists, by scheduled CSV export if not. Second, it pulls aggregator order data from each merchant portal, so delivery sales are captured on the day they happen rather than when the payout lands. Third, it accepts the outlet's cash count and key-item stock count through a simple mobile form — a web form or a structured WhatsApp reply, not a photo. Fourth, it compares everything, writes a consolidated record, and pushes a short exception message to the operations lead and the outlet manager.

The mobile form is the part groups underestimate. A photograph of a Z-reading is not data; someone has to retype it. A form with eight fields, submitted by the duty manager before they leave, is data — and it timestamps who submitted it and when, which quietly solves the problem of the outlet that always reports late.

Payout reconciliation runs on a separate weekly cycle. When an aggregator settlement arrives, the job matches it against the orders already captured for that period and flags any order that was recorded but never paid, or paid at an unexpected rate. This is where groups routinely find money — refunds absorbed silently, promotional funding not credited back, commission applied to the wrong tier.

What does a 30-day build sequence look like?

Sequence it so each week produces something usable on its own:

1. Week 1 — define and instrument. Agree the six outputs and the tolerance for each exception. Get POS export or API access working for one outlet. Build nothing else.
2. Week 2 — the lockup form. Deploy the cash and key-item count form to all outlets. Even with no automation behind it, this alone kills the photo-retyping loop.
3. Week 3 — consolidate and compare. Join POS sales, aggregator orders and the lockup form into one nightly record per outlet, with variance calculated automatically.
4. Week 4 — exceptions and payouts. Turn on the morning exception message and run the first weekly aggregator payout match.

Run the old process in parallel for the final week. If the automated close and the manual close disagree, the automated one is usually right and the disagreement tells you which manual step was quietly wrong all along.

How do you know it is working?

Three measures. Admin minutes spent on the close per outlet per day, which should fall from roughly thirty to under ten. Time from close to consolidated group figures, which should land under twelve hours. And exception closure rate — the share of flagged variances that get an explanation within 48 hours. That last one matters most. A close that flags problems nobody investigates is just a more expensive spreadsheet.

Build it now and it will be running before the Deepavali and year-end festive stretch, when volume is highest, relief staff are least familiar with process, and stock variance is most likely to be absorbed as "it was busy."

Frequently asked questions

Do we need to count stock every night for this to work?

No — and full nightly counts usually fail within a fortnight. Count ten to fifteen high-cost or high-shrinkage items daily and keep your existing weekly or monthly full count. Daily counting of a narrow list catches the variance that matters while remaining fast enough that staff actually do it at lockup.

Our POS has no API. Is automation still possible?

Yes. Most POS back offices support scheduled email or file exports of daily sales, and a job can collect and parse those on a fixed schedule. It is slightly less elegant than an API and needs monitoring in case a report format changes, but it produces the same consolidated result. Lack of an API is not a reason to delay.

Should each outlet close its own books, or should head office do it?

Split it. The outlet is responsible for the physical facts only — cash counted, key items counted, incidents noted — submitted before lockup. Head office owns consolidation, variance investigation and payout reconciliation. Asking outlet managers to reconcile aggregator settlements is how the task gets skipped.