From First Contact to a Live, Trusted Profitability Model
Choosing a costing partner is a bet on whether the numbers will hold up when a board, a lender or a buyer pushes back on them. This page sets out exactly how Cost and Profitability Consulting takes a client from a first conversation to a governed, refreshable profitability model running in CostCtrl. The path is deliberate and repeatable: diagnose the question, design the cost model with time-driven activity-based costing, build the data pipeline, validate every number against the audited accounts, go live, then govern and iterate. TDABC is the spine of the whole engagement, and years of hands-on implementation are what let us compress the timeline without hollowing out the method.
In short. The journey has six stages: diagnose the business question and confirm the data exists to answer it; design a TDABC cost model around resource pools, capacity cost rates and time equations; build the ETL pipeline that feeds it; validate by reconciling every figure back to the trial balance; go live in CostCtrl so management reads whale curves and cost-to-serve rather than blended averages; then govern and iterate so the model refreshes monthly and stays trusted for years. What makes this fast and defensible is not a tool but a discipline. TDABC needs only two inputs per activity, the cost of supplying capacity and the time each transaction consumes, and we have implemented it hands-on for long enough to know where it bends and where it breaks. You keep a model your own team can run; we make sure it is right before anyone acts on it.
Why a defined journey beats a one-off study
Most profitability work fails not because the arithmetic is wrong but because the engagement has no shape. A consultant arrives, builds a heroic spreadsheet, presents a striking slide, and leaves. Three months later the numbers are stale, no one can refresh them, and the insight that was supposed to change pricing has quietly decayed into a file nobody opens. The problem was never the method; it was the absence of a path from question to living model.
A defined journey fixes that by making each stage produce an artefact the next stage depends on, and by making the client an owner rather than an audience. The diagnostic produces a scoped question and a data inventory. The design produces a documented cost model. The build produces a pipeline your team can run. Validation produces a reconciliation that ties to the cent. Go-live produces decisions. Governance keeps all of it true. Nothing is hand-waved, and nothing leaves with the consultant.
This is also how trust is earned rather than asserted. A board does not trust a number because a consultant is confident; it trusts a number it has watched survive a reconciliation gate and a challenge session. The journey below is built so that by the time management acts on the whale curve, they have already seen the model defend itself. That is the difference between a margin story and a margin fact.
Diagnose: the question before the model
The first engagement is a conversation, not a proposal. Before anyone talks about resource pools or ETL, we need to know what decision the model is meant to inform. Are you trying to reprice a loss-making tail of customers, decide which product lines to keep, justify a service surcharge, or hand a private equity owner a margin bridge for the first hundred days? The shape of the question determines the grain of the model, and building at the wrong grain is the most expensive mistake in costing work.
Alongside the question we run a fast data inventory. A costing model needs three kinds of input: money, from the general ledger and cost-centre balances; structure, from the chart of accounts and the product and customer hierarchies; and behaviour, from the operational drivers that record who consumed what. Where a direct ERP extract is impractical, a SAF-T file often gives us the ledger and the master data in one governed package, which lets a client start without waiting on a full integration. The diagnostic ends with a plain statement of what we can answer now, what needs more data, and roughly what the model will show. Cost and Profitability frequently packages this as a fixed-scope Profitability Health Check, so the client sees the shape of the prize before committing to the full build.
Design the cost model with TDABC
This is the stage where experience separates a durable model from a fragile one, and it is where our years of hands-on time-driven activity-based costing implementation earn their place. Robert Kaplan and Steven Anderson's TDABC reduces the whole problem to two numbers per activity: the capacity cost rate, an annual cost of a resource pool divided by its practical capacity, and a time equation that says how many minutes each transaction consumes. Get those two right and the model allocates itself from the transaction data.
The design work is deciding what the resource pools are, how they map from the accounting cost centres, and how the time equations should flex with real complexity rather than a flat average. Cost centres were built for budgeting and responsibility, not causality, so the crosswalk from accounting structure to cost model is rarely one-to-one and is the single most important design artefact in the engagement. We set practical capacity honestly, at roughly 80 to 85 percent of theoretical, so that idle capacity shows up as a visible number rather than being smeared across output and making healthy products look expensive.
Two judgements decide whether a model ages well, and both come from having built many of them.
| Design judgement | The amateur instinct | The experienced choice |
|---|---|---|
| Granularity | Model every micro-activity for the sake of precision | Stop where the driver data stops being reliable; forty good activities beat four hundred guessed ones |
| Driver choice | Use whatever count is easiest to extract | Choose the driver that actually causes the cost, even when it is harder to source |
| Capacity | Cost at theoretical capacity and hide the slack | Cost at practical capacity so unused capacity is a reported line |
| Time equations | A single average minute per transaction | Equations that flex with order size, channel and complexity |
The output of this stage is a documented model design: the pools, the rates, the time equations and the mapping table, all in a form the client can read and challenge before a line of pipeline is built.
Build: the data pipeline that feeds the model
With the design agreed, the build stage turns raw exports into the clean, mapped, driver-ready dataset the costing engine consumes. This is the ETL layer, and its value concentrates in the transform step: cleaning and reconciling the extracts, mapping cost centres to the resource pools from the design, deriving activity quantities from operational events, and conforming every product and customer to a single stable key so one account does not appear three times under three spellings.
We are deliberately tool-agnostic here, because the pipeline has to be maintainable by your team after we leave. We build inside whatever your data team already trusts, whether that is Alteryx, Power Query, KNIME, Talend, dbt or plain SQL. A client whose data already lands in a cloud warehouse gets version-controlled, testable transforms an auditor will respect; a client working from ERP and spreadsheet exports gets an analyst-friendly blend that reaches a model faster. The costing logic is identical across all of them; only the syntax changes. What never changes is the rule that the extract and transform must be automated, so that a monthly refresh is a button and not a project.
Validate: proving every number before anyone acts
No number leaves this stage until it has survived two gates. The first is the reconciliation gate: the sum of every cost loaded into the model must equal the audited trial balance to the cent. If the extracted cost does not tie back to the accounts, nothing downstream is credible, and we automate this check rather than eyeballing it so that it runs on every refresh, not just at launch. A costing model that disagrees with the trial balance is almost always an ETL problem, a missed ledger or an inconsistently handled accrual, and the gate is where that gets caught.
The second gate is a challenge session with the people who know the business. We take the model to the operations and commercial teams and test its results against their intuition. When the model says a flagship account is unprofitable, the question is whether that is a real cost-to-serve finding or a broken driver quietly redistributing profit between customers. A driver that does not truly cause a cost is the most dangerous error in costing because the model still balances; it is simply wrong in a way no reconciliation catches. Walking the results past the people closest to the work is how we find those before a decision rests on them. The model that emerges is decision-grade and defensible under scrutiny from a CFO, a lender or a buyer's diligence team.
Go live in CostCtrl
Go-live is the point where the validated model stops being a project and becomes an instrument management reads. CostCtrl consumes the conformed inputs, the resource pools with their costs, the cost objects with their keys and the driver quantities per period, and runs the TDABC calculation on top: capacity cost rates, time-equation consumption, unused-capacity reporting, and the profitability and whale-curve views that leadership acts on. The division of labour is deliberate. The pipeline owns correctness and repeatability of the inputs; CostCtrl owns the costing method and the outputs.
What changes for the client is the nature of the conversation. Instead of a blended average that hides the distribution behind it, management sees every customer, product and channel ranked on true net margin, and the whale curve that shows cumulative profit climbing well above the reported total before a loss-making tail drags it back down. That gap is the recoverable prize, and it is now something the team can act on: reprice, re-tier service, set minimum-order rules or renegotiate terms. Because the model is live rather than a static spreadsheet, a controller can answer a board question in minutes rather than weeks, and the answer ties to the accounts.
Govern and iterate: keeping the model trusted
A live model is not a finished one. The last stage is governance: the routines that keep the model true as the business changes, so that the trust earned at validation does not erode over the following year. A model that was right at launch and never touched again is a slow return to the stale spreadsheet the whole journey was meant to escape.
Governance is mostly a handful of standing habits. The monthly refresh runs the automated pipeline and re-clears the reconciliation gate, so drift is caught the month it appears rather than at year end. The mapping table and the time equations are version-controlled and carry sign-off, so a change in the org structure or a new product line updates the model deliberately rather than by accident. Ownership sits with the client's finance team, with us on hand for the periodic review, so the model does not depend on any one person's memory. The same governed inputs then extend naturally into activity-based management and profitability KPIs, so the recaptured margin stays visible on the board dashboard and the gains show up in the numbers quarter after quarter. The costing stays rigorous; the model stays yours.
- How long does the journey from first contact to a live model take?
- For a mid-market company with usable ERP data, a decision-grade model can be live in weeks rather than quarters. TDABC needs only two inputs per activity, a capacity cost rate and a time equation, so a first model can be stood up quickly and refined as decisions are chosen. Many clients start with a fixed-scope Profitability Health Check to size the prize, then move into the full build once the shape of the answer is clear.
- Why does TDABC matter so much in your approach?
- Time-driven activity-based costing is what makes the model both fast and defensible. It reduces costing to two numbers per activity, the cost of supplying capacity and the time each transaction consumes, which lets us build on data a company already keeps and separate the cost of work done from the cost of idle capacity. Years of hands-on implementation are what let us choose the right granularity and drivers, the judgements that decide whether a model ages well or falls apart.
- Do we keep the model, or does it leave with the consultant?
- You keep it. The pipeline is built in whatever tool your data team already trusts, the model design is documented, and ownership sits with your finance team. We are the implementation partner across the whole chain, from diagnostic to governance, but the deliverable is an auditable model your team can run without us, not a black box that walks out the door.
- How do you make sure the numbers are trustworthy before we act on them?
- Two gates. Every cost loaded into the model must reconcile to the audited trial balance to the cent, and that check is automated so it runs on every refresh. Then the results go to a challenge session with the operations and commercial teams to test them against reality and catch any broken driver logic, which is the one error a reconciliation cannot find. Only a model that survives both gates is used for a decision.
- What happens after the model goes live?
- Governance keeps it true. A monthly refresh runs the automated pipeline and re-clears the reconciliation gate, the mapping table and time equations are version-controlled with sign-off, and ownership sits with your team with us on hand for periodic review. The same governed inputs extend into activity-based management and profitability KPIs, so the recaptured margin stays visible and the model stays trusted for years rather than decaying into a stale spreadsheet.
Sources & further reading: Robert S. Kaplan & Steven R. Anderson, Time-Driven Activity-Based Costing (Harvard Business Review, 2004; Harvard Business Review Press) · OECD, Guidance for the Standard Audit File - Tax (SAF-T) · IMA and practitioner literature on activity-based costing implementation and data requirements