Instamart reconciliation is a mapping problem before it is a finance problem. The money arrives net of deductions, on a GRN-linked cycle, referencing IDs that mean nothing to your ledger — and until you map it back, you cannot tell a fair deduction from a wrong one.
Ask a finance team what their Instamart short-payment rate is and most cannot answer. Not because the data is missing, but because the payment that arrived was a single settlement, the deductions inside it referenced Swiggy's own IDs, and nobody has mapped that back to the invoices it was supposed to close.
That mapping gap is the whole game. Everything downstream — spotting a wrong deduction, chasing an unpaid invoice, closing the books cleanly — depends on first reconstructing which payment settled which invoice line, and which debit note came off which one.
The first thing to establish for any SKU is which commercial model it runs on, because it changes what an unpaid unit even means.
Outright. Instamart raises a PO and takes ownership of the stock. Once received and a GRN is posted, the transaction is complete from your side and you are paid for the full received quantity — sold or not. You invoice against the GRN. The chain is PO → GRN → invoice → payment, and your job is to collect their payment against your invoice.
Sale or return (SOR). The stock sits with Instamart but title stays with you until a unit sells. You are paid for sold units only; the rest returns to you as RTV. There is no payment to chase for unsold stock — there is a return to reconcile. The chain is stock placed → sold vs returned → payment for sold, RTV for the rest, and your check is that sold plus returned equals what you sent, and that every sold unit was paid.
For most brands Instamart is predominantly outright, with SOR applying at the margins on select categories. The reason this matters: under outright, an unpaid unit is a collection issue you chase; under SOR, an unpaid unit may simply be unsold, and chasing it is wasted effort. Reconciling without knowing the model produces exactly this kind of misdirected follow-up.
Payment timing keys off the GRN, not the invoice and not the dispatch.
Once Instamart's receiving posts the GRN, the payment cycle begins — with settlement landing a defined period afterwards, often in the region of 30 days but dependent on your terms and category. The invoice date is almost incidental to when you get paid.
Two things fall out of this:
Instamart settlements arrive net of debit notes, and telling a fair one from a wrong one requires knowing the type.
Line-item debit notes reference a specific invoice line:
Overall debit notes apply across the settlement:
A line-item DN is checkable: you can hold it against the exact invoice line and confirm the quantity gap or rate difference is real. An overall DN is checkable only against the agreement — and promo DNs applied beyond their agreed window or percentage are one of the most common quiet leaks, precisely because they are not tied to a line anyone verifies.
The number worth internalising: brands frequently run 10%+ of invoices late or short. Spread thinly, invoice by invoice, it never shows up in the settlement total — the payment looks about right and gets banked.
A knock-off is how you find it. You allocate the received payment to specific open invoices at line level, net the legitimate debit notes, and close a line only when it fully reconciles. Every invoice then resolves to one of three states: paid in full, short by a validated deduction, or short by an unexplained amount. That last state is money you can still recover — if you know it exists.
The obstacle is the mapping, and on Instamart it is real. The settlement speaks in Swiggy's transaction IDs; the debit notes carry reason codes; the RTV references its own return document. None of it natively points at your invoice line. Rebuilding those links — payment to invoice line, DN to line, RTV to dispatch — is where reconciliation is either done or skipped, and it is too much manual matching to sustain by hand at volume.
This deserves its own point because it is the crux of the whole exercise.
A deduction that maps cleanly to a line — this quantity DN against this invoice line, where you can see 500 invoiced and 480 accepted — is one you either accept as correct or dispute with evidence. A deduction that maps to nothing is one you have no basis to challenge and no basis to accept; it simply reduces your payment and disappears into net revenue.
Getting the mapping right ensures the correct DNs are deducted and the incorrect ones surface. Without it, a price DN applied at the wrong rate, or a promo DN run past its scheme end, settles silently. With it, the wrong ones stand out because they fail to reconcile against the line they claim to belong to.
Once knock-offs have run, you know which invoices are open and why. Now the follow-up matters.
An unexplained short payment that is not chased ages out of the dispute window and becomes a permanent write-off. The collection is not optional housekeeping; it is the step that turns identified leakage into recovered cash. And it can only happen after reconciliation, because you cannot follow up on a shortfall you have not yet isolated.
Brands that run this well — Limese across Nykaa, Zepto, Noon and Reliance, Bikaji across 10+ channels into SAP — report 99% reconciliation accuracy and, in Bikaji's case, 60+ hours a week returned. The headline is accuracy; the substance is every Instamart payment decomposed, every debit note mapped to its line, and every unexplained shortfall chased while it was still live.
Predominantly outright for most brands — Instamart raises a PO, takes ownership and pays for the full received quantity after GRN. Sale or return (SOR), where you are paid only for sold units and the rest returns as RTV, applies marginally on select categories. The model determines whether an unpaid unit is a collection issue or simply unsold.
By the GRN date. The payment cycle starts when Instamart posts the GRN, with settlement landing a defined period afterwards — often around 30 days depending on terms and category. The invoice date does not drive it, so a delayed GRN directly delays payment.
Because settlements reference Swiggy's own transaction IDs and debit note reason codes rather than your invoice lines. Until each payment and deduction is mapped back to the specific invoice line it relates to, you cannot distinguish a correct deduction from a wrong one, or identify which invoices are short.
Line-item DNs tied to an invoice line — quantity DN, price DN and tax DN — and overall DNs applied across the settlement — promo DN and RTV DN. Line-item DNs are validated against the invoice line; overall DNs against the agreed scheme terms.
By allocating each payment and debit note to specific invoice lines, a deduction that does not reconcile against the line it claims to belong to fails to close cleanly and surfaces as an exception. Without line-item knock-offs, a wrong rate or an expired promo deduction simply reduces the net payment unnoticed.
Datavio links Instamart payments and debit notes to your invoice lines automatically, so wrong deductions surface instead of settling.
Book a demo →
Deductions are not fraud and they are not all disputable. Knowing which category you are looking at, and what evidence i
Outright vs SOR on Blinkit, how payments land against GRN, the debit note stack, and why knock-offs have to happen at line level.
Outright vs SOR on Zepto, GRN-linked settlement timing, validating debit notes, and knocking off every payment at line level.