An invoice that doesn't match the purchase order cannot be paid.
Not by policy — by construction. Procure is procure-to-pay for companies whose treasury is onchain: purchase requests, approvals, orders, goods receipt, vendor invoicing and a three-way match that settles in USDC on Arc.
Spend software normally enforces these rules in application code, which means they hold exactly as long as the application does. Here they live in a contract. Compromise the server and you still cannot pay an unapproved vendor an unapproved amount.
The cycle
- 01Request and approve
Anyone raises a request against their department's budget. Approvers sign it with their own wallet — free, instant, no gas, no transaction.
- 02Order
A purchaser issues the order and its terms are fixed onchain before anyone can act on them. Approving one figure and paying another becomes impossible.
- 03Receive and invoice
The requesting side confirms delivery — never whoever pays. The vendor invoices from their own portal, typing their own figure.
- 04Match and settle
Order, receipt and invoice are compared. If they agree, the contract verifies the signatures and moves the USDC. If they don't, it reverts.
Not rows in our database. The contract recovers each one and counts it against an onchain approver set before releasing anything.
Every payout address is checked across three chains via The Graph. Blocked vendors leave the onchain allowlist, so screening is a rule the chain keeps.
Double-entry throughout. GR/IR clearing nets to zero only when what arrived and what was invoiced agree — so the exception report can't be ignored.
It cannot verify that goods arrived or that an invoice is genuine — those are assertions the approvers sign about. What it enforces is that the approvers this organisation registered, in sufficient number, signed for exactly this payee and this amount against this order, once, within budget, to a screened vendor.