OpenChainGraph Suite · ART-701

Three Way Invoice Match

Matches one invoice against its purchase order and its goods receipt and decides whether it can be paid. Every invoice line pairs to an unused PO line by declared po_line, then exact sku, then a free same-number PO line; there is no fuzzy text matching. Totals, tax and duplicate-invoice checks all run in integer minor units.

Three-Way MatchInteger Minor UnitsZero PIIClient-side only
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Scope & reliance
Each paired line takes the first verdict that applies in a fixed order: quantity over received, receipt missing (a two-way match, reported as a flag rather than a failure), quantity over ordered, or unit price outside the declared basis-point tolerance, where a variance exactly at the tolerance passes. Totals are recomputed from the line sum, half-up tax at one declared rate, and the total from those two. Prior invoices from the same vendor are screened on the normalized invoice number, same total inside the declared day window, or the same PO. Fractional quantities and sub-minor-unit prices are refused with a named reason, never rounded; one currency per invoice; no tax-jurisdiction logic; day differences come from integer days-from-civil arithmetic with no clock. No formal correctness proof exists for this node yet (compute_proof_ready: deferred); see the proof-status note below the results.
Invoice under test
Edit any field and run. The sample is fixture F1, the clean-match seal vector from the conformance set.
Result
Proof status
This node ships compute_proof_ready: deferred. No formal correctness proof has been produced for this kernel; the result above is a deterministic recompute, verified by a property-test floor, not a proven one.
Execution Hash & §4 Artifact
SHA-256 execution hash (JCS canonical, RFC 8785):