Yes. FP&A (financial planning and analysis) software can manage multiple budget versions and scenarios side by side. Versions record saved iterations of a plan, while scenarios test different assumptions. Centralized labels, approvals and reporting help teams compare alternatives while preserving the approved budget. The key is controlled changes and consistent calculations across the cases.
What is the difference between a budget version and a scenario?
A budget version is a saved iteration or snapshot of a plan, with a status such as draft, submitted or approved. A scenario is a named set of assumptions used to test an outcome. Versions identify which plan and point in time a report uses. Scenarios show what changes when assumptions differ.
A typical cycle produces several versions. Department heads submit version one. Finance consolidates and the CEO reviews, producing version two with cuts. The board approves version three. Each version is kept, because variance analysis later needs to compare actuals to the plan the board approved, not to the first draft.
Illustrative example: use the board-approved plan as the base case. A downside scenario lowers new bookings by 15 percent and stretches collections by ten days. An upside scenario accelerates two product launches. All three share the approved plan’s structure, accounts and departments.
Mixing versions and scenarios causes confusion. A file called “Budget downside v2 final” does not identify its approval status or assumptions clearly. Keep separate labels for the saved version, its approval status and its scenario, and show those labels in reports.
A forecast is an updated outlook that can have its own versions and scenarios. A monthly reforecast combines actuals for closed months with updated assumptions for the remaining periods. Reports should identify the approved budget and the specific forecast being compared with actuals.
How do I build best, base and worst cases without cloning the whole model?
Keep scenario assumptions separate from the formulas that calculate the results. A driver table can let one workbook switch between base, upside and downside cases. If the planning system uses separate scenario files, keep their formulas, reporting structure and source-data cutoff aligned, and record which assumptions differ.
Illustrative example: a team keeps separate base, upside and downside workbooks. An analyst corrects an FX (foreign exchange) assumption in the base copy but misses the downside copy. The comparison then reflects both the intended scenario changes and an unintended model difference. Review calculation changes across every case.
Illustrative driver assumptions for three scenarios:
| Driver | Base | Upside | Downside |
|---|---|---|---|
| New bookings growth | 20% | 28% | 5% |
| Gross revenue retention | 90% | 92% | 86% |
| Days sales outstanding | 45 | 42 | 55 |
| Hiring plan | 48 hires | 60 hires | 30 hires |
| Average hire start lag | 10 weeks | 8 weeks | 14 weeks |
Excel’s desktop Scenario Manager supports up to 32 changing values per scenario, according to Microsoft’s What-If Analysis guidance. A shared driver table is another way to organize a larger set of assumptions.
Focus on the drivers that materially change the decision. Document why each assumption differs between cases, and keep the results explainable to reviewers.
Who controls which budget version is the approved one?
The CFO or a designated finance owner approves the budget and controls changes to that approved version. Preserve the approved values, assumptions and reporting structure as a dated baseline. Later amendments should create a separately identified version with a recorded reason and approval, so budget-versus-actuals reports retain the original comparison.
Illustrative example: the board approves version three, but two department heads continue using version two saved locally. Their variance reports compare actuals with different baselines, so they disagree about whether spending is on plan. A shared approved version and clear status labels keep the comparison consistent.
Submission rules matter as much as the lock. Once a department head submits, edits should go through finance or reopen the submission with a record of what changed. Otherwise numbers move after review, and the consolidated budget no longer matches what was discussed.
Late submissions need a rule too. Finance can roll forward last year’s actuals with an inflation assumption as a placeholder, label it, and replace it when the submission arrives. The budget cycle should not stall on one department.
A short audit trail answers most disputes: who changed which number, when, and from what to what.
How do I keep last year’s budget comparable to this year’s?
To compare budget years, map both to a common reporting structure in a separate comparison view. Preserve last year’s approved budget unchanged, including the structure used at approval. When accounts or departments move, label the remapped view and retain a bridge to the original so readers can distinguish reclassification from a real spending change.
Illustrative example: customer success moves from sales and marketing into cost of revenue this year. Last year’s budget had $1.9 million of customer success cost in sales and marketing. A direct comparison makes this year’s sales and marketing budget look lower and cost of revenue look higher. A separate comparison view maps both years to the same structure, using documented chart of accounts mappings.
Keep both views. The remapped comparison supports planning conversations; the original shows what was approved at the time. Label each clearly in reports.
Inflation and pricing changes are the other factor. A flat budget for a vendor contract with a 6 percent uplift is a cut in real terms. Compare unit drivers, such as cost per employee or hosting cost per customer, alongside totals, so a year-over-year change can be explained by volume, price or efficiency.
Store last year’s approved budget as a locked version in the same system. Rebuilding it from an old file each year invites errors.
How do I do multi-year and long-range planning?
A long-range plan links a detailed first-year baseline to later years using a smaller set of strategic drivers. At budget approval, the baseline can be the approved budget; during the year, it may be the latest forecast. Label that choice and reconcile it to the budget so changes in strategy are clear.
One structure uses monthly periods for the first year and annual periods for years two to five. Tie the first year to the stated budget or forecast baseline. Explain any difference from the approved budget before extending growth, margin and investment drivers into later years.
Drivers change at long horizons. Monthly headcount detail gives way to headcount ratios, such as engineers per million in revenue. Account-level expenses give way to percentages of revenue for most lines, with explicit plans for the largest investments.
A long-range plan should include the balance sheet and cash flow to assess funding needs. Annual balances can hide cash shortfalls within a year, so use monthly or quarterly detail when the timing of funding matters.
Revisit the long-range plan at least annually, and whenever a major assumption changes, such as an acquisition or a pricing shift.
Where should budget data live: the ERP, spreadsheets or an FP&A platform?
Budget data should have one authoritative planning location, chosen for the controls the team needs. An FP&A platform can manage iterations, scenarios and consolidated reporting, while Excel or Google Sheets provides the working interface. Send the approved budget to the ERP (enterprise resource planning) system when accounting needs it for budget controls, and reconcile the transfer.
- ERP: records transactions and may hold approved budgets for spending controls.
- Excel or Google Sheets: provides a flexible planning interface; agree how files, edits and access are controlled.
- FP&A platform: manages planning versions and consolidated reporting; reconcile any approved budget transferred to the ERP.
Datarails FP&A centralizes budget versions, submissions and planning workflows, with FinanceOS® providing the connected data and governance underneath. Teams can work in Excel, Google Sheets or the web application, depending on the workflow enabled for their organization. Google Sheets planning submissions use a separate Contributors feature, currently in beta. Datarails supports managed scenario cloning and comparisons, so finance can maintain consistent model logic without relying on uncontrolled workbook copies.
The guide to AI for forecasting and scenario analysis covers how scenario work is changing with AI tools.
Can I mix automated data feeds with manual adjustments?
Automated feeds and manual adjustments can coexist if the model stores them separately and controls when adjustments apply. Keep ledger actuals unchanged; identify each planning or reporting adjustment by period, reason, owner and review status. When the source system later includes the same item, reverse or expire the adjustment to avoid counting it twice.
A refresh can overwrite values typed into imported-data cells. Put adjustments in a separate input area outside that refresh range, and test the next refresh before relying on it. Show the original actuals, adjustments and adjusted total separately.
In Datarails, configure imported actuals and planning adjustments as distinct inputs, and check which values and explanations are mapped into reports. Test a refresh with the intended template to confirm that adjustments remain separate and are included once. Reviewers should be able to reconcile the source actuals, adjustment amounts and resulting totals.
Set a rule for review. Adjustments above a threshold need a second approver, and all adjustments are reviewed at each reforecast to decide whether they still apply.
Evaluate budget versions and scenarios in Datarails
In a Datarails demo, compare an approved budget, a revised forecast and a downside scenario. Ask how changes are approved, which users can reopen a locked cycle, and how a refresh handles a manual adjustment.
