When a forecast doesn't hold up, the instinct is to adjust the model. It's quick, it feels like problem-solving, and it usually works for a while.
It's also how a planning system quietly stops being trustworthy. Adjusting Adaptive Planning models to compensate for problems in the source data doesn't fix those problems. It encodes them, and it removes the evidence that they were ever there.
That has been a manageable risk for years. It stops being manageable the moment you put AI on top, and for a reason most teams don't see coming.
Why teams do it
Nobody sets out to build a planning model on unreliable data. The decision usually gets made under pressure, late in a deployment, and for reasons that are entirely understandable at the time.
Fixing data in the source system means investigation, root cause analysis, and often re-entry work. Weeks before go-live, that feels like a project restart. Adjusting the model takes an afternoon.
There's also an ownership problem. If the issue sits in the source system, it belongs to someone else. Work around it in Adaptive and ownership becomes muddy, which is more comfortable for everyone in the short term.
And model adjustments are invisible in a way that data corrections aren't. Nobody on the business side sees the workaround. They see forecasts that reconcile.
So the workaround goes in. It works. The project goes live. What happens next is the part worth understanding.
What actually breaks
Forecasts drift from reality. When a model compensates for a data issue, the forecast improves relative to the model's own assumptions and diverges from the business. Actual spend keeps following the real data. The forecast keeps following the adjustment. The gap widens, and because the adjustment isn't visible, it gets harder to explain every cycle.
Variance analysis stops being useful. Planning is iterative: forecast, compare to actuals, find the variance, adjust. If the forecast rests on a workaround rather than reliable data, you can't tell whether you missed the plan because an assumption was wrong or because the model was compensating for something in the data. Every cycle starts with uncertainty nobody has quantified.
The reasoning leaves with the person. This is the one that catches teams out.
Following a Workday Financials deployment and a request to update Adaptive, we found a problem in the cost centre mapping. The structure in Financials had been wrong initially, so during the integration a correction was applied in SQL. Financials was then corrected properly and restructured. The SQL kept following the old logic.
Nothing failed. No error was raised. The mapping had never been documented, and the divergence was only picked up six months later, during a system review and a deep reconciliation of Workday to Adaptive data.
Six months of forecasts had been produced from it. They looked fine.
That particular correction route was specific to how the integration had been built. The pattern isn't. A workaround gets applied because it's the fastest way through, it isn't documented because it's meant to be temporary, and the person who understood it moves on.
What this looks like inside Adaptive
The reason these problems survive for months rather than days is worth understanding, because it's specific to how Adaptive handles data it doesn't recognise.
Adaptive doesn't reject values it can't place. Depending on the hierarchy, unknown values land in an uncategorised bucket. That's the detail that matters: an incomplete hierarchy doesn't produce an obvious error, it produces a plausible number. Totals still tie at the top. Reporting and analysis are affected depending on your system settings, but nothing announces itself.
The workarounds behave the same way. Mapping unidentified cost centres to other levels will solve a short-term reconciliation problem between Financials actuals and Adaptive. Left in place, it distorts variances further down while the summary continues to look correct. Hard-coded values and dimensions sitting inside formulas, where they should be attached to clearly defined assumptions, are no different. They work, and then they stop being visible.
Reconciliation is the control, and in practice it's weaker than most teams assume. In an ideal deployment you wouldn't need it. Because workarounds on cost centre structures exist, the realistic position is that Adaptive output gets reconciled to a Workday Financials report every month. That takes time, and the level you do it at decides whether it's worth doing at all. Reconcile too high and it will tie, which tells you nothing. Wrongly mapped dimensions don't show up in a total. They show up underneath it.
Why AI turns this into an exposure
Here's what changes.
A person reading a variance report works from the top down. Totals first, then the lines that moved. A summary that ties looks like a system that works.
AI doesn't read it that way. Ask it to forecast or run variance analysis and it works at the most granular level available. If a dimension is uncategorised, or a cost centre is mapped to the wrong location, the forecast it produces won't include all the data. It isn't reading the summary that reconciles. It's reading the detail that doesn't.
So the problem inverts. With a traditional model, data issues eventually surface in variance analysis, because a person is looking for them. With an AI model, the same issues sit upstream of a process that has no reason to flag them, and the output looks more sophisticated rather than less.
That matters because of who ends up defending it. The model produces a forecast. Finance presents it. A quarter later it's wrong, the board asks why, and the honest answer is that nobody is certain what the model learned from. The AI didn't fail. The data did. Finance owns the credibility problem either way.
The difference between an AI forecast a CFO can present and one they can't isn't the model. It's whether the answer to "where did this come from?" is a sentence or a shrug.
"It learned from three years of audited transaction data, analysed by cost centre and spend category, and it tracks actuals within the tolerance we've agreed." That's defensible.
"It learned from data we knew had gaps, some of which we corrected in the planning layer, and we're not certain what it picked up." Same model. It can't be defended.
Data integrity first
Adaptive Planning depends on three layers, in this order: reliable source data, clear data governance, and models built on that data rather than compensating for it. Skip the first two and the third will fail eventually.
In practice, that means a few things.
Audit the source system before you configure anything. Are the hierarchies complete? Are cost centre assignments consistent? Do balances reconcile at every level, not just the top? Document the baseline, so that later you can tell whether quality is improving or drifting.
Define ownership while it's still cheap. Who maintains the chart of accounts. When cost centres get created. What validates a new dimension. These questions are trivial before go-live and expensive afterwards.
Decide what an acceptable variance actually is. There's no industry figure here, and anyone offering you one is guessing. What counts as a reasonable gap between actuals and forecast is a judgement for the system owner, and it depends on the business. Make it explicitly, write it down, and reconcile against it.
Reconcile at a level low enough to find something. Monthly, model output to source data, and when there's a variance, investigate it rather than absorbing it. Fix data problems in the source system first, then adjust the model if it still needs adjusting.
If you're adding AI, run that audit before you start, not after the first forecast disappoints. AI amplifies data drift, so validation has to be continuous rather than a one-off exercise at the beginning. And if you find quality issues partway through an AI initiative, stop and fix the data. There's no configuration that makes a model work around it.
Two questions worth asking your team
Can you explain every assumption in your Adaptive Planning model by pointing to reliable data in the source system? If the answer is "not entirely," that's a data problem rather than a planning problem, and no model adjustment will resolve it.
And if you built an AI forecast on your current data today, could you defend it to the board by tracing it back to source? If the answer is "we'd want to clean the data up first," that's the right answer. It's also a much cheaper conversation to have now than after the investment.
Michael Trussell is a Workday Adaptive Planning Architect at VirtualResource, where we work with finance and HR teams on Workday deployments, ongoing Adaptive Planning optimisation, and AI enablement. If you're weighing up either, the conversation usually starts with a look at where the data actually is.