Resolve a three-way match exception by identifying which evidence disagrees: the purchase order, the receipt or the supplier bill. Assign the discrepancy to the person who can verify it, retain the explanation and approve the correct transaction outcome. Raising tolerances until the bill passes can conceal an unresolved receiving or commercial problem.
This guide focuses on exception handling and the boundary of Oracle's documented workflow. It does not assume that every product described as NetSuite three-way matching has the same behavior. Confirm the installed SuiteApp, custom workflow and integration before applying any procedure.
Oracle's 3 Way Match Vendor Bill Approval Workflow is included in the NetSuite Approvals Workflow SuiteApp. It compares specified bill details with purchase orders and item receipts and routes identified discrepancies for review.
The same current page explicitly lists partially received item receipts as unsupported. That limitation needs an implementation decision when partial deliveries are common. A third-party product's support for partial-receipt matching does not establish that the standard template has the same capability.
Record the workflow name, installed version, customization owner and transaction channels in the design. If the business uses a different matching engine, obtain its own primary documentation and test evidence. Avoid combining capabilities from several products into a fictional standard process.
Use reason categories that identify the evidence owner. A missing receipt goes to receiving. A disputed unit price goes to procurement or the commercial owner. An incorrect supplier reference or captured quantity goes to AP intake. A currency or accounting-period issue goes to finance.
Record the purchase-order line, receipt identifiers, bill line and comparison value. Header totals are insufficient when one bill combines several items or shipments. Include unit of measure and currency so the reviewer compares like with like.
Distinguish “goods not received” from “goods received but not recorded.” The first may require a commercial decision to withhold payment. The second requires evidence and a correct receipt entry. Neither should be solved by fabricating a receipt to release a bill.
Oracle's exception criteria documentation distinguishes percentage tolerance limits from absolute quantity difference limits. It also identifies separate checks for terms, location, receipts, quantities and amounts.
Create a policy matrix showing which criteria apply to each relevant purchase type, who owns the threshold and when an exception requires approval. Do not assume that an amount tolerance also covers quantity or receipt absence.
Test interacting criteria. A bill can remain in exception because another enabled check rejects it even after a tolerance is adjusted. The acceptance evidence should name the criterion that fired, not merely record “matching failed.”
A purchase order requests 200 units at 15 each. The warehouse has recorded receipt of 180 units, while the supplier bills 200. The bill may be commercially premature, the remaining receipt may be missing or the supplier may have made an error.
The receiving owner first verifies the physical and documentary position. If 180 arrived, AP should not create a receipt for the missing 20 to make the records agree. Procurement determines whether to request a corrected bill, agree a partial payment or resolve the outstanding delivery under approved policy.
If the account uses the standard Oracle template, the documented partial-receipt limitation must be addressed in the workflow design. This example describes the business evidence required; it does not claim that the template automatically resolves this scenario.
A price mismatch can reflect a valid amendment, a stale PO, a supplier error, freight or a different unit of measure. Compare the original agreement and approved changes before editing either the PO or bill.
Keep the amendment evidence visible. Changing the PO after the invoice arrives can make a comparison pass without showing who accepted the increase. Require approval of the commercial change and retain the previous value where your control design calls for it.
Separate the invoice's commercial correctness from its accounting allocation. A valid freight charge may still need a different accounting treatment from the purchased item. Finance should approve that treatment rather than leaving it to the person clearing the exception.
A bill waiting for receipt evidence should have an owner, next review date and payment-risk indicator. Record whether the due date or discount deadline creates urgency, but do not let urgency substitute for evidence.
If a receipt is entered later, verify that the matching process re-evaluates the intended bill and uses the correct linked receipt. Test that behavior in the actual workflow. A receiving update should not require AP to guess whether an earlier exception remains current.
For service purchases, agree what constitutes acceptance. A warehouse-style item receipt may not be the right business evidence for every expense. Design the approved purchase-type route rather than forcing all purchases into one mechanical test.
Approving a bill answers whether it may proceed under policy. Posting a purchase variance answers an accounting question about differences between receipt and bill values. One does not automatically prove that the other is complete.
Have the controller define when approved differences require a variance process, a corrected document or another accounting treatment. Preserve the original exception reason so recurring price or quantity problems can be analyzed after the bill is paid.
Do not close an order solely to remove it from an exception queue. Confirm whether more goods, bills, credits or returns are expected. A superficially clean queue can create a later reconciliation problem if the underlying lifecycle remains open.
Oracle's customization guidance recommends copying the workflow and cautions against undocumented customizations. Treat changes to checks, states and tolerances as controlled releases with an owner and rollback plan.
Test a clean bill, missing receipt, price variance, quantity difference, wrong location, stand-alone bill and representative integration entry. Include partial-receipt scenarios as a specific suitability gate. Record expected versus observed results and inspect the resulting approval status.
For workflow diagnosis and exception-report design, CuriousRubik's NetSuite support services can help review the account's actual checks and ownership. Bring an example from each major exception category.
For each exception category, specify the evidence required to move forward: a receiving document for missing quantity, an approved amendment for price, or a corrected source invoice for capture error. Record who may approve an exception without changing the source documents. This makes it possible to distinguish correction, commercial acceptance and exceptional payment authority in later review.
Oracle currently lists them as unsupported. Confirm whether your account uses that template, a customization or another product before designing partial-delivery handling.
No. Oracle distinguishes a percentage tolerance from an absolute quantity difference. Review the relevant criteria and their interaction in the workflow.
Receiving should verify what physically arrived and provide the evidence. AP coordinates the bill, while the authorized owner decides any payment exception.
No. Approval and accounting reconciliation answer different questions. Finance should define the required treatment of each accepted difference.
Only after an approved policy review supported by actual exception data. First determine whether the queue reflects bad data, missing receipts or genuine supplier discrepancies.