Manually processing bank statements is one of the tasks where the finance team spends the most time. Hundreds of rows, each waiting to be linked to a current account.
The annoying part of the job is that most of these rows are repetitive in nature. The same customer sends transfers every month with the exact same description.
In this article, we explained how bank integration works, how the rule engine automates matching, and how exceptions are managed.
Table of Contents
How does integration work?
Bank integration allows account activities to be automatically retrieved from the bank. There is no need to download and upload statements.
Transactions are pulled at regular intervals and listed as pending records in the system. Each row contains the date, amount, counterparty, and description.
At this point, an accounting entry has not yet been created. Transactions need to be linked to a current account and, if necessary, an invoice.
Integration setup is done through bank account definitions; see the cash and bank definitions article.
What is the rule engine?
The rule engine is the structure that automatically classifies and matches incoming transactions based on specific conditions.
The logic is simple: if the transaction meets these conditions, link it to this current account and record it this way.
Rules are enriched over time as they learn. While there are few rules in the first month, by the sixth month, the majority of transactions become automatically matched.
A similar rule logic is also used on the CRM side; CRM automation rules you can check out the article.
Which rules should be set up?
Counterparty-based. Every transaction coming from a specific IBAN is linked to that current account. This is the most reliable rule type.
Description-based. Transactions whose descriptions contain a specific text are matched. This works effectively if the customer regularly includes the company name.
Amount-based. Used for regular payments with fixed amounts. Rent, subscriptions, and loan installments fall into this group.
Expense item-based. Payments coming from a specific source are directly assigned to an expense item; service and expense definitions check out the article.
Rules can be combined. A definition such as "transactions coming from this IBAN and with an amount in this range" yields more precise results.
The importance of description discipline
The success of automatic matching depends on the quality of the description. A bank transfer with an empty description is always processed manually.
Therefore, telling your customers what to write works well. Asking them to write the invoice number or current account code makes the job easier for both sides.
When a payment link is used, this problem is solved from the root; the payment is already linked to a specific invoice. Payment link we covered in the article.
Description discipline should also be applied to the payments you send yourself. When the counterparty's reconciliation is easier, your job becomes easier too.
Unmatched transactions
No rule works a hundred percent. Unmatched transactions should be gathered in a separate list and processed regularly.
If this list starts to grow, one of two things has happened: either a new customer has been added or an existing rule has broken.
Every manually matched transaction is an opportunity for a new rule. If you are doing the same transaction manually for the second time, it is time to write a rule.
The number of pending transactions can be tracked via notifications; notifications alert you when thresholds are exceeded.
How much time does it save?
The gain is directly proportional to the number of transactions. For a business with fifty transactions a month, integration is not mandatory.
For a business with five hundred transactions a month, manual processing takes days. Automatic matching reduces this time to hours.
The real gain is in timeliness rather than time. When statements are processed weekly, current balances lag by a week; daily pulling closes this gap.
Up-to-date balances enable the sales team to make accurate decisions; risk limit control is only meaningful with current data. Collection risk check out the article.
Integration and rule definitions in the finance module are made.
Security and authorization side
Bank data is among a business's most sensitive data. When setting up an integration, access control must be designed alongside technical capability. This is not a layer to be added later.
The basic principle is this: viewing transactions and making transactions are different permissions. A user who views statement lines and performs matching does not need payment initiation authority. Separating these two permissions is valuable for both security and internal control.
In multi-company structures, each company's bank accounts must remain within their own scope. A finance manager of one company is generally not expected to see another company's account; multi-company scope model ensures this separation.
Rule definition authority must also be restricted. A wrongly established rule can link hundreds of transactions to the wrong current account, and reversing this error is tedious. Rule changes should be kept in the audit trail; sensitive transaction authorities we discussed this distinction in the article.
Staging the setup
Initiating bank integration with all accounts at once generates an uncontrollable stack of records in the first week. A staged setup is much safer.
In the first phase, start with a single bank account; preferably the main account with the most activity. Incoming transactions are monitored for a month and repeating patterns are noted. This observation forms the basis of the rule set.
In the second phase, initial rules are written and the automatic matching rate is measured. This rate is the only indicator showing the true benefit of the integration. When it exceeds sixty percent, the team begins to feel the difference.
In the third phase, other accounts are added. At this point, the team now knows how to handle exceptions, and new accounts do not cause problems.
The same approach of starting with a narrow scope applies to other modules as well; pilot project selection we detailed this approach in our article.
Frequently asked questions
Which banks do you work with?
Scope varies by bank and account type; get confirmation for your own bank before setup.
Can the integration make payments?
Transaction reading and payment initiation are different permissions; clarify the scope during setup.
What happens if a rule matches incorrectly?
A correction is made and the rule is revised. That is why supervision is important in the initial period.
Can reconciliation be done without bank statements?
Manual upload is also supported; automatic retrieval only speeds up the process.
Bank integration automates the most repetitive task of the finance team. As rules mature over time, manual work is reduced solely to exceptions.
By consulting with the EQLEM team, you can plan your bank integration and rule configuration.