In my overview of AI agent examples, supplier invoices get one short section. That is enough to decide whether the idea fits your company. It is not enough to plan a build, because the work hides in the details. Where does the agent pick up an invoice? What does it do when the delivery note says 40 and the invoice says 50? Who gets the final word before money leaves the account?
This article follows one supplier invoice from the moment it arrives to the moment it sits in your accounting system. There are seven steps. For each one I describe what the agent does, what typically goes wrong and how a sensible build catches it. I write this as a description of how such an agent is put together, not as a client story. I have no client stories yet, and I won't invent one.
What has to exist before you build one
An invoice agent automates your accounts payable rules. If those rules live in one person's head, the agent has nothing to follow. Four things need to be in place first.
Clean vendor master data. One record per supplier, with a verified bank account, a tax ID and payment terms. Duplicate supplier records are the most common reason an agent matches an invoice to the wrong account, and the agent cannot tell which of two "Miller Supplies" entries is the real one.
Written approval rules. Who approves invoices for which cost centre, up to which amount, and who stands in during holidays. If today's answer is "it depends", write down what it depends on before anyone writes code.
Purchase orders and goods receipts that get booked on time. Matching only works if the receipt is in the system when the invoice arrives. If the warehouse books deliveries once a week, the agent will flag every invoice from the other six days as unmatched.
Coding rules for invoices without an order. Rent, utilities, software subscriptions and consultants rarely have a purchase order. Someone has to decide which GL account and cost centre each kind of spend goes to, and a year of past postings that follow those rules is the best training material you have.
If one of these is missing, fix it first. It costs less than building an agent around the gap.
The seven steps
1. Intake from the inbox or supplier portal
The agent watches the accounts payable mailbox and, where suppliers use them, the portals you log into to download invoices. If you receive structured e-invoices through a network, it reads those too. Each new document becomes one record with its source, arrival time and original file attached. A PDF that contains three invoices gets split into three records. Delivery notes and order confirmations sent to the same address get sorted out here, so they don't end up treated as invoices.
What goes wrong. Duplicates. The same invoice arrives by email and through the portal, or a payment reminder arrives with the original invoice attached again. The fix is a duplicate check on supplier, invoice number, date and amount before anything else happens. A near-duplicate, same supplier and amount but a different number, goes to a person instead of being processed or dropped.
2. Extraction
From a structured e-invoice the agent reads the fields directly, so there is nothing to guess. From a PDF or a scan it extracts the header, every line, the tax amounts and the bank details. Then it checks the arithmetic. Do the lines add up to the net total? Does net plus tax equal the gross amount? Does the tax rate match what the supplier normally charges?
What goes wrong. A plausible misread. A 7 read as a 1 still produces a tidy, believable number. A credit note read as an invoice turns a refund into a payment. A model's own confidence score does not catch these reliably, so the build should not rely on it. The arithmetic checks and a comparison against the vendor master catch most of them, for example a bank account that differs from the one on file. Anything that fails a check leaves this step flagged.
3. Matching against the purchase order and delivery note
For invoices with an order, the agent finds the purchase order and the goods receipt in your ERP and compares them line by line. Quantity and price have to agree within the tolerance you set, for example a small rounding difference or a fixed percentage on price. A clean three-way match moves on. A mismatch goes to the buyer with the line and the size of the difference named.
What goes wrong. Real purchasing is messy. A partial delivery gets invoiced in full, one invoice covers three orders, freight appears with no order line, or the supplier raised a price that nobody updated in the order. Each of these needs its own rule, and the build should decide which ones the agent may settle alone. I have written up the patterns where automated matching breaks, and most of them apply here.
4. Coding to GL account and cost centre
Invoices without an order need an account, a cost centre and a tax code. The agent proposes all three from the supplier's history, the line text and your written coding rules, and it shows its reason next to each proposal, such as "coded like the last six invoices from this supplier" or "rule: software subscriptions go to the software expense account".
What goes wrong. The agent copies last month when this month is different. A supplier that used to bill a subscription now bills a laptop, and an expense becomes an asset. A service from a supplier abroad needs a different tax treatment than the domestic one the agent saw last time. Treat a change in line text, amount range or tax rate as a reason to flag, and review a sample of the coding every week.
5. Exception handling
Everything that fails a check lands in a review queue. Each item carries the reason, the evidence and a drafted next step: a query to the supplier asking for a corrected invoice, a note to the buyer about the price difference, or a question to the cost centre owner. A person reads the draft and sends it, edits it or overrides the agent.
What goes wrong. The queue grows faster than anyone clears it. Then invoices miss their discount dates and suppliers start calling, and the agent has made the process slower than before. The other failure is a vague reason such as "low confidence", which forces the reviewer to redo the whole check. Size the queue before go-live and make each item answerable on one screen. The piece on an escalation queue people actually trust goes into how.
6. The human approval point
Here a person decides, every time. The agent never releases a payment. A person also approves every invoice from a new supplier, every invoice above your approval limit, every invoice coded to an account on a short sensitive list, and every change of bank details. Those limits sit in the connector code, so the agent cannot be talked past them by a cleverly worded invoice. Hard limits in code explains why a prompt instruction is not enough.
What goes wrong. Two things. The first is rubber-stamping. When the agent is right a hundred times in a row, the approver stops looking. Put the invoice, the order, the receipt and the agent's reasoning on one screen, and keep pulling samples that a second person checks in full. The second is fraud. A letter announcing new bank details looks exactly like a real one. The rule is to confirm by phone with a number from your own records, never the one printed on the letter, and the agent's job is to make sure no such change slips through unflagged.
7. Posting to the accounting system
Once approved, the agent writes the booking through your accounting system's API or import format, attaches the original document and records who approved what and when. The accounting system stays the system of record. The agent keeps its own log only to show how each proposal came about.
What goes wrong. A timeout and a retry can post the same invoice twice. Every write needs a unique key per invoice, so a second attempt changes nothing. A booking into a period that has already been closed, or a partial write where the header lands without the lines, needs a clear error and a person, not a silent fix.
A note on e-invoicing mandates
This depends on where you operate. Several European countries now require structured e-invoices between businesses, and more are adding rules. Germany, for example, has required every business to be able to receive them for domestic B2B invoices since 1 January 2025. Where structured data arrives, step 2 gets simpler and more reliable. It does not remove the PDF path. Foreign suppliers, small suppliers and transition periods keep PDFs coming for years, so plan the agent to handle both.
How to start
Start with read access and shadow mode. The agent processes a full month of real invoices next to your accounts payable team, writes nothing, and you compare its matching and coding with what your people did. Agree the pass mark before the run. Shadow mode explains how to set one up so it proves something. Give it two months if the first one includes a quarter end or a holiday period.
Cost depends mostly on how many systems the agent touches and how large the share of exceptions is. How much an AI agent costs to build goes through the drivers. If invoice processing is one part of a larger close, AI agents for the month-end close shows where it sits. Our agent build service takes one workflow like this from shadow mode into production on the software you already run.
Bring a month of invoices to a scoping call
Bring a sample of last month's supplier invoices, the awkward ones included, and your approval rules to a thirty-minute scoping call. We go through them with you, mark which steps an agent could take over and which stay with your team, and tell you what building the first version would cost. If your master data or approval rules need work first, you hear that too.