Instamart Payment Reconciliation: From Debit Note PDFs to Expected Payment

An Instamart settlement is a net figure with a story hidden behind it. The gross was reduced by a stack of debit notes, each with a code and an amount, and the settlement will not tell you why any of them was raised or which invoice it belongs to.

Reconciling it properly means reconstructing that story — computing what Instamart should have paid against each invoice, and comparing it to what actually arrived. Everything hinges on being able to read the debit notes and map them back.

Start from what should be paid

The anchor is the expected payment, computed per invoice:

Expected payment = Invoice value − valid line-item DNs on its lines − valid overall DNs allocated to it

Actual received is then measured against this. A match closes the invoice; a gap is either an explained deduction or a dispute. The whole exercise is making that comparison possible, and that begins with the debit notes.

The debit note PDF is the source of truth

Instamart's settlement gives you the amount deducted. It does not give you the remark, and the remark is what makes the deduction reconcilable.

Downloading each debit note PDF and reading it is the step most manual processes skip and then regret. The PDF is where you find:

• For a quantity DN — the SKU and the short quantity, matched to the invoice line.
• For a price DN — the rate Instamart applied against the rate expected, checked against your agreed rate on that date.
• For a tax DN — the tax computation, reconciled against the line's GST.

For these, the PDF confirms or contests the deduction against a specific line. For promo and RTV, the PDF is not just confirmation — it is the only thing that lets you map the deduction at all.

Promo and RTV: mapping is the whole job

Promo DNs carry agreed marketing, funding and visibility costs, and Instamart frequently raises them across a campaign or a settlement rather than against one invoice. The settlement will show a promo deduction; it will not show which invoices it covers. The DN PDF names the scheme, the period, and the invoices or SKUs in scope — which is what allows it to be allocated correctly, and what lets you catch a promo DN raised beyond its agreed window or at the wrong percentage.

RTV DNs deduct the value of returned stock. The RTV document references the returned goods and the dispatch or invoice they originated from. Mapping it back is how you confirm the return happened and was valued right. An RTV DN that ties to no genuine return, or is priced wrongly, is contestable — with the document as evidence.

Miss this mapping and promo and RTV deductions simply shrink the payment, indistinguishable from legitimate ones. Do it, and each is either validated against its scheme or return, or flagged.

The payment side is many-to-many

Even with debit notes mapped, Instamart payments do not line up one-to-one with invoices.

• One payment, many invoices. A settlement bundles multiple invoices, net of all their debit notes. It has to be decomposed and each invoice credited its share.
• Many payments, one invoice. An invoice can be settled across cycles, or a reversed deduction paid separately later. Its received total is only known once every fragment is gathered.

Reconciliation therefore links a set of payments to a set of invoices through a set of debit notes. An invoice is closed only when every payment touching it is summed, every DN mapped to it is netted, and the total is checked against the expected payment.

The view that makes it actionable

Zero variance means correct and closed. A gap explained by a valid, mapped DN is closed and documented. A gap that is unmapped or invalid is a live dispute — surfaced as the settlement lands.

Datavio builds exactly this: it ingests each Instamart settlement, downloads and reads the debit note PDFs, maps promo and RTV notes back to their invoices, accumulates split and combined payments, and presents the expected payment against each invoice with the variance computed.

Why it matters

An unmapped deduction is an accepted deduction, whether or not it was correct — and the acceptance was never a decision, just a gap nobody could explain in time. Computing the expected payment per invoice, backed by the DN PDFs, converts that silence into specific, evidenced line items you can either close or chase.

That is the mechanism behind the reconciliation accuracy brands report across quick commerce. Not more effort — a defined expected figure per invoice, every deduction mapped to the document that justifies it, and every gap chased while the window is open.

Questions we get asked