What Is a Driver Tree? A Practical Guide (and the Plug-Node Problem Nobody Names)

A driver tree looks like an org chart for numbers. A top metric (revenue, EBITDA, cash runway) sits at the root, and branches fan out underneath it, each one breaking the number above into the smaller, more controllable pieces that produce it. It is one of the oldest structures in FP&A, and it is also one of the most quietly abused. The diagram is easy to draw. Making every leaf trace back to something real is the part most teams skip.

That gap matters more now than it used to. Once an AI assistant is reading your driver tree and answering “why did revenue miss plan” by walking down the branches, a tree with even one fabricated leaf will produce a fluent, confident, wrong answer, and nothing in the interface will tell you which branch to distrust.

What a driver tree actually is

A driver tree decomposes a headline metric into the factors that mathematically produce it, layer by layer, until you reach numbers a team can directly act on. Revenue might break into new revenue plus expansion minus churn. New revenue might break into leads times conversion rate times average deal size. Each branch is a real equation, not a loose narrative: the parent node’s value must equal some defined function of its children’s values.

That equation requirement is what separates a driver tree from a mood board of KPIs on a dashboard. A metrics dashboard shows you numbers side by side and lets you infer a relationship. A driver tree asserts the relationship: this number is calculated from those numbers, by this formula, always. If the formula doesn’t hold, if revenue on the dashboard and revenue computed from the branches disagree, the tree is broken, not just imprecise.

The payoff of getting this right is diagnostic speed. When a metric moves, you don’t ask “why” in the abstract. You walk the tree, compare actual to plan at each node, and the branch that deviates most tells you where the story lives. That’s the entire pitch behind KPI variance analysis done well: variance isn’t interesting at the top of the tree, it’s interesting at the leaf where it originated.

Building one: top-down structure, bottom-up data

Design the tree top-down. Start with the metric you actually care about (usually the one that shows up in the board deck or the covenant test) and ask what it’s mathematically composed of. Keep decomposing each node the same way until you hit a leaf that is either (a) a raw, sourced number, like headcount or units shipped, or (b) a rate derived directly from two sourced numbers, like conversion percentage.

A simple SaaS revenue tree might look like this:

Level	Node	Formula
Root	Net new ARR	New ARR + Expansion ARR − Churned ARR
Branch	New ARR	New logos × Average deal size
Branch	New logos	Qualified leads × Close rate
Leaf	Qualified leads	Sourced from CRM, actual count
Leaf	Close rate	Closed-won ÷ qualified leads, sourced from CRM
Branch	Churned ARR	Beginning ARR × Gross churn rate
Leaf	Beginning ARR	Sourced from prior-period reconciled actuals
Leaf	Gross churn rate	Cancelled ARR ÷ beginning ARR, sourced from billing system

Notice the pattern: every leaf either comes from a system of record or is a ratio of two numbers that do. Nothing at the bottom is typed in because it “felt about right.” That’s not a stylistic preference: it’s the entire point of the exercise. A driver tree that can’t be traced to source data is just an org chart with numbers in the boxes.

Build the data plumbing in the other direction, bottom-up. Before you wire a leaf into the tree, confirm it reconciles: does “qualified leads” in this month’s tree match the CRM export for this month, to the transaction? If a driver tree is fed by driver-based forecasting built on deterministic math, every recalculation should reproduce the same leaf values from the same source data, every time: no silent rounding, no cached number quietly going stale two quarters later.

The plug-node problem

Here is the failure mode that gets left out of most driver-tree explainers, and it’s the one that actually breaks trees in practice: the plug node.

A plug node is a leaf that exists to make the arithmetic balance rather than to represent a real, measured driver. It shows up in a few disguises. Sometimes it’s an “other adjustments” line that absorbs whatever gap is left after the real drivers are totaled. Sometimes it’s a manually typed override: someone hard-codes a number into a cell because the automated feed was wrong or late, and the override outlives the reason it was added. Sometimes it’s subtler: a rate assumption (“we’ll assume 22% close rate going forward”) that was reasonable as a planning input but gets left in the tree long after actuals should have replaced it.

The reason this matters more than a rounding error is that a driver tree’s whole value proposition is traceability. The moment one leaf is a plug, you’ve lost the property that made the tree worth building. You can no longer say “this number is provably derived from source data”: you can only say “this number is derived from source data, except for the parts that aren’t, and we’re not always sure which parts those are.” An AI narrating variance off that tree will attribute the plug’s movement to whatever branch it sits under, with full confidence, because nothing in the structure distinguishes a sourced leaf from an invented one.

The fix isn’t a policy reminding people not to do this. It’s a structural rule: every leaf node must carry a source reference (the ledger entry, the CRM record, the reconciled actual it was computed from), and any node without one should be visibly flagged as unverified rather than silently rendered like the rest of the tree. That’s a modeling-layer requirement, not a spreadsheet-hygiene tip, because spreadsheets have no native way to distinguish a formula cell fed by a live link from one fed by a value someone typed over it last quarter.

Driver trees, scenarios, and where “what-if” belongs

A driver tree also gives you the natural surface for scenario work. Because each leaf is an explicit, named input, you can ask “what if close rate drops to 18%” and watch the change propagate up through every branch to the root, instead of hunting through a spreadsheet for every cell that references the old assumption. That’s the mechanism behind what-if driver modeling: a scenario is just the same tree recalculated with one or more leaves swapped, not a parallel tree someone builds from scratch and hopes stays consistent with the base case.

This is also where the plug-node problem resurfaces in a new shape. If a scenario changes a leaf that turns out to be a plug rather than a real driver, the “what-if” answer is meaningless: you’re not testing a real lever, you’re testing a number someone invented. Scenario tools built on top of an ungoverned tree inherit that risk silently.

The takeaway

A driver tree is a genuinely useful structure: it turns “why did the number move” from a research project into a two-minute walk down a branch. But it earns that usefulness only if every leaf is honest: sourced, reconciled, and labeled when it isn’t. A tree with a plug node buried three levels down doesn’t fail loudly. It fails by quietly telling a confident, wrong story about your business, and an AI reading that tree will repeat the story without knowing it’s wrong.

If you’re evaluating a tool that builds or narrates driver trees, ask it one question: for any given leaf, can it show you the source transaction, or is that leaf a typed-in assumption wearing a formula’s clothes? Book a demo to see how rexfin keeps every leaf traceable to a reconciled actual, with nowhere for a plug node to hide.