Build a governed invoice approval agent: LLM reads, policy decides

The Problem

Your accounts-payable team processes thousands of invoices a month, and the routing rules live in people's heads and a wiki page nobody reads. An invoice over a threshold should go to the CFO; one without a purchase order needs extra scrutiny. In practice, routing is inconsistent, exceptions take three email chains, and when a SOX auditor asks "who approved this $47,000 invoice and under what control," the answer is a spreadsheet and a shrug.

Why a Black-Box LLM Fails Here

The obvious move is to paste the invoice into an LLM and ask "approve or escalate?" Two minutes of demo magic, then it falls apart:

• Not explainable. The model says "escalate, 0.83 confidence." Your auditor needs "escalated because the amount exceeded the $25,000 PO-less threshold." Confidence scores are not controls.
• Not consistent. The same invoice can get different answers on different runs. A financial control that is not deterministic is not a control.
• Not auditable. Logging a prompt and a completion does not tell you which policy rule applied.

The Governed Architecture

A governed agent separates the three jobs that a black-box LLM dangerously fuses:

• The LLM reads. It extracts structured fields from the unstructured invoice text — and nothing else. It never decides.
• A DMN policy table decides. A deterministic decision table maps the extracted fields to an outcome. Same inputs, same outcome, every time. The row that fired is the explanation.
• BPMN routes. The business process sends the decision to the right approver and records the audit trail.

Try It Live

Go to archiet.com/agents and open the Invoice Approval agent. In the text box, type:

Invoice #INV-4521 from Vertex Systems for $47,200. No purchase order
attached. Payment terms Net-30. Capital expenditure.

Click Run governed agent. Here is what happens:

1. The LLM extracts (and is shown to you as read-only — "AI read this; it does not decide what happens next"):

{
  "invoice_number": "INV-4521",
  "supplier": "Vertex Systems",
  "amount": 47200,
  "po_attached": false,
  "category": "capital_expenditure"
}

2. The DMN policy table evaluates {amount: 47200, po_attached: false} and fires the rule: amount > $25,000 AND no PO → route to CFO, escalation required.

3. BPMN routes the invoice to the CFO approval step.

4. The audit trail records:

• Which rule fired (INV-RULE-CFO-NOPO)
• Why (amount $47,200 exceeded $25,000 with no PO attached)
• What the LLM extracted (the raw JSON above)
• Timestamp, agent version, policy table version

Every part is reconstructable. An auditor can replay any decision from the log.

The Regulatory Angle: SOX §404

The Sarbanes-Oxley Act §404 requires management to establish and document internal controls over financial reporting — and to produce evidence those controls operated. An invoice approval policy that is a deterministic DMN table, with every decision logged and the firing rule recorded, is that control. You are not writing a memo describing a control that lives in someone's judgement; the control is the table, and the audit trail is the operating evidence.

Generate This for Your Own System

When you describe an accounts-payable or procurement workflow in Archiet's Blueprint Wizard, the governed invoice agent is generated alongside your application code:

• The DMN policy model (with your thresholds extracted from your PRD — if you wrote "invoices over £10,000 need director sign-off," that £10,000 becomes the threshold)
• The decision engine runtime
• The /extract, /policy, and /decide API endpoints
• Frontend components for the agent interface

Your policy, your thresholds, your approvers — generated, wired, and auditable.

---

The same BPMN + DMN + bounded-LLM pattern powers the loan adjudication, FNOL triage, prior authorisation, refund/retention, and KYC/AML agents in the gallery. The architecture is identical; only the policy table changes.