RPA, rules or agents: what each does in accounting
By Ariel Berger · October 30, 2026
Category: llms-and-nlp
Vendors use RPA, rules engines and AI agents as if they were the same thing. They are not, and the difference decides what breaks, who maintains it and what it can handle.
Key takeaways
The problem Buyers cannot tell RPA, rules engines and AI agents apart, so they pick on branding and then pay for the wrong failure mode.
Core insight Each tool fails differently: RPA breaks when screens change, rules break on cases nobody foresaw, and agents err with confidence, so each needs a different safeguard.
Practical outcome Match the tool to the shape of the task, use the cheapest one that works, and add an agent only where the input is messy and a rule cannot be written.
Marketing has blurred three different technologies into one word. I think that is bad for buyers, because each of the three fails in its own way, and you protect against each differently.
Here is how I separate them, with the caveat that this is opinion drawn from what I built and saw, not a standard taxonomy.
Rules engines
A rules engine applies explicit conditions. If the vendor is on the list and the amount is under the limit, approve. It is deterministic: the same input always gives the same output, and you can read the logic.
That is a strength. For anything you can state as a rule, a rule is the best tool. It is cheap, fast and explainable to an auditor in one sentence.
How it fails: on the case nobody wrote down. The rule set grows, rules start to conflict, and the person who understood them leaves. It fails by omission and by tangle.
Robotic process automation
RPA records or scripts the actions a person takes on a screen: click here, copy this field, paste there. It is useful when a system has no interface for programs. The general idea is described under robotic process automation.
It repeats a fixed path. It does not understand what it is doing. If the path is right, it is quick to build and does not need a ledger vendor's cooperation.
How it fails: when the screen changes. A moved button or a new pop-up halts the run, or worse, the script clicks the wrong thing and continues. It is brittle by design, so it needs monitoring and a maintenance owner.
Machine-learning models and agents
Models learn patterns from examples. In 2016 we used supervised NLP and computer vision to read invoices and predict their coding. That is classification: given this input, which output is most likely?
An agent adds planning and action on top. Given a goal, it chooses steps, calls tools and acts within limits. Large language models made this far more flexible than what we had, because they handle messy text without a trained model per document type.
How it fails: with confidence. A model can produce a plausible wrong answer and present it just as it presents a right one. It also drifts: behavior can change when a model or prompt changes. I think of this as the defining operational fact of the technology, and the one vendors discuss least.
A comparison
| Rules | RPA | Agents | |
|---|---|---|---|
| Best input | Structured, predictable | Fixed screens, no interface | Messy text, varied documents |
| Same input, same output | Yes | Mostly | Not guaranteed |
| Typical failure | Unforeseen case | Screen change | Confident error |
| Main safeguard | Rule review and tests | Monitoring and alerts | Limits, review, sampling |
| Explainability | High | High | Needs designed logging |
My rule of thumb
Use the cheapest tool that does the job. If you can write the logic as a rule, write the rule. If the system offers an interface, call it directly instead of scripting a screen. Add a model where the input is too varied for rules, such as free-text invoices or ambiguous bank memos.
Real systems combine all three. A good design puts a rule around the agent: the agent proposes, and a deterministic check refuses anything outside a limit. I like that pattern because it keeps the flexible part inside a fixed boundary.
Anthropic describes a similar principle in Building effective agents: find the simplest solution and increase complexity only when needed. I agree, and I would apply it harder in finance, where an error has a ledger entry attached.
Questions that cut through branding
- If I change a screen layout, what happens?
- If I give you a case you have not seen, what happens?
- If I run the same document twice, do I get the same answer? If not, why, and how do you bound the variation?
- Where is the deterministic check that stops a bad output?
A vendor who answers these plainly knows the product. A vendor who answers with the word "AI" a few more times does not.
Where this leaves you
Inventory your automation. Next to each item write which of the three it is, and what its failure looks like. You will probably find an RPA script with no owner and a rule table nobody has read in two years.
Fix those before you add an agent. A new tool on top of an unmaintained base only adds one more thing to maintain.