Accounting and advisory practice · Bulgaria · major clients in pharma, healthcare and R&D, some US-listed
On-Premise RPA for Bank Statement Entry
Every bank line was keyed in by hand, because the accounting system offers no import and almost no export. The clients behind those books cannot accept one wrong entry, and their data has to stay in the office, which rules out cloud AI. We automated the work regardless, with everything running on site.

- Industry
- Accounting & Bookkeeping
- Function
- Finance & Accounting
- Region
- Bulgaria
Results
- ~9
- working days returned each month
- Projected over the three companies.
- 200-300
- statement lines keyed in by the robot
- Matched to invoices and SAP data.
- 0
- data that leaves the client's office
- Platform, robots and data stay on premise.
01
The challenge
The client is an accounting and advisory firm in Bulgaria that chooses to serve a small number of large clients. Those clients work in pharma, research and development, and healthcare, and several of them trade publicly in the US.
All bookkeeping happens in Business Navigator, a late-1990s accounting system that still runs on its original platform and interface. Exporting from it barely works. Importing into it is close to impossible. So for three of the firm's clients, a staff member took each monthly bank statement, 200-300 lines long, keyed in every line by hand, matched each payment to the invoice it paid, and compared salaries and expenses with the client's SAP data.
The real cost
- 3-4 employee days per company each month. Across the three, that came to roughly 9 working days every month for a small team, spent typing and checking rather than advising.
- No entry point. There was no import file, no API and no database access, so the standard workaround of generating an import file was off the table.
- Zero tolerance for mistakes. One wrong line in the books of a pharma company listed in the US is a serious matter.
- Data bound to the office. Under the end clients' confidentiality terms, cloud services are not allowed, and neither, for the moment, is AI.
02
What we did
We delivered a complete RPA solution that lives inside the client's office and operates the accounting system through its own screens, just as a staff member would. n8n and our Robot Framework Server sit on a dedicated machine on the client's premises. We maintain it remotely via VPN, and none of it runs on our infrastructure.
A Robot Framework Server we built ourselves
This is our own automation service, built on Robot Framework and run as a server. It takes commands over an API from custom n8n nodes we wrote, inside a protected virtual network. n8n supplies the scripts and the server runs them against the desktop application. It ships with 30-40 general-purpose custom keywords, plus a keyword set written specifically for this accounting system.
Reading the screen, no AI involved
Some parts of the application do not respond to standard UI automation at all. In those places the robot finds its way by image recognition, using Tesseract OCR and OpenCV. Custom algorithms we wrote find the right fields and screens. We left AI models out on purpose, so the solution meets the end clients' confidentiality rules in their current form.
Step by step
- Launch the accounting application and verify its licence.
- Collect new statements from the office NAS via our custom Samba connector, which looks for them daily, then parse them. Supported banks are DSK Bank, ProCredit Bank and UBB, with statements in Excel or PDF.
- Pull the current open items and invoices out of the application by operating its interface.
- Reconcile in code. Each statement line is matched to an invoice, and for two of the companies salaries and expenses are also checked against SAP data.
- Key the statement data into the application and link the reconciled items, again through the interface.
- Pass an accountant only the items that could not be reconciled.
Why not browser nodes?
The Robot Framework Server can drive a browser too. For web tasks, though, we still prefer our Playwright-based n8n nodes, because they run on the n8n worker and n8n fully manages them. The server follows a client-server design, and that is what desktop automation calls for. What a system exposes decides which engine we use.
Stack
| Layer | Tools |
|---|---|
| Orchestration | n8n with custom nodes, self-hosted on the client's premises |
| Desktop automation | Our Robot Framework Server: 30-40 custom keywords and a set specific to the application |
| Screen recognition | Tesseract OCR, OpenCV and custom locator algorithms |
| File intake | Custom Samba connector of our own, Windows NAS |
| Data reconciled | Bank statements, exports from the accounting system, SAP data |
| Access | Remote maintenance over VPN |
03
The outcome
| Before | After (projected) | |
|---|---|---|
| Entering statements for three companies | ~9 working days monthly | Only the exceptions |
| Checking against SAP | Done by hand as a cross-check | Part of the same run |
| Data leaving the office | None, and that does not change | None |
| Swapping out the accounting system | The only other option offered | Unnecessary |
- Statement entry and reconciliation no longer take about 9 working days each month across the three companies.
- One pass reconciles statements, accounting data and SAP data together.
- Nothing leaves the client's office: platform, robots and data all remain on site.
- Evidence that a closed 1990s system without import can be automated safely and kept in place.
The bigger point
Any system can be automated, whether it offers a database, an import file or nothing but a screen. In our invoice processing project we post via the database. In our e-commerce reconciliation project we post via import files. Here we had only pixels to work with, and the process still runs without supervision.
A risk teams tend to overlook
After an update, legacy desktop software may change a screen or how its licence behaves. A robot without screen-recognition fallbacks and monitoring will then stop without telling anyone. Ours verifies the licence and the screens every time it runs.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.

Bulgarian accounting practice · 10-15 people · bookkeeping for 100+ companies
AI That Reads and Posts Accounting Invoices
- of documents go through uncorrected
- 97%
- of documents go through uncorrected
- less data entry every year
- 576 h
- less data entry every year

Bulgarian accounting firm · 10-15 people · bookkeeping for 100+ client companies
Hands-Free Bank Statement Retrieval
- client companies handled twice a month
- 70+
- client companies handled twice a month
- bank portals driven by RPA
- 3
- bank portals driven by RPA

Accounting practice · Bulgaria · 10-15 people, bookkeeping for 100+ client companies
Bank Statements That Reconcile and Post Themselves
- of transactions reconciled and posted automatically
- ~90%
- of transactions reconciled and posted automatically
- statement formats from Bulgarian banks
- 5
- statement formats from Bulgarian banks



