AI invoice processing that survives an audit: extraction, validation, and the human gate

Accounts payable is the most requested automation I get, and for good reason: someone is opening PDFs, reading numbers, and typing them into an accounting system. It's the definition of work a machine should do.

It's also the fastest way to automate a financial loss if you build it naively.

The failure mode you're designing against

A language model reads an invoice and returns $1,500.00 where the document says $15,000.00. It does this with complete confidence, no error, no exception. The next step in your workflow posts it. Nobody notices until reconciliation.

Every design decision below exists to catch that.

The architecture

Layer 1 — Get clean text out first.

Don't hand a raw scanned PDF to a general model and hope. Use a dedicated document-understanding service (Azure Document Intelligence, AWS Textract, Google Document AI) to get structured text with positional data. These are trained specifically on documents and give you confidence scores per field, which a general chat model won't.

For clean digital PDFs, straight text extraction is fine and cheaper.

Layer 2 — Extract to a strict schema.

The model's job is narrow: turn text into structured fields. Force it into a schema — vendor name, invoice number, invoice date, due date, line items, subtotal, tax, total, PO number. Use structured output / tool calling so you get validated JSON rather than prose you have to parse.

Layer 3 — Validate with arithmetic, not with the model.

This is the layer people skip, and it's the one that catches the $1,500 error:

• Do the line items sum to the subtotal?
• Does subtotal plus tax equal the stated total?
• Is the invoice number new, or have we seen it before? (Duplicate payment is the second most common AP loss.)
• Does the vendor exist in the accounting system?
• If there's a PO number, does the amount match the PO within tolerance?
• Is the total within the historical range for this vendor?

Arithmetic doesn't hallucinate. If the math doesn't reconcile, the document goes to a human — no exceptions, no confidence threshold override.

Layer 4 — Route by risk, not by confidence.

Confidence scores are a weak signal. Route on business rules instead:

Condition	Route
Under $500, known vendor, math checks, matches PO	Auto-post
Any validation failure	Human review, always
New vendor, first invoice	Human review, always
Over threshold (I usually start at $2,500)	Human approval
Bank details differ from vendor record	Stop. Flag as possible fraud.

That last row is not optional. Vendor bank-detail changes are the mechanism behind business email compromise, which costs companies far more than duplicate payments.

Layer 5 — Log everything, immutably.

For each invoice: the source document, the extracted JSON, which model and version produced it, which validations passed and failed, who approved it, and when. When an auditor asks how a payment was authorized, "the AI did it" is not an answer. The log is.

What this gets you honestly

Not "zero-touch AP." Anyone promising that is selling.

What you get is the 80% of invoices that are small, routine, from known vendors, and arithmetically clean flowing through without a person, and the 20% that are genuinely ambiguous landing in a queue with the extraction already done. The person's job shifts from typing to deciding.

For a company processing a few hundred invoices a month, that's typically most of a full-time role returned to higher-value work — and a duplicate-payment catch rate better than the manual process, because software never gets tired on a Friday afternoon.

Where to start

Run it in shadow mode for a month. Extract and validate every invoice, post nothing, and compare against what the humans actually entered. You'll find two things: the model's real accuracy on your documents, and several errors your manual process has been making for years.

---

The takeaway: the model extracts, arithmetic validates, and business rules route. Never let confidence alone authorize a payment.