## TL;DR

Change orders amend the PO baseline, and matching must use the latest approved version, not the original. Version the PO: keep the original plus each approved change, match invoices against the current version, and require change-order approval before the amended baseline takes effect. Invoices that arrived under an older version get re-baselined, not rejected.

## Steps

1. Maintain PO versions: original plus approved changes.
   Expected: A versioned baseline.
2. Match new invoices against the current version.
   Expected: Correct baseline.
3. Re-baseline in-flight invoices when a change is approved.
   Expected: No false mismatches.
4. Require approval on the change order itself.
   Expected: Control at the source.
5. Audit the version history with each match.
   Expected: Full traceability.

## When to use

- Amended POs
- Price or quantity changes mid-order
- Change-order workflows

## When not to use

- Unapproved price changes (disputes)
- Original PO matching
- Contract amendments (legal, not PO)

## Compatibility

ERP-agnostic.

## Variant phrasings

### PO change order matching

### amended PO invoice

### PO version invoice match

## Root cause

Orders change: quantities grow, prices adjust, lines get added. Matching against a stale baseline manufactures mismatches out of legitimate changes.

## Edge cases

- Verbal change agreements need written confirmation before re-baselining
- Change orders after partial billing need cumulative re-baselining
- Emergency changes need retroactive approval paths

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KRNfSLv1Q0etD51YZJAc9g