Zepto settlements are fast, frequent and netted. That cadence is a good thing for cash — but it means deductions accumulate quickly and quietly, and the only defence is reconciling every settlement down to the invoice line before the next one lands.
The challenge with Zepto reconciliation is rarely any single settlement. It is the pace. Settlements come frequently, each one netted down by a set of deductions, and if reconciliation runs monthly it is always weeks behind the payments. By the time a wrong deduction is spotted, several more cycles have settled on top of it.
Keeping up means reconciling at the cadence the settlements arrive, and at the granularity the deductions live — which is the invoice line. Everything below is that playbook.
Zepto, like the others, operates two commercial models, and reconciliation forks completely depending on which one a SKU sits under.
Outright. Zepto issues a PO and buys the stock. After receipt and GRN, the sale is complete from your side; you are paid for the full received quantity irrespective of sell-through, and you invoice against the GRN. Chain: PO → GRN → invoice → payment. You are collecting their payment against your invoice.
Sale or return (SOR). Stock sits with Zepto, title stays with you, and you are paid only for what sells. Unsold units return as RTV. Chain: stock placed → sold vs returned → payment for sold, RTV for the rest. You are checking that sold plus returned ties back to what you sent, and that every sold unit was paid.
Zepto is mostly outright for brands, with SOR at the margins. Establish this first, because under outright an unpaid unit is chased as a collection gap, while under SOR the same unit may just be unsold — and reconciling without the distinction sends your team chasing money that was never owed.
Payment does not key off your invoice. It keys off the GRN.
Once Zepto posts the GRN, the payment clock starts, and settlement follows a defined number of days later — often in the 30-day region, though it depends on your terms. Because Zepto settles frequently, a single settlement still bundles multiple invoices and GRNs from different dates, so it can never be read as one invoice against one payment.
Watch the GRN posting itself. A late GRN pushes the payment out by exactly that delay, and no invoice-side action recovers it. Monitoring GRN latency is part of protecting your payment timeline, not a separate task.
Every Zepto settlement lands net of debit notes, and the type tells you how to validate it.
Line-item debit notes hang off a specific invoice line:
Overall debit notes apply to the whole settlement:
The validation route differs by type. Line-item DNs are provable against the referenced invoice line — you can confirm the quantity gap or the rate difference is genuine. Overall DNs are only provable against the agreement, which is why an over-applied promo DN or one that outlived its scheme slips through so easily. It is not attached to anything a person routinely checks.
Here is the figure that justifies the discipline: brands regularly see more than 10% of invoices paid late or short. Individually small, collectively significant, and completely invisible in a settlement total that looks about right.
A knock-off is the fix. Allocate each settlement to specific open invoices at line level, net the valid debit notes, and close a line only when it reconciles to zero. Every invoice then lands in one of three states — paid in full, short by a validated deduction, or short by an unexplained amount. The unexplained bucket is your recoverable money, and it does not exist as a visible number until you have done the knock-off.
The friction is the mapping. Zepto's settlement references its own IDs; debit notes carry reason codes; RTV points at return documents. None of it natively names your invoice line. Rebuilding those links at Zepto's settlement frequency is more matching than a team can do by hand and stay current — which is why, done manually, it slips to monthly and falls behind.
Correct mapping is what ensures the right debit notes are deducted and the wrong ones are caught.
When a quantity DN maps to an invoice line showing 500 invoiced and 470 accepted, you can see it is fair and accept it. When a price DN maps to a line where the rate matches your agreed rate, it fails to reconcile and surfaces as an exception to dispute. Without the mapping, both settle identically — as a smaller net payment. The entire value of reconciliation is that correct and incorrect deductions stop looking the same.
Reconciliation identifies the short invoices. Collection recovers them. The two are different jobs and both are necessary.
An unexplained short payment left unchased ages past its dispute window and converts into a silent write-off — a decision nobody made, enforced by a calendar. Because Zepto settles quickly, windows arrive quickly too, which is the strongest argument for reconciling at pace: the faster the cycle, the less time you have to catch and chase a wrong deduction.
Brands that run this properly report the outcome as accuracy — Bikaji at 99% across 10+ channels into SAP, with 60+ hours a week recovered; Limese at 99% across Nykaa, Zepto, Noon and Reliance. Underneath the number is the same loop repeated every cycle: decompose the settlement, knock off to the line, map every debit note, and chase every unexplained shortfall while it is still collectable.
Mostly outright for brands — Zepto issues a PO, buys the stock 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 at the margins. The model decides whether an unpaid unit is chased as a collection gap or treated as unsold.
From the GRN. The payment cycle begins when Zepto posts the GRN, with settlement following a defined number of days later, often around 30 depending on terms. The invoice date does not drive payment, so a delayed GRN directly delays the money.
Because settlements arrive quickly and each is netted by deductions, monthly reconciliation is always several cycles behind. Wrong deductions accumulate before they are caught, and dispute windows arrive sooner — so reconciliation needs to run at the pace settlements land, at invoice-line granularity.
Line-item DNs tied to an invoice line — quantity DN, price DN and tax DN — and overall DNs across the settlement — promo DN and RTV DN. Line-item DNs are validated against the invoice line; overall DNs against the agreed scheme.
By allocating each payment and debit note to specific invoice lines, a deduction that does not reconcile against its claimed line fails to close and surfaces as an exception. Without line-item knock-offs, a wrong rate or an expired promo deduction simply reduces the net settlement unnoticed.
Datavio reconciles each Zepto settlement to the invoice line automatically, so deductions never outrun your finance team.
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.
Why Instamart reconciliation is a mapping problem, how payments link to GRN, and the debit note types you validate against invoice lines.