Invoice Document Processing Agent Blueprint

Ask an accounts payable lead what lands in the inbox on a Monday and you will not hear "data." You will hear about a scanned invoice photographed slightly crooked, one file holding three invoices and a delivery note, a credit note with no explanation, and a supplier asking why last month's bill still has not been paid. The documents are the job. Everything after them waits on somebody reading paper.

This open blueprint, the Reducto Invoice AP deployment, starts from a division of labour we think AP automation keeps getting wrong. Reading documents is a document platform's job, and Reducto does it: sorting what each document is, splitting bundles into their separate pieces, pulling the fields out with a pointer back to where each value sits on the page. Deciding whether an invoice should be paid is a different kind of work entirely. That part belongs to arithmetic and to named people, and the blueprint keeps it there.

Where the reading happens is also a decision, not a default. Supplier invoices are among the most sensitive documents a company holds, so the same deployment runs two ways: against the hosted document service, or with the reading engine inside the company's own network boundary, where document traffic never leaves. Same pipeline, same checks either way. The difference is geography, and for a finance team geography is often the whole argument.

The match is arithmetic

An invoice earns its place in a payment batch by agreeing with two other records: the purchase order that authorised the spend, and the goods receipt that says the delivery actually arrived. The blueprint checks all three against each other — line against line, quantity against quantity, totals against totals — in code, under tolerances written down as policy that anyone can read.

Tolerances matter because documents are noisy. A supplier's price drifts a little between the order and the bill, and a system that treats every drift as a crisis floods the exception queue until nobody trusts it. So a drift inside tolerance passes, with the drift shown on the record rather than buried. A drift outside it becomes an exception with the reason and the figures attached: the price moved, the quantity billed exceeds what arrived, a line appears that no order carries, the document contradicts its own totals. The person who picks it up starts from the disagreement, not from a blank page.

Some documents never get that far. What arrives labelled as paperwork is not always an invoice: a supplier statement looks bill-shaped and asks, in effect, to be paid. The blueprint refuses anything that is not payable, with the reason on the record. The statement is not wasted work, though — it gets read anyway, and its lines are checked against the books so the monthly argument about whose list is right happens from evidence.

One invoice, start to finish

Follow a single ordinary invoice through. It arrives inside a bundle, is sorted out as an invoice, split from its neighbours, and read: supplier, number, dates, lines, totals, each value carrying its citation back to the page. The screens run. Its supplier is known, its bank details agree with the approved record, and it is not a second copy of something already paid.

Then the match. Most lines agree exactly with the order and the receipt. One line's price has drifted, inside tolerance, so that fact rides on the record where the approver will see it. Nothing is left for a model to have an opinion about: the invoice matched, with the drift disclosed.

At the gate, a named approver reads the record — the match, the drift, a credit note the supplier issued against this invoice and that has been applied against the amount owed — and approves or rejects it, with a reason either way. What approval produces is a proposed payment: this supplier, this invoice, the amount still open after the credit. A treasurer later assembles proposals into a batch, and when the bank reports back what it actually paid, that answer is checked to the cent, not to a tolerance. Money that left is not a document; a small shortfall is a question for a person, not rounding.

The oldest fraud in the book

The screen that matters most is the quietest. The classic payment-diversion fraud does not hack anything; it sends a perfectly ordinary invoice that asks to be paid to a different bank account. Everything matches. The order is real, the goods arrived, the totals agree. Only the destination changed.

So the blueprint compares the account on the invoice against the supplier's approved account, as it stood on the invoice's own date. Suppliers do change banks legitimately, and last month's genuine account should not convict this month's invoice, nor bless a future one quoted early. Any account that was not the approved one on that date stops the record at fraud review. And here is the part we would defend in an argument: the approver cannot clear it. The gate refuses to decide a fraud-held record at all, because a bank change is not verified by clicking approve on the document that requested it. It is verified out of band, with the supplier, then recorded on the supplier's own record, after which new invoices are read against the corrected history. The same discipline runs the other way at payment time: payment instructions are built from the approved supplier record, never from the invoice. An invoice is a claim by its sender. It does not get to name its own destination.

A close cousin gets its own stop: an invoice that arrives after its twin was already approved and paid. It reads cleanly and matches its order, because the twin is no longer pending anywhere. The blueprint checks arrivals against what has actually been paid and holds the second copy with the payment evidence on its face, for a controller to rule on. Paying twice is the failure this entire system exists to prevent, so it gets a dedicated tripwire rather than a line in a duplicate check.

What it does not do

Honesty about the edges, since AP is a poor place for surprises. The document engine's hosted service has not yet been exercised live from this blueprint. The checks and gates are tested end to end against a stand-in reader that works from the text documents carry, which is a weaker thing than reading scanned paper, and a real deployment's first job is proving the reading against its own invoice pile. A credit note that arrives after its invoice has already been paid stays visible on the record, unapplied, with its reason; carrying a supplier's credit balance forward onto future invoices is a ledger this blueprint deliberately does not build. And the boundary at the far end is the design, not an omission: the system proposes payments and assembles controlled batches for the company's own payment systems. It executes nothing. If a figure leaves the bank, some other system, with its own controls, sent it, and a person in this one said it could go.

Work with us

If your AP team spends its week reading documents by hand so that a small number of judgement calls can happen at the end of it — and if the fraud you actually worry about is an ordinary invoice pointing at an extraordinary bank account — start with Trida AI's intake: tell us about your invoice volume and your approval chain, and we will talk through what this deployment looks like inside your boundary.

Get the Code on GitHub: github.com/tridaai/blueprint-reducto-invoice-ap