Partial receipt matching — definition
Partial receipt matching is the process of reconciling invoiced quantities against goods actually received across multiple deliveries against a single purchase order, rather than assuming one invoice will always correspond to one complete receipt.
Key takeaways
- Partial deliveries are one of the most common AP matching exceptions, not an edge case
- The gap between GRN and invoice usually comes from timing, short-ships, over-invoicing, or back-order billing, not fraud
- Most AP automation assumes 1 PO to 1 receipt to 1 invoice, and quietly breaks when reality doesn't follow that pattern
- Quantity-based tolerance rules at the receipt level, not the PO level, are what actually close the gap
A vendor delivers 600 units against a PO for 1,000. Your receiving team logs a goods receipt note (GRN) for 600. Two days later, the vendor's invoice arrives for the full 1,000 units, priced and billed as if the entire order shipped complete.
Your AP system checks the invoice against the PO. Both say 1,000, so on a PO-level match, that looks clean. It's only when someone checks the GRN that the problem surfaces: you've received 600 units and you're being asked to pay for 1,000.
Now run the scenario in reverse. The vendor ships in three batches over five weeks, each with its own GRN and its own invoice. By the third invoice, AP is trying to figure out which GRN it belongs to, whether the first two were already paid in full, and whether the running total across all three actually reconciles to what was ordered.
Neither of these is a fraud case. Neither is even unusual. It's Tuesday for most AP teams handling physical goods.
The core issue: most invoice matching logic is built around a 1 PO : 1 receipt : 1 invoice relationship. Partial receipts turn that into a 1 PO : many receipts : many invoices relationship, and the matching math that worked cleanly at the PO level stops being precise enough to catch real discrepancies.
Why Partial Receipts Are One of the Most Common Matching Exceptions
Ask any AP team to name their most frequent 3-way match exception, and partial shipments usually top the list, ahead of price variances and missing documentation.
There are ordinary supply chain reasons this happens constantly:
- Vendor inventory constraints. The vendor ships what's in stock rather than waiting for the full order.
- Freight and logistics splitting. A single order splits across multiple trucks or carriers, arriving on different days.
- Manufacturing lead time staggering. Made-to-order batches ship as they come off the production line.
- Vendor billing practices. Some vendors invoice per shipment. Others invoice for the full PO regardless of what's shipped, expecting the balance to follow later.
None of this is exotic. It's how physical goods procurement works once you're buying from more than a handful of vendors with real supply chains. The problem isn't that partial receipts happen. It's that most AP tooling was designed around the clean case and routes every partial to a human, with no structural logic for resolving it.
That's expensive at volume. A company processing a few hundred PO-backed invoices a month, with even a modest share of vendors shipping in partials, ends up with dozens of exceptions in queue at any time, each requiring someone to reconstruct which receipt covers which invoice line.
Why most tools handle this badly: the matching engine checks whether invoice quantity falls within tolerance of PO quantity, and stops there. It rarely checks whether invoice quantity falls within tolerance of what's actually been received and not yet billed. That second check is the one that catches the real gap.
What the "Gap" Between GRN and Invoice Actually Represents
When a GRN quantity and an invoice quantity don't match, the mismatch is a symptom. It's worth being specific about what's actually causing it, because the resolution differs in each case.
Timing gaps. The goods are in transit or recently received, but the receiving record hasn't been logged yet. This resolves itself within days and mostly needs a short hold, not an escalation.
Short-ships. The vendor shipped less than ordered and invoiced for what they shipped. The GRN and invoice agree with each other, they just both fall short of the PO. This is usually fine, and the PO simply stays open for the remainder.
Over-invoicing against partial receipt. The vendor ships 600 units but invoices for the full 1,000, either billing ahead of schedule or making an error in their own systems. This is the case that needs to be caught and held, because paying it means paying for goods you don't have yet.
Back-order invoicing. The vendor invoices for a shipment that hasn't arrived, expecting the invoice and the goods to reconcile once the delivery lands. Depending on payment terms, this may be acceptable practice with some vendors and a hard stop with others.
Quantity discrepancies across multiple partials. Across three or four partial receipts against one PO, the running total of what's been billed and what's been received can drift apart gradually, a few units at a time, until the final reconciliation shows a gap that no single invoice-to-GRN comparison would have caught.
Reconciling these correctly requires tracking two running totals per PO: cumulative quantity received across all GRNs, and cumulative quantity invoiced across all vendor bills matched to it. Each new invoice checks against remaining receivable-but-unbilled quantity, not the PO's original ordered quantity. That distinction is the difference between a system that catches over-invoicing on partials and one that lets it through because the PO still shows open quantity.
Common Failure Patterns
The pattern underneath all four: these failures share the same root cause as the failures on the shipment-matching side of ERP-specific inbound receiving — matching logic built for one PO to one invoice, applied to a relationship that's actually one-to-many. The fix is the same wherever it's implemented: track state at the receipt level, not just the PO level.
A Practical Resolution Framework
Closing the GRN-to-invoice gap doesn't require rebuilding your matching process from scratch. It requires four structural changes, applied in sequence.
Step one: track cumulative received quantity, not just PO quantity. For every PO with more than one GRN, maintain a running total of units received and units billed to date. Each new invoice is checked against received-minus-billed, rather than the PO's original order quantity. This single change catches the over-invoicing-on-partial scenario that PO-level matching misses.
Step two: set quantity-based tolerance rules, not just price tolerance. Most 3-way matching setups already have a price tolerance band, often somewhere in the low single digits as a percentage. Apply the same logic to quantity: define how much an invoice can exceed received-but-unbilled quantity before it auto-flags, versus how much variance is common enough with a given vendor to auto-approve. A vendor who reliably ships 98-102% of invoiced quantity due to rounding shouldn't generate an exception every cycle.
Step three: build assignment logic for invoice-to-GRN mapping. When multiple receipts are open against one PO, use a defined priority order: explicit reference on the invoice first (a delivery note or shipment number), then quantity and date proximity, then FIFO against the oldest unbilled receipt. This removes the ambiguity that otherwise turns every multi-shipment PO into a manual reconciliation exercise.
Should this partial-quantity invoice auto-approve or route to a human?
Most partial invoices are legitimate and predictable. Routing all of them to manual review wastes AP time on cases that aren't actually in question.
Ask on the demo
“Does invoiced quantity fall within tolerance of received-but-unbilled quantity, and has this vendor's variance pattern been consistent recently?”
Good sign
The gap is within tolerance and consistent with the vendor's typical pattern, safe to auto-approve with documentation
Red flag
The invoice exceeds received-but-unbilled quantity, or the vendor's pattern has shifted, worth a human look before payment
Step four: escalate only genuine gaps, with context attached. With the first three steps in place, the exception queue shrinks to cases that actually need judgment: quantity gaps that exceed tolerance, invoices with no confident GRN assignment, or receipts aged well past a normal reconciliation window. Escalate those with the PO, associated GRNs, and running totals already assembled, so the reviewer isn't starting from a blank page.
Industry estimates vary widely by source and definition, but manual invoice exception handling is commonly estimated in the range of 10 to 20 minutes per invoice for straightforward cases, climbing well beyond that for multi-receipt reconciliations. Treat any specific figure as directional. The structural point holds regardless: the cost of partial-receipt exceptions scales with how much of the reconciliation is manual versus rules-based.
When Strict Partial-Receipt Matching Isn't Worth the Overhead
Not every category or vendor relationship needs this level of rigor, and building it everywhere at once tends to produce more process than the risk justifies.
Low-dollar, low-volume categories. If a vendor relationship represents a small fraction of spend and rarely triggers partial shipments, the cost of building and maintaining receipt-level tolerance logic likely exceeds the exposure it prevents. A manual glance at the invoice against the PO total is often sufficient.
Trusted vendors with a long clean history. A vendor who has shipped and invoiced accurately for years, with variance consistently inside a tight band, doesn't need the same scrutiny as a newer or less predictable one. Many teams apply lighter-touch review, or higher auto-approval tolerance, to vendors with a demonstrated track record, and reserve strict receipt-level matching for higher-risk relationships.
Services and non-inventory categories, or very early-stage AP operations. If there's no physical goods receipt in the first place, software subscriptions, consulting, or other service spend, a 2-way match between PO and invoice is the right level of control; layering GRN reconciliation on top just adds process without adding control. Similarly, if you're processing a small volume of PO-backed invoices and partial shipments are genuinely rare, building the full framework above may be premature. A simple manual check against the PO covers the exposure until volume grows enough to justify the structure.
The honest test: if your AP team can already name, from memory, which vendors ship in partials and roughly how the numbers usually shake out, you may not need a formal framework yet for those categories. The framework earns its keep once that knowledge stops fitting in someone's head and starts showing up as unresolved queue items.
If partial receipts are a routine part of how your vendors ship, PO-level matching alone won't catch the gap.
Rhocash tracks the GRN-to-invoice relationship at the receipt level, not just the PO level:
- Cumulative receipt tracking across every partial delivery, so each new invoice checks against actual unbilled-received quantity
- Quantity-based tolerance rules that auto-approve variance within a defined band and route only genuine gaps to review
- Invoice-to-receipt assignment logic that resolves which GRN a partial invoice belongs to, using reference numbers, date proximity, and FIFO allocation
- Aging visibility into open receipts before they turn into a period-end reconciliation problem
Teams with active receiving operations typically find this is where a meaningful share of AP time was going before the structure was in place.
Frequently Asked Questions
What is partial receipt matching in accounts payable?
Partial receipt matching reconciles invoiced quantities against goods actually received when a purchase order is fulfilled across multiple deliveries rather than one complete shipment. Instead of comparing a single invoice to a single GRN, it tracks cumulative received and billed quantities across every receipt logged against a PO.
Why does my AP system approve invoices for more than what's been received?
Most matching logic checks an invoice's quantity against the PO's total ordered quantity, not what has actually been received so far. If the PO still shows open quantity, the invoice can clear even though the specific shipment it's billing for hasn't fully arrived. Closing this gap requires checking against received-but-unbilled quantity instead of the PO total.
How should tolerance rules work for partial shipments?
Tolerance rules for partial receipts work best when they're quantity-based and vendor-specific, not a single global threshold. Define how much an invoice can vary from received-but-unbilled quantity before it needs review, and adjust that band based on a given vendor's typical pattern. A vendor with consistent minor variance from rounding doesn't need the same scrutiny as one with unpredictable gaps.
What's the difference between a short-ship and over-invoicing?
A short-ship is when a vendor ships and invoices for less than the full PO quantity, and the GRN and invoice agree with each other, just both below the original order. Over-invoicing is when the invoice quantity exceeds what's actually been received, regardless of what the PO authorizes in total. Short-ships are usually fine and just leave the PO open. Over-invoicing on a partial receipt is the case that needs to be caught before payment.
Does every business need this level of partial-receipt matching rigor?
No. Categories with low volume, low dollar exposure, or a long history of clean vendor behavior often don't need the full framework, and neither do service-based categories without a physical goods receipt. The structure earns its value once partial shipments happen often enough that manual reconciliation becomes a recurring drain on AP time.
Related reading
- 3 Way Matching in Accounts Payable — the control framework this article builds on, and why exception queues grow past matching's capacity
- 2-Way vs 3-Way Matching: Choosing the Right AP Controls — how to decide which matching level fits a given category or vendor
- How to Automate Invoice Matching for NetSuite Inbound Shipments — the ERP-specific version of this problem, with item receipt writeback and control reporting in NetSuite
- How to Automate Multi-PO Invoice Matching in NetSuite — matching complexity when consolidated invoices span multiple purchase orders
More in this cluster
Related Articles
2 Way vs 3 Way Matching: When Each Is Right (And When to Drop Tolerances)
3-way matching isn't automatically the safer choice, and 2-way matching isn't automatically the riskier one. This is a practical decision guide for choosing the right matching level by category and vendor, and setting tolerances that don't create exception overload or fraud exposure.
3 Way Matching in Accounts Payable: When Control Becomes the Bottleneck
Three way matching catches discrepancies perfectly. But when exception queues start representing half your invoice volume, you haven't failed at control—you've outgrown detection-only systems. Here's what breaks and what's evolving.