At a glance
- Daily reconciliation ties four things together: the POS export, card settlements, delivery-app payouts and bank deposits.
- The workflow table in this article can be copied as a checklist: one row per stage, with the check and the exceptions to route.
- The one published hours figure we found is a vendor's modeled example, not survey data, so we show how to compute your own number instead.
- An agent can match and classify; the controller decides every exception.
- An agent layer sits beside your accounting platform. Check that platform's own documentation for what it already matches.
How do multi-location restaurants reconcile POS, delivery-app and bank-deposit data?
A multi-location group reconciles each location's daily sales summary from the point-of-sale (POS) system against the money that actually arrives: card settlements from the processor, payouts from delivery apps, and cash and card deposits at the bank. One vendor describes the manual routine as pulling data from the POS, matching it against bank deposits, credit card settlements and third-party delivery payments, and investigating any variances [1].
A card settlement is the batch of card payments a processor pays out to the merchant, net of fees; card settlement reconciliation checks that payout against POS card sales. A third-party delivery payment is the payout a delivery platform sends for orders it handled, net of its commission; delivery app payment reconciliation checks it against the delivery orders in the POS.
The difficulty is timing and netting. Card money arrives after a delay and net of fees, and delivery money arrives net of the platform's commission and fees. The same vendor describes a card settlement delay and deducted processing fees [1]. A deposit therefore won't equal that day's sales figure once fees and delays apply, and the match has to explain the gap instead of just comparing totals.
How many hours does manual reconciliation take for a multi-unit restaurant group?
No measured, independent study is available that we could verify. The only published figure we found comes from a vendor. FirmAdapt's CEO published a calculation on April 4, 2026: a restaurant group with 10 locations reconciles 3,650 daily sales summaries per year, and at 15 to 20 minutes per location per day, that is 900 to 1,200 hours per year [1]. It is a calculation based on an assumed 15 to 20 minutes per location per day; a modeled example, not survey data.
Use the method rather than the number. Annual hours equal locations, times minutes per location per day, times days open, divided by 60. Time a few real closes at two or three locations to get your own minutes, including the time spent chasing variances. That gives you a baseline you can defend before and after any change.
The daily sales reconciliation workflow for restaurant groups
This is the daily workflow for one business day, run per location and rolled up to the group. It follows the order of the money: POS export first, then card settlement, then delivery-app payouts, then the bank deposit tie-out. The table is written as a checklist you can copy into your close procedures and adapt to your own POS and bank feeds.
| Stage | Input | Check | Exceptions to route |
|---|---|---|---|
| 1. POS export | Daily sales summary for each location: sales by tender type and by channel, tax, tips, discounts, voids | Totals foot; every location has a record for the business date; tender and channel codes map to ledger accounts | Missing location-day; totals that do not foot; a tender or channel code with no mapping |
| 2. Card-settlement match | Processor settlement reports | Card tender totals by card type agree to the settlement after fees and the expected settlement delay | Settlement not yet received; fee difference; chargeback or adjustment |
| 3. Delivery-app payment match | Delivery platform payout statements | Delivery orders in the POS agree to the payout after commission and fees; credits and disputes are matched to their orders | Order in the POS but not in a payout; credit or dispute; commission that differs from the agreed rate |
| 4. Bank-deposit tie-out | Bank activity for the deposit accounts | Cash counted and card and delivery payouts agree to deposits; combined deposits are split back to days and locations | Cash short or over; deposit with no source; source with no deposit |
| 5. Review and post | Matched sets and the exception list | Every exception has a recorded resolution; cleared items are posted; open items carry an age | Item still open past the age limit you set |
Run stages 1 through 4 in this order because each one removes known money from the next. After card and delivery money is matched, what remains in the bank activity is mostly cash and unexplained items, which is a much shorter list to investigate.
What does an agent automate in a restaurant group's daily reconciliation?
An AI agent is software that completes a multi-step task using tools, within rules a person sets. In this workflow it can do the repetitive mechanical work in stages 1 through 4. A vendor describes automation of the same pattern, including flagging any cash variance above a configurable threshold [1].
- Pull the POS exports, settlement reports, payout statements and bank activity.
- Apply your mapping and matching rules, allowing for fees and settlement timing.
- Classify each difference by likely cause and draft the exception queue.
What the agent should not do is resolve a variance on its own. We recommend it write each exception to a queue with the evidence attached: the POS line, the settlement or payout line, the bank line and its proposed cause. It proposes; a person decides. This is the same approve-before-it-posts pattern covered on our document review with human approval page, and the matching pattern is covered on financial reconciliation automation.
Who reviews a restaurant group's reconciliation exception?
The controller owns every exception-resolution decision, as the group's own operating choice. Others can supply facts: a location manager can confirm a cash count, or an accounts payable lead can confirm a platform fee. The decision to write off, adjust, re-map or chase a difference stays with the controller, and the agent never closes an exception by itself.
- Read the proposed cause
Open the exception with its POS, settlement or payout, and bank lines side by side, and read the cause the agent proposed.
- Gather the facts
If the evidence is incomplete, ask the location or the platform for the missing record and leave the item open.
- Decide the resolution
Choose to accept as timing, adjust, re-map, write off or dispute. The controller records the choice.
- Record who decided and when
Keep the decision, the person, the date and the evidence together so the close can be re-performed later.
- Adjust the rule if it repeats
If the same exception recurs, change the matching rule or mapping, with the controller's approval, rather than clearing it by hand each day.
Does this replace Restaurant365 or a similar platform in a restaurant group?
No. We recommend an agent as a layer beside your accounting platform, not a replacement for it. Your platform stays the system of record. Restaurant365's own documentation says its bank deposits are used when auto-matching uploaded bank activity and when performing a bank reconciliation [2], and that with regular use of its Bank Activity feature many transactions will already be marked as reconciled [3].
So the first step is to read your own platform's documentation and list what it already matches in your configuration. Whatever it leaves open, such as a delivery payout that cannot be tied to its orders, is the candidate scope for an agent. The same check applies to MarginEdge, Kit or any other tool you run.
Where to start: a first scoped workflow
Start with one stage at a few locations, not the whole workflow. We recommend delivery-app payout matching or card-settlement matching, because both are rule-based and produce a clear exception list. Run the agent alongside the manual close for a few weeks and compare its exception list with what your team found.
- Time the current close at two or three locations to set the baseline minutes.
- Pick one stage and write its matching rules and tolerance in plain language.
- Define the exception queue and who sees it. The controller decides each item.
- Run in parallel with the manual close and review every difference between the two.
- Widen to more locations or the next stage only when the controller is satisfied with the exception evidence.
If you want help scoping this, our AI agent implementation service starts with a single workflow like this one.
When this doesn't apply
- Your platform already matches deposits and settlements, and the exception list is short enough that your team clears it the same day.
- The POS does not export a clean daily summary, so there is nothing consistent to match. Fix the export first.
- Volume is a single location, where a spreadsheet or the platform's own matching can be enough.
- Matching rules differ by location and are not written down. Document them before automating.
Frequently asked questions
How do multi-location restaurants reconcile POS, delivery-app and bank-deposit data?
They compare each location's daily POS sales summary with card settlements, delivery-app payouts and bank deposits, in that order. Because card and delivery money arrives late and net of fees, the match explains the gap instead of comparing totals. Differences that cannot be explained become exceptions for the controller to resolve.
How many hours does manual reconciliation typically take for a multi-unit group?
We found no measured study. FirmAdapt's April 4, 2026 calculation for 10 locations, based on an assumed 15 to 20 minutes per location per day, gives 900 to 1,200 hours per year; it is a modeled example, not survey data. Time your own closes to set a baseline.
What does an agent automate in this reconciliation?
An agent can pull exports and statements, apply your mapping and matching rules, allow for fees and settlement timing, and classify each difference by likely cause. It writes each exception to a queue with the evidence attached. It does not resolve exceptions; a person does that before anything posts.
Who reviews an exception?
The controller decides every exception, as the group's own operating choice. A location manager or payables lead can supply facts, such as a cash count or a platform fee. The agent proposes a cause and attaches evidence, and the controller records the decision, the date and the evidence.
Does this replace Restaurant365 or a similar platform?
No. We recommend an agent as a layer beside your accounting platform, which remains the system of record. Read the platform's own documentation to see what it already matches. Whatever it leaves open, such as delivery payouts that cannot be tied to orders, is the candidate scope for an agent.
Related reading
- Financial reconciliation automation covers the matching-and-exception pattern this workflow follows.
- Document review with human approval covers the approve-before-it-posts pattern used for exceptions.
- AI agent implementation covers how a single workflow is scoped and built.
- POS-to-bank reconciliation for retail chains is the retail-chain version of this reconciliation.
- Restaurant groups covers how we work with multi-location restaurant operators.
- Financial close automation covers the wider period-end process this daily work feeds.
Sources
- [1] FirmAdapt, Restaurant accounting automation: daily sales reconciliation across multiple POS systems (April 4, 2026) (accessed 2026-10-29)
- [2] Restaurant365, Bank Deposit (product documentation, May 14, 2026) (accessed 2026-10-29)
- [3] Restaurant365, Bank Reconciliation (product documentation, October 9, 2026) (accessed 2026-10-29)
More in Receivables and collections
Claims Scrubbing and Submission: What to Automate vs. What Stays Human-Reviewed
Claims scrubbing and submission: which checks to automate, which stay with a billing specialist, and a matrix to sort your own claim edits by who decides.
Medical Billing and RCM CompaniesAI Agents for Customer Deduction and Chargeback Management in Food & Beverage
Customer deduction chargeback management for food and beverage: a six-step coding and dispute workflow showing what an agent prepares and your analyst decides.
Food and Beverage ManufacturersStandardizing Denial Management Across Clients: An Implementation Guide for Billing Companies
Denial management across clients for billing companies: a five-stage workflow to normalize categories, route work queues and keep appeals with specialists.
Medical Billing and RCM Companies