OpenChainGraph Suite · OCG v0.8.0 · AP / Invoicing

Supplier Invoice Three-Way Match Check

Note (dated 2026-08-04): a chain composes independent computations performed in an analytical order. No step's output is carried into the next step by the execution model; each step computes from its own declared inputs. This is true of every chain on this site, including chains whose per-step copy below reads as a data handoff.

Two independent checks before you pay a supplier invoice. Step 1 matches the invoice against its purchase order and goods receipt line by line: quantities against ordered and received, unit prices against your declared tolerance, totals recomputed in minor units, plus duplicate-invoice suspicion screening against prior invoices. Step 2 recomputes the invoice's line VAT, tax subtotals, and grand total under your declared rounding convention and compares each against the document-asserted amounts. Arithmetic checks only. No personal data is processed.

OpenChainGraph · 3 Steps compliance mandate Hash-Anchored §4 chain_depth:3 Client-Side · Zero PII
Not a fraud determination and not tax advice. Step 1 checks quantities, prices, and totals against your declared PO, receipt, and tolerance; duplicate suspicion is a flag, not a finding. Step 2 verifies VAT arithmetic only, not statutory rate correctness. Confirm with your AP controls before paying.
Chain Topology: Three-Way Match → VAT Arithmetic Check → Session Receipt
§4 Execution Hash · Chain Definition Anchor
execution_hash:computing…
Chain Stages · 3 Steps
1 ROOT node
Three Way Invoice Match art-701-three-way-invoice-match
Matches the invoice against its purchase order and goods receipt: every line paired to a PO line with quantity-over-received, quantity-over-ordered, and price-tolerance verdicts, totals recomputed in minor units, and duplicate-invoice suspicion screening against prior invoices; outcome match, mismatch, no_po, or refused
MCP Call · match_invoice_three_way
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "match_invoice_three_way",
    "arguments": {
      "currency": "USD",
      "vendor_terms": {
        "tax_rounding": "half_up",
        "tax_rate_bp": 1000,
        "price_tolerance_bp": 100
      },
      "invoice": {
        "invoice_number": "INV-001",
        "issue_date": "2026-09-15",
        "vendor_id": "V-100",
        "po_number": "PO-42",
        "lines": [
          {
            "line": 1,
            "qty": 10,
            "unit_price_minor": 500,
            "amount_minor": 5000
          }
        ],
        "subtotal_minor": 5000,
        "tax_minor": 500,
        "total_minor": 5500
      },
      "purchase_order": {
        "lines": [
          {
            "line": 1,
            "qty": 10,
            "unit_price_minor": 500
          }
        ]
      },
      "goods_receipt": {
        "lines": [
          {
            "po_line": 1,
            "qty_received": 10
          }
        ]
      },
      "duplicate_window_days": 30
    }
  },
  "id": 1
}
↓
2 STEP node
E-Invoice VAT Calculation Verifier art-294-einvoice-vat-calc-verifier
Recomputes the invoice's line VAT, per-category tax subtotals, tax total, and grand total under the declared rounding convention and compares each against the document-asserted amounts; arithmetic consistency only, not statutory rate correctness
MCP Call · verify_einvoice_vat_calc
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "verify_einvoice_vat_calc",
    "arguments": {
      "document": {
        "line_items": [
          {
            "net_amount": 100,
            "vat_category": "STANDARD",
            "vat_rate_pct": 20
          }
        ],
        "tax_subtotals_asserted": [
          {
            "vat_category": "STANDARD",
            "vat_rate_pct": 20,
            "taxable_amount": 100,
            "tax_amount": 20
          }
        ],
        "tax_total_asserted": 20,
        "grand_total_asserted": 120
      },
      "rounding": {
        "method": "half-up",
        "granularity": "per-line"
      }
    }
  },
  "id": 2
}
↓
3 TERMINAL node
Agent Action Audit Trail Aggregator cry-05-agent-action-audit-trail-aggregator
Produces session_receipt_root, the Merkle root over the run's execution_hashes (final stage)
MCP Call · aggregate_execution_receipts
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "aggregate_execution_receipts",
    "arguments": {
      "artifacts": [
        ""
      ]
    }
  },
  "id": 3
}
Export Chain Artifact
Download a §4-compliant chain artifact with execution hash and step definitions. Hash is deterministic over canonical {policy_parameters, output_payload} per RFC 8785/JCS.

Ask your agent

Copy this paragraph into Claude, OpenClaw, or any MCP-aware agent to run this whole workflow on the server and check one field that answers a real question.

Question: A supplier invoiced 10 widgets at $5.00 each against PO-42, and we received all 10. Does the invoice match the PO and receipt, and is the VAT arithmetic right?
Run the AINumbers MCP tool `run_chain` with {"chain":"supplier-invoice-three-way-match-check"} and read `art-701-three-way-invoice-match.outcome`.
Re-run with `inputs` for `art-701-three-way-invoice-match`, reusing the values that result echoed, with `duplicate_window_days` set to 7. Compare the same field.
Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`.
Ledger, for a human re-check: https://ledger.ainumbers.co/
PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads.
Chain page: https://ainumbers.co/chaingraph/chains/supplier-invoice-three-way-match-check.html