What RPA is
Robotic process automation, RPA for short, refers to software that mimics the way people operate other programs. A so-called bot clicks buttons, fills in fields, copies values from one screen to the next and reads results off the screen. In other words, it does the same as a person at the keyboard, only following a fixed sequence and without breaks.
The appeal is obvious: nothing has to change in the existing systems, because the bot uses the same screens as the staff. That makes RPA a quick way in when two programs need to exchange data but neither was designed for it. That, however, is also the weakness this article is about.
Where RPA is used in mid-sized companies
RPA is used for processes that follow fixed rules and work with structured data. Typical areas:
- Transferring orders from a portal into an inventory management or ERP system.
- Recording incoming invoices in accounting when the values are already available in structured form.
- Reconciling master data such as addresses, prices or item numbers between two programs.
- Compiling recurring reports from several applications.
- Retrieving data from portals run by authorities, banks or suppliers that offer no other access.
What these processes have in common is that today a person carries data from one system to another. These are the same processes that are also suited to an interface. The real question is therefore not whether RPA can handle them, but whether a screen robot is the right route.
How a bot works and why it matters
An RPA bot finds its way via what is on screen: window titles, field labels, positions on the screen or the structure of a web page. As long as the screens stay the same, it works reliably. If the vendor changes a screen in an update, moves a field or renames a button, the bot can no longer find its way. In the better case it stops; in the worse case it enters values into the wrong field.
On top of that, a bot only sees what is on the screen. It does not know whether a value is correct from a business point of view, whether a record has already been transferred, or whether the target system has silently truncated an entry. These checks have to be built in addition, and via the screens they are considerably harder to build than via an interface that returns structured responses and error messages.
When RPA is NOT the right solution
For most processes between two business systems, RPA is not the first choice. If a system offers an interface, such as a documented API, database access with clearly limited permissions or a defined data export, connecting to it directly is the more stable route. It transfers fields rather than screen content, is unaffected by changes to the screens and can be secured with automated tests.
RPA is not the right choice in these cases:
- There is an interface: if one exists or can be provided with reasonable effort, a direct connection is more stable and less fragile in operation.
- The screens change often: every update to the connected application can interrupt the bot, and every interruption needs someone to notice and fix it.
- The process is business-critical: if a stalled bot means orders do not arrive or deliveries are not triggered, a solution that depends on screen positions is a risk.
- Business judgement is needed: assessing a complaint or approving a special price is not a sequence of clicks. Here a person decides, supported by good software.
- The process itself is flawed: a cumbersome process does not get better with a bot, only faster at being cumbersome.
That leaves the case RPA is actually meant for: a system has no interface, for example an older program without an API or an external portal that can only be reached through the browser. In that case a screen robot can be a sensible interim solution. The key word is interim: the bot bridges the time until the legacy system is replaced or the vendor provides an interface. It should not become the permanent foundation of a core process.
A screen robot is a bridge, not a foundation.
If RPA, then with the same rules as any software
Anyone using RPA as an interim solution should treat it like any other software in operation:
- Every run is logged: what was transferred, when and with what result.
- Error cases land visibly with a responsible person instead of being silently skipped.
- After every update to the connected application, someone checks whether the bot still works correctly.
- There is a business owner and a technical owner, both named.
- It is settled when and by what the bot will be replaced, for example by an interface or by replacing the legacy system.
The last point in particular decides whether an interim solution quietly becomes a permanent one.
The interface route
Building an interface means more than the technical connection. Beforehand, it is settled which system is authoritative for which field, what applies when data contradicts itself and who decides in an error case. Only then is it programmed, with logging, visible error cases and automated tests.
For a window manufacturer, we look after software that has been in daily use since 2022. It includes a nightly ERP reconciliation across 11 sites, and the software is safeguarded by around 6,000 automated tests. Running a reconciliation of this scale through input screens would be a risk with every update to the systems involved.
We develop with Claude Code, the AI tool from Anthropic. No change goes live without automated tests, code review and approval by a human. That applies to an interface just as much as to any other software we build.
What the two routes cost
At first glance RPA looks inexpensive, because nothing changes in the existing systems. But the costs include the licence for the RPA platform, setting up each bot and maintaining it after every update to the connected applications. Which option pays off depends on how long the solution is meant to last and how often the systems involved change.
For bespoke solutions, our ranges are as follows, all net: a small line-of-business application costs €10,000 to €30,000, a system for several departments €30,000 to €90,000, and company-wide solutions start at €90,000. Before that comes a paid analysis of one to two weeks for €3,000 to €6,000, which is credited in full; if it does not produce a usable result, you get the fee back. After that we build at a fixed price per stage, and operations and maintenance start at €300 per month.
The first step
If you are considering automating a process with RPA, or already have bots in use that regularly fail after updates, that is a good reason for an initial conversation. In 30 minutes, free of charge, we clarify whether the systems involved offer an interface and which route pays off in your case.