By August Rosedale, CTO and Co-founder of Qurrent
›
Back
A dozen or so years ago, the pitch for robotic process automation (RPA) in accounts payable was honest.
A bot that clicks through invoice screens is faster than a person, costs almost nothing per run, and never asks for a day off.
Finance teams bought this technology in droves. But then a vendor portal is redesigned and a button moved forty pixels. And then that bot processing ten thousand invoices a month started clicking the wrong thing.
At Qurrent, we build a different sort of business automation. That being said, I want to be careful to make a case less dramatic than "RPA is dead" and say something more useful: RPA fails for a specific, structural reason, and the fix keeps everything that made it attractive.
Why RPA in accounts payable breaks by design
An RPA bot automates the screen, and only the screen. It holds a stored reference to a button, a field, or a pixel coordinate, and executes the same click path every time. That design is what makes it fast and cheap to run, and it is why the whole system sits one frontend deploy away from failure.
From a human's perspective, the change that kills a bot is trivial. A button moves slightly, a field gets renamed, an invoice template shifts a column. The bot is not “thinking”. It has no concept of what it is trying to accomplish, so it either clicks the wrong element or halts entirely.
Understanding why RPA breaks starts there: the bot only ever replayed a recording of someone doing the task.
The record across RPA in finance reflects that gap. Estimates say 30 to 50 percent of initial RPA projects fail, and the pattern plays out the same way. While the initial pilot works, production reality arrives with the first upstream change nobody warned the bot about.
That weakness shows up three ways once bots meet real invoice volume.
The three failure modes finance teams actually see
In production it rarely announces itself as one big outage. Instead, you’ll see it show up in three recurring ways:
1. Screen-level breakage stops work at the worst possible moment
An RPA bot works perfectly until the second it doesn’t and nearly every time the triggers are outside your control:
A vendor portal ships a redesign or a new login step
A scheduled ERP upgrade restructures a form
A supplier changes invoice template or file format
An internal tool gets a refresh nobody thought to flag
The failure might even go unnoticed with a pile of invoices queue behind a stalled bot until an aging report or an angry supplier surfaces it, and by then the backlog is measured in days.
2. Exception blindness leaves the hardest invoices with your team
Scripted automation runs the happy path, and accounts payable is not a happy-path process.
The missing PO, the quantity mismatch, the duplicate that is almost a duplicate are all exceptions are where AP teams actually spend their time.
A bot routes every one back to people, so the work that justified the automation budget stays manual while the bot handles the invoices that were never the bottleneck.
3. Maintenance debt turns a quick win into a permanent budget line
Every upstream change means developer time to find the broken reference, rebuild it, and test it. Multiply that across dozens of bots and every release cycle, and maintenance quietly becomes its own program.
In 2022, nearly three quarters of organizations reported having already implemented RPA though rated their own automation transformation at a 5.04 out of 10. In the years since, attention has obviously shifted toward AI and LLMs to automate processes, but it’s important to understand that these failure modes share one root cause.
A different architecture changes the outcome.
AI agents vs RPA: what actually changes
The word "agent" gets attached to a lot of systems that do not deserve it. Building something with an LLM does not make it agentic.
An agent needs two capabilities: it takes actions and decides on its own when to take them, and it observes each result and decides what to do next. That loop, act, observe, decide, is the entire difference.
Applied to accounts payable, the difference is architectural:
Dimension | RPA bot | AI agent |
|---|---|---|
What it follows | A stored click path | A goal, with actions it chooses |
When the UI changes | Clicks the wrong thing or halts | Reads the page and finds the new path |
When an invoice is an exception | Routes it to a person | Investigates, resolves, or escalates with context |
Ongoing maintenance | Developer rework on every change | The system adapts and stores what it learned |
Cost per action | Very low | Higher, because reasoning costs compute |
That last row matters more than most comparisons of AI agents vs RPA admit. Reasoning through every click is slower and costlier than replaying a script, and across thousands of runs a day that cost compounds.
The models underneath will also keep changing, which rewards architectures built to absorb change. Sure, agents solve the brittleness problem. The engineering question is whether you get the resilience without paying reasoning costs on every click.
You can, and the pattern is simpler than most people expect.
Store-and-replay with agent fallback keeps the speed and drops the fragility
Here is how we build frontend automation at Qurrent.
On the first run, an agent navigates the workflow for real: it reads the page, finds the buttons and fields, and completes the task while the system stores every click. Subsequent runs replay that stored path deterministically, with no LLM calls per click, as fast and as cheap as any RPA bot.
The difference is what happens when the replay fails because a button is missing or a page has changed.
A traditional bot stops and waits for a developer. Our system falls back to the agent, which reads the page again, locates the element in its new position, completes the step, and saves the updated path for the next run.
How this simple fallback changes everything
The workflow becomes resistant to frontend changes, backend changes, and full redesigns, because every failure is handled by a component that understands the goal rather than the coordinates. Speed stays close to pure RPA, since the agent only wakes up when something has changed.
Two design principles round out the pattern.
First, deterministic where it counts: when the task is arithmetic, matching, or anything with one correct answer, we run programmatic code that returns the same result every time and save agent reasoning for decisions needing judgment.
Second, oversight sits above the loop, reviewing outcomes at the process level rather than approving every action. A person asked to approve every step of a system that is right nearly all the time falls into a rhythm of approving everything, and the one bad action sails through.
Pure RPA and pure agent-on-every-click are both extremes with real costs. The hybrid takes the strength of each and covers the weakness of the other.
Where this leaves RPA in accounts payable
AP is the sharpest test for this pattern because volume compounds and the environment never sits still. A process touching thousands of invoices a month hits breaking changes continuously, and the gap between "a developer fixes it next sprint" and "the system fixes itself on the next run" separates programs that stall from programs that hold.
The bigger opportunity sits one level up. A hundred-step AP process was designed for people, and translating it step for step into any automation preserves flaws the process never needed.
The most effective deployments redesign the workflow around what a digital workforce can do, the same logic behind rebuilding the P&L around digital workers rather than bolting automation onto the old cost structure.
If you are mapping which of your AP workflows could run this way, Qurrent's Finance Operations Readiness Assessment is built for that first pass: which processes fit, what they look like redesigned, and where the fastest results are.
Keep what RPA got right
If you run finance operations, the frustration is familiar. The bots were supposed to take the invoice work off your team, and instead your team inherited a new job. Instead of doing work that requires human interpretation, you’re watching the bots, feeding them exceptions, and waiting on rebuilds every time a screen changes.
The speed promises were fulfilled but with that came increased fragility.
The answer keeps the first and removes the second. Qurrent deploys fully managed agentic workforces that run accounts payable end-to-end on the store-and-replay with agent fallback pattern, with deterministic code where precision matters, agent reasoning where judgment does, and SLAs on the outcome.
To see your AP process rebuilt this way, start with a free readiness workshop.