This system map is part of the purchase order mismatch resolution guide, which covers what to inventory before a procure-to-pay rollout. Here the question is structural: which system holds each record, which field joins it to the next, and who owns it.
The map: system, record, linking key, owner
A mismatch is resolved across at least four systems or modules. Names here are system types, not products, and the owner column shows the usual role.
| System or module | Record it holds | Linking key it carries | Usual owner |
|---|---|---|---|
| Procurement suite | Requisition, PO, each revision and its approval | PO number, line number, revision number | Procurement systems lead |
| ERP purchasing | The ERP's copy of the PO line | PO number and line; revision, if synced | Procurement systems lead |
| ERP receiving | Receipt events, over-receipt overrides and notes | PO line, receipt number | Warehouse operations manager |
| ERP payables | Invoice lines, match result, hold code, release | Invoice number, PO line, receipt reference, hold ID | AP manager |
| AP case queue or shared inbox | Supplier queries and internal notes | Case number; invoice number, if typed | AP supervisor |
| ERP configuration | Tolerance settings by period | Effective date | Finance systems lead |
The last row is easy to forget. A hold only makes sense against the tolerance that applied when it fired.
Join by join: where each link usually breaks
| Link | From | To | Join field to ask about | Where it commonly breaks |
|---|---|---|---|---|
| Revision to approval | PO change | Approval record | PO number plus revision number | Approval given by email, outside the workflow |
| Suite PO to ERP PO | Procurement suite line | ERP PO line | PO and line number in both systems | Sync failures leave the ERP on an older revision |
| PO line to receipt | ERP PO line | Receipt event | PO line on the receipt | Receipt posted against the wrong line or a blanket PO |
| Receipt to invoice match | Receipt event | Invoice line | PO line and receipt reference | Invoice keyed to the header, not the line |
| Invoice to hold | Invoice line | Hold record | Invoice number and hold code | Hold reason overwritten when the invoice is revalidated |
| Hold to release | Hold record | Release note or case | Case number in the release comment | Release with no comment; reason only in a chat thread |
Each break leaves both records intact and the link between them missing. That is why a history can look complete in every system and still fail to explain a single case.
One fully joined case (Illustrative)
Illustrative only; every number is invented, and the case is a price hold rather than the quantity hold in the worked exception example. A supplier's 4% price increase on one line is approved as revision 2 and synced correctly. The supplier's invoice, however, is keyed to the PO header, so the match compares it with the first line's price and a price hold fires.
| Record | System | Keys it carries | Joined to the next by |
|---|---|---|---|
| PO 6120 line 3, revision 2, price increase approved | Procurement suite | PO 6120, line 3, rev 2 | PO and line number |
| ERP PO line at revision 2 | ERP purchasing | PO 6120, line 3, rev 2 | PO line on the receipt |
| Receipt 4471 against line 3 | ERP receiving | PO 6120 line 3, receipt 4471 | Receipt reference, if keyed |
| Invoice 9902 keyed to the header, price hold | ERP payables | Invoice 9902, PO 6120, hold PRICE | Invoice number on the case |
| AP case 517, line mismatch found | AP case queue | Case 517, invoice 9902 | Case number in the release comment |
| Invoice rekeyed to line 3; hold released | ERP payables | Hold PRICE, case 517, user, timestamp | Back to rev 2 by PO and line |
Every record exists, and the revision synced. The mismatch came from the invoice-to-line join, the fourth link in the table above, and the case only explains itself because the release comment cites case 517.
When one PO has two numbers
Join fields often fail because the two systems number things differently, not because a field is missing. Common patterns to ask about:
| Pattern | What it looks like | What reconciles it |
|---|---|---|
| Separate number ranges | The suite issues 6120; the ERP stores 4500006120 | A prefix rule, or the suite number stored in an ERP reference field |
| Line renumbering | Suite line 3 becomes ERP line 30 | A documented multiplier or a line cross-reference table |
| Blanket agreements | Releases against one agreement get their own numbers | The agreement number carried on every release and receipt |
| Supplier invoice numbers | The same supplier reuses a number each year | Supplier ID plus invoice number plus date as the composite key |
| Case tools outside the ERP | AP cases numbered in a ticket system | The case number pasted into the release comment |
Ask the P2P systems analyst which of these apply and whether the rule is written down. An integration specification or mapping document usually holds the answer.
Revision archiving: the setting that decides what survives
Revision numbers are the spine of the map. In Oracle Purchasing, for example, revisions begin at 0 and increase by 1 when controlled information changes, depending on the document type's archive setting. If the company archives revisions, each change has its own record and a case can be rebuilt exactly. If it does not, only the latest version survives, and what the ERP believed when the invoice arrived is gone.
The hold side has its own logic. Oracle's Payables help describes three-way matching as checking that quantity billed does not exceed quantity received, with a matching hold that must be released before payment when tolerances are exceeded. That makes the release a distinct record, separate from the payment, that can carry a reason. Treat vendor behavior here as a question for the company's systems analyst, not a fact about its configuration.
The ten-hold test
A quick way to measure how joinable a history is, without anyone seeing a record. Ask AP to pick ten released quantity holds from at least a year ago and report three counts:
- Holds whose release traces back to a PO revision, receipt or case by ID.
- Holds that need a match by date, supplier or quantity.
- Holds with no recoverable reason.
Ask for the counts only. SourceX does not publish a benchmark for a good result; the counts give a review an honest starting point, and they fit in one line of the referral brief. The workflow map template is a blank layout for recording the map itself, and the procurement approvals guide covers the approval side in more depth.
Who can act on the map, and does the company qualify?
The procure-to-pay head or a P2P systems analyst can confirm the map; the CFO usually decides whether to explore licensing, with counsel checking supplier agreements. If you are the implementation partner, keep the referral separate from your project; ERP implementation partners explains how. Related record types include accounts payable exception handling.
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 the map and the ten-hold counts show a client's revisions, receipts, holds and releases still join by ID, register as a partner, check the company on who qualifies and read the program terms before the introduction.