This worked case is part of the purchase order mismatch resolution guide, which covers what to inventory before a procure-to-pay rollout. Here one held invoice is followed from the first revision to the release, so a partner can spot the same pattern at a client.
The case: a correct invoice held for ten days (Illustrative)
A fictional 380-person HVAC parts distributor runs a procurement suite for requisitions and PO approvals and an ERP for receiving and accounts payable. A buyer orders 400 compressor parts. Two days later the supplier offers a larger lot, and the buyer raises the line to 520; the category manager approves the change. The procurement suite records revision 1, but the sync to the ERP fails without an alert. The dock receives 520, the supplier bills 520, and the ERP still believes 400 were ordered. The invoice is held. Nobody made a pricing error and nobody shipped the wrong goods.
A mismatch is four numbers that should agree and do not: ordered, approved as a change, received and billed. The resolution record says which number was right.
Step by step: what each system believed
All days and quantities are invented.
| Day | Event | Quantity the record shows | System | Who acted |
|---|---|---|---|---|
| Day 1 | PO issued, revision 0 | 400 ordered | Procurement suite, copied to ERP | Buyer |
| Day 3 | Line raised and approved as revision 1 | 520 ordered | Procurement suite only; sync fails silently | Buyer, category manager |
| Day 9 | Dock posts the receipt with an over-receipt override and a note | 520 received | ERP | Receiving clerk |
| Day 12 | Invoice matched against the ERP's PO line | 520 billed against 400 ordered | ERP | AP, automatically |
| Day 12 | Invoice exceeds the 5% quantity tolerance (420 units) and is held | Hold applied | ERP | AP, automatically |
| Day 19 | Supplier asks why payment is late; AP opens a case | Case logged | AP ticket queue | AP specialist |
| Day 21 | Buyer finds revision 1 and its approval; ERP PO line corrected | 520 ordered in both systems | Procurement suite, ERP | Buyer, P2P systems analyst |
| Day 22 | Hold released with the note "approved revision not synced"; paid next run | Released | ERP | AP supervisor |
The five decisions inside the case
The table shows events. The evidence lies in the five decisions, each made by a named role and captured in a record:
- Approve the larger lot (day 3). The category manager's approval of revision 1 is the fact that later makes 520 correct. Record: the approval entry on the revision.
- Accept the over-receipt (day 9). The clerk could have refused the extra 120 units. The override note shows the clerk chose to accept and flagged it. Record: receipt with override reason.
- Hold the invoice (day 12). An automatic decision under the tolerance rule. Record: hold code and timestamp.
- Look one system further (day 21). The buyer checked the procurement suite rather than accepting the ERP's 400. Record: the PO correction and the case note.
- Release, with a reason (day 22). The supervisor's release note names the cause. Record: the release comment.
Remove decision 1's record and the release looks like an AP override of a valid control. Remove decision 5's comment and the history shows that an invoice was eventually paid, but not why.
Why this sequence is useful evidence
Because the software makes each step a separate, dated act. In Oracle Payables, three-way matching checks that quantity billed does not exceed quantity received, and an invoice outside the quantity and price tolerances gets a matching hold that must be released before payment. SAP documents the same pattern: when an upper tolerance limit is exceeded, the invoice is posted but blocked for payment, and releasing it is a separate step. SAP also notes that a block stays in place after its cause disappears. So the release is a deliberate act by a named person, usually with a timestamp and sometimes a reason.
Oracle
SAPThat makes resolved mismatches strong material for training and evaluating agents that do procurement work. An agent that reads only the ERP would have kept the invoice on hold or rejected it. The person who resolved it looked one system further and found the approved change. Exception handling data for AI agents explains why decisions like that matter, and the order-entry data page covers the sell-side version of the same judgment.
How to recognize a similar case at a client
Signals that a company holds cases like this:
- Requisitions and approvals run in one system while receiving and AP run in another.
- AP keeps a hold report with release comments, not just a paid-invoice report.
- Receiving clerks can post over-receipts with a reason code.
- PO revisions are archived, not overwritten.
- Supplier payment queries arrive through a case queue or shared inbox that is kept.
Questions for the procure-to-pay head, recorded as answers only:
- Roughly how many quantity or price holds a year, and what share is released after a correction rather than rejected?
- Do release comments say why, or are they usually blank?
- When a PO changes in the procurement suite, is the ERP revision updated by integration, by hand, or both?
- How many years of holds and revisions are retained?
The system map shows which join fields decide whether a case like this can be rebuilt by ID.
Who to talk to, and what stays unknown
The procure-to-pay head knows coverage; the CFO usually decides whether to explore licensing, with counsel checking supplier agreements. The who-can-license tree covers the path. Never ask for invoices, POs or exports, even as an implementation partner with access. Related record types: accounts payable exception handling and wholesale distribution data.
For SourceX, an introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. What stays unknown until SourceX reviews it: SourceX's current data needs, what supplier terms allow, what must be removed and any offer. SourceX licenses approved business data directly from companies for AI training and evaluation, and manages the agreement, rights review, data preparation, delivery and payout. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a client's hold history keeps the revision, the receipt override and the release reason linked for years of cases, register as a partner, check the company on who qualifies and read the program terms before you introduce the CFO.