A spreadsheet is the right place to prototype a costing model and the wrong place to run one every month. The failure is not the formula, it is the scale: version chaos, no traceability, fragile driver logic and a single person who understands the file. A purpose-built profitability engine keeps the same logic but makes each run repeatable in minutes, every number traceable to its source, and the whole model defensible in front of a board.
Ten minutes, fourteen questions, the full result on screen, no email required. If you already trust your margin by customer, you do not need it.
CostCtrl vs Spreadsheets for Profitability Modelling
Quick answer. A spreadsheet is the right place to prototype a costing model and the wrong place to run one every month. The failure is not the formula, it is the scale: version chaos, no traceability, fragile driver logic and a single person who understands the file.
Spreadsheets are excellent for the first version of a profitability model: they are fast, flexible and everyone already has one. What they are not built for is repeatability at scale. Once a costing model has to be rerun every period, reconciled to the ledger, explained to auditors and survive the analyst who built it moving on, the spreadsheet's strengths become liabilities. There is no reliable version history, no lineage from a reported margin back to the driver and source data behind it, and driver logic buried across thousands of linked cells that no one dares touch. Independent research has found errors in close to 90% of audited operational spreadsheets, and the largest were not typos but structural failures that survived every review. A purpose-built engine such as CostCtrl keeps the accounting logic a good analyst would build by hand, and adds what the spreadsheet cannot: a model that reruns in minutes on new data, a full audit trail from any output back to its inputs, AI-assisted model build, and role-based controls that make the result defensible rather than merely plausible. The rule of thumb: prototype in a spreadsheet, then move to an engine the moment the model becomes something you rely on rather than something you rebuild.
The instinct to defend the spreadsheet is understandable, and largely correct for the job it was designed to do. Modelling a cost allocation for the first time, testing a driver, sketching a whale curve for one business unit: a spreadsheet is the fastest tool on earth for that. The problem is that a profitability model rarely stays a one-off. It becomes the monthly management pack, the number the board sees, the basis for a pricing decision. And the qualities that made the spreadsheet fast to build, unconstrained cells, ad-hoc formulas, copy-and-paste, are exactly the qualities that make it dangerous to run repeatedly.
Consider what "run the model again" actually means in a hand-built file. Someone opens last month's workbook, saves a copy with a new name, pastes in fresh actuals, prays that no formula range silently failed to extend, checks a few totals, and ships it. Every step is manual, and each is a place for an undetected error. Raymond Panko's review of field audits found that the large majority of operational spreadsheets contain at least one error, and cell-level error rates that compound with size. The European Spreadsheet Risk Interest Group (EuSpRIG) has catalogued the consequences for years, from Fidelity's missing minus sign to Fannie Mae's €1bn-scale restatement traced to a spreadsheet. The most instructive case is JPMorgan's 2012 "London Whale" loss: the US Senate Permanent Subcommittee on Investigations found the risk model ran through a chain of Excel workbooks completed by manually copying and pasting between them, and one step divided by a sum where it should have divided by an average. That single structural error understated risk and contributed to a loss measured in billions. None of these were arithmetic mistakes. They were failures of traceability, controls and repeatability, which is precisely the axis on which spreadsheets and purpose-built engines diverge.
The comparison below is not spreadsheet-versus-software in the abstract. It is what changes when a profitability model moves from a hand-run workbook to a purpose-built costing engine, holding the accounting logic constant. The point is not that one is good and the other bad: it is that they are optimised for different phases. A spreadsheet wins the first build; an engine wins every build after that.
| Dimension | Hand-run spreadsheet model | Purpose-built engine (CostCtrl) |
|---|---|---|
| Build time (first version) | Fast: an experienced analyst can prototype in hours | Comparable, and AI-assisted: the engine drafts cost pools, drivers and mappings from your data for the analyst to refine |
| Refresh / rerun | Manual paste of new actuals, hours of checking, high risk a range or link silently breaks | Repeatable run in minutes on new source data, with the same logic applied identically every period |
| Traceability | A reported margin is the end of a chain of cells no one can fully reconstruct | Every output traces back through its drivers to the source transaction, on demand |
| Audit & controls | No native change log; who changed which assumption, and when, is usually unknown | Versioned models, recorded assumption changes and role-based access, so the model is defensible under review |
| Scale (products, customers, periods) | Degrades as rows and links multiply; large files slow, corrupt or exceed practical limits | Built for millions of transaction rows and full customer and product granularity |
| Key-person risk | The logic lives in one person's head and one fragile file | The model is an explicit, documented object the team and successors can read and run |
Read the table as a phase transition, not a verdict. Everything in the left column is acceptable, even ideal, while a model is being invented. Everything in the left column becomes a business risk the moment that model is something the organisation depends on month after month.
The method is on this page. What it would find in your numbers is not. The Profit Check scores seven dimensions of your costing in ten minutes and names the gap worth closing first. If you already have your margin by customer and by product in a number you trust, you do not need it.
Take the Profit CheckThe upgrade is not about replacing the analyst's judgement, which no tool can do. It is about removing the manual, error-prone mechanics that sit between the judgement and the answer. Four capabilities separate an engine from a workbook, and each maps directly onto a spreadsheet failure mode.
Repeatable runs. The model is defined once as logic, cost pools, drivers, allocations and mappings, and then executed against whatever period's data you load. Rerunning next month is not a rebuild; it is a run. That collapses a multi-day close-and-check cycle into minutes and, more importantly, guarantees the same rules are applied every time, so a change in the result reflects a change in the business rather than a change in how someone happened to paste the file together.
Full traceability. In CostCtrl, any figure, a product's cost, a customer's net margin, a cost pool's total, can be opened back to the drivers and source records that produced it. This is the difference between a number you can assert and a number you can defend. When a CFO or an auditor asks "why is this customer showing a loss?", the answer is a drill-path, not a promise to go and check the workbook. It is also what makes time-driven activity-based costing honest at scale: the cost split is reproducible because its lineage is preserved.
AI-assisted build. A purpose-built engine can read your ledger and transactional data and propose an initial model, suggesting cost pools, candidate drivers and account mappings for the analyst to accept, adjust or reject. This is where the tooling landscape has moved: enterprise planning platforms such as Anaplan and Pigment have made model-as-software the norm for planning, and CostCtrl applies the same discipline specifically to cost and profitability. The analyst still owns the model; the engine removes the tedium of wiring it together from scratch.
Defensibility. Versioning, recorded assumption changes and role-based access turn the model from a black box into an auditable object. When the mix, the pricing or the cost-to-serve conclusion is challenged in a board meeting, the model can show its working. A spreadsheet can be right and still lose that argument because it cannot prove it is right.
Most profitability models do not fail suddenly. They decay, one shortcut at a time, until the file everyone relies on is one nobody trusts. These are the failure patterns we see most often, and each is a signal that the model has outgrown the spreadsheet.
| The pitfall | Why it bites, and what to do |
|---|---|
| Version chaos ("model_final_v7_REAL.xlsx") | Parallel copies drift apart and no one knows which is authoritative. A single versioned model with a change log removes the question entirely. |
| Broken traceability | A number is quoted with no path back to its drivers, so it cannot be defended or corrected. Insist that every output can be drilled to its source before it reaches a decision. |
| Fragile driver logic | Allocation rules hard-coded across thousands of linked cells break silently when a range or sheet changes. Drivers should be defined once as logic, not scattered as formulas. |
| Slow, manual refresh | A close that takes days of pasting and checking means the model is always stale and rarely re-examined. If a rerun is not measured in minutes, the model will not keep pace with the business. |
| Key-person risk | When the only person who understands the file leaves, the model effectively leaves with them. Make the model an explicit, documented object, not tribal knowledge. |
| Unaudited assumptions | Rates and allocation bases are changed without record, so results shift for reasons no one can reconstruct. Every assumption change should be logged and attributable. |
The common thread is that each pitfall is invisible while the model is small and fatal once it is load-bearing. The discipline that fixes them, versioning, lineage, logic-not-cells, controlled assumptions, is exactly what a costing engine provides by construction, and what a spreadsheet can only approximate through heroic manual effort. For a smaller finance team weighing how far to take this, the proportionate route is set out in enterprise profitability for SMEs.
Where spreadsheets win. For a first pass, a one-off analysis, a sanity check or a model you are still inventing, nothing beats a spreadsheet. It has zero setup cost, infinite flexibility and a universal skill base. A good analyst thinking through a new cost-to-serve logic or a product-mix question should reach for one first. The mistake is not using a spreadsheet; it is keeping a spreadsheet in production after the analysis has become a recurring dependency. Treat the workbook as the sketch, not the system of record.
Where they stop. The line is repeatability. The moment a model has to be rerun on a schedule, reconciled to the ledger, explained to someone who did not build it, or trusted by a board, the spreadsheet's flexibility becomes uncontrolled risk. That is the point to move the logic into an engine, and it is worth being honest that this is a project, not a button: the value of a tool-agnostic partner is getting the accounting right first, then choosing the platform. Cost and Profitability builds the model on sound method regardless of the tool, and where a repeatable engine is the right answer, CostCtrl is where that logic lives. The related reading below traces the methods this tooling is meant to serve: cost-to-serve analysis, activity-based management, profitability KPIs and performance measurement, product-mix optimization and economic value added. Get the method right, and the choice of tool becomes a question of scale, not of principle.
Panko, R. R. What We Know About Spreadsheet Errors and related field-audit reviews (error rates in operational spreadsheets). · European Spreadsheet Risk Interest Group (EuSpRIG), Horror Stories (documented public spreadsheet failures in finance). · US Senate Permanent Subcommittee on Investigations, JPMorgan Chase Whale Trades (risk model built and run through manual Excel workbooks). · Kaplan, R. S. & Anderson, S. R. Time-Driven Activity-Based Costing (repeatable, driver-based cost models).
Proof
A distributor in New Zealand. €1.335M of cost-to-serve made visible, then halved, and 830 loss-making customers brought down to 295.
Read the case study →Who you would be talking to
Miguel Guimarães, Founding Partner
Cost and profitability practitioner for 25+ years. Presented the Damco cost-to-serve case at Managing for Profit (Amsterdam RAI, December 2009), on the same programme as Robert S. Kaplan.
Call +351 910 313 731
Workshops
One working profitability model, built from real data, that you take home at the end.
Reserve a seat
Reviewed by
Miguel Guimarães
Founding Partner, Cost and Profitability Consulting
More than 150 Time-Driven ABC engagements across 11 sectors since 2010, working within the Kaplan and Anderson framework.
About the author →Published
Done. There is nothing here to refuse. This site retired advertising on 27 August 2026, and no advertising or tracking tag runs on it for anyone. Your remaining choices, session recording and audience measurement, are under “Cookie settings” at the foot of any page.
We are asking again. Your last answer is more than 12 months old, so it has been cleared. Nothing is switched on until you answer.
This notice has changed. Your previous answer was given to different wording, so it has been cleared and we are asking again. Nothing is switched on until you answer.
Say yes and we learn which pages help. Say no and nothing on this site changes.
Session recording. Microsoft Clarity records how this page is used - mouse movement, clicks and scrolling - so we can improve it. Form fields are always hidden from the recording.
Audience measurement. Google Analytics 4 counts your visit and the path you take through the site, so we can see which pages are useful. It stores two cookies of our own domain, _ga and _ga_L5HNZN655T, holding a randomly generated identifier for your browser - so these statistics are not anonymous. Nothing is loaded until you say yes.