Solutions · Finance and payables
Invoices routed and coded inside the limit. Approval and payment stay with a named person.
Accounts payable is the same work every week: the same suppliers, the same coding, the same limits, settled the same way. Razoo learns the routing and the coding from the approvals your team already makes, and keeps the payment itself behind a person, always.
How it works
A handful of lines in the agent folder carry the whole policy.
An AP agent is a folder of YAML: the fields it reads and their sensitivity, the rules that run before any model, the process steps and their kinds, and the actions it may stage. Your finance lead can read every line. Nothing is hidden in a prompt.
Plumbing first
Purchase-order match, supplier lookup, duplicate check, and limit comparison are deterministic rungs. Zero tokens, fully replayable.
Reasoning only for the residual
An invoice with no PO and an unfamiliar description goes to a model on a token contract. The model may suggest a coding. It stages, it does not post.
Judgment for money
Approval and payment are judgment steps. The approver's choice is recorded with their name and becomes evidence for the learned rung.
Delegated limits
The agent declares who may approve up to what. An invoice under the limit from a matched purchase order can be routed and coded by a rule. Above it, the ladder stops at judgment.
Known suppliers
A supplier the business has paid before, with a matching bank detail on file, is a field the rule may read. A new supplier, or a changed bank detail, is never learnable and always a person.
money_legal on the amount
The invoice amount is declared money_legal in fields.yaml. That single line means no rule, no pattern, and no model can execute anything that touches it. A person confirms. No envelope or confidence can override it.
The AP queue
What the approver sees on a Tuesday.
Most rows resolved before anyone looked. The ones that did not carry the reason: over the limit, a new supplier, a coding the rule has not earned yet. Each staged action has its own Confirm, and the payment row always needs one.
- A rule fires at zero tokens and the row says which rule and which version.
- A learned pattern fires inside its envelope and shows the replay that certified it.
- A money_legal row shows the amount, the recipient, and the envelope, and waits for a named person.
- One click on Was this wrong? records a counterexample and the pattern stops firing.
- Hartley Stationery642.10Rule
PO matched · coded 6210 · rule ap.under_limit v1
- Meridian Cleaning1,980.00Learned
routed to the approver · learned · certified by replay
- Northgate Pty Ltd12,400.00Human
above delegated limit · needs a named approver
- Unknown: Bexley Freight3,120.55Human
new supplier · never learnable
- Harbour Build4,750.00Model
no PO · capable tier suggested 6320 · staged
Staged · Northgate Pty Ltd
12,400.00 to Northgate Pty Ltd · envelope: money_legal · confirm required
Resolved without a model
11 of 17
Tokens today
2,340
Payments auto-executed
0 · ever
Learned versus never
What gets learned, and what never auto-executes.
The learnable fields are declared. Identity keys and money_legal fields cannot be declared learnable; doctor refuses the file. So the miner can only ever propose patterns over the fields you chose, and the payment is structurally outside its reach.
Routinglearned
GL codinglearned
Vendor matchinglearned
Exception triagelearned
Paymentsalways human
Approvals over the limitalways human
New suppliers and changed bank detailsalways human
Anything the rule was not certified foralways human
The agent folder
Readable by your finance lead. Validated by doctor.
You never have to write this. The onboarding interview asks about limits, approvers, and suppliers in plain language and writes the folder. Doctor validates it and names the file and the fix when something is wrong. Simulate replays synthetic history and shows a simulated week before anything goes live.
- Rule conditions are a closed AST: field, eq, gte, lte, exists, all, any. No expressions, no code.
- Numbers are compared as numbers. A string amount is a type mismatch and goes to judgment rather than silently failing to match a money rule.
- Actions live in actions.yaml. money_legal true with auto_confirm true is a doctor error, and the runtime refuses it anyway.
- A connector YAML can map a confirmed action to your ERP over HTTPS, with the secret by reference. Confirm still comes first.
fields: - key: amount sensitivity: money_legal # a person, always ai_capability: suggest - key: supplier_known sensitivity: normal learnable: true - key: po_matched sensitivity: normal learnable: true - key: cost_centre sensitivity: normal ai_capability: prefill learnable: true - key: supplier_bank_detail sensitivity: money_legal # never learnable; doctor refuses it
id: ap.over_delegated_limit version: "1" when: field: amount gte: 5000 then: verdict: flag severity: high message: Above the delegated limit. Route to the named approver. # a string "5000" does not match gte 5000; a mismatch queues judgment
illustrative agent folder, authored the way the reference agents in the repository are
Four eyes, and a page when you are needed.
The two things finance teams ask for first.
Four-eyes confirm
A per-agent confirm policy with a second-approver threshold. Above the amount, the second confirm must come from a different named user, and doctor validates the policy. The money_legal confirm itself opens a modal showing the amount, the recipient, the envelope, and requires a reason.
Approver notifications
An outbox job enqueued in the same transaction as any money_legal staged row, delivered by email, Slack, Teams, or a signed webhook, so the queue comes to the approver instead of waiting to be noticed.
Bring one month of invoices. We will show you what stops needing a model.
Design partners in finance run the AP agent on real traffic behind their own network, with every approval attributed and every payment behind a person.