If you run accounts payable on Oracle E-Business Suite, you know the Qty Rec hold well. An invoice you're sure is correct lands in the exception queue, Payables won't let it pay, and the reason code points at quantity received. The invoice is right. The purchase order is right. The goods may well have arrived. Oracle is still holding it — and understanding exactly why is the key to clearing it without doing something you'll regret at audit.
What a Quantity-Received hold actually means
Three-way matching in Oracle Payables compares three documents: the invoice, the purchase order, and the receiving transactions recorded against that PO. For a PO line set up to require receipt, Oracle will only match an invoiced quantity that has actually been received into the system.
A Quantity Received hold fires when the invoiced quantity exceeds the quantity received so far. Crucially, it isn't saying the price is wrong or the PO is wrong. It's saying: I don't have enough received quantity on record to justify paying for this many units. The match has two of its three legs — invoice and PO — but the receiving leg doesn't cover what's being billed.
That's a different failure from a Qty Ord (quantity ordered/billed) hold, which means you're invoicing for more than the PO authorised. Qty Rec is specifically about the gap between invoiced and received.
Why invoices keep landing on this hold
The reason Qty Rec holds are so common has little to do with anything being wrong and everything to do with who creates the receipt:
- The receipt was never entered. The goods arrived, but the person who took delivery never recorded a receiving transaction in Oracle. The receiving leg is simply empty.
- The receipt is late. Receiving happens in batches days after delivery, so the invoice beats the receipt into the system and holds until receiving catches up.
- The shipment was partial. 100 units were ordered, 60 arrived and were received, and the supplier invoiced for the 60 they shipped — but the receipt was recorded against the wrong line, or for the wrong quantity, so the match can't find its 60.
- A unit-of-measure or line mismatch. The receipt exists but was logged against a different PO line or in a different UOM, so Oracle can't reconcile it to the invoiced line.
In decentralised organisations — a large US public school district receiving goods at dozens of sites, for instance — the first two are overwhelmingly the common cause. The people receiving goods aren't AP staff, and recording receipts in Oracle isn't their day job.
Clearing the hold the right way
The instinct under deadline pressure is to manually release the hold so the invoice pays. Resist it. Releasing a Qty Rec hold without a matching receipt pays for goods Oracle has no record of receiving — which defeats the entire point of three-way matching and leaves an audit trail that says you overrode a control. For public money especially, that's the wrong answer.
The right answer is to give the match what it's missing: the receipt.
- Record (or correct) the receiving transaction. If the goods genuinely arrived, the receipt should exist. Create it against the correct PO line, in the correct unit of measure, for the quantity that actually arrived. Once the received quantity covers the invoiced quantity, the hold clears on the next validation — no override needed.
- Use receipt selection, not blind matching. When you match the invoice, match it explicitly against the specific receipt(s) that correspond to it, rather than letting it match against whatever's open on the PO. This matters most with multiple deliveries against one PO: you want the invoice tied to the right receipt so the running balance of received-versus-invoiced stays honest.
- For partial shipments, match partial. Don't force a full receipt to clear a partial invoice. Record the receipt for what arrived, match the invoice to it, and leave the PO balance open for the next delivery. The hold clears for the received portion and the rest stays controlled.
- Re-run validation. A hold doesn't lift itself the instant the receipt appears — Payables re-evaluates on validation. Once the receiving leg covers the invoice, the match passes and the invoice is payable.
The better fix: stop the hold from happening
Clearing Qty Rec holds one by one is a tax on the AP team that never ends, because the root cause — missing or late receipts — keeps recurring. The durable fix is to capture the receipt at the source, at the moment and by the person who already knows the goods arrived.
If the site bookkeeper or department initiator who receives the goods confirms receipt inside the AP approval flow — and that confirmation creates the real Oracle receiving transaction in the background — then by the time the invoice reaches Payables the receiving leg already exists. The match has all three legs and passes on the first try. We've written about that pattern in depth in in-workflow goods receiving on Oracle EBS: it turns Qty Rec holds from a recurring queue into a non-event.
The distinction is worth holding onto. Clearing a Qty Rec hold means supplying the receipt the match is waiting on, against the right receipt. Preventing it means making sure that receipt is there before the invoice ever validates. Override is neither — it's paying around a control you put there for a reason.
Where EZ Cloud fits
EZ Cloud runs natively on Oracle EBS, so receipts it creates are real Oracle receiving transactions and matches it performs are genuine three-way matches — never a flag in a side system that someone still has to reconcile. We built in-workflow receiving with partial-receipt handling for education and public-sector teams on Oracle EBS precisely because Qty Rec holds were eating their week.
If your AP team is releasing quantity-received holds by hand just to keep payments moving, that's a control you're quietly spending — and a problem worth solving at the source instead.