Driver-based planning automation with AI

A driver-based plan expresses each output as a formula over operational inputs, so revenue is headcount times ramp times attainment rather than twelve typed-in numbers. Automating it means wiring those drivers to actuals as they post, recomputing the plan when a driver moves, and letting a model propose and explain values without letting it invent the structure. The spreadsheet stops being the plan and becomes a view of it.

Most planning models are not really driver-based, whatever the deck says. They start driver-based in the first tab and degrade into hard-codes by the third, because someone needed a number to tie out before a board meeting and never went back. That decay is the actual problem. A model where half the cells are formulas and half are overrides typed in during quarter-end cannot update itself, and it cannot survive a backtest, because the causal chain was cut the moment the override landed. Ask it why a variance happened and it has nothing to say.

A plan is a graph of drivers, so store it as one

The first piece of engineering has nothing to do with AI. It is representing the plan as a dependency graph rather than a grid of cells. Each node is a driver or an output; each edge is a formula. Headcount feeds capacity, capacity and attainment feed bookings, bookings and terms feed billings, billings feed cash. Once the plan is a graph, a change to one driver recomputes exactly the nodes downstream of it and nothing else.

That representation buys several things a spreadsheet cannot give you:

• Lineage from any output back to the drivers that produced it, so a flagged number has a traceable path rather than a fog of nested cell references
• Point-in-time correctness, because each driver carries the value that was known as of a given date, and a backtest reads the graph as it stood then
• Overrides that are explicit nodes with an owner and a reason, not silent replacements of a formula, so you can see every place a human overrode the machine and why

The overrides matter more than they look. Every real plan has them, and the honest move is to model them as first-class objects instead of pretending they do not exist. An override with a name attached is a decision you can review at the next cycle. An override typed over a formula is a landmine.

Wire drivers to actuals, then let the plan recompute

A rolling forecast is only rolling if actuals flow into it without a human re-keying them. The plumbing here is the same discipline as the close. A posted GL line has to map to the driver it belongs to, and that mapping is where most FP&A automation quietly breaks, because the chart of accounts and the driver tree were designed by different people at different times.

We build the mapping as a maintained artifact with its own tests, not a lookup someone edits under deadline. Each driver reconciles back to the ledger on the close cadence, so the forecast and the close never report two versions of last month. When a chart-of-accounts change lands, the mapping tests fail loudly instead of routing revenue into the wrong node for a quarter before anyone notices.

This is where a model starts earning its place. Given the driver graph and clean actuals, it can propose next-period driver values from history and seasonality, flag drivers that have drifted from their assumed trajectory, and draft the variance commentary. The rule we hold to is that the arithmetic happens before the language. The model receives a decomposed variance already attributed to drivers by the pipeline, and its job is to phrase what the decomposition shows: which driver, how much of the gap it explains, and what residual is left unaccounted. It does not narrate causes it has not been handed. A fluent explanation with the wrong driver in it is worse than no explanation, because someone will act on it.

Scenarios are edits to the graph, not new spreadsheets

Scenario planning falls out of the graph representation almost for free, which is the point of building it that way. A scenario is a set of overrides on driver nodes: hiring freezes in Q3, attainment down ten points, a price change on one product line. Because the plan recomputes deterministically from drivers, you can hold twenty scenarios as twenty override sets against one model rather than twenty copied files that diverge the moment anyone touches the base.

• Each scenario names the drivers it changes and inherits everything else from the base, so a fix to a base formula propagates to every scenario at once instead of being re-applied twenty times
• Scenarios are diffable, so you can show a board exactly which drivers separate the downside case from the plan, in numbers, not adjectives
• A model can generate candidate scenarios from a stated shock and then be checked against the graph, which is safe precisely because it edits driver values and cannot rewrite the structural formulas underneath

The failure mode to watch is the model proposing a structural relationship rather than a value. Suggesting that attainment should be 82 percent next quarter is a value question, and it is fair game. Suggesting that attainment now depends on marketing spend when the graph never wired that edge is a structural claim, and structural claims from a model get proposed to a human, never auto-applied. One wrong edge propagates silently through every scenario and every downstream output, and you find it three cycles later when the numbers stopped meaning anything.

Build the graph first. Wire the drivers to reconciled actuals. Let the model propose and explain at the edges, hold the structure under human control, and the plan updates as reality does instead of the week before the board meets.