RPA — 25,000 Hours a Year Lost to Rework

625 Weeks of Work — Gone to Rework

Not because people are careless. Because the human brain is not designed to copy invoice numbers flawlessly for eight hours a day.

Gartner has measured it precisely: 25,000 hours per year. That’s how much the average finance department loses to corrections caused by human errors. 625 forty-hour work weeks. Nearly $878,000 in labor costs alone. And yet nobody started a company so that people inside it could fix other people’s mistakes.

That’s where RPA comes in.

What RPA Is — and Definitively Is Not

Robotic Process Automation is a technology that creates a digital agent — a piece of software that mimics exactly what a human does at a computer. Click here. Copy this value. Paste it there. Check whether it matches. If yes — move on. If no — flag the exception.

No physical robots. No artificial intelligence in the sense you know from movies. RPA is more like a tape recorder that captures a sequence of screen actions and plays them back without fatigue, without breaks, without that Friday afternoon moment at 3:47 PM when focus drifts and one supplier’s VAT number ends up on another supplier’s invoice.

An important caveat that many vendors gloss over: RPA only handles rule-based tasks. If a decision requires situational judgment, contextual interpretation, or something the human brain does automatically but is hard to articulate in words — the bot won’t cope. RPA doesn’t think. RPA executes. And that’s precisely why it’s so effective at what it was designed for.

Numbers That Are Hard to Ignore

The RPA market in 2025 reached a value of $4.7 billion (Grand View Research) to $28.3 billion (Precedence Research) — the discrepancy stems from differences in segment definitions. CAGR? Between 24% and 42%, depending on the source and forecast horizon. Regardless of which methodology you choose, the conclusion is one: companies are spending more on this technology every year and have no intention of stopping.

But raw market data doesn’t say as much as individual deployments.

ANZ Bank

Automated over 500 processes across Australia, New Zealand and India. Result: 85% less manual work. Freed capacity equivalent to 400 FTEs. Not layoffs — capacity. Those same people now do things that require thinking, not clicking.

City of Copenhagen

Not a tech company, not a bank — a municipal authority serving 600,000 residents — deployed RPA and saves 8,500 hours annually.

Grupo Éxito (Colombia)

Reduced order processing time by 75%.

American health insurer

Recovered 2,900 hours per month just on correcting claims errors — and the handling time for a single claim dropped to two and a half minutes.

These results are not coincidental. They share a common pattern: high volume of repetitive tasks, clear rules, and data scattered across multiple systems. Where these three conditions co-occur, RPA works almost immediately.

Half of Projects Fail. And That’s an Important Fact.

Now I’ll flip the perspective, because an article about RPA that only talks about successes is an article that lies.

Ernst & Young estimates that 30 to 50% of initial RPA projects end in failure. Not for technical reasons — Forbes reports that only 3% of failures stem from technology issues. The rest? Poor management. Wrong processes selected. No plan for what happens after deployment.

A bank in Southeast Asia installed 2,000 bots on employee computers. Most did the same thing: copied data from one field to another on a fixed schedule. The problem appeared when systems started updating. The interface changed — a button that used to be in the top-left corner moved to the center of the screen. The bot kept looking in the top-left corner. And kept looking. And looking.

Nobody at the bank could say which bot was doing what. Departments kept growing around each other. The automation that was supposed to simplify things had created a new layer of chaos — digital, this time.

This case isn’t an exception. It’s the rule in organizations that treat RPA as a software purchase rather than an engineering project. A bot is not a tool you switch on and forget. A bot requires maintenance, monitoring, updates every time the interface of a system it works with changes. RPA developers spend at least 30% of their time trying to understand what their own bots are actually doing — as data from Blueprint Software Systems shows.

Why Most Companies Automate Too Early

There’s a paradox that few people mention at automation conferences. It goes like this: the worse the process, the greater the temptation to automate it. Because it’s repetitive, boring, generates errors — a perfect candidate. On paper.

In practice, automating a bad process doesn’t eliminate the problem. It cements it. The bot will execute the same redundant steps faster and without errors — but they’ll still be redundant steps. If an invoice goes through five approvals when two would suffice, RPA will make it go through five approvals in four minutes instead of four hours. Savings? Yes. Optimization? No.

That’s why in QA10’s architecture, RPA is never the first step. The first step is process mining — a technology that shows how a process actually runs, how many variants it has, where bottlenecks and loops form. Only after that phase — after simplification, after eliminating unnecessary steps — does automation come in.

This sequence is not our preference. It’s a lesson drawn from dozens of implementations and from hard data: organizations that combine process mining with RPA identify the most profitable processes to automate with surgical precision. They don’t automate everything. They automate what’s truly worth it.

Attended, Unattended, Hybrid — What These Words Mean for Your Business

Three RPA operating modes, explained without jargon.

Attended — the bot works on a computer alongside a human. It waits for a signal, executes its part, and returns control. Like an assistant who, at the snap of a finger, fills in a form while you’re talking to a customer on the phone. Works well in customer service and processes that require a human decision at one of the stages.

Unattended — the bot operates on its own, on a server, without supervision. It starts at 2:00 AM, processes a thousand invoices, generates a report and places it on the CFO’s (digital) desk by morning. It’s a workhorse — the process must be fully predictable, but when it is, results are immediate.

Hybrid — a combination of both. The bot handles what it can, and where it encounters an exception, escalates to a human. The human decides, the bot continues. An increasingly popular model, because it combines automation efficiency with human judgment flexibility.

In 2025, attended RPA accounted for 61% of the market (Mordor Intelligence). But the cognitive RPA segment — bots augmented with AI capable of handling unstructured documents — is growing at 33% per year. The boundary between RPA and AI is blurring. Slowly, but clearly.

What This Means for Your Company — Without Slides, Concretely

RPA makes sense when four conditions are met. The process is repetitive — it happens at least several dozen times per day. Rule-based — decisions can be written as “if X, then Y.” Digital — data exists in a system, not on paper. And stable — interfaces don’t change every week.

If your company processes over 200 documents per month manually — and that’s the threshold at which we start a conversation at QA10 — then somewhere within those processes are hundreds of hours that your people could spend on something better. Analysis. Strategy. Customer service that no bot can replace.

But before we reach for tools, we need to know where to dig. That’s why every RPA implementation we deliver starts with an AiP audit — a process analysis that pinpoints precisely what’s worth automating, what needs simplifying first, and what is better left untouched. This way you don’t end up in the 30–50% failed projects statistic. You end up in the group that knows what it’s doing.

Every RPA at QA10 is also built in the Zero-Trust philosophy — build on top, don’t replace. The bot doesn’t replace your ERP, doesn’t interfere with its logic. It acts as an intermediary layer that connects systems that were previously silent and automates tasks people used to do manually. When a system update changes the interface — the bot should be modifiable in hours, not weeks.