The cost driver library: what actually moves the minutes
Quick answer. A cost driver is the characteristic of a transaction that changes how long the work takes. A good driver passes three tests: it moves the minutes materially, it already exists as a field in your data, and the people who do the work recognise it. In time-driven activity-based costing the driver enters a time equation as a term, and the minutes are priced at the capacity cost rate. This page is a lookup table of the drivers we use, activity by activity, across six areas of a business.
Every costing project reaches the same morning. Somebody asks what we should drive invoicing on. Or picking, or a service call, or a machine changeover.
This is the answer we give, written down: the driver that moves the minutes, the shape of the time equation, the field in your systems that carries the driver, and the mistake people make with it.
Why the driver, not the average, decides the number
Traditional costing picks one driver for everything, usually volume, revenue or headcount, and spreads cost across it. The result looks fair and is quietly wrong. The simple high-volume work carries cost it never caused, and the fiddly low-volume work gets a discount nobody granted. We wrote about that failure in the overhead allocation problem.
Choosing drivers properly is how you fix it. Not by finding more drivers, which is how classic activity-based costing collapsed under its own weight, but by finding the few that genuinely change the work. A driver earns its place when removing it would visibly change the answer.
Three tests a driver has to pass
- Does it move the minutes? If doubling the driver does not noticeably change how long the task takes, it is a label, not a driver. Ask the person who does the work, then check a sample.
- Is it already in your data? A driver you cannot populate for every transaction models nothing. It has to exist as a column in the ERP, the warehouse system, the ticket log or the billing extract.
- Would the team recognise it? Drivers get defended in meetings. If a supervisor cannot look at the term and say yes, that is what makes it longer, the model will not survive its first challenge.
How a driver enters the equation
A time equation estimates the minutes one execution of a process consumes: a base time for the standard case, plus a term for each driver. Quantities enter as multipliers, conditions enter as flags worth zero or one.
Cost of the transaction = T × capacity cost rate
The worked warehouse example on our time equations reference shows the shape with illustrative figures: picking time = 3 + 0.8 × (order lines) + 6 × (refrigerated flag) + 12 × (export documentation flag). A base time and three terms, and it already separates a seven-minute domestic order from a forty-five-minute export one. The library below gives you the terms. Your own observation gives you the coefficients.
The driver is the question the work is answering. Get the question right and the coefficients are arithmetic.
Drivers for order handling, invoicing and collections
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Order entry | Order lines; channel (manual, EDI, portal) | base + per line + flag for manual channel | Sales order header and line tables | Costing per order value. A large order is not a long order. |
| Order amendment | Amendments after confirmation | base per amendment + flag for post-dispatch change | Order change log, revision counter | Amendments are usually invisible because they overwrite the original record. |
| Credit check and release | Blocked-order flag; manual releases | flag × release time | Credit management block table | Averaged across all orders, so the few chronic accounts pay nothing. |
| Invoicing | Invoice lines; flag for bespoke format or portal upload | base + per line + flag for portal submission | Billing extract, invoice header | Customer portals and bespoke formats add real minutes and appear nowhere in the ledger. |
| Credit notes and disputes | Credit notes; flag for dispute needing investigation | base per note + flag × investigation time | Credit note document type | Treated as a finance cost rather than a cost of serving that customer. |
| Collections | Chase contacts; days beyond terms | base per contact + per additional reminder | Dunning history, aged debt report | Slow payers rarely show up in profitability because collections sits below the line. |
Shapes, not coefficients. The minutes behind each term come from your own observation.
Drivers for receiving, picking and dispatch
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Goods receiving | Pallets or cartons received; flag for quality inspection | base + per pallet + inspection flag | Inbound receipt document | Driven on purchase value, which has nothing to do with handling time. |
| Put-away | Storage locations touched; flag for temperature-controlled zone | base + per location + zone flag | Warehouse system movement log | Ignored entirely because it happens before the sale. |
| Picking | Order lines; units per line; flag for special handling | base + per line + per unit + handling flag | Pick confirmation records, line counts | Using order count alone, which flattens a two-line order and a sixty-line one. |
| Packing | Cartons built; flag for gift, kit or bespoke labelling | base + per carton + labelling flag | Packing list, carton count | Customer-specific packing is a service, and it is almost never priced as one. |
| Dispatch and documentation | Shipments; flag for export documentation or dangerous goods | base per shipment + documentation flag | Shipment header, incoterm and country fields | Export paperwork is one of the largest hidden differences between two similar customers. |
| Returns handling | Return lines; flag for inspection, repack or scrap | base + per line + disposition flag | Returns document, disposition code | Returns are netted against revenue, so the work they cause disappears. |
Drivers for routes, drops and redeliveries
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Route planning | Drops planned; flag for time-window constraint | base + per drop + window flag | Transport planning export | Time windows are agreed by sales and paid for by operations. |
| Delivery drop | Drops; flag for tail lift, in-store delivery or booked slot | base per drop + access flag + waiting time | Proof-of-delivery timestamps | Cost per kilometre instead of cost per stop. Stops, not distance, consume the day. |
| Waiting at delivery | Recorded waiting minutes at site | measured minutes, straight through | Telematics, or arrival and departure stamps | Waiting is treated as bad luck rather than as a customer characteristic. |
| Failed delivery and redelivery | Failed attempts | base per attempt + redelivery flag | Delivery status codes | Counted as a service metric, never converted into money. |
Drivers for customer service and account management
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Inbound contact | Contacts; channel (call, email, chat); flag for escalation | base per contact + channel term + escalation flag | Ticket or telephony system, contact log | Handling time is averaged across every account, so the noisy ones are subsidised. |
| Complaint resolution | Complaints; flag for investigation involving operations | base + investigation flag × time | Complaint or non-conformance log | The operations time spent investigating never reaches the customer's P&L. |
| Account management | Scheduled reviews; visits; flag for tender or annual negotiation | per review + per visit + tender flag | CRM activity records, calendar exports | Sales effort is called an investment, so no one asks which accounts consume it. |
| Customer onboarding | New accounts; flag for system integration, trial or bespoke setup | base per account + integration flag | CRM stage history, project log | A one-off cost that is never recovered from the accounts that churn quickly. |
| Reporting to the customer | Bespoke reports produced per period | base per report + per bespoke field | Nowhere. This one has to be captured deliberately. | Bespoke reporting is a promise made in a tender and costed by nobody. |
Drivers for setup, production and quality
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Setup and changeover | Changeovers; flag for a change between incompatible families | base per changeover + family-change flag | Production order sequence, work-centre log | Spread over annual volume, which makes short runs look as cheap as long ones. |
| Production run | Machine or labour minutes; units; flag for non-standard speed | per unit + speed-loss term | Work-centre confirmations, machine data | Standard run rates that were set years ago and quietly stopped being true. |
| Quality inspection | Inspections; sample size; flag for customer-specific certificate | base + per sample + certificate flag | Quality module, certificate requests | Customer-specific certificates and audits are given away in the contract. |
| Rework and scrap | Rework orders; flag for full disassembly | base per rework + disassembly flag | Rework order type, scrap postings | Booked to a cost centre, so it never reaches the product or customer that caused it. |
| Planning and expediting | Rush orders; replanning events | base per replan + rush flag | Order priority flag, schedule change log | Expediting is invisible work done by experienced people, which makes it expensive. |
Drivers for project, support and back-office work
| Activity | Driver that moves the minutes | Time-equation shape | Where the driver lives | Common trap |
|---|---|---|---|---|
| Scoping and proposal | Proposals produced; flag for bespoke pricing or legal review | base per proposal + review flag | CRM opportunity records | Pre-sale effort is excluded from engagement profitability by convention. |
| Delivery work | Billable hours; flag for out-of-scope requests | recorded hours + scope-creep term | Timesheets, project system | Timesheets record what was billed, not what was done. The gap is the margin. |
| Review and rework cycles | Review rounds per deliverable | base + per additional round | Document version history, approval log | The third and fourth review round is where a profitable engagement turns. |
| Support ticket | Tickets; severity; flag for out-of-hours | base + severity term + out-of-hours flag | Service desk system | Support is a flat percentage in the contract and a variable cost in reality. |
| Shared-service transaction | Transactions processed; flag for exception handling | base per transaction + exception flag | Process system, exception queue | Recharged by headcount, so the divisions that send exceptions pay the same as the tidy ones. |
Five drivers that look right and are not
These come up in almost every kick-off, because they are the fields everybody already has.
Revenue. Revenue measures what a customer pays, not what they make you do. It is the driver that guarantees your biggest customers look like your best ones.
Units or weight. Fine for a pure material cost, misleading for handling. Ten single-unit orders and one ten-unit order have the same units and very different cost.
Headcount. Common for allocating support functions. It says who is nearby, not who is served.
Square metres. Useful for rent and little else. It reflects a lease negotiation, not the work.
Number of customers. Splits a cost pool evenly and calls it fair. It is the average, wearing a driver's costume.
If you must start with one of these because the better field does not exist yet, say so in the model documentation and put the fix on the roadmap. A documented approximation is honest. A silent one is the reason models lose their credibility a year in.
How many drivers a model actually needs
Fewer than people expect. One time equation per process, carrying the two to four terms that matter, beats one equation per variation. A focused cost-to-serve model runs on a handful of processes: order handling, picking and packing, delivery, invoicing, returns. A full mid-market profitability model typically lands between 10 and 40 equations in total.
The discipline that keeps a model healthy is subtractive. Add a term when a driver visibly moves the minutes and the data can carry it. Add an equation only when a genuinely distinct process appears. Every extra term is something a controller has to maintain, explain and defend, and decorative precision is the most common reason a model stops being updated. We have watched that happen often enough to write about it in why costing models fail after go-live.
Once the terms are chosen, the minutes still have to become money. That conversion is the capacity cost rate, and it is derived line by line in the TDABC reference and covered in capacity costing. The full build sequence lives in how to build a TDABC model.
Fair questions.
- What is a cost driver?
- A cost driver is the characteristic of a transaction that changes how much work it causes, and therefore how much cost it consumes. In time-driven activity-based costing the driver enters a time equation as a term, so the minutes charged to a transaction reflect what made it longer: the number of order lines, a special handling requirement, an extra review round, an expedited schedule.
- What are examples of cost drivers in activity-based costing?
- Order lines for picking and invoicing, cartons for packing, drops for delivery, changeovers for machine setup, contacts for customer service, review rounds for professional work, exceptions for shared-service processing. Conditions work as drivers too, entered as flags worth zero or one: refrigerated, export documentation, out-of-hours, bespoke labelling, dispute under investigation.
- How do I choose the right cost driver?
- Three tests. It has to move the minutes materially, so doubling it visibly changes how long the task takes. It has to exist as a populated field in your systems, because a driver you cannot measure for every transaction models nothing. And the people who do the work have to recognise it, because the model will be challenged and someone has to be able to defend it.
- How many cost drivers should a model have?
- Far fewer than newcomers expect. One time equation per process rather than per variation, with two to four terms each. A focused cost-to-serve model needs a handful of processes; a full mid-market profitability model typically lands between 10 and 40 equations. Extra terms have to earn their place, because every one of them is something a controller will have to maintain.
- Why is revenue a bad cost driver?
- Because revenue measures what a customer pays, not what they make you do. Allocating service cost on revenue guarantees that your largest accounts look like your most profitable ones, which is exactly the illusion cost-to-serve analysis exists to remove. The same objection applies to headcount, square metres and a flat split per customer.
- Where do the driver values come from?
- From the systems you already run: order and invoice lines from the ERP, pick and movement records from the warehouse system, drops and waiting time from proof-of-delivery timestamps, contacts from the service desk, changeovers from the work-centre log. Usually one or two drivers per model have no home yet and need to be captured deliberately, which is normal and worth flagging in the model documentation rather than approximating in silence.
Which drivers are hiding in your business?
The free Profit Check tells you whether your cost model can see the work that actually varies, or whether it is still spreading averages.
- Duration
- 12 to 15 minutes
- You receive
- Score, 7 dimensions, sector benchmark
- Price
- Free, no email needed
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, Founder
Cost and profitability practitioner since 2010. Lectured alongside Professor Robert S. Kaplan at the CFO conference in Amsterdam (2009).
Call +351 910 313 731
