Procurement as a Governed Agent Run
Purchasing, intercompany billing, three-way match, dispute clearing, and settlement run end to end, with ERP and treasury links instead of manual handoffs.
Connect the spend controls and write the procurement policy
Connect Ramp for governed cards, spend limits, and approvals, and Stripe, Brex, or Mercury for the payment and banking side. The limits you set in Ramp are the guardrails the run operates inside, so autonomy stays bounded.
Write your procurement policy as a playbook, a reusable, named set of steps: what needs a PO, the three-way match tolerance, who approves above which amount, and when to escalate. The run never invents policy; it follows this.
Playbook: !procure-to-pay For each purchase request or incoming invoice: 1. Intake: capture vendor, amount, PO number, and line items. 2. Three-way match: reconcile invoice against the PO and the goods-receipt. Allow a variance up to [tolerance]. 3. Dispute: if it fails to match, gather the mismatch and open a dispute; do not pay. 4. Pay: within Ramp limits and approval rules, post approved spend and attach the receipt. 5. Escalate anything over [threshold] or outside policy to a human.
Give the run read-only access to the ERP so it can confirm the PO and receipt itself, instead of trusting the invoice's own claim about what was ordered.
Trigger the run on new requests and invoices
Procurement should move without a person forwarding each invoice. Point your intake (an inbox, a queue, or an ERP webhook) at a run so a new invoice or purchase request starts the !procure-to-pay playbook automatically.
For lower volume, a schedule works: sweep the intake folder and open invoices twice a day. Set it under Settings, then Schedules, choose the playbook, and route the summary to your finance Slack channel.
The sharp edge: a run with pay authority and a loose match tolerance will pay a wrong invoice cleanly. Start with a tight tolerance and a low escalation threshold, then loosen only once the matches prove reliable.
Watch one invoice clear the match
Take an invoice that arrives against an open PO:
The run matches before it pays and stops on a mismatch instead of forcing it through.
Invoice: INV-8841, vendor Acme Parts, $12,480 Run actions: - Intake: matched to PO-3120 (12,000) and receipt GR-2290. - Three-way match: invoice is $480 over the PO, 4%, above the 2% tolerance. - Did not pay. Opened a dispute noting the overage and the two extra line items not on the PO. - Routed to the buyer with the mismatch spelled out. - Logged the whole check to the audit trail with links to PO, receipt, and invoice.
What the run settles and records
When the run finishes, each invoice is either paid correctly or held with a reason, all verifiable:
Matched invoices paid within Ramp's limits, each with its receipt attached and coded to the right account. Disputes opened on mismatches, with the exact variance named. Escalations routed to a human for anything outside policy. An ERP reconciliation showing every record tied out.
The audit trail is the proof-of-work: for each invoice it records what was matched, what was paid or held, and who approved it, so a controller can retrace any payment.
Sharpen the procurement loop
When the run keeps escalating a case it could handle, add the rule to !procure-to-pay, or write it into memory (the notes a run recalls next time), like "freight surcharges up to 5% on this vendor are expected, not a mismatch".
Review disputes weekly; teaching Opulent how you resolved each one shrinks the escalation queue and tightens the match logic.
The natural chain: extend into Opulent x Ramp: Controllable Autonomous Finance so the same governed layer also handles coding, reporting, and reconciliation across all spend, not just purchase orders.