AI agents for accounts payable: what they take over, where they stop (2026)

Which tasks in your accounts payable process an agent genuinely finishes today, which it half-does, and which you are better off keeping it out of.

What is an AI agent for accounts payable?

An agent has agency. It does not follow a path you mapped out in advance, but works out within set bounds which steps are needed: first the order, then the goods receipt, then last week's email announcing a surcharge. On the next invoice that route can look different, because the situation is different. The difference with rule-based automation and with workflows is covered in more depth in AI agents for finance.

Two points from that article matter here, because they decide what you buy.

The label tells you nothing. AI-first and AI-native are about how something was built. Agent is about what it can do. You can be AI-native and still run a workflow with no agency at all, and you can build an agent on top of a twenty-year-old system. What you want to know is not the build history, but what happens to your invoice that does not match.

The split that works is: the AI reads and investigates, the rule decides. Almost all existing invoice processing has AI, and it nearly always sits in the same place, namely the reading step. A PDF becomes fields, and with line-level recognition it becomes items, quantities and prices. That is good work, it has been good for years, and it decides nothing.

That the invoice says €12.96 per unit is a reading result. Whether that matches the order, whether a difference of €22.47 is a rounding or a pricing error, which GL account it belongs on, and who you email about it: those are decisions. An agent starts exactly there. The order says 400 units and the invoice says 380. The PO number is not on it. The supplier invoices from a different entity than the one that ordered. At that point capture software puts the invoice in a queue, which is exactly what you should expect from that category. An agent goes and works out why.

Where the time actually goes in accounts payable

The ratio that settles this discussion is not how many invoices clear automatically. It is how the time is divided.

In practice we see the same thing at Claridy every time. The twenty percent of invoices that do not fit the rules costs more than eighty percent of the time. The cases you did not foresee are exactly the cases someone loses half an hour on: the order number the supplier mistyped, the amount that is three cents off, the credit note belonging to an invoice from a previous period, the emailed question about why it has not been paid yet.

That is why a higher recognition rate buys you nothing any more. Those eighty percent were never the problem. An accounts payable team running good capture software already processes the easy invoices almost untouched, and the day fills up anyway.

What this means for your decision: if reading invoices is still manual at your company, buy capture software and not an agent. That is cheaper and it solves your problem. If reading is already handled and the time goes into everything around it, more capture software buys you nothing.

Six things an AP agent takes over

1. Handling the invoice inbox

Not just invoices. A shared purchasing mailbox holds invoices, credit notes, delivery notes, dunning letters and ordinary questions, all mixed together. An agent recognises per message what kind of document it is, assigns it to the right entity and set of books, and processes it straight away instead of passing it to a person who then has to judge it again.

That saves two steps that are manual almost everywhere today. At an international software company on NetSuite the AP team downloads invoices from group mailboxes and forwards them to country-specific capture addresses. At a retail group on Dynamics, staff drag invoices from email into the document system by hand every morning. One group of companies has split its purchasing mailbox per legal entity, purely because its capture tool cannot tell entities apart.

On top of that the agent answers what comes in: payment status, an announced credit note, a price difference that needs explaining. In the thread, with the right document attached.

2. Matching at line level, 2-way and 3-way

Invoice against order, and where goods receipts exist, against the receipt as well. At line level, because that is what most ERP setups demand. A retail group on Dynamics put it plainly: "We do match at line level, because the system demands it."

The work sits in the cases that fall just outside that, and there are more of them than you would like:

• The order number is not on the invoice, or the supplier copied it wrong. A maintenance company on NetSuite registers invoices entirely outside the purchase order process, whether or not an order exists.
• One invoice hangs off several purchase orders, or off an order delivered in parts.
• The quantities match and the price does not, or the other way round.

An agent finds the order itself based on supplier, amounts and lines, shows how confident it is, and only reaches your team when it cannot close the gap.

The rule it matches on is one you write yourself, in plain language. No table of field positions per supplier.

3. Coding at line level, across every dimension

GL account, cost centre, project, VAT code, and whatever other dimensions hang off your set of books. Per invoice line, not per invoice, because one invoice can span three cost centres.

The order that works: supplier first. Most suppliers post the same way every time and then you are done. If the supplier is not consistent, which happens often with large suppliers that deliver all sorts, the agent looks at the history of comparable lines and at the instructions you gave it. You write those instructions in plain language, not as a table of fixed positions per supplier.

The point that matters most: the system has to learn from your corrections. If your team posts a line differently from what was proposed three times, the fourth time should be right without anyone editing a rule. Ask a vendor about this explicitly, because it is the difference between software that gets better and software that needs maintenance every quarter.

4. Working out the difference and emailing about it

This is one task, not two. A difference you have not investigated is one you cannot explain, and an email sent without knowing what is wrong earns you a second email.

Two kinds of deviation, and an agent should catch both.

The arithmetic kind. Do the lines add up to the total, is VAT calculated over the right base, is there a discount that was never applied. At a retail group on Dynamics a line of 17 cents stayed unmatched because the system could not clear it. Cases like that cost no real work, they only cost attention, and attention is the scarce thing.

And the substantive kind. The wrong VAT rate, reverse-charge VAT that was not reversed, invoicing from or to the wrong entity, an IBAN that differs from your supplier master data, a missing order number.

What the agent does: recalculate, pull in the order, the receipt and the earlier correspondence, and if that does not settle it, draft an email with the difference stated concretely.

To the supplier or to a colleague, and that distinction matters more than it looks. A price that deviates from the order is the supplier's business. A quantity that deviates from what was received is the business of the colleague who ordered or accepted it. An agent that sends everything to the supplier is only moving the work around.

It then processes the reply and picks the invoice back up. Without anyone having to put a reminder in their calendar.

5. Putting it forward for approval

Not pushing it down a fixed route, but working out who has to decide and putting it to that person. That difference is the core of what you may expect from an agent.

The thresholds involved differ per company and often live in nobody's system. In one set of books on Exact Globe the rule is: if the purchase order is matched, nothing under five thousand euro needs approval. A retail group on Dynamics runs a different rule: "If it matches on the purchase line, you can always clear it. If it matches on supplier and amount, I want an employee to look at it every time."

You may expect the agent to apply those rules without anyone re-entering them per invoice, to work out the right approver itself based on supplier, amount, cost centre and what happened before, and to present the invoice with everything that person needs to say yes or no. So the order, the receipt, the deviation and what the agent found out about it. An approver who has to go looking first does not approve any faster.

6. Reconciling payments and supplier statements

The invoice is paid, and then the last piece of manual work begins. The bank transaction has to go against the open items, and that is rarely one to one.

Where it goes wrong is the same every time. One payment covers thirty invoices, with a remittance advice sitting as a PDF in a separate email. Something was partly paid. A credit note was offset that belonged to an invoice from an earlier period. At a travel services company on NetSuite a payment of €20.60 could not be matched to a €20 invoice, because a PayPal fee had been taken off it. That same company describes teams shuffling amounts through suspense accounts to clear currency differences and fees, purely because the ERP cannot close the match.

An agent reads the remittance advice out of the attachment, links the lines to the open items, and clears the difference according to the rule you set: exchange difference, bank charges, settlement discount. What it cannot close reaches your team with the candidates attached, instead of as an empty line on a bank statement.

The same goes for supplier statements. What is open according to the supplier, what is open according to you, and which invoices sit in the gap. In more depth: reconciliation software and matching and bank reconciliation in NetSuite.

Traditional invoice processing versus AI agents

The difference is in execution. Traditional software follows rules you thought up. Agentic software is built for the cases you did not think up, and in accounts payable there are more of those than you would like.

That last row is not a missing feature. It is a design choice, and it is the most important sentence in this article.

Where you do not want agency

It is tempting to think you want as much agency as possible. More things can be solved, after all.

But the more freedom, the less predictable. A set of books needs one property that most other systems do not: the same input has to produce the same output. Every time, a year from now too, including when someone checks it.

A system that posts this invoice to 4300 today and to 4310 next month because it read the situation differently is unusable. However reasonable that reading is. Your accountant asks why this posting was made this way, and "the model thought so" is not an answer.

Do the arithmetic, too. A system that is right 95 percent of the time sounds excellent. At two thousand invoices a month that is a hundred wrong postings, and finding them all costs more time than posting them yourself would have. Worse: a system that is usually right teaches your team to stop checking. Those hundred errors then stay invisible until the accountant trips over them.

So the split that does work is the same one as above. The agent can do anything to find out what is going on. What it then writes into your ERP follows code you described in plain language and can read back.

Where it stops

Three things an agent on accounts payable does not solve, and that you should hear from your vendor before you sign.

Below fifty invoices a month it still works, but the question is whether it earns its keep. There is no technical floor. An agent learns from repetition, and fewer invoices means less to learn from, but the calculation that counts is a different one: what does this cost you today, and does the time saved outweigh the price and the effort of setting it up. At fifty invoices a month that is often an honest no. Ask for that calculation before you start, not after.

What your ERP does not offer, an agent cannot write into it. This is more concrete than it sounds. In a pilot on Exact, the default approver at supplier level turned out not to be readable, simply because Exact has no API for it. You only hit undocumented limits like that during the build. Ask about it per process you want to automate.

Sometimes you do not want approval outside your ERP at all. Finance departments often prefer keeping approval flows inside NetSuite or Dynamics, because then they do not have to train colleagues on a second tool or manage extra licences. That is a good argument. An agent that goes along with it beats an agent that imposes its own approval screen.

How to start

Start with the exceptions, not the volume. That is the reversal most projects miss.

1. Count what gets stuck. Not how many invoices you process, but how many stall each month and why. That second list is your business case.
2. Write down your tolerance rules. You already have them, they just live in someone's head. Under what amount can it clear. Which kind of difference is a rounding and which is a pricing error. Who has to look at it above which amount.
3. Decide per step where agency is allowed. Investigating: yes. Posting: no, unless it runs through recorded rules.
4. Run it supervised first. The system proposes every action, your team approves. You see where it is right and where it is not, and then you move the threshold. Be wary of a vendor who proposes running unsupervised on day one.
5. Measure the cycle time of the exception. Not the recognition rate. That number was already high before you started.

The risk is low because you are not going into a migration. You put something next to what you have that takes over one job. If it does not work you switch it off, and your books look exactly as they did before.

Frequently asked questions

What Claridy actually does here sits on the automated invoice processing and procure to pay product pages. On the architecture behind this: what is a system of action for finance. On the distinction between automation, workflows and agents: AI agents for finance. All invoice processing vendors side by side: the comparison guide. Deeper on matching: 3-way matching at scale.

Last checked: 2026-08.