Almost every costing model starts in a spreadsheet, and that is the right place to start. A spreadsheet is where you find out whether the idea works at all, before anyone has bought anything. The problem is not that the model began there. The problem is that it is still there three years later, it is now eleven linked files, and one person in the finance team is the only reason it still runs.
How do you move from spreadsheets to a real costing model?
Move the logic, not the file. First write down what the spreadsheet actually does: which costs it takes, how it splits them, and which assumptions are hard-coded inside formulas. Then rebuild that logic where the data lives, so cost pools, drivers and capacity are stored as structured records rather than cell references. Keep the spreadsheet running in parallel for one full period and reconcile the two, line by line, before switching anyone’s reporting over to the new model.
When a spreadsheet stops being the right tool
Spreadsheets do not fail suddenly. They degrade, and the symptoms are recognisable long before anyone calls it a problem. The month-end run takes a day instead of an hour. Nobody can say with confidence where a particular allocation percentage came from or when it was last reviewed. A question like “what would happen if we moved this product to the other line” cannot be answered without breaking something.
The clearest signal is different from all of these, and it is worth watching for: the model can no longer be handed over. When the only safe way to explain it is to sit next to the person who built it, the organisation does not own the model. One employee does. That is a business continuity issue dressed up as a finance issue, and it is usually what finally forces the move.
What “a real costing model” actually means
The phrase is vague enough to be sold badly, so it is worth being precise. A real costing model has four properties a spreadsheet almost never has, and none of them are about the software.
The inputs are separate from the logic. Costs, volumes and times arrive as data, not as numbers typed into the same cell as a formula. The logic is explicit and named. There is a defined list of cost pools, a defined list of activities, and a stated driver linking each one, rather than a percentage buried in a nested IF. The result is traceable in both directions. You can start from a customer’s cost and walk back to the ledger line that produced it, and start from a ledger line and see where it landed. And the model has a version. You can say what changed between March and April and who changed it.
The migration, in the order that works
Start by documenting the spreadsheet rather than replacing it. Open it and write down, in plain language, every place where a judgement was made: every allocation percentage, every rate, every exception someone added for one product and never removed. This step is tedious and it is the one that decides whether the project succeeds. Most spreadsheet models turn out to contain a handful of decisions that nobody currently in the building remembers making.
Then fix the cost structure before you touch any system. Decide what the cost pools are, what work the organisation actually performs, and what drives each pool. If you cannot describe the allocation in a sentence a department head would accept, moving it into a database only makes it harder to argue with. Bad logic in a proper model is worse than bad logic in a spreadsheet, because it now looks authoritative.
Only then look at where the model should live. The requirement is unglamorous: it has to pull its inputs from the systems that already hold them, recalculate without manual assembly, and let someone who did not build it change an assumption and see the effect. Capacity deserves particular attention. Spreadsheet models almost always push every cost onto output, which means idle capacity gets charged to whatever happened to be produced. A model worth migrating to keeps unused capacity visible as its own number.
A model nobody but its author can run is not an asset, it is a dependency.
Run both, then stop
Reconcile one complete period in both the spreadsheet and the new model, and explain every difference before you accept it. Some differences will be errors in the new model. Others will be errors in the spreadsheet that were never visible, and those are the ones that build trust, provided you can show why the new answer is the right one.
Then actually decommission the spreadsheet. Two models running in parallel indefinitely is the worst of both outcomes: twice the effort, and an argument available whenever someone dislikes a number. Set a date, agree the model of record, and archive the file rather than leaving it open on a shared drive. The point of the migration was never the technology. It was to make the cost of the work something the business can question, change and rely on without a single person in the room.
The CostCTRL demo shows a working time-driven model with live cost pools, drivers and capacity, so you can see how the same logic behaves once it is out of a spreadsheet.
Related reading: the data you need for a TDABC model, time-driven activity based costing and activity based costing software.