What is RPA?

Every office contains a category of work everyone recognizes and nobody loves: download the report here, copy the columns there, fill in the form in a third system, attach, send, repeat tomorrow. RPA — robotic process automation — automates exactly that layer: software robots operate applications through their screens the way a person would, opening programs, reading fields, copying data, clicking buttons, faithfully following the procedure they were shown — without breaks and without Friday-afternoon slips. The key contrast is with classic API integration: integration wires systems together underneath (elegant and robust, but it requires the systems to expose APIs and someone to connect them), while RPA works on top, through the same interface humans use — which is why it shines precisely where integration cannot reach: legacy applications without APIs, third-party portals you do not control (banks, public institutions, supplier systems), processes crossing five incompatible tools. Typical cases: pulling bank statements and reconciling, entering supplier invoices into accounting systems that lack imports, periodic reports assembled from several sources, checks in public registries. The honesty brochures skip: a robot that clicks on screens is inherently more fragile than an API — an interface update can confuse it — so serious RPA includes monitoring, failure alerts, exception handling and maintenance in the budget, and the sound architecture rule is a hierarchy: integrate through APIs where they exist, use RPA where they do not. The economics are usually favorable and checkable in advance: good candidate processes have clear rules, decent volume and few exceptions, and a single-process pilot typically pays for itself within months.