Activity-based costing projects rarely stall on method. They stall in the third week, when somebody asks what data the model will need and the answer comes back as a list long enough to justify moving the whole thing to next year. That list is almost always wrong. A first ABC model needs far less than the people assembling the list believe, and nearly all of it is already sitting in systems the company runs every single day.
What data do you need to start activity-based costing?
Four inputs. The cost ledger for one closed period, a list of the activities your teams actually perform, a measure of the time or capacity each activity consumes, and volume data for the products, services or customers you want to cost. The first and the fourth already exist in your ERP and your invoicing system. The second and the third come from your own supervisors, not from new software. A first model does not require a new IT project.
Start from the cost you already report
Activity-based costing does not create cost. It re-routes cost you have already recognised, so the starting point is the ledger for one closed period at whatever account and cost-centre detail your ERP already produces. Resist the urge to commission a special extract. If the finance team has to build something new before the model can begin, the model has acquired a dependency it did not need and a delay it will not recover.
The one constraint that matters is reconciliation. Whatever the model allocates has to sum back to the same total the accounts report for that period, to the cent. A model that cannot be tied to the published numbers will be argued with rather than used, and every argument will be about the tie-out rather than about the decision the model was built to support.
The four inputs, and where each one already lives
The first input is cost by account and cost centre, straight from the ERP. The second is a list of the activities each department performs, which comes from a short session with the people doing the work rather than from any system. The third is how much time or capacity each activity consumes, built from headcount, shift plans, machine hours and supervisor estimates. The fourth is volume by cost object: orders, lines, deliveries, service calls, patients or tickets, taken from invoicing, CRM or the warehouse system.
Notice which two are expected to be hard. Inputs two and three are the ones that cause hesitation, and they are precisely the two that never come out of a system in any company, at any level of maturity. Waiting for them to appear in a database is waiting for something that does not happen.
Estimated time is data. Precision is not the constraint.
The time-driven variant of activity-based costing, published by Robert Kaplan and Steven Anderson in 2004, was designed around exactly this problem: estimates are acceptable inputs, provided they are checked. A supervisor who says that picking an order line takes roughly ninety seconds has given you a usable number, because ninety seconds multiplied by the volume of lines can be tested against the hours the department actually worked. The test is the value. An estimate that survives it is evidence; an estimate that fails it has just told you where the model is wrong.
The costly mistake runs in the opposite direction: commissioning a time-and-motion study before the first model exists. That converts a four-week exercise into a six-month one and produces precision on activities that may turn out to consume two percent of the cost base. Build the rough model, look at where the money concentrates, and spend measurement effort only there.
What actually stops these projects, and it is not data quality
Two things stop them, and neither appears on the data list. The first is that nobody has decided what is being costed. If it has not been settled whether the model is producing profitability by product, by customer, by channel or by all three, every data request looks unbounded, because it genuinely is. Fix the cost object first and the data requirement shrinks to something a single person can gather.
The second is that the activity list has no owner and drifts. Twenty to forty activities is enough to carry a first model in most mid-sized organisations. A list that reaches two hundred is a signal that the workshop dropped from activity level to task level, and the extra detail buys nothing except a maintenance burden that guarantees the model is never updated. If you want to see the shape this takes in practice, a cost-to-serve view is usually the cleanest first cut.
The question is never whether your data is good enough to model. It is whether your allocation would be better than the average you are using today.
A one-afternoon test before you commit
Pick one closed month. Export the ledger by account and cost centre. Export volumes for the same month by whatever cost object you chose. Ask two department heads to list what their teams do and roughly what share of the week each activity takes. If you can assemble those four things in an afternoon, you have enough for a pilot model and the argument about data readiness is over.
If you cannot produce volumes by cost object, you have found the real gap, and it is worth naming precisely: that is a reporting gap, not a costing one. It will block any profitability analysis you ever attempt, activity-based or otherwise, and it is usually fixed in the source system in days rather than months. Everything else on the standard activity-based costing data wish list can wait for version two.
Our hands-on TDABC workshop takes you from a ledger extract to a first profitability model, using the four inputs above and nothing else.