In the morning, someone opens the bank statement in one window and the list of invoices in another and starts ticking things off. At ten payments a day, that works. At a few hundred, with companies that pay three invoices in a single transfer and write “goods” as the reference, it turns into detective work. Automated bank reconciliation matches the clear-cut payments on its own and sets the rest aside for you.
The gain is not only in hours. When payments are recorded the same day, you know who has paid before you ring to chase the money, you do not hold orders up for nothing, and you have a list of unpaid invoices you can trust.
How the bank statement gets into the software
There are two routes, and we often use both. The first is files exported from internet banking. Some formats are designed to be read by software (MT940 and CAMT.053 are banking standards for statements), others are plain CSV tables. We write a separate reader for each bank and format, because the same information sits in a different place from one bank to the next.
The second route is a direct connection: interfaces offered by the bank, or open banking (access to your account data, with your consent, through an authorised provider). What is available depends on your bank and the type of account, so we check at the outset and make no promises beforehand. Whichever way it comes in, each transaction is saved only once, even if someone uploads the same statement twice.
The rules by which a payment finds its invoice
Matching is done in tiers, from the most certain to the least. Each tier has a confidence level, and you decide from which level upwards the system is allowed to record a match by itself.
The system learns from confirmations in a simple, verifiable sense: once you have linked an IBAN to a customer, it recognises it the next time. We do not use models that guess without being able to explain why.
- Invoice number in the reference and an identical amount: a certain match, recorded automatically.
- A known IBAN and a single open invoice for that amount: almost certain.
- A name similar to the one on file, identical amount: a suggestion to confirm.
- An amount equal to the total of several invoices for the same company: a proposed grouped payment.
- An amount lower than the invoice: a proposed partial payment, with the balance left open.
- None of the above: an unidentified payment, sent to a person.
Where automated bank reconciliation stops
No honest system matches everything. There will always be payments from individuals paying on behalf of another company, transfers with an empty reference, and payments from which the customer has deducted a return on their own initiative. These land on a work screen where the operator sees the transaction, the candidate invoices and the reason the software did not decide.
Take an example: a company transfers you an amount that does not correspond to any combination of invoices. The operator can split it across several invoices, leave it as an advance payment or mark it for clarification. The decision stays on record, under the operator’s name, and can be undone.
Bank charges, interest and transfers between your own accounts are recognised by their pattern and kept out of the operator’s way. How they are entered in the accounts is for your accountant to decide; the system only labels them.
The unpaid invoices report and what else comes out of the same data
Once payments are linked to invoices, the list of unpaid invoices is calculated automatically and is up to date. From there you can trigger payment reminders, with the wording and frequency you choose, or an internal rule that stops deliveries above a limit set by the company.
The result also goes to accounting, as an import file or through an API (a direct link between programs), so that your accountant no longer has to enter the statement line by line.
- Balance for each company, with its open invoices and how old they are.
- Unidentified payments and unallocated advances, with how old they are.
- The share of automatic matches, tracked over time, as a sign that the rules are sound.
The trial on real statements and the build itself
We start from real statements from recent months and the invoices from the same period. We run them through the rules and count: how many match with certainty, how many with a suggestion, how many not at all. Only after this trial do we know how much automation can take on in your case.
We usually build in Python, with a PostgreSQL database (a relational system, well suited to transactions that must not be lost), as a separate application connected to your invoicing software. For a while, the system runs alongside the old method. One piece of advice that helps more than any algorithm: put a clear payment reference on your invoices.
Frequently asked questions
Does it work with any bank?
With any bank from which you can export the statement in a format that software can read. It is easy to check: you send us a sample statement. A direct connection, without files, depends on what the bank in question offers.
How many payments will match without anyone stepping in?
We cannot say before running the rules on your data. Companies that quote the invoice number are easy to match; private individuals and grouped payments are harder.
Can the system also make payments to suppliers?
Reconciliation reads the account; it does not move money. Bulk payment files can be prepared, which you upload and authorise yourself in internet banking, if the bank accepts such files.
This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.