A Robot Typing Into Your ERP Is a Confession, Not a Solution

A robot logs into the ERP at seven every morning, opens the supplier invoice screen, and types in the eighty invoices that arrived overnight from the portal of the company's largest customer. It has run for fourteen months. It saves a person most of a day, every day, and it cost a fraction of what the integration was quoted at.

It is also the single most fragile thing in the estate, and nobody has noticed, because it has not broken yet.

This is not an argument against robotic process automation. It is an argument that the choice between a robot at the screen, a call to an interface, and a setting inside the product is an architectural decision that gets made as a procurement decision — usually by whoever had budget, usually in a hurry, and usually without anyone writing down what happens when the screen changes. It is one specific instance of the rule that the automation you can build fastest is not the one you should build first.

The three things being compared

They are frequently discussed as though they were competing products. They are not; they operate at different layers, and the layer is what determines the properties.

Configuration changes behaviour using capability the product already has: an approval rule, a scheduled action, a template, a validation. Nothing is built. It upgrades with the product and it is supported by the vendor.

Native extension or interface work uses the product's own supported extension points and application interfaces. Something is built, it lives inside the software's own model of the world, and it breaks loudly and specifically when a version changes.

Screen-level automation — RPA — drives the software the way a person does, through the interface built for human eyes. Nothing inside the application knows it exists. It is the only one of the three that works on a system whose vendor is gone, whose interface is undocumented, or whose contract forbids you from touching it.

That last property is the real one, and it is why RPA exists. It is also the source of every problem it has.

What screen-level automation is genuinely good at

It has legitimate uses, and dismissing it is as lazy as buying it reflexively.

A system you cannot change. A bank portal. A government submission screen. A customer's procurement portal. A supplier's ordering site. You have no interface and you will never get one. A robot is the only mechanism available, and it is the right answer.

A system that is dying anyway. The legacy application being replaced in eighteen months. Building a proper interface into a thing with a known end date is spending capital on a demolition. A robot is the correct temporary answer provided the end date is real, and this is the single most abused justification in the category, because the end date usually is not.

Proving a process before you invest in it. A robot built in two weeks tells you whether the automated version of a process is actually wanted, at a cost you can walk away from. As a probe, it is excellent.

Very low volume, very high nuisance. Fifteen minutes a week of somebody re-keying between two screens does not justify an integration project and never will. A robot is proportionate.

Notice what those four have in common: either the alternative genuinely does not exist, or the commitment is deliberately short.

Where it goes wrong

The failure is not the technology. It is that the temporary answer becomes permanent without anyone re-deciding, and its properties are wrong for permanence.

It is coupled to pixels. A field that moves, a new mandatory column, a changed label, an extra confirmation dialog — any of these stops it. Your vendor ships these routinely and correctly, and they will not tell you, because from their side nothing broke. Every ERP upgrade becomes a small unplanned project, which is one more entry on the list of reasons an upgrade that should be routine turns out not to be.

It fails silently and it fails halfway. A broken integration usually throws an error somebody receives. A robot that fails on invoice forty-one of eighty has posted forty and not the rest, and the way that is discovered is a supplier phoning about a payment. Partial completion in a financial process is worse than no completion, and it is the default behaviour unless somebody engineered otherwise.

It runs as a user, and usually a powerful one. The robot needs an account. That account is shared, its password is in a configuration file, it typically has broad rights because narrowing them was fiddly, and every transaction it creates is attributed to it. This quietly destroys the audit trail for the highest-volume process in the company — the same collapse that makes a log whose only answer is a service account worthless as evidence.

It has no owner after the consultant leaves. It was built by a specialist, in a tool nobody else in the company uses, with logic that exists nowhere else in writing. Two years later it encodes business rules — which invoices to skip, how to match a supplier, what to do with a mismatch — that are documented only as a script nobody can read.

It hides the missing integration rather than motivating it. This is the most expensive one and the least visible. Once the pain of re-keying is gone, the case for the proper interface disappears, and the organisation carries a permanent hidden dependency instead of a solved problem. The robot is not the solution to the missing integration; it is the reason the missing integration is never built — and it therefore sits at the heart of the integration problem nobody funds.

The four questions that actually decide it

Before choosing, four questions in this order. The first one settles most cases on its own.

Does the target system have a supported interface? If yes, use it. Not because interfaces are fashionable, but because the vendor is then contractually on the hook for keeping it working, and the robot's vendor is not. The most common reason this question gets the wrong answer is that nobody asked the vendor — they asked the implementation partner, who quoted the work rather than checking the documentation.

Can configuration do it without any code? Very often a substantial part of what the robot does is available as a scheduled action, an import template or an approval rule that nobody looked for. This is worth two hours of investigation on every automation proposal, and it is the cheapest hours you will spend.

How long will this need to run? Under a year, a robot is a reasonable bet. Over three years, you are betting that a user interface will be stable for three years, and no software vendor has ever offered that. Write the expected life down, because the number never gets written down and that is precisely why the temporary becomes permanent.

What happens when it fails halfway? If you cannot answer this in one sentence — it resumes from the last confirmed record, it reverses what it did, it alerts a named person before anything else runs — do not deploy it into a financial process. This question, asked early, disqualifies more RPA proposals than the other three combined.

The hybrid that usually wins

The best outcome in practice is rarely all-robot or all-interface. It is a robot at the boundary you do not control, handing to a supported interface on the boundary you do.

The customer's portal has no interface, so a robot collects the files. It does not then type them into your ERP; it drops them into a location, and a supported import or interface takes them from there. The fragile part is small, isolated at the edge, and does one thing. The part touching your financial records is supported, logged, restartable and attributable to a real process rather than to a phantom user.

This costs slightly more than the pure screen-level version and it removes almost all of the risk, because the pixels it depends on belong to one screen rather than to every screen in the chain.

If you already have robots running

Most companies reading this have three or four, built at different times by different people. The useful exercise is short.

List them. For each: what it touches, which account it runs as, what happens when it fails, who could fix it, and how long it has been "temporary". That last column is the one that produces the reaction, because the answer is usually years.

Then do two things immediately, before any strategy. Give each robot its own named account with only the rights it needs — this is a day's work and it restores the audit trail. And make failure loud: a robot that cannot complete must alert a person by name, not write to a log file that nobody reads.

Everything else — replacing them, keeping them, funding the proper interface — is a decision for the list, and the list is usually enough to make it obvious. That inventory is a standard part of an independent look at what the estate is actually doing, because robots are almost never on anybody's system diagram.

The short version

Screen-level automation is the right answer when you genuinely cannot change the other system, or when the commitment is deliberately short. It is the wrong answer as a permanent substitute for an interface that exists, and it becomes that by default rather than by decision.

Its properties are the problem: it depends on pixels its vendor changes without telling you, it fails halfway and silently, it runs as a shared account that erases attribution on your highest-volume process, and after two years its business logic lives only inside a script nobody can read.

So ask the four questions in order — is there an interface, can configuration do it, how long must it live, what happens at the halfway failure — and prefer the hybrid: a small robot at the boundary you do not control, handing to a supported path on the boundary you do. And whatever you already have running, give it a named account and make it shout when it stops, because the robot you have not heard from in fourteen months is not the same thing as a robot that is working.