Zepto settles fast and often, each payment already netted by debit notes. Keeping up means computing the expected payment for every invoice as it settles — invoice value minus the DNs actually raised against it — and treating every gap as something to explain before the next cycle lands.
Zepto's settlement cadence is the reconciliation challenge in one word: pace. Payments land frequently, each already reduced by a set of debit notes, and if you only reconcile monthly you are always several cycles behind the deductions. By the time a wrong DN is spotted, more have settled on top of it.
The defence is to compute, for every invoice, what Zepto should pay — and to do it as each settlement arrives, not in a monthly catch-up. That expected figure, checked against what actually came in, is what keeps reconciliation current.
Per invoice:
Expected payment = Invoice value − valid line-item DNs mapped to its lines − valid overall DNs allocated to it
Actual received is then compared against it. The value of computing this per invoice, every cycle, is that a wrong deduction shows up immediately as a variance rather than accumulating unnoticed across settlements.
A Zepto settlement gives the amount of each debit note. It does not give the remark, and the remark is what makes the deduction reconcilable. That detail sits in the debit note PDF.
Downloading and reading each one is what lets you:
For these, the PDF confirms or contests the DN against a line. For promo and RTV, the PDF is the only route to mapping them to an invoice at all — and at Zepto's frequency, that mapping has to keep pace.
Promo DNs carry agreed scheme, funding and visibility costs, often raised across a campaign or settlement rather than one invoice. The settlement shows the deduction; the DN PDF names the scheme, period and invoices or SKUs in scope, which is how it is allocated — and how a promo DN applied past its window or at the wrong rate is caught. Because Zepto settles quickly, an unmapped promo DN compounds fast: several more cycles settle before anyone reconstructs which invoices it covered.
RTV DNs deduct returned-stock value and reference the returned goods and their originating dispatch or invoice. Mapping the RTV back confirms the return and its valuation; one that ties to no genuine return, or is mispriced, is contestable with the document as proof.
Zepto's pace multiplies the usual payment complications:
So each invoice closes only when every payment touching it is summed, every mapped DN netted, and the total checked against the expected payment — a loop that has to run at settlement speed to stay current.
| Field | Source |
|---|---|
| Invoice value | Your invoice |
| Line-item DNs | DN PDFs, mapped to lines |
| Promo / RTV DNs | DN PDFs, allocated to invoice |
| Expected payment | Computed |
| Actual received | All payments touching the invoice |
| Variance | Expected − Actual |
A zero variance closes the invoice. A gap explained by a mapped, valid DN is closed and documented. An unmapped or invalid gap is a dispute — visible the moment the settlement posts, which on Zepto is often.
Datavio runs this at Zepto's cadence: ingesting each settlement, downloading and reading the debit note PDFs, mapping promo and RTV DNs to invoices, accumulating split and combined payments, and showing the expected payment against each invoice with the variance already computed.
On a fast settlement cycle, dispute windows arrive fast too. A wrong deduction caught in the cycle it settled is recoverable; the same one found at month-end has often aged past its window. Computing expected payment per invoice, backed by the DN PDFs, as each settlement lands is what makes the difference between identifying leakage and recovering it.
The reconciliation accuracy brands report on Zepto is the outcome of exactly this discipline — a defined expected figure per invoice, every debit note mapped to its justifying document, and every variance chased while it is still live.
Invoice value minus the valid line-item debit notes (quantity, price, tax) mapped to its lines, minus any valid overall debit notes (promo, RTV) allocated to it. Actual received is compared against this expected figure, ideally each settlement cycle so variances surface immediately.
Because settlements arrive frequently and are already netted by debit notes, monthly reconciliation falls several cycles behind. Computing expected payment per invoice as each settlement lands means a wrong deduction appears immediately as a variance rather than compounding unnoticed.
In the debit note PDF, not the settlement summary. The PDF carries the remark that identifies the reason and, for promo and RTV DNs, the scheme, period or originating dispatch needed to map the deduction to the correct invoice.
Promo DNs, often raised at campaign or settlement level, are allocated using the scheme, period and in-scope invoices or SKUs named in the DN PDF. RTV DNs are tied back via the returned goods and their originating dispatch or invoice referenced in the document.
Yes. Each settlement nets multiple invoices together, so a payment is split back across the invoices it covers. One invoice may also be paid across multiple cycles, making reconciliation a many-to-many match that has to run at Zepto's settlement pace.
Datavio computes expected payment per Zepto invoice after mapped debit notes, at the pace Zepto settles.
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