FMCG and D2C brands selling to Blinkit, Zepto, and Swiggy Instamart face a B2B wholesale-inventory reconciliation problem — 450 to 1,200 POs per month per brand at SKU-level negotiated margins (15–35% off MRP), with damage deductions at the dark-store dock, trade-promotion netting, Section 194Q TDS on purchases above ₹50 lakh, and 30–45 day payment terms — where a 1% margin drift on a top SKU compounds to lakhs of receivable variance per quarter.
Match each quick-commerce payment advice to the originating PO and invoice at SKU level. Validate negotiated margin per SKU per platform against the brand's trade-scheme master. Decompose deductions into categories — trade promotion, damage, short-receipt, return, fill-rate penalty, Section 194Q TDS — and book each to its own GL. TCS Section 52 applies only for marketplace categories (rare for direct-buy FMCG); GSTR-2B captures those credits via the operator's GSTR-8.
Quick-commerce platform adapters (Blinkit, Zepto, Swiggy Instamart), PO and invoice mapping per dark store, SKU-level trade-scheme and margin master, damage and short-receipt classification rules, Section 194Q TDS threshold per buyer, and settlement cycle calendar (T+30 to T+45).
A reconciled B2B receivable ledger per platform with SKU-level margin drift isolated, damage and short-receipt variance quantified per dark store, 194Q TDS credit tracked in Form 26AS, and trade-promotion spend verified against agreed scheme rates — with a board-ready view of net realisation per SKU per platform.
A personal-care FMCG brand sells through Blinkit, Zepto, and Swiggy Instamart across 12 cities. Each platform raises its own POs at negotiated margins off MRP, stocks at dark stores, and pays on T+30 cycles net of damage deductions, promotional spend, and TDS 194Q. One monthly payment from Blinkit covers 280 POs with 14 deduction types. This article is for finance teams at FMCG and D2C brands managing quick-commerce payment reconciliation against ERP POs and invoices.
What Quick Commerce Seller Reconciliation Involves
Quick-commerce seller reconciliation is fundamentally different from marketplace reconciliation. The platform is not a facilitator between the brand and end customer — it is a direct buyer. Blinkit, Zepto, and Swiggy Instamart purchase inventory via PO, take physical possession at dark stores, and sell to consumers under their own GSTIN. The brand’s reconciliation task is B2B: matching platform POs to sales invoices, then matching platform payment advices to outstanding invoices, accounting for deductions along the way.
The India-specific context is the density and speed of the operation. A mid-size FMCG brand can have 150 to 400 POs per month per platform, each PO covering 15 to 40 SKUs shipped to a specific dark store. Across three platforms, that is 450 to 1,200 POs monthly with unique SKU-level margin, promotional spend, and damage deductions. Reconciling at invoice-aggregate level misses per-SKU margin drift — a 1 percent margin error on a top-10 SKU across 200 stores compounds to lakhs in receivable variance within weeks.
How Quick Commerce Payment Reconciliation Works
Matching Platform POs to Brand Sales Invoices
The base layer of reconciliation is PO-to-invoice matching. Each platform raises POs via their buyer portal with SKU, quantity, agreed margin, and expected delivery window per dark store. The brand’s sales team confirms the PO, dispatches goods, and raises a tax invoice with the wholesale price (MRP minus the agreed margin plus applicable GST). The reconciliation engine matches each invoice to its parent PO by PO number, validates the SKU, quantity, and rate per line, and flags exceptions — PO quantity not fully supplied, margin applied differently from the PO, or an unreceived invoice where the PO was raised but no dispatch happened.
Matching Platform Payment Advice to Invoices
The platform’s monthly or fortnightly payment advice lists each invoice being settled with the invoice number, gross value, deductions by category, and net payable. The reconciliation step is to match each line in the payment advice to the brand’s open receivable from that platform, validate the gross equals the invoice total, categorise each deduction (promotional scheme, damage, return, TDS 194Q, other), and post the deductions to the correct GL accounts. A common error is expensing all deductions as a single “platform charges” line, which hides trade promotion spend in the wrong account and distorts both revenue and net margin reporting.
Handling Damage, Return, and Near-Expiry Deductions
Damage and short-receipt deductions are raised at the dark-store receiving dock. The platform’s inbound team inspects each dispatch, records damage or quantity shortage, and generates a debit note against the brand’s invoice. For products nearing expiry, the platform may return stock from the dark store back to the brand’s warehouse and deduct the returned value from the next payment cycle. Reconciliation requires tracking each debit note back to the original PO, validating the damage quantity against the dispatch manifest and third-party quality check reports where available, and booking an inventory write-off or filing an insurance claim where transit damage is the cause.
Quick Commerce Platform Commercial Reference
| Platform | Typical Margin Off MRP | Payment Cycle | Primary Deduction Categories |
|---|---|---|---|
| Blinkit | 18 to 30% by category | T+30 from invoice | Trade scheme, damage, TDS 194Q |
| Zepto | 20 to 32% by category | T+30 to T+45 | Damage, return, fill-rate penalty |
| Swiggy Instamart | 20 to 30% by category | T+30 typical | Scheme spend, damage, expiry return |
| BigBasket (Dark Store model) | 18 to 28% by category | T+30 to T+45 | Scheme, damage, TDS 194Q |
India Compliance Angle: TDS 194Q and GST Treatment
TDS Section 194Q applies when the platform’s aggregate purchases from a single brand in a financial year exceed ₹50 lakh. At that threshold, the platform deducts 0.1% TDS on the excess amount over ₹50 lakh and files the deduction in the quarterly 26Q return. The brand claims this TDS credit in Form 26AS and in the income tax return. Brands with multi-platform quick-commerce presence routinely cross the ₹50 lakh threshold with each platform individually — reconciliation must track 194Q deductions per buyer (platform) because the threshold is per-deductor, not aggregate across buyers.
GST treatment follows the wholesale model. The brand issues a tax invoice to the platform with 18%, 12%, 5%, or 0% GST depending on the SKU, split as CGST + SGST for intra-state deliveries and IGST for inter-state deliveries (where the dark store is in a different state from the brand’s dispatching warehouse). The platform claims ITC on the invoiced GST. For GSTR-1 reporting, these are B2B supplies shown at invoice-level detail in Table 4A, not B2C aggregated rows.
For brands comparing quick-commerce reconciliation against their marketplace operations on platforms like Flipkart or Meesho, the structural difference is commercial: quick-commerce is wholesale (B2B invoicing) and marketplace is facilitation (B2C with operator TCS). Payment gateway reconciliation pipelines can handle both by treating each platform as a distinct counterparty with its own matching rules, though the data sources (POs vs. orders) and deduction taxonomies differ. Using reconciliation software India brands operate with that supports per-SKU margin tracking avoids the compounding error from aggregate-level matching. The GST portal is the source of truth for TCS credits where any quick-commerce SKU category operates in marketplace mode.
The following questions address the reconciliation issues FMCG and D2C brands selling into quick-commerce encounter most often.