By the Foxnut team · Updated 6 August 2026

Comparison

Cash flow forecasting: the payment dates nobody can predict

Automated cash flow forecasting is two problems in one name: assembling the known items, and guessing when customers pay. Four arrangements, six dimensions, and where a model does not belong.

By the Foxnut team · Updated 6 August 2026

Half of a cash flow forecast is arithmetic and half of it is a guess about other people, and almost every disappointment with this software comes from buying one and being sold the other. The arithmetic half is everything already contracted: payroll, rent, tax, debt service, standing orders, the payables run with dates attached, the receipts already banked. Assembling that half is a data-plumbing job with a known answer, and automating it is uncontroversial. The other half is when customers actually pay, and that is not a fact about the company holding the forecast at all. In 2024, suppliers across the European Union reported average agreed business-to-business payment terms of 43 days and an average actual payment period of 60.3 days, a gap of roughly seventeen days between the date in the ledger and the date the money arrives. So the decision in front of a finance team is not whether to automate the forecast. It is which of four arrangements it can live with, and how much of the second half it is prepared to pay a machine to guess. Foxnut Studios builds and hands over the fourth arrangement, which is a reason to be explicit that it is the right answer least often. What that kind of build has to leave behind, and who owns a forecasting model after the build, is the question worth settling before any of this.

The four arrangements, and what actually separates them

What separates them is not sophistication. It is what each one assumes about payment dates, and what it does when that assumption is wrong.

Axis	Spreadsheet rebuilt from ledger exports	The accounting package or ERP’s own projection	Treasury platform with bank connectivity	A payment-date model on the company’s own history
What it produces	A period-by-period position, rebuilt by hand from open items and a bank balance	The same position, generated from open receivables and payables inside the system of record	A consolidated multi-account position with scenarios layered over it	A predicted payment date, or a probability of payment in a window, for each open invoice
What it assumes about payment dates	Whatever the preparer types, which is usually the due date adjusted by memory	The due date, treated as the payment date	The due date, plus rules or averages the treasurer configures	That past payment behaviour predicts future payment behaviour at the account level
Where it breaks	Staleness, and a version history nobody can audit	The seventeen-day gap between terms and reality, applied silently across every open invoice	Rule maintenance, and scenarios that multiply faster than anyone reviews them	Counterparty behaviour that shifts, thin history on new accounts, and disputes the ledger never recorded
What it costs to keep running	The preparer’s hours, every cycle, forever	Little, if the underlying ledger is clean and the bank feed is connected	Licence, bank connectivity, and an owner for the rule set	A maintained model, a monitored data feed, and someone who can tell drift from noise
Who owns it after go-live	The person who built it, and nobody else	The finance system’s administrator, by default	Whoever the vendor trained, if anyone	The trained internal team the system was handed to

The second row is the one that decides most cases. Three of these four arrangements use the contractual due date as the expected payment date, and the published evidence says that date is systematically optimistic. The fourth tries to correct it, and the interesting question is whether that correction is reliable enough to act on.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Cash flow forecasting reads unusually on three of them: the variance being modelled belongs to other organisations, the regulatory exposure is nil for most of the year and then briefly serious, and the software market is mature at exactly the half of the problem that was never hard.

Cash flow forecasting: process profile
Dimension	What it reads on cash flow forecasting	Source
Exception variance	The exception is the subject. Average agreed business-to-business terms across the EU were 43 days in 2024 against an average actual payment period of 60.3 days, and public authorities paid 9.5 days later still. The variance is structured by country far more than by sector: payment performance varies more between Member States than between sectors within one country, and construction was the most punctual sector in six Member States while being the worst performer in three others. A prior learned in one market does not transfer to another.	EU Payment Observatory, Annual Report 2025
Volume	Not invoice count. A forecast is produced on a cadence, so the effort does not scale with lines; what scales is the number of counterparties whose behaviour has to be tracked and the collections work behind it. Companies report spending an average of 9.85 hours a week chasing late payments, and 52% report facing problems from late payments in 2024, five points more than in 2023. Those hours, not throughput, are the payback condition.	EU Payment Observatory, Annual Report 2025
Cost of an error	Asymmetric, and paid in financing. An optimistic forecast costs an unplanned draw, a missed supplier payment or a fee; a pessimistic one costs idle cash and deferred commitments. The scale of the underlying constraint is not small: the European monitoring report estimates that EU micro companies, SMEs and intermediate-sized enterprises would have over EUR 100 billion a year in additional cash flow if late payments stopped.	EU Payment Observatory, Annual Report 2025
Reversibility	High for the forecast, low for the action taken on it. A projection can be rerun at negligible cost, and error compounds with horizon rather than being locked in: a probabilistic model trained on more than 3.5 million transaction entries from over 1,000 SME customers forecast 12 weeks ahead, and its authors record that multi-step prediction accumulates error iteratively and that the results could hardly meet the required coverage. The irreversibility sits in the decision, not the document.	Kotios and others, Journal of Big Data, 2022
Regulatory exposure	Nil for most of the year, then briefly and specifically serious. A cash flow forecast is not a book of record, but management's going-concern assessment covering at least twelve months from approval of the financial statements commonly rests on one, and the auditor is required to apply professional scepticism when reviewing future cash flow. Audit procedures include checking the forecast's arithmetic and testing whether it is inconsistent with forecasts prepared for other purposes such as impairment or deferred tax, where the underlying data would be expected to be the same.	ISA (Ireland) 570 Going Concern, Revised October 2019
Vendor market maturity	Mature at the plumbing, unproven at the prediction. Bank connectivity, ledger integration and scenario tooling are long-established commodities. Predicting when an individual invoice will be paid is not: a prototype built with a multinational bank reported up to 81% prediction accuracy, improved from up to 77% in the earlier report of the same work, and the stated obstacle is that the decision-making process is not registered in the accounts receivable system at all.	Appel and others, arXiv:2008.07363 and arXiv:1912.10828

Two of those rows carry the argument. The exception-variance row says the thing being forecast is a behaviour belonging to somebody else, measured across an economy where the average payer runs seventeen days past the terms it agreed to, and where the shape of that lateness is a property of the country rather than of the industry. The vendor-maturity row says the ceiling on correcting for it is set by information the forecasting company does not hold: the reason an invoice is being withheld is decided inside the customer’s payables department and is not written down anywhere the model can read.

The regulatory row is the quiet one, and it changes what a good system looks like. For most of the year nothing here is attested to anyone. Once a year the same forecast, or one built from the same data, sits underneath a going-concern assessment that an auditor examines with explicit professional scepticism, checking its arithmetic and whether it contradicts the forecasts prepared for impairment or deferred tax. What that procedure rewards is not point accuracy. It is a forecast whose assumptions are written down, whose data lineage is traceable, and which produces the same numbers as the other forecasts built from the same ledger. A system optimised for a single best-guess figure and unable to show its workings is worse at the one moment of the year when the forecast is actually inspected.

When to choose each

Each arrangement wins a real category of company. The failure modes are asymmetric, which is why the order matters more than the sophistication of any one of them.

When the spreadsheet wins

It wins when the position is simple, the counterparties are few, and the person who maintains it knows them. A single bank account, a dozen customers and a finance lead who can say which of them pays on the fifteenth regardless of terms is a forecasting system with better information than any model would have, because the knowledge that matters is relational rather than statistical. The failure mode is that it exists once and nowhere else. There is no version history, no way to see which assumption moved between two versions, and no continuity when the preparer leaves. The upgrade worth making here is almost never a forecasting product; it is connecting the bank and the ledger so the sheet stops being retyped.

When the accounting package or ERP projection wins

It wins whenever it is already licensed and the ledger underneath it is clean, which is more often than it is used. It reads open receivables and payables directly from the system of record, so it cannot drift from the books, and it costs nothing further to run. This should be settled before any build is considered, because a large share of what gets scoped as a forecasting project is an unconfigured module and an unconnected bank feed. The failure mode is the due-date assumption applied silently: every open invoice is projected to land on its terms, and the aggregate is optimistic by roughly the gap the European data records. That error is invisible in the output and consistent in direction, which is the worst combination, and it is why the first useful measurement any finance team can take is its own realised gap between terms and payment, per customer.

When a treasury platform wins

It wins with several accounts, several currencies or several entities, where the work is consolidation rather than prediction, and where somebody needs a defensible scenario view rather than a single number. Bank connectivity is genuinely hard to build and genuinely commoditised to buy, so building it is rarely justified. The failure mode is rule sprawl: the payment-timing corrections are configured by hand, they are correct on the day they are set, and nothing tells anyone when a counterparty’s behaviour has moved. Scenarios have the same problem in a different register, multiplying until nobody can say which one the business is planning against.

When a payment-date model wins

It wins where three conditions hold together: enough counterparties that the behaviour is statistical rather than relational, enough payment history per counterparty that a pattern exists to fit, and a receivables ledger that records what happened rather than only what is outstanding. The evidence that this can work is real. A prototype developed with a multinational bank reached up to 81% prediction accuracy and its authors report simulations in which prioritising collectors’ work on that basis saves up to about 1.75 million dollars a month. The failure mode is the one that same paper names: the decisions that determine payment are made in the customer’s organisation and are not registered in the receivables system, so the model is fitted to an incomplete record of its own subject. The second failure mode is quieter and shows up on the horizon that matters most for treasury: forecasting further out compounds error step by step, and the SME cash flow study above found its 12-week probabilistic forecasts falling short of their own coverage targets on real bank data.

What this comparison usually gets wrong

The category is sold as an accuracy improvement and is mostly a data-plumbing improvement. Most of the value a company gets from replacing a manual forecast is that the position is now current, complete and consistent with the ledger, which has nothing to do with prediction and everything to do with connection. That value is real and it is the majority of the benefit, but attributing it to the model sets an expectation the model cannot meet, and the disappointment arrives about two quarters later.

The second error is treating the payment date as a modelling problem rather than a commercial one. The strongest published lever on when money arrives is not a better estimate; it is the terms themselves. Longer payment terms are associated with longer payment periods in 87% of cases, larger companies are the ones paying late in 16 of 20 Member States, and public authorities pay 9.5 days later than businesses despite tighter statutory limits. A company with a payment-timing problem has a negotiation and a collections problem that a forecast can describe more precisely and cannot fix.

The third is a measurement trap that catches careful teams. Comparative payment data is thinner than it looks: the European monitoring report for 2025 records that data availability worsened relative to the previous year, with fewer sectoral and impact breakdowns available, and it names the resulting gap as a serious one. Circulating benchmark figures for forecast accuracy by horizon are worth the same scepticism, because most of them trace to treasury-software marketing rather than to any published study. A forecast accuracy target inherited from a vendor’s collateral is not a target.

There is one prior question this comparison does not answer, and it belongs before the four arrangements rather than inside them. Whether the ledger data is complete, consistently coded and current enough for any of this is a readiness question with its own answer, and a forecasting system built on a receivables ledger nobody trusts will produce a confident number from bad inputs faster than a person would.

The verdict

The evidence supports automating cash flow forecasting comprehensively on one half of the problem and cautiously on the other, and the split is clean enough to write into a scope. Automate the assembly without hesitation: bank connectivity, ledger integration, the contractually known inflows and outflows, the consolidation, the version history and the assumption log. That work is deterministic, the tooling for it is mature and mostly already paid for, and it is where the recoverable time actually sits, next to the ten hours a week the European survey data records companies spending on chasing payment. Treat a predicted payment date as an input to a range, not as a date, and do not buy one at all until the receivables ledger records why invoices go unpaid.

The reason is structural rather than a matter of the current state of the technology. Three of the six dimensions point the same way. The variance being forecast is generated by other organisations and is more a property of the country they trade in than of their industry. The information that would explain it sits in the customer’s payables department and is absent from the seller’s records by construction, which is the constraint the payment-prediction literature reports rather than a gap that more data will close. And the one moment the forecast is inspected by an outsider is an audit procedure that tests arithmetic, consistency and assumptions rather than accuracy. A process with that profile does not reward a more confident number. It rewards a current one, with its assumptions visible and its range honest.

For a finance team weighing this, the useful first move is a measurement rather than a purchase. Take the last two years of paid invoices, and for each significant customer compute the realised gap between the agreed terms and the actual payment date, along with how much that gap moves. A team that can produce that distribution already has most of the forecast improvement a model would offer, knows whether its own book behaves statistically or relationally, and can tell whether the projection built into its existing accounting system is wrong by three days or by twenty. A team that cannot produce it is being asked to buy a prediction of something it has never measured, and measuring it first costs a week. If you want a second opinion on which half of your own forecast is worth automating, bring us the distribution and we will tell you plainly.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

The accounting package or ERP already projects a cash position from open receivables, open payables and a bank feed, and that feature has never been switched on, or the bank feed was never connected. That software, and the studio says so. Connecting a bank feed and turning on a projection that is already licensed is configuration work, not a build, and paying for a custom system to produce a view the incumbent already produces is the wrong purchase.
There is one bank account, a short list of customers whose paying habits the finance lead can recite by name, and a forecast that one person rebuilds in an hour when it is needed. The person already doing it, unchanged. The cost this work removes is time spent reconciling and chasing rather than lines processed, and where that time is an hour rather than the ten hours a week the European survey data reports as the average, there is no payback to find. Connecting the bank feed to the spreadsheet is the whole of the useful automation.
Receipts are concentrated in a handful of counterparties whose payment timing is negotiated case by case, or a single late payer dominates the position. A redesigned process, not an automated one. With a handful of counterparties there is no distribution to learn from, only a set of relationships, and the effective work is renegotiating terms and collections practice. A model fitted to a dozen payers will report the recent past with a confidence interval attached to it.
The forecast would be wired to an irreversible decision - drawing a facility, deferring a payroll run, releasing a payment batch - with nobody reading the output before it acts. A human control point, or a simpler deterministic rule. The forecast can be rerun at any time at no cost, but a facility drawn or a payment released cannot be recalled, so the asymmetry belongs to the decision rather than to the model. Automating the contractually known half and leaving the judgement to a treasurer is both cheaper and the position the audit standard's own procedures assume.
Disputes, credit notes, promises to pay and the reasons an invoice is being withheld live in email threads and in the credit controller's memory, while the receivables ledger records only that an invoice is open. The organisation itself, doing the documentation work first. This is the limitation the published payment-prediction research names directly: the decision-making process is not registered in the accounts receivable system, so the very facts that determine when an invoice is paid are the ones a model never sees. Data scattered across several systems is workable, and the studio works with that routinely. Data that exists only in an inbox is not.

Sources

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.

Automated cash flow forecasting is two problems sharing one name