Every product claims both capabilities and very few mean the same thing by them. The five categories of tool, the nine criteria that genuinely separate them, and how to test a vendor on your own model.
Choosing the best FP&A software for scenario planning and what-if analysis is harder than it looks, because almost every product in the category claims both capabilities and very few mean the same thing by them. One vendor means you can save three named versions of the budget and flip between them. Another means a user can change a growth rate and watch the model recalculate. A third means the tool will sample thousands of combinations of uncertain inputs and hand back a distribution with the odds attached. Those are not three flavours of one feature. They are three different answers to the question a finance team is actually asking, and only one of them tells you how likely your plan is to happen.
This guide is written for the person running that evaluation: a CFO, a head of FP&A, a finance director, or the analyst who has been handed a shortlist and a deadline. It sits underneath our broader guide to what-if analysis software, which covers the mechanics of deterministic and probabilistic what-if analysis in general. Here the scope is narrower and more practical: what an FP&A team specifically needs, how the categories of tool differ in ways the marketing pages obscure, the criteria that genuinely separate products, how to script a demo that cannot be gamed, and what the published evidence says about where finance planning actually breaks down today.
The argument throughout is simple. The binding constraint in most finance functions is not modelling horsepower and it is not consolidation speed. It is that the plan leaving the building is a single number with no stated confidence, produced by a process too slow to re-run when the world moves. Fixing that requires a specific set of capabilities, and a product can be excellent at everything else and still not have them. Knowing which problem you are buying for is most of the work, and it is work you have to do before the first demo rather than after the third.
Before comparing products it is worth being precise about the jobs involved, because buyers routinely conflate three of them and then wonder why the tool they bought did not solve the problem they had. The three jobs are related, they are often sold together, and they are nonetheless distinct enough that strength in one predicts nothing about strength in the others.
The first job is consolidation. Six regions, four product lines and three cost centres each submit a plan, the submissions arrive in incompatible formats with different assumptions baked in, and somebody has to assemble them into a single coherent view that ties to the ledger. This is the historic reason enterprise performance management platforms exist, and it is a genuine problem with a genuine answer: a governed dimensional data model, a submission workflow, and a reporting layer that everyone reads the same way.
Consolidation is also the job that most reliably justifies a large software purchase, because the pain is visible, measurable and recurring. If the monthly close and the budget cycle are consuming weeks of analyst time in reconciliation, a platform that collapses that work pays for itself in a currency the CFO already tracks. The important thing to notice is that solving consolidation does nothing whatsoever about the confidence of the resulting plan. A number assembled quickly and accurately from six regions is still a number.
The second job is modelling: expressing how the business actually works as a set of drivers and relationships, so that revenue is not a growth rate applied to last year but the output of capacity, conversion, price and retention interacting. This is what people mean when they talk about driver-based planning, and it is the prerequisite for any serious what-if analysis, because a what-if question is only interesting if the model propagates the change through to something you care about.
Modelling quality is mostly a function of the team rather than the tool, which is an uncomfortable thing for a buyer to hear. A good analyst builds a defensible driver model in a spreadsheet; a weak driver tree stays weak after migration to a platform costing six figures a year. What software changes is the durability of the model: whether it survives the analyst leaving, whether two people can work on it at once, and whether anyone can see what changed between versions. Those are real benefits and they are not the same as the model being right.
The third job is the one this guide is about, and it is the one most often missing. Given a model and a set of assumptions you are not sure about, produce the range of outcomes those assumptions imply, the probability of hitting the committed number, and a ranking of which assumption is driving the spread. This is what separates probabilistic what-if analysis from the deterministic kind, and it is a genuinely different capability rather than a presentational one.
The distinction matters commercially because the first two jobs are mature, competitive and well served, while the third is patchily served and frequently misrepresented. A product can consolidate beautifully, support a rich driver model, let a user change any input and recalculate instantly, and still be incapable of telling you the probability that the plan succeeds. If that is what you need, no amount of excellence in the other two jobs substitutes, and the demo will not reveal the gap unless you ask for it directly.
The naming in this market is unusually unhelpful. FP&A software, EPM, CPM, xP&A, business planning, integrated planning and connected planning are used by vendors and analysts to mean overlapping and shifting things, and the labels track marketing positioning more closely than they track architecture. A product named for financial planning may be a consolidation engine with a scenario screen; a product named for risk may be a simulation engine with no planning workflow at all.
The only reliable way through this is to ignore the label and ask what the product is fundamentally organised around. Is the central object a governed dimensional model, a spreadsheet, a simulation, or a decision? Everything else follows from that answer, because the organising object determines what the product makes easy, what it makes possible but awkward, and what it will never do well no matter how many releases ship. We return to this in the section on tool categories below, and the same framing is developed at more length in our guide to scenario analysis software.
It is worth grounding the buying decision in published data rather than vendor narrative, because the data is specific about where finance planning is actually slow and actually weak. Two bodies of survey work are particularly useful here: the Association for Financial Professionals, which benchmarks planning practice across corporate finance teams, and the FP&A Trends Group, which has run a comparable survey annually for the better part of a decade. The picture they produce is consistent and not especially flattering.
The headline finding is that structured scenario planning, meaning a repeatable process rather than an occasional exercise, is practised by well under half of finance functions. The Association for Financial Professionals surveyed 332 corporate finance practitioners in August and September 2025 for its 2026 benchmarking report, and found that while nearly everyone maintains a list of risks and opportunities, far fewer have turned that list into a structured scenario process.
38% - of organisations use structured scenario planning, even though 90% maintain a list of risks and opportunities and 89% do some form of contingency planning. The gap between keeping a risk list and running structured scenarios is the gap most buyers are trying to close.
Source: Association for Financial Professionals, 2026 AFP FP&A Benchmarking Survey
That gap is the interesting part. Almost every finance team can name the things that could go wrong. Far fewer have a process that quantifies what those things would do to the plan, and fewer still re-run it when the inputs change. The risk register exists, it is reviewed, and it has no mathematical connection to the forecast sitting next to it in the board pack. Closing that connection is precisely what good scenario and what-if tooling is for, and it is why a risk list is not evidence that the problem is solved.
The common objection to structured scenario work is that it adds time to a budget cycle that is already too long. The benchmarking data points the other way. The same AFP survey found that organisations practising structured scenario planning completed budget development in an average of 8.1 weeks against 9.2 weeks for those that did not, roughly 11% faster, with the overall average sitting at 8.7 weeks and essentially unchanged from three years earlier.
8.1 vs 9.2 weeks - average budget development time for organisations that practise structured scenario planning against those that do not, about 11% faster. Structured scenario planners also reported 14% higher strategic alignment and 13% higher integration of external factors.
Source: Association for Financial Professionals, 2026 AFP FP&A Benchmarking Survey
The causation is worth thinking about rather than asserting, and the plausible mechanism is that structure removes argument. A team with agreed planning variables and a defined scenario process spends less of the cycle debating which version of the assumptions to use, because that was settled in advance. A team without it rediscovers the debate every submission. The survey is consistent with that reading: structured scenario planners also reported materially better horizontal alignment across the business, which is to say fewer incompatible versions of the truth to reconcile.
Speed is where the evidence is most damning, and it is the number to hold in mind during a software evaluation. The 2025 FP&A Trends Survey found that only 18% of organisations can produce a scenario in under a day, a third need about a week, and the remaining half take longer still or cannot run scenarios at all. A planning capability that takes a week to answer a question is not available during the conversation in which the question is asked.
Only 18% - of organisations can run a planning scenario in under one day; 33% need about a week, and the remaining 49% take longer or cannot run scenarios at all. On the same survey, 69% of FP&A effort was still consumed by manual data gathering, reconciliation and reporting.
This is the single most useful number for framing a purchase, because it converts an abstract benefit into a test. If a tool cannot take a question from an executive and return a defensible answer the same day, it has not addressed the constraint that half the market is stuck behind. Time to answer therefore belongs in the evaluation criteria as a first-class requirement rather than a nice-to-have, and we treat it that way in the scorecard below.
The same survey work found that only 17% of organisations use fully driver-based models, with a further 40% using partial ones, and that model sophistication tracks self-assessed forecast quality closely: 77% of those using dynamic or fully driver-based models rated their internal forecasts as good or great. Meanwhile 29% of organisations needed more than ten days to produce a forecast at all, and only 15% could do it in under two.
17% and 77% - only 17% of organisations use fully driver-based models, and 77% of those using dynamic or fully driver-based models rate their internal forecasts as good or great. On the same survey only 11% had fully aligned strategic, financial and operational planning.
There is an obvious selection effect in a self-assessment, and it should be read with that in mind. The more defensible reading is not that driver models cause good forecasts but that the two travel together, probably because both reflect a team that has done the work of understanding how the business converts activity into money. Either way the practical implication for a buyer is the same: the driver model is the asset, the software is the container, and buying the container before building the asset is the most common sequencing mistake in this category.
Put the findings side by side and a coherent picture emerges. Most finance teams know what their risks are, cannot quantify them against the plan, take about two months to build a budget, cannot re-run it quickly when the world changes, and spend most of their effort moving data rather than interpreting it. The constraint is not analytical ambition. It is cycle time, repeatability and the absence of any stated confidence around the output.
That diagnosis should shape the shortlist. A tool that makes the modelling deeper without making the cycle faster addresses the wrong half of the problem. A tool that makes consolidation faster without attaching confidence to the output addresses the other wrong half. The products worth serious evaluation are the ones that shorten the loop from question to defensible probabilistic answer, and that is a narrower set than the category listing suggests. Our guide to the limits of spreadsheet forecasting covers why the default tool struggles with exactly this loop.
Nearly every FP&A product on the market supports deterministic what-if analysis, and it is genuinely useful, so it is worth being clear about what it does well before explaining where it fails. The mechanics are familiar to anyone who has used a spreadsheet: change an input, recalculate, read the new output. Name the input sets and you have scenarios. Solve backwards for the input that produces a target output and you have goal seek. Vary one or two inputs across a grid and you have a data table.
Named cases are excellent communication devices. A base, upside and downside case gives a board three coherent stories about the future, each internally consistent, each explicable in a sentence. That is a real virtue, and no probabilistic output replaces it, because a distribution is harder to narrate than a story about what happens if the big contract lands. Keep the named cases in the deck; the argument here is about what else needs to be there.
Deterministic what-if is also the right tool for a genuinely binary question. If the business either acquires the competitor or does not, two fully worked models are more informative than a probability distribution over a blend of the two, because the blend describes a world that cannot happen. Discrete structural choices want discrete models. The failure mode is applying the same approach to continuous uncertainty, which is most of what a finance plan contains.
The first and most serious limitation is coverage. A plan with a dozen uncertain inputs has an enormous space of possible combinations, and three named cases sample three points from it. Worse, they sample three points chosen for narrative tidiness rather than for likelihood: the downside case is usually constructed by moving several inputs to their pessimistic values at once, which is a specific and often improbable combination rather than a representative bad outcome.
This produces a characteristic distortion. The named downside is simultaneously too pessimistic as a description of how things usually go wrong and not pessimistic enough as a description of how badly they can go, because the genuinely bad outcomes come from combinations nobody thought to name. The plan then carries a false sense of having been stress tested. Sampling the space properly is what a simulation does, and it is the whole of the difference between the two approaches.
The second limitation is that a deterministic scenario contains no information about how likely its inputs are. If the upside case assumes churn falls to a level the business has never achieved and the downside assumes a price increase that competitors would match within a quarter, both appear with equal standing in the deck. The reader has no way to know that one is a stretch and the other is routine, because the format has nowhere to put that information.
Ranges fix this, and the fix is not cosmetic. Stating that net revenue retention is somewhere between 96% and 112% with the middle of the range around 104% carries far more information than picking 104% and calling it the plan, or picking 96% and calling it conservative. Once every uncertain input is expressed that way, the combination arithmetic can be done by machine, and the output inherits the weights. This is the move described in detail in our guide to three-point estimation.
The third limitation is correlation, and it is the one that causes real damage in finance models. Inputs in a business plan are not independent. A demand shock suppresses new bookings and raises churn and compresses pricing at the same time; a labour market shortage raises salary cost and slows the sales capacity ramp together. A named downside case usually captures some of this by construction, because whoever built it moved the related inputs together by intuition.
What is lost is any systematic treatment. Intuition applied to three or four inputs does not scale to twenty, and the pattern of which things move together is exactly the thing that determines how fat the bad tail is. A tool that samples inputs independently will understate the probability of the compound bad outcome, sometimes severely, which is why correlation handling appears as an explicit evaluation criterion later in this guide rather than being left to the vendor to mention.
The deepest difference is not technical. A deterministic what-if answers the question "what would the number be if this were true." A probabilistic what-if answers "how likely is the number we have committed to, and what is most responsible for the risk." The second question is the one an executive actually has, and the first is a proxy that survives mainly because the tooling made it the easy question to ask for three decades.
That reframing is worth carrying into the evaluation, because it is a sharp test. Ask a vendor to answer the second question live, on your model, with your assumptions. Products built around probability will do it in minutes. Products that have added a scenario screen to a deterministic engine will answer a different question confidently and hope nobody notices the substitution. The fuller treatment of this distinction sits in the pillar guide to what-if analysis software.
There is a finding in the academic literature that every FP&A buyer should know before evaluating tools, because it determines how much of the value is in the software and how much is in the process around it. It concerns how good senior financial executives are at stating ranges, and the answer is that they are systematically and substantially overconfident.
Between June 2001 and March 2011, Duke University ran forty quarterly surveys of US chief financial officers, asking each to forecast market returns and to state an 80% confidence interval around the forecast. Ben-David, Graham and Harvey analysed the resulting panel of more than 13,300 forecast distributions and published the result in the Quarterly Journal of Economics. Realised returns fell inside those 80% intervals only 36% of the time.
36% - of realised market returns fell inside the 80% confidence intervals stated by CFOs, across more than 13,300 forecast distributions collected over a decade. The authors describe executives as severely miscalibrated, producing distributions that are far too narrow, with miscalibration worst during periods of high uncertainty.
Source: Ben-David, Graham and Harvey, Managerial Miscalibration, Quarterly Journal of Economics 128(4)
Two details of that study matter more than the headline. The first is that the miscalibration was worst precisely when uncertainty was highest, which is when the ranges matter most and when a planning process is most likely to be asked for one. The second is that the authors found the same executives who were miscalibrated about markets were similarly miscalibrated about their own firms, and that firms with miscalibrated executives invested more aggressively and carried more debt. The bias does not stay in the forecast; it reaches the balance sheet.
A simulation is only as good as the ranges fed into it, so a tool that accepts ranges from a single overconfident estimator will produce a confident-looking distribution that is too narrow in exactly the way the point estimate was. Buying probabilistic software does not immunise anyone against this. What it does is make the error visible and correctable, which the single-number process never did, and that is a real advance even though it falls short of a cure.
The practical consequence is that some of the features that look like secondary considerations in a product comparison are in fact load bearing. Whether a tool makes it easy to collect ranges from multiple contributors rather than one analyst matters, because an aggregate of several people is usually wider and better than any individual estimate. Whether the tool keeps a record of stated probabilities against outcomes matters, because that record is the only way a team discovers its own bias. And whether the tool nudges toward a reference class of comparable past cases matters, because the outside view is the most reliable antidote known.
The cheapest corrective is to stop asking one person for the range. Ask three people who own different parts of the driver, collect their low and high values separately, and use the envelope rather than the average. This feels wasteful and almost always produces a wider and more accurate range, because individual overconfidence is not perfectly correlated across people and the disagreement itself is information about where the real uncertainty lives.
The second habit is to anchor on history before anchoring on ambition. If the question is the plausible range for new logo conversion next year, start with the distribution of what it has actually been for the last eight quarters, then argue about why next year should differ. This is the outside view, formalised in the practice our guide to reference class forecasting describes, and it is the single most effective debiasing technique with a solid evidence base behind it.
The third habit is to state the low and high as genuine bounds rather than as a polite spread around the plan. A useful prompt is to ask what would have to be true for the outcome to fall below the stated low, and to keep widening until the answer stops being a scenario someone can describe in one sentence. If the bottom of your range is a world you can casually imagine, it is not the bottom of your range. Our discussion of optimism bias in business goes further into why these corrections are necessary at all.
Turn the above into demo questions. How does the product collect a range from more than one contributor, and does it keep their individual inputs or only the blend? Does it surface the width of an input range next to the history of that metric, so an implausibly narrow range is visible on screen? Does it record what was forecast and what happened, and is that record per person or only per model? None of these are exotic requirements, and the pattern of which vendors have thought about them is informative.
A vendor who treats these as process questions outside the tool is not necessarily wrong, but they are telling you something about where the product boundary sits, and you will have to build that process yourself. A vendor who has built for them has thought about the failure mode that the research identifies as the dominant one, which is a reasonable proxy for having thought seriously about the rest.
The products a finance team will encounter fall into five groups once you organise them by what they are built around rather than how they are marketed. Each group has a natural buyer, a set of things it does better than anything else, and a set of things it will always be awkward at. Matching your binding constraint to the right group eliminates most of a shortlist before any demo happens.
The spreadsheet remains where most financial models are born, and simulation add-ins extend it rather than replacing it. You keep the workbook, mark certain cells as distributions rather than values, and the add-in runs the model thousands of times and collects the outputs. The appeal is immediate: no migration, no new modelling language, and the full expressive power of a tool the whole team already knows.
The limitations are inherited rather than introduced. The model is still a spreadsheet, with the fragility, the hidden hard-coded cells and the inspection difficulty that implies. Governance is whatever your file sharing provides, which in most organisations is close to nothing, and the simulation is only as reviewable as the workbook underneath it. Add-ins suit a strong analyst working on a bounded, well understood model who needs probabilistic output without changing anything else about the process. They suit a finance function trying to make probability a standard part of planning much less well, because the capability stays with the person who owns the file.
Enterprise performance management platforms are built around the planning process: a governed dimensional data model, submission workflow, driver-based planning, consolidation, and a reporting layer. Scenario capability is usually present and usually deterministic, offering named versions of a plan that can be held side by side and compared. For a multi-entity business with a genuine consolidation problem, this category is the right answer and nothing else comes close.
The caution is that they solve a different problem from the one this guide is about, and the overlap in vocabulary hides it. If six regions submit budgets in incompatible spreadsheets and consolidation takes three weeks, a platform fixes that and a simulation tool does not. If the consolidated plan is a single number with no stated confidence, the platform may consolidate it faster without touching the underlying issue. Many organisations genuinely need both, and the mistake is assuming the first purchase covered the second. Our comparisons with Anaplan, Pigment and Workday Adaptive Planning set out that boundary in more detail.
A large group of products target the finance team that has outgrown spreadsheets but will never run a full enterprise platform: fast implementation, prebuilt connectors to the general ledger and the CRM, templated driver models, and reporting that looks good in a board pack. These are often the best value in the market for a company between roughly fifty and a thousand employees, because they remove the data wrangling that the survey evidence says consumes most FP&A effort.
Their scenario capability varies enormously and is the thing to probe hardest. Some offer genuine variant comparison; many offer a saved set of input overrides with a nice interface. Almost none offer simulation. If the primary need is to stop spending two weeks a month assembling actuals, this category delivers it. If the primary need is to attach a probability to the annual plan, check carefully rather than assuming, because the marketing language in this segment is the least precise in the market.
These are built around simulation as the primary object: distribution families, correlation structures, convergence diagnostics, sensitivity decomposition and tail statistics as first-class features. They are the most capable option for genuinely quantitative work and are standard in insurance, energy, mining and large capital programmes, where the analysis has to survive a regulator or a lender looking at it closely.
Their cost is specialist assumption. They expect a user comfortable choosing a distribution family, reasoning about convergence and interpreting variance decomposition, and in a finance function without that background they tend to end up operated by one person and trusted by nobody else. Capability concentrated in a single individual is a fragile asset, and it is worth asking during the evaluation who the second user would be. Our guide to Monte Carlo simulation software covers this category in depth, including how to judge whether your team has the background to run it.
A smaller category organised around the decision rather than the model. The central object is a choice between options, the output is a recommendation with a probability and a ranked set of drivers, and the design priorities are time to first answer and explainability rather than modelling depth. These suit organisations where the binding constraint is that rigorous analysis is not happening at all, rather than that it is happening imprecisely.
The trade-off is honest and worth stating plainly: a tool optimised for a decision will not replace a full planning model, and pretending otherwise disappoints everyone. Incertive sits in this category deliberately, which is why the platform is organised around comparing plan variants and producing a success probability rather than around building a general-purpose dimensional model. If your problem is consolidation, buy a platform; if your problem is that commitments are being made on single-point estimates and nobody has time to change that, this is the category to look at.
Name your binding constraint in one sentence before looking at any product, and write it down so it cannot drift during the evaluation. If the constraint is consolidation and process, buy planning software. If it is that quantitative risk work has to be deep and defensible to an outside party, buy a dedicated risk tool. If it is that an excellent analyst needs simulation on a model that already works, an add-in is the cheapest good answer. If it is that decisions are being made on single numbers and the cycle is too slow to change that, buy for time to answer and explainability.
The characteristic failure is buying the most capable tool available and discovering that capability was never the constraint. Adoption almost always is. A tool that produces a defensible answer in an afternoon changes more decisions than one that produces a superb answer in a fortnight, and the difference compounds, because the fast tool gets used on the small decisions where most of the value quietly accumulates.
Feature matrices in this category are nearly useless, because every product ticks scenario planning and what-if analysis and the words do not constrain the implementation. What follows is a set of criteria chosen precisely because products differ on them, each stated as something you can verify in a demo rather than read off a datasheet.
The first and most discriminating question is whether an assumption can be entered as a range rather than a value. Not a scenario where you type a different value, and not a sensitivity grid where the tool steps through values you specify, but a native representation of an uncertain quantity with a low, a high and a shape. If the data model has nowhere to put uncertainty, everything downstream is deterministic regardless of what the screen is called.
Verify it by asking to enter a three-point estimate on a driver during the demo and then asking what the tool does with it. A product built for this will ask about the shape of the distribution or choose a sensible default and tell you which. A product that is not will convert your range into three saved scenarios, which is the substitution to watch for and the most common one in the market.
Given range inputs, the next question is whether the tool knows that some of them move together. Independent sampling of correlated drivers understates the probability of the compound bad outcome, which is the outcome that actually hurts, and in a finance model the correlations are strong: demand, pricing, churn and collections all respond to the same macro conditions.
There are several legitimate implementations, from an explicit correlation matrix to shared common drivers to scenario-conditioned sampling, and any of them is better than none. What you are listening for is whether the vendor understands the question. An answer along the lines of correlation being handled by the user building the relationship into the model is acceptable and tells you where the work falls; a blank look tells you the tool will produce a tail that is too thin and will not warn you.
A probability without a driver ranking is half an answer. Knowing the plan has a 62% chance of being met is useful; knowing that most of the spread comes from net revenue retention and almost none from hosting cost is what tells an FP&A team where to spend the next week. This is sensitivity analysis, usually presented as a tornado chart, and it is the output that most reliably changes behaviour.
Ask how the ranking is computed and whether it accounts for the width of each input range as well as the slope of the response. A driver with enormous leverage and almost no uncertainty does not belong at the top of the list, and a ranking that puts it there is ranking the wrong thing. Our explainer on sensitivity analysis covers the distinction, and the tornado diagram page shows what the output looks like in practice.
Scenario planning in the useful sense means comparing structurally different plans, not the same plan with different numbers. A phased rollout against a full launch. Hiring ahead of revenue against hiring behind it. Two acquisition structures. These differ in their logic rather than their inputs, and comparing them requires the tool to hold more than one model and show the distributions side by side.
Many products can do this with enough effort by duplicating the model and maintaining both, which is a maintenance liability rather than a feature. What you want is first-class support: define the variants, run them, compare the probability of success and the driver rankings in one view. Ask to see three structurally different plans compared on one screen and watch how much work it takes.
Given the survey evidence that half of finance functions take longer than a week to produce a scenario, this criterion deserves to be weighted heavily. The measure is not how long a simulation takes to compute, which is almost always trivial on modern hardware, but how long it takes to get from a question asked in a meeting to an answer that will survive being challenged.
Test it directly. Bring a real question that has not been pre-built into the demo environment, and ask the vendor to answer it live. The spread between products on this measure is enormous and almost never visible in a scripted demonstration, which is why the unscripted version is worth insisting on even when it makes the sales team uncomfortable.
A probabilistic result that cannot be reproduced is not evidence. Six months after a decision, somebody will ask what the model said and what it assumed, and the answer has to be retrievable without reconstruction. That requires the tool to store the inputs, the model version and the result together, and to be able to show the same analysis again rather than a fresh run on different data.
This is also where simulation introduces a wrinkle a buyer should ask about, because a random process produces slightly different numbers each time it runs. A product designed for governed use will either fix the random sequence or run enough iterations that the result is stable to the precision you report, and it will be able to explain which. Vagueness here predicts awkward conversations with auditors later.
This criterion is routinely ignored and predicts long-term value better than any other, because it is the only one that forces the method to prove itself. Does the tool record what was forecast, at what confidence, against what success criterion, and what eventually happened? Without that record, nobody can tell whether the probabilities mean anything, and the whole approach rests on an assumption rather than evidence.
Incertive does this through calibration tracking, which compares the probability estimates a person has made against the outcomes they recorded and reports how well the two have lined up. It is worth being precise about the scope: the score describes a person’s own forecasting record, it is not aggregated into a team view, and recorded outcomes do not feed back into anybody’s future analyses. What it gives you is a measured answer to the question of whether your eighty percents have behaved like eighty percents, which is exactly the question the miscalibration research says you cannot answer by intuition.
If the survey evidence is right that most FP&A effort goes on gathering and reconciling data, then integration is where a lot of the measurable return sits. The questions are concrete: which systems does it connect to natively, how does the mapping get maintained when the chart of accounts changes, and what happens to the model when a dimension is added.
Be realistic about the ceiling, though. Integration removes manual assembly; it does not make the data good. A connector that pulls a badly structured ledger faster produces a faster bad forecast, and the survey finding that only a small minority of organisations rate their data quality as good suggests this is the common case rather than the exception. Integration is necessary and insufficient, and a vendor who says so is more credible than one who does not.
The last criterion is the one that determines whether anything changes. The output has to be comprehensible to a chief executive, a board member or a divisional head who will not open the model, and it has to remain comprehensible when they challenge it. That means the probability has to be traceable to the assumptions that produced it, in a view somebody can read in a meeting.
Test it with the hardest realistic question: ask the vendor to show you why the probability is what it is, and keep asking why until you reach the inputs. A product designed for decision support walks that path cleanly. A product designed for modellers will eventually answer with a screen full of statistics, which is a correct answer that will not survive a board meeting. How it works and the methodology page show the path we expose for this.
The evaluation process matters almost as much as the criteria, because a software demonstration is a performance and the vendor has had more practice at it than you have. The defence is to fix the weights before you see anything and to bring your own material, so that the comparison is on your problem rather than on the vendor’s best case.
Take the nine criteria above, decide which three matter most for your binding constraint, and assign weights that sum to one hundred before any vendor speaks. Write the weights in a document and circulate it. This feels bureaucratic and it is the single highest-return step in the process, because it prevents the most common failure in software selection: the weights drifting toward whatever the most impressive demo happened to emphasise.
Expect the weights to look lopsided and let them. A mid-market team drowning in manual data assembly might put forty points on integration and ten on correlation handling. A team that already has clean data and a good driver model might reverse it entirely. There is no universal weighting, and a scorecard where every criterion gets eleven points is a scorecard that has not made a decision about what the organisation needs.
Prepare two artefacts for every demo. The first is a simplified version of your real driver model, with perhaps eight to twelve drivers, enough to be recognisable and small enough to be rebuilt in an hour. The second is a question nobody has seen, phrased the way an executive would phrase it: what are the odds we hit the revenue number if the enterprise segment ramps a quarter later than planned.
Then ask the vendor to answer it live in their product. This is the test that separates the field, and the responses are informative even when they are refusals. A vendor who does it in twenty minutes has a product built for the question. A vendor who needs a week of configuration has told you what your own time to answer will look like. A vendor who answers a slightly different question and moves on quickly has told you the most useful thing of all.
If the evaluation gets as far as a trial, design it around the things you expect to break rather than the things you expect to work. Change the chart of accounts mid-trial and see what happens to the model. Add a driver that was not in the original design. Ask two people to edit the same plan at once. Hand the tool to somebody who was not in any of the demos and see whether they can produce an answer unaided.
The last of those is the real test and it is often skipped out of politeness toward the vendor and the internal champion. A product that only works in the hands of the person who ran the trial is a product that will be used for the length of that person’s tenure. Insist on the cold test, with a specific named person who has not been trained, and take the result seriously even when it is disappointing.
Vendor-supplied references are selected, so the questions have to be chosen to get past the selection. Avoid asking whether they are happy. Ask how long the implementation actually took against what was quoted, how many people use it today compared with the number licensed, what they tried to do that the product could not do, and what they would model differently if they started again.
The highest-value question is about a decision. Ask the reference to describe a specific decision where the tool changed the outcome, with enough detail to be real. An enthusiastic customer who cannot produce one is describing a reporting improvement rather than a decision improvement, and that distinction is exactly the one you are trying to make. If several references cannot produce one, that is the product’s answer about where its value sits.
Score each product against the pre-agreed weights immediately after its demo rather than at the end of the process, because memory flatters whoever presented last. Then do one final check that has nothing to do with the arithmetic: ask whether the winning product solves the sentence you wrote down as your binding constraint. If the scorecard picked something that does not, the weights were wrong and it is worth finding out why before signing.
It is also worth deliberately pricing the option of doing nothing new, or of solving the problem with process rather than purchase. Some of the gains described in this guide are available by changing how ranges are collected and how plans are presented, with no software at all. A tool that cannot beat a disciplined process by a clear margin is not worth the implementation risk, and knowing where that bar sits makes every subsequent negotiation easier.
Everything in this guide assumes a model that connects assumptions to outcomes. If revenue in your plan is last year multiplied by a growth rate, there is nothing for a what-if question to propagate through, and a simulation of that model would tell you only that an uncertain growth rate produces an uncertain revenue. Driver-based planning is the work that makes the rest possible, and the survey evidence says most organisations have not finished it.
A driver model expresses an outcome as the arithmetic of the things that produce it. Instead of a revenue growth rate, you have sales capacity times productivity times win rate times average deal size, plus the existing base times net revenue retention. Instead of a headcount cost line, you have headcount by role times fully loaded cost by role, phased by start date. Each term is something an owner in the business recognises and can argue about from evidence.
The advantage over a growth-rate plan is not precision but diagnosis. When a growth-rate plan misses, the only available explanation is that growth was lower than expected, which is a restatement rather than an explanation. When a driver plan misses, the variance decomposes: capacity arrived on time but conversion was below range and deal size held. That tells you what to fix, and it tells you which range was wrong, which is how the estimates improve over time.
The common error is building a driver tree that is too detailed, on the theory that more granularity is more accurate. It usually is not, because every additional driver needs a range, an owner and a maintenance commitment, and a tree with two hundred leaves gets maintained by nobody. The useful discipline is to find the smallest set of drivers that explains most of the variance, which is a question sensitivity analysis answers directly.
A practical route is to start deliberately coarse, with perhaps ten to fifteen drivers, run the sensitivity ranking, and only then add detail beneath the two or three drivers that dominate the spread. This inverts the usual sequence and produces a much smaller model that performs better, because the detail sits where it changes the answer rather than being spread evenly for the sake of symmetry. Where a driver turns out to be irrelevant to the outcome, the correct response is to stop modelling it.
Every driver needs a named owner in the business, not in finance. The head of sales owns conversion and capacity ramp, the head of customer success owns retention, the head of engineering owns infrastructure unit cost. Finance owns the arithmetic that connects them and the discipline of asking for ranges rather than numbers, and that division of labour is what makes the plan defensible when it is challenged.
This also changes the politics of a missed plan in a way that is worth engineering for deliberately. When a driver has an owner and a stated range, a miss is a conversation about whether the outcome fell outside the range and why, rather than an argument about whether finance was too pessimistic. The range is a commitment to a belief about the world rather than to a number, which turns out to be a far more productive thing to hold people to.
Tooling helps with durability, collaboration and version history. It does not help with the structure of the tree, which requires somebody who understands the business to sit down and work out how it converts activity into money. Vendors sometimes offer templated driver models by industry, and those are a reasonable starting point as long as they are treated as a prompt rather than an answer, because the thing that makes your business different is usually in the structure rather than the parameters.
The sequencing advice follows from this. Build or substantially improve the driver model before the software decision rather than after it, even if the interim version lives in a spreadsheet. A team that arrives at an evaluation with a working driver tree can test products against something real, will recognise which products force an unnatural structure on it, and will implement far faster when the choice is made. A team that intends to design the model during implementation has combined two hard problems into one.
Scenario capability is only valuable if the planning calendar lets you use it. A team that re-plans once a year has limited use for a tool that can answer in a day, and a team committed to a monthly re-forecast will be constrained by any tool that takes a week. Cadence and tooling have to be designed together, and the AFP benchmarking data suggests the cadence question is unresolved in most finance functions.
Rolling forecasts have been recommended by nearly every commentator on financial planning for two decades, and the AFP benchmarking survey found adoption at 43% of organisations. That is substantial and it is also well short of universal, after twenty years of advocacy, which should prompt some curiosity about why.
43% - of organisations use rolling forecasts, and average budget development time across all respondents was 8.7 weeks, essentially unchanged from three years earlier. Cadence ambitions have outpaced cycle-time improvement.
Source: Association for Financial Professionals, 2026 AFP FP&A Benchmarking Survey
The usual reason is arithmetic. If a full forecast takes most of a month to produce, a monthly rolling forecast consumes the finance function entirely and leaves no capacity for analysis, which defeats the purpose. Rolling cadence requires the cycle time to come down first, and that is a process and tooling problem rather than a question of intent. This is why time to answer is the criterion that unlocks the others: it is the precondition for every cadence improvement people want.
A workable pattern separates the three activities that usually get bundled into one. An annual plan sets the commitments and the structure. A monthly or quarterly re-forecast updates the numbers against actuals with the structure unchanged. And an on-demand scenario answers a specific question when one arises, outside both calendars. These have different audiences, different precision requirements and different costs, and conflating them is why re-forecasting feels like repeating the budget.
The on-demand track is the one that benefits most from probabilistic tooling and the one most often missing from the calendar entirely. Questions arrive when the board asks about a tariff change or a competitor moves or a large customer signals trouble, and they do not wait for the next cycle. A team that can answer these in a day with a defensible range becomes the first call for strategic questions, which is a materially different role from producing the monthly pack.
If most FP&A effort goes on assembling and reconciling data, the first automation target is obvious and it is not the modelling. Get actuals flowing in without manual intervention, get the mapping maintained in one place, and get variance reporting generated rather than assembled. That work is unglamorous, it is where the hours are, and it is the precondition for everything else because a forecast cycle cannot be faster than its data preparation.
Only then is it worth automating the analysis itself, and the order matters because the reverse sequence produces a sophisticated model fed by a manual pipeline, which breaks the moment the analyst who maintains it takes leave. The benchmark to aim at is that a re-forecast requires judgement about assumptions and essentially no data handling, at which point the cadence question becomes a choice rather than a capacity constraint.
Cadence design also has to answer a question that single-number planning leaves implicit: which point in the distribution becomes the commitment. A forecast at the midpoint is the honest expectation and will be missed roughly half the time, which makes it an uncomfortable basis for external guidance. A commitment at a higher confidence level will be beaten more often than missed, at the cost of being lower.
Making this choice explicitly is one of the clearest practical gains from probabilistic planning, and it is a choice most finance functions currently make by accident. Deciding deliberately that the internal forecast sits at the midpoint while external guidance sits at a level the business can afford to clear turns a recurring credibility problem into a policy. The S-curve figure later in this guide shows what that choice looks like when you can see the whole distribution.
A distribution is more informative than a number and harder to use, and the skill of reading one is learnable in an afternoon. Since the output of any tool in this category is percentiles, curves and rankings, it is worth being fluent in what each one does and does not tell you before deciding which product presents them best.
A percentile is a level with a probability attached. The P50 is the value with half the simulated outcomes below it and half above; the P80 is the value exceeded in twenty percent of outcomes. These are definitional rather than empirical, and the only real subtlety is the direction convention: for a cost or a duration, the high percentile is the pessimistic one, while for revenue or return it is the optimistic one. Mixing up the direction between a cost model and a revenue model is a common and embarrassing error.
The useful habit is to report three numbers rather than one: a downside, a midpoint and an upside, with the probabilities stated. The gain is not precision but honesty, because a single number implies a confidence nobody has and three numbers with probabilities make the uncertainty part of the message. Our page on probability distributions shows how P10, P50 and P80 are presented together.
The most useful single view in an FP&A context is the simulated outcome plotted against the number you have committed to, because it converts the abstract question of risk into a readable share of the chart. The proportion of simulated outcomes falling short of the commitment is the probability of a miss, and seeing it as area rather than as a percentage tends to change the conversation more than the percentage does.
Two things to look at beyond the headline share. First, the shape: a distribution with a long thin left tail says that most misses are small but a rare miss is severe, which calls for a different response than a symmetric spread. Second, the position of the commitment within the range: a plan sitting near the optimistic edge of its own distribution is a plan that requires most things to go right, which is worth knowing before it is signed off rather than afterwards.
The cumulative view, usually called an S-curve, answers the question an executive actually asks: what level can we commit to with a given confidence. Read up from the horizontal axis to find the probability of achieving a level, or across from a confidence level to find the level it corresponds to. It is the same information as the histogram, arranged so that the commitment decision is a direct read rather than a calculation.
This is where the gap between forecasting and committing becomes visible and manageable. The midpoint is the honest central expectation. The level you guide to externally should reflect how costly a miss is, which is a business judgement rather than a statistical one, and the curve makes the price of each increment of confidence explicit. Treating that as an explicit policy choice rather than an instinct is one of the most practical changes probabilistic planning brings.
The sensitivity output answers the question of what to do next. Ranked by how much each driver moves the outcome, the list tells an FP&A team where additional work is worth doing, and it is usually surprising, because the drivers that dominate a distribution are frequently not the ones that dominate attention.
Read the ranking as a budget for analyst time. The top driver deserves real work: better history, a tighter range, a conversation with the owner about what would move it. The bottom half deserves none, and the discipline of consciously not refining the bottom half is where a lot of the time saving comes from. A model that treats every assumption as equally deserving of attention wastes most of its effort on assumptions that do not change the answer.
It is as important to know the limits. The distribution describes the consequences of the ranges you supplied and the structure you built, so it cannot reveal a risk you did not model, and it will not warn you that your ranges were too narrow. A tidy distribution is not evidence that the inputs were good, which is why the calibration record matters so much and why the research on miscalibration should be read as a warning about confidence in the output rather than only about confidence in the inputs.
Nor does the output make the decision. A plan with a sixty percent chance of success might be an obvious yes or an obvious no depending on the cost of failure, the availability of alternatives and the organisation’s appetite for risk. The analysis informs the judgement; it does not substitute for it, and a tool marketed as removing judgement from the decision is misdescribing both the mathematics and the job. Our discussion of the hidden costs of false precision covers how precise-looking output can mislead.
The argument is easier to see on a concrete case, so what follows is a deliberately simplified annual revenue plan for a subscription business, worked first the usual way and then probabilistically. Every number in this section is illustrative and chosen for clarity rather than drawn from a real company.
The plan starts from an existing revenue base of 72 units, applies net revenue retention of 104%, and adds new business from a sales team of 18 quota-carrying reps ramping over four months, each expected to close 0.9 units in the year at an average selling price that holds flat. The arithmetic produces roughly 86 units of annual revenue, the number goes into the board pack, and the finance team is asked to defend it (all figures illustrative).
Each of those inputs is a point estimate standing in for something uncertain. Retention has ranged between 98% and 109% over the past eight quarters. Ramp time has been as short as three months and as long as six. Rep productivity varies by segment and by hiring cohort. Average selling price has been drifting down under competitive pressure. The plan presents one combination of these as though it were the expectation, and the 86 inherits all of that uncertainty without displaying any of it.
The conventional response is to add an upside and a downside. The upside sets retention at 109%, ramp at three months and productivity at the top of its range, producing about 97. The downside sets retention at 98%, ramp at six months and productivity at the bottom, producing about 74. The deck now shows 74, 86 and 97, and everyone feels the plan has been stress tested (all figures illustrative).
It has not, in two specific ways. The downside of 74 requires every driver to land at its worst simultaneously, which is a single improbable combination rather than a representative bad year, so it overstates how likely that particular figure is while saying nothing about the much more probable outcome where two of the four drivers disappoint. And nothing in the presentation says how likely 86 itself is, which is the only question the board actually has.
Now express each uncertain input as a range with a shape: retention between 98% and 109% centred near 104%, ramp between three and six months centred near four, productivity per rep between 0.7 and 1.05 units centred near 0.9, average selling price between a 4% decline and flat. Add the knowledge that retention and selling price tend to move together, because both respond to competitive pressure, so they should not be sampled independently.
Sampling thousands of combinations from those ranges produces a distribution rather than a figure, and the distribution says something the three cases could not. Suppose it centres near 84 with a P10 around 75 and a P90 around 94, and that the committed 86 sits at roughly the sixty-second percentile, meaning about 38% of simulated outcomes fall short of it (all figures illustrative). That is the sentence the board needed, and the deterministic version could not produce it in principle rather than by oversight.
The sensitivity output then tells the team where the risk lives. In this illustrative case net revenue retention dominates, because its range is wide and it multiplies the largest base, followed by conversion and then by ramp time, with selling price and infrastructure cost contributing little. The practical implication is that a week spent tightening the retention estimate is worth more than a month spent refining the cost lines, which is the opposite of how finance review time is usually allocated.
It also reframes mitigation as something testable before it is paid for. If a customer success investment would lift the bottom of the retention range from 98% to 101%, that change can be made in the model and the plan re-run, and the resulting movement in the probability of hitting 86 is an estimate of what the investment buys in risk terms (illustrative). That is a different and better conversation than arguing about whether the investment is worthwhile in the abstract.
Nothing about the business changed between the two versions. The same model, the same drivers, the same beliefs about the future. What changed is that the plan now arrives with its own risk attached: a stated probability, a ranked set of causes, and a view of what would have to be true for the commitment to fail. The board can accept 86 knowingly, or ask for 84, or fund the retention work, and each of those is a decision rather than an act of faith.
This is the entire proposition of probabilistic planning in one example, and it is worth noticing how modest the methodological change is. Nobody had to abandon the spreadsheet, learn a new discipline or rebuild the driver model. They had to state the inputs they were unsure about as ranges rather than points, let the machine explore the combinations, and report the odds alongside the number. You can try the same mechanics on a small case with the Monte Carlo calculator or the project success calculator.
A planning platform purchase is an IT project, and IT projects have a measured track record that buyers rarely consult before signing. Since this guide is about quantifying risk, it would be inconsistent not to quantify the risk of the purchase itself, and the published evidence is sobering enough to change how an evaluation should be structured.
McKinsey, working with the University of Oxford, studied more than 5,400 IT projects and found that large ones ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Software projects fared worse than the average, with cost overruns around 66% against 43% for non-software projects, and 17% of projects went badly enough to threaten the existence of the company running them.
45% over budget, 56% less value - across more than 5,400 IT projects studied with the University of Oxford, large IT projects ran 45% over budget and 7% over time while delivering 56% less value than predicted. Software projects averaged 66% cost overrun, and 17% of projects threatened the very existence of the company.
The relevant part for an FP&A buyer is the value figure rather than the cost figure. Overrunning a budget is painful and visible; delivering a little over half the expected value is the quieter and more common outcome, and it is precisely what a planning platform implementation looks like when it goes wrong. The licence gets paid, the system goes live, the consolidation improves, and the decision-quality benefits that justified the business case never materialise because nobody changed how plans are made.
Bent Flyvbjerg and Alexander Budzier, writing in Harvard Business Review, documented the pattern in which a major enterprise-software implementation goes beyond overrun into material financial damage, including the case of Levi Strauss, where an SAP implementation contributed to a charge of 192.5 million dollars. Their broader point is that the distribution of IT project outcomes has a fat tail: the typical project overruns moderately and a small minority fails catastrophically.
This is the same statistical shape this guide recommends modelling in a revenue plan, which makes the irony hard to miss. A finance team buying planning software to quantify tail risk in the business should apply the same thinking to the purchase, and the applicable lesson from the research is that the tail is driven by scope and coupling. The catastrophic cases are nearly always large, multi-year, all-at-once programmes rather than contained deployments.
The structural defence is to scope the first deployment around a single real decision rather than around a system. Pick a decision that is genuinely upcoming and genuinely consequential, implement only what is needed to analyse it, and get to an answer that somebody acts on. This produces a working capability in weeks and an internal reference that no business case can substitute for, and it keeps the failure cost of being wrong about the vendor to something recoverable.
This is the opposite of the usual sequence, which builds the full data model, migrates the historical plans, trains everyone, and only then attempts an analysis. The usual sequence is attractive because it looks thorough and because it matches how implementation partners price work, and it concentrates all the risk at the end, where discovering a mismatch is most expensive. Our guide to risk assessment software implementation sets out this phasing argument in more detail.
The licence is usually the smallest of the three costs. The second is implementation, whether from the vendor or a partner, and it is quoted and therefore visible. The third is internal time, which is rarely quoted and frequently larger than either: the analyst days spent mapping data, the business owners pulled into driver workshops, the finance leadership attention spent on decisions about structure. Leaving this out of the comparison systematically favours the product with the most configuration work, which is the opposite of the intended effect.
A reasonable practice is to estimate internal days as a range rather than a number, for exactly the reasons this guide has been arguing, and to ask each vendor for the range their comparable customers actually consumed rather than the quoted estimate. The difference between those two figures is informative on its own, and a vendor who can produce the real distribution rather than a single confident number has demonstrated something about how they think.
Every product in this category promises a single source of truth, and the phrase is doing a lot of work. It is worth unpacking what integration genuinely buys, because the survey evidence says data handling is where FP&A time goes and because the gap between a connector working and a forecast improving is wider than the sales narrative admits.
A good integration removes manual assembly: exporting from the ledger, pasting into a workbook, re-mapping accounts that moved, reconciling the result against a report that was run on a different date. That work is error prone, it is invisible in any job description, and on the published evidence it consumes the majority of the function’s effort. Automating it is the clearest and most defensible return available in this category.
It also removes a specific category of embarrassment. A plan assembled by hand from exports taken at different moments will not tie to the reported actuals, and the time spent explaining why is time spent destroying confidence in the analysis. A pipeline that pulls from one place at one moment eliminates that class of question entirely, which matters more for credibility than for accuracy.
Integration does not improve the data. If the chart of accounts does not distinguish the things the business needs to plan separately, no connector will invent the distinction, and the forecast will remain structurally unable to answer the question. The same survey work that found most FP&A time going on data handling also found only a small minority of organisations rating their data quality as good, and those two findings are related: the handling is manual partly because the data needs human repair.
This argues for doing some unglamorous structural work before or alongside the implementation, in particular getting the dimensions right on the systems of record. It is slower than buying a tool and it is the thing that determines whether the tool helps. A vendor who raises this during the sales process rather than after the contract is signed is giving you useful information about their experience and their incentives.
One underappreciated integration question is granularity: at what level does the plan need to resolve, and does the incoming data support it. A plan that forecasts by segment and channel needs actuals tagged by segment and channel, and if the ledger stops at product line then the variance analysis will be a reconstruction rather than a comparison. This is worth resolving on paper before the implementation, because discovering it halfway through means either a data project or a quietly simplified model.
The same question applies in time. Weekly operational drivers feeding a monthly financial model require a decision about how the aggregation happens and what gets lost in it, and the answer affects how fast a scenario can be re-run. These are not exciting decisions and they are the ones that determine whether the day-one experience matches the demo, which is why they belong in the evaluation rather than in the implementation.
No evaluation in 2026 escapes the question of artificial intelligence, and the vendor messaging has moved faster than the evidence. The useful approach is to separate what finance teams are measurably doing with these tools from what they are being told the tools will do, and the published survey data makes that separation possible.
Gartner surveyed 183 CFOs and senior finance leaders in May and June 2025 and found that 59% reported using AI somewhere in the finance function, barely changed from 58% the year before. More revealing is where it is used: knowledge management leads at 49%, followed by accounts payable automation at 37% and error or anomaly detection at 34%. The largest obstacles were data literacy and data quality rather than model capability.
59% - of finance leaders reported using AI in the finance function in 2025, up only marginally from 58% in 2024. The leading use cases were knowledge management (49%), accounts payable automation (37%) and error or anomaly detection (34%), with data literacy and data quality cited as the largest obstacles.
Notice what is absent from that list. The use cases with real adoption are document handling, transaction processing and exception detection, which are valuable and are not forecasting. Meanwhile intent is running well ahead of deployment: Deloitte’s Q4 2025 CFO Signals survey of 200 finance chiefs at companies above a billion dollars in revenue found 87% expecting AI to be extremely or very important to finance operations in 2026, with only 2% saying it would not be important.
87% - of CFOs expect AI to be extremely or very important to their finance operations in 2026, against 2% who say it will not be important. Half rank digital transformation of finance as a top priority for the year, and 49% prioritise automating processes to free staff for higher-value work.
Source: Deloitte, Q4 2025 CFO Signals
The gap between 87% expecting importance and 59% reporting any use at all is the space in which vendor claims currently operate. It is not evidence that the claims are false; it is a reason to require that they be demonstrated on your data rather than described. The same Gartner programme found financial planning software attracting 24% of planned future investment in core finance technology, behind cloud ERP at 38%, which puts the spending in proportion.
There are places where the help is real and worth paying for. Turning a plan described in prose into a structured set of drivers and uncertainties is tedious work that a language model does well, and it collapses the setup time that keeps most teams from running an analysis at all. Summarising what a distribution implies in language an executive can read is similarly useful, and so is suggesting which uncertainties a plan has failed to mention, because omission is the dominant failure in risk identification.
What AI does not do is supply the probabilities. The odds come from the simulation arithmetic applied to the ranges, and that arithmetic has been well understood since the middle of the last century. A vendor who implies that a model is generating the probability directly has either misdescribed the product or built something you should ask hard questions about, because a plausible-sounding number with no derivation is exactly the kind of false precision this guide argues against.
Incertive uses language models for the parts of the problem they suit: reading a plan written in prose, identifying the uncertainties in it, and expressing the result in readable terms. The probability itself comes from simulation over the ranges, which is why the methodology page describes the arithmetic rather than the model, and why the output is traceable back to assumptions a human can inspect and change.
Once a probability informs a commitment, it becomes something somebody may have to defend: to an auditor, a lender, a board committee or a regulator. Finance functions are used to this discipline for reported numbers and much less used to it for forward-looking analysis, and the transition catches teams out. The governance questions are worth settling during selection rather than after the first awkward request.
The minimum standard is that any analysis which supported a decision can be shown again exactly as it was, with the inputs, the model version and the result stored together. Reconstruction does not count, because a reconstruction six months later uses whatever the current model and current data say, which is precisely not the question being asked. Ask the vendor to show you an analysis from a prior date and watch whether it is retrieved or rebuilt.
Simulation adds the wrinkle that a random process will not repeat identically unless something is held fixed, and a product built for governed use will have an answer: either the sequence is held, or the iteration count is high enough that the reported figures are stable at the precision used. Either is defensible. What is not defensible is a result that shifts between runs by more than the precision in which it is quoted, and a buyer should test this rather than assume it.
The second requirement is knowing who asserted what. When a range turns out to have been wrong, the useful question is who owned it and on what basis, and that is only answerable if the tool records authorship and change history at the assumption level. This sounds bureaucratic and it is the mechanism that makes estimates improve, because an assumption with a visible owner and a visible history gets better and an anonymous one does not.
It also protects the finance function. A plan built on ranges supplied by business owners, with the authorship recorded, puts the conversation about a miss where it belongs. Without that record, every variance discussion defaults to a debate about whether finance was too conservative, which is both unproductive and a reliable way to bias future plans upward.
The questions are consistent enough to prepare for. Where did each range come from, and is there evidence behind it. What correlations were assumed, and why. How many iterations were run, and is the result stable. Who reviewed the model, and when. Has the model been checked against outcomes, and what did that show. A product that stores the answers as a by-product of normal use makes this a retrieval exercise; one that does not makes it a project.
The last of those questions is the one most teams are unprepared for and the one that most improves the process. Being able to show that stated confidence levels have tracked realised outcomes over several cycles is a far stronger answer than any argument about methodology, and it is the kind of evidence that survives a change of leadership. Our calibration tracking page describes how that record is kept, and the broader treatment sits in our probabilistic forecasting guide.
Pricing in this category is deliberately hard to compare, with licence models based variously on named users, on modelled entities, on data volume and on modules. The way through is to stop comparing prices and start comparing the cost of a defined outcome, which forces every quote onto the same footing.
Total cost of ownership over three years has three components. The licence, which is quoted and usually escalates on renewal. Implementation, which is quoted and usually underestimated. And internal effort, which is almost never quoted and is frequently the largest. Comparing only the first of these reliably favours the product that pushes the most work onto your team, which is the opposite of what a buyer intends.
Ask each vendor three specific questions and write the answers down: what the renewal escalator is, how many internal days their comparable customers spent reaching production, and what happens to the price when a user or an entity is added. The third question matters more than it appears, because a model that charges per modelled entity creates a quiet incentive against the granularity your plan needs.
A more useful denominator than cost per user is cost per decision analysed. Estimate how many consequential decisions a year the tool will actually inform, divide the three-year cost by that number, and the comparison becomes meaningful across very different pricing models. The exercise is also diagnostic: a team that cannot name ten decisions a year the tool would inform has learned something important before signing a contract.
Run the number against the stakes rather than against the budget. If the decisions in question commit several million, then a tool costing a fraction of one percent of that is cheap even if it is expensive as software, and if the decisions are small then the calculus reverses. Published tier limits and prices for our own product are on the pricing page, and the same arithmetic is worth doing for every option on the shortlist including the option of changing process instead.
The comparison set should include the current process, costed honestly. Count the analyst days consumed by the last budget cycle, the elapsed time from question to answer, and if you can, one or two decisions that went badly in ways a quantified range would have flagged. That last item is uncomfortable to estimate and is usually the largest number on the page, which is precisely why the exercise is worth doing before anyone starts discussing licence tiers.
Doing nothing is sometimes the right answer, and knowing when strengthens the negotiation either way. Several of the gains described in this guide, in particular collecting ranges from owners rather than points from one analyst and reporting a probability alongside the number, are available for the price of changing a template. A tool has to beat that baseline by enough to justify the implementation risk the McKinsey figures describe, and most of the value in asking the question comes from having the baseline in writing.
The failure mode for tools in this category is not that the mathematics is wrong but that nobody uses the output. The probability appears in an appendix, the decision is made on the familiar single number, and at renewal the tool is a reporting line nobody can defend. Avoiding that is a design problem and it is worth planning as deliberately as the implementation.
The temptation is to pilot on something safe where nothing is at stake, and a low-stakes test produces a low-stakes reaction. Pick a real commitment with real money attached: the annual plan, a major hire-ahead-of-revenue decision, a pricing change, a market entry. When the analysis surfaces a driver that leadership had not weighted, the value is self-evident and the rollout stops needing to be sold.
The corollary is to accept the risk that the first analysis contradicts a decision somebody has already made emotionally. That is not a problem to be managed away; it is the capability working, and how the organisation handles the first instance sets the pattern for everything after. A team that quietly shelves an inconvenient first result has taught everyone what the tool is for.
The single biggest quality lever is the ranges, and they live with the people closest to the work rather than in finance. Ask each owner for a realistic low, high and most likely on the drivers they control. This produces wider and better ranges than one analyst’s estimate, for the reasons the miscalibration research explains, and it builds shared ownership so the result cannot be dismissed as the finance team’s model.
It also changes what a planning conversation is about. Asking a sales leader for a number invites a negotiation about ambition; asking for a range invites a discussion about what is known, what the history says and what would have to be true at each end. The second conversation is more honest, it is usually shorter, and it produces an artefact that can be checked later against what happened.
The output has to travel into the board pack, the investment paper and the gate meeting rather than living in the tool. One sentence is usually enough: the plan has a stated probability of being met, the two drivers most responsible for the risk are named, and the action being taken on each is stated. When leadership sees that sentence every time a commitment is approved, the probability stops being a novelty and becomes part of the vocabulary.
Standardising the sentence matters more than the formatting. If every proposal arrives with the same three elements, comparison across proposals becomes possible and the absence of the elements becomes conspicuous. That is the point at which the practice is embedded, and it tends to happen faster than people expect once the first few papers set the precedent. Our note on building a risk-aware culture covers the organisational side of this shift.
Uncertainty shrinks as time passes and real information replaces assumptions, so the analysis should be refreshed at each decision gate rather than produced once at approval. This is where the capability earns its keep: a commitment that would have been waved through on momentum gets a fresh quantified look, and a plan drifting toward failure gets caught while stopping is still cheap.
It also produces the record that makes the whole thing self-justifying. A series of re-runs across a year is a series of stated probabilities with known outcomes, which is the raw material for calibration, and calibration is the only argument for the method that does not depend on anyone believing the methodology in the abstract. The practice becomes durable at the point where it can show its own track record.
The patterns repeat often enough to be worth listing plainly. Most of them are failures of sequencing or of scope rather than failures of product judgement, which is encouraging, because they are avoidable without any special expertise.
One meta-mistake deserves separate mention: letting the evaluation become a search for the most capable product rather than the most appropriate one. Capability is rarely the constraint and adoption nearly always is, so the product that produces a defensible answer in an afternoon will usually change more decisions than the one that produces a superb answer in a fortnight. That trade-off is easy to state and surprisingly hard to hold onto in a room full of impressive demonstrations.
What follows is a schedule that has the virtue of producing something usable early and keeping the cost of a wrong vendor choice recoverable. It assumes a finance team of modest size and no dedicated implementation staff, which describes most of the organisations reading this.
Write the binding constraint in one sentence. Name the first real decision the tool will be used on, with a date. Take the nine criteria from this guide, choose weights that sum to one hundred, and circulate them. Build or clean up a simplified driver model with eight to twelve drivers and identify an owner for each. Nothing in this fortnight involves a vendor, and skipping it is the most common reason evaluations go badly.
Shortlist three products, not six. Give each the same simplified model and the same unscripted question, and score immediately after each session against the pre-agreed weights. Make at least two reference calls per vendor and ask specifically for a decision the tool changed. By day forty you should have a scored shortlist and a clear view of which product answers your question rather than a different one.
Run a paid or unpaid trial on the single decision you named in the first fortnight. Collect ranges from the business owners rather than estimating them in finance. Produce the probability, the driver ranking and a one-page summary, and have somebody who was not involved in the demos try to produce an answer unaided. Change something structural mid-trial, such as adding a driver, to see what maintenance will feel like.
Put the analysis into the actual meeting where the actual decision is made. The test is not whether the output is admired but whether it is used: does anyone change a view, ask for a mitigation to be modelled, or alter the commitment. Record what was forecast, at what confidence, and against what resolvable criterion, because this is the first entry in the calibration record and it costs almost nothing to start.
Make the purchase decision against the scorecard and the sanity check, then do the small amount of standardisation that determines whether the practice survives. Agree the one-sentence format in which probability and drivers appear in every proposal. Agree which gates trigger a re-run. Agree who owns each driver range. These three agreements are worth more than any amount of further configuration, and they take an afternoon.
The deliberate omission from this schedule is a full data migration, which belongs after the first embedded decision rather than before it. Getting one real decision analysed and acted upon inside ninety days is the thing that makes the rest of the programme fundable and the thing that tells you whether you chose correctly while changing course is still cheap.
To close the practical argument, here is the mapping from situation to category, stated bluntly. It is a starting point for a shortlist rather than a substitute for the evaluation, and it will eliminate a surprising amount of work.
Two situations deserve a warning. If you are buying because a board member asked for scenario planning and nobody has defined what that means, stop and define it first, because the term covers everything from three saved budget versions to full probabilistic simulation and the wrong reading will produce an expensive mismatch. And if you are buying to fix forecast accuracy, be clear that no tool makes the future more knowable; what it does is stop the plan from understating how unknowable the future already was.
The search for the best FP&A software for scenario planning and what-if analysis usually starts as a product comparison and should end as a diagnosis. The published evidence is specific about where finance planning breaks down: structured scenario planning is practised by well under half of organisations, only around one in six can turn a scenario around inside a day, fully driver-based models remain rare, and the majority of FP&A effort is still consumed by moving data rather than interpreting it. None of those is a modelling-capability problem, and a tool bought to solve a capability problem will leave all of them in place.
What follows from that diagnosis is a short list of things to insist on. Assumptions that can be entered as ranges rather than points, because the research on managerial miscalibration says the single number was always hiding more than it showed. Correlation handled rather than ignored, because the outcomes that damage a business come from several things going wrong together. A driver ranking alongside the probability, because the probability says where you stand and the ranking says what to do. An answer available the same day, because a capability that arrives after the meeting is not a capability. And a record of forecast against outcome, because that is the only thing that ever proves the numbers meant anything.
The methodological change this requires is smaller than it sounds, which is the most encouraging part. Nobody has to abandon the spreadsheet, retrain the team or rebuild the planning calendar. State the inputs you are least sure about as ranges rather than points, let the machine explore the combinations rather than naming three of them by hand, and report the odds alongside the number. That is a modest change in method and a large change in what the plan is capable of supporting, and it is the change our pillar guide to what-if analysis software argues for at greater length.
If you want to go deeper on particular parts of this, the companion pieces cover them: financial scenario planning software for the finance-specific tooling landscape, Monte Carlo simulation software for the simulation engines themselves, the limits of Excel forecasting for why the default tool struggles with this, and scenario planning software for the broader category view. The glossary defines the terms, and the comparison with static forecasting sets out the contrast in the plainest form.
Incertive was built for the narrow version of this problem: a team that needs a defensible probability on a real commitment, quickly, without a modelling project. Describe a plan in plain language, and it identifies the uncertainties, runs the simulation and returns a probability of success with the drivers ranked and the assumptions visible and editable. You can see what it looks like for executives, read how the method works, try it on a decision you are facing with the go/no-go calculator, or get started. The next commitment is coming either way. The only question is whether you make it with the odds in front of you.
There is no single best product, because the category covers tools built around four different organising ideas and the right answer depends on which problem is binding. If consolidation across entities is the pain, a cloud EPM or CPM platform is the right purchase. If manual data assembly is consuming the team, a mid-market FP&A tool with strong native connectors delivers the fastest return. If a strong analyst needs probability on a model that already works, a spreadsheet simulation add-in is the cheapest good answer. If commitments are being made on single-point estimates and nobody has time to change that, a decision-intelligence tool optimised for time to answer and explainability is the right category. The practical method is to write your binding constraint in one sentence before any demo, weight the evaluation criteria against it, and then test products on your own model with an unscripted question.
In practice the terms are used loosely and overlap, but the useful distinction is structural. What-if analysis changes the inputs to one model and reports the effect on the outputs, which is how Excel Scenario Manager, Goal Seek and Data Tables work and how most planning platforms implement the feature. Scenario planning, in the stronger sense, compares structurally different plans rather than the same plan with different numbers: a phased rollout against a full launch, hiring ahead of revenue against hiring behind it. The most important difference in a product evaluation is neither of those, though. It is whether the tool is deterministic, producing one exact output per set of exact inputs, or probabilistic, accepting ranges and returning a distribution with the odds attached. Only the second answers how likely the plan is to be met.
Three named cases are good communication devices and poor risk assessments. A plan with a dozen uncertain inputs has a very large space of possible combinations, and three cases sample three points from it, chosen for narrative tidiness rather than likelihood. The named downside is usually built by moving several inputs to their worst values at once, which is a specific improbable combination rather than a representative bad year, so it is simultaneously too pessimistic as a description of how things usually go wrong and not pessimistic enough about how badly they can go. Simulation samples the space properly, weights each input by how likely its values are, can account for drivers that move together, and produces the one number the three cases cannot: the probability that the committed figure is met. Keep the named cases for the narrative and add the distribution for the decision.
It depends far more on scope than on product, and the scope decision is where the risk sits. McKinsey, working with the University of Oxford across more than 5,400 IT projects, found large IT projects running 45% over budget on average and delivering 56% less value than predicted, with software projects faring worse than the average. The structural defence is to scope the first deployment around a single real decision rather than around a system: implement only what is needed to analyse one upcoming consequential commitment, get to an answer somebody acts on, and leave full data migration until after that. On that approach a first embedded decision inside ninety days is realistic for a mid-sized finance team, while a full-platform, all-at-once programme is typically measured in quarters and carries most of the published failure risk.
You keep score, because a single probabilistic forecast is close to untestable. If you say an outcome has a seventy percent chance and it does not happen, you were not wrong: seventy percent events fail to happen three times in ten. Only the set is testable, and the property being tested is calibration, meaning whether roughly seventy percent of the things you called seventy percent actually happened. That requires a record: for each forecast, the date, the stated probability, a resolvable success criterion and eventually the outcome. After a dozen or so resolved forecasts, patterns emerge, and most organisations discover they are overconfident in the specific sense that their ninety percent forecasts come in nearer seventy. That matters because the research on managerial miscalibration found realised market returns falling inside executives’ stated 80% confidence intervals only 36% of the time. Tool selection should therefore treat outcome tracking as a requirement rather than a nice-to-have.
Incertive gives finance teams a defensible probability on a real decision without a modelling project. Describe the plan in plain language and get a success probability, the ranked drivers behind it, and the assumptions laid out so anyone can challenge them.
Analyze My PlanBack to Blog