KT Sparks

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.

On-Premise RPA for Bank Statement Entry
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

  1. Launch the accounting application and verify its licence.
  2. 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.
  3. Pull the current open items and invoices out of the application by operating its interface.
  4. 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.
  5. Key the statement data into the application and link the reconciled items, again through the interface.
  6. 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

LayerTools
Orchestrationn8n with custom nodes, self-hosted on the client's premises
Desktop automationOur Robot Framework Server: 30-40 custom keywords and a set specific to the application
Screen recognitionTesseract OCR, OpenCV and custom locator algorithms
File intakeCustom Samba connector of our own, Windows NAS
Data reconciledBank statements, exports from the accounting system, SAP data
AccessRemote maintenance over VPN

03

The outcome

BeforeAfter (projected)
Entering statements for three companies~9 working days monthlyOnly the exceptions
Checking against SAPDone by hand as a cross-checkPart of the same run
Data leaving the officeNone, and that does not changeNone
Swapping out the accounting systemThe only other option offeredUnnecessary
  • 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.