Hybrid tax and banking RPA, from Power Automate to an in-house API on AWS

Challenge

Most Brazilian tax obligations have no API. The portal exists, the file has a defined format, but the path between the ERP and the authority is a browser with a human inside it. That holds for downloading tax documents from national issuers. It also holds for bringing goods into a free trade zone, where a specific file has to be submitted and its response tracked for days.

On the banking side the problem is the same: reconciliation and posting depended on someone opening the online banking portal for each company in the group.

The temptation in these cases is to throw everything at an RPA tool and let the business rule live inside the robot. Nobody can audit automation built that way, and it breaks with every screen-layout change.

Solution

I adopted a hybrid architecture with an explicit boundary: every tax and financial rule stays inside the ERP; Power Automate and Logic Apps only execute the part that requires a browser or an external portal.

The ERP assembles the work package, triggers a cloud flow through an authenticated webhook, and goes back to tracking the process by polling, because the authority’s response can take hours or days. The robot decides nothing, it clicks and reports back. When the portal’s layout changes, the external flow breaks and the business rule stays standing.

On top of that I built the observability layer: centralised logging of every run, email and WhatsApp alerts on failure, and an internal dashboard for tracking runs, so the operations team can see what’s stuck without opening the database.

In 2026 the banking side got a second generation. The ERP now calls an in-house API hosted on AWS (API Gateway in front of EC2), follows each run until it completes, fails or times out, downloads the OFX and CNAB statements from S3 and attaches them to the record, with per-operation detail. On top of that sits a fallback job that runs every 15 minutes: it works out the outcome of runs left without a reply and re-triggers the ones that failed, up to a limit of attempts and time, keeping the chain of attempts and blocking duplicate triggers. I shipped it with the module’s architecture and operations manual.

For the free trade zone case, the flow runs from the invoice through to the notification. The ERP generates the file in the required format, the robot submits it, an async monitor tracks the status change, and the person responsible is notified when there is a pending issue.

Outcome

Processes that depended on someone sitting in front of a portal started running on their own, with a record of everything that happened. And when something fails, someone finds out immediately and knows which step it stopped at. Silent failure is the worst defect in an RPA project, and the active alerting is there precisely so that none of it slips through. On the banking side, a transient failure does not even become a ticket: the retry fixes it first.

What this case shows

The decision that holds the project up is where the rule lives. RPA came in as a last resort and observability was treated as a requirement from the start. In among that, integration of the Microsoft automation stack and AWS services with a legacy ERP, without the rules leaving it.