There are companies where the money coming in and the paperwork bear no resemblance to each other. The documents are hundreds of daily transactions of minimal value, recorded by a vertical management system. The money is a single payout arriving once a month from a payment gateway, covering a period that does not line up with the accounting month. In these conditions automated bank reconciliation stops being a convenience and becomes the only way to know what has actually come in, because nobody can rebuild by hand the link between an aggregated payout and the transactions behind it.
The pattern affects a growing number of business models: subscriptions, metered consumption, online sales, digital receipts. These are companies that behave financially like a flow, while accounting still treats them as a sequence of documents.
Automated bank reconciliation is not decided by reading the movements
Reading the bank statement is the part already solved. Treasury platforms connect to accounts through the banking interfaces provided under payment services regulation and pull movements in without manual work. The critical point arrives immediately afterwards, and it sits in two questions: what is this movement, and which document does it belong to.
The first question is about classification, the second about matching. They are different jobs, they need different data, and they are often confused during evaluation. The result is that a company buys a platform to solve matching and discovers the classification rules are still to be defined.
Bank reconciliation: rules or algorithm for categorising movements?
Categorisation rests on rules the company defines, by supplier or by cost type, alongside an automatic algorithm that learns from movements already classified and proposes the category.
The two components coexist and neither is sufficient alone. The algorithm works well on recurring, recognisable movements, where the description is stable and the beneficiary repeats. Rules cover everything else. They matter most when classification has to reach a granularity the automation cannot guess: the split by business unit, by project, by product line. This is where automated bank reconciliation stops being a technical topic and becomes a financial control topic. The more mature platforms also allow a single payment batch to be split across several categories, the typical case of one transfer to a supplier who invoices items of different natures.
This deserves saying plainly, because it is where projects lose time: defining the rules is initial, manual work, and it falls to whoever knows the chart of accounts. In the early phases of a project it is one of the activities that absorbs most attention, and the quality of the result depends on how well that work is done rather than deferred. Deferring it makes it more expensive.
Automated bank reconciliation and payouts from a payment gateway
A payment gateway connects to the treasury platform as though it were a bank account: individual payouts become visible movement by movement, not as an end-of-period total. It is the first step that makes a stream of recurring collections readable.
The documents remain, and this is where automated bank reconciliation meets its most frequent limit. When a sale produces a digital receipt rather than an electronic invoice, automatic retrieval of the data from the Revenue Agency behaves differently depending on the section the document is filed under. Online commercial documents, in particular, are not pulled automatically in the large majority of cases: how far each platform covers this varies and needs checking at evaluation time. Anyone wanting to understand the wider framework of Italian VAT and electronic invoicing obligations can start from the Revenue Agency guidance on VAT in Italy, bearing in mind that delegating access to an intermediary is an administrative step to schedule, not a software setting.
Automated bank reconciliation: a case from the field
A company invoicing subscriptions and consumption through a vertical management system sat exactly in this position. Money arrived from the gateway once a month, aggregated, out of step with the period it related to. The vertical system produced the documents as digital receipts. The result was a cash position nobody could close: every amount was there, but not in the same month, and none of it spoke to the rest.
What changed the approach was giving up on one-to-one matching. The project connected the gateway as an account, so payouts became individual, dated movements. Categorisation rules separated the components of the flow. The platform APIs took the documents produced by the vertical system and aligned them, closing the loop on the accounting side. Reconciliation stopped being an after-the-fact reconstruction and became a check on a queue of exceptions, which is work of a different order of magnitude.
Forecast, due, collected: three states of the same line
Automated bank reconciliation does not only close positions: it feeds the forecast. The costliest confusion in treasury is adding up expected collections that never became collections. Platforms with a serious forecasting module distinguish the state of each line visually, and the distinction is worth understanding before signing, because it changes how the board reads the dashboard.
An estimated collection can be entered before the invoice exists, for instance against a won order or an expected renewal. When the company issues the invoice, the line changes state and becomes a real due date, tied to a document. When the payment appears on the account, the line changes state a second time and becomes a realised collection.
| State of the line | Where the data comes from | What it can be used for |
|---|---|---|
| Forecast | Estimate entered by hand or a recurring rule | Planning, knowing the document does not yet exist |
| Document issued | Invoice or receipt retrieved from the sales cycle | Committing the forecast to a certain due date |
| Collected | Matched bank movement | Closing the position and feeding the delay history |
Three states readable at a glance prevent the error that costs most: taking a liquidity figure to the board that includes money never received. The state is read, not summed. Anyone who has already set up a structured cash forecast will recognise the same principle applied to the current month rather than the annual horizon, and will find the wider picture in the article on the five fatal mistakes of managing treasury in Excel.
Matching collections: APIs when the invoice is created outside accounting
In consumption-based models the document is generated by the software that measures the service delivered, not by the accounting system. The APIs of a treasury platform import and export movements, invoices and receipts between the platform and that system. Financial data and commercial data stay aligned without double entry.
Feasibility always has to be validated against the specific system in use, and this holds as a general rule: an integration described as available is not yet an integration verified against the real data structure. The proof is in the file format. In the treasury projects Aesir Srl runs, reading the data structures and testing the exchange is the first technical activity, before any platform configuration.
Where feasibility is verified
On the ERP side the door stays open: Aesir is Gold Partner of NTS Informatica for Business Experience, and with other systems we use the connectors available or build them. The platforms we select process data in datacentres within the European Union, with certifications from the ISO/IEC 27001 family and requirements aligned with NIS2: the same standards applied to the Aesir infrastructure, which operates Tier IV datacentres in the EU with replication. The link between expected collections and how customers actually behave is developed in the article on credit management and average payment delay.
Automated reconciliation: checks before connecting the accounts
Six checks worth running at evaluation stage, whichever platform is chosen:
- Which institutions and which collection gateways can be connected today, and which need a data structure to be agreed?
- Is the gateway treated as an account with individual movements, or as a period total?
- Does categorisation reach the granularity financial control needs, or stop at cost type?
- Can a single payment batch be split across several categories?
- Which system produces the sales cycle documents, and how often are they refreshed?
- Are the delegations for accessing documents at the Revenue Agency already active, and with which intermediary?
The last item is the one that most often stretches the start-up timeline, because it is an administrative formality and does not depend on whoever configures the platform.
Frequently asked questions
Can a treasury platform replace the invoicing software?
Several platforms are enabled to issue documents and can cover invoices, self-billing and quotations. The choice is best assessed against the existing sales cycle: where invoicing is already produced by a vertical system, it is usually more robust to leave it there and align the data through APIs.
What is the difference between classifying a movement and matching it to an invoice?
Classifying means assigning the movement to a cost or revenue category, which serves financial control. Matching means linking it to the document that originated it, which serves to close the customer or supplier position. A complete platform does both, from different starting data.
How much manual work remains after go-live?
The queue of exceptions remains: partial collections, aggregated payouts, new movements to classify for the first time. The volume falls as the rules are refined, and the difference from a spreadsheet is that the platform lists the exceptions rather than making someone hunt for them.
Can gateway payouts be traced back to individual receipts?
Connecting the gateway makes the payouts visible one by one, which is the basis for doing it. Automatic retrieval of digital receipts depends on the section the documents are filed under and on the state of each platform, so it needs checking case by case during analysis.
Let’s talk
The value of a treasury platform in these settings does not sit in the automation it claims. It sits in narrowing the perimeter of manual work to a finite, visible list. There is one check to run before choosing: understand which systems produce the sales cycle documents and in what form the money arrives on the account. When those two things are clear, evaluating a platform becomes quick. When they stay implicit, any platform will look adequate during the demo and insufficient by the third month. If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.