Accounting & Bookkeeping · Professional Services · Banking Operations
Bank Reconciliation Automation
- Client
- Accounting firm · Bulgaria · 10-15 staff, books kept for 100+ client companies
- Industry
- Accounting & Bookkeeping
- Department
- Finance & Accounting
- Region
- Bulgaria
- Duration
- 6 weeks
- Delivery team
- 3 people
A payment registered twice, or an invoice left open weeks after it was paid: that is what line-by-line manual reconciliation produces at month-end. Now about 90% of bank transactions reconcile and post themselves, and accountants only see the lines that need judgement.
A working model of the approach on sample data. It plays on its own and pauses when scrolled away; nothing here touches a live system.
The results
- ~90%
- of transactions auto-reconciled and posted
- The rest are lines the bank sent with no usable description.
- 5
- bank statement formats supported
- A new bank is a template: the latest took about four hours.
- 0
- payments registered twice
- Settled documents are detected before anything posts.
The challenge
Our client is a Bulgarian accounting and financial-management firm of 10-15 people keeping the books for more than 100 client companies in Microinvest.
Every line on every bank statement was read and posted by hand: find the invoice the payment settles, check it has not already been paid, identify the counterparty, decide which accounts the movement belongs on. Per account, per company, every month. Salary runs, ATM withdrawals, bank fees and budget payments each follow their own rules.
What it was costing them
- Double-posting and stale open items. A payment registered twice, or a paid invoice left open, distorts a client's books and is found late.
- Skilled time on routine lines. Most lines are predictable, yet accountants spent judgement-level time on every one.
- A bottleneck at the end of the chain. Reconciliation is the last step before closing, so any delay pushes the whole close.
The approach
We built an unattended bank reconciliation robot on a self-hosted n8n platform that posts straight into the accounting system.
Reading any bank's statement
Structured, per-bank connectors read each statement format. Five Bulgarian banks are supported, and a new bank is a new template rather than a rewrite: the latest one took about four hours. Structure and key fields are validated before anything is posted. Statements downloaded and filed by our statement download robot feed straight in.
Matching against what is actually open
The robot loads open invoices from Microinvest and matches each statement line against them. Documents already settled are detected, so a payment is never registered twice. Matched invoices are closed with the statement data.
Rules the accountants own
An Excel rulebook of description keywords, income or expense, IBAN and debit and credit accounts decides how each movement is posted. The rules execute inside n8n.
| Movement type | Handling |
|---|---|
| Invoice payments | Matched to the open invoice and closed |
| Salaries | Own rule set |
| ATM withdrawals | Own rule set |
| Bank fees | Own rule set |
| Budget and tax payments | Own rule set |
| Related-party payments | Own rule set |
Posting identical to manual entry
- Counterparty resolution. Counterparties missing from the accounting system are looked up in the Bulgarian Commercial Register and created with their default accounts.
- Direct posting. Matched payments are registered in each company's own Microinvest database over a secure VPN. The database operations were derived from entries made through the application's own screens, so the result is identical to manual entry.
Exceptions that teach the system
Business exceptions, such as a missing rule or an unmatched company, are kept apart from system exceptions, such as a referenced document not found or already paid. When a company name does not match, Latin on the statement and Cyrillic in the accounting system, the robot sends a confirmation form and writes the answer back, so the match is permanent.
Reporting and safety
- Every statement produces its own Excel report, line by line: IBAN and currency, operation type, counterparty and account, amount and euro equivalent, description, dates, document number, balance after the operation, status and execution ID. Filed to SharePoint and emailed to the team.
- Every processed line is recorded as it goes, so an interrupted run can be repeated without duplicate entries.
- Statement files are downloaded to the automation server only for processing and deleted immediately after. The server itself requires 2FA.
- IBAN, currency, operation type
- Counterparty, account and amount
- Document number, balance after
- Status and execution ID
- Filed to SharePoint and emailed
Technology
| Layer | What we used |
|---|---|
| Orchestration | n8n, self-hosted, with a JavaScript rules engine |
| Statement reading | Our own per-bank statement connectors, 5 Bulgarian banks |
| Accounting system | Microinvest Delta Pro, via our own MSSQL connector over OpenVPN |
| Enrichment | Bulgarian Commercial Register lookup |
| Reporting | Microsoft SharePoint, Microsoft Graph API, Excel, email |
The outcome
| Before | After | |
|---|---|---|
| Statement lines posted by hand | All of them | About 10% |
| Duplicate payments | Found late, if at all | Prevented before posting |
| Traceability | The accountant's memory | Statement, execution and rule for every posted line |
| Unknown counterparty names | Asked every time | Asked once, stored for good |
- About 90% of transactions reconciled and posted without an accountant.
- The remaining 10% are mostly lines the bank sent with no usable description, and they arrive as a short exception list instead of a full statement to read.
- Every posted line traces back to its statement, its execution and the rule that mapped it.
- The counterparty naming problem fixes itself: every answered form is stored and never asked again.
- The third robot of a programme that reuses the Microinvest connector and Commercial Register lookup built for invoice processing.
Statements download themselves, invoices post themselves, payments reconcile themselves: three robots, one accounting firm, no retyping.
The risk most teams miss
Clients add new payment types and the rules drift. Without someone owning the rulebook, the match rate falls quietly. Keeping the rules in a workbook the accountants maintain is what holds it at 90%.
Built with
The tools this ran on, by the layer each one carried.
- Apps & integration
- Automation
- Data & cloud
Microsoft SharePointMicrosoft's platform for document libraries and team sites.
Microsoft SQL ServerRelational database behind many accounting and ERP systems.
Microsoft ExcelConfiguration workbooks and reports owned by the business.- Microsoft Graph APIAPI into SharePoint, Outlook and the rest of Microsoft 365.
Related work
Accounting & Bookkeeping70+client companies covered, twice a monthBank Statement Download AutomationAccounting firm · Bulgaria · 10-15 staff, books kept for 100+ client companiesRead the case
Accounting & Bookkeeping97%of documents need no correctionAI Invoice Processing AutomationAccounting firm · Bulgaria · 10-15 staff, books kept for 100+ client companiesRead the case
Accounting & Bookkeeping600invoices booked in a single monthly runMulti-Channel Payment Reconciliation and Accounting Import AutomationAccounting firm · Bulgaria · books for an international data centre and hosting providerRead the case
Next step
Start the same conversation
Tell us the process that keeps breaking. We will come back with what it would take to fix it, what it would cost, and what we would measure.
Or write to us directly: •••••@•••••••.•••
- A reply from a partner within one business day
- Fixed scope and fixed fee, agreed before we start
- The maps and the backlog are yours either way