Accounts payable is where many small finance teams lose their week, and not to hard decisions. It is a queue. Invoices arrive by email as PDFs, someone opens each one, finds the purchase order, checks the delivery, keys the numbers into the ledger, and asks a colleague about the one that does not match. Most of that is looking things up and comparing them, which is the kind of work an agent does well, as long as the payment itself stays with a person.
§ 01Where an agent takes the work
- Invoice intake. Invoices come into a shared inbox in every format there is. The agent reads the PDF or the email body, pulls out supplier, invoice number, date, lines, VAT and total, and puts them into one consistent record. A repeated invoice number from the same supplier is flagged before anything is posted.
- Three-way matching. The agent compares the invoice with the purchase order and the delivery note or goods received record. Quantities and prices inside your tolerance go through as matched. Anything outside it goes to a person with the two figures side by side and the reason it failed.
- Coding suggestions. For suppliers you have coded before, the agent proposes the nominal code, cost centre and VAT rate from your history and says how sure it is. A bookkeeper confirms with a click instead of typing.
- Supplier statement reconciliation. Matching a monthly statement against your ledger is slow, repetitive comparison. The agent lists what agrees, what is missing on either side, and what looks like a timing difference.
- Chasing. A missing purchase order number, a query on an unclear invoice, an approval sitting with a budget holder: these are all follow-up emails. The agent sends the reminder and logs the answer.
- Payment run preparation. The agent assembles the invoices that are due, marks anything on hold or unmatched, and hands the batch to whoever approves it.
The pattern is the same in all six: read from your systems, prepare the output, and hand anything unusual to a person. That narrow definition is why these deployments hold up. The engineering behind it is written up in our Lab notes.
§ 02Where a person stays in charge
- Releasing payments. The agent prepares the run and a person approves it. Money leaving the account is the one step you cannot fix with an edit, so we build it as an approval step and not as a setting. How that approval queue works.
- Changes to supplier bank details. This is where invoice fraud lives. The agent should never act on an email asking to update bank details. It flags it, and someone rings the supplier on a number you already have.
- Disputes and credit notes. Whether to accept a short delivery or push back on a price depends on the relationship with the supplier, and that is not in any system.
- Unusual VAT treatment, accruals, and anything at month end that needs a judgement about which period a cost belongs in.
- Anything above a value you set. Large invoices get a human look however well they matched.
§ 03What actually goes wrong
It is rarely the reading of invoices. Current models extract invoice fields well. The trouble is everything around it.
- Purchase orders that do not exist. Matching needs something to match against. If half your spend is invoiced without a PO, the agent has nothing to compare with and you are really building a coding assistant. That is still useful, but scope it as that.
- Delivery data that lives on paper or in someone's head. A three-way match without a goods received record is a two-way match. Decide supplier by supplier whether that is acceptable.
- Accounting software with limited access. Cloud packages with documented APIs are straightforward. A desktop system that only imports files needs an adapter, and the adapter often takes more effort than the agent.
- Tolerance rules nobody has written down. The agent needs a number for how far apart an order and an invoice can be. Most teams find in the first week that the rule they follow is not the one they would have written.
§ 04Start read-only, then earn write access
The first version reads the inbox and the ledger, prepares the match and the coding suggestion, and writes nothing. A bookkeeper reviews a queue instead of building it. Then track one number: how often the person changes the suggestion. If it is high, the rules or the data are wrong, and you found that out for the price of a small build. If it is low and stable, let the agent post the routine, fully matched invoices itself and keep the queue for exceptions. Payment release stays manual the whole way.
§ 05Cost and timing
A single agent covering one part of the process costs 3,000 to 5,000 USD and takes 2 to 3 weeks. A coordinated set covering intake, matching, statement reconciliation and payment run preparation costs 15,000 to 50,000 USD over 6 to 12 weeks. The price moves with the number of systems involved and how tidy the purchase order data is, not with how many invoices you receive. The full breakdown is in our cost guide.
§ 06Is this just RPA?
Rule-based automation copes with invoices that look the same every time. Agents cope with the ones that do not: a new supplier's layout, a scanned PDF, a query written in plain English. Most teams end up using both. The comparison is in AI agents vs RPA.
──
If your finance team spends its week working through a queue of invoices, a 30 minute discovery call will show which part is worth automating first and which part should stay with a person. Engagement models and prices are on our Hire page.