A three-way match runs when the invoice is entered: the system pairs each invoice line with a purchase-order line, checks quantity against the goods receipt, checks price against the order, and applies the tolerance rules. Everything inside tolerance posts for payment. Anything outside stops and waits for a person.
Knowing the exact sequence matters, because each step fails for different reasons and gets fixed in a different place.
The match runs when the invoice posts
Nothing about matching is continuous. The check fires when an invoice is keyed, scanned, or received electronically and the system tries to post it. Whatever the purchase order and receipt say at that moment is what the invoice is judged against, which is why timing problems show up as exceptions even when every document is eventually correct.
Line pairing comes before any comparison
Before a single number is compared, the system has to decide which purchase-order line each invoice line belongs to. Clean references make this trivial. A missing PO number, a supplier's own item codes, or one invoice covering three orders makes it hard, and a line that cannot be paired cannot be matched at all. A large share of what looks like a price or quantity problem is really a pairing problem.
Quantity clears first, then price
For each paired line, the system checks quantity: invoiced quantity against received quantity, so the company never pays for more than arrived. Then it checks price: the invoiced unit price against the purchase-order price. Each check applies its own tolerance, and each can fail independently, which is why a single invoice can carry both a quantity mismatch and a price variance.
Inside tolerance pays; outside tolerance stops
Lines that clear both checks post automatically, and an invoice whose lines all clear goes to the payment run with no one touching it. One failed line is enough to hold the document. The system records a block reason, parks the invoice, and routes it to a queue.
The flag is where the real work starts
Everything up to the flag is arithmetic, and ERPs have done it reliably for decades. The expensive part begins after: working out why the documents disagree and what to do about it, which takes context the match never sees. That step should run autonomously too, end to end, with people handling only the genuine judgment calls. The manual vs automated resolution page compares the options.
Fragment picks up exactly where the match stops, reading the order, receipt, contract, and history to clear the flag on its own. See how Fragment reads that context or request a demo.