A large share of "exceptions" in a PO-driven AP operation aren't really exceptions at all. The invoice is fine. The PO is fine. The price and quantity are fine. The only thing missing is a goods receipt — nobody has confirmed in the ERP that what the supplier billed for actually arrived. So three-way matching has nothing to match against, the invoice goes on hold, and it lands in the AP queue.
And that's where it gets stuck, because AP can't fix it. AP didn't order the goods, didn't take delivery, and has no standing to confirm receipt. The only person who can clear the hold is the requester who raised the PO. Yet in most shops the invoice sits with AP anyway, while someone chases the requester by email, the supplier chases AP for status, and a mechanical situation turns into days of back-and-forth.
The "not receipted" case is its own thing
It's worth separating this from the other reasons a PO invoice fails to match:
- Price mismatch — the unit price billed differs from the PO. That's a buying or negotiation question.
- Quantity over-billing — the supplier billed more than was ordered. That's a dispute.
- Receipt missing entirely — the goods were (probably) delivered, but no one recorded the receipt. Nothing is wrong with the invoice; an action is simply owed.
The third case is the most common and the most automatable, precisely because there's no disagreement to resolve — there's a task to complete. Treating it like a price dispute, where AP investigates and adjudicates, is the wrong model. The right model is: identify who owns the receipt, and put the action in front of them.
Detecting it requires a live PO and requester lookup
You can't route to the requester if you don't know who the requester is, and you can't be sure receiving is the actual problem unless you've checked the PO's live state. Both come from the ERP, in real time, at the moment the invoice fails to match:
- Pull the PO referenced on the invoice and confirm it's a valid, open, invoiceable PO — not closed, cancelled, or final-closed.
- Check for matching receipts. If the receipted quantity is zero (or short of what's billed), receiving is the gap.
- Read the requester or buyer off the PO header. That's the person who can either confirm receipt or tell you the goods never came.
Only with all three facts in hand can the system say, with confidence, "this is a not-receipted hold, and here is exactly who must act." Guess any of them and you've routed a confident message to the wrong person — which is worse than not routing at all.
Route the action, not the blame
Once the case is identified, the invoice shouldn't sit in AP's general queue. It should generate a clear, specific action to the requester: this invoice is on hold because the receipt for PO [X] hasn't been recorded; please confirm goods were received (or flag that they weren't). The requester confirms receipt in the ERP, the receipt posts, matching succeeds on the next pass, and the invoice flows through — without AP ever having touched it as a judgment call.
This is the same principle that makes upstream prevention so effective: the closer the receipt confirmation sits to the person who actually received the goods, the fewer three-way-match rejections you generate in the first place. Routing a not-receipted hold to the requester is the reactive version of that idea — catching the gap when it has already happened, and sending it to the one person who can close it.
Don't forget the supplier
While the requester is being asked to confirm receipt, the supplier is sitting in the dark — and a supplier in the dark sends a follow-up email. The same logic that routes the hold internally should also answer the supplier honestly: we've received your invoice; it's on hold pending confirmation of receipt on our side, and no action is needed from you. That single proactive reply prevents the "any update?" email that would otherwise hit the AP inbox a few days later.
That's the connection to supplier-email exception prevention: the most efficient AP operation doesn't just resolve exceptions faster, it keeps the people who can't help — AP for receiving, and the supplier for an internal task — out of the loop entirely, while keeping everyone informed.
Where EZ Cloud fits
EZ Cloud reads PO status, receipt quantities, and the requester or buyer live from Oracle — EBS or Fusion — when a PO invoice fails to match. Instead of dropping a not-receipted hold into AP's queue, it routes the receiving action to the person who owns the PO, and answers the supplier automatically so the inbox stays quiet. AP stops being a middleman for a task it can't perform, and the invoices that were only ever waiting on a receipt stop being treated like disputes.
The same engine handles the AI email exception prevention side, and posts cleanly back into Oracle EBS and Fusion using Oracle-supported methods. If your PO exception queue is mostly invoices waiting on someone else to confirm receipt, that's a queue that shouldn't exist.