Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A multi-outlet QSR chain reconciling Zomato weekly settlements at 50-plus outlets faces three structurally different process choices — manual Excel, an aggregator-side reconciliation tool, or reconciliation infrastructure — each with a different break point on order-level trace, deduction-stack accuracy, Section 393 and Section 52 ledger separation, GSTR-2B commission ITC matching, multi-outlet rollup, and CARO 2020 audit evidence.
Walk each approach through the same Zomato weekly cycle: ingest the settlement file with order-level breakup, decompose the deduction stack (commission 25-35%, GST on commission at 18%, Section 393 TDS at 1% under payment code 1010, Section 52 CGST TCS at 1% intra-state CGST/SGST or inter-state IGST, ad spend, restaurant-borne discounts, refund reversals), match against POS gross sales, link to the bank credit narration, post commission ITC against GSTR-2B, accept the TCS credit into the electronic cash ledger via GSTR-8A, post the income-tax TDS receivable, flag any Section 9(5) GST liability, roll up across outlets and GSTINs, and retain the audit trail.
Zomato weekly settlement-file connector with order-level breakup; commission tier rules; Section 393 TDS calculator at 1% on gross supply with payment code 1010 mapping; Section 52 CGST TCS calculator with intra-state CGST/SGST and inter-state IGST split; GSTR-2B commission ITC matcher; GSTR-8A cash-ledger acceptance flow; Section 9(5) GST liability classifier; refund-period reversal logic; multi-outlet and multi-GSTIN rollup; CARO 2020 audit evidence retention.
A weekly Zomato reconciliation in which every rupee in the bank credit traces back to an order, every deduction has an offsetting ledger entry posted to the right statute, the Section 393 TDS receivable and Section 52 TCS cash-ledger balance reconcile cleanly to source, GSTR-2B commission ITC is accepted on time, multi-outlet and multi-GSTIN rollups close inside the month, and CARO 2020 audit evidence is one query away.
A 50-outlet QSR chain runs on Zomato as a primary delivery channel. Every Tuesday, a single bank credit lands from “ZOMATO MEDIA PRIVATE LIMITED” — but the figure is roughly 62 to 68 percent of the gross order value reported across the partner dashboard for the chain’s 50 outlets. The other 32 to 38 percent is the deduction stack: commission, Section 393 TDS, Section 52 CGST TCS, GST on commission, ad spend, restaurant-borne discounts, and refund reversals from earlier cycles. At ₹3 crore monthly Zomato GMV across 50 outlets, the chain generates roughly ₹3 lakh of Section 393 TDS receivable, ₹3 lakh of Section 52 TCS cash-ledger credit, and ₹13.5 to ₹19 lakh of commission with the corresponding 18% GST input tax credit at stake every month. None of that closes itself.
This article is a process-level walkthrough comparing three structurally different approaches finance leaders at multi-outlet chains use, and where each one breaks.
The Three Approaches
The three approaches are not feature variants of the same solution. They are different operating models.
Manual Excel. A senior associate or a finance manager downloads the Zomato Partner Portal settlement file each cycle, opens the chain’s POS export, opens the bank statement, and reconciles in a workbook with VLOOKUPs, pivot tables, and a manual TDS / TCS schedule. This is how most chains start.
Aggregator-side reconciliation tool. A purpose-built per-aggregator product — examples of the aggregator-side reconciliation category — ingests the Zomato file, decomposes the deduction stack at order level, and produces a reconciliation report. The tool’s scope is Zomato (often Swiggy too), and the output goes back to the finance team for posting and downstream tax workflows.
Reconciliation infrastructure. A config-driven engine that treats Zomato as one of many sources alongside Swiggy, ONDC, POS, bank, GST portal, and TDS statements, with rules per source, four-rail joins, multi-outlet and multi-GSTIN rollup, GSTR-2B and GSTR-8A integration, and ERP write-back. The reconciliation closes inside the engine; the finance team reviews exceptions and signs off.
Walkthrough: A Single Zomato Weekly Cycle, 50 Outlets
The same cycle, the same data, three approaches.
Step 1 — Settlement file ingestion
The Zomato weekly file for 50 outlets typically carries 25,000 to 40,000 order rows depending on city mix, with ~30 columns covering order ID, gross order value, restaurant-borne discount, platform-borne discount, commission, GST on commission, Section 393 TDS deducted, Section 52 TCS collected, ad spend, refund flag, and outlet code.
- Manual Excel. The associate opens the CSV. A 30,000-row file with 30 columns crosses Excel’s practical handling threshold for VLOOKUP-heavy workbooks. Splitting the file by outlet introduces a multi-tab consolidation step.
- Aggregator-side tool. A scheduled connector pulls the file via the Zomato Partner Portal flow and parses the deduction columns into typed fields automatically.
- Reconciliation infrastructure. The same connector runs as one of many source connectors. The file is normalized into a standard order-level model that other sources (POS, bank, GST) can join against.
Step 2 — Commission decomposition
Zomato commission tiers run from 18 to 25 percent for standard partners, scaling to 25 to 35 percent for delivery-only kitchens or premium tiers. At ₹3 crore monthly GMV with a blended 27 percent commission, the chain is paying approximately ₹81 lakh in commission with ₹14.6 lakh of 18% GST on commission as input tax credit.
- Manual. Tier rules are encoded in IF formulas per outlet; rule changes mid-month risk a silent miscalculation.
- Aggregator-side tool. Tier rules are configurable; the tool surfaces commission variance at order level.
- Reconciliation infrastructure. Tier rules sit in the same rule engine as TDS rates and GST rates, so a rate change propagates everywhere with one config update.
Step 3 — Section 393 TDS at 1% under payment code 1010
Section 393 of the Income Tax Act 2025 carries the e-commerce operator TDS forward from legacy Section 194O. Zomato deducts 1% on gross supply value and deposits under payment code 1010, which appears in the new TDS statement format under the chain’s PAN. At ₹3 crore monthly GMV, that is ₹3 lakh of TDS receivable — claimable against quarterly advance tax if posted on time.
- Manual. The associate keeps a separate TDS schedule, manually traces deductions to the new statement once it arrives, and posts a quarterly entry. Cross-period reversal of refund-related TDS is error-prone.
- Aggregator-side tool. Reports the TDS line per order and produces a TDS receivable summary; posting and reconciliation against the new TDS statement remain a finance-team task.
- Reconciliation infrastructure. The Section 393 calculator at 1% with payment code 1010 mapping runs natively. The tool reconciles the chain’s posted TDS receivable against the new statement and flags variances. See the reference in TDS payment codes 1001-1092 and the Section 393 walkthrough.
Step 4 — Section 52 CGST TCS at 1% claim against the cash ledger
Section 52 of the CGST Act 2017 is GST law and is unchanged by the Income Tax Act 2025. Zomato collects 1% TCS on net taxable supply (gross less same-month refunds), filed monthly in GSTR-8, auto-populated to the chain’s GSTR-8A view, and credited to the GST electronic cash ledger to offset output GST in GSTR-3B. At ₹3 crore monthly GMV, that is approximately ₹3 lakh of cash-ledger credit, split as 0.5% CGST + 0.5% SGST for intra-state supplies or 1% IGST for inter-state.
- Manual. The associate logs into the GST portal, pulls GSTR-8A per GSTIN, manually accepts entries, and tracks the cash-ledger balance in a separate worksheet. With multiple GSTINs across states the workload multiplies.
- Aggregator-side tool. Computes the TCS at order level; the GSTR-8A acceptance and cash-ledger reconciliation remain manual unless the tool integrates with the GST portal directly.
- Reconciliation infrastructure. GSTR-8A acceptance flow runs per GSTIN with cash-ledger utilization mapped to GSTR-3B output liability.
Step 5 — GSTR-2B commission ITC matching
The 18% GST on Zomato commission — ₹14.6 lakh monthly in this example — is ITC-eligible. The match is between the chain’s books, the Zomato tax invoice, and GSTR-2B as published on the GST portal.
- Manual. GSTR-2B download, VLOOKUP against book entries, manual reconciliation; mismatches require a chase to Zomato support that the finance team owns.
- Aggregator-side tool. May produce an ITC schedule but typically stops short of GSTR-2B match.
- Reconciliation infrastructure. GSTR-2B is one of the source rails; commission ITC reconciliation is part of the same workflow.
Step 6 — Section 9(5) GST liability flag
Under Section 9(5) of the CGST Act, restaurant supplies through e-commerce operators are taxed at the operator’s hands for specific notified categories. The chain’s reconciliation must flag whether each supply falls under Section 9(5) (operator pays output GST) or remains the restaurant’s own outward supply for GSTR-1.
- Manual. A category-wise classifier lives in a separate sheet; misclassification causes GSTR-1 misreporting.
- Aggregator-side tool. May or may not include this classifier depending on product scope.
- Reconciliation infrastructure. The classifier is a rule in the same engine, with output feeding GSTR-1 staging.
Step 7 — Refund and cancellation reversal across periods
Refunds processed in a later cycle reduce that cycle’s net taxable supply (Section 52 base) and reverse output GST and Section 393 TDS in the original sale period if it crosses a filing month. With 30,000+ orders weekly, refund volume runs into the hundreds.
- Manual. Cross-period reversal is the single largest source of audit-period adjustments.
- Aggregator-side tool. Tracks refund reversals at order level; the cross-statute reversal posting (output GST in original period via GSTR-1 amendment, plus Section 393 TDS adjustment) remains finance-team work.
- Reconciliation infrastructure. Refund-period reversal logic posts to all three statutes coherently.
Step 8 — Multi-outlet rollup and CARO 2020 audit evidence
50 outlets typically map to 5 to 12 GSTINs depending on state spread. Roll-up is per outlet, per GSTIN, per state, per cycle, and per quarter — with audit evidence retained for each.
- Manual. Rollup is a quarterly pivot exercise; CARO 2020 audit evidence is reconstructed retroactively.
- Aggregator-side tool. Rollup at outlet and chain level; the multi-statute audit evidence is partial.
- Reconciliation infrastructure. Rollup and audit evidence are continuous outputs of the same pipeline.
Approach Comparison
| Capability | Manual Excel | Aggregator-side tool | Reconciliation infrastructure |
|---|---|---|---|
| Order-level deduction trace | Manual, brittle | Automated for Zomato | Automated, multi-source |
| Section 393 TDS posting | Manual schedule | Computed, posting manual | End-to-end |
| Section 52 TCS to cash ledger | Manual GSTR-8A | Computed, claim manual | End-to-end with GSTR-3B utilization |
| GSTR-2B commission ITC match | Out of scope | Often out of scope | Native |
| Section 9(5) classifier | Separate sheet | Optional | Native rule |
| Multi-aggregator (Swiggy, ONDC) | Re-build per aggregator | Separate tool per aggregator | One engine |
| Multi-outlet, multi-GSTIN rollup | Quarterly pivot | Outlet level | Continuous |
| CARO 2020 audit evidence | Reconstructed | Partial | Continuous |
| ERP write-back | Re-keyed | Per-aggregator integration | Native |
Where Each Approach Breaks
Manual Excel breaks at the transition from a single-channel chain to a multi-aggregator multi-state chain — typically around 10 outlets and 6,000 weekly orders. The break is not a feature gap; it is the workflow’s inability to close inside a calendar month.
Aggregator-side reconciliation tools — products in the per-aggregator reconciliation category — solve the Zomato-specific deduction trace cleanly. They break at the platform boundary: the moment the chain adds a second aggregator, a third aggregator, ONDC, direct-channel, or needs the four-rail join (aggregator + POS + bank + tax) for CARO 2020 evidence. Each new source becomes a separate tool, a separate operations contract, and a separate handoff back to finance.
Reconciliation infrastructure starts paying off at the scale where multi-source, multi-statute, multi-outlet rollup is the bottleneck — broadly 30 outlets and ₹2 crore monthly aggregator GMV, with the gap widening as the chain grows. For a config-driven engine that treats restaurant aggregator reconciliation as one preset of many, see restaurant reconciliation software India and the broader payment gateway reconciliation money page.
Buyer-side Evaluation Criteria
A finance leader evaluating between an aggregator-side tool and reconciliation infrastructure should score five criteria explicitly:
- Source coverage — how many aggregators, POS systems, banks, and tax sources the engine handles natively.
- Statute coverage — Section 393 with payment code 1010, Section 52 CGST TCS, Section 9(5), GSTR-2B, GSTR-8A, GSTR-3B all in one engine.
- Multi-outlet, multi-GSTIN rollup at chain, region, state, and GSTIN levels.
- Audit evidence retention — pull-on-demand for any cycle, any outlet, any statute.
- ERP write-back — Tally, SAP, Oracle, NetSuite, Zoho without a separate integration project per aggregator.
For a head-to-head named comparison, see vs Cointab. For the broader pillar, see restaurant reconciliation India and the regulatory walkthrough at Section 393 TDS on restaurant aggregator settlements. For the restaurant chain industry surface, see the Restaurant Chains industry guide.
The questions below address the buyer-side decisions most often raised by finance leaders at multi-outlet QSR chains.