Ask a large language model to draft a TDABC cost model and it will happily produce one: cost pools, candidate drivers, a capacity cost rate, even a plausible-looking time equation. The output reads like something a competent analyst wrote. The trouble is not that it is wrong in an obvious way - a model with an obviously wrong number gets caught quickly. The trouble is that it is wrong the way a bright graduate with no domain experience is wrong: fluent, well structured, and quietly built on assumptions nobody in your business ever confirmed.
Can an LLM draft a cost model, and where does it get it wrong?
An LLM can draft the shape of a cost model quickly: cost pools, candidate drivers, a plausible structure to react to. That first pass is genuinely useful. It gets it wrong wherever the model needs facts about your business that were never in its training data - your actual practical capacity, your real driver volumes, which costs are truly fixed at your scale versus step-fixed. Use it to draft the skeleton, never the numbers that go inside it.
What it is actually good at
Given a description of a business, an LLM will produce a sensible list of candidate cost pools and a first cut of drivers that is rarely embarrassing. It knows the vocabulary of costing, it has read a great deal of accounting literature, and it is fast at turning a rough description into a structured starting point. For a team staring at a blank spreadsheet, that first draft can save a genuinely useful afternoon. It is also good at explaining a method back to a non-specialist, and at generating the documentation nobody wants to write by hand.
Where the training data runs out
A cost model is only correct if its numbers describe your operation, and none of those numbers were in any training set. Your practical capacity - the minutes a team actually has available once holidays, training and idle time are accounted for - exists only in your rosters and your ERP. Your driver volumes, the number of setups or order lines or support tickets your business actually produced last quarter, exist only in your systems. An LLM asked to estimate any of these will produce a number that sounds specific and is, in fact, a guess dressed as a fact. It has no way to flag the difference, because language models are built to sound confident, not to signal uncertainty about a fact they cannot check.
The overhead allocation trap, specifically
Ask a model to suggest a driver for IT overhead and it will often propose headcount, because headcount is the driver most frequently mentioned in the textbooks and case studies it was trained on. Headcount is convenient and almost never causal: two departments with the same number of people can consume wildly different amounts of IT support depending on how many systems they touch and how complex their work is. A model has read thousands of examples where headcount was used as a driver and very few where someone explained why it was the wrong choice for that specific business. It reproduces the popular answer, not the correct one for you.
A workable division of labour
The useful split is structure versus fact. Let the model draft the list of cost pools, propose candidate drivers to react to, and write the first explanation of the method for people who were not in the room. Do not let it invent a capacity figure, a driver volume, or a percentage split between activities - those come only from your ERP, your timesheets, your rosters, or a genuine time study. A model can accelerate the parts of the work that are about organising known facts. It cannot manufacture the facts themselves, however confidently it writes the sentence containing them.
An LLM can write a very convincing sentence about a number it has never seen. That is precisely the failure mode a cost model cannot afford.
What to check before you trust an AI-drafted model
Before any AI-drafted allocation goes near a pricing or a board decision, trace every number back to its source. If a driver volume cannot be pointed at a specific report or system, it is an assumption and should be labelled as one, not published as a fact. Ask whether doubling the driver would plausibly double the cost - the causality test still applies whether a person or a model proposed the driver. And ask whether someone in the business who actually does the work would defend the number in a room. If the answer to any of those is no, the draft needs a human with the real data before it becomes a decision.
The Profit Check is free, takes a few minutes, and is built on your real data, not an AI guess. It tells you where you are making and losing money.
Related reading: where LLMs get overhead allocation wrong and moving from spreadsheets to a real costing model.