Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
An Indian restaurant's daily revenue lands across aggregator payouts, POS card and UPI settlements, and physical cash, each with different commissions, TDS 194O, TCS Section 52, GST splits and settlement timing — making book-to-bank match impossible without per-rail decomposition.
Decompose each aggregator settlement into gross order value, commission, packaging fee, cancellation, TDS 194O and TCS Section 52 before matching the net payout to the bank credit; reconcile POS gateway settlements separately by MID and batch ID; match daily cash deposits to POS cash sales by deposit slip.
Per-aggregator commission rate by contract tier, packaging fee schedule, GST 5%/18% rule by outlet type and tariff threshold, multi-brand cloud-kitchen GSTIN mapping, T+N settlement cycle by gateway, and TCS Section 52 GSTR-2X claim cadence.
A daily close that ties POS-recorded sales to bank credits across all four rails, with classified variances (under-payout, missing TDS, GST 5% vs 18% mismatch, cash short/over) and an aged exceptions list ready for aggregator dispute and audit trail.
A finance controller running a 12-outlet restaurant chain in Bangalore closes April books and finds three numbers that should match but do not: POS recorded sales of ₹3.41 crore, aggregator settlement reports totalling ₹1.92 crore, and bank credits across four accounts of ₹2.74 crore. The gap is not theft. It is the cost of running restaurant reconciliation in India without per-rail decomposition — commission, TDS 194O, TCS Section 52, packaging fees, refunds and cancellation deductions are all hiding inside the difference, and so is the 5% vs 18% GST split that determines whether the input tax credit on aggregator commission can be claimed at all. This guide walks through what the daily close looks like when it is done correctly.
What restaurant reconciliation in India involves
Restaurant reconciliation in India is the process of tying every order recorded at the point of sale to a corresponding bank credit, after stripping out the deductions and tax components that each payment rail applies before payout. Indian restaurants operate across four rails simultaneously: food-delivery aggregators (Zomato, Swiggy, Magicpin, Dunzo), POS-attached payment gateways for in-store card and UPI (Pine Labs, MSwipe, PayU, Razorpay), direct UPI collections, and physical cash. Each rail has its own settlement cycle, its own deduction stack, its own GST treatment, and its own audit trail.
What makes the Indian context structurally different from a US or European restaurant is the layered tax regime. Section 9(5) of the CGST Act shifts the GST liability for restaurant services delivered through e-commerce operators to the operator itself from 1 January 2022. Section 194O of the Income Tax Act requires those same operators to deduct 1% TDS on gross facilitated value. Section 52 of the CGST Act adds a 0.5% TCS layer that is reported in GSTR-8 and claimable through GSTR-2X. None of this exists outside India, and none of it can be reconciled with a generic accounting tool that was designed for a single-currency, single-tax-jurisdiction restaurant business.
Why this is harder than retail or e-commerce reconciliation
The aggregator deduction stack
A single Zomato or Swiggy order on the platform produces an order value, but the restaurant never receives the order value. What lands in the bank, days later, is order value minus platform commission (commonly 18–30%), minus packaging fee charged back, minus customer refunds and cancellations, minus 1% TDS under Section 194O, minus 0.5% TCS under Section 52, plus or minus promotional reimbursement adjustments. Each component appears as a separate line in the settlement report — but the report is per-week or per-cycle, not per-order, and the order-level breakdown is in a different download. Reconciling at the cycle level hides per-order disputes; reconciling at the order level requires joining two reports per aggregator per day.
The GST 5% vs 18% split
Standalone restaurants pay 5% GST on dine-in and takeaway with no input tax credit, under Notification 11/2017-CTR. A restaurant attached to a hotel where any declared room tariff is ₹7,500 or above pays 18% GST with full ITC. Outdoor catering (a separate supply line) is taxed at 18% with ITC. Aggregator commission, billed to the restaurant by Zomato or Swiggy, carries 18% GST regardless — but that commission ITC can only be claimed against 18%-with-ITC revenue (catering, hotel-attached restaurant), not against 5% revenue. A finance team that fails to segregate revenue by GST rate at the line-item level either over-claims ITC and faces a Section 73 demand, or under-claims and leaks credit on every cycle.
Cloud kitchens, multiple brands, one GSTIN
A cloud kitchen operator running four brands (a north-Indian, a biryani, a sandwich, a dessert brand) out of one Bangalore unit typically holds one GSTIN for the unit, but four separate listings on Zomato and four on Swiggy. The aggregator settlement reports come per-listing, but the GST return is filed at the GSTIN level. Reconciliation must aggregate eight listings (4 brands × 2 aggregators) into one GSTIN-level supply figure, then match it to the GSTR-3B filed and to the GSTR-1 outward supply, while keeping per-brand P&L separable for management accounts.
The daily close, step by step
Step 1 — POS day-end and rail tagging
The day-end POS report must tag every transaction by payment rail at source: aggregator (with the platform name and the platform order ID), card via gateway (with the MID and terminal ID), UPI (with the VPA and UTR), or cash. If the rail tag is missing or wrong at this step, no downstream reconciliation will work — a Zomato order recorded as cash, or a UPI receipt logged against a card terminal, becomes an unfindable variance later.
Step 2 — Aggregator settlement decomposition
Each aggregator settlement file (Zomato weekly payout, Swiggy daily payout, Magicpin cycle payout) must be parsed into its component columns: gross order value, commission, GST on commission, packaging fee, refund deduction, cancellation deduction, TDS 194O, TCS Section 52, net payout. The net payout figure is the only one that will match the bank credit. The other columns must be matched to the POS order log to detect rate variance — if Zomato’s contracted commission is 23% but a settlement line bills 27%, that is an over-deduction that needs to be raised inside the dispute window before the cycle ages.
Step 3 — POS gateway and UPI net settlement match
Card and UPI receipts taken at the till settle through the POS-attached gateway (Pine Labs, MSwipe, Razorpay, Cashfree) on a T+1 or T+2 cycle. The gateway deducts MDR, GST on MDR, and where applicable a small TDS, before crediting net to the merchant bank account by MID and batch. Reconciling here means matching POS card-batch totals to gateway settlement files to bank credits — a three-leg match, similar in shape to platform payment gateway reconciliation for marketplaces but with restaurant-specific settlement-cycle quirks.
Step 4 — Cash deposit slip vs POS cash sales
Physical cash recorded at the till must tie to the cash deposit slip submitted to the bank, which must tie to the cash-deposit credit in the bank statement. Variances here split into two classes: short cash (till count below POS cash sales — operational shrinkage or recording error) and over cash (deposit above POS cash — usually a tip pool or a missed receipt). Daily cash variance trending is a control that catches both fraud patterns and process drift.
Variance taxonomy by rail — reference
| Rail | Common variance | Typical root cause | Resolution path |
|---|---|---|---|
| Aggregator (Zomato/Swiggy) | Commission rate higher than contract | Promotion tier mis-applied | Dispute via partner portal within cycle |
| Aggregator | TDS 194O missing in 26AS | Aggregator filing lag | Match in next-quarter 26AS, follow up if still absent |
| Aggregator | TCS Section 52 not in GSTR-2X | Aggregator GSTR-8 not filed for cycle | Wait for next cycle; raise after 30 days |
| POS gateway | MDR rate variance vs contract | Card-network tier mis-classification | MID-level dispute with acquirer |
| UPI | UTR captured at till but no bank credit | Settlement file delay or chargeback | Trace via NPCI UTR; reconcile in T+2 |
| Cash | POS cash above deposit slip | Skim, recording error, or tip pool | Daily till audit; CCTV review for material gaps |
| GST | ITC claimed on commission against 5% revenue | Rule mis-application | Reverse claim in next GSTR-3B; recalc working sheet |
| Multi-brand kitchen | Brand-level revenue does not aggregate to GSTIN supply | Listing-to-GSTIN mapping gap | Rebuild mapping table; restate working |
The India-specific regulatory layer
Three statutory anchors govern restaurant reconciliation in India and must be present in any working close.
Section 9(5), CGST Act — for restaurant services supplied through an e-commerce operator, the operator is the person liable to pay GST. The restaurant’s outward supply via Zomato or Swiggy is reported by the aggregator, not by the restaurant. The restaurant’s GSTR-1 should not double-count these as B2C outward supply. Many restaurants get this wrong in the first quarter after listing on a new platform.
Section 194O, Income Tax Act — 1% TDS on gross facilitated value, deducted by the operator, credited to the restaurant’s PAN, visible in Form 26AS. Reconciling 194O against Form 26AS quarterly is the only way to catch missed deposits or PAN-mismatch errors before the income-tax return is filed.
Section 52, CGST Act — 0.5% TCS, reported by the aggregator in GSTR-8, claimable by the restaurant through GSTR-2X into the electronic cash ledger. This is a working-capital line, not a tax cost — but it leaks if not claimed every cycle.
Notification 11/2017-CTR (5% vs 18%) — outlet-type classification (standalone vs hotel-attached vs catering) drives the rate. The classification must be set per outlet, per supply line, and applied to each invoice. Cross-checking on the GST portal confirms the current notification text where contract terms are ambiguous. Where a restaurant operates an outdoor catering line alongside the dine-in, the two revenue streams are separately taxed and separately ITC-eligible.
What automated reconciliation changes
Manual restaurant reconciliation across four rails for a multi-outlet chain is a five-to-ten-day monthly close, and deduction-level variance work usually does not happen — chains accept aggregator settlements at face value and lose 0.5–2% of revenue to silent under-payouts. Purpose-built reconciliation software India for restaurants treats each settlement file as a structured deduction stack, joins it back to the POS order log at order ID level, and surfaces only the lines that fail to match. TransactIG carries 24+ industry presets including a restaurant configuration that handles the four-rail split, the 5%/18% GST routing, and TCS Section 52 reconciliation against GSTR-2X. Customer outcomes include match-rate improvement from 51% to 88%, with the daily cycle compressing from a five-day monthly batch to a same-day operational control. Build is two-to-four weeks on AWS Mumbai (ISO 27001:2022) once the POS exports a structured day-end file with rail tags at source. For the restaurant chain industry surface, see the Restaurant Chains industry guide. For a head-to-head against the aggregator-side reconciliation tool category, see TransactIG vs Cointab.