Enterprise Costing, Then vs Now
This is a composite scenario drawn from real field experience across cost-model implementations; the details, sector and figures are illustrative and represent no single client. For a generation, getting a defensible enterprise cost model meant a multi-year build on a heavyweight platform, a seven-figure budget, and a dependence on scarce specialists that often left the model dead within a year of go-live. The modern stack does the same job in days, keeps it alive in the client's own hands, and makes every number traceable, and once you have seen both, the old way is hard to defend.
The heavyweight-platform era of enterprise costing was not a mistake for its time; it was the only way to allocate cost at scale before the tools caught up. But its economics were punishing: a large enterprise costing suite, a global advisory firm to configure it, eighteen to thirty-six months of build, and a model so intricate that only a handful of people ever understood it. When those people rotated off, the model calcified, accurate on the day it was signed off, and quietly wrong every month after. The modern approach inverts every one of those constraints. A small specialist team, a purpose-built costing engine (CostCtrl), and AI to accelerate the mapping and the narrative deliver a first working model in days, not quarters, at a fraction of the old cost, with a structure the client's own finance team can maintain and a full audit trail behind every allocated euro. The point is not that software got cheaper. It is that costing stopped being a construction project and became a living capability. This page sets the two eras side by side, fairly, and shows why the second one wins.
How enterprise costing used to be built
Picture a large, capital-intensive infrastructure operator around 2019 (a composite, not a single organisation). The board wants to know what each service line, asset and customer segment actually costs to run. The received answer, then, was a programme: license a heavyweight enterprise cost-management platform, engage a Big Four firm to configure it, and stand up a project office to run the build. The platform was genuinely powerful, it could model tens of thousands of cost objects and drivers, and that power was exactly the problem. Every strength came with a matching weight.
The build unfolded over quarters, not weeks. Requirements workshops, a driver dictionary, allocation rules encoded by consultants, reconciliation against the general ledger, then a validation cycle that alone could run for months. Representative figures for a programme of this size (illustrative): eighteen to thirty-six months of elapsed time and a budget well into seven figures once licences, system integration and internal effort were counted. When the model finally went live it was, on that day, a serious piece of work, a defensible answer to a hard question. The difficulty was everything that came after day one.
Accurate at go-live, wrong by the next quarter
The failure was rarely dramatic. A heavyweight cost model does not crash; it drifts. The business reorganises, a cost centre is renamed, a new service launches, an asset is retired, and each change needs a specialist to re-encode the allocation logic. Because the model was built for the client rather than by them, that specialist was usually external, expensive, and no longer on site. So the small changes queued, the workarounds multiplied, and within a year the model that cost a fortune to build was being politely ignored in favour of a spreadsheet someone trusted. This is the pattern a defensible cost split is supposed to end, not repeat (see CostCtrl versus spreadsheets).
None of this is anecdotal. The Standish Group's long-running CHAOS research has for years shown that large IT-enabled programmes are the ones most likely to be challenged or fail outright, with success rates falling as project size rises. The Project Management Institute's Pulse of the Profession has repeatedly put the share of budget lost to poor project performance in the double digits. And Gartner's analytics research has long reported that a large majority of sophisticated analytical models never reach sustained production use, not because the analysis was wrong, but because adoption, ownership and maintenance were treated as an afterthought. A cost model is exactly this kind of asset: its value is not in the go-live, it is in the fiftieth month of trustworthy use. The old delivery model optimised the launch and neglected the life.
A specialist team, a purpose-built engine, and AI
The modern answer is not a bigger platform. It is a different shape of delivery, made of three parts. First, a small specialist team that lives in cost and profitability work and brings the method rather than reinventing it, time-driven activity-based costing done properly, so the driver logic is transparent instead of buried (the foundations sit in activity-based management). Second, a purpose-built costing engine, CostCtrl, designed for exactly this job: it is opinionated about cost pools, drivers and capacity, so the structure that took a heavyweight suite months to configure is largely there on arrival. Third, AI to do the slow, mechanical parts, mapping a chart of accounts to cost pools, drafting time equations from process descriptions, reconciling to the ledger, and writing the first-pass narrative a finance team can review rather than compose.
The compound effect is a first working model in days. Not a toy: a model that ties to the general ledger, respects the cost of unused capacity (see cost of unused capacity), and produces a profitability view leadership can act on in the first workshop rather than the fourth quarter. Because CostCtrl is purpose-built and the logic is explicit, the same team that saw the model built can maintain it. The specialist configures the first version and teaches the pattern; the client's own analysts carry it forward. Costing stops being something that is delivered to the business and becomes something the business owns.
The two eras, side by side
The table sets the heavyweight-platform era against the modern stack across the dimensions that actually decide whether a cost model earns its keep. The figures are illustrative and representative of programmes of this type, not verified results from any single client.
| Dimension | Then: heavyweight platform era | Now: specialist team + CostCtrl + AI |
|---|---|---|
| Time to first model | 18-36 months of build and validation before leadership sees a usable view (illustrative) | A first working model in days; a refined, ledger-tied version in weeks (illustrative) |
| Total cost | Seven figures once licences, integration and internal effort are counted (illustrative) | A fraction of the old cost, a small fixed-scope engagement plus a subscription engine (illustrative) |
| Maintainability | Changes need a scarce, usually external specialist; small edits queue for weeks | The client's own finance team maintains the model; changes are made in the workshop, not in a change request |
| Traceability | Powerful but opaque; allocation logic understood by a handful of people | Every allocated euro traces back through driver and cost pool to the source ledger line |
| Key-person risk | High; the model lives and dies with named specialists who rotate off after go-live | Low; the method is explicit and taught, so no single person is the model |
| Likelihood of surviving past go-live | Low; often quietly abandoned within a year as it drifts out of date | High; designed to be updated monthly by the people who use it |
Read down the last column and a pattern emerges: every advantage of the modern stack is really the same advantage wearing different clothes, ownership. Speed, cost, maintainability, traceability and survival all follow from a model the client can actually hold. The old world outsourced understanding; the new world builds it in.
What the heavyweight era got right
It would be a straw man to pretend the old approach was foolish. It was the rational response to a real constraint. Before purpose-built engines and capable AI, allocating cost across tens of thousands of objects genuinely required an industrial platform and specialist hands, and the heavyweight suites did things smaller tools of the day could not. The discipline those programmes imposed, a driver dictionary, formal reconciliation, a validated audit trail, is exactly the discipline the modern stack keeps. Time-driven activity-based costing itself, the method underneath all of this, was formalised by Kaplan and Anderson precisely to tame the complexity that early activity-based costing collapsed under. The modern approach does not reject that lineage; it inherits it and sheds the weight.
What changed is not the ambition but the cost of achieving it. The old model paid for its rigour with time, money and fragility. The modern model keeps the rigour and stops paying those three prices, which is only possible because the engine is purpose-built and the mechanical work is automated. When a large enterprise costing suite is genuinely the right tool, a handful of the very largest, most idiosyncratic environments, it still is. For the overwhelming majority of organisations that once assumed they needed one, they no longer do. The honest comparison is not "old bad, new good"; it is "the constraint that justified the old way has lifted."
Where the modern approach can still go wrong
Speed is a temptation as well as a virtue. A first model in days is only valuable if the inputs beneath it are real, and the failure mode of the new stack is the mirror image of the old one: instead of over-building, teams under-validate. A few pitfalls recur. Confusing fast with finished: the day-one model is a starting hypothesis, not a signed-off answer, and it still needs reconciliation to the ledger and a sanity check against how the business actually behaves. Letting AI encode a plausible-but-wrong driver: a language model will happily draft a time equation that reads well and allocates badly, so the specialist has to own the logic, not rubber-stamp it. Skipping the capacity question: a model that ignores unused capacity flatters busy periods and punishes quiet ones, which is why the cost of unused capacity has to be explicit from the start.
There is also an adoption trap the old world knew well and the new world can still fall into. A model the client cannot maintain will die whatever built it, so the handover is not a phase at the end, it is the design principle from the beginning. If the specialist team leaves and the finance function cannot make next month's change unaided, the engagement has failed regardless of how fast the first model appeared. Judged the right way, the modern stack is measured not by time-to-first-model but by whether the model is still trusted and current a year later. That is the same test the heavyweight era so often failed, and it is the one worth holding the new approach to. It is also why profitability work should be tied to the metrics leadership already watches (see profitability KPIs) and, for investors, to the diagnostics that reveal where portfolio value actually sits (see private-equity portfolio profitability diagnostics).
Common questions about enterprise costing, then and now
- Why did traditional enterprise cost models fail after go-live?
- Not by crashing, but by drifting. Heavyweight cost models were built for the client by external specialists, so every change to the business, a reorganisation, a new service, a retired asset, needed one of those specialists to re-encode the allocation logic. After go-live the specialists rotated off, changes queued, and the model gradually diverged from reality until people stopped trusting it. Research on large programmes points the same way: the Standish CHAOS studies show big IT-enabled builds are the most likely to be challenged, and Gartner has long reported that most analytical models never reach sustained production use. The value of a cost model is in its fiftieth month of use, and the old delivery approach optimised the launch instead of the life.
- How can a credible cost model be built in days rather than months?
- Because the slow parts have been removed, not skipped. A purpose-built costing engine like CostCtrl already encodes the structure, cost pools, drivers, capacity, that a general-purpose enterprise suite took months to configure. AI handles the mechanical work of mapping the chart of accounts to cost pools, drafting time equations from process descriptions, and reconciling to the ledger. A specialist team brings the method rather than inventing it. What is left is judgement, which is where the human effort concentrates. The result is a first working model in days that ties to the general ledger, a hypothesis to refine, not a finished audit, but a genuine one.
- Is a heavyweight enterprise cost-management platform ever still the right choice?
- Occasionally, yes. A small number of the very largest and most idiosyncratic environments have modelling needs that genuinely justify an industrial platform, and where that is true it remains the right tool. But for the overwhelming majority of organisations that once assumed they needed one, the constraint that justified it has lifted. A purpose-built engine plus a specialist team plus AI now delivers the same rigour, reconciliation, an audit trail, defensible drivers, without the multi-year build, the seven-figure budget or the fragility. The honest test is whether the extra platform weight buys anything the modern stack cannot; usually it does not.
- How do you keep a fast-built model from being fast but wrong?
- By treating the day-one model as a starting hypothesis and validating it deliberately. The three checks that matter most: reconcile every allocation back to the source ledger so nothing is invented; have the specialist own each driver and time equation rather than rubber-stamping an AI draft that reads well but allocates badly; and make the cost of unused capacity explicit so busy and quiet periods are treated fairly. Speed comes from removing mechanical work, not from removing scrutiny. Done this way, fast and correct are not in tension.
- What does it mean for the client to own the model, and why does it matter?
- Ownership means the client's own finance team can make next month's change without calling anyone. Because CostCtrl is purpose-built and the logic is explicit rather than buried in bespoke configuration, the specialist configures the first version and teaches the pattern, and the internal analysts carry it forward. This matters because it is the single factor that most separates models that survive from models that die. A cost model the business cannot maintain will be abandoned whatever built it; a model it can maintain stays current, stays trusted, and keeps earning its keep long after the engagement ends.
References
The Standish Group, CHAOS Report (success, challenge and failure rates of IT-enabled projects, and how they worsen with project size). · Project Management Institute, Pulse of the Profession (share of investment lost to poor project performance). · Gartner, research on analytics and data-science adoption (the majority of advanced analytical models never reach sustained production use). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (Harvard Business Review, 2004; book, Harvard Business Press, 2007, the method underpinning transparent, maintainable cost models). · Kaplan, R. S. & Cooper, R. Cost & Effect (design and lifecycle of activity-based cost systems). For related reading see economic value added (EVA).