What driver-based planning actually means

"Driver-based planning" is one of those phrases that gets tossed around in FP&A circles without a clear definition. Here's what it actually means in practice.

A driver is any non-monetary input that, when changed, recomputes a downstream financial line. Headcount is a driver. Units sold is a driver. Bill rate is a driver. They're the things you control or assume; everything else (salaries, revenue, COGS) is computed from them.

In NashOS, you mark an account as a driver by setting isDriver=true and giving it a unit of measure (FTE, units, %, hours). That's it. Now anywhere in the cube, you can write a member formula like:

SALARIES_ENG = HEADCOUNT_ENG × −10000

(Negative because we store expenses as negative numbers — sign convention.) When you change HEADCOUNT_ENG from 12 to 15, the formula recomputes SALARIES_ENG, which rolls up into OPEX, which rolls into EBITDA, which rolls into Net Income. Three days of model-rework collapses to a single edit.

The pattern compounds. Stack drivers: HEADCOUNT_ENG × LOADED_COST × INFLATION_FACTOR. Add scenario-specific overrides: one formula for SALARIES_ENG under scenario=BUDGET, another under scenario=STRETCH. Mix in time-shifts: PRIOR(REV_ACTUAL) × 1.05 for a 5% growth plan.

The thing nobody tells you: driver-based planning isn't about modeling sophistication. It's about reducing the surface area where humans make mistakes. Every cell you compute is a cell nobody can mistype. Every scenario is a configuration change, not a copy-paste of a 200-row tab.