A Practitioner’s Introduction to Activity‑Based Costing (ABC)
Understanding ABC
If you’ve encountered Activity‑Based Costing before, it was likely in the context of a formal accounting method. But at its core, ABC is a way of understanding why something costs what it costs. The basic premise is that work drives cost. If something requires more effort, time, material, or more use of a shared system, it will naturally generate more cost.
This is a pattern that practitioners are already familiar with. For example, when a workload uses more compute or storage, it drives more infrastructure cost. ABC gives us a structured way to describe these patterns by showing that cost isn’t random or evenly distributed. Cost is generated by work, and it follows the operational complexity of that work into the products or services that consume it.
As cloud, AI, and modern architectures reshape how technology is delivered, the underlying principle of ABC still applies: cost follows activity, and activities support the products and services that rely on them. There’s much more to the mechanics of ABC than is covered here, but practitioners don’t need an academic understanding of the accounting methods to be effective.
Why Look Back at Accounting to Understand Modern Technology Costing?
Technology costing often feels like a new problem, but accounting has been solving versions of this problem for decades. Manufacturing, logistics, and service organizations have long used ABC (and Job Order Costing, discussed later) to understand how work creates cost and how that cost flows into products.
Technology is not very different; the activities are just different:
Instead of machine hours, we have compute hours.
Instead of material handling, we have help desk and support.
Instead of production runs, we have model training cycles.
By grounding technology costing in established accounting practices, we gain clarity and can avoid reinventing the wheel. ABC becomes a bridge between traditional financial structure and modern technology operations.
What ABC Really Means for Practitioners
ABC is often explained in academic terms, but practitioners only need to hold onto three ideas:
Activities consume resources. Engineering hours, compute, storage, licenses, and other things the business purchases are the inputs.
Products and services consume activities. Applications, platforms, business services, and AI models rely on those activities to exist.
Cost flows through this pipeline. Resources → Activities → Products or Services.
Once you see cost this way, the rest becomes much easier to explain and model.
Examples That Make the Concept Click
Incident Management
More incidents = more response hours = more cost. The activity is incident management. The cost driver might be ticket count or resolution hours. The inputs are the people and tools used to perform the activity.
Model Training
More training runs = more GPU hours, orchestration, and data prep = more cost. The activity is model training. The cost driver might be training hours or dataset size. The inputs are the people, tools, and infrastructure used in the activity.
Cloud Consumption
More workloads = more compute/storage/network = more cost. The activity is running workloads or applications. The cost driver might be vCPU hours, GB stored, or requests processed. The inputs are the cloud services consumed by the activity.
These examples show that ABC may feel like a new vocabulary, but the underlying concept is familiar: it’s a structured way of describing work and resource consumption.
The Steps of ABC (Practitioner Version)
ABC can be implemented in many ways, but the practitioner‑friendly version usually follows this pattern:
1. Identify the major activities
Not every activity, just the meaningful ones, and tiering or layering is common:
Unit‑level
Batch‑level
Product‑level
Customer‑level
Tiering keeps the model manageable and prevents over‑engineering.
2. Determine the cost of each activity
This is where existing accounting data helps. Labor, cloud, software, hardware, and facilities are the resource pools.
3. Identify cost drivers
Cost drivers explain why an activity consumes more or less cost. Examples: ticket volume, training hours, GB stored, number of integrations.
4. Calculate the cost driver rate
This is the “cost follows activity” step. If an activity consumes 40% of a resource, it receives 40% of the cost.
5. Assign activity cost to products or services
Activities exist to support something like an application, a platform, a business service, or a model. Those consumers inherit the cost of the activities they rely on.
This is the full ABC chain: Resources → Activities → Products or Services.
Where Frameworks Like ITFM, TBM, and FinOps Fit In
Available frameworks help apply these ideas in practical ways. Each approaches cost transparency from a different angle, but they all benefit from ABC thinking:
ITFM provides financial structure and transparency around technology spend.
TBM organizes and communicates technology cost using a standard taxonomy and layered model.
FinOps brings cost awareness into technology operations, where activity‑based patterns are especially visible and often change rapidly.
ABC is the underlying logic. All three benefit from the same principle: cost follows activity.
How to Start Building
To trace costs through activities, we start with the basics: what the costs are and where they come from. Cost Pools, or the categorization of costs into meaningful buckets, form the foundation for an ABC‑informed cost model. Whether you’re applying ABC, Job Order Costing, or the modern frameworks that build on them, this first layer makes the rest of the model possible.
Segment 1 of Foundations of Cost Modeling: A Standards‑Aligned Guide for Technology and Finance focuses entirely on this foundational step. It introduces how to move from organizational data to a cost pool structure using publicly available classifications as a neutral starting point. This makes it useful for anyone configuring a cost model for the first time or trying to understand a model they’ve inherited, regardless of whether they work within ITFM, TBM, FinOps, or a homegrown approach.
Bringing It All Together
ABC helps us understand why costs behave the way they do, how activities drive that behavior, and how those activities support the products and services our organizations rely on. It encourages us to think through cost from its point of origin, what we purchased, through the lifecycle of how that purchase is used, which capability or service it supports, and how it ultimately creates value for the business.
