Partial Delivery Invoice Matching: Multi-GRN Guide

Partial delivery and multi-GRN invoice reconciliation tracks one purchase order against several goods received notes and one or more supplier invoices using a long-format table with cumulative-received and cumulative-billed running balances. When an invoice does not break out which delivery it is billing, AP teams apply a documented FIFO or pro-rata allocation policy. The un-invoiced-received balance — cumulative received minus cumulative billed — is the GRNI position at any point in time.

That is the structural answer most three-way-matching pages skip. The textbook diagram of one PO, one GRN, and one invoice compared line by line — the baseline extraction of PO, GRN, and invoice data into a single comparison spreadsheet — assumes a world that is cleaner than the one most AP teams work in. The variant that actually lands on your desk is partial delivery invoice matching: one purchase order satisfied by three or four goods received notes across weeks of staged deliveries, and billed through either a string of progressive invoices or a single consolidated invoice covering everything received in the period.

The teams that hit this routinely are not unusual: construction and contractor AP running progressive billing against project POs, manufacturing AP working blanket POs with kanban or JIT receiving, grocery and FMCG bookkeepers handling daily split deliveries, wholesale and distribution AP fulfilling back-orders in batches, and hospitality central bookkeeping consolidating multi-site receiving against single supplier POs.

Scope: one PO, multiple GRNs, one or more invoices. The simpler two-document case lives in two-document delivery-note to invoice matching, and readers who need the baseline concept first should start with canonical two-way, three-way, and four-way invoice matching.

The Long-Format Reconciliation Table

The design principle is that each row records one event — one receipt or one invoice line — against one PO line, rather than one row per PO line with deliveries and invoices crammed into appended columns. Long format keeps many-to-many honest because the row grain matches the event grain. Add a GRN, add a row. Add an invoice line that touches the PO line, add a row. Multi-GRN reconciliation stops being a column-juggling exercise and becomes a straightforward append.

The schema breaks into four blocks of columns plus a block of computed columns.

Composite keys — the columns that uniquely identify a row and let you sum within scopes:

• PO number
• PO line number
• Supplier code
• Item code or SKU
• Unit of measure
• Receipt-event sequence (1, 2, 3, ...)
• Invoice-event sequence

PO header columns — carried on every row for the line so summaries and filters work without joins:

• PO date
• PO line description
• PO line quantity ordered
• PO line unit price
• PO line authorised total

Receipt columns — populated on rows that represent a GRN touching this PO line:

• GRN number
• GRN date
• Quantity received this GRN
• Cumulative quantity received
• Variance from cumulative ordered

Invoice columns — populated on rows that represent an invoice line touching this PO line:

• Invoice number
• Invoice date
• Quantity billed this invoice
• Cumulative quantity billed
• Line unit price billed
• Line value billed

Computed columns — derived from the keys and the running totals, recalculated whenever a row is added:

• Open quantity (PO ordered minus cumulative received)
• Un-invoiced received (cumulative received minus cumulative billed)
• Over-delivered flag (cumulative received greater than PO ordered)
• Over-billed flag (cumulative billed greater than cumulative received)
• Price-variance flag (invoice unit price not equal to PO unit price within tolerance)

Un-invoiced received is the GRNI position at any point in time for that PO line; month-end accrual reads the same column rather than a separate ledger. The accounting side lives in the dedicated piece on GRNI reconciliation and month-end accrual.

Receipt-event sequence is what distinguishes two GRNs against the same PO line. Without it, cumulative-received cannot sum deterministically and allocation has nothing to anchor against.

A Worked Example: PO 100 Units at $5, Three GRNs, Two Invoices

The arithmetic is easier to follow on a concrete case. Take a PO line that authorises 100 units at a unit price of $5, for a line authorised total of $500. The supplier code, item code, and unit of measure stay constant; only the receipt and invoice events change as the line runs.

Five events land against the line, interleaved:

1. GRN 1 receives 30 units. Cumulative received: 30. Cumulative billed: 0. Open quantity: 70. Un-invoiced received: 30 — that is the GRNI exposure on this line as soon as the first delivery is on the dock.

2. GRN 2 receives 40 units. Cumulative received: 70. Cumulative billed: 0. Open quantity: 30. Un-invoiced received: 70. The exposure is climbing because the supplier has delivered more without yet invoicing.

3. Invoice 1 bills 60 units at $5, value $300. Cumulative billed: 60. Cumulative received unchanged at 70. Un-invoiced received: 10 (70 minus 60). Open quantity unchanged at 30 — the invoice does not consume any of the PO's open authorisation, because open quantity tracks against ordering, not billing.

4. GRN 3 receives 30 units. Cumulative received: 100. Cumulative billed: 60. Open quantity: 0 — the line is now fully received. Un-invoiced received: 40 (100 minus 60). Open PO remaining quantity tracking shows zero open on the line, but the line is not closed yet; invoicing still has 40 units to catch up.

5. Invoice 2 bills 40 units at $5, value $200. Cumulative billed: 100. Cumulative received: 100. Open quantity: 0. Un-invoiced received: 0. The line reconciles: cumulative received equals cumulative billed equals PO ordered, and the line authorised total has been fully invoiced at the agreed unit price.

Two things to notice in the walk. Open quantity tracks PO ordering, not invoicing — open-PO remaining-quantity tracking falls only when goods are received, which keeps the procurement signal honest for the buyer reading the column. Un-invoiced received oscillates: it climbs when a GRN lands without a matching invoice, falls when an invoice catches up against earlier receipts, and returns to zero only when cumulative billed equals cumulative received.

Allocation Logic When the Invoice Doesn't Break Out Which Delivery It Bills

The worked example was clean because each invoice billed a quantity that happened to align neatly with prior receipts. Most real supplier invoices are not that cooperative. The line reads "100 units at $5" and carries no GRN number, no delivery date, no receipt reference — just a quantity and a price. The AP team has to decide, every time, how to map that invoiced quantity onto the GRN rows it actually corresponds to. The choice is allocation, and the choice has to be the same one every time.

Two strategies cover almost every case.

FIFO allocation assigns the invoiced quantity to the earliest un-invoiced GRN rows first, in receipt-event-sequence order. Take the worked example with the numbers shifted: GRN 1 has 30 un-invoiced units, GRN 2 has 40 un-invoiced units, and an invoice arrives billing 60 units. FIFO consumes all 30 from GRN 1, then 30 from GRN 2, leaving 10 un-invoiced on GRN 2 and zero on GRN 1. FIFO is the right default for fungible goods where the physical order of receipt does not materially differ from one batch to the next, and where the team needs a policy a Power Query step can express in a single sort and a running consumption. FIFO allocation invoice to GRN works cleanly for stock items, components, raw materials, and any case where what arrived in shipment one is functionally equivalent to what arrived in shipment two.

Pro-rata allocation splits the invoiced quantity proportionally across all GRN rows that fall within the invoice's billing period. With the same setup — three GRNs in the period received 30, 40, and 30 units, total 100 — an invoice billing 60 units assigns 18 units to GRN 1, 24 units to GRN 2, and 18 units to GRN 3. Pro-rata fits period-billed and consolidated-invoice patterns where the supplier is not implicitly identifying any specific delivery: the invoice covers the period, the deliveries within the period are all in scope, and the split should reflect what was actually received rather than what arrived first.

Both strategies need to match one invoice to multiple GRNs in a way that the reconciliation can defend at audit, which is the point worth being direct about: allocation is a policy choice the spreadsheet supports but does not make. The AP team has to pick FIFO or pro-rata, write it down as a documented policy, and apply it consistently — at minimum within a supplier, ideally across the whole AP function. A reconciliation that uses FIFO for some invoices and pro-rata for others, or that switches policy based on whichever number balances easier, will not produce a defensible un-invoiced-received balance at month end.

Both policies express deterministically in a spreadsheet formula set, a Power Query step, or a BI-tool calculation — FIFO as a sort by receipt-event sequence and a running consumption of un-invoiced quantity, pro-rata as a period-bounded sum and a proportional split by row.

The opposite direction — one supplier invoice that spans multiple POs rather than the multi-GRN-against-one-PO case here — is its own allocation discipline with its own rules and its own pitfalls. Readers whose actual case is the inverse case: one supplier invoice spanning multiple POs should work from that piece instead.

Progressive Billing and Consolidated Billing: Same Schema, Different Cadence

The allocation strategy you reach for is shaped less by the goods being received than by how the supplier chooses to bill. Two patterns cover most of the field, and most AP teams work with both somewhere in their supplier base.

Progressive billing means each invoice covers a specific period, a specific milestone, or a specific set of deliveries the supplier has chosen to bill in this cycle. Some deliveries within a cycle may not be billed yet. Some may end up billed across two invoices when the supplier closes the cycle differently from how the receipts landed. Progressive billing invoice matching is the default cadence in construction, where interim payment applications run every two weeks or monthly against a project PO, and it shows up in mid-cycle B2B services where the supplier raises an invoice at each agreed milestone rather than at the end of the engagement.

Consolidated billing means one invoice per period — typically a week, sometimes a month — covering every delivery the supplier made in that period. The invoice arrives as a roll-up: a long list of line items, often by SKU rather than by delivery, with a single header date that bears no relationship to any individual goods receipt. Consolidated invoice multiple deliveries reconciliation is the working pattern in grocery and FMCG, where daily deliveries against a single weekly purchase order roll into a Friday-dated statement-style invoice. It is also common in industrial distribution where the supplier prefers one billing cycle per customer per period rather than per-delivery invoicing.

The long-format schema does not change between the two. The columns are identical. What changes is the row count: progressive billing tends to produce more invoice rows per PO line, each smaller; consolidated billing tends to produce fewer, larger invoice rows. The natural default for allocation also tends to shift — FIFO often fits progressive billing because each invoice is implicitly billing the deliveries that landed before the cycle closed, while pro-rata often fits consolidated billing because the supplier is billing the period rather than any subset of deliveries. The natural default is not the policy, though. Document the choice; do not infer it from the billing pattern and hope.

Under progressive billing, the un-invoiced-received balance oscillates as deliveries land between invoice cycles. Month-end accrual has to read the column at point in time, not at a smoothed average across the month, or it will misstate GRNI exposure in both directions.

Under consolidated billing, a single missed or delayed invoice cycle can leave a large un-invoiced-received balance that masks individual delivery exceptions. A short shipment buried inside a hundred-line roll-up invoice can sit on the un-invoiced-received column for weeks if nobody reads line by line — the visibility is in the row grain.

FMCG cases often compound partial delivery with catch-weight, which the long-format schema absorbs by adding a weight column alongside quantity; the dedicated piece on catch-weight reconciliation for variable-weight FMCG deliveries works that through end to end.

Exception Cases That Only Appear Once the World Stops Fitting on One Row

Multi-receipt reconciliation has its own family of exceptions. None of them appear in the clean one-PO-one-GRN-one-invoice case, because none of them are detectable until you have cumulative columns to compare against PO-level totals.

Cumulative over-delivery. No single GRN exceeds the PO line ordered quantity, but the sum across receipts does. A PO authorising 100 units is satisfied by three GRNs of 35, 40, and 30 units — cumulative received lands at 105, five units over. The over-delivered flag triggers on the computed column rather than on any individual receipt, which is the only place it could trigger. This is a common back-order partial fulfilment AP case: the supplier ships the back-ordered remainder plus a small over-supply they were quietly hoping the buyer would accept. The decision is whether to return the surplus, accept it and ask for a credit on quantity, or absorb it.

Cumulative under-billing. Cumulative received exceeds cumulative billed at PO close and no further invoice arrives. The line is fully received, the PO closes from a procurement standpoint, and the un-invoiced-received column sits at a positive number that never returns to zero. This is positive AP exposure the team should raise with the supplier rather than absorb — you have goods you have not been billed for, and quietly recognising them as a windfall is not defensible at audit. The un-invoiced-received figure at PO close is the figure to chase.

Final-delivery shortfall. The last expected GRN arrives — the supplier has flagged it as the final shipment against the PO — and cumulative received is still below PO ordered. The decision splits two ways: chase the supplier for the remainder, or close the PO short and write down the open quantity as cancelled. This is distinct from a back-order still in flight, where the open quantity is still expected to arrive on a later delivery. Shortfall is the supplier's stated final delivery being short of what was ordered, which is a different conversation from a delivery that has not happened yet.

Mid-stream price changes. The supplier changes unit price between GRNs — sometimes by agreement, sometimes by invoicing at a list price that has updated since the PO was raised. The line-unit-price column on each invoice row holds the actual billed price, not the PO's authorised price, and the price-variance flag triggers per invoice row rather than per PO line. The cumulative quantity may match perfectly at PO close while the line value billed exceeds the PO line authorised total, because the running average billed price has drifted upward. Catching this requires the per-row price column; a reconciliation that only carries quantity will miss it.

Line-level mismatches between a single invoice and its PO — the price or description on one invoice line not matching the corresponding PO line on a one-shot, one-receipt purchase — are a related but distinct exception type the article does not deep-cover. Readers working that case should refer to line-level mismatches between an invoice and its PO for the single-invoice-single-PO dispute discipline.

What Each Extraction Has to Surface for the Long Format to Hold

None of the reconciliation above runs unless the three input documents land in the table as rows. Each document type has its own set of fields, and each has its own gotchas at the extraction stage.

Purchase orders. The fields the long-format table needs are PO number, PO date, supplier code, line number, item code or SKU, line description, unit of measure, quantity ordered, unit price, and line authorised total. POs are usually the cleanest of the three to extract because they originate in-house, on a known template, in a controlled format. The point worth being precise about is preserving the header-versus-line distinction on extraction: PO header fields (PO number, PO date, supplier code) belong on every row of the line, and PO line fields (line number, item, quantity, price) belong on the line they describe. A flat extraction that loses that distinction collapses the schema before the GRN rows even arrive.

Goods received notes. The fields needed are GRN number, GRN date, the PO number being received against, the PO line number per row, item code, unit of measure, and quantity received this GRN. The pivot — the field that does the work the rest of the schema cannot do without — is the receipt-event-sequence key. The GRN number alone is not enough, because two GRNs can hit the same PO line in close succession with sequential numbers that mean nothing to the cumulative-received calculation. Extraction has to emit each GRN as a distinct row keyed by both PO line and a sequence that lets cumulative-received be summed deterministically across the receipt events in order. The dedicated coverage on extracting GRN line items with the receipt-event-sequence key works through what that means for the parsing stage.

Supplier invoices. The fields needed are invoice number, invoice date, supplier code, line number, item code or SKU, description, quantity billed this line, line unit price, line value, and — where present — a PO reference and a GRN reference. The pain point on this document is variability: invoices come from the supplier's system, on the supplier's template, with the supplier's choice of what to break out and what to consolidate. Many supplier invoices do not include a PO-line reference, and even fewer include a GRN reference.

That gap turns into work upstream of the long-format table. When the PO-line reference is missing, the team needs a mapping rule to identify which PO line each invoice line corresponds to — typically by SKU plus unit price, by description match against the PO line description, or by a supplier-side item code the buyer has mapped to its own item master. When the GRN reference is missing, the invoice line lands in the table against the right PO line but with no implicit allocation, and the FIFO or pro-rata policy from the allocation section runs to assign invoiced quantity to specific receipt rows.

Supplier-invoice variability is the most demanding of the three extractions because it depends entirely on what the supplier's system chose to emit, not on what the buyer's system would prefer. POs and GRNs originate inside the buyer's process, where the template can be standardised. Invoices arrive from the outside, and the long-format table has to absorb whatever shape they take.

Industry Variants: Construction Progressive Billing and Manufacturing Kanban

Two industries skew heavily toward multi-receipt reconciliation as their default, and each names the documents involved differently enough that a reader from outside the industry will not always recognise the equivalent fields.

Construction progressive billing. The PO is often a subcontract, a framework purchase order, or a project-level call-off rather than a one-off purchase order. The document the supplier sends in place of an invoice is frequently a payment application or a progress payment certificate — itemised against work completed and goods delivered to date, sometimes certified by a quantity surveyor before payment. The goods receipt surrogate varies: for materials, a delivery ticket plus a foreman sign-off on site; for services within a construction contract, the service entry sheet workflow for services progress billing plays the equivalent role. The cadence is interim — typically every two weeks or monthly, sometimes tied to defined milestones. The long-format schema absorbs construction progressive billing PO GRN invoice flows without modification; the rows are simply more numerous and smaller per cycle than a one-shot delivery would produce.

The interim cadence is not purely commercial preference. Under UK law, a party to a construction contract is entitled to payment by instalments, stage payments, or other periodic payments unless the work is specified or agreed to take less than 45 days — the statutory basis for progressive billing on construction POs. That is Section 109 of the UK Housing Grants, Construction and Regeneration Act 1996, which is why most UK construction contracts default to interim payment cycles whether or not the parties have negotiated specific milestones.

Manufacturing kanban and JIT. The PO is typically a blanket PO with a release schedule — a single authorisation covering, for example, 10,000 units of a component over the next quarter, with release quantities and dates either fixed in advance or pulled on demand. Each release, each kanban pull, each call-off order produces a GRN against the same blanket PO line. The supplier consolidates billing weekly or monthly rather than invoicing per release. Blanket PO release invoice matching reads naturally as long-format: the blanket PO line is one PO row of header data, every release adds a receipt row keyed by the release date and sequence, and each consolidated invoice line lands as one or more invoice rows allocated by the team's documented policy.

The manufacturing variant has enough of its own conventions — release scheduling, supplier-managed inventory triggers, contract-quantity tolerances — that re-deriving them here would duplicate the dedicated coverage. Readers working a manufacturing AP function should consult blanket PO and partial-shipment matching in manufacturing for the industry-specific mechanics; the long-format schema in this article is the data shape underneath.

Tooling Fit: Spreadsheets, AP Automation Tools, and Extraction + Spreadsheet

The reconciliation discipline above has to run somewhere. Three shapes are realistic, and each has a different breaking point.

Excel with Power Query, or Google Sheets, or a BI tool. Works to a real point if the long-format discipline is enforced from the first row entered. Power Query implements FIFO and pro-rata allocation as deterministic steps, and pivot tables roll the cumulative columns up by supplier, project, or item code. The shape fails on two axes: volume (at tens of thousands of receipt rows per month, responsiveness drops and the team starts archiving into separate workbooks, fragmenting the un-invoiced-received view) and concurrency (the canonical reconciliation file becomes a bottleneck the moment more than one person needs to update it during close).

AP automation tools that claim multi-GRN match. Many vendor products list multi-GRN matching as a feature, but the UI is often a sequence of two-way matches per receipt event rather than a long-format reconciliation holding every row from PO open to PO close. The allocation policy hides inside the tool's match logic rather than being expressed as a documented choice. The stress test before signing the contract: feed the demo a one-PO, three-GRNs, one-consolidated-invoice case where the invoice does not break out delivery, and watch whether the tool surfaces the allocation choice or silently picks one. Silent allocation means losing control of the most defensible part of the reconciliation.

Extraction plus spreadsheet workflow. Extract POs, GRNs, and supplier invoices into the long-format schema directly, then run reconciliation in the spreadsheet or BI layer with FIFO or pro-rata allocation expressed explicitly as a Power Query step, formula, or calculated column. The allocation policy stays under AP control, the reconciliation logic stays auditable, and the extraction and matching stages decouple so each can be tuned independently. This is the recommended shape for mid-market AP teams whose reconciliation is too complex for a vendor tool's match UI and too high-volume for free-form Excel.

Invoice Data Extraction fits the extraction stage of that workflow. A natural-language prompt names the fields the schema needs — PO number, PO line, GRN number, item code, quantity, unit price, dates, and PO and GRN references where the supplier provides them — and the same prompt runs whether the batch is 50 documents or 5,000 (single PDFs up to 5,000 pages, batches up to 6,000 mixed-format files). Output lands in Excel, CSV, or JSON, ready for Power Query or a BI tool to run the FIFO or pro-rata allocation on. This is AI-powered invoice and PO data extraction for the extraction stage; the matching stays yours.