Scenario Planning with Driver-Based Models

14 min read·
financestrategy planningceo toolkit

Scenario planning fails when scenarios are three separate spreadsheets built from three stories. A driver-based model works differently: a small set of named drivers such as volume, price, unit cost, and fixed cost generate the P&L, and each scenario is simply a different setting of those drivers. This guide shows how to select drivers, build the model, run base, downside, and upside cases, test covenant headroom, and write triggers that change behavior. It includes a worked example with verified arithmetic.

Reviewed by Sloan, Driver-Based Financial Forecast Analyst — drafted using Performis's own agentic AI process, reviewed and edited before publishing.

Executive summary

Scenario planning is the practice of working out, before it happens, what you would do if the world turns out differently from your plan. Done well, it gives a mid-market management team three things: a view of which few variables really move the business, a range of outcomes instead of a single forecast, and a list of pre-agreed triggers that tell you when to act.

Done badly, it produces three polished spreadsheets, each telling a different story, none of which can be updated when something changes. By the time a customer is lost or a cost jumps, the scenarios are stale and nobody can say what the new numbers are.

A driver-based model fixes this. Instead of forecasting revenue, cost of goods, and overhead as free-standing lines, you build the profit and loss from a handful of operating drivers: volume, price, unit variable cost, fixed cost, and perhaps working-capital days. A scenario is then a change to the driver settings, and the financial statements recalculate. Everything is traceable. Updating a driver updates the whole picture.

This guide covers:

  1. How to choose drivers, and why fewer is better.
  2. How to build the model so that scenarios are driver changes.
  3. How to run base, downside, and upside cases, plus one-driver sensitivities.
  4. How to test the result against covenants and liquidity.
  5. How to write triggers and actions so scenarios change behavior.

It supports the "size the gap" step in the strategic planning playbook and pairs with the rolling forecast approach.

When to use this

Use driver-based scenario planning when:

  • You are setting a multi-year plan and want to know how fragile it is.
  • A covenant, an earn-out, or a sponsor commitment puts a floor under EBITDA or liquidity.
  • The business depends on a few external variables such as commodity prices, a major customer's volumes, or exchange rates.
  • Budget variance conversations keep ending in "it was the market," with no way to separate market effects from execution.
  • You are evaluating a large option and want to see how it behaves under stress, as part of a strategic options review.
  • The 13-week cash forecast is accurate, but the 12-month view is not.

Do not use it when the model's basic data is unreliable. If you cannot reconcile revenue by volume and price to the ledger, fix the data first. Covenant and lender-agreement definitions govern what counts as EBITDA or debt in your documents; confirm calculations with your own agreements and advisers.

Diagnostic questions

  1. If volume fell 5% next quarter, how many dollars of EBITDA would you lose? Can anyone answer in five minutes?
  2. Which three to six variables explain most of the variation in your gross profit over the past eight quarters?
  3. Is your forecast built from drivers (units, price, rates, headcount) or from percentage growth on last year's lines?
  4. Which of your costs are truly fixed over the next 12 months, which are variable with volume, and which are step costs that change at thresholds?
  5. What is your covenant or lender floor for EBITDA, leverage, or liquidity, and how much headroom does the base case leave?
  6. What is the smallest decline in volume or price that would breach that floor?
  7. For each major external risk, is there a named leading indicator you can watch?
  8. Who owns each driver assumption, and who is allowed to change it?
  9. When did you last compare driver assumptions to actual driver outcomes, not only EBITDA to EBITDA?
  10. What actions would you take in a downside, how long would each take, and how much would each save?
  11. What has to be decided by whom, and by what date, if the downside begins?
  12. Does your board or sponsor have a view on which scenarios they want to see, or are you choosing them yourself?

How to read the answers: if question 1 takes days to answer, you do not have a driver-based model yet. If question 6 has no answer, you do not know how close you are to a covenant problem. If question 10 shows actions without lead times, your downside plan will arrive too late to help.

The framework: drivers, relationships, settings, triggers

Component What it is Example
Drivers Operating inputs you can observe and discuss Units sold, average price, material cost per unit, headcount, days sales outstanding
Relationships Fixed arithmetic linking drivers to financial lines Revenue = units × price; variable cost = units × unit cost
Settings The values chosen for each scenario Base: 400,000 units; downside: 380,000
Triggers Observable thresholds that start predefined actions Two consecutive months of orders below the downside level

Choosing the drivers

A good driver has four properties:

  1. It moves the result materially. If a 1% change barely moves EBITDA, leave it out.
  2. It is observable early. Order intake is a driver you see before revenue; revenue is a result.
  3. It has a named owner who can explain a change.
  4. It is independent enough that you can change it without silently changing another. If price and volume move together because of the way customers react, model that link explicitly rather than hiding it in a single setting.

Start with five to eight drivers. Models with thirty drivers cannot be explained to a board, and most of the extra drivers do not change the answer. A typical set for a manufacturing or distribution business includes volume by major segment, price realization, input cost per unit, labor hours or headcount, fixed overhead, and collection and inventory days if cash is the question.

Variable, fixed, and step costs

The structure of costs matters more than the number of drivers. Split costs into three groups:

  • Variable costs move with volume: materials, freight, sales commissions, usage-based services.
  • Fixed costs do not change in the planning horizon unless you act: rent, salaried headcount, insurance.
  • Step costs change at thresholds: a second shift, an additional warehouse, a new account manager.

Mislabeling fixed costs as variable makes a downside look milder than it is. A salaried team does not shrink when volume falls unless you decide to shrink it. Be honest about which costs only respond to management action, and treat those actions as separate levers with lead times.

Scenarios are settings, not stories

Define scenarios by the driver values and give each a short descriptive name. Resist narrative scenarios such as "recession" with no numbers attached. If you want to describe a macro story, translate it into driver settings: what happens to volume, price, and input cost under that story? Then document the translation so it can be challenged.

A useful minimum set is:

  • Base: your current best estimate.
  • Downside: a plausible adverse combination, not a catastrophe. Be specific about which drivers move and how far.
  • Upside: a plausible favorable case, which also tests whether you could execute it (capacity, working capital).
  • Single-driver sensitivities: change one driver by 1% and record the EBITDA effect. This is the quickest way to learn what matters.
  • Reverse stress test: how far must one driver move before a covenant, a liquidity floor, or a sponsor commitment is breached?

Step-by-step process

  1. Define the question. What decision or risk is the scenario exercise meant to inform: the plan, an investment, a covenant, a refinancing? Owner: CEO or CFO. Output: a one-sentence purpose.
  2. Reconstruct the P&L from drivers. For the last four to eight quarters, rebuild revenue as volume × price, variable cost as volume × unit cost, and fixed costs by line. Reconcile to the ledger. Owner: FP&A. Output: a historical driver table that ties to reported results.
  3. Test the driver set. Check that the drivers explain history. If the model cannot reproduce last year's EBITDA within an agreed tolerance, add or correct a driver. Owner: FP&A. Output: a back-test note.
  4. Classify costs. Variable, fixed, step. Owner: Controller with function heads. Output: a cost behavior table.
  5. Assign driver owners. One name per driver, who explains changes. Owner: CFO. Output: a driver owner list with data sources.
  6. Set the base case. Use the plan's initiative assumptions and known contract changes. Owner: FP&A. Output: base case.
  7. Run single-driver sensitivities. Move each driver by 1%, record the EBITDA and cash effects, and rank them. Owner: FP&A. Output: a sensitivity table.
  8. Design the downside and upside. Combine driver moves that could realistically occur together, and justify each with evidence such as historical ranges in your own data, contract terms, or supplier notices. Owner: CEO and function heads. Output: scenario settings table.
  9. Compute results and test constraints. For each scenario, compute EBITDA, leverage, liquidity, and any other covenant or sponsor metric as defined in your agreements. Owner: CFO. Output: results table with headroom.
  10. Run the reverse stress test. Find the driver movement that breaches the floor. Owner: FP&A. Output: break-point per driver.
  11. List management actions and lead times. What would you do, how much would it save, how long until it takes effect, and who approves it? Owner: COO and CFO. Output: an action menu with timing.
  12. Write triggers. Pair each key driver with an observable leading indicator, a threshold, and an action. Owner: CEO. Output: a trigger table.
  13. Install in the cadence. Update driver actuals monthly, reforecast quarterly, and review triggers at the monthly performance review. See operating cadence. Owner: CFO. Output: standing agenda item.

Templates

Driver register

Driver Definition and unit Owner Data source Update frequency Historical range (own data) Base Downside Upside

Cost behavior table

Cost line Variable / Fixed / Step Driver it follows Step threshold (if any) Management lever and lead time

Scenario summary

Metric Base Downside Upside Floor or covenant Headroom in base
Revenue
EBITDA
Leverage or other covenant metric
Liquidity

Trigger table

Driver Leading indicator Threshold Observation window Action Action owner Approver Lead time

Metrics and KPIs

Metric Formula Data source Use
EBITDA sensitivity per 1% of a driver EBITDA at +1% of the driver minus base EBITDA Model Ranks drivers by importance
Contribution margin per unit Price − variable cost per unit Model Value of each lost or gained unit
Break-even volume Fixed costs ÷ contribution margin per unit Model Floor on volume
Covenant headroom Base EBITDA − minimum EBITDA required under the agreement Model, lender agreement Cushion before a breach
Reverse stress break-point Headroom ÷ EBITDA impact per 1% of the driver, in percent Model How far a driver can move before the floor is hit
Driver forecast error Actual driver − forecast driver, by driver Operating systems Quality of assumptions
Trigger response time Days from trigger breach to decision Decision log Whether scenarios change behavior

Setting driver ranges without invented benchmarks. Use three anchors in order: the historical range of the driver in your own data (best and worst quarter over several years), contractual limits such as price-adjustment clauses or supplier cost pass-through terms, and named public sources such as published commodity price series or listed-peer filings for the relevant input. Set the downside at the edge of a range you have actually seen or can document, and avoid ranges taken from a general article.

Common mistakes

  1. Scenarios that are stories. A "recession scenario" with no driver values cannot be modelled, challenged, or updated.
  2. Too many drivers. A model nobody can explain will not be used. Five to eight drivers cover most mid-market businesses.
  3. Calling fixed costs variable. This makes every downside look gentler than it will be. Show the cost behavior table to the operators who run those costs.
  4. Moving every driver by the same percentage. A uniform 10% haircut reveals nothing. Combine moves that fit a plausible story, and justify each from your own data.
  5. Forgetting working capital. A growth upside can consume cash through receivables and inventory. Include collection and inventory days when liquidity matters.
  6. No back-test. If the driver model cannot reproduce last year, its forecast is not trustworthy.
  7. Management actions with no lead times. An action that saves $1M a year but takes six months to start does not help a covenant test in two.
  8. Triggers without owners or approvers. A threshold that nobody is responsible for watching never fires.

Worked example

Illustrative. All numbers are made up to show the method. They describe no real company and are not benchmarks.

A manufacturer sells 400,000 units a year at $200 average price, has variable cost of $128 per unit, and fixed costs of $19.2M. It carries $36.0M of debt under an agreement with a maximum leverage of 4.0 times EBITDA, which, for this example, we treat as a plain debt ÷ EBITDA test and which in a real company is defined by the agreement. Minimum EBITDA to stay inside the test is $36.0M ÷ 4.0 = $9.0M.

Base case.

Line Calculation Result
Revenue 400,000 × $200 $80.00M
Variable cost 400,000 × $128 $51.20M
Contribution $80.00M − $51.20M $28.80M
Fixed cost $19.20M
EBITDA $28.80M − $19.20M $9.60M
Leverage $36.0M ÷ $9.6M 3.75x

Contribution per unit is $200 − $128 = $72. Headroom is $9.6M − $9.0M = $0.6M.

Single-driver sensitivities (1% change, all else equal).

Driver EBITDA effect
Volume −1% −$0.288M
Price −1% −$0.800M
Unit variable cost +1% −$0.512M
Fixed cost +1% −$0.192M

Check: price −1% means $200 × 0.99 = $198, so revenue falls by 400,000 × $2 = $0.8M with no cost offset. Volume −1% removes 4,000 units × $72 = $0.288M. Variable cost +1% adds 400,000 × $1.28 = $0.512M. The reading: price is the most powerful single driver, nearly three times as powerful as volume per percentage point.

Reverse stress test. Headroom of $0.6M divided by $0.288M per 1% of volume gives about 2.1% volume decline to breach, which matches $0.6M ÷ ($72 × 400,000) = 2.08%. A 1% price fall costs $0.8M and breaches on its own, since $0.8M exceeds the $0.6M headroom.

Scenarios as driver settings.

Driver Base Downside Upside
Volume (units) 400,000 380,000 (−5%) 416,000 (+4%)
Price $200.00 $198.00 (−1%) $202.00 (+1%)
Variable cost per unit $128.00 $129.28 (+1%) $128.00
Fixed cost $19.20M $19.20M $19.584M (+2%)
Result Base Downside Upside
Revenue $80.000M $75.240M $84.032M
Variable cost $51.200M $49.126M $53.248M
Contribution $28.800M $26.114M $30.784M
Fixed cost $19.200M $19.200M $19.584M
EBITDA $9.600M $6.914M $11.200M
Leverage ($36.0M debt) 3.75x 5.21x 3.21x

The downside moves EBITDA by −$2.686M and breaches the 4.0x test by a wide margin. The upside adds $1.6M after a 2% increase in fixed cost to support the extra volume.

Management actions. The team identifies a fixed-cost action worth $0.8M a year, taking effect in about two quarters. Applied to the downside, EBITDA rises to $7.714M and leverage falls to 4.67x. That is still above 4.0x. The conclusion is useful: the planned action alone does not rescue the downside, so the plan needs earlier triggers, a conversation with the lender before a test date arrives, and possibly a larger or faster lever.

Triggers. Two consecutive months of order intake at or below the downside run-rate (380,000 units annualized) trigger three actions, each with an owner and an approver: the fixed-cost action goes to the CEO for approval, the CFO opens a conversation with the lender, and the head of sales reviews price discipline, since price is the most powerful single driver. Lead times are written next to each.

What the example shows. A 2.1% volume decline is enough to breach, which is not obvious from a three-case table alone. Single-driver sensitivities and the reverse stress test are what make a covenant risk visible before it arrives.

AI prompt assistance

AI can help build and check models, but it will produce plausible arithmetic that is wrong unless you verify it. Supply the data and check every figure.

1. Build the driver table from history.

I will paste four quarters of revenue, units sold, and cost of goods by category. Rebuild revenue as units × average price and variable cost as units × cost per unit, and show whether the result reproduces the reported figures. List every line that does not tie, with the difference.

Check: tie totals to the ledger, and ask the controller to confirm the cost classification.

2. Propose driver moves for a downside.

Here is our driver register with historical ranges. Propose a downside setting that combines moves of the kind we have seen in the past, citing the specific historical period for each. Do not use ranges from outside the data I provided.

Check: the proposal is a draft for management to challenge, and each range must be defensible from your own records.

3. Audit the model arithmetic.

Here is my scenario table with drivers and results. Recompute revenue, variable cost, contribution, EBITDA, and leverage for each scenario and list any discrepancy with the working.

Check: independently recompute one scenario in a spreadsheet.

Implementation guide

Phase Weeks Owner Exit criteria
Rebuild from drivers 1-3 FP&A / Controller Historical P&L reproduced from drivers within tolerance; cost behavior table agreed
Base and sensitivities 4 FP&A Base case; single-driver sensitivity ranking
Scenarios and constraints 5-6 CFO / CEO Downside and upside settings; covenant and liquidity headroom; break-points
Actions and triggers 7-8 CEO / COO Action menu with lead times; trigger table with owners and approvers
Operate Ongoing CFO Monthly driver actuals; quarterly reforecast; trigger review in the monthly meeting

Governance. The CFO owns the model and its integrity. Each driver has an owner who can explain movements. The CEO owns the triggers and approves the actions. If lenders or a board are involved, agree in advance when the scenario outputs will be shared and how they are defined, since agreement definitions rule.

Downloadable assets

The driver register, cost behavior table, scenario summary, and trigger table above are copy-ready into a spreadsheet, and the base-case table in the worked example can be reproduced with a few formulas. For cash scenarios, the 13-week cash flow builder is the nearest existing tool, and the covenant headroom calculator tests the covenant side.

Related resources

Frequently asked questions

What is a driver-based model?

A driver-based model builds the financial statements from a small set of operating drivers, such as volume, price, unit cost, and fixed cost, rather than forecasting each line separately. Changing a driver recalculates the results. This makes scenarios simple to define, easy to update, and traceable to the assumptions behind them.

How many scenarios do you need?

You need a base, a plausible downside, and a plausible upside, plus single-driver sensitivities and a reverse stress test. More scenarios rarely add insight. The sensitivities show which drivers matter, and the reverse stress test shows how far the most important driver can move before a covenant or liquidity floor is breached.

How do you pick the drivers?

Pick five to eight drivers that move EBITDA materially, can be observed early, and have a named owner. Check by back-testing: if the driver model cannot reproduce last year's results within a tolerance you set, a driver is missing or a cost is classified incorrectly. Add only what the back-test shows you need.

What is a reverse stress test?

A reverse stress test asks how far a driver must move before a specific limit is breached, rather than asking what happens under a given move. Divide the headroom by the EBITDA effect of a 1% change in the driver. The result is the percentage movement that uses up the cushion, which is often smaller than leaders expect.

How often should scenarios be updated?

Update driver actuals monthly and reforecast scenarios at least quarterly, or sooner when a trigger fires or a major contract changes. A scenario model that is not refreshed quickly becomes misleading because it looks authoritative. Tie updates to the monthly performance review so they happen without a special request.

How this works in a System of Performance

A scenario model is only useful if the driver actuals reach it quickly and the triggers get watched. In most companies, driver data sits in the ERP, the CRM, and a few spreadsheets, and the triggers live in a slide. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. To see which of your key drivers you can already trace to source data, bring it to us as a launch partner.

Free template for this topic

Free template · Excel workbook

Driver-Based Scenario Planning Model

A driver-based base, downside and upside model with covenant check, sensitivities and an initiative cascade.

Run this on your own books

Bring the number you want to move.

A guide tells you what to measure. As a launch partner, AI Associates size it, run the fix with your team’s approval, and track what comes in going forward.

Start now →

Related articles