Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Secondary aggregators like Magicpin and Dunzo run voucher and hyperlocal-delivery models with their own settlement formats, promo accounting, and platform-fee structures — and restaurants accepting them alongside Zomato and Swiggy must reconcile multiple aggregator types to a single revenue book without missing voucher fraud, cashback misallocation, or TCS credit.
Match each aggregator order or voucher redemption to the outlet POS bill via the platform-issued reference ID. For Magicpin, key on voucher code redeemed in the POS tender table. For Dunzo and similar delivery platforms, key on order ID. Derive platform fee, GST on platform fee, and TCS at 0.5% from the settlement file. Book gross revenue with output GST, platform fee with ITC, TCS as a tax credit in GSTR-3B, and reconcile net to the bank credit batch.
Magicpin connector reading voucher redemption settlement file; Dunzo or equivalent hyperlocal connector reading order-level settlement; POS tender-type mapping per platform; TCS-aware GST ledger that posts the 0.5% credit by GSTIN and period; multi-platform consolidated reconciliation.
Per-platform reconciled revenue, voucher-fraud exception list, platform fee with ITC, TCS credits applied to GSTR-3B, and a unified aggregator ledger that ties Zomato, Swiggy, Magicpin, Dunzo, and any regional platform to a single chain-level revenue figure.
A multi-outlet casual-dining group in Pune lists on Zomato, Swiggy, Magicpin, and a regional voucher platform, with Dunzo handling delivery in two markets where it still operates. The bulk of aggregator revenue flows through the two primary platforms, but Magicpin’s voucher redemptions account for ₹18 lakh a month and the secondary platforms together for another ₹6 lakh — small enough to be ignored individually, large enough to matter at year-end. This article is for finance teams running multi-platform aggregator estates that include secondary players alongside Zomato and Swiggy.
What Magicpin and Dunzo Settlement Reconciliation Involves
Magicpin and Dunzo restaurant settlement reconciliation is the process of matching three data sets per platform per settlement period: the POS bill record at the outlet (gross sale, tender type, voucher or order reference), the platform settlement file (gross order or voucher value, platform fee, GST on fee, TCS, refunds, net payout), and the bank credit narration carrying the platform’s payout batch reference. The output is per-platform reconciled revenue with platform fee booked as expense (with ITC where eligible) and TCS booked as a tax credit available in GSTR-3B.
The complication compared with Zomato and Swiggy is twofold. First, the settlement format differs — Magicpin keys on voucher redemption rather than order, and the gross figure is voucher face value rather than menu price. Second, the secondary platforms sometimes issue TCS certificates at lower frequency than monthly, which lags the GSTR-2A reflection and complicates timely ITC and TCS credit claims.
How the Reconciliation Works
Magicpin Voucher Redemption Match
A guest buys a voucher on Magicpin (often at a discount funded by Magicpin) and redeems it at the outlet. The cashier enters the voucher code on the POS, which records a separate tender type. Magicpin’s settlement file lists each redeemed voucher with the code, redemption time, face value, platform fee (typically 8% to 15% of face value), and GST on the fee. The reconciliation matches by voucher code: every Magicpin-side redemption should appear in the POS tender table, and every POS voucher tender should appear in the Magicpin settlement. Mismatches in either direction are voucher exceptions that need outlet-level investigation.
Dunzo Order-Level Match
Where Dunzo operates as a delivery partner, the settlement file is order-level — gross order value, commission (typically 18% to 22%), GST on commission, packaging charge, and net merchant payout. The reconciliation matches each Dunzo order ID to the corresponding aggregator order in the POS, derives commission expense with ITC on the GST component, and ties the net to the bank credit. The flow is structurally identical to Zomato or Swiggy reconciliation; only the field names and timing differ.
TCS Credit Claim
Each platform deducts TCS at 0.5% on net taxable supplies under Section 52 of the CGST Act. The TCS appears in the restaurant’s GSTR-2A and is claimable as a credit in GSTR-3B in the same period. The reconciliation tracks TCS deducted per platform per period, claims the credit, and follows up with the platform if the certificate or GSTR-2A reflection lags. Quarterly TCS certificates from secondary aggregators are accepted but the credit must still be claimed in the month the deduction occurred.
Magicpin and Dunzo Reference
| Platform | Settlement Cycle | Key Match Field | Platform Fee Range | TCS Frequency |
|---|---|---|---|---|
| Magicpin | Weekly to fortnightly | Voucher redemption code | 8% to 15% of face value | Monthly typically |
| Dunzo (where operating) | Daily to weekly | Order ID | 18% to 22% commission | Monthly |
| Zomato | Weekly | Order ID | 18% to 25% commission | Monthly |
| Swiggy | Weekly | Order ID | 18% to 25% commission | Monthly |
| Regional voucher platforms | Fortnightly typical | Voucher code | 5% to 12% | Monthly to quarterly |
India Compliance Angle: Section 52 TCS and Restaurant Supply
Restaurant supply through e-commerce operators is taxed at 5% GST under the e-commerce operator notification, with the operator responsible for collecting and paying GST under Section 9(5) of the CGST Act. TCS at 0.5% under Section 52 is a separate flow that applies on the net taxable value of supplies. The two are often confused — the 5% is output tax paid by the platform on the restaurant’s behalf, while the 0.5% TCS is a tax-on-payment mechanism that creates a credit available to the restaurant in GSTR-3B. Magicpin voucher redemptions where the platform structures the transaction as a voucher rather than a direct supply may follow a different GST treatment depending on the voucher’s classification under Section 12(4) — the platform’s tax invoice carries the determinative position. Restaurants should reconcile the platform’s GST treatment to their own books each period and surface mismatches to the platform’s merchant support.
Finance teams using payment gateway reconciliation tooling can ingest Magicpin, Dunzo, Zomato, Swiggy, and regional aggregator settlements into a single platform that reconciles by platform-issued reference and tracks TCS credits at GSTIN level. Reconciliation software India handles the voucher-based match for Magicpin alongside the order-based match for delivery platforms, with multi-outlet rollup if the chain operates across cities. The GST portal publishes Section 52 TCS rules and the e-commerce operator notification governing restaurant supply.
For the restaurant chain industry surface, see the Restaurant Chains industry guide. For the buying-intent surface covering this rail, see the restaurant reconciliation software for India overview, and for a head-to-head against the aggregator-side reconciliation tool category, see TransactIG vs Cointab.
The following questions address the secondary aggregator settlement issues restaurants in India encounter most frequently.