Accounting practice · Bulgaria · 10-15 people, bookkeeping for 100+ client companies
Bank Statements That Reconcile and Post Themselves
Manual, line-by-line month-end reconciliation leads to payments booked twice and invoices that stay open for weeks after the money arrives. Today roughly 90% of bank transactions are matched and posted automatically, and the accountants handle only the lines that call for judgement.
- Industry
- Accounting & Bookkeeping
- Function
- Finance & Accounting
- Region
- Bulgaria
- Duration
- 6 weeks
- Team
- 3 people
Results
- ~90%
- of transactions reconciled and posted automatically
- The remainder are bank lines without a usable description.
- 5
- statement formats from Bulgarian banks
- Adding a bank is a template job. The most recent took about four hours.
- 0
- double-registered payments
- Already settled documents are caught before posting.
01
The challenge
The client is an accounting and financial-management practice in Bulgaria. Its team of 10-15 keeps the books for over 100 client companies, all of them in Microinvest.
Bank statements were processed by hand, one line at a time. For each movement someone had to locate the invoice it paid, confirm that invoice was still open, work out who the counterparty was and choose the accounts to post to. That happened for every account of every company, every month. Salary runs, cash taken out at ATMs, bank charges and payments to the budget each had rules of their own.
The real cost
- Duplicates and items that should be closed. When a payment is booked twice or a settled invoice stays open, the client's books are wrong, and nobody notices until late.
- Expert hours on predictable lines. Most lines follow a pattern, but every one got the attention of a qualified accountant.
- A delay at the very last step. Reconciliation comes right before the close, so whenever it slips, the whole close slips with it.
02
What we did
We delivered an unattended reconciliation robot running on self-hosted n8n. It writes its postings directly into the accounting system.
Statements from any bank
Each bank's statement format has its own structured connector. Five Bulgarian banks are covered today. Adding a bank means adding a template, not rewriting code, and the most recent one took roughly four hours. Before any posting happens, the structure and key fields are checked. Anything our robot for downloading statements fetches and files goes straight into the queue.
Matching only against open items
The robot pulls the open invoices from Microinvest and checks each statement line against that list. It recognises documents that are already settled, so no payment gets booked twice. When a line matches, the invoice is closed using the statement data.
A rulebook the accountants control
How each movement is posted is decided by an Excel rulebook: keywords from the payment description, income or expense, IBAN, and the debit and credit accounts. n8n runs those rules.
| Type of movement | How it is handled |
|---|---|
| Invoice payments | Matched to the open invoice, which is then closed |
| Salaries | Dedicated rule set |
| ATM withdrawals | Dedicated rule set |
| Bank fees | Dedicated rule set |
| Budget and tax payments | Dedicated rule set |
| Related-party payments | Dedicated rule set |
Postings that look like manual work
- Finding the counterparty. If a counterparty does not exist in the accounting system yet, the robot looks it up in the Bulgarian Commercial Register and creates it with its default accounts.
- Writing straight to the books. Matched payments go into each company's own Microinvest database through a secure VPN. We modelled the database operations on entries keyed in by hand on the application's own screens. As a result, the outcome matches manual entry exactly.
Exceptions that make it smarter
We separate business exceptions (a rule is missing, a company cannot be matched) from system exceptions (a referenced document cannot be found, or has already been paid). Company names often differ: Latin script on the statement, Cyrillic in the accounting system. In that case the robot sends a confirmation form and stores the reply, and the match holds from then on.
Reports and safeguards
- Each statement gets its own line-by-line Excel report: IBAN and currency, type of operation, counterparty and account, amount and its euro value, document number, dates, description, closing balance after the operation, execution ID and status. The report is saved to SharePoint and emailed to the team.
- Lines are logged as they are processed, so a run that stops halfway can be restarted without creating duplicates.
- Statement files sit on the automation server only while they are processed and are removed straight afterwards. Access to the server requires 2FA.
Stack
| Layer | Tools |
|---|---|
| Orchestration | Self-hosted n8n with a JavaScript rules engine |
| Reading statements | In-house connectors for 5 Bulgarian banks |
| Accounting | Microinvest Delta Pro through our MSSQL connector over OpenVPN |
| Data enrichment | Bulgarian Commercial Register lookup |
| Reporting | Excel, email, Microsoft SharePoint, Microsoft Graph API |
03
The outcome
| Before | After | |
|---|---|---|
| Lines posted manually | Every line | Roughly 10% |
| Double payments | Spotted late, or never | Blocked before posting |
| Audit trail | Whatever the accountant remembered | Each posted line linked to statement, execution and rule |
| Unrecognised counterparty names | A question every time | One question, answer kept permanently |
- Roughly 90% of transactions are reconciled and posted with no accountant involved.
- Most of the other 10% are lines that came from the bank without a usable description. The team gets them as a short exception list, not a whole statement to work through.
- Each posted line can be traced to the statement it came from, the execution that handled it and the rule that mapped it.
- Name mismatches resolve over time: each completed form is saved, so the same question never comes back.
- This is robot number three in a programme. The Microinvest connector and the Commercial Register lookup it uses were first built for invoice processing.
Three robots at one accounting firm: statements download, invoices post, payments reconcile, and nobody retypes a thing.
Where it usually goes wrong
Over time clients introduce new kinds of payments, and the rules stop fitting. If nobody owns the rulebook, the match rate slides without anyone noticing. What keeps it at 90% is that the rules live in a workbook the accountants maintain themselves.
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 and advisory practice · Bulgaria · major clients in pharma, healthcare and R&D, some US-listed
On-Premise RPA for Bank Statement Entry
- working days returned each month
- ~9
- working days returned each month
- statement lines keyed in by the robot
- 200-300
- statement lines keyed in by the robot