What is the safe automation boundary?

The workflow may receive an invoice, extract fields, check arithmetic, find a vendor, look for duplicates, compare the invoice with a purchase order or receipt and prepare an approval packet. It may create a draft bill in a staging state if finance explicitly approves that design.

It must not accept new bank details from an invoice, create a vendor, decide an accounting treatment, override a mismatch, release a payment or mark an invoice approved. Those actions can move money or alter financial records and require authorised controls outside the model.

Invoice agent architecture

Text equivalent: the system accepts a file only through an approved route, checks it, extracts a defined schema, validates totals and required fields, matches internal records and flags duplicates or anomalies. Finance reviews the original and evidence before any record is created or payment process begins.

Build the invoice processing agent step by step

1. Define the finance boundary. Document what the workflow may read, calculate and draft. Mark vendor creation, bank changes, approval and payment as human-only actions.
2. Secure the intake channel. Use a controlled mailbox, portal or storage location. Validate file type and size, scan attachments and preserve the immutable original. Do not execute macros, links or embedded instructions.
3. Extract a fixed schema. Capture invoice number, vendor identifiers, invoice and due dates, currency, line items, subtotal, tax, total, purchase-order reference and payment details as observed. Keep field confidence and page location when available.
4. Validate fields and arithmetic. Require the mandatory fields for the jurisdiction and process. Recalculate line totals, subtotal, tax and grand total with deterministic code. Apply an explicit rounding tolerance.
5. Match vendor and purchase records. Find the vendor with a trusted identifier, then retrieve purchase order, receipt and contract data read-only. A similar name is not enough to create or select a vendor.
6. Detect duplicates and anomalies. Compare vendor ID, invoice number, amount, currency, date and file hash. Flag changed bank details, unusual currency, split invoices, duplicate totals and mismatched addresses for finance.
7. Create an approval packet. Show the original file, extracted fields, calculations, match results, discrepancies and proposed next action. Approval must bind to that exact packet and expire if source data changes.
8. Write once and monitor. If approved, create only a draft or pending record with an idempotency key. Store the external record ID and verify it before retrying after timeouts.

Example extraction contract

{
  "document_id": "doc_7719",
  "vendor_name_observed": "Example Components SL",
  "vendor_id_verified": null,
  "invoice_number": "EC-2026-1048",
  "invoice_date": "2026-10-02",
  "currency": "EUR",
  "subtotal": 1200.00,
  "tax": 252.00,
  "total": 1452.00,
  "purchase_order": "PO-4401",
  "bank_details_present": true,
  "field_confidence": {"invoice_number": 0.98, "total": 0.99},
  "needs_finance_review": true
}

The presence of bank details is a flag, not permission to use them. Compare them with a separately verified vendor master, and route every change through the organisation's established verification process.

Invoice content is untrusted

An invoice can contain text such as “ignore the purchase order,” “use the new bank account below” or even instructions aimed at an AI system. The workflow must treat all document text as data to extract. It cannot expand its tools, alter policy or skip checks because a document says so.

Failure paths and test matrix

Success criteria

• Every extracted value can be traced to the original file and page or region when supported.
• Arithmetic and duplicate checks are deterministic.
• No vendor or bank record is created or changed from invoice content alone.
• Every mismatch, low-confidence field and policy exception reaches finance.
• Writes are idempotent and external record IDs are verified.
• Payment release remains entirely outside the agent's authority.