What robotic process automation is, where it works, where it breaks, and when an API or an AI model is the better route.
Robotic process automation uses software bots to carry out repetitive, rule-based computer tasks the way a person would, such as copying data between systems, filling forms, or processing invoices. It works across existing applications without changing them, freeing staff from tedious work and reducing errors. RPA suits high-volume, predictable processes, and is increasingly combined with AI to handle less structured tasks.
Robotic process automation (RPA) is software that operates your existing applications the way a person would: it opens the screen, reads a field, copies a value, clicks the button. Nothing in the application changes. The bot sits on top of it and repeats a recorded sequence, hundreds of times a day, without getting bored.
That is also its limit. RPA does not understand what it reads. It matches positions and patterns, so it is fast to deploy and fragile the moment a screen, a file layout or a supplier's PDF changes. The useful question in 2026 is not "RPA or not" but which of three routes fits the step in front of you: a bot on the interface, a connection through the API, or an AI model that reads the messy input first.
A developer records or scripts a sequence: log in to the ERP, open the purchase order, copy the amount into the accounting package, attach the PDF, submit. The bot then runs that sequence on a schedule (unattended) or when a person triggers it from their desk (attended). It identifies elements by their position, label or internal identifier, and it stops, or worse continues wrongly, when one of those changes.
Vendors in this space include UiPath, Microsoft Power Automate, Automation Anywhere and Blue Prism. All of them sell the same core idea with different licensing, and all of them work best on stable, in-house applications with no API.
RPA fits when the process is high-volume, the rules are explicit, the input is already structured, and the application you need to drive has no usable API. Legacy systems, government portals and older AS/400-style back offices are the classic cases. It also fits as a stopgap: a bot can bridge two systems for a year while a proper integration is built.
It does not fit when the input is unstructured (an emailed order in free text, a scanned invoice in a new layout), when the screen changes often (most SaaS products push interface updates monthly), or when the same result is available through an API. Driving a screen to do what an API call would do is paying for fragility.
An API integration talks to the application directly: no screen, no clicks, no dependence on where a button sits. It costs more up front, because someone has to read the API documentation and handle authentication and errors properly, and it is far more stable afterwards. For Dutch SMEs most of the systems that matter (AFAS, Exact Online, e-Boekhouden, the major webshop platforms and carriers) have APIs, which is why the Dutch adoption data below looks the way it does.
The rule we apply: if an API exists, use it. If none exists and the process passes the volume and rule tests, RPA is a reasonable bridge. If the input is unstructured, neither route works on its own.
RPA executes a script. AI exercises judgement. A language or vision model reads the messy input (a supplier's new invoice layout, a customer who wrote a sentence instead of ticking a box), infers what it means, and decides the next step. That is the missing piece in most failed RPA projects: the bot was fine, the input was not.
The design that holds up in practice is layered. AI for the reading and deciding, deterministic automation (an API call, or a bot where no API exists) for the moving and posting, so every irreversible action still runs through a rule you can audit. Our AI automation work is built this way, and the process automation page sets out how to choose the first candidate.
Statistics Netherlands (CBS) puts RPA use among micro-enterprises at 2.3% in 2025, barely moved from 1.7% three years earlier, while process mining in the same period nearly tripled to 9.8%. Read plainly: Dutch firms are automating, but mostly through integrations and analysis of their own process data, not through bots on screens. That matches what we see. The RPA that survives is a small number of unattended bots on systems nobody can replace yet.
Two lines on the bill. Licensing, which the vendors price per bot or per user and which for a small deployment typically runs from a few hundred to a few thousand euros a year. And build and maintenance, which is where the real money goes: a single well-scoped bot is a few days to a few weeks of work, and every interface change afterwards is a maintenance ticket. Budget the maintenance honestly; a bot that nobody owns stops within a year.
At Crux Digits we rarely quote RPA on its own. A €2,500 audit decides which route (API, bot or AI) fits each step of one process, and a €20,000 Production-ready MVP runs it on real cases against a measured baseline.
Want this applied in your business? See how we take it to production:
We build this AI in production, at fixed prices, with one named expert. Start with a free consultation.
Book a free consultation →