CFO skepticism about AI is both reasonable and, in some specific ways, well-founded. The hype cycle around machine learning in financial planning has produced genuine confusion about what the technology can do today, what it might do in two or three years, and what it will probably never do well regardless of how the models improve.
This matters because the confusion pulls in two directions simultaneously. Some finance teams are dismissing genuinely useful automation because it's been oversold by vendors with inflated claims. Others are deploying tools with unrealistic expectations and then abandoning them when the results fall short of those expectations — concluding that "AI doesn't work in FP&A" when the more accurate conclusion is that it was applied to the wrong problem.
Below are three of the most persistent myths we encounter, along with a more accurate description of what the technology actually does.
Myth 1: AI Will Replace the Forecasting Process
The most common version of this myth is the idea that machine learning models will eventually produce financial forecasts that are more accurate than human-built ones — and that therefore the traditional FP&A forecasting cycle will become obsolete. Some vendor presentations lean into this framing deliberately, positioning AI as a replacement for the planning function rather than a tool within it.
The reality is considerably more nuanced. Machine learning models perform well on forecasting problems that have two characteristics: large volumes of historical data with consistent patterns, and relatively stable underlying causal relationships. Revenue forecasting for a high-volume subscription business with several years of churn data can, in some cases, be approached with statistical models that outperform manual methods on specific metrics. That's a real and meaningful capability.
But most FP&A problems don't fit that profile. Budget planning requires assumptions about strategy, pricing decisions, hiring plans, and market conditions — none of which are well-represented in historical data. A company entering a new product category or geographic market has essentially no historical signal to train a model on. A company going through a merger has structural breaks in its data that make historical patterns unreliable. In all of these cases, human judgment isn't a fallback when the AI fails — it's the primary tool.
We're not saying statistical forecasting methods have no role in FP&A. Time-series models for demand forecasting, anomaly detection in expense streams, and pattern recognition in accounts receivable ageing are all legitimate applications. We're saying they're tools within the planning process, not replacements for it.
Myth 2: AI in Finance Requires a Data Warehouse and a Data Team
This myth has historically been accurate. Early machine learning applications in finance genuinely did require significant data infrastructure investment — clean, structured data repositories, data engineering pipelines, model training environments, and a team capable of maintaining them. For large enterprises with appropriate IT budgets, this made sense. For mid-market finance teams of three to eight people, it placed AI-assisted forecasting permanently out of reach.
What's changed is where the intelligence sits. Modern financial control tools embed pattern recognition and anomaly detection directly into the data pipeline between your ERP and your reporting layer. The "AI" in this context is closer to a sophisticated set of categorisation rules and anomaly thresholds that are applied automatically as transactions flow through — not a separate model that requires a data scientist to maintain.
Consider the practical case: a finance team at a manufacturing business with roughly 150 employees and a Fortnox or Visma ERP. Their accounts payable has 40 to 60 active suppliers. A rules-based classification system — one that learns from historical payment patterns and flags transactions that deviate from established norms — can categorise expenses, surface anomalies, and highlight cash flow deviations without requiring any data infrastructure beyond the ERP integration itself.
This is genuinely different from the enterprise-grade ML deployment that the "you need a data warehouse" myth assumes. It's also less impressive in a demo than a full forecasting model — which is partly why the myth persists. The tools that actually get used by mid-market finance teams are less glamorous and more useful than the ones that get featured in vendor presentations.
Myth 3: If the AI Is Confident, the Number Must Be Right
This myth is the most operationally dangerous. It surfaces when teams start treating AI-generated forecasts or categorisations as outputs to be reported rather than inputs to be reviewed. The tell is when a financial controller presents an AI-generated cash forecast to a CFO without a clear articulation of what assumptions drove the model and which line items were manually reviewed versus algorithmically produced.
Machine learning models produce outputs that look like numbers, and numbers in financial contexts carry implied precision. A forecast that says "projected cash position in 60 days: SEK 4.3M" reads the same way whether it was produced by a carefully validated model or a model that has been silently trained on stale data with a broken input.
Two failure modes are worth being explicit about. First, distribution shift: the model was trained on a period of business normality and is now making projections during a period of structural change — a new payment terms agreement with a major customer, a shift in revenue mix, a change in supplier payment timing. The model doesn't know what it doesn't know; it will produce confident-looking output from the wrong historical baseline.
Second, categorisation drift: expense categorisation models can quietly start miscategorising as the business evolves. If R&D spend starts being categorised as Cost of Goods Sold, the gross margin numbers that flow from the forecast are wrong — but the model has no mechanism to surface this unless someone checks the underlying categories periodically.
The discipline required is the same as with any other forecasting tool: define what the model is responsible for, define what it is not responsible for, and build a review process that catches errors before they propagate into board-level reporting.
What AI in FP&A Actually Does Well — And Where the Boundary Is
After clearing away the myths, it's worth being specific about genuine capability. The applications where machine learning approaches deliver consistent practical value in mid-market financial planning are:
- Automated transaction categorisation. Classifying expenses to the right accounts and cost centres based on vendor name, amount, and description — reducing manual coding and the error rate that comes with it.
- Anomaly detection in cost streams. Flagging vendor payments that deviate from established patterns (unexpected amount, unexpected frequency, new counterparty). This is useful for both cost control and fraud prevention.
- Cash flow pattern recognition. Identifying seasonal patterns in receivables collection and payment timing that a manual model might miss, and surfacing those patterns explicitly in the forecast.
- Variance explanation. Attributing budget-vs-actual variances to specific transaction categories or time periods, reducing the time a finance team spends manually tracing where a number came from.
The boundary — what these tools should not be expected to do — is equally important. They don't replace the judgment required to set targets, decide on assumptions, or evaluate whether a strategic initiative's financial projections are credible. They don't know your business is about to restructure a division, acquire a competitor, or lose its largest customer. Every place where human context, strategy, or judgment is the primary input, the model is a support tool, not the answer.
The finance leaders who get the most value from these capabilities are the ones who've been clear-eyed about that boundary from the start — treating the tools as very good analysts who are fast and consistent but need supervision, rather than as oracles who are correct by default.