Restaurant Aggregator Reconciliation

By Nupur Mittal

Co-founder at OCTA — works with accounting firms on month-end close and reconciliation automation.

Restaurant aggregator reconciliation matches a restaurant's own sales records (its POS export) to a food-delivery platform's settlement report, then explains the gap between what the POS says was sold and what actually lands in the bank. It bridges POS sales to the aggregator's reported collections, subtracts every settlement deduction — commission, payment fees, delivery funding, promotional charges, and VAT — and ties the result to the bank receipt. This page walks through the full process for a Talabat-style aggregator against a POS system like Syrve, with a worked example in AED, and how OCTA Flow runs the matching while a person signs off.

Why aggregator reconciliation matters, and where it goes wrong

Every restaurant that takes orders through a delivery aggregator runs two parallel sets of books without realizing it. The POS records a sale the moment an order is placed and paid for. The aggregator records something different: it nets out its own commission, payment handling fee, delivery funding contribution, and any promotional or voucher cost before it ever sends a payout. The number that hits the restaurant's bank account is neither the POS total nor a simple percentage of it — it's the POS total run through a chain of deductions that only the aggregator's settlement report shows in full. Without a structured reconciliation, a finance team is left comparing two numbers that were never supposed to match in the first place.

The volume makes this worse than a typical reconciliation. A single branch can generate thousands of orders a month through one aggregator alone, and a restaurant group running several brands across several branches is reconciling that volume for every aggregator, every branch, every period. Order IDs are formatted differently between the two systems. Branch names rarely match character-for-character. Dine-in orders paid through the aggregator's app show up mixed in with delivery orders. Cancelled orders, partial refunds, and vouchers each move money differently on each side. Left unreconciled, the gap between "sales per POS" and "cash received from the aggregator" becomes an unexplained variance that nobody can point to a cause for — and that's exactly where revenue leakage, aggregator billing errors, and simple timing differences all hide, indistinguishable from each other until someone does the work to separate them.

The aggregator reconciliation process, step by step

A rigorous aggregator reconciliation follows a consistent sequence, run per branch and rolled up to a brand total. The steps below are the full procedure OCTA Flow executes for a Talabat-style aggregator against a POS system such as Syrve; they also stand alone as a best-practice process for any restaurant group reconciling a delivery aggregator.

1. Align the period and confirm scope. Take the aggregator's detailed settlement report (its order-level statement of account) and the POS export filtered to that aggregator's payment type, for the same period. Confirm both files cover the same calendar span. Orders that fall right at a month boundary and settle in the following cycle are timing differences to describe, not errors to chase.

2. Decompose the aggregator's sales figures per order. The aggregator's report doesn't give you a clean "sales" number — it gives you the raw components. For each order, back out the small-order fee, service fee, and delivery charges the aggregator already netted off, add back any discount the aggregator itself absorbed, and compute the net sales, the discount amount, and the gross sales (net plus discount) at the order level. Strip VAT (5% in the UAE) from net sales to get the VAT-exclusive figure that commission is calculated on.

3. Match orders one-to-one. Pair every aggregator order to its POS receipt using the order ID on one side and the external order number on the other, treating both as text and normalizing formatting differences (a POS system will often store an order number as a decimal that needs its trailing zero stripped before it will match). Flag duplicate order numbers on either side rather than silently keeping the first one.

4. Classify what doesn't match. An order on the aggregator's report with no POS receipt — other than dine-in orders paid through the aggregator's app, or an order the aggregator itself marked cancelled — is a real exception: a sale the books don't know about. A POS receipt tagged with the aggregator's payment type but with no matching aggregator order is the mirror exception: a sale the aggregator never reported or paid for. Both need investigating, not writing off.

5. Build the two adjustment blocks and bridge to the aggregator's total. This is the core of the reconciliation. Take the POS gross sales, discount, and net sales as the starting point, then bridge to the aggregator's own reported totals through two adjustment blocks: an order-level variance block (every order where the POS and aggregator amounts disagree, however small) and a dine-out adjustment block (orders placed through the aggregator's app for dine-in service, which the POS and the aggregator often categorize differently). The two blocks combine into a Total Gross Adjustment and Total Discount Adjustment. Add those to the POS totals and the result must equal the aggregator's own reported gross sales, discount, and net sales — the bridge is exact by construction, and any gap between the bridged number and the aggregator's directly-summed total is a genuine reconciling exception, not a rounding artifact.

6. Subtract every settlement deduction. Starting from the bridged collection figure, work through the full deduction stack the aggregator applies before it pays out: commission and its VAT, payment handling fees and their VAT, the aggregator's delivery-funding contribution, deal or promotional-premium charges, and a credit back for cancelled orders. Layer in whatever the aggregator bills separately rather than netting from order data — vendor wastage claims, customer compensation, promotional listing charges, cost-per-click marketing charges — as manual entries once the aggregator's own invoices for them are available.

7. Tie the result to the bank. The running total after every deduction is the expected payout. Compare it to what the bank statement shows was actually received from the aggregator for the period. Any residual difference is the balance that must be investigated — never carried forward or plugged with an unexplained adjustment. Repeat the full sequence for every branch, then confirm the branch totals sum exactly to the brand-level result.

The settlement bridge (worked example)

Here's a simplified worked example for one branch for a monthly period, using AED and the UAE's 5% VAT rate.

Step 1 — POS starting point:

Step 2 — Bridge to the aggregator's reported totals:

This bridged Collection figure must tie to the aggregator's own reported gross sales, discount, and net sales, summed directly across every order on its report — confirming the two adjustment blocks captured every variance.

Step 3 — Subtract settlement deductions (whole-report basis for this branch):

Step 4 — Tie to the bank:

The branch ties exactly: AED 178,980 of bridged collection, less AED 25,378 of commission, fees, and VAT, equals the AED 153,602 the bank confirms was actually received. When the two don't tie within tolerance — commonly AED 1 per order for line-level variances and AED 100 per branch or AED 500 at brand level for the summary balance — that gap becomes the exception to chase, not a number to plug and move past.

Key controls and red flags

A reconciliation that just matches transactions isn't enough — what makes it a genuine control is what a careful reviewer checks for on top of the matching:

• The bridged totals don't tie to the aggregator's own reported figures beyond tolerance — the single most serious flag, since it means an order-level variance or dine-out adjustment was missed
• Orders on the aggregator's report with no POS receipt, excluding dine-in orders and cancelled orders — a sale the books haven't recorded
• POS receipts tagged for the aggregator with no matching aggregator order, or a blank order reference — a sale the aggregator never reported or paid for
• Duplicate order numbers on either side, which double-count a sale if left unresolved
• A cancelled-order refund that doesn't match the aggregator's own credit note, which can point to a timing difference in when the credit was issued versus when it was booked
• A branch's cancellation or refund rate running more than double the brand median — worth investigating before assuming it's normal variation
• A branch or POS location that can't be matched to its aggregator counterpart, which will silently exclude that branch's orders from the reconciliation if not flagged and resolved
• A coverage gap between the two files' periods beyond normal month-boundary timing, which means the two sides simply aren't reconciling the same window of business
• Non-aggregator transactions mixed into the aggregator-filtered POS export — call-center orders or a different aggregator's orders paid through a similar channel, which will distort the totals if not excluded

Catching these consistently — for every branch, every aggregator, every period — is what turns the reconciliation from a spreadsheet exercise into a real check on cash leakage.

What a completed reconciliation produces

A finished aggregator reconciliation is a signed workpaper, not just a matched file. A complete package includes:

How OCTA Flow automates aggregator reconciliation

OCTA Flow runs the order-level matching and the settlement bridge for you, and leaves the judgment calls — and the sign-off — with your team. The workflow mirrors the process above:

1. Pick the Restaurant Aggregator Reconciliation Skill. Flow already knows the full procedure: decompose the aggregator's sales figures, match orders one-to-one, build the variance and dine-out adjustment blocks, bridge to the aggregator's collection total, and subtract every settlement deduction.
2. Connect your data. Point Flow at the aggregator's detailed settlement report and the POS export for the period, plus the bank statement if you want the payout auto-matched — or upload the files directly.
3. Run. Flow matches every order it can, decomposes the aggregator's sales columns, builds both adjustment blocks, bridges POS sales to the aggregator's reported collection, and works through the full deduction stack to an expected payout per branch.
4. Review findings by severity. Rather than a wall of matched orders, Flow surfaces only the exceptions — a missing order, a branch that won't map to its counterpart, a summary balance that won't tie — ranked by severity, each with a recommended action. Your team works the handful of exceptions, not thousands of order rows.
5. Sign off. Once every branch ties within tolerance and the manual settlement lines are entered, Flow assembles the workpaper — Summary, Branch Summary, aggregator and POS detail, and Exceptions — with the full audit trail intact.

The result: the order-by-order matching that used to take a preparer days across every branch and every aggregator now runs in minutes, and your team's time goes to the exceptions that actually need a decision.

Control and trust: Flow proposes, you approve

This matters most when the numbers touch cash that's already moved: OCTA Flow never writes to your books or your aggregator account on its own. Every proposed treatment — chasing the aggregator for a missing order, escalating an unresolved balance, confirming a branch mapping — is something a person on your team reviews and confirms.

That control model runs through the whole reconciliation:

• Findings, not silent changes. Flow raises what it found and what it recommends — you decide whether to chase the aggregator, escalate, or accept a documented timing difference.
• Severity and escalation built in. A branch that won't tie out is flagged as critical and can be escalated to a finance manager or controller rather than absorbed into next period's opening balance.
• A complete audit trail. Every match, every adjustment, every approval, and every override is logged, so the reconciliation is fully traceable back to the source files.

You get the speed of automating thousands of order-level matches with the accountability of a person confirming every judgment call — exactly what reconciling cash against a third-party platform requires.

What the reconciliation draws on

To run an aggregator reconciliation, Flow uses the same sources a preparer already works from:

• Aggregator settlement report — the aggregator's detailed order-level report (its statement of account) for the period, with sales, refund, voucher, commission, and fee columns (required)
• POS sales export — the restaurant's point-of-sale export filtered to that aggregator's payment type, with gross, discount, net sales, and VAT per receipt (required)
• Bank statement extract — the aggregator's payout credits for the period, to auto-fill the Received in Bank line and confirm the balance ties (optional — stays a manual input if not provided)

Flow works from whatever your client has connected — it identifies each file by what it contains, not by filename, so it doesn't matter what the aggregator or POS system is called or how the export is labeled.

Related skills and terms

Frequently Asked Questions

What is restaurant aggregator reconciliation? It's the process of matching a restaurant's own POS sales records to a food-delivery aggregator's settlement report, bridging any differences between the two, then subtracting the aggregator's commission, fees, and other deductions to arrive at the payout the restaurant should have received — and checking that figure against the actual bank deposit.

How do you reconcile Talabat (or any aggregator) to your POS? Match each order between the two systems, sort what doesn't match into an order-level variance block and a dine-out adjustment block, bridge the POS totals to the aggregator's own reported gross and net sales, then subtract commission, payment fees, delivery funding, promotional charges, and VAT to reach an expected payout. Compare that to the bank receipt — the gap, if any, is what needs investigating.

Why doesn't my POS sales total match what the aggregator reports? The two systems record different things by design. The POS logs the sale at the moment it's placed; the aggregator's report already reflects its own fee structure, any voucher or discount it absorbed, and how it categorizes dine-in orders placed through its app versus standard delivery orders. A reconciliation exists specifically to bridge that gap in a structured way rather than leaving it unexplained.

What deductions does an aggregator take out of restaurant sales before paying out? Typically commission (plus VAT on that commission), a payment handling fee (plus its VAT), a contribution toward delivery funding, and deal or promotional-premium charges tied to any discounts run through the platform. Aggregators also bill some items separately — vendor wastage claims, customer compensation, promotional listing charges, marketing charges — that don't appear in the order-level data and have to be entered from the aggregator's own invoices.

What's the difference between a dine-in order and a delivery order in this reconciliation? Some aggregators let customers order for dine-in through the same app used for delivery. Those orders are paid through the aggregator but fulfilled in the restaurant, and the two systems often categorize them differently — which is why they're bridged through their own adjustment block rather than treated as a standard delivery-order variance.

Can aggregator settlement reconciliation be automated? The order matching, the sales decomposition, and the settlement bridge can be automated and reviewed, while judgment calls — chasing a missing order, confirming a branch mapping, accepting a timing difference — stay with your team. That's the model OCTA Flow uses.

Does OCTA Flow post entries or contact the aggregator directly? No. Flow surfaces findings and recommended actions; a person on your team decides whether to chase the aggregator, escalate internally, or accept a documented explanation. Nothing is written to your books or sent to a third party automatically.

See how restaurant groups reconcile every branch and every aggregator with human sign-off → start a 30-day OCTA Flow trial.

See OCTA Flow on your own files

AI agents that run reconciliations, close, and reporting on your QuickBooks or Xero stack, with a full audit trail.

Start your 30-day trial · Prefer a walkthrough first? Book a demo