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.
Allevo participated at CFO Conference on March 4th 2021. The event gathers Chief Financial Officers, entrepreneurs, business owners, top managers, fiscal consultants and experts in finance from smaller and larger corporates active on the Romanian market. Our slot was included in a panel discussion, with 397 live participants. This was the perfect audience to introduce Allevo, the experience we have in banking and how we can help address some of the issues these companies face.
Although online, we were able to address some questions and learn from our future customers what they are missing in relationship with their partner banks. One CFO says their partner bank facilitated in 2020 the centralization of their business units and helped them automate some of their processes, solving the cashpooling issue they faced.
Another CFO said banks play a very important role in the business environment and need to fund operations of smaller companies, to keep a healthy and steady economy afloat.
The third CFO replied that the most important role a bank plays is not that of funding, but helping with cash management and incoming payments, and the automation of financial processes.
This was a very good confirmation that the problem we are solving by implementing the Whizzer project is still not addressed yet. Even larger corporates still run a lot of manual financial processes in their day to day activities. This was the perfect context to present some of the results of the Whizzer project: the service itself that allows a company to get bank statements from all its partner banks and run a reconciliation process between invoices issued to customers and incoming payments, and invoices received from suppliers and outgoing payments. This helps a business owner get a better understanding on the cash at hand, and allows them to manage their liquidity way before the balance sheet is delivered by the accountant.
Why is this needed? Because not all business owners afford to hire a stand-alone CFO and quite often this role is covered by the owner, who is also a sales person, and a CEO, and a support contact for customers, all at the same time. Financial decisions are critical and need to be based on acurate data. Whizzer comes to the rescue by providing an overview of the cashflow situation, what payments and invoices look like, a rough balance sheet based on information processed by the application and an accounts payable, accounts receivable department in its own right.
While implementing the application we learned the following:
- reconciliation between invoices and bank statements need to be first split by “direction”, creating thus two subcategories of pairs: incoming payments and issued invoices; outgoing payments and received invoices
- reconciliation must be an automatic process, but manual pairs should be available for users of the application as well
- criteria for matching should be an exact match
- while scanning all transactions the algorithm should be able to suggest possible pairs, to make manual matching easier
- this algorithm should run in the background, with no impact on the performance of the application.
The audience seemed enthused by the proposal, and we already received a request for proposal after the event.
The Whizzer project is implemented in Bucharest, has an end date of 30 November 2021 and a total value of EUR 738.375, out of which EUR 420.000 non-refundable grant. The Whizzer project is aimed to create an open source software solution that offers financial operations as a service to SMEs, to help them automate and centralize common financial flows, at a very low cost: balance sheet, salary payments, invoicing, money flow automation, accounts payable and receivable, cash reporting. Target group includes banks, financial service providers and SMEs across Europe, with focus on SMEs, in terms of technical harmonization and communication on top of a well-built open banking layer.
