Three-Way Match

The pilot engine. It reconciles three documents for a single purchase — Purchase Order, Goods Receipt, and Vendor Invoice — and decides whether the invoice can be paid automatically or must be held.

The rule

A payment auto-approves only when both conditions hold:

Within tolerance — the invoice variance against the PO is inside the agreed tolerance band: |invoice − PO| ≤ PO × tolerancePct.
Covered by the receipt — the invoiced amount does not exceed the goods actually received (allowing the same tolerance): invoice ≤ receipt + toleranceAmount.

Any breach of either condition is fail-closed: the verdict becomes hold_dual_approval rather than letting the payment through.

Fail-closed means the default on uncertainty is to stop, not to pay. A tolerance breach or a receipt shortfall always routes to dual human approval.

Worked example

The demo mirrors the prototype’s settlement PO-7741 / INV-99214:

Line	PO	Receipt	Invoice
Raw stock (40 units)	12,400	12,400	12,400
Expedited freight	0	0	480

With poTotal = 12,400, receiptTotal = 12,400, invoiceTotal = 12,880, and a ±5% tolerance band (toleranceAmount = 620):

variance = 12,880 − 12,400 = +480 (+3.87%) → within ±620.
receipt coverage: 12,880 ≤ 12,400 + 620 = 13,020 → covered.
Verdict: auto-approve.

Push the invoice past 13,020 (e.g. a larger freight surcharge) and it breaches both the tolerance band and receipt coverage → hold for dual approval.

How the decision maps to the Guardian

A clean match starts at autonomy level full_auto. Each breach raises a warning compliance flag; the shared fail-closed core then downgrades the verdict to a human gate:

Condition	Flag raised	Guardian effect
Tolerance breach	`tolerance_breach` (warning)	downgrades `allow` → `prepare` (hold)
Receipt shortfall	`receipt_shortfall` (warning)	downgrades `allow` → `prepare` (hold)

The canonical verdict is returned on result.guardian. See Compliance Guardian for the adapter, and the API Reference for the full signature.