For every Blinkit invoice there is a number you can compute before any money moves: invoice value minus the debit notes legitimately raised against it. Get that expected figure right and a short payment stops being a mystery and becomes a line you can chase.
Most Blinkit reconciliation starts from the wrong end. The payment arrives, and the team works backwards trying to explain it. A better question runs the other way: given this invoice and the debit notes raised against it, what should Blinkit pay?
That number — the expected payment — is computable. And once you have it, every actual payment either matches it or it does not, and the ones that do not are your entire follow-up list.
For a single invoice, the expected payment is simple to state and surprisingly hard to compute in practice:
Expected payment = Invoice value − (valid line-item debit notes) − (valid overall debit notes allocated to this invoice)
The difficulty is not the subtraction. It is establishing which debit notes are valid and which actually belong to this invoice — and that requires reading the debit notes, not just their totals.
A Blinkit settlement will tell you a debit note exists and give you an amount. That is not enough to reconcile it. The reason a DN was raised — the remark — is what tells you whether it is correct and which invoice line it belongs to.
That remark lives in the debit note PDF, not in the settlement summary. So the first real step is unglamorous: download every DN document, and read what it says.
For these three, the PDF gives you enough to accept or dispute the deduction against a specific line. The two that cause the most trouble are the ones where the PDF is the only way to map them at all.
Promo DNs are marketing, funding and scheme contributions. They are often raised at a settlement or campaign level, not against a single invoice, and the settlement will not tell you which invoices a promo DN relates to. The DN PDF will — it names the scheme, the period, and frequently the invoices or the SKUs in scope.
Without reading it, a promo DN is just an amount reducing your payment. With it, you can check: was this scheme actually agreed, did it run in this period, was the percentage correct, and does it apply to these invoices? Promo DNs raised past the scheme end or at the wrong rate are one of the most common recoverable leaks, and they are invisible unless the PDF is opened and mapped.
RTV DNs net off the value of stock returned to you. The RTV document references the returned goods — SKU, quantity, and the original dispatch or invoice they came from. Mapping an RTV DN back to the invoice it relates to is what confirms the return is genuine and correctly valued. An RTV DN that does not tie back to a real return, or is valued at the wrong rate, is a deduction you can contest — but only once you have the document that proves the mismatch.
This is why, for promo and RTV especially, downloading and parsing the DN PDFs is not optional housekeeping. It is the only way the deduction can be mapped to the invoice at all.
Even with every DN mapped, the payment side has its own complications, and both break naive matching.
One payment against many invoices. A single Blinkit remittance routinely settles a batch of invoices at once, net of the debit notes across all of them. You cannot read it as one payment closing one invoice. It has to be split back across the invoices it covers, each getting its share, before any single invoice can be marked settled.
Many payments against one invoice. The reverse also happens. An invoice may be partly paid in one cycle and the balance in another, or a deduction may be reversed and paid separately later. Until you accumulate every payment touching an invoice, its true received amount is unknown.
So the reconciliation is genuinely many-to-many: a set of payments, a set of invoices, a set of debit notes, all interlinked. Closing an invoice means gathering every payment fragment against it, netting every DN mapped to it, and checking the total against the expected payment.
The output that makes this usable is a single view, per invoice:
| Field | Source |
|---|---|
| Invoice value | Your invoice |
| Line-item DNs (qty, price, tax) | DN PDFs, mapped to lines |
| Overall DNs (promo, RTV) | DN PDFs, allocated to invoice |
| Expected payment | Computed |
| Actual received | Sum of all payments touching the invoice |
| Variance | Expected − Actual |
When variance is zero, the invoice is closed and correct. When it is negative by a mapped, valid DN, it is closed and explained. When it is negative by an unmapped or invalid amount, it is a dispute — and it is visible the moment the settlement lands, not at month-end.
This is what Datavio produces: it ingests the settlement, downloads and reads each debit note, maps promo and RTV DNs back to their invoices, accumulates split and combined payments, and shows the expected payment against every invoice with the variance already calculated.
You cannot chase what you cannot quantify. "The settlement looked a bit short" is not a claim Blinkit will action. "Invoice INV-00412 has an expected payment of ₹1,84,300, we received ₹1,71,900, and the ₹12,400 gap is a promo DN for a scheme that ended before this invoice was raised" is.
The expected-payment calculation is what turns a vague sense of leakage into specific, documented, disputable line items — each mapped to its invoice, each backed by the DN PDF, each chased before its window closes.
Brands running reconciliation this way report 99% accuracy and recover the hours that used to go into reconstructing payments by hand. The accuracy is downstream of one discipline: computing what should have been paid, per invoice, and treating every gap from it as something to explain or recover.
Take the invoice value and subtract the valid line-item debit notes (quantity, price, tax) mapped to its lines, then subtract any valid overall debit notes (promo, RTV) allocated to that invoice. The result is what Blinkit should pay; the actual received amount is then compared against it to find the variance.
The settlement summary gives only the DN amount, not the reason. The remark that identifies which invoice or scheme a debit note relates to — essential for promo and RTV DNs — lives in the DN PDF. Reading it is the only way to validate the deduction and map it to the correct invoice.
Promo DNs are often raised at scheme or settlement level; the DN PDF names the scheme, period and invoices or SKUs in scope, which is how they are allocated to specific invoices. RTV DNs reference the returned goods and their original dispatch or invoice, which is how the return is tied back and its value verified.
Yes. A single remittance routinely settles a batch of invoices net of the debit notes across all of them, so it must be split back across those invoices. The reverse also happens — one invoice may be paid across multiple cycles — making reconciliation a many-to-many exercise of payments, invoices and debit notes.
A gap between the expected payment and the actual received that maps to no valid debit note, or to a DN that is incorrect — such as a promo DN applied after its scheme ended or an RTV DN that does not tie to a genuine return. The DN PDF provides the evidence, and the variance identifies the amount.
Datavio computes the expected payment per invoice after mapped debit notes, so short payments surface the day they land.
Book a demo →
Blinkit pays you two different ways depending on the model, deducts through a stack of debit notes, and settles on its o
Instamart reconciliation is a mapping problem before it is a finance problem. The money arrives net of deductions, on a
Zepto settlements are fast, frequent and netted. That cadence is a good thing for cash — but it means deductions accumul