We implement the Whizzer project with the help of EEA & Norway Grants, as part of the “SMEs
Growth Romania” program, operated by Innovation Norway Romania. The total nonrefundable value of the grant is EUR 420k. This money allows us to invest in developing an application aimed to help SMEs better manage their finances.
For this project, we partnered with Bakken & Bæck, a development studio based in Norway, to help us make sense of the data processed by our application. They helped us define a matching algorithm for transactions available in the application. This algorithm is useful for some of the reports delivered by the application to its users: accounts payable and accounts receivable and cashflow reporting and forecasting.
We here describe the reconciliation process:
The data analysis algorithm screens for relationships between processed transactions and creates pairs and possible pairs of transactions. A ranking system is implemented, that chooses those transactions that are the most probable pairs. Where automated relationships cannot be found, the user is shown possible pairs, available for manual matching.
There are two options for reconciliation: automated and manual. Transaction categories eligible to this algorithm are:
- debit transactions from the bank statement, with incoming invoices
- debit transactions from the bank statement, with instructed payments
- credit transactions from the bank statement, with instructed payments
- credit transactions from the bank statement, with issued invoices.
The criteria for creating pairs of transactions is a series of fields that are part of these categories, with an exact match. The algorithm learns while processing data and suggests pairs of transactions based on historic behavior.
In the analysis of data available for payments and invoices, a number of scenarios where matching could fail were identified:
- the same invoice is paid twice: one is automatically matched, and one shows as possible duplicate and can be manually closed
- the same invoice is split in two different credit or debit transactions
- invoices and bank statements are either issued in different currency, either include fees and commissions or even some sort of dynamic conversion rate. Issue: what do fees look like in the statement and how can these be linked to the initial transaction? This topic is still under analysis.
- a payment is instructed to a beneficiary name other than the one listed on the invoice.
Below are the processing flows, including states of transactions and statuses:
If you wish to collaborate with Allevo and Bakken & Bæck to test beta functionality, available in the near future, we are more than open to run some tests with some early adopter SME companies. You help us improve our solution and maybe you gain improvement of own financial processes.
What we bring is not a robotic type of automation, but an automation that improves the process and that makes it safer and more transparent.