How to Enter Drivers
This article explains how to enter driver values in Model Reef input fields.
You will learn:
Where to set values for drivers.
How driver series differ from variables.
How driver changes propagate to dependent variables.
Drivers are reusable time series, used as inputs in formulas and presets rather than directly hitting financial statements.
1. Where to edit drivers
You enter driver values in:
The Driver Editor screen, which shows the driver time series.
Sometimes in the Data Library viewer, when editing a driver type entry.
Occasional summary fields that feed driver presets or patterns.
Drivers are usually model-wide assumptions rather than branch-specific line items.
2. Types of driver inputs
You can normally enter driver values as:
Direct numeric values per period.
Base values plus growth rates per period.
Seasonal patterns or indices.
Imported series (for example from CSV or external data sources) which you can then adjust.
For simple drivers, typing direct values per period is enough. For more complex patterns, presets or imports are often used first.
Editing driver series
4. Drivers versus variables
Key differences between drivers and variables:
Drivers do not directly create P&L, Balance Sheet or Cashflow entries.
Drivers only affect financial statements through variables that reference them.
Drivers tend to represent assumptions (prices, volumes, growth rates) rather than accounting lines.
You use drivers in formulas such as:
Revenue = Volume driver × Price driver
Costs = Base cost × Inflation driver
5. Scenario specific behaviour
Each scenario model has its own copy of drivers:
Editing a driver in one scenario does not affect the same driver in another scenario model.
You can create different growth, price or utilisation assumptions per scenario by editing the relevant driver series.
This is central to scenario analysis and planning workflows.
6. Validation and driver sanity checks
Model Reef may highlight driver values that:
Jump sharply between periods.
Fall outside configured bounds.
Differ significantly from historical patterns (if any).
Good practices:
Sanity check time series visually.
Use notes to document why unusual driver shapes are correct.
Avoid hard coding volatile assumptions in many places. Centralise them in a small number of drivers instead.
Related articles
Last updated