RPA without an API: how to automate legacy systems, in-house software and government portals

In many companies that have been operating for more than a decade, an old ERP, HR module or in-house production program runs alongside Microsoft 365 and a new CRM. Replacing a core system is usually a costly, multi-year project, and migrating historical data can be harder than choosing the new software.

The effect shows in day-to-day work. Someone manually retypes data from email, the CRM or KSeF into the old system, and then back into Excel. We describe how to calculate what this costs in a separate article on manual data copying.

RPA (robotic process automation) is a program that performs the same clicks and entries in an application as an employee. It needs neither an API nor the vendor’s consent to integration, because it uses the program’s ordinary windows.

A robot that clicks through screens is effective, but it needs looking after. Any change in how a window looks can stop it. That is why it is worth checking simpler and more durable routes first.

If none of the routes below works or pays off, a robot is a sensible choice. You will find a comparison of robots and API integration in a separate article.

Most often, a robot is used with an old accounting module or ERP, with in-house software no longer supported by its vendor, and with portals that offer no API. Each of these situations needs a slightly different approach.

In-house programs are the hardest, but they can be the most valuable, because there is no other way to connect them. Take a hypothetical production planning program written more than 20 years ago by a company that no longer exists. Every morning, a robot exports orders from it to Excel, where further automations pick them up.

Such a project takes longer, because every path through the program has to be described, and you have to decide what the robot will do if the application freezes. The table below sets out the main differences.

Often, yes. An old system changes rarely, so a robot, once built, can run for a long time without fixes. Cloud applications change their appearance more often, and every change may require the robot to be adjusted.

There are, however, exceptions worth knowing about before you start. A robot still needs to be reviewed after every change in the system’s environment, even if the program itself has not changed.

Take a hypothetical manufacturing company whose ERP, more than ten years old, has no KSeF module. Purchase invoices arrive via KSeF as data, but the accountants download them and retype them manually. Each day that is 90 invoices at about 4 minutes each, or 6 hours of work.

The solution has two parts. An automated flow in Power Automate downloads new invoices from KSeF and checks whether the supplier is in the system and the order matches. A Power Automate for desktop robot logs into the ERP and enters the data field by field.

Invoices the robot cannot match, for example from a new supplier or without an order number, go onto an exceptions list each morning. An accountant resolves them manually instead of retyping everything from scratch.

You can estimate the benefit using your own data: 6 hours × 21 working days = 126 hours a month. At a labour cost of PLN 70 per hour, that is PLN 8,820 a month, from which you need to deduct licences, robot maintenance and the time spent handling exceptions.

A lot of official data can be retrieved without a robot. The register of VAT taxpayers has an official API with a limit of 100 queries a day, each covering up to 30 entities. It shows, among other things, whether a company is an active or exempt VAT taxpayer, and its bank account numbers. For larger checks, the Ministry of Finance provides a file that can be downloaded once a day.

A current KRS extract is returned by a free Ministry of Justice API. The personal data in it is partly anonymised, so for full details of board members you need a regular extract. Exchange rates are published via an API by the National Bank of Poland.

A robot on a portal only makes sense where there is no API. Before you launch one, read the terms of use – some services prohibit automated access. Nor may a robot circumvent anti-bot safeguards, such as typing in a code from an image.

Signing in carries the most risk. A robot that signs in with a specific person’s Trusted Profile (profil zaufany, the Polish government e-ID) or qualified signature acts on that person’s behalf. Such a solution requires legal analysis and the person’s consent; company accounts and powers of attorney work better.

In the Microsoft ecosystem, robots are built in Power Automate for desktop. The program itself is free for Windows, but running a robot on a schedule or overnight requires the paid licences in the table below.

On top of the licences, add maintenance. Someone has to check the robot’s work report every day, handle exceptions and fix the robot after changes in the systems. Decide before you start who does this – your employee or the supplier.

A robot on an old system takes the most tedious work off the team and gives you time for a well-considered decision on replacement. Provided it is not forgotten.

Keep a simple register: which robots run on which system, which processes depend on them and who is responsible for them. When choosing a new system, include an API and a KSeF module in the requirements, so that the robots can be switched off rather than migrated.

If the cost of maintaining the robots starts to exceed the benefit, that is a sign the old system needs replacing. It is worth doing this calculation once a year.