What questions should I ask in an FP&A software demo?

The questions worth asking in an FP&A software demo are the ones that make the vendor do something rather than describe something. Ask them to drill from a variance into the underlying transactions on your data, to add a department mid-demo and show what breaks, to consolidate two entities with an intercompany balance, and to tell you plainly what their platform is bad at. Feature checklists get answered yes by everyone; live tests do not.

The reason to structure a demo this way is that FP&A tools fail after purchase in predictable ways, and each failure mode has a test that would have caught it. Integrations turn out to be scheduled exports rather than live connections. Model changes turn out to require the vendor. Consolidation turns out to mean summing entities rather than eliminating between them. None of that surfaces from asking whether a feature exists.

Bottom line: insist the demo runs on your own data, and score vendors on four live tests — drill-through, a mid-demo model change, consolidation with an elimination, and budget workflow with a rejection. Then ask what the product is bad at. The speed and specificity of that last answer is the most reliable signal in the whole process.

Before the demo: decide what you are testing

The most common demo mistake is arriving without a definition of success, which lets the vendor set the agenda and run a polished tour of their strengths. Two pieces of preparation prevent that.

First, write down the five outputs you need the tool to produce. A monthly board pack, a rolling reforecast, a headcount plan, budget-versus-actual by department, a cash forecast — whatever your actual accountabilities are. These become the acceptance criteria for every vendor, which makes comparison possible. Our FP&A software evaluation guide has a scoring sheet built around exactly this.

Second, send your own data in advance and ask for the demo to be built on it. Good vendors welcome this; it is a fast, quiet filter. A vendor who insists on sample data is either protecting a weak integration or has not scoped the work your data will require, and you want to know which before you buy rather than in week three.

• Five named outputs, written down, used as acceptance criteria for every vendor.
• Your own data supplied in advance, not a sample dataset.
• A list of every source system, by name and version.
• The number of people outside finance who will submit numbers.
• Whether statutory consolidation is in scope, decided before the first call.

The four tests to run live

These take about twenty minutes between them and separate real capability from a good slide.

1. Drill from a variance to the transactions

Pick a number in a report and ask them to show you what it is made of, all the way down to the entries in the source system. This is the single best test of whether an integration is genuinely live. If drill-through opens a different application, or produces a summary rather than transactions, the connection is a periodic export and your month-end will involve reconciling two systems. This is what live drillable budget-versus-actual should look like in practice.

2. Change the model in front of you

Ask them to add a department, a new GL account or a cost centre during the demo, then show it flowing into a report. What you are measuring is who can make changes. If the answer involves a professional-services ticket, that is a recurring cost and a dependency on someone else's calendar — and it is the most common source of quiet dissatisfaction a year after go-live.

3. Consolidate two entities with an intercompany balance

Many planning tools sum entities and call it consolidation. Ask specifically for the elimination entry and, if it applies to you, which FX rate type is used for which account class. An honest vendor whose product does not do this will say so in one sentence, which is a good sign about everything else they tell you. If consolidation is a real requirement, multi-entity consolidation software is the category you are actually shopping in.

4. Push a budget template and reject a submission

If department owners will contribute numbers, ask them to send a template to two contributors, reject one submission with a comment, and show the audit trail of who changed what and when. Submission status tracking is the feature finance leads say they underrated, and it is the practical difference between a platform and a spreadsheet. Where that threshold sits is covered in the annual budgeting process guide.

The question most buyers never ask

Ask each vendor what their platform is bad at. Then judge the answer on two dimensions: how fast it comes, and how specific it is.

The good answers are immediate and concrete — we are not the right fit for statutory consolidation, we are heavy for a team of two, our workflow assumes a formal budget cycle, our modelling depth has a ceiling. Vendors who know their product's shape can describe its edges quickly, and it usually correlates with having implemented enough customers to have seen the mismatches.

The bad answers are a pause followed by a strength reframed as a weakness, or a claim that the platform suits everyone. That is either inexperience or evasion, and both cost you during implementation. It is also worth asking who they lose to and why, and who they think is genuinely better for a use case unlike yours. A vendor who cannot name a credible competitor is not a reliable guide to their own market.

For our part: Aleph is the wrong tool if you need statutory consolidation with intercompany eliminations and currency translation, and it is more than a two-person team with one entity needs. It fits finance teams who want to keep modelling in Excel and Google Sheets on live ERP, CRM and HRIS data. Aleph holds 4.9 out of 5 from 108 reviews on G2 against a 4.55 category average, and the broader landscape names the alternatives fairly.

Questions about cost, ownership and references

Three areas that decide the next two years and rarely get covered in a first demo.

1. Scoped implementation estimate, in writing, for your systems. Not a range from a pricing page. Ask what assumptions it rests on and what would break it.
2. Who maintains mappings and hierarchies after go-live, and at what cost. Businesses reorganise; someone owns that work. If it is the vendor, price it as recurring.
3. A reference that matches you on three dimensions at once — company size, industry and ERP. One out of three is easy to supply and tells you nothing.

Ask about annual escalation at renewal too, commonly 5 to 15 percent, because it compounds into the three-year number that should drive the decision. We break the full cost picture down in what FP&A implementation actually costs and the pricing guide.

One last question that costs nothing: ask what the first thirty days after go-live look like, day by day. Vendors who have done this many times have a specific answer. For the metric definitions your reporting will be judged against, the Benchmarkit SaaS benchmarks we co-published is the reference set worth agreeing on before you start.

Questions by who is in the room

Different stakeholders should be asking different things, and a demo that only serves the finance lead tends to hit an obstacle later at security review or renewal.

If you own the numbers

Your questions are about ownership and speed. Who can change the model. How long a reforecast takes end to end once live. Whether last quarter's forecast can be reproduced exactly. Whether variance commentary lives with the plan or in a separate document. And whether your existing model is reused or rebuilt — the answer that predicts implementation cost more than any other, as we cover in what implementation actually costs.

If you own the budget

Your questions are about total cost and exit. Scoped implementation in writing. Annual escalation at renewal. What happens to your models and data if you leave — specifically, whether you can export the model logic or only the outputs. Portability is worth asking about precisely because nobody volunteers it, and it is the practical difference between a tool and a lock-in.

If you own security or IT

Your questions are about access and data movement. How permissions map to your existing groups, whether row-level and field-level restrictions are supported, and where data is stored and for how long. If compensation or headcount detail will sit in the model, this is not a formality — see role-based access controls in FP&A tools and how we handle security for what to probe.

After the demo: the reference call

The reference call is the highest-signal part of the process and the most commonly wasted. Vendors supply references who will say good things, so the value is not in whether they are happy. It is in the specifics only a customer knows.

Ask how long implementation actually took against what was quoted. Ask what they would scope differently. Ask who maintains the model now and whether that was the expectation. Ask what broke in the first ninety days. Ask what they still do in a spreadsheet outside the tool, which is the fastest way to find the real gaps. And ask whether they would buy it again at the renewal price rather than the initial price.

Insist that at least one reference matches you on size, industry and ERP simultaneously. One-out-of-three references are easy to supply and prove very little; a vendor with genuine traction in your segment can produce all three. If they cannot, your use case may be less proven than the demo suggested, which is worth knowing rather than fatal.

• Actual implementation length versus the quoted length.
• What they would scope differently with hindsight.
• Who maintains the model today, and whether that matched expectations.
• What broke in the first ninety days.
• What they still do in a spreadsheet outside the tool.
• Whether they would buy again at renewal pricing.

Finally, run the same five acceptance outputs past the reference. If a customer of similar shape produces four of your five outputs in the tool and keeps the fifth in Excel, you have learned exactly where the boundary sits — which is more useful than anything in the demo itself. Then score the vendors against the evaluation framework and, if the shortlist has narrowed to tiers rather than products, the company-size mapping will settle it.