Ask an Oracle E-Business Suite AP team why purchase-order invoices land in the exception queue, and the honest answer is rarely a price discrepancy or a quantity overage. More often it's something duller and more frustrating: there's no receipt in the system yet. The invoice is correct. The PO is correct. The goods even arrived. But because no one created the receiving transaction in Oracle, the three-way match has nothing to match against — so EBS rejects it.
That single gap generates a surprising share of AP rework, especially in decentralized organizations where the people receiving goods aren't the people processing invoices.
Why "no receipt" rejections happen
Three-way matching in Oracle Payables compares the invoice, the purchase order, and the receiving transaction. All three have to exist and agree within tolerance. The PO is created up front. The invoice arrives from the supplier. The receipt is supposed to be entered by whoever physically takes delivery.
In practice, that third leg is the weak one. In a large US public school district, for example, goods are received at dozens of individual sites — schools, warehouses, departments — by bookkeepers and staff whose primary job isn't AP. Asking each of them to log into Oracle Purchasing and enter a receiving transaction is a non-starter. So receipts get skipped, delayed, or done in a batch days later.
The downstream result is predictable:
- The invoice flows into Oracle AP and fails 3-way match for "no receipt."
- It drops into an exception queue.
- An AP specialist investigates, tracks down whether the goods actually arrived, and manually creates or chases the receipt.
- The invoice gets reprocessed.
Multiply that by every PO invoice from every site and you have a standing tax on the AP team — one that has nothing to do with anything actually being wrong.
The fix: confirm receipt where the goods are received
The cleanest place to capture a receipt is at the moment and by the person who already knows the goods arrived — inside the approval flow they're already touching.
Here's the pattern. The person who receives the goods (a site bookkeeper, a department initiator) already attests, as part of approving an invoice, that the goods were received. That attestation is the signal. So instead of treating it as a checkbox that dies in the AP tool, you turn it into the Oracle receiving transaction.
When the initiator confirms receipt, the system shows a read-only summary of the PO lines — quantities ordered and quantities already received — and a single "Confirm Receiving & Continue" action. On confirm, the system creates the corresponding receiving transaction in Oracle in the background, then continues the approval flow exactly as before. The receiver never logs into Oracle Purchasing. They never see a receiving form. They click one button in the tool they're already in.
By the time the invoice reaches final approval and posts to Oracle AP, the receipt already exists. The three-way match has all three legs. It passes. No exception, no queue, no AP investigation.
Partial receiving is the part that's easy to get wrong
A naive "mark it received" button breaks the moment a shipment arrives in pieces — which, for goods, it constantly does. You ordered 100 units, 60 showed up, the supplier invoiced for the 60 they shipped. If your receiving logic assumes full receipt, you've just created a different matching problem.
This is why showing quantities ordered versus quantities already received matters. The confirmation has to respect partial receiving: create a receipt for what actually arrived, against the right PO lines, leaving the balance open for the next delivery. Done right, an invoice for a partial shipment matches cleanly against a partial receipt, and the remaining quantity stays available for later. Done wrong, you've traded "no receipt" rejections for "quantity mismatch" rejections.
Build it as additive, with a safety net
The reason this works in production is that it changes nothing about how Oracle does matching — it just makes sure the receipt is there before the match runs. A few principles keep it safe:
- Scope it to PO goods invoices that need 3-way matching. Non-PO invoices, service-only POs with nothing to physically receive, and POs already receipted in Oracle should pass through untouched.
- Add a check before posting. Right before the invoice goes to Oracle AP, verify the receipt was actually created. If it succeeded, the invoice proceeds automatically. If it's still processing or failed, the approver gets a clear message and next steps instead of a silent rejection later.
- Keep it reversible. Because the behavior is purely additive — a receipt that would have had to be created manually anyway — existing invoices and workflows keep behaving exactly as they did before.
The net effect is that the most common, most annoying class of three-way-match failure simply stops occurring for invoices that flow through the workflow. AP stops being the receiving department of last resort.
Where EZ Cloud fits
This is the kind of operational detail that separates AP automation that captures invoices from AP automation that actually clears them. EZ Cloud runs natively on Oracle EBS, so the receiving transaction it creates is a real Oracle receipt — not a flag in a side system that someone still has to reconcile.
We've built this exact in-workflow receiving flow, partial receipts included, for education and public-sector teams on Oracle EBS where goods arrive at many sites and the receivers aren't AP staff. If "no receipt" rejections are quietly eating your AP team's week, the answer usually isn't more matching rules — it's capturing the receipt at the source, before the match ever runs.