Three-way matching sounds simple: match the invoice to the purchase order and the goods receipt, and if the invoice is covered by what's been received, it's good to pay.
The trouble starts with the word "received." Goods and services rarely arrive in one neat delivery, especially in healthcare. A blanket purchase order gets receipted in stages over weeks. Multiple invoices draw against the same purchase-order line over time. And the moment that happens, a naive receipt check starts producing wrong answers — in both directions.
The two ways a naive check fails
The first failure mode is over-strict. Some tools treat "not fully receipted" as "invalid" and put the invoice on hold. But partial receipting is standard practice. An invoice that legitimately draws against a partial receipt gets blocked, a human has to override it, and the automation you bought is now generating manual work instead of removing it.
The second failure mode is worse, because it's silent. Consider a services blanket PO:
- A receipt of $10,000 comes in. Invoice 1 for $10,000 validates and is approved. Correct.
- A second receipt of $20,000 comes in, bringing the cumulative receipted total to $30,000. Invoice 2 arrives for $22,000.
A check that compares the invoice against the cumulative receipted figure sees $22,000 against $30,000 and passes it. But $10,000 of that $30,000 was already consumed by Invoice 1. Only $20,000 is actually available — so Invoice 2 should fail. The naive check just let through $2,000 of unsupported spend, and nobody saw it happen.
The same trap exists for goods. If a PO line shows 8 units received, and one approved invoice already claims all 8, the next invoice claiming any quantity should fail — but a tool that only reads "8 received" will happily pass it.
The right model: a running balance
The fix is to stop comparing invoices against the raw receipted total and start comparing them against the available balance:
Available = receipted total in Fusion − amount already committed by other active invoices on the same PO line
In plain terms: every invoice that's actively in flight against a purchase-order line has reserved part of the receipted balance. Before you validate a new invoice, you subtract what those other invoices have already claimed. What's left is what this invoice is genuinely allowed to draw against.
Walk the earlier example through the correct model:
| Event | Receipted total | Already committed | Invoice being validated | Result | |---|---|---|---|---| | Receipt 1 = $10,000 | $10,000 | — | $10,000 | Valid | | Receipt 2 (cum. $30,000) | $30,000 | $10,000 (Invoice 1) | $22,000 | Invalid — only $20,000 available | | Later receipt (cum. $32,000) | $32,000 | $10,000 (Invoice 1) | $30,000 | Invalid — only $22,000 available |
Each decision now reflects reality: the receipted capacity that's left after accounting for everything else in the pipeline.
Which invoices count as "committed"
The model only works if you're precise about which in-flight invoices reserve capacity and which don't:
- Approved invoices — committed. They're on their way to the ledger.
- Pending / in approval invoices — committed. They're actively consuming the balance.
- Awaiting clarification invoices — committed. Still live in the workflow.
- Rejected or duplicate invoices — not committed. They're not being paid, so they release their hold.
- Freshly uploaded, not yet in workflow — not committed. Nothing reserved yet.
There's one more subtlety that matters in practice: when you re-validate an invoice that's already in the workflow, you must exclude that invoice itself from the committed total. Otherwise it counts its own claim against its own available balance and fails for no reason. The running-balance calculation always excludes the invoice currently being checked.
Why healthcare hits this constantly
Blanket POs are everywhere in health-service procurement — recurring services, framework agreements, consumables ordered against a standing PO across many sites. These are exactly the purchase orders that get receipted in stages and billed by multiple invoices over a period. If your receipt validation can't reason about a running balance, every one of these POs becomes a stream of false holds or, worse, a channel for quietly overpaying past the receipted amount.
This is also why three-way matching is only as good as its receipt logic. Get the balance wrong and you either drown your team in overrides or let unsupported spend through — the two outcomes AP automation is supposed to prevent.
Where this fits
Partial-receipt validation is one branch of the full set of invoice scenarios a healthcare AP team handles on Oracle Fusion — alongside catching duplicate and already-paid invoices, credit notes, statements and the rest. They share a principle: real validation means reasoning about live ERP state, not reading a single field in isolation.
It also depends on integrating with Fusion the way Oracle supports — reading receipt data over Oracle Integration Cloud (OIC) REST and posting approved invoices through FBDI load, with no custom writes to Fusion's base tables. That's what keeps the integration durable across Fusion's quarterly updates, and you can see how it's built on our Oracle EBS and Fusion integration page.
Where EZ Cloud fits
EZ Cloud validates every PO invoice against the available receipted balance — receipted total in Fusion, minus what other active invoices on the same line have already committed — so partial receipts pass when they should and overshoots get caught before they post. No blanket holds on legitimate partial bills, and no silent overpayment past the receipted amount.
If your three-way matching is generating false holds on blanket POs, or you've ever found spend that slipped past a partial receipt, that's the exact gap we close for healthcare finance teams running AP automation on Oracle Fusion.