Use case · Driver-based planning
Drivers move the plan. You decide which, where, and when.
Driver-based planning in Cube ties budgets and forecasts to the drivers that move them. Every driver can be global or scenario-specific, so each what-if runs on exactly the assumptions you choose.
The problem
The plan breaks the moment a driver moves.
Every finance leader knows the model that only one person can safely touch.
Buried assumptions
Growth rates and ratios sit hardcoded in cells, so nobody can say which assumptions actually drive the plan.
Stale actuals
The model runs on last month's export, so every driver conversation starts with whether the numbers are current.
One change, ten tabs
Update a single driver and you re-key it across every tab, version, and department file by hand.
One governed model
How driver-based planning works in Cube
Actuals and operational data flow in from hundreds of source systems, your driver logic lives in one governed model, and every surface your team plans in stays current.
Cube
The Agentic Finance Layer holds your drivers, actuals, and every plan version in one governed model.
Inside the model
Your drivers and your formulas, in plain language.
Both live in the model where finance edits them directly. A driver can apply to every scenario or just one.
The proof
Your driver model, on live actuals.
Fetch actuals against every driver, adjust the plan, and publish versions back to one governed model.
| Revenue drivers | Feb · Actuals | Mar · Actuals | Apr · Plan | May · Plan | Jun · Plan |
|---|---|---|---|---|---|
| New sales reps | 11 | 12 | 14 | 15 | 16 |
| Pipeline per rep ($K) | 360 | 360 | 360 | 360 | 360 |
| Win rate | 25% | 25% | 25% | 25% | 25% |
| New pipeline ($K) | 3,960 | 4,320 | 5,040 | 5,400 | 5,760 |
| New ARR ($K) | 990 | 1,080 | 1,260 | 1,350 | 1,440 |
Charted
One driver, two curves.
Rep count moves pipeline, pipeline moves ARR. The chart reads straight from the driver grid above.
Why teams choose Cube
Every what-if flows through the whole plan.
Driver-based planning and scenario planning run on one model, so any assumption can flow through everywhere.
One model, no module walls
Legacy tools split planning into modules. Cube is one model, so a driver change flows through revenue, headcount, opex, and cash together.
Drivers, scenario by scenario
Apply a driver to every scenario or pin it to just one, so each what-if runs on exactly the assumptions you choose.
Scenario planning, governed
Every what-if traces to the source transactions behind it, and user-based access controls decide who sees each scenario.
Adoption
Easy to adopt, hard to outgrow.
Cube deploys alongside the stack you run today, and your team stays in control.
Finance-led setup
Configured by your team, guided by ours.
of sources
Hundreds of source systems, with pre-built connectors for major platforms.
Rip-and-replace
Your ERP, CRM, and spreadsheets stay where they are.
Onboarding
Hands-on setup with a named contact.
FP&Agents at work
Agents that keep the driver model honest.
Cube's FP&Agents watch the drivers, the actuals, and the logic that connects them.
Analyst
Ask why New ARR moved and get the driver, the math, and the trace behind it.
Planner
Drafts scenario versions from driver changes and keeps every version comparable.
Data Manager
Keeps actuals and driver data flowing from your source systems into the model.
Q2 sales hires: 2
Q2 sales hires: 4
Q2 sales hires: 6
One driver changed. Everything downstream recalculates.
Where you work
One model, on every surface.
Cube delivers the same governed numbers wherever the work happens. Explore the full story on Where You Work.
Cube Workspace
The browser app where finance builds the model, sets permissions, and publishes.
Excel & Google Sheets
Bi-directional sync: fetch live actuals into the sheet, publish plans back.
AI assistants via MCP
Claude, ChatGPT, and Gemini answer from your governed numbers.
Slack & Teams
Ask a question in chat and get the governed figure back, with the trace.
PowerPoint & Google Slides
Decks with figures bound to Cube that refresh to the current numbers.
BI tools
Tableau, Looker, and Power BI read from the same model as the plan.
Security & governance
Governed enough for the numbers that matter.
The short version is below; the full picture lives on Cube's security overview.
Read-only by default
Cube reads from your source systems and never writes back to them.
Version history
Every plan version and driver change is logged and recoverable.
Permissions by role and dimension
Department owners see their drivers; finance governs the whole model.
Trace to the source
Any figure drills to the accounts and transactions behind it.
Already convinced?
Book a demo and see your drivers recalculate on your own data. Still researching? The complete guide to driver-based planning continues below.
The definition
What is driver-based planning?
Driver-based planning
Driver-based planning is a financial planning method that builds budgets and forecasts on the operational drivers that cause financial outcomes, such as sales headcount, win rates, pricing, and utilization.
Instead of projecting each line item from its own history, finance models the relationships between drivers and results, so when a driver changes, every dependent revenue, expense, and cash figure recalculates.
Cube keeps that driver logic in one governed model on the platform finance teams already trust, connected to the spreadsheets your team runs every day.
Operational drivers
Financial outcomes
The hard part
Why is driver-based planning difficult?
The method is simple on a whiteboard; keeping it alive against real data is where most teams stall.
Finding the real drivers
Teams guess at what moves the numbers. Cube tests driver assumptions against live actuals, so the model keeps only the inputs that earn their place.
Spreadsheet fragility
One broken formula silently corrupts the plan. In Cube, driver logic lives in a governed model that spreadsheets read from and publish to.
Stale actuals
Manual exports age the moment they land. Cube fetches actuals live from your ERP, CRM, and HRIS, so drivers are always tested against current numbers.
Version chaos
Nobody knows which file holds the current plan. Cube keeps every version in one place, with history, so comparisons are always like for like.
Cross-functional inputs
Sales and people data live outside finance. Cube brings CRM and HRIS drivers into the same model as the financials.
Logic drift
Driver relationships go stale as the business changes. Cube's FP&Agents flag drivers that stop explaining the movement in actuals.
Side by side
Manual vs automated driver-based planning
The method is the same; the difference is how much of your team's time it consumes.
| Manual spreadsheets | Driver-based planning in Cube | |
|---|---|---|
| Actuals refresh | ✗Exported and pasted by hand each cycle | ✓Fetched live from your source systems |
| Driver updates | ✗Re-keyed across every tab and file | ✓Changed once, recalculated everywhere |
| Scenarios | ✗Copies of the workbook that drift apart | ✓Versions of one model, compared side by side |
| Cross-functional inputs | ✗Emailed spreadsheets from sales and HR | ✓CRM and HRIS data in the same model |
| Audit trail | ✗Whoever remembers what changed | ✓Every change logged and traceable to the source |
The landscape
What are the main types of driver-based plans?
Most teams start with one driver family and expand from there, because the model is the same underneath.
Revenue drivers
Pipeline, reps, win rates, pricing, and retention build the top line. See how teams run revenue planning and forecasting in Cube.
Headcount drivers
Hires, ramp, comp, and attrition drive the largest cost line in most plans and feed every department budget.
Cost and unit-economics drivers
Usage, unit costs, and utilization shape spend and cash. The same logic powers cash flow forecasting and capex planning.
Field notes
Driver-based planning best practices
These hold whatever software you run.
Start with a few drivers
Five to ten drivers that explain most of the movement beat fifty that explain everything poorly.
Give every driver an owner
Each driver needs a named business owner who commits to its value in the plan.
Test drivers against actuals
A driver is a hypothesis; retire the ones whose movement stops predicting outcomes.
Plan in scenario ranges
Model downside, base, and upside on the same drivers so debates stay about assumptions.
Revisit the driver map on a cadence
Review it every planning cycle, because business models change faster than planning models.
The checklist
What to look for in driver-based planning software
Whatever vendor you evaluate, hold them to these six rows.
Live source connections
Actuals should flow from your ERP, CRM, and HRIS without manual exports.
Spreadsheet compatibility
Your Excel and Google Sheets models should keep working, connected to the platform.
One governed model
Drivers, actuals, and versions in a single place with permissions and history.
Scenario versioning
Changing a driver should produce a comparable version, never another file.
Traceability
Any planned or actual figure should trace to the source transactions behind it.
AI with governance
Agents can maintain driver logic and explain movement, and finance approves every change.
One driver changes. The whole plan follows.
Book a demo and watch your own drivers recalculate on live actuals, traced to the source.
Book a demoWe will build the demo around your use case and your source systems.
