One finance task / four evidence states
Ask the system to prove the job.
Demonstrated
Works in the proposed configuration.
Configuration needed
Confirm effort, rights and continuing cost.
Additional dependency
Identify the add-on, product or custom work.
Not yet proven
A roadmap promise remains unproven.
Use your records, an ordinary case and an exception. Finance checks usability; the application owner checks operation; the commercial owner checks scope and price.
Read the diagram
Test one finance task, then distinguish demonstrated capability, configuration, additional dependencies and unproven promises.
01
Bring one piece of real work
Choose the decision or process that is prompting the investment. Define the inputs, the required result and who must use or approve it. Prepare permitted, representative data, including an awkward case. Ask your current application owner and each shortlisted supplier to demonstrate the same task.
For ERP, test the transaction through posting, approval, reconciliation and reporting, including correction of an error. For planning, change a business driver and trace the effect through the forecast and related plans. For close and consolidation, follow a late adjustment across entities, reconciliation, consolidation and sign-off.
02
Watch the handoffs, not just the final screen
Ask who loads the data, maintains the mappings, resolves a failure and approves the result. Identify the agreed source for shared figures and records. Check permissions, source traceability, audit history, integration and exports. Include your actual entity, currency, reporting and data-volume requirements where they matter.
For a planning scenario, watch how versions, assumptions and approval work. For a close scenario, watch matching, currency treatment, intercompany differences and adjustments. For ERP, confirm the relevant operating and local reporting needs.
If automation or an AI agent is part of the proposal, demonstrate the connection it will actually use. Show which account acts, what it may change, where approval is required and who handles a failed transfer. Ask what the record shows when an action is blocked.
03
Separate what is demonstrated from what is promised
Record four different answers: demonstrated in the proposed configuration; available but requiring configuration; dependent on an add-on, custom work or another product; or not yet proven. Ask for the license tier, implementation effort and continuing cost that go with each answer. A roadmap promise remains unproven until it can be tested. Confirm how you can export your records and what ending the arrangement would require and cost.
Have the finance user confirm that the result is usable, the application owner confirm how it will run, and the commercial owner confirm the scope and price. Use the unresolved items to decide the next step: improve what you own, run a narrower test, seek another option, or proceed to a fuller evaluation.
Example system demonstration
A forecast revision you can compare
FP&A needs to revise a forecast when sales volume changes, without emailing separate spreadsheet versions to every cost owner.
- Bring:
An approved baseline, product volumes and prices, cost assumptions, one changed driver and one deliberately missing assumption.
- Ask the demonstrator:
Create a separate scenario, change the driver, show the affected outputs, identify the missing input, and route the scenario for review without overwriting the baseline.
- Check:
Can a finance user trace the change to the agreed source, compare versions and identify who approved it? If an agent submits the revision, does a submission without approval leave the baseline unchanged and create a record the application owner can inspect? Can that owner explain the setup and support work?
- Keep:
The scenario outputs, configuration used, evidence for each requirement, extra costs, and the unanswered question assigned to an owner.
The request the FP&A lead sends after the planning meeting, built from the example above and the finance page's volume scenario. It goes to the current planning application's owner and to one shortlisted supplier, with the same task for both.
Completed demonstration request
Example forecast revision request
- System / configuration being evaluated:
- The current planning application in the configuration we run today; one shortlisted alternative in the configuration the supplier proposes for us, not a showcase tenant.
- Business task and decision it supports:
- Revise the monthly forecast when sales volume changes, so the leadership review can decide on the lower-volume case without a second round of emailed spreadsheets.
- Inputs, awkward case and required output:
- The approved baseline: 10,000 units at $100, variable cost $60 a unit, fixed cost $250,000 for the period, operating contribution $150,000. The change: volume to 9,000 units, price per unit, variable cost per unit and fixed cost unchanged, operating contribution $110,000. The awkward case: one new product line with its price left blank on purpose. Required output: a separate scenario beside the baseline, revenue, variable cost and contribution recalculated, the blank price flagged rather than defaulted.
- User or automation account, permitted actions and approver:
- The FP&A analyst's own account makes the change. If the demonstration includes an assistant that submits revisions, name the account it acts under and what it may change; the FP&A lead approves any scenario before it reaches the review.
- What must happen end to end:
- Create the scenario without touching the baseline; change the volume driver; recalculate the linked outputs; flag the missing price; route the scenario to the FP&A lead; show the version history and the approval on the record.
- Evidence:
- For each step above, one of four answers, written by us in the session: demonstrated in the proposed configuration; available but needing configuration; dependent on an add-on, custom work or another product; not yet proven. No answer is taken from the slides.
- Agreed source, connection, blocked-action evidence and failure owner:
- Volumes and prices come from the approved plan in the application; the ERP actuals feed is the agreed source for cost rates. Show what the record holds when a submission is blocked for lack of approval, and name who is called when the feed fails.
- License, setup, continuing cost and exit terms:
- For every required capability, including those demonstrated: confirm the license tier, what our current agreement includes, setup effort, continuing cost, and how we can export scenarios and history if we leave.
- Question still open / owner / due date:
- Whether the blank-price flag can be a block rather than a warning; the application owner; before the second session.
- Next decision:
- Consider improving the current system when it meets the required tasks and the cost, risk and team capacity are acceptable. Test any unproven requirement before deciding. Evaluate alternatives when a material capability, cost or support gap remains.
- Evidence location:
- Keep the scenario outputs, the configuration used and the session notes with the copied forecast improvement brief in the team's shared project folder.
Keep the next decision clear.
Copy this record into the document you already use with your team. Give an unanswered question an owner and a next action.
Your working record
Finance system demo request
- System / configuration being evaluated:
- To complete
- Business task and decision it supports:
- To complete
- Inputs, awkward case and required output:
- To complete
- User or automation account, permitted actions and approver:
- To complete
- What must happen end to end:
- To complete
- Evidence:
- Demonstrated / Needs configuration / Add-on or custom work / Unproven
- Agreed source, connection, blocked-action evidence and failure owner:
- To complete
- License, setup, continuing cost and exit terms:
- To complete
- Question still open / owner / due date:
- To complete
- Next decision:
- Improve current system / Test further / Evaluate alternatives
- Evidence location:
- To complete
Next: Decide who owns finance's technology work Once the demonstration shows what the system can do, decide who owns the configuration, the data feeds and the platform, and confirm their capacity, before the change starts.