Choosing FP&A Software: Make the Demo Follow Your Workflow

A vendor’s standard demo runs on prepared data, along a path the vendor knows well. That is a reasonable way to screen options. On its own, it does not establish whether the software fits the way your team closes, forecasts and reports.

To find that out, ask each shortlisted vendor to demonstrate the same workflow against acceptance criteria you set in advance, and record what you actually saw. For this evaluation, distinguish three stages: an introductory demo to screen options, a tailored workflow demonstration for the shortlist, and a scoped proof of concept only where a consequential requirement is still unresolved. This article covers the middle stage. Even a well-run tailored demo shows only that the workflow can work in an agreed setup. It does not prove production readiness.

Hypothetical example. The finance team, workflow and table entries below are invented to illustrate the method. They do not describe any product.

1. Define one workflow and the result you need

Pick one recurring process the team wants to improve. In our example, an Excel-heavy finance team runs a monthly cycle with five steps: refresh actuals from the general ledger, update one departmental forecast assumption (Marketing’s planned Q4 program spend), review the impact, approve the change and produce the management reporting pack.

Before any demo, write a few acceptance criteria you could observe on screen. Ours:

• Refreshed actuals reconcile in total to the agreed trial balance or control totals.
• Department-level figures reconcile to an agreed departmental general ledger report or another appropriate source.
• The changed Marketing assumption flows through the forecast and into the reporting pack without manual rebuilding.
• A reviewer can see which version they are looking at, what changed, who changed it and whether it is approved.
• The team can name who will maintain account and department mappings and model logic after go-live.

These are examples, not universal requirements. What matters is agreeing on them internally and sharing the same set with every shortlisted vendor.

2. Prepare a small, representative demo pack

Give vendors enough to run the workflow, and no more:

• Synthetic or properly anonymized data with your real structure: a few departments, a few months.
• Your account and department mappings.
• A small existing model, or a written description of its logic.
• One reporting output you want reproduced.
• One realistic exception (see step 4).
• The acceptance criteria, and who from your team will attend in which role.

Don’t send confidential company files without approved handling under your company’s policies. Stripping names may not be enough. NIST describes how researchers re-identified individuals in released datasets that had names and similar identifiers removed, by combining the data that remained (NIST SP 800-188). In finance data, a one-person department’s salary line or a customer recognizable by its revenue can reveal who is behind the numbers.

If two of your own reports disagree on figures you plan to use, settle which is authoritative before the demo. Our guide to checking finance data when reports disagree walks through how.

A small sample tests the workflow. It doesn’t validate production data volumes, performance or every integration.

3. Make the demo follow the workflow

Ask the vendor to show each stage rather than describe it:

At each stage, note where Excel remains in the workflow, if anywhere, and whether that matches your requirements. Some teams want to keep Excel for analysis or outputs; others want it out of the core process. Neither is right by default. For every step, also ask who does this after go-live: a finance user, an administrator, IT, the vendor or a partner.

4. Add one agreed exception

Continue the example: September actuals include a new general ledger account that isn’t in the mapping yet. Agree this exercise with the vendor in advance. The goal is to see the process, not to catch anyone out.

Ask them to show how the unmapped account is detected, who is notified or assigned to fix it, how the mapping is corrected, and how the correction appears in the reconciliation and the reporting pack.

Then record what kind of work you saw: ordinary finance-user work, administrator configuration, specialist implementation, custom code, or a capability that was only described.

If AI features appear, such as a suggested mapping for the new account or drafted commentary, ask which outputs are generated suggestions and which are deterministic calculations. Also ask whether a suggestion passes through the same approval control as a manual change. NIST notes that generative AI can produce confidently stated but erroneous content (NIST AI 600-1). A suggested mapping is a proposal for someone to approve, not a correction.

5. Record evidence and decide what to verify next

Record each requirement with a descriptive status, not a score:

• Demonstrated in the agreed setup
• Described, not demonstrated
• Requires configuration or services
• Requires further validation

A requirement can carry more than one status. For example, exception handling may be demonstrated and still require an administrator to configure it.

Then sort open items into three kinds:

• A genuine mismatch with a non-negotiable requirement. For example, reviewers can’t see approval status, and the vendor confirms there’s no supported way to provide it. Either the requirement changes or the option leaves the shortlist.
• An acceptable dependency. Configuration or services you can accept, provided the owner, scope and ongoing maintenance are clear.
• An unresolved question. Ask for written confirmation, or run a proof of concept scoped to that requirement alone. The more consequential the requirement, the stronger the case for testing over taking someone’s word.

Finally, check what you saw against what you’re being offered. Confirm that the modules or edition used in the demo are the ones in the proposal. Also confirm that the configuration and services you noted are assigned to someone: your team, the vendor or a partner.

If you’re still forming a shortlist, our FP&A software page can help you explore fit before you script the first demo.