# PO mismatch resolution records | SourceX

Canonical: https://refer.sourcex.si/guides/workflow-purchase-order-mismatch-resolution
Last updated: 2026-10-19

Before a procure-to-pay rollout, inventory purchase order mismatch history as linked evidence: every PO revision with its approval, the receipt events posted against each line, the invoice holds the match produced, and the correction or release note that cleared each one. Record which system holds each piece, how many years it covers, who owns it and the date the old procurement module will be retired. Then introduce the procure-to-pay head, and through them the person who can authorize a licensing discussion.

A purchase order mismatch happens when the PO, the receipt and the invoice disagree on quantity or price by more than the company allows. Resolving one means finding which document was wrong, correcting it and releasing the hold. That resolution is spread across procurement, receiving and accounts payable, which is exactly why a rollout that replaces one of them can cut the chain.

## What should be inventoried before a procure-to-pay rollout affects purchase order mismatch resolution history?

The history the new suite does not need on go-live day. A procure-to-pay rollout typically migrates open POs, active suppliers, current catalogs and unpaid invoices. Closed POs with their revision chains, old receipts, released holds and the comments explaining each release are the parts most easily left in a legacy module.

| Record class | Why the rollout puts it at risk | What to ask the company |
|---|---|---|
| PO revision history | Only the current revision of open POs is migrated | Are archived revisions kept, and for how many years? |
| Change approvals | Old approval workflow is switched off | Will approval history be exported or retained in place? |
| Receipt events and overrides | Receiving may move to a new module | Are closed receipts and override notes kept? |
| Invoice holds and releases | Hold tables are often left out of a migration scope | Who owns the hold history and its comments? |
| AP cases and supplier emails | Shared inboxes are consolidated or purged | Is there an AP case log, and how far back does it go? |
| Tolerance settings by period | New tolerances replace old ones | Is there a record of which tolerance applied when? |

On top of the table, get four facts: the record classes that exist, their time coverage, the owner of each system, and the real access deadline, such as the date the legacy purchasing module is decommissioned. Do not recommend keeping data beyond what the company is authorized to retain; the inventory exists so people with that authority can decide.

## Why the release note is the record most likely to be lost

Because the hold and its release are separate events, and only one of them changes the money. Oracle's Payables help describes three-way matching as checking that quantity billed does not exceed quantity received; an invoice outside the quantity and price tolerances gets a matching hold that must be released before it can be paid. SAP's documentation makes the same point from the other side: an invoice blocked for a variance stays blocked even after the cause is removed, and must still be released in a separate step. When the upper tolerance limit is exceeded, the invoice is posted but blocked for payment.

So the payment record shows that an invoice was eventually paid. The release, with whoever wrote why, shows how the mismatch was resolved. Release comments live in hold tables and AP case logs, which are often left out of a migration scope.

Revision history has its own configuration question. In Oracle Purchasing, PO revisions begin at 0 and increase by 1 when controlled information changes, depending on the document type's archive setting. Whether earlier revisions exist at all is therefore a setting someone chose years ago. Ask, rather than assume.

## An illustrative inventory sheet

Illustrative only; the company and figures are fictional. A 600-person industrial distributor is rolling out a procure-to-pay suite in front of its ERP and will retire the ERP's purchasing module. Its procure-to-pay head fills in the sheet from the rollout plan.

| Record class | System | Years held | Owner | Moves at go-live? | Readable until |
|---|---|---|---|---|---|
| PO revisions | ERP purchasing module, archive on | 2016 to now | Procurement systems lead | Current revision of open POs | Purchasing module decommissioned |
| Change approvals | ERP approval workflow | 2016 to now | Procurement systems lead | No | Purchasing module decommissioned |
| Receipt events | ERP inventory module | 2015 to now | Warehouse operations | Not affected | ERP kept |
| Invoice holds and release notes | ERP payables hold tables | 2017 to now | AP manager | No | Archive decision pending |
| Tolerance settings by period | ERP configuration | Current only | Finance systems | No | Not recorded |

Reading the sheet: receipts are safe because inventory stays in the ERP. The approval history and the hold and release records, which together explain each mismatch, depend on a decommission date and an archive decision nobody has made yet. The missing tolerance history is a known gap worth writing down.

## Which date is the real deadline?

The day the legacy purchasing module is decommissioned or set read-only, from the rollout plan. Go-live is earlier and matters less, because the old module may stay readable for a period. If the hold tables are subject to a separate archive or purge decision, record that date too. If nothing is fixed, write "not set"; that is the only honest urgency. The [legacy ERP archiving guide](/guides/legacy-erp-data-archiving) explains common archive choices.

## Who decides, and does the company qualify?

The procure-to-pay head knows coverage. The CFO decides whether a licensing discussion fits, with counsel checking supplier agreements. If you are the implementation partner, keep the referral separate from the statement of work; [ERP implementation SOW confidentiality](/guides/erp-implementation-sow-confidentiality) and [does referring clients hurt the relationship](/questions/does-referring-clients-hurt-relationship) cover the etiquette.

The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, 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: dataset demand, the rights review result, what must be removed and whether any offer follows. Partners sign the Channel Partner Agreement before submitting introductions, and the first valid introduction within the 90-day window is credited when the company submits a verified application. How rewards are calculated is on the [rewards page](/rewards); related record types include [accounts payable exception handling](/data-types/accounts-payable-exception-handling-process), and other sectors are on the [industries hub](/industries).

## Go deeper on purchase order mismatch resolution

- [Purchase order mismatch resolution exception examples](/guides/purchase-order-mismatch-resolution-exception-examples): one held invoice worked through from revision to release.
- [Purchase order mismatch resolution records across systems](/guides/purchase-order-mismatch-resolution-records-across-systems): a system map of the identifiers that join PO, receipt, invoice and hold records.
- [Who can license purchase order mismatch resolution records](/questions/who-can-license-purchase-order-mismatch-resolution-records): a decision tree for which executive to introduce and what needs supplier review.
- [Purchase order mismatch resolution referral brief template](/resources/purchase-order-mismatch-resolution-referral-brief-template): a fill-in, metadata-only brief for the introduction.

## 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 procure-to-pay go-live will retire a purchasing module that holds years of revision and hold history, [register as a partner](/register), check the company against [who qualifies](/who-qualifies), and read the [terms](/terms) before you send the handoff.

## Sources

- https://docs.oracle.com/cd/A60725_05/html/comnls/us/ap/point04.htm
- https://docs.oracle.com/cd/A60725_05/html/comnls/us/po/revnum.htm
- https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/af9ef57f504840d2b81be8667206d485/8a70b6531de6b64ce10000000a174cb4.html
- https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/b7eb2f9e70ab4c88abbff8b34a409b26/ec236b54f94c8f4ce10000000a4450e5.html
- https://refer.sourcex.si/terms