The invoice reflects a new price. The purchase order still shows the old one. The ERP posts the invoice and blocks it for payment, and now the supplier is on the phone asking for a payment date. Before anyone releases the block, find out whether purchasing approved the new price and whether the order reflects it.
Clearing a hold safely means sending it to the person who can fix the cause, then checking the result before the bill enters a payment run.
Posted is not payable
SAP documents that in S/4HANA Logistics Invoice Verification, an invoice can post and still be blocked for payment when a variance exceeds an upper tolerance (SAP’s Blocking Invoices documentation). Seeing the accounting entry tells you little about whether the bill can be paid.
| Hold or block type | What triggered it | Typical owner |
|---|---|---|
| Missing receipt | No goods or service receipt for the billed line | Receiving or service owner |
| Quantity variance | Billed quantity exceeds received (or accepted) quantity | Receiving |
| Price variance | Billed price exceeds PO price beyond tolerance | Buyer |
| Approval pending | Bill has not been approved by an authorized person | Approver |
| Coding review | Entity, location, or account needs confirmation | AP or budget owner |
| Possible duplicate | Matches an existing bill on key fields | AP reviewer |
| Manual block | Someone placed it deliberately | The person who placed it, or their manager |
Find the reason before releasing anything
Open the bill and identify the exact line and check that stopped it. Then send the owner what they need to act, and nothing they have to go hunting for.
| Reason | Send the owner |
|---|---|
| Missing receipt | PO line, invoice quantity, delivery reference |
| Quantity or price difference | Invoice, PO, and receipt lines showing the difference, plus prior bills |
| Price change | Invoice and PO prices, unit of measure, any approved amendment |
| Receipt reversed | Goods receipt history and the return or correction reference |
| Supplier resent the invoice | Original and revised documents, and any posted invoice or credit |
| Manual block | Who placed it, when, and what must change before release |
Purchasing confirms a price change. Receiving corrects or explains a receipt. AP checks prior bills and credits. Record each response with the variance before an authorized reviewer decides whether to release.
The release procedure
- Identify the triggering line. On a multi-line bill, only one line may have a variance.
- Route to the owner with the evidence above.
- Fix the source record, not the tolerance. If purchasing approved the new price, the PO should show it. If receiving missed an entry, receiving posts it.
- Rerun the check. Compare the updated records with the bill.
- Confirm the hold is cleared, and separately confirm whether the bill is eligible for the next payment run.
- Record the decision: who approved, what evidence they used, and when.
- Check the proposal before payment release to confirm the bill is included, or excluded, as intended.
Never widen a tolerance to make one bill pass. If the tolerance is wrong, change it through the controller with a test, not through a hold queue.
How holds work in NetSuite, Oracle Fusion, and SAP
NetSuite
If you use the 3 Way Match Vendor Bill Approval workflow, Oracle lists the exception criteria it can check, including whether an item receipt exists and whether a quantity difference exceeds a configured limit (Oracle’s exception criteria). Oracle also documents the workflow’s states (Oracle’s workflow states).
One configuration detail matters more than the rest. Oracle documents that the workflow skips item-receipt validations when Bill in Advance of Receipt is enabled. If that preference is on, an approved bill does not prove receipt. Check your actual configuration before you treat an approval as evidence of delivery.
When receiving posts the missing receipt or the buyer approves a revised price, compare the updated records with the bill, confirm the approval status, and check separately whether the bill can enter the payment run.
Oracle Fusion
In Oracle Fusion Cloud, the Payables Matching Hold Detail Report can show the source of matching holds (Oracle matching hold detail report). Use it as the reference list when you check which holds a tool found and which still need action.
A useful test: give a reviewer a bill number and business unit but not the hold reason. They should be able to find the hold, see what changed after receiving supplied the missing evidence, and identify who is authorized to release it. If a coding correction is proposed, someone with access to the target business unit confirms it.
SAP S/4HANA
SAP separates posting from payment eligibility, as described above. It also offers flexible workflows for supplier invoices, including blocked invoices (SAP flexible workflow). Ask your SAP administrator to show both the posting path and the approval path in your environment, and to confirm which roles can lift a payment block.
Quantity differences have a balance-sheet consequence. In S/4HANA Cloud, a PO with a goods receipt and an invoice for a different quantity leaves a balance in the goods receipt/invoice receipt (GR/IR) clearing account (SAP’s GR/IR clearing documentation). Every unresolved quantity block is also an open item someone will have to explain at month-end.
Worked example: a price block and a quantity block (illustrative)
How variances post depends on your configuration.
Price block. PO for 500 units at $8.00, or $4,000. The goods receipt posts for 500 units, crediting GR/IR $4,000. The invoice arrives at $8.40 per unit: 500 × $8.40 = $4,200. The variance is $200, or 5 percent. With an upper price tolerance of 3 percent, the invoice posts and is blocked for payment.
The vendor liability is $4,200. GR/IR is cleared for $4,000, and the $200 goes wherever your configuration sends price differences. The buyer now has two paths:
| Buyer finding | Action | Amount paid |
|---|---|---|
| New price was approved | Update the PO to show the approved price and release the block | $4,200 |
| New price was not approved | Request a $200 credit from the supplier; release once it posts | $4,000 net |
Quantity block. Same PO, but receiving has recorded only 450 units. The goods receipt credits GR/IR 450 × $8.00 = $3,600. The supplier invoices 500 units at $8.00, $4,000. The invoice debits GR/IR $4,000, leaving a $400 debit balance in GR/IR. That balance stays open until the remaining 50 units are received ($400 = 50 × $8.00) or the supplier issues a credit. The block and the GR/IR balance are the same problem seen from two places. The GR/IR and receipt accrual reconciliation guide covers clearing it.
Using automation on holds
Software is good at the evidence-gathering part: reading invoice lines, pulling the PO and receipt history, and drafting the explanation. Give it a job the reviewer can check.
- Ask it to point to the specific records behind every proposed explanation.
- If two receipt lines could apply, it should show both and leave the decision open.
- It should report a document as posted and blocked, not just posted.
- Before any retry after a timeout, it should check whether the ERP already recorded the invoice and retrieve the document number.
- The established release workflow still governs payment. A tool that can lift blocks needs that permission granted, tested, and logged, like any person.
Have the vendor name the interface it would use and demonstrate it with the proposed service role in a sandbox. Confirm which entities and document types the role can read, whether it can create drafts or post, and who can lift a payment block.
Test with one item within tolerance, one above it, and a two-line bill where only one line has a variance. Ask the reviewer to show which item triggered the block and whether the invoice stays excluded after correction. If missing-receipt holds dominate your queue, fix the receiving handoff first; the three-way matching guide covers how.
What goes wrong
- Tolerance creep. Someone widens a tolerance to clear a backlog, and the next quarter’s price increases pass unreviewed. See purchase price variance.
- Release without source correction. The block is lifted but the PO still shows the old price, so the next invoice blocks again.
- Holds in one inbox. Every hold lands with AP, which then chases receiving and purchasing by email. Route by reason.
- Approval read as receipt. A NetSuite bill approved under Bill in Advance of Receipt is treated as proof of delivery.
- Paid, then corrected. A receipt is corrected after the bill was paid, and nobody tracks the expected credit.
- Held bill in the payment run. Payment selection does not respect the hold. Test this explicitly; the vendor payment runs guide has the pre-release checks.
Daily hold review
- Pull the hold report (or the system’s equivalent) and sort by reason, not by age alone
- Confirm each hold has a named owner and the evidence attached
- Check holds older than your service level and escalate to the owner’s manager
- For every release since yesterday, confirm the source record was corrected and the decision recorded
- Reconcile today’s proposed payment run against open holds before release
- Note any GR/IR balances created by quantity blocks for the month-end review
- Log any tolerance change request for the controller rather than acting on it