Overhead Allocation and Cost-to-Serve

Executive summary

Overhead allocation is the rule that decides how much shared cost (customer service, warehousing, billing, planning, management) lands on each customer, product, or business unit. The most common rule is also the laziest: spread overhead as a percentage of revenue. It is easy to compute and it gives every dollar of revenue the same burden. Under that rule a customer that places one large order a month and a customer that places forty small orders look equally profitable at the same gross margin.

Cost-to-serve fixes this by following the work. You group overhead into pools, find the activity that makes each pool grow (tickets handled, order lines picked, invoices issued), compute a rate per unit of activity, and charge each customer for the units it actually consumed. The result is not more accurate to the cent, but it points at the right customers, products, and channels.

This guide covers when the extra effort pays off, how to build it in a spreadsheet from ledger and system data, and how to keep it simple enough that you will still maintain it next year. It ends with an illustrative example where a customer that looks profitable under a revenue allocation loses money once the activity it causes is counted.

When to use this

Use cost-to-serve when:

• Gross margin looks healthy but operating profit does not, and nobody can say which customers or products cause the gap.
• You sell a mix of large and small customers, or standard and custom products, through channels that need different levels of support.
• Pricing, minimum order, or service-level decisions are being made on gross margin alone.
• Overhead has grown and every leader claims their function is "shared".
• You are preparing for a sale and the buyer will ask for customer-level profitability.

Do not start here if you cannot trace cost by function from the ledger. Do not use it to justify an unplanned cut to a customer relationship without involving sales: the next step after this analysis is a commercial decision, not a finance one. For the commercial side, see customer profitability analysis.

Diagnostic questions

1. What percent of total cost is overhead (cost not directly traceable to a unit of product or service), and how is it presented on the P&L?
2. How is overhead currently allocated to customers, products, or units: revenue, headcount, direct labor, or not at all?
3. Which five functions make up most of the shared cost?
4. For each of those functions, what activity makes the workload go up? Can you count it from a system (ticket count, order lines, invoices, shipments, quotes)?
5. Do the customers with the most complaints, returns, or special handling also have the lowest gross margins, or do they hide behind average pricing?
6. Which customers or products receive services not reflected in their price (expedited shipping, custom packaging, dedicated support, consignment stock)?
7. Does the sales team see profit by customer, or revenue and gross margin only?
8. Can you separate costs that vary with activity from costs that are fixed in the short run?
9. Which allocation decisions are driven by a contract, such as cost-plus or shared-service charges, and which are management choices?
10. Who would own the model after it is built, and how often would it be refreshed?

If question 4 gets a blank stare, begin with two pools and two drivers that you can count today. A rough driver you can refresh monthly beats a precise one you can only compute once.

The framework: pools, drivers, rates, assignment

Step A: separate direct from shared cost

Start with the P&L. Direct cost is anything you can trace to a specific unit of revenue without a rule: materials, direct labor, freight on a specific order. Shared cost is everything else. Do not push direct cost into overhead because it is hard to trace. If freight on each order is in the system, trace it.

Step B: build overhead pools

A pool is a group of shared cost that moves with the same activity. Examples:

Aim for five to eight pools. More than that and the model becomes a maintenance burden.

Step C: choose drivers

A good driver satisfies three tests:

1. Causal. If the driver doubles, the pool's workload roughly doubles.
2. Countable. You can get it per customer or product from a system you already run.
3. Stable enough. The definition will mean the same thing next quarter.

Pick the cheapest driver that passes. Time-based drivers from time-tracking sound precise but usually fail the countable test.

Step D: compute a rate

Rate per driver unit = Pool cost ÷ Total driver units in the period
Cost-to-serve (customer) = Sum over pools of (Rate × Customer's driver units)

Use the same period for cost and driver units. Where capacity is clearly idle (a warehouse sized for twice the volume), consider separating the idle portion so it is not charged to the customers who happen to be there. This is a judgment call, so make it explicit and write it down.

Step E: assign and view

Charge each customer or product its pool costs. Show gross profit, cost-to-serve, and the resulting operating profit side by side with the revenue-allocated view. The comparison is the point: the difference between the two views tells you who is being subsidized.

What about management and general cost?

Executive cost, audit, and legal rarely have a causal driver. Leave them unallocated, or allocate them last and label that line clearly as an arbitrary spread. Do not let an arbitrary allocation decide whether a customer is dropped.

Step-by-step process

1. Define the objective: customer profitability, product profitability, or channel. Owner: CFO. Output: one-sentence scope.
2. Extract the P&L and cost by function for the last twelve months. Owner: Controller. Output: cost by function and natural account, tied to the ledger.
3. Separate direct from shared cost. Owner: FP&A. Output: shared cost total, agreed with operations.
4. Define pools and assign each shared cost line to one pool. Owner: FP&A with function leads. Output: pool map, with every dollar of shared cost mapped once.
5. Pick and test drivers. Pull driver counts from systems and sanity-check them with the function lead. Owner: FP&A with operations. Output: driver table with source system per driver.
6. Compute rates and the cost-to-serve per customer. Owner: FP&A. Output: customer profitability table, with a reconciliation to total shared cost.
7. Compare to the current method and list the customers whose result changes sign or rank by a large amount. Owner: FP&A. Output: exception list.
8. Review with sales and operations before anyone sees it more widely. Owner: CFO. Output: agreed list of cases to investigate. Some will have a good reason (a strategic account, a new customer ramping up).
9. Choose actions: change the price, minimum order, service level, or channel; or fix the process that drives the activity. Owner: Commercial lead with CFO. Output: action list.
10. Refresh quarterly and keep a log of changes to pools and drivers. Owner: FP&A.

Templates

Pool and driver map

Customer cost-to-serve table

Reconciliation checklist

1. Sum of pool costs equals total shared cost from the ledger.
2. Sum of customer driver units equals total driver units for each pool.
3. Sum of customer cost-to-serve equals the sum of pool costs.
4. Sum of customer operating profit is the same under both methods.

Worked example

Illustrative. All numbers are made up to show the method. They are not benchmarks.

A distributor has $10.0M of revenue from three customers (in reality there would be many, but three show the effect). Gross profit is 25% for each: A earns $1,500,000 on $6.0M, B earns $750,000 on $3.0M, and C earns $250,000 on $1.0M. Total gross profit is $2,500,000. Shared overhead is $1,800,000, in three pools.

Revenue-based allocation. Overhead is 18% of revenue ($1.8M ÷ $10.0M). That gives A $1,080,000, B $540,000, and C $180,000. Operating profit is $420,000 for A, $210,000 for B, and $70,000 for C. Total: $700,000. All three look profitable, with C the weakest.

Driver-based allocation.

Driver units by customer:

Cost-to-serve:

Operating profit:

The total is $700,000 under both methods, which is the reconciliation check. The method moved profit between customers, not into or out of the company.

What it says. Customer C makes up 10% of revenue and 50% of tickets, 50% of order lines, and 64% of invoices. Under revenue allocation it looked marginally profitable. Under driver allocation it loses $692,000. Customer A, the largest, is far more profitable than the revenue view suggested.

What it does not say. It does not say drop customer C. It says the price, order size, or service level for C does not cover the activity it causes. The options include a minimum order quantity, a handling charge, consolidating invoices, moving C to a self-service channel, or repricing. Each option has a commercial consequence that sales must weigh. Also check how much of the $942,000 would actually disappear if C left. Warehouse and service capacity is often fixed in the short run, so the avoidable cost may be smaller than the allocated cost. Treat the allocated number as a guide to pricing and process, and the avoidable number as the guide to a drop decision.

Metrics and KPIs

Targets by method. Do not borrow a cost-to-serve ratio from another company. Set your own targets by comparing segments inside your business (your best-served customer group is your own benchmark), by tracking the rate per unit over time, and by setting contractual floors such as a minimum margin after cost-to-serve for any new account. A named public peer's disclosure of fulfillment or selling cost can inform a sanity check, but their scope will differ from yours.

Common mistakes

1. Allocating everything. Executive and audit cost has no activity driver. Allocating it distorts the picture. Keep it as an unallocated line.
2. Too many pools and drivers. A model with 30 pools will not be refreshed. Start with five to eight.
3. Using drivers that cannot be counted. Survey-based time estimates drift. Prefer system counts.
4. Treating allocated cost as avoidable cost. Dropping a customer rarely removes all the cost allocated to it. Separate the two before a decision.
5. Sharing the results with sales without context. Show the method and the reconciliation first. Otherwise the conversation becomes a fight about the numbers, not about the customer.
6. Ignoring strategic accounts and ramp-up. A new customer, a reference account, or a customer that opens a channel may deserve a different test. Record the reason and set a review date.
7. Penalizing customers for your own inefficiency. If a pool rate is high because of rework or an inefficient process, fix the process first. The customer is not the cause.
8. One-off analysis. Customers change. Refresh quarterly.
9. Skipping reconciliation. If the customer totals do not tie to the ledger, the model will lose credibility the first time someone checks.

AI prompt assistance

AI is useful for preparing the pool map and writing up findings. It cannot see your operations, so check any pool or driver suggestion with the function lead.

1. Draft a pool map.

Here is last year's cost by function and natural account for a [type of business]. Propose five to eight overhead pools, assign each cost line to exactly one pool, and suggest one countable driver per pool. Flag lines you could not assign.

Check: total of pools must equal total shared cost. Confirm each driver can be pulled from a system you run.

2. Test whether a driver is causal.

Here are monthly pool costs and monthly driver counts for 24 months. Compute the correlation and fit a simple line. Tell me whether the driver explains the movement in cost, and which months are outliers.

Check: recompute one month by hand. A strong correlation does not prove causation, so ask the function lead whether the driver really makes the work go up.

3. Compare the two views.

Here are two customer profit tables, one from revenue-based allocation and one from driver-based allocation. List the customers whose operating profit changes sign or whose rank changes by more than five places, and show the difference in dollars.

Check: both tables must total to the same operating profit.

4. Draft a customer conversation brief.

Based on this customer's cost-to-serve, write a one-page brief for the account manager: where cost-to-serve is high, which drivers explain it, and three options (price, process, service level) with the tradeoff of each. Do not recommend ending the relationship.

Check: the account manager must confirm facts and decide what to raise with the customer.

Implementation guide

Governance: the CFO owns the method, FP&A owns the model and its reconciliation, operations owns the driver data, and sales owns the commercial response. Contracts with cost-plus or shared-service clauses may define allocation rules, so follow the agreement and ask counsel when in doubt. Accounting treatment for external reporting (inventory costing, for example) follows your accountants and standards, and this management view is separate.

Downloadable assets

The pool and driver map, the customer cost-to-serve table, and the reconciliation checklist above are laid out to be copied into a spreadsheet. The worked example tables can be used as a test case for your own build: if your model reproduces the totals above from the same inputs, the mechanics are right. A calculator for this guide is not currently listed.

Related resources

• SG&A cost guides hub: the wider set of overhead and structure guides.
• Customer profitability analysis: turning cost-to-serve into pricing and account decisions.
• Margin expansion playbook: where cost-to-serve sits among margin levers.
• Zero-based budgeting for mid-market companies: reopening the cost pools you have just measured.
• Span of control cost analysis: the management structure side of overhead.

Frequently asked questions

What is cost-to-serve?

Cost-to-serve is the cost of the activity needed to serve a specific customer, product, or channel beyond the cost of the goods or service itself. It is calculated by multiplying a rate per activity unit, such as tickets handled or order lines picked, by the units each customer consumes.

Why is allocating overhead by revenue misleading?

Allocating by revenue assumes every dollar of sales causes the same overhead. In practice small orders, custom work, and high-touch accounts cause more activity per dollar. A revenue allocation hides that, so low-margin, high-activity customers look better than they are and large, simple customers look worse.

How many overhead pools do I need?

Five to eight is usually enough. Each pool needs a driver that you can count per customer from a system. More pools add precision you cannot maintain. Start with the two or three pools that make up the most cost and add others only if they change a decision.

Does a negative cost-to-serve result mean I should drop the customer?

No. A negative result means the price, order pattern, or service level does not cover the activity the customer causes. Check how much of the allocated cost is actually avoidable, then consider price, minimums, or process changes. Decisions about a customer relationship belong with sales and leadership, with the finance analysis as input.

Is this the same as activity-based costing?

It is a simplified form of it. Activity-based costing assigns cost to activities and then to products using drivers. A cost-to-serve model for a mid-market company uses the same logic with fewer pools and drivers so that it can be refreshed quarterly from data you already have. It is a management view, not a replacement for statutory accounting.

How this works in a System of Performance

A cost-to-serve model goes stale when the pool map lives in one analyst's spreadsheet and the driver counts are refreshed by hand. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see which customers cost more to serve than their margin covers, bring it to us as a launch partner.