A single purchase order rarely produces a single invoice. Here is why that happens, what it breaks downstream, and how to model the relationship so reconciliation still closes.
A Blinkit PO lands for 5,000 units across 40 SKUs. By the time it closes, your books carry four invoices against it, two GRNs, a debit note for short supply, and a payment that reconciles cleanly against none of them.
Nobody made a mistake. This is just what a purchase order looks like once it meets a real supply chain.
The trouble is that most finance processes — and almost every spreadsheet — quietly assume a purchase order produces one invoice. When it produces five, the matching logic does not degrade gracefully. It fails silently, and the failure surfaces weeks later as an unexplained short payment.
Four things split a purchase order, and most brands hit at least three of them:
Partial dispatch. You have 3,200 of the 5,000 units in the Bengaluru warehouse. The channel wants the order now. You ship what you have and follow with the balance, and each dispatch carries its own invoice.
Multi-location delivery. A modern-trade PO destined for six distribution centres becomes six shipments, six GRNs, and often six invoices — even though it arrived as one document.
Channel-side invoicing. Some marketplaces generate the invoice themselves on receipt rather than accepting yours. Their invoice numbering has no relationship to your PO reference, so the link has to be reconstructed from SKU, quantity and date.
Mid-cycle rate revisions. A promotional price changes between dispatch one and dispatch three. The same PO now carries two different rates, and the difference will come back as a rate-difference deduction if it is not caught.
The failure is not that the numbers are wrong. It is that the relationship becomes ambiguous, and ambiguity is what makes reconciliation manual.
Ask a simple question of a split PO — has this order been fully received? — and you need to sum GRN quantities across multiple receipts, net off rejections, and compare against the ordered quantity per line, not per order. Do that in a spreadsheet across 200 open POs and it takes a person a full day. It also goes stale the moment a new GRN lands.
The harder question is payment allocation. A single remittance arrives covering parts of three invoices, minus a deduction that references none of them. Somebody has to decide which invoice each rupee belongs to. Get it wrong and two things happen: an invoice sits open that has actually been paid, and another shows settled when it is still short.
That is how brands end up writing off recoverable money. Not through negligence — through arithmetic that nobody has time to redo every week.
The fix is structural. Stop treating the PO as a row in a sheet and start treating it as a parent record with children hanging off it.
Once that structure exists, the awkward questions become trivial. Fill rate per line falls out of it. So does the true outstanding, and so does the evidence pack for a dispute — because you can point at exactly which line, on which dispatch, against which GRN.
This is unglamorous plumbing, and its effect is easy to underestimate until the volume is real.
Bikaji runs 300+ SKUs across 10+ channels, with the document trail split across portals, email and their DMS. Once POs, invoices, GRNs and payments were matched automatically and pushed into SAP, they reached 99% reconciliation accuracy and freed up 60+ hours a week that had been going into chasing and matching.
Limese, distributing beauty and personal care across Nykaa, Zepto and Reliance, hit the same 99% reconciliation accuracy on invoiced-versus-GRN quantities — the specific comparison that multi-invoice POs make so painful by hand.
Neither result came from working harder at the spreadsheet. They came from removing the assumption that a PO has one invoice.
If you want to check whether this is costing you money right now, pull your last 50 closed POs and count how many had exactly one invoice and one GRN. In our experience with brands selling across quick commerce and marketplaces, the answer is usually under half.
Then take the ones that split and check whether the payment reconciles to the line. That gap — between what you believe was settled and what actually was — is the number worth acting on.
Most commonly because of partial dispatch, where stock is shipped in tranches and each tranche carries its own invoice. Multi-location deliveries, channel-generated invoicing and mid-cycle rate revisions also split a single PO into several invoices.
Allocate at the PO line level rather than the invoice level. Each payment is split across the specific lines it settles, with deductions mapped to their own reason codes, so the remaining open balance per line stays accurate even when a single remittance spans several invoices.
Per line. Quantity and rate are agreed at line level, so short supply, rate differences and partial receipts can only be identified accurately per SKU line. Reconciling at the PO header level hides offsetting errors across lines.
We will run a live reconciliation against your open purchase orders and show you exactly where the chain breaks.
Book a demo →Scoring couriers on observed P90 delivery time and landed cost, so dispatch stops running on habit.
What changes operationally when you cross into the GCC — documentation, VAT, Aramex, and reconciling in more than one currency.
A finance view: why the close is too late to find problems, and what a live outstanding position actually requires.