The Cooper-Kaplan activity cost hierarchy is a framework that sorts overhead costs into tiers based on what actually triggers each cost, rather than spreading everything across units produced. Robin Cooper and Robert Kaplan introduced it in the late 1980s as the foundation of activity-based costing (ABC), arguing that traditional volume-based allocation systematically overcosts high-volume products and undercosts low-volume ones. The original four tiers are unit-level, batch-level, product-sustaining, and facility-sustaining activities. Later refinements added a fifth tier for customer-level costs. Each tier has a different relationship to production volume, and treating them all the same is where most costing errors begin.
Unit-Level Activities
Unit-level costs occur every time you produce one more item or deliver one more service. Every additional unit adds a proportional amount of cost, and every unit removed eliminates it. Direct labor is the classic example. A technician paid $22.50 per hour to assemble a component that takes one hour scales perfectly with output. Raw materials behave the same way: $14.20 in steel for every bracket means 1,000 brackets cost 1,000 times more in steel than a single one.
Machine-related energy consumption also fits here when it is tied to running equipment for one unit. A stamping machine using 0.5 kilowatt-hours per part at $0.11 per kWh adds $0.055 per unit and disappears the moment you stop making that part. Managers track these costs through bills of materials and labor logs because they feed directly into pricing.
A frequent point of confusion is the relationship between unit-level activities and variable costs in traditional accounting. All unit-level costs are variable, but not every variable cost is unit-level. Traditional variable costing lumps together anything that moves with volume, whether that volume is counted in units, batches, or orders. ABC sharpens the lens by asking what specifically causes each cost to change. A shipping fee triggered once per order varies with the number of orders but not with the number of units in each order. Traditional costing calls it variable; ABC classifies it as batch-level.
Batch-Level Activities
Batch-level costs are triggered by groups of products rather than individual units. You incur them once per production run, purchase order, or inspection cycle, no matter how many items the batch contains. Machine setup is the textbook example. A technician spending three hours at $30 per hour to reconfigure a line adds $90 in setup, whether that run produces 10 units or 1,000. The per-unit share drops from $9.00 at 10 units to $0.09 at 1,000, and that is where the hierarchy begins revealing information volume-based costing hides.
Procurement costs behave the same way. If purchasing spends $75 in staff time and materials to issue a single order for 500 pounds of plastic, the order triggers the cost, not the quantity. Quality inspections performed on a per-lot basis, where a sample from each batch gets tested before release, are another batch-level expense driven by the number of runs rather than total output.
The Overproduction Trap
When batch-level costs are buried inside general overhead and spread across all units using a single volume-based rate, a predictable distortion appears. High-volume products absorb a share of setup and ordering costs that actually belong to low-volume products triggering the small runs. High-volume products look less profitable than they are; low-volume specialty products look more profitable. This cross-subsidy is invisible under traditional costing and is one of the primary problems Cooper and Kaplan set out to fix.
The same distortion tempts managers into a false economy: running larger batches to spread setup costs over more units. Per-unit cost drops on paper, but the larger batches create excess inventory that ties up cash, consumes warehouse space, and risks obsolescence. Those holding costs rarely appear in the same line item as the setup savings, so the trade-off stays hidden. Treating setups as batch-level expenses forces a more honest conversation about optimal batch size.
Product-Sustaining Activities
Product-sustaining costs exist to keep a specific product line alive in the portfolio. They do not vary with the number of units produced or the number of batches run. They persist as long as the product itself remains active. Engineering change notices are a clear example. Updating a blueprint might cost $1,800 in staff time whether you sell 50 units of that product this year or 50,000. Patent maintenance fees, safety certification renewals, regulatory compliance documentation, and product-specific marketing campaigns all belong in this tier.
These costs are easy to overlook because they feel like fixed overhead, and under traditional costing they get smeared across all products by volume. That treatment punishes high-volume simple products by forcing them to subsidize the compliance and engineering burden of low-volume complex ones. A company with 200 SKUs and a company with 20 SKUs might have similar unit-level and batch-level costs, but the 200-SKU company carries far higher product-sustaining expenses. ABC makes that complexity cost visible.
The composition of these costs also shifts across a product’s life. Introduction is dominated by research and development and initial marketing. Growth pushes manufacturing to the front while sustaining costs hold steady. Maturity brings promotional spending and staff training. Decline adds disposal costs and potentially new R&D for a replacement product. A product that looks cheap to sustain in its growth phase may have consumed enormous resources during introduction that were never properly attributed to it.
Facility-Sustaining Activities
Facility-sustaining costs keep the organization running as a whole. They do not change with the number of units, batches, or product lines. Monthly building rent, general plant security, property taxes, insurance, and salaries for plant-wide management belong here. These expenses exist even if the factory produces nothing for a month.
This tier is the most controversial in the hierarchy, and Cooper and Kaplan were deliberate about it. Because facility-sustaining costs have no cause-and-effect link to any specific product, allocating them to products creates misleading data. Spreading $150,000 in annual rent across product lines by machine hours or labor hours pretends that discontinuing one product would reduce rent. It would not. The allocation creates a phantom savings that can drive bad decisions on pricing and product mix.
Many ABC practitioners treat facility-sustaining costs as period expenses covered by overall margin rather than assigning them to individual products. That does not mean the costs are unmanaged. They are managed at the organizational level through decisions about facility size, location, and capacity, not through product-level cost accounting. On an ABC product profitability report, facility-sustaining costs often appear below the product margin line as a lump sum instead of being spread across product costs. Ignoring that distinction is one of the most common implementation mistakes.
Customer-Level Activities
Cooper and Kaplan’s later work expanded the hierarchy to recognize a fifth tier: costs driven by individual customers or customer segments rather than products. Two customers can buy identical products in identical quantities and still impose very different costs on the business. One places a single annual order, pays on time, and never calls support. The other places weekly orders, demands custom packaging, disputes invoices, and calls the account team three times a month. The product-level cost is the same; the customer-level cost is not.
Customer-level activities include dedicated account management, technical support, custom order handling, specialized shipping, and sales visits. The cost driver is usually tied to customer behavior: number of service contacts, number of orders, or number of custom specifications. Businesses that focus only on product profitability often misallocate marketing resources by chasing high-revenue customers who actually destroy margin through servicing demands. A customer generating $500,000 in annual revenue but consuming $480,000 in product, batch, and customer-level costs is less valuable than a customer generating $200,000 at $150,000 in total cost. ABC makes that math visible.
How the Hierarchy Exposes Cross-Subsidization
The core insight of the hierarchy is that volume-based costing creates systematic cross-subsidies. High-volume products get overcharged for overhead; low-volume products get undercharged. This is not random error. It follows a predictable pattern because volume-based allocation assumes every cost moves in lockstep with production quantity, when in reality only unit-level costs do.
Consider a factory making two products: Product A in runs of 5,000 units and Product B in runs of 50. Under traditional costing, both share overhead based on total production volume, and Product A absorbs most of it. But if both products require the same number of setups, engineering changes, and inspections per run, their batch-level and product-sustaining costs are similar. ABC reveals that Product B’s true per-unit cost is far higher than traditional costing suggests, because each of those 50 units must absorb the same setup and sustaining costs that Product A spreads across 5,000. Cooper and Kaplan were the first to note that overhead costs are, in most cases, not proportional to production quantity, and they proposed the hierarchy specifically to account for that quantity-independent resource consumption.
Choosing the Right Cost Drivers
A cost driver is the measurable factor that triggers an activity’s cost. Picking the wrong driver undermines the entire hierarchy, because even perfectly classified costs produce garbage numbers if the allocation base does not reflect actual consumption. Cost drivers fall into three categories, each trading accuracy against measurement effort.
- Transaction drivers count how many times an activity occurs: number of setups, number of purchase orders, number of inspections. They are the cheapest to track because the data often already sits in an ERP system. Their weakness is the assumption that every occurrence consumes the same resources. If one setup takes 30 minutes and another takes four hours, counting them equally distorts the allocation.
- Duration drivers measure how long an activity takes: setup hours, inspection hours, engineering hours. They capture variation transaction drivers miss and are worth the extra effort when time per occurrence varies significantly across products or batches.
- Intensity drivers weight each occurrence by complexity, multiplying driver quantity by a complexity factor. They are the most accurate and the most expensive to implement, often requiring specialized measurement or quality control staff. They make sense only when the resources consumed are both costly and highly variable.
Kaplan’s own advice is to aim for estimates that are approximately right, within five to ten percent of actual consumption, rather than measuring to four decimal places. Start with transaction drivers wherever they reasonably approximate resource demand. Move to duration drivers only for activities where time per occurrence varies enough to create meaningful distortion. Reserve intensity drivers for the most expensive, most variable activities. If your estimates are off, the system will surface it through unexpected surpluses or shortages of committed resources, which becomes a signal to refine the driver rather than a reason to rebuild the model.
Putting the Hierarchy to Work
Implementation begins by identifying every overhead cost in the general ledger and assigning it to one of the tiers. This sounds mechanical, but classification is where most of the judgment lives. Is a quality control salary unit-level (testing every item), batch-level (testing per run), or product-sustaining (maintaining the testing protocol for a product line)? The answer depends on what actually triggers the work, and getting it wrong cascades through every downstream calculation.
Once costs are grouped into activity pools, you calculate a rate for each pool by dividing total pool cost by the total quantity of its cost driver. A batch-level setup pool of $45,000 for the year with 500 planned setups produces a rate of $90 per setup. A product requiring 20 setups absorbs $1,800; a product requiring 200 absorbs $18,000. Under traditional costing, both would have shared setup costs by unit volume, which could dramatically under- or over-assign the cost depending on their relative production runs.
The payoff shows up in the decisions the data supports. A product that appears profitable under volume-based costing may actually be losing money once its consumption of batch and product-sustaining activities is visible. Finance teams can set more accurate prices, identify products worth discontinuing, and justify capital investments in automation that reduces unit-level labor or quick-changeover equipment that reduces batch-level setup time.
The Maintenance Problem
The biggest practical obstacle to ABC is keeping the data current. Building the initial model is labor-intensive; maintaining it year over year is where many implementations quietly die. Developing and sustaining an ABC model is significantly demanding in time and cost, and some organizations need a dedicated budget line for model maintenance alone.
A persistent data quality problem is that employees surveyed about their time tend to report production-related tasks consuming 100% of their capacity, leaving out breaks, training, travel between workstations, and other idle time. Cost drivers then look lower than they actually are because the denominator is overstated, which understates the cost per activity. Some models adjust by assuming a standard idle-time percentage, but that assumption can introduce its own errors that surface only after decisions have already been made from the model’s output.
Time-Driven ABC: Kaplan’s Refinement
By the early 2000s, Kaplan acknowledged that traditional ABC had serious scalability problems. The employee surveys and interviews needed to build and update the model were expensive, subjective, and hard to repeat. Large operations required thousands of employees to submit periodic surveys with dedicated staff managing the data, and many organizations let their ABC systems go stale.
Time-Driven Activity-Based Costing (TDABC), developed by Kaplan and Steven Anderson, strips the model down to two parameters: the unit cost of supplying capacity and the time each activity requires. Instead of surveying employees, managers estimate the time each transaction type takes and pull actual transaction volumes from existing ERP and CRM systems. Divide the cost of capacity supplied by the practical capacity of those resources to get a cost-per-minute rate, then multiply by the estimated minutes each activity consumes.
The critical improvement is how TDABC handles unused capacity. Traditional ABC assumed resources ran at full capacity because employee surveys always added up to 100% of available time. TDABC builds in a practical capacity estimate, typically 80% to 85% of theoretical capacity, and explicitly calculates the cost of unused capacity as the difference between resources supplied and resources consumed. Managers get a concrete number they can act on, either by reducing resource supply or reserving that capacity for growth.
TDABC also handles complexity through time equations rather than proliferating activity pools. Instead of creating a separate activity for every order type or shipping method, you write an equation that adds time for each complication: base order processing takes 3 minutes, add 2 minutes for a custom label, add 5 minutes for hazardous materials packaging. The model stays compact as the business gets more complex.
Where the Hierarchy Does Not Apply
ABC is a management accounting tool, not a financial reporting requirement. External financial statements prepared under Generally Accepted Accounting Principles (GAAP) use methods like FIFO or LIFO for inventory valuation and standard costing for overhead allocation. You do not need ABC to comply with GAAP, and external auditors generally neither require nor expect it. The two systems can coexist: ABC principles inside overhead calculations for internal decisions, standard costing for external reports.
Where ABC touches tax rules is in the uniform capitalization requirements under 26 U.S.C. ยง 263A, which require businesses to include both direct and indirect costs in inventory or capitalize them to property produced. The IRS permits several allocation methods, including specific identification based on cause and effect, burden rate methods, and standard cost methods. An ABC system that rigorously traces indirect costs to activities and products can support a defensible allocation, provided the method is consistently applied and verifiable.