Wednesday, half past nine in the morning. The finance director of a group with three companies and accounts at five banks takes a call from the relationship manager: the revolving credit facility expires next month, and the bank wants to know whether to renew it and for how much. The honest answer is "it depends". It depends on a project a customer has not yet paid for, on how much raw material purchasing will come to in November, and on whether the 23rd, when salaries and a lease instalment fall on the same day, is covered or not. The cash flow sheet exists, in a well-built spreadsheet, updated on Fridays by someone in the finance team who exports statements from each bank, pastes them in, reconciles what they can and adjusts the forecast by hand. Today is Wednesday, and money has already come in and gone out that the sheet knows nothing about.
Nobody in this scenario is doing a bad job. Treasury is simply being managed from a snapshot taken five days ago, projected with assumptions only one person knows. In a group with several banks and payment terms that vary from customer to customer, it is the difference between negotiating credit well in advance and asking for it in a hurry.
Short answer
To stop running cash flow on bank statements and a spreadsheet updated on Fridays, treasury needs three layers, in this order: a consolidated position read directly from the banks, automatic reconciliation of transactions against the ERP and, only then, a 13-week forecast using the direct method, built from real invoices, orders and commitments. AI helps at specific points, such as estimating when each customer will actually pay, but the arithmetic is done by auditable rules. A consolidated position costs between €15,000 and €28,000 and, with forecasting and scenarios, between €28,000 and €45,000; with a single company and one or two accounts, a spreadsheet is still enough.
The forecast is the last layer, not the first
When a company decides to "do cash flow forecasting", the temptation is to start with the forecasting model, because that is the part that shows up in demos. But the most common starting point has two problems: the current position is not consolidated anywhere, and some of the transactions have not yet been reconciled against the invoices they relate to.
That is why a treasury system that works has three layers, in this order. First, a reliable consolidated position, read directly from the banks, by company and for the group. Second, automatic reconciliation of transactions against what is in the ERP, so you know what has already been received and paid. Only then comes the forecast, which starts from that clean position and projects the coming weeks from real commitments. Artificial intelligence comes in at specific points in the last two layers, not as the engine for everything.
Signs your treasury needs more than a spreadsheet
- knowing the group's total balance means logging into several online banking portals;
- the weekly position takes half a day of work to put together;
- bank reconciliation carries "unidentified" transactions from one month to the next;
- the forecast assumes customers pay on the invoice due date;
- nobody can say, objectively, how far off last month's forecast was;
- decisions on credit lines, factoring or early payments are made on gut feel;
- if the person who maintains the sheet is on holiday, the sheet stops.
When several of these signs come together, the cost is no longer just the team's time. It has become the financial cost of deciding late.
How it works under the hood
Consolidated position: reading the banks without manual files
The bank connection is made through open banking under PSD2, the EU Payment Services Directive. It created what are known as account information services, which let an authorised provider read balances and transactions on payment accounts accessible online, with the account holder's consent. In practice, the most common route for a platform like this is not to get licensed itself but to rely on an aggregator that is already a registered provider, with Banco de Portugal (the Portuguese central bank) or another EU authority, and which maintains connections to dozens of banks. Who is formally the provider towards the company is set out in the contract with that aggregator, and it is worth having your legal team look at that from the start. Access is read-only. No money leaves the account this way.
There are details worth knowing before you start. Consent is given by whoever has authority over the accounts, bank by bank and company by company, and the authentication has to be renewed periodically, currently every 180 days as a rule; the system should warn you before a connection expires, so the position does not quietly go stale. Not every account is covered in the same way: revolving credit accounts, factoring accounts, company cards or foreign currency accounts sometimes do not appear through open banking, or appear with less detail. For those, the system imports statements in standard formats such as CAMT.053 or MT940, or an export from online banking. No account gets left out just because it is harder.
PSD2 is under review at European level. The new package, a third directive and a Payment Services Regulation, has been politically agreed, but formal adoption is still to be completed and there will be a transition period before it applies. Open banking is here to stay, but it is a point to keep an eye on with your legal team and with the aggregator you choose.
In a group, the consolidated position also has to identify transfers between companies. A transfer from the parent company to a subsidiary is not new money, and if it is not flagged as intra-group it distorts the total. Accounting consolidation proper is a separate subject, which we covered in the article on custom ERP for enterprise groups and holdings; here, all that matters is that the group balance is the true balance.
Reconciliation: where the time really goes
Reconciliation is the least glamorous part and the one that saves the most work. It looks trivial until you look at real cases: one customer pays five invoices in a single transfer, another pays an invoice in three instalments, a third deducts a credit note that has not yet been issued. Card terminal receipts arrive net of fees and batched by day. Factoring pays the advance on one day and the balance weeks later. And the transaction description is often a truncated string where the invoice number appears in a different format, or not at all.
The way to solve this is a cascade. First, deterministic rules: payment reference, SEPA transfer identifier, invoice number in the description, exact amount and the right customer. Then, approximate matching: combinations of the same customer's open invoices that add up to the amount received, with a tolerance for bank charges. Whatever is left goes into an exceptions queue, already carrying suggestions ranked by likelihood, and whoever confirms a suggestion is teaching the system. The goal is not to reconcile everything automatically, which is a promise we do not make. It is for the finance team to handle exceptions instead of matching lines. It is the same logic we use to read PDF invoices and orders and post them to the ERP: checks first, and an exceptions queue for whatever needs judgement.
A 13-week forecast using the direct method
Thirteen weeks is the standard horizon in treasury for a practical reason: it covers a quarter, week by week, which is the window in which you decide whether to renew a credit line, bring a payment forward or delay a purchase. Beyond that, the forecast moves to monthly and leans more on the budget.
The weekly projection is built from what is already committed. On the receipts side, open invoices, confirmed orders still to be invoiced and recurring contracts. On the payments side, supplier invoices according to the company's actual payment policy (if you pay on Fridays or on the 25th, the forecast needs to know that), salaries, rent, loan repayments, taxes and investments already approved. Every line of the forecast has a traceable source: click on a figure in week 7 and you see which invoices and commitments make it up.
On top of this sit scenarios: the base case, one where the three largest customers pay 30 days late, another where a large order slips by a month. Management needs to know in which week the headroom disappears if things go badly, and to get an alert when the projection crosses a set threshold.
Where AI genuinely helps, and where simple statistics are enough
| Forecast component | What works best |
|---|---|
| Salaries, rent, leases, loan repayments | Fixed calendar. No AI. |
| Supplier payments | The company's payment policy rules |
| Actual payment date per customer | Payment delay history per customer; a machine learning model when there are many customers and behaviour varies |
| Counter sales, retail, card receipts | Time series with weekly and annual seasonality |
| Classifying transactions with no reference | Classification and language models, with human confirmation |
| Explaining variances | A language model writing about figures already calculated |
The place where modelling adds the most value is payment behaviour. The invoice says 30 days, but the customer consistently pays at 55, except in December. Another pays on time, but only after a reminder. For many companies, a median of days late per customer, updated every month, already improves the forecast a great deal compared with using the due date. A more elaborate model pays off when there are hundreds of customers, when behaviour changes with invoice value or time of year, and above all for spotting early the customer who is starting to pay worse. That alert, on its own, is often worth more than the forecast.
Language models are useful for classifying transactions with no apparent rule and for the weekly explanation of variances: "week 41 came in €140,000 below forecast because two customers did not pay invoices due on the 10th and a supplier payment was made early". The rule we follow is that the model writes about figures the system has already calculated, using auditable rules. It is never the one doing the arithmetic.
Common mistakes that make the forecast useless
Buying a forecasting tool before sorting out reconciliation. A projection that starts from a wrong balance, or from invoices already paid without anyone knowing, is wrong from day one, and the team stops trusting it within a month. It is one case of a broader problem: knowing whether your company data is ready before investing in AI.
Forecasting with due dates. It is the most common assumption and the most optimistic. The paperwork says one thing, each customer's history says another.
Presenting a single number, which gives a false sense of precision, instead of scenarios that show where the risk is.
Not comparing forecast with actual. Without measuring the error every week, nobody knows which parts of the forecast they can trust.
From the first conversation to switching off the old sheet
1. Free diagnosis
A 30-minute conversation about the group structure, the banks, the systems in use and where the manual work sits today. It is free and carries no obligation to proceed.
2. Discovery and proposal
Two to three weeks mapping accounts, banks, ERPs and files, and analysing a sample of a few months of real statements. This analysis is what tells us how much of the reconciliation can be automated and which exceptions will remain. Scope, timeline and investment are agreed here, in a proposal that should break down each item, as we show in the article on what a custom software quote should include.
3. Building layer by layer
Between 10 and 16 weeks, in two-week cycles with a demo at the end of each one. The consolidated position comes first, because it is useful from the very next day; then reconciliation, then the forecast and scenarios.
4. Forecast running alongside the current spreadsheet
For a few weeks, the system and the spreadsheet run side by side. The old sheet is only switched off once the team trusts the numbers.
5. Go-live and fine-tuning
Training, documentation and three months of follow-up support, while the payment behaviour models build up history.
Investment and timeline
These are the figures we publish on the financial and treasury management page:
- Consolidated position, with balances from several banks, transactions and automatic reconciliation: between €15,000 and €28,000.
- Treasury with forecasting, which adds cash projection, receivables and payables, and scenarios: between €28,000 and €45,000.
- Financial platform, with cost centre budgeting, multi-step approvals and consolidation across companies: from €45,000.
When the board also wants to see treasury alongside operational indicators such as sales, margins or the order book, the work moves closer to a management dashboard, which typically falls between €20,000 and €35,000.
What pushes the figure up: the number of companies and of different ERPs, banks or accounts without open banking coverage, multiple currencies, factoring and reverse factoring (confirming) arrangements, and highly business-specific reconciliation rules. What brings it down: a single ERP with documented access to the data, few banks and a disciplined invoicing process. It also helps to come with a prototype of the treasury sheet built in ChatGPT, Claude or Gemini, because it shows what the finance team wants to see and shortens discovery. What a prototype does not bring is still missing, such as user accounts and access, the real connection to the banks and the ERP, backups and testing, which is what we explain in the article on taking an AI-built prototype into production.
When it is not worth it
With a single company, one or two bank accounts and a predictable collection cycle, a well-maintained spreadsheet is enough, and we say so in the diagnosis. Nor is it worth it when the group already runs a single ERP with a reasonable treasury module and the process fits it: in that case, the best investment is getting that module working properly.
There are also off-the-shelf treasury tools that do the essentials well when the banks are covered, the ERPs are supported and the process is standard. A custom solution makes sense with several ERPs, your own reconciliation rules, a forecast tied to operational data such as orders, projects or contracts, or when per-entity licensing across a group starts to cost more than building.
What the finance team should have to hand
- How many bank accounts, at how many banks and across how many companies?
- How much time a week goes into building the position and reconciling today?
- Which decisions would be made differently with a reliable 13-week forecast?
- Is the invoicing, order and supplier data in an ERP with data access, or spread across several systems?
- Who in the finance team will be responsible for validating the forecast every week?
The third question carries the most weight: if the answer is "none", the spreadsheet is still the better option. If your group's treasury still depends on statements pasted in by hand, you can request a free diagnosis. We look at the banks, the systems and the current process, without commitment, and return a proposal with scope, timeline and investment defined.
