Blog » Strategy
Cascading Targets in a KPI Tree: Percent Does Not Divide
· 12 min read
Cascading targets in a KPI tree: 12 percent on every driver asks for 12 percent more revenue than the board approved.
Every Driver Owner Missed and the Plan Landed on Target
A revenue tree with two children is the simplest object in planning, and it is where most cascaded targets break.
Take a year that opened at 24,000,000 dollars of revenue, 8,000 accounts and 3,000 dollars of revenue per account. The board approved a 12 percent target, so 26,880,000 dollars. Finance cascaded the 12 percent down one level and published two node targets: 8,960 accounts and 3,360 dollars per account.
The year closed at 8,480 accounts and 3,170 dollars per account. The account owner finished 480 logos short, 5.36 percent under target. The pricing owner finished 190 dollars short, 5.65 percent under. Revenue came in at 26,881,600 dollars, which beat the approved figure by 1,600.
Every number in that paragraph reconciles. Two owners failed against their published targets and the company delivered the plan, because the published targets were never the plan.
What Does It Mean to Cascade Targets Down a KPI Tree?
Cascading targets means converting one approved target on a parent node into targets on the child nodes that produce it, so every driver has an owner and a number. In kpitree.io the parent to child relationship is arithmetic, which is what makes a cascade checkable: the child targets either reconcile to the parent target under the node's identity, or they do not.
Driver based planning builds the plan from operational quantities rather than from last year's line items. It is an established practice, benchmarked by the Association for Financial Professionals in its 2026 FP&A survey work¹ and tracked across the annual FP&A Trends surveys.² A KPI tree is the structure that makes those drivers explicit.
The cascade is the step after the tree exists. The tree already states that revenue equals accounts multiplied by revenue per account. The cascade decides what each of those two owners is held to.
That step is where the arithmetic is usually abandoned. The tree is built from identities, and then targets are allocated by percentage, which is not an operation those identities support. A driver based plan and a driver tree answer different questions, and a target set sits between them.
Why Does a 12 Percent Target Not Mean 12 Percent on Every Driver?
Because a multiplicative node multiplies its children. Give both children of a two factor node 12 percent and their product grows 25.44 percent, not 12. The two node targets then imply revenue exactly 12 percent above the revenue target the board approved. Each additional factor multiplies that error again rather than adding to it.
The general form is short. For a parent that is the product of n children, cascading growth g to every child implies a parent factor of one plus g raised to the power n, against an approved factor of one plus g. The ratio between them is one plus g raised to the power n minus one.
At 12 percent that is 12 percent too much on two factors, 25.44 percent on three and 40.49 percent on four. A sessions, conversion rate and order value tree is three factors, so a 12 percent revenue target cascaded as written asks for 33,718,272 dollars against an approved 26,880,000, a gap of 6,838,272 before anyone has argued about a single assumption.
Growth across a product node adds in logarithms, not in percentages. An equal split gives each child the nth root of the parent factor: 5.83 percent each on two factors, 3.85 percent on three, 2.87 percent on four. Those are the figures that multiply back to 12.
Three Ways to Split a Parent Target
Only three methods are worth using, and the choice is not a matter of taste. It depends on whether the node is multiplicative or additive, and on whether the children have equal headroom.
Uniform percentage is the default in most planning cycles because it is fast and it looks fair. It is correct on a sum node and wrong on every product node.
Equal logarithmic split is correct on a product node and treats every child as equally movable, which is almost never true. It is an opening position, not an answer.
Feasibility weighting is the only method that produces targets anyone can hit. It fixes the children that cannot move, then solves for the ones that can. If revenue per account can rise only 2 percent because most of the book sits on contracted pricing, accounts must carry 9.80 percent, since 1.02 multiplied by 1.0980 is 1.12.
| Method | Product node | Sum node | Use it when |
|---|---|---|---|
| Uniform percentage | Overshoots by one plus g to the power n minus one; 12 percent on two factors implies 25.44 | Correct; the child percentages sum back to the parent | Never on a product node, and on a sum node only when children have equal headroom |
| Equal logarithmic split | Correct; each child takes the nth root, 5.83 percent for two factors at 12 | Not applicable | As an opening position, before any constraint has been stated |
| Feasibility weighting | Correct; fix the constrained children, then solve for the rest | Correct; allocate the absolute gap by headroom rather than by current size | Every target set that gets published |
Sum Nodes Split Cleanly and Still Allocate Badly
A sum node has no overshoot problem. Give four segments 5 percent each and the total grows 5 percent. The arithmetic is sound and the allocation is still usually wrong.
Take the feasible cascade: accounts rise 5 percent to 8,400 and revenue per account rises 6.67 percent to 3,200, and 8,400 multiplied by 3,200 is 26,880,000 exactly.
The account target is 400 new logos. Four segments carry it, opening at enterprise 800, mid market 2,000, SMB 4,400 and self serve 800. A uniform 5 percent assigns 40, 100, 220 and 40.
Enterprise cannot deliver 40. Its serviceable list holds 60 unworked logos and its historical win rate is 20 percent, so 12 is the figure capacity supports. The other 28 have to go somewhere, and self serve is the only segment with no rep constraint, so it takes 68 rather than 40.
A uniform percentage allocates the absolute burden in proportion to current size. Current size is a fact about history. Headroom is a fact about next year.
The Mix Drag Nobody Budgeted
Reassigning those 28 logos is not free, because the four segments do not carry the same revenue per account.
Enterprise runs 12,000 dollars, mid market 4,200, SMB 1,250 and self serve 625. Those four rates against the opening counts produce 24,000,000 dollars and a blended 3,000.
Hold every segment rate flat and apply the capacity cascade. Enterprise reaches 812, mid market 2,100, SMB 4,620 and self serve 868, which is 8,400 accounts and 24,881,500 dollars. Blended revenue per account is 2,962.08.
The sibling node's target was 3,200.00. Hitting the account target in the only way capacity allows moves the blended figure 37.92 dollars in the wrong direction, before a single price has been negotiated.
Run it forward. Reaching 26,880,000 from 24,881,500 needs 8.03 percent of within segment pricing, against the 6.67 percent the cascade asked for. The mix shift added 1.37 points to the pricing owner's year and no document records it. It is the same mix term a price, volume and mix bridge isolates after the fact, arriving a year early.
The account target and the revenue per account target were set independently. The only feasible way to hit the first makes the second 1.37 points harder, and both owners were told their numbers were consistent.
What Happens When a Target Lands on a Ratio Node?
A ratio node has two routes to improvement and one of them is destructive. A 3.2 percent conversion rate target is met by winning more orders or by cutting sessions, and cutting sessions is cheaper. Target the numerator and the denominator as separate columns, or attach a floor to the denominator.
This is a structural property of derived nodes rather than a failure of character. kpitree.io computes a rate by dividing two summable columns, so both columns stay visible underneath the rate, which is what a target set needs.
Three rules follow.
- Never publish a ratio target alone. Publish it with a target or a floor on the denominator, so the only route to the rate runs through the numerator.
- Never publish a target on a parent and on its children independently. Two owners then book the same growth twice and the plan totals more than the tree supports. The reconciliation is the same residual check the MECE tests run on actuals, pointed forward.
- Never set a ratio target by averaging the children's ratios. A blended rate is weighted by its denominator, so the average of the segment rates is not the figure the business has to hit.
Targets Move People, Which Is the Whole Problem
The arithmetic above treats a target as a number. It is also an instruction to a person, and the evidence on that is older than any planning tool.
Specific and difficult goals outperform vague ones, conditional on commitment and on feedback the person can act on, which Locke and Latham established across four decades of studies and summarized in American Psychologist in 2002.³ A cascaded node target is specific, which is the point of cascading it.
That same specificity has documented side effects. Ordóñez, Schweitzer, Galinsky and Bazerman cataloged them in 2009: narrow goals pull effort toward what is measured and away from what is not, and they raise the incentive to misreport.⁴ Jensen made the financial version of the argument in 2001, that tying pay to a budget target gives managers a reason to manage the number rather than the business.⁵
Lean practice reached the operational answer first. Strategy deployment, known as hoshin kanri, moves targets through catchball, an iterative exchange in which each level negotiates a target against what it can do before accepting it.⁶ Arithmetic decides what is consistent. Catchball decides what is owned.
Five Tests Before You Publish a Cascaded Target Set
- Product test. Multiply the child targets of every product node and confirm the result equals the parent target rather than something above it. This one test catches the overshoot every time.
- Sum test. Add the child targets of every sum node and confirm they equal the parent target, rounding residual included, and that the residual belongs to a named child.
- Headroom test. For each child, state the constraint that caps it and the evidence behind the cap. A target with no stated constraint is a wish with a decimal point.
- Mix test. Hold every rate flat, apply only the volume targets, and read what happens to each blended rate in the tree. Any movement is a drag or a tailwind that belongs in the rate owner's target before publication.
- Single owner test. Confirm no quantity is targeted twice, once at a parent and once at a child. Rerun both tests after any late change, because a revision to one node quietly breaks them.
Run test 4 last and expect it to move numbers. It is the one that usually does.
Where Target Cascading Is the Wrong Instrument
Four situations defeat the method.
Step changes. A cascade spreads a continuous target across existing drivers. A new market, a new product line or an acquisition is a new node, not a percentage on an old one. Model it separately and add it to the parent.
Targets below the noise floor. A segment with 40 accounts has a conversion rate that swings on two deals. Cascading a 0.3 point target into it produces a figure that cannot be told apart from variance in either direction.
Drivers with long lead times. Price realization and churn land across quarters while volume lands in weeks. A cascade carrying a number and no date asks a rate owner to deliver in the first quarter what the contract book releases in the fourth.
Compensation already fixed against the published set. Repairing an inconsistent cascade mid year while pay depends on those numbers reproduces the gaming problem rather than solving it.⁵
The first three are fixable before publication. The fourth is the argument for running the five tests before targets are signed rather than after.
Building the Cascade in kpitree.io
kpitree.io builds the tree this cascade runs on from one uploaded CSV. The file needs one row per segment per period and the summable columns that sit underneath every rate: accounts, revenue, and whatever counts the lower nodes divide.
Inside the tree, parent to child relationships are addition and subtraction, so a sum node is a real arithmetic identity rather than a layout choice, and the product test and the sum test have something to test against. Every rate is a derived node that divides two summed columns at the level being read, which is why blended revenue per account recomputes to 2,962.08 when the segment counts move and no segment rate changes. That recomputation is the mix test, done by the structure instead of by hand.
The arithmetic is where the help ends. The tree computes the identities and shows what a proposed target set implies. It does not know which segment has headroom, and it will not negotiate with the enterprise team.
CSV upload is the evidenced ingest path today. The smallest useful version is eight rows: four segments across two periods, with counts and dollars.
Frequently Asked Questions
How do I split a parent target across a product node? Take the nth root of the parent factor, then move weight toward the children with headroom while keeping the product equal to the parent factor. Check by multiplying, every time.
Is a uniform percentage cascade ever correct? On a sum node whose children have equal headroom, yes. On a product node, no, at any growth rate other than zero.
Should every node in the tree carry a target? No. Target the leaves and the nodes with named owners. A parent target plus independent child targets counts the same growth twice.
What happens to a cascade when the tree is regrouped? Nothing, provided the targets were set on summable columns. A target stored as a rate cannot be regrouped, which is the same reason the tree stores counts and dollars rather than a stored ratio.
How do I handle the rounding residual on a sum node? Assign it to one named child before publication. A residual left unassigned returns as a reconciliation failure in the first review.
Closing: Cascade the Dollars, Not the Percent
A percentage is not a quantity, and a tree is made of quantities. That is the whole of it.
Convert the approved target into an absolute figure at the root. Push absolute figures down, splitting a product node in logarithms and a sum node by headroom. Convert back to percentages at the end, for the people who prefer to read them, and never cascade the percentage itself.
Then run the five tests. The product test and the sum test take minutes and catch the arithmetic. The mix test takes longer and is the one that finds the 1.37 points of pricing nobody put in anyone's target.
Done that way, a year where both owners miss and the company still lands the plan stops being a story about execution. It becomes what it always was, a target set that asked two people for 30,105,600 dollars while the board had approved 26,880,000.
Upload one CSV with your segments and two periods, and check whether this year's target set multiplies back to the number your board approved.