Blog » Root Cause Analysis
Cost to Serve Analysis in a KPI Tree: Pick the Driver
· 12 min read
Cost to serve analysis in a KPI tree: a revenue allocation reported 500,000 dollars of contribution for both customers. Driver allocation reported 890,000 and 110,000.
The Customer With the Lower Cost Per Order
Cost to serve analysis in a KPI tree fails for a reason that has nothing to do with arithmetic. The total is almost always right. The split across customers is almost always wrong, and the tree reconciles either way.
Take one quarter and two customers. Both bill 4,000,000 dollars. Both carry 2,800,000 dollars of cost of goods sold, so both post 1,200,000 dollars of gross margin at 30.0 percent. Below that sits 1,400,000 dollars of cost to serve for the two of them together.
Allocate it by revenue and each customer carries 700,000 dollars. Contribution after serving cost is 500,000 each, 12.5 percent of revenue, and the two accounts are indistinguishable.
Allocate the same 1,400,000 by the activities that caused it and Customer A carries 310,000 dollars while Customer B carries 1,090,000. Contribution is 890,000 against 110,000, a ratio of 8.1 to 1.
The total is 1,000,000 dollars under both methods. Only one of them tells you which customer to renegotiate.
What Is Cost to Serve Analysis?
Cost to serve analysis assigns the cost of serving a customer, order or channel to that customer, order or channel using the activities that actually consume the cost, rather than spreading it by revenue or volume. In a kpitree.io tree it sits below gross margin as a set of additive activity pools, each with its own driver.
The method is a narrower relative of activity-based costing, which identifies activities and charges each one to whatever consumed it.² The Institute of Management Accountants publishes implementation guidance covering methodology choice and the level at which analysis should be aggregated,¹ and a separate conceptual framework for choosing a costing approach at all.⁸
Cost to serve keeps that logic and trims the scope. It concerns itself with the cost of transacting, delivering and supporting, not with the cost of making. That narrower frame is what makes it survivable in a quarterly cadence.
The stakes are set by the size of the cost base. US business logistics costs ran 2.4 trillion dollars in the 2026 State of Logistics Report, 7.8 percent of GDP, down from 2.6 trillion and 8.7 percent a year earlier.⁵ ⁶ For most distributors and manufacturers, serving cost is the second largest line on the page and the least attributed.
Build the Additive Layer in Activity Counts and Dollars
A tree that stores cost to serve per order cannot reconcile, because that figure is a quotient and quotients do not sum. Store the counts and the dollars separately.
For the worked quarter the summable columns are revenue, cost of goods sold, and four pool totals: order processing 240,000 dollars, picking and packing 420,000, outbound freight 560,000, and customer service 180,000. Alongside them sit four driver counts: orders, order lines, deliveries and service contacts. One row per customer per period.
Customer A placed 400 orders across 3,600 order lines, took 400 deliveries and opened 120 service contacts. Customer B placed 1,600 orders across 8,400 lines, took 1,600 deliveries and opened 780 contacts. Group totals are 2,000 orders, 12,000 lines, 2,000 deliveries and 900 contacts.
Every rate in the tree is then derived by dividing two summed columns, the same rule that stops a KPI tree in Excel from averaging a stored ratio. Change the grouping and each rate recomputes against its own denominator instead of averaging an average.
Four Pools, Four Rates, One Reconciliation
Divide each pool by its own driver count to get a rate. Order processing runs 120.00 dollars per order. Picking and packing runs 35.00 per order line. Outbound freight runs 280.00 per delivery. Customer service runs 200.00 per contact.
Charge each customer its own consumption. Customer A takes 48,000 dollars of order processing, 126,000 of pick and pack, 112,000 of freight and 24,000 of service, for 310,000. Customer B takes 192,000, 294,000, 448,000 and 156,000, for 1,090,000.
The two sum to 1,400,000 dollars, the pool total, with no residual and no plug. That holds pool by pool, not only in aggregate, which is the property worth testing.
The cause is visible once the counts are on the page. Customer B's average order is 2,500 dollars against Customer A's 10,000. A 280 dollar delivery is 11.2 percent of B's average order and 2.8 percent of A's. Nothing about B's pricing is the problem. Its ordering behavior is.
Why Does a Revenue Allocation Hide an Unprofitable Customer?
Because revenue is not a cost driver. A revenue split charges every customer the same serving cost per dollar billed, which assumes two customers of equal size consume equal activity. When one orders four times as often in quarters the size, the split moves 390,000 dollars of real cost off that customer and onto its neighbor.
The gap decomposes exactly, pool by pool. A revenue split gives Customer B half of each pool: 120,000 dollars of order processing, 210,000 of pick and pack, 280,000 of freight and 90,000 of service.
Against the driver-based charge, each difference is the pool rate multiplied by the driver volume B consumed above its revenue share. Orders: 600 excess orders at 120.00 is 72,000 dollars. Lines: 2,400 excess lines at 35.00 is 84,000. Deliveries: 600 excess deliveries at 280.00 is 168,000. Contacts: 330 excess contacts at 200.00 is 66,000.
Those four terms sum to 390,000 dollars, which is the whole understatement, to the dollar. Customer A's bridge is the same four terms with the sign reversed. It is the volume and rate split used in a price, volume and mix bridge, applied to cost consumption instead of revenue.
Both allocations reconcile to 1,400,000 dollars. A reconciliation cell clears both. The 780,000 dollar spread between the two customers is invisible to every check that tests arithmetic rather than causality.
Which Denominator Should Cost to Serve Use?
The one that matches the decision. Cost to serve per order ranks these two customers backwards, because B's orders are individually cheaper and far more numerous. Per order line and per 1,000 dollars of revenue both rank them correctly. Publish the denominator on the node, because the ranking is a property of the divisor, not of the customer.
The blended figure is 700.00 dollars per order across 2,000 orders. Customer A's actual cost to serve per order is 775.00, 13.8 percent above the blend. Customer B's is 681.25, below it. A dashboard sorted by cost to serve per order puts the profitable account at the top of the problem list.
The spread in the underlying benchmarks is wide enough that this matters outside the example. APQC's procurement data shows organizations spending from roughly 14 dollars to more than 54 dollars to process a single purchase order,³ and its order management measures are published per 1,000 dollars of revenue rather than per order for exactly this reason.⁴
| Denominator | Customer A | Customer B | Ranking it produces |
|---|---|---|---|
| Per order | 775.00 dollars | 681.25 dollars | Wrong. A looks 13.8 percent worse while earning 8.1 times the contribution |
| Per order line | 86.11 dollars | 129.76 dollars | Correct. B consumes 50.7 percent more per line |
| Per 1,000 dollars of revenue | 77.50 dollars | 272.50 dollars | Correct, and comparable across customers of different size |
| Percent of revenue | 7.75 percent | 27.25 percent | Correct, and directly subtractable from the 30.0 percent gross margin |
An Allocation Rate Is Not a Savings Rate
The tree now says Customer B consumed 1,090,000 dollars of serving cost. It does not say that 1,090,000 dollars leaves if B leaves, and treating the rate as a savings rate is the most expensive mistake available here.
Consolidate B from 1,600 orders to 800, holding revenue and order lines constant. At the allocation rates, that removes 800 orders at 120.00 and 800 deliveries at 280.00, or 320,000 dollars. B's charge falls to 770,000 and contribution rises to 430,000.
Only the variable share is real. If 40 percent of the order processing pool and 60 percent of the freight pool vary with volume inside the quarter, the recoverable amount is 38,400 dollars plus 134,400 dollars, or 172,800. The other 147,200 dollars stays in the business and gets reallocated to whoever remains.
So label each pool with its variable share as a stored column, and read two numbers at every node: the cost consumed, and the cost removable this period. Only the second one funds a decision.
Four Tests Before You Trust a Cost to Serve Tree
- Pool additivity test. For each pool separately, the sum of customer charges must equal the pool total. Aggregate agreement across all four pools can hide two pools that offset, which is the failure mode the MECE checks are built to separate.
- Driver count test. Every driver count in the tree must tie to the system of record: orders to the ERP, deliveries to the transport records, contacts to the service desk. A count that comes from a monthly summary slide is not a count.
- Causality test. For each pool, confirm the driver moves the cost. Compare a period with materially more deliveries and check that freight rose roughly in proportion. If it did not, the driver is a convenient divisor, not a cause, and every charge built on it is decoration.
- Variability test. Record the variable share of each pool and refuse to quote a saving above it.
Run test 1 first because it fails loudly. Test 3 decides whether the tree was worth building.
Where a Cost to Serve Tree Is the Wrong Instrument
Four situations break the method.
Near-zero marginal serving cost. In software, serving cost is mostly salaries and infrastructure that do not move with one customer's activity. Allocating them produces a precise number attached to no available decision.
Missing driver data. If order line counts, delivery records and contact logs do not exist per customer, the tree is an assumption carried to two decimal places. Build the counting first and the tree next quarter.
Strategic volume. An account that consumes serving cost out of proportion may still be carrying fixed capacity that would otherwise sit idle. The contribution number is correct and is not the whole argument.
Seasonal or immature operations. One quarter of activity counts from a business with a December peak describes December, not the year. Use twelve monthly rows.
In the first case, skip the tree. In the other three, build it and label what it cannot yet support, which is the same discipline OTIF counting requires of its denominators.
Building the Tree in kpitree.io
kpitree.io builds this decomposition from one uploaded CSV. The file needs one row per customer per period and ten summable columns: revenue, cost of goods sold, the four pool totals, and the four driver counts.
Inside the tree, parent to child relationships are addition and subtraction, which is what lets gross margin minus four cost pools produce contribution as a real arithmetic identity rather than a layout convention. Every rate, cost per order, cost per line, cost as a percent of revenue, is a derived node that divides two summed columns at the level being read. Regroup from customer to channel to region and each rate recomputes against its own denominator.
CSV upload is the evidenced ingest path today. The tree computes the arithmetic. It does not narrate it, and it will not tell you which customer to fire.
The smallest useful version is two rows. Take your two largest accounts, one quarter, ten columns, and split the serving cost your team already argues about.
Frequently Asked Questions
Is cost to serve the same as activity-based costing? No. Activity-based costing charges all costs, including production, to activities.² Cost to serve applies the same logic to transacting, delivering and supporting only, which is why it can be refreshed quarterly.
Should cost to serve sit above or below gross margin? Below. Above it, serving cost gets mixed with cost of goods sold and neither branch reconciles to the ledger cleanly.
How many activity pools are enough? Four covers most distribution businesses. Add a fifth only when it is larger than the smallest existing pool and has a driver you already count.
What if two pools share a driver? Keep them separate with the same driver. Merging them hides a rate change in one pool behind stability in the other.
Why does my cost to serve differ from a consultant's figure? Almost always the pool boundary or the allocation base, not the business. Reconcile the inputs before arguing about the conclusion. Where the number feeds a plan, integrated planning is the current FP&A benchmarking theme, surveyed across 332 professionals in 54 countries.⁷
Closing: Allocate by Driver, Not by Size
A cost to serve total that ties to the general ledger says nothing about which customer earned it. The split is the analysis, and a revenue-weighted split is the assumption that all customers behave alike, stated as arithmetic.
Store ten summable columns per customer per period. Derive every rate by dividing two of them. Charge each pool by the activity that causes it, then check that the charges sum to the pool total pool by pool, not just in total. Label each pool's variable share so nobody quotes an unrecoverable saving.
Done that way, the two identical 4,000,000 dollar customers stop looking identical, and the 780,000 dollar difference between them becomes a renegotiation with a number attached rather than a suspicion.
Upload one CSV with two customers, four cost pools and four driver counts, and split your own cost to serve in kpitree.io.
Sources
- Implementing Activity-Based Costing (Statement on Management Accounting)
- Activity-based costing (ABC)
- How Efficient Is Your Procurement Process? Benchmarks Reveal a Wide Performance Gap
- Total cost to perform the customer order management function per $1,000 revenue
- State of Logistics Report
- US logistics costs fall to 7.8% of GDP in 2026 report
- 2026 AFP FP&A Benchmarking Survey Report: Integrated Planning
- IMA Releases New Statement on Management Accounting for Managerial Costing Conceptual Framework