If you have ever tried to answer what a product, a service or a customer actually costs you, a cost model is how you get there. It takes the costs already sitting in your general ledger and traces each one to the product, service or customer that caused it.
This guide covers how cost models work and how to choose the right approach for yours, based on best practices from Sander den Hartog, who has spent over 20 years building cost models with organizations across banking, telecom and government.
Whether you are building your first cost model or improving one that already exists, this page is your reference point. If you are past the design stage and looking at tooling, start with our cost modeling software.
Key Takeaways
- A cost model traces costs from the general ledger down to the products, services, customers or transactions that caused them.
- The method label matters less than the logic. What separates a strong model from a weak one is whether every allocation reflects genuine cause and effect.
- Decide the use case before you design anything, because it determines the granularity, the data, and who ends up using the output.
- You do not need perfect data. A model that is 70 to 80% right gets you further than a perfect model you never build.
- A correct model is not enough. Stakeholders will not use a model they have not validated themselves.
- Allocate on a rule rather than naming specific products, so a new product or a reorganization does not mean rebuilding the model.
What is a cost model?
A cost model is a structured representation of how costs flow through an organization, from the general ledger to the products, services, customers, or transactions that consume them. It takes cost information you already hold for financial accounting and reorganizes it around cause and effect, so you can see what each output actually costs to produce. In short, a cost model is a blueprint that describes your whole organization in terms of costs.
It starts with the costs your organization already incurs. From there, the model traces each cost downward to answer one question: how do these costs land on the products and services we sell?
That journey from ledger to output is what cost modeling is. Most organizations take it to product or service level, but a model can go further, down to individual customers, channels, or single transactions. How far down you go is one of the first choices you make, and it determines most of the work that follows.
What can you decide with a cost model?
The range of decisions a cost model supports is open-ended, which is why the first thing to pin down is its use case. What you want to decide determines how you build the model, how granular it needs to be, and who ends up using the output.
Here are 5 common cost modeling use cases:
- Product pricing and margin: Do we have a defensible cost price, and are we selling this profitably?
- Customer profitability and cost-to-serve: Which clients, segments or channels earn their keep once you count what it costs to serve them?
- Operational improvement: Of ten improvement projects on the list, which one releases the most cost?
- Budgeting and scenarios: What will this cost before we commit to it, and what happens to our cost base if volumes move 20%?
- Regulatory reporting: Can our regulatory reporting meet the prescribed method and survive an audit?
The emphasis also shifts by sector. For example, while manufacturers use cost models to find where production cost is being lost, service organizations use them to understand what delivering a service to a particular client actually costs.
How does a cost model work?
Every cost model is built from layers. Sander den Hartog draws four, though there can be more.
The cost model starts with your costs, taken straight from the general ledger. Those costs pay for resources: people, systems, buildings. Nobody wants resources for their own sake, though. You hold them because they perform activities and processes, and those activities exist because you sell products and services. That chain is the whole cost model. Put 100 million in at the top and 100 million comes out at the bottom, spread across everything you sell.
Direct costs go straight to the product that caused them. Indirect costs need the middle layers to work out which products consumed them.
The 4 components of a cost model
Every layer holds cost objects, and one cost travels through them in sequence. Let’s take a bank as an example. The first layer holds a general ledger line: the personnel cost of the back office. That cost pays for the back office staff in the second layer. Those staff perform an activity in the third layer, such as opening new accounts, and those accounts belong to a credit card in the fourth.
An allocation connects each object to the next, stating how much cost moves and on what basis. Objects also carry attributes, meaning their characteristics: a resource has a number of FTE, an activity has a time it takes to perform. Most allocations use those attributes as their driver.
So, a cost model has 4 components:
- Layers: the levels cost passes through, from ledger to product.
- Objects: the individual items within each layer.
- Allocations: the rules that move cost from one object to the next.
- Attributes: the characteristics of an object, which most drivers use
Cause and effect runs in both directions
Everything so far runs top to bottom, which is how you arrive at a cost price. A good cost model also runs bottom to top, because the products you sell drive the activities you perform, and those activities drive the resources you hold.
That gives you two numbers to compare: what your products actually cost, and what your budgeted volumes said they would cost. The gap splits into a price effect, where resources cost more than planned, and a volume effect, where you sold more or less than expected.
Download our free Cost Allocations whitepaper
A cost model example
Take a bank that wants to know what a credit card costs to deliver. Here is how one general ledger line reaches that number.
- Layer 1, cost: The GL shows €2,000,000 in personnel cost for the back office.
- Layer 2, resources: That pays for 25 back office FTE, so €80,000 per FTE.
- Layer 3, activities: Those FTE perform several activities. Time recording shows 40% of their hours go to opening new accounts, so €800,000 lands on that activity. The bank opens 40,000 new accounts a year, giving a back office cost of €20 per new account opened.
- Layer 4, products: Of those 40,000 accounts, 10,000 were opened for credit cards. So €200,000 of back office personnel cost reaches the credit card product.
That is one cost path. If you repeat it for everything else a credit card consumes, from IT to card production to fraud monitoring, you will have its full cost. Divide by the number of cards and you have a unit cost you can price against.
The allocation that matters here is the one from opening new accounts to the credit card, because it works on the number of new accounts opened per product. That means a sixth product needs no new allocation. It arrives in the data with its own account volumes and the rule already covers it.
How do you choose the right cost model?
Choosing a cost model is less about selecting a named method and more about answering four questions. The method will follow.
1. What is the use case?
The biggest decision to make when it comes to your cost model is its use case. A model built for operational improvement looks different from one built for regulatory reporting, and a model built for both usually satisfies neither well. Thus, write the use case down before you design anything.
If you cannot name a decision someone will make differently because of the model, you are not ready to build it.
2. Where does the cost model end?
Decide your final cost object. Cost per product and service tends to be the default, but cost per client, cost per transaction, or a matrix of several is often what people actually need. This determines the granularity of everything upstream, so changing it later is expensive.
3. Does the logic hold cause and effect?
Whatever method you land on, apply this test to every allocation: does the cost object receiving the cost actually drive it? Resources should be driven by the activities they perform, activities by the products that require them, and costs by the resources you need to hold.
As a quick way to check, ask yourself: If that product, client, or activity consumed less, would this cost fall? If the answer is no, then the allocation is distributing cost instead of tracing cause and effect.
4. How material is it?
Materiality is the accounting principle that an item only matters if getting it wrong would change a decision. It is a familiar concept in financial accounting and an underused one in management accounting, but it applies to cost models just as directly.
One way to test is through sensitivity analysis: change a driver and see how much the output moves. Drivers that barely shift the result are candidates for simplification.
One last thing, which is not about the model itself but constrains it just as much: settle your reporting frequency before you start building. A model that needs six weeks of manual preparation per cycle cannot produce monthly output.
What data do you need to build a cost model?
A common response when someone proposes building a cost model is “we don’t have the right data for that.” This is almost always wrong. As Sander den Hartog points out, four sources you already have cover the foundation of most cost models:
- Financial data: Your general ledger already holds every cost you need to start, because financial accounting requires it anyway.
- Sales data: Volumes, products, clients and channels, which your billing system already records.
- Personnel records: Headcount, FTE, department and role. Most resource allocations use these.
- Process data: What your organization does, in which departments, and roughly in what volumes.
You will still have gaps, but the ones worth taking seriously sit on material cost. If a large IT service has no consumption measurement at all, that is a real constraint and it usually justifies a measurement project of its own.
Your first cost model only needs to be 70 to 80% right
A model that is 70 to 80% right already gets you on the right track. Once it runs, you can see which drivers move the result, and that tells you which data gaps are worth closing.
Almost everyone wants more granularity after building a first model. That is the right point to want it, because by then you know what the extra detail buys you.
How to build a cost model
Here are five steps you can follow to build a cost model:
- Define the goal and name the users: write down what the model is for and who will act on it.
- Design the model on paper first: sketch the layers, the objects in each, and the allocation logic between them before you open any spreadsheet or software.
- Derive the data model from the design: for each allocation, name the driver, the source system and the frequency. In this order, so your question shapes the model rather than whatever your data warehouse happens to hold.
- Validate with your stakeholders: take the output to the people who will use it and walk them through it. This is what decides whether the model gets adopted.
- Automate the cycle: set the data flow up once and schedule it, so a monthly model runs monthly.
Involve people from outside finance from the beginning. As Sander den Hartog says:
“Making a blueprint of your organization is not something you can do from behind your computer or in your corner office.”
Additionally, document as you go rather than afterwards. Record the goal, the design, the data sources and, above all, the reasoning behind each decision, because that is the part a successor cannot reconstruct from the model itself. For a more detailed walk through, see our 8-step telecom cost model guide.
How to validate a cost model
Validation happens at two levels and passing the first and skipping the second is the most common reason a technically sound model never gets adopted.
Level one: does the cost land where it should?
The basic check is completeness. Every euro that entered the model has to come out somewhere, and anything that did not arrive at a cost object should be unallocated on purpose rather than by accident.
This model validation is numeric and dedicated cost modeling software can handle it with automations. For instance, CostPerform’s model validation tools scan for mismatched incoming and outgoing costs, illegal allocations, and invalid formulas, alongside sensitivity analysis that shows which drivers actually move the result.
Passing this check means the model calculates correctly. It does not mean the model is right.
Level two: do your stakeholders recognize the results?
Take the cost model output back to the people it was built for and walk them through it. This is the most important validation you can do and it is the one that decides adoption.
One of two conversations can happen when validating your model with your stakeholders:
- Sometimes they tell you it cannot be right, that this product cannot possibly cost that much more than the other one. They are usually correct and then you have found a problem in the model.
- Sometimes you dig into it together, follow the logic back through the layers, and find the model is right. Those are the better conversations, because it has just told the organization something it did not know.
This only works if you agreed the design and the allocation rules before producing any results. Once data errors are cleared, the outcomes stand. If you renegotiate the rules because someone dislikes their number, every future result becomes negotiable too.
Why cost models fail
There is no such thing as a bad cost model, only models that need improvement. Two problems account for most of the models that get abandoned.
1. The goal drifts away: A cost model gets built for a purpose, then detail gets added and structures get extended request by request. Years later it belongs to one person in finance and answers nobody’s question. Or it would, but nobody knows it exists.
2. The model cannot absorb change: Departments split, products launch, sites close… If your allocations name specific products, each change means someone has to add another allocation, and if they forget, the model still balances while the cost lands in the wrong place. Allocations built as rules avoid this. For example, a bank that allocates its back office by the number of new accounts opened per product does not need to touch the model when a sixth product launches.
3. Nobody can take over the model: Handing a cost model to a colleague is cumbersome, especially in a spreadsheet. What determines whether a handover works is documentation, and four things need to be written down:
- The goal: What the model is for, and who acts on its output.
- The design: The layers, the objects, and the allocation logic.
- The data model: Which driver, from which source, at what frequency.
- The reasoning: Why each decision was taken.
The reasoning often gets skipped during handovers. A successor can work out what the model does by reading it, but they cannot work out why one allocation was chosen over an equally plausible alternative, and without that they will not touch it.
How CostPerform helps you with cost modeling
CostPerform is cost modeling software built for finance teams who need to model costs at any level of detail, from a whole business unit down to a single transaction.
- Defend every number: Trace any cost from the general ledger through every allocation to the product, service or customer that consumed it. When someone challenges a figure, you can show them exactly where it came from instead of asking them to trust it.
- Rules instead of fixed links: Distributions, virtual allocations and conditional allocations let you state allocation logic once, so a new product or a reorganisation does not mean rebuilding the model.
- Automated validation: The model validation tool scans for mismatched costs, illegal allocations and invalid formulas before anything reaches a report.
- Scheduled data flows: Connect your source systems once, so a monthly model runs monthly instead of eating six weeks of preparation.
- Model any allocation method: Activity-based costing, time-driven ABC, multi-dimensional costing and direct costing come as predefined methods, with industry templates as a starting point.
The National Bank of Belgium rebuilt its cost model in CostPerform after outgrowing Oracle HPCM. The new model runs ten times faster and meets the bank’s ECB reporting deadlines. Read the National Bank of Belgium case study.
Download our free Cost Allocations whitepaper
FAQs about cost modeling
What is the difference between cost modeling and cost estimating?
Cost estimating is a one-off calculation of what something will cost, usually for a new product, project or service. Cost modeling builds a reusable structure that keeps answering that question as the business changes. An estimate gives you a number, and a model shows you why that number is what it is.
What are the most common cost modeling mistakes?
The most common cost modeling mistakes are building the model without agreeing what it is for, designing it around the data you happen to have rather than the question you need answered, allocating cost on a basis the receiving side cannot influence, and ignoring maintenance until an organizational change breaks the model.
How can you improve an existing cost model?
To improve an existing model, check whether the model still matches its original goal, whether it can absorb organizational change without a rebuild, and whether every allocation still holds cause and effect.
Do you need perfect data to build a cost model?
No. General ledger data, sales volumes, personnel records and basic process information cover the foundation of most models, and you almost certainly hold all four already. A model that is 70 to 80% right will get you in the right direction.
How accurate does a cost model need to be?
Accurate enough that more detail would change a decision. If modeling something more finely would not change what anyone does, then the extra granularity costs maintenance effort for nothing.