Quick Commerce FMCG Settlement Auditor (Blinkit / Zepto / Instamart)

Section 52 of the CGST Act 2017 empowers e-commerce operators (ECOs) to collect tax at source on the net taxable value of supplies they facilitate, with a statutory ceiling of 1 per cent. The actual notified rate has been moved twice. The rate was originally notified at 1 per cent (0.5 per cent CGST + 0.5 per cent SGST, or 1 per cent IGST for inter-state). The Council reduced the notified rate to 0.5 per cent (0.25 per cent CGST + 0.25 per cent SGST, or 0.5 per cent IGST) with effect from 10 July 2024 via Notification 15/2024-Central Tax. The 1 per cent figure that still appears in older blog posts and vendor guides is the statutory ceiling, not the live notified rate. For settlement audits in 2024 and 2025, the working rate is 0.5 per cent of net taxable value, applied by the ECO at the point of settlement and reported by the ECO in GSTR-8. The brand sees it in GSTR-2A. The calculator above defaults to 0.5 per cent for that reason; you can override only if you have a specific reason to do so (for example modelling a historical settlement before 10 July 2024).

Section 9(5) of the CGST Act 2017 is a reverse-charge mechanism for ECOs that has been notified only for four specific service categories: passenger transport (Notification 17/2017-Central Tax (Rate) clause i), housekeeping services (clause ii), restaurant and cloud-kitchen services (clause iii), and short-stay accommodation (clause iv). Under Section 9(5) the ECO itself becomes liable to pay the GST on the supply as if it were the supplier — Zomato and Swiggy file restaurant supplies in their own GSTR-3B and the restaurant does not. Section 9(5) does not cover goods. Quick-commerce platforms (Blinkit, Zepto, Swiggy Instamart) supply FMCG goods on behalf of brand owners and registered sellers — that is a goods supply, not a notified service category. The applicable provision is Section 52 (TCS at the notified rate, currently 0.5 per cent), not Section 9(5). The brand continues to file its own GSTR-1 and GSTR-3B and pay the GST on the supply; the ECO collects TCS as a tax credit for the brand and reports it in GSTR-8 for reconciliation in the brand's GSTR-2A. A surprising number of internal vendor SOPs still conflate the two — when in doubt, the test is: goods or service. Goods is Section 52. The four notified services are Section 9(5).

The ECO files GSTR-8 monthly by the 10th of the following month. GSTR-8 declares the gross supply value facilitated by the ECO, returns and adjustments, net taxable value, and TCS collected (broken into CGST, SGST, IGST). Once filed, the data flows into the supplier's (brand's) GSTR-2A under the TCS table. The brand reconciles three numbers at month-end: (1) net taxable value declared by the ECO in GSTR-8 versus the brand's own GSTR-1 supplies to that ECO, (2) TCS amount in GSTR-8 versus the cumulative TCS the brand sees on individual settlement files for the month, (3) TCS credit auto-populated in GSTR-2A versus what the brand claims as a tax credit while filing GSTR-3B. The most common mismatch sources are: settlement files dated in the next month but accounted by the ECO in the current GSTR-8, returns and damage debits processed by the ECO after the brand's invoice cut-off, and platform fee / marketing fee invoices raised separately by the ECO that the brand has not booked. The auditor surfaces the TCS amount per settlement file; the GSTR-2A reconciliation is a monthly aggregation step that sits on top.

No — and treating them as one bucket is the largest single source of mis-claimed input tax credit on quick-commerce settlements. A listing fee is a fresh supply by the ECO back to the brand: the ECO is selling space on the platform to the brand and raises a tax invoice on the brand at the applicable GST rate (typically 18 per cent under HSN 998314 — advertising space or 998365 — sales promotion services). The brand books the listing fee as a marketing expense and claims the GST on it as input tax credit. A dark-store visibility fee or marketing debit can fall into either of two categories. When the ECO is selling end-cap, banner, or app-feature placement to the brand, it is the same as a listing fee — fresh supply, separate tax invoice, ITC available to brand. When the ECO is recovering trade-promotion funding from the brand (the brand committed to a buy-one-get-one or slab discount, the ECO ran it at the SKU level, the ECO now claims reimbursement from the brand for units sold) it is a reduction in the original supply value and the correct GST instrument is the brand's Section 34(1) credit note, not a fresh tax invoice. The two paths get conflated in settlement files because the line items look similar. The auditor records both as debits in the rupee math, but the GST treatment row by row is the brand's GST team's call. The Section 34 credit-note path carries a hard 30 November of the following financial year deadline.

Quick-commerce platforms run shorter settlement cycles than traditional marketplaces because the operating model is dark-store inventory turning over at a 10 to 30 minute promise. Typical observed windows are: Blinkit T+7 to T+10 day cycle on EFT settlement, with TCS deducted on the net taxable value at the point of settlement; Zepto T+7 to T+12 day cycle with similar TCS handling and a more granular per-SKU damage debit pattern at the DC level; Swiggy Instamart T+10 to T+14 day cycle aligned with the broader Swiggy settlement infrastructure. The exact contracted window is private to each brand's vendor agreement and the standard practice for fast-moving SKUs is shorter than for slow-movers. If you observe a settlement cycle longer than the chain's typical band for two consecutive cycles without a contractual change, that itself is a reconciliation red flag — the chain is either holding settlement against an open debit dispute, awaiting damage reconciliation from the DC, or has a TCS reconciliation pending. The calculator above reports the cycle band based on platform selection; the actual age comes off the brand's GL once the EFT credits.