ProcureLock — a receipt rail for every state of procure-to-pay.

Every transition in a B2B procurement cycle — request, quote, purchase order, PO acknowledgement, advance shipping notice, goods receipt, invoice, payment — bound to a dual-signed, post-quantum-ready receipt. Buyers, suppliers, ERPs, and procurement networks verify the chain offline. Live in production today.

What ProcureLock is

ProcureLock is the receipt-rail surface for procure-to-pay (P2P) and order-to-cash (O2C) flows. Every state transition in the procurement pipeline — purchase request raised, quote received, PO issued, PO acknowledged by the supplier, advance shipping notice transmitted, goods receipt confirmed, invoice received, payment disbursed — produces a dual-signed (Ed25519 + ML-DSA-65) post-quantum-ready receipt that any party in the cycle can verify offline.

Goods-receipt, invoice, and payment attestations validate cryptographic chain-of-custody from the prior po_issued receipt and enforce a true three-way match at protocol level. The chain_verify primitive returns the entire history for a PO, in canonical order, with any state-machine gaps, quantity mismatches, or price variances called out explicitly. ProcureLock is live on hivemorph today at /v1/procurelock/*.

EDI standards coverage

ProcureLock field semantics align with the four EDI dialects a global procurement function already speaks. Receipts drop into existing ERP, P2P, and supplier-network stacks without translation.

The 10 MCP tools

Live well-known manifest at hivemorph.onrender.com/v1/procurelock/health. Contact for MCP integration credentials.

The attestation envelope

Every event_attest call returns an envelope containing: buyer DID, supplier DID, PO number, line item identifiers, event type, event hash, timestamp, optional carrier / 3PL / financier DIDs, optional ERP correlation id (SAP IDoc number, Coupa transaction id, Ariba network id), monetary value, currency code, and dual signatures (Ed25519 + ML-DSA-65). The signatures bind every field. Any tamper attempt invalidates verification.

The envelope is CBOR-canonical. Verification works offline against the issuer's published public keys — no Hive call required. ML-DSA-65 (NIST FIPS 204) is the post-quantum signature; Ed25519 (RFC 8032) provides classical assurance. Both must verify for the receipt to be valid.

Three-way match enforcement

The procure-to-pay state machine has a defined topology. A goods receipt cannot precede a PO. An invoice cannot be paid without a matched goods receipt. ProcureLock enforces this at protocol level — three_way_match compares PO line items, goods receipt quantities, and invoice amounts and emits explicit variance codes for any over-shipment, short-ship, price discrepancy, tax mismatch, or quantity gap. chain_verify reports out-of-order transitions, missing states, or unmatched cycles with discrepancy codes.

Cancellations, reversals, and credit memos are valid from any state. Each is its own attestation, signed by the originating party, anchored against the prior chain.

Deployment patterns

• ERP sidecar — a small daemon co-located with SAP / Oracle / NetSuite / D365 that fires event_attest at every IDoc / business object lifecycle event with sub-second impact.
• Procurement-network bridge — Coupa, Ariba, or Jaggaer call event_attest at each cXML round-trip; suppliers and buyers verify offline against the receipt rail without changing their integration shape.
• Carrier / 3PL integration — the carrier hits event_attest for ASN and proof-of-delivery events with chain-of-custody to the prior po_issued receipt, making the shipment leg tamper-evident.
• Audit / SOX / financier verification — the auditor or supply-chain financier runs chain_verify + three_way_match against the PO and gets a full canonical history, signed end-to-end.

Pricing

Settlement: USDC on Base 8453 via x402. Volume contracts available for Tier-1 buyers and procurement networks above 10M events / year.

Field map

ProcureLock binds every procurement state to a dual-signed receipt that drops cleanly into existing ERP and procurement-network infrastructure. Each attestation accepts the procurement-native correlation fields below; the receipt envelope round-trips through standard X12 / EDIFACT / cXML / IDoc transports via the Hive Receipt primitive.

Receipt envelopes are CBOR-canonical and fit inside any X12 / EDIFACT / cXML / IDoc transport. Cross with DeedLock when the procurement leg has a real-estate component, or stamp directly into Coupa / Ariba / SAP S/4HANA / Oracle Procurement Cloud pipelines.

Hive runs the receipt rail underneath the broader A2A · agent-to-agent commerce category.