Zomato & Swiggy Payout Reconciliation: Where Restaurants Quietly Lose 3–5% of Delivery Revenue
Ask a restaurant owner what Zomato or Swiggy charges in commission and they'll answer without blinking — 18%, 22%, maybe 25% if they've opted into ads and priority placement. Ask the same owner whether last week's payout actually matched what was owed, and the answer is usually a shrug. Not because they don't care. Because finding out means opening a payout sheet with hundreds of line items, each one netting off commission, GST, TCS, TDS, a discount here, a penalty there, and trying to tie it back to orders that were rung up on a completely different system three weeks ago.
In 2026, with aggregator commissions effectively running 25–35% once GST, payment gateway fees and platform fees are added in, that gap between what should have been paid and what actually landed in the bank account isn't a rounding error. Operators who've actually sat down and reconciled a full payout cycle line-by-line are finding 3–5% of delivery revenue disappearing into mismatches — orders marked delivered on the POS but missing from the payout, discounts charged to the restaurant that were never approved, double deductions on cancelled orders, and TCS/TDS calculated against the wrong base amount.
Why this is a 2026 problem, not a 2022 problem
Aggregator fee structures haven't gotten simpler — they've gotten more layered. Zomato's platform fee alone went up roughly 19% earlier this year, stacking on top of base commission, ad spend, Zomato Gold-equivalent discounts, and payment gateway charges. Swiggy's structure looks similar, with its own collection fee and subscription-linked surcharges. Each of these is a separate line in the payout file, and each one is a place a mismatch can hide.
At the same time, GST's e-invoicing and reconciliation net keeps tightening. E-invoicing thresholds have been lowered again in 2026, pulling more restaurant groups into mandatory, auditable digital invoicing, and GSTN has added stricter validation on e-way bills and ITC matching at the GSTR-1/GSTR-2B level. That means a mismatch between your POS bill and the aggregator's reported sale isn't just a revenue leak anymore — it's a compliance discrepancy waiting to surface at audit time.
Where the money actually goes missing
Talk to operators who've done a manual reconciliation (most say it took 3–5 hours a week when done properly) and the same four patterns show up over and over:
- Missing orders: An order was marked complete and billed on the POS, but never appears on the aggregator's payout sheet at all — often because of a sync failure between the aggregator and the kitchen/POS integration.
- Status mismatches: An order the POS shows as delivered and paid for was actually cancelled or refunded on the aggregator side, and the restaurant either double-counts revenue or misses the cancellation fee that got deducted.
- Amount mismatches: Tax, discount or rounding differences between what the POS calculated and what the aggregator settled — frequently caused by promotional discounts the aggregator funded partially and passed the rest on to the restaurant without clear labeling.
- Penalty and commission drift: Ad spend, priority listing fees, or penalty deductions (for late acceptance, low ratings, or stockouts) get bundled into the net payout with no line-by-line trail back to specific orders.
None of this is catchable by glancing at a bank credit. It only shows up when someone tallies the aggregator's order-level report against the restaurant's own order-level records — which is exactly the manual, spreadsheet-driven work most owners don't have three to five hours a week to do, and most POS systems don't do for them automatically.
What this looks like on an actual payout
Take a mid-sized outlet doing roughly ₹12–15 lakh a month in combined Zomato and Swiggy sales — not unusual for a busy casual-dining or cloud kitchen operation in a metro. At a 3% reconciliation gap, that's ₹36,000–45,000 a month quietly missing, or upward of ₹4–5 lakh a year, across just two channels. Multiply that across a five-outlet chain and it stops being a rounding issue and starts being the difference between a location that's marginally profitable and one that isn't. The frustrating part is that almost none of this is deliberate underpayment by the aggregator — it's mostly sync failures, timing mismatches between order status updates, and bundled deductions that nobody on the restaurant side has the bandwidth to unbundle every week.
What the market is already building toward
This isn't a gap that's gone unnoticed. Petpooja has built out dedicated online order reconciliation tooling that ingests Zomato/Swiggy payout reports and matches them against POS data. UrbanPiper has published guidance specifically on catching payment errors on Zomato and Swiggy through its aggregator integration hub. Standalone reconciliation tools like Cointab exist purely to solve this one problem for restaurant finance teams. The direction is clear: reconciliation is moving from "something the owner's accountant does manually at month-end" to "something the POS should be doing automatically, order by order, as payouts land."
That's the right direction, but it only works if the reconciliation engine has clean, complete order data to reconcile against in the first place — which means the POS recording the original bill has to be accurate about channel, discount, tax and status from the moment the order is placed, not patched up after the fact.
What to actually check before your next payout cycle
- Can you pull an order-level export, not just a summary? A payout total tells you nothing. You need every order ID, gross amount, commission, tax and net payout broken out individually, matchable against your own POS records.
- Does your POS tag the sales channel on every bill? Dine-in, takeaway, Zomato, Swiggy and any other channel need to be distinguishable at the line-item level, or reconciliation is guesswork.
- Are cancellations and refunds reflected on the POS side in real time? If your kitchen and billing system don't get a cancellation signal back from the aggregator promptly, you'll keep counting revenue that was never paid.
- Is GST calculated consistently between your POS and the aggregator's invoice? With e-invoicing thresholds tightening in 2026, a persistent mismatch here is a compliance flag, not just a revenue one.
- Who actually reviews the payout file each cycle, and how long does it take them? If the honest answer is "nobody, we just check the bank balance looks roughly right," that's the leak.
For a multi-outlet operator running dine-in, takeaway and two or three aggregators simultaneously, this adds up fast. A 3–5% miss on delivery revenue across a chain doing even a modest volume of aggregator orders is real money every single month — money that's not lost to competition or bad reviews, just lost to nobody having the time to check a spreadsheet.
The fix doesn't have to mean hiring a finance analyst. It means treating reconciliation as a daily five-minute check instead of a monthly fire drill: the POS flags mismatches as payouts arrive, instead of an owner discovering six weeks later that three weeks of Swiggy orders never got credited. Whether that reconciliation lives inside your POS, in a bolt-on tool like the ones Petpooja and UrbanPiper offer, or in a dedicated reconciliation product, the principle is the same — it only works if it's automatic and it only works if the underlying order data was clean to begin with.
Setu Dine's multi-outlet dashboards tag every order by channel from the moment it's billed, which is the foundation reconciliation actually depends on — you can't match what you never recorded cleanly. If you're running dine-in alongside Zomato and Swiggy and haven't reconciled a full payout cycle recently, it's worth the afternoon before it becomes a bigger number.