Every costing model rests on a handful of choices about what causes cost, and most of those choices were made quickly, by someone who was under pressure to produce a number by Friday. Years later the number is still being produced, the choice has never been revisited, and nobody in the room can explain why overhead is spread by headcount rather than by anything the departments actually do.
What is a cost driver and how do you choose the right one?
A cost driver is the measurable thing that makes a cost go up or down: the number of setups, the number of order lines, the minutes a machine runs. Choosing the right one means finding the factor that genuinely varies with the work, not the one that happens to be easy to measure. Test a candidate driver by asking whether doubling it would plausibly double the cost, whether the data already exists and is reliable, and whether the people whose costs it allocates would accept it as fair. If any of the three fails, it is a proxy, not a driver, and you should say so.
Driver, allocation base, and why the distinction matters
A lot of confusion disappears once you separate two ideas that are usually used interchangeably. An allocation base is whatever you divide by. A cost driver is the thing that causes the cost to exist. Direct labour hours can be both, but very often they are only the first: they are convenient, they are already recorded, and they have no causal relationship at all with the cost being spread across them.
This is the failure that activity-based costing was invented to fix. When a single volume-based base carries overhead that is actually driven by complexity, high-volume simple products absorb costs they never caused and low-volume complex products get a discount nobody granted deliberately. The model does not report an error. It reports a set of margins that are wrong in a consistent direction, which is far harder to notice.
The three tests a candidate driver has to pass
Causality comes first. If the driver doubled, would the cost plausibly double? Setups is a driver for setup cost because more setups means more setup work. Revenue is almost never a driver for anything, because revenue is a consequence of price, and price is a decision, not a cause of work.
Availability comes second, and it is where most good drivers die. A driver you cannot measure every period without a special project is not a driver you can run a model on. This is a real constraint, not a failure of ambition. It is better to use a slightly coarser driver you can pull from the ERP every month than a theoretically perfect one that requires someone to count things by hand.
Acceptance comes third, and it is the one that gets skipped. The people whose costs you are allocating have to find the logic defensible, because they are the ones who will have to act on the result. A driver that cannot survive a conversation with the operations manager will not survive contact with a pricing decision either.
Transactional, duration and intensity drivers
Drivers fall into three families, and picking the wrong family is a more common mistake than picking the wrong metric within a family. Transactional drivers count events: number of purchase orders, number of inspections, number of customer calls. They assume every event consumes the same resources, which is fine when the variation between events is small.
Duration drivers measure time: minutes of setup, hours of machine running, minutes on a call. They cost more to collect and they are the right answer whenever events differ substantially from each other. A ten-minute call and a ninety-minute call are not the same transaction, and a model that counts both as one call will quietly overcharge the easy customers.
Intensity drivers charge the actual resources used by a specific instance. They are the most accurate and the least practical, and outside of a handful of settings they are rarely worth the collection effort. Time-driven costing exists largely to get most of the accuracy of duration drivers without the cost of measuring everything, by using time equations that adjust a standard time for the few characteristics that genuinely change it.
A driver chosen for convenience does not remove the arbitrariness. It hides it inside a number that now looks precise.
How many drivers is the right number
More drivers do not mean a better model past a certain point, and the point arrives earlier than most people expect. Each additional driver adds data collection, maintenance and one more thing that can drift out of date without anyone noticing. The practical rule is to add a driver only when the cost pool it splits contains work that behaves in genuinely different ways, and when the resulting change in reported cost is big enough to change a decision.
Review the choices on a schedule rather than when something breaks. Drivers go stale because the business changes underneath them: a process gets automated, a product line is discontinued, a customer segment starts ordering in a completely different pattern. The driver that described the work accurately in 2023 may now be describing a process that no longer exists, and the model will keep producing confident numbers the entire time.
What to do with a driver you are not sure about
Write down that you are not sure. A model that labels its weak allocations is more useful than one that presents everything with the same confidence, because it tells the reader where to push back and where not to bother. Run the sensitivity: change the uncertain driver, see whether the ranking of your products or customers actually moves. Very often it does not, and you have just saved yourself an argument. When it does move, you have found the assumption worth spending real effort on, and you can go and measure it properly instead of measuring everything.
Our TDABC workshops are hands-on: you work through cost pools, activities and driver selection on a live model, using your own vocabulary rather than a textbook example.
Related reading: activity based costing, time-driven activity based costing and moving from spreadsheets to a real costing model.