RPA and AI agents solve different problems, so the choice is made step by step, not tool by tool. Use an agent when a step needs judgment, RPA or an API when it needs determinism, and a person when it needs accountability. Most finance and operations processes contain all three.
This guide gives you a way to sort the steps of a process, a worked example in accounts payable and a short checklist. It is written for the people who own the process, meaning finance, operations and shared-services leaders, not for the team choosing a tool.
What is the difference between RPA and an AI agent?
RPA follows a script. It repeats the same clicks, in the same order, on the same screens, and it does exactly what it was told. That makes it fast, cheap to run and easy to audit, and it makes it fragile when the input or the screen changes.
An AI agent reads the situation. Given a goal, a set of approved tools and your policies, it interprets unstructured input, such as an invoice in an unfamiliar layout or an email from a supplier, and decides which approved action to take. That flexibility is the point, and it is also the risk: without controls, the same input can produce a different answer on a different day.
An API sits next to RPA on the deterministic side. When a system exposes a stable API, call it directly. RPA is for the systems that do not.
How do you decide which one a step needs?
Ask three questions of every step, in this order.
- Does the step require judgment? If a person has to read something messy, interpret intent or apply a policy with exceptions, an agent is a candidate. Examples: classifying a document, coding an invoice against policy, drafting a reply to a supplier.
- Does the step require determinism? If the same input must always give the same output, and the action writes to a system of record, use RPA or an API. Examples: posting a journal entry, updating a vendor master field, running a bank reconciliation rule.
- Does the step require accountability? If a named person must own the outcome, because money moves above a threshold, a customer is told something or an audit control changes, keep a person in the decision. The agent can prepare it. The person signs.
Many steps score on more than one question. Split them. The judgment part goes to an agent, the posting part goes to RPA or an API, and the approval stays with a person. This is the technology-agnostic principle we work from: the process decides the tool, not the other way around.
What does this look like in accounts payable?
Accounts payable shows all three needs in one flow, and we have published the results of one case: an AP agent at a regional manufacturer (anonymised). Here is how the steps sort.
- Judgment (agent): reading each invoice, extracting the fields, matching it to a purchase order and coding it against policy, including invoices that arrive in layouts nobody planned for.
- Determinism (RPA or API): posting the approved invoice to the ERP and updating the payment record. These are fixed steps with a fixed result.
- Accountability (person): the invoices the agent escalates because they fall outside policy or beyond what it can resolve.
The measured outcome: 92% of invoices went straight through by month 2 and 95% by month 6. AP throughput tripled with the same team, and the cost came in under $0.40 per invoice. The rest went to people, with a defined path to reach them.
Two controls make those numbers trustworthy. The agent is evaluated against a 500-invoice golden set, so every change gets a score. And prompt and model versions are pinned quarterly, so any result can be traced to the exact version that produced it.
When should you not use an agent?
Do not use an agent for a step that is a fixed sequence on a stable system. RPA or an API is cheaper, faster to run and easier to explain to an auditor. Do not use an agent to make a decision nobody can review afterwards. If you cannot replay why it acted, it should not act alone.
Do not use RPA for a step that depends on reading varied documents or free text. The bot will handle the layouts it was built for and push everything else into an exception queue that people work by hand. That queue is where agents earn their place.
Checklist: before you assign a step to a tool
- Have you written the step down, and decided whether it should exist at all?
- Is the input structured and stable (RPA or API) or varied and unstructured (agent)?
- Does the action write to a system of record? If so, is it reversible, or does a person approve it?
- Who is the named owner of the outcome?
- Is there an evaluation set built from real cases, and a pass mark the agent must reach?
- What is the exception path, and who works it?
- Can you pause the agent immediately, and replay any decision it made?
- Are prompt and model versions pinned, with a review date?
Frequently asked questions
Will AI agents replace RPA?
No, because they cover different steps. RPA and APIs remain the right choice for deterministic work on stable systems, and agents usually call them to execute what they decide. The useful question is where each one belongs in a given process.
Do we need an agent if our RPA already works?
Not necessarily. If your bots run without a growing exception queue, leave them alone. If people still handle exceptions by hand that depend on reading and judgment, an agent can help there, behind a person's review at first.
How do we keep an agent's decisions auditable?
Log every prompt, tool call and output with the identity of the operator, evaluate the agent against a fixed set of real cases and pin prompt and model versions so results are traceable. Our article on governing AI agents in finance covers these controls in detail.