Blinkit Reconciliation: Outright vs Sale-or-Return, and Getting Paid Correctly

Most brands treat their Blinkit payout as a single number that arrives, gets banked, and gets ticked off. That works right up until the number is short, at which point nobody can say which invoice was underpaid, which debit note was legitimate, and which was cut in error.

The reason is that a Blinkit payout is not one number. It is a settlement covering many invoices, net of several kinds of deduction, arriving on a cycle that has little to do with when you raised the invoice. Reconciling it properly means taking it apart and putting each rupee back against the line it belongs to.

Before any of that, you need to know which commercial model you are operating under, because the entire reconciliation shape changes with it.

Outright vs sale-or-return

These are two fundamentally different arrangements, and a brand often runs both at once across different SKUs.

Outright. Blinkit places a PO, takes the stock, and owns it. Once goods are received and a GRN is raised, the sale is done from your side — the units are theirs whether or not they sell through. You invoice against the GRN, and you get paid for the full received quantity, typically on a defined cycle after the GRN date.

The reconciliation chain is PO → GRN → invoice → payment, and the thing you are chasing is their payment against your invoice.

Sale or return (SOR). Here the stock physically sits with Blinkit, but you retain title. You are paid only for units that actually sell. Whatever does not sell comes back to you as a return to vendor (RTV). There is no payment for unsold stock — only a return.

The reconciliation chain is stock placed → units sold → payment for sold units, RTV for the rest, and the thing you are checking is that sold quantity plus returned quantity reconciles back to what you sent, and that you were paid for every unit marked sold.

Blinkit runs primarily outright for most brands, with SOR applying marginally on certain categories or launches. But you cannot assume — the model determines whether an unpaid unit is a collection problem (outright) or simply an unsold one (SOR), and those get resolved in completely different places.

Payment timing runs off the GRN, not the invoice

This trips up brands that come from a traditional distribution background.

Your payment clock does not start when you raise the invoice, and it does not start when you dispatch. It starts when the GRN is posted. Payment then lands a set number of days after that — commonly around 30 days, though the exact terms vary by agreement and can differ by category.

Two practical consequences follow.

First, a delayed GRN is a delayed payment, full stop. If Blinkit's receiving posts the GRN four days late, your money is four days later, and there is nothing in your invoice date that will fix it. This is why chasing GRN posting matters as much as chasing payment.

Second, because payment is GRN-based and batched into settlement cycles, one payment routinely spans multiple invoices raised across different dates. You cannot reconcile it invoice-by-invoice in your head. It has to be decomposed.

The debit note stack

Almost no Blinkit payment arrives at face value. It arrives net of debit notes, and those come in two shapes.

Line-item level debit notes attach to a specific invoice line:

• Quantity DN — you invoiced 500, they received or accepted fewer. The deduction is the quantity gap at the agreed rate.
• Price DN — you invoiced at one rate, they are paying at another. Usually a rate that was revised, a promotional price that should have applied, or a slab mismatch.
• Tax DN — a GST or tax computation difference on the line.

Overall debit notes apply to the settlement rather than to one line:

• Promo DN — agreed promotional or marketing contributions, funding, visibility charges.
• RTV DN — the value of stock returned to you, netted off the payment.

The distinction matters enormously for reconciliation. A line-item DN can and should be validated against the specific invoice line it references — you can prove or disprove it. An overall DN has to be validated against what was agreed — a promo DN for a scheme that ended last month, or applied at a higher percentage than contracted, is exactly the kind of leakage that survives because nobody maps it back.

Why reconciliation has to be line-item

Here is the number that makes this worth the effort: brands routinely see over 10% of invoices either paid late or not fully paid. Not 10% of value in one big miss — 10% of invoices, each short by a little, spread across thousands.

At a header level, that is invisible. The settlement lands, it is roughly the right size, and it gets banked. The shortfall only appears if you reconcile at line level: this invoice, these five lines, this payment, these three debit notes, and a remaining balance of ₹0 — or not.

Knock-offs are the mechanism. A knock-off is the act of allocating a received payment against specific open invoices, line by line, netting the legitimate debit notes, and closing each line only when it fully reconciles. Done properly, every invoice ends in one of three states: fully paid, short by a validated deduction, or short by an unexplained amount — and it is that third bucket that is your recovery pipeline.

The mapping is the hard part. Blinkit's settlement references its own IDs, its debit notes carry reason codes, and none of it natively points at your invoice line. Reconstructing the link — payment to invoice, DN to line, RTV to original dispatch — is tedious by hand and is exactly where line-item reconciliation either happens or quietly gets skipped.

Follow up, or watch it age into a write-off

The final discipline is collection.

An invoice that is short-paid and never chased does not resolve itself. It ages past the dispute window, and once the window closes the shortfall is permanent. This is how brands write off recoverable money without ever deciding to — the decision is made by inaction and a calendar.

Following up requires knowing which invoices are open and why, which is only possible once knock-offs have run. You cannot chase a shortfall you have not identified. So the sequence is fixed: decompose the settlement, knock off line by line, map every debit note to its cause, and then chase every invoice that ends short by an unexplained amount — before the window closes, not at month-end when it already has.

What good looks like

Bikaji reconciles PO, invoice, GRN and payment across 10+ channels into SAP and reaches 99% reconciliation accuracy, recovering 60+ hours a week that had gone into chasing and matching. Limese hit the same 99% accuracy on invoiced-versus-received quantities across Nykaa, Zepto, Noon and Reliance.

The accuracy figure is the visible result. The mechanism underneath it is unglamorous: every payment knocked off against the right invoice line, every debit note mapped to its reason, and every unexplained shortfall chased while it was still recoverable.

Questions we get asked