Insights · TDABC
Building a TDABC model requires five data sources: the general ledger, payroll by department, operational transaction data, capacity estimates, and complexity drivers - and most companies already have four of the five sitting in their ERP. The single biggest myth about time-driven activity-based costing is that you need perfect data to start. After 150+ models built since 2010, we can say it plainly: perfect data is not a prerequisite. Knowing which data matters is.
time equations × capacity rates
auditable · refreshed monthly
The five data sources that actually matter
1 · General ledger - what was spent
The financial backbone: every cost account, by month, with cost-centre detail. It feeds the model’s cost pools - the total euros that will be allocated. In EU countries with ERP (Portugal since 2008; variants in Norway, Austria, Poland, France and others), the standardised export gives you this at transaction level in one file.
2 · Payroll by department - what capacity costs
People are usually 50-70% of allocatable cost. You need total employment cost per department (not per person - no sensitive data required): salaries, social charges, benefits. Combined with headcount and working schedules, this produces the capacity cost rate - the cost per minute of each resource group, the number every time equation multiplies against.
3 · Operational transaction data - what the business actually did
Orders, order lines, shipments, deliveries, production runs, support tickets, patient episodes - whatever your operation’s unit of work is. This is the model’s fuel: each transaction gets costed through the time equations. It lives in the ERP, the WMS, the billing system, the CRM. One quarter of history is enough to start; a year is better for seasonality.
4 · Capacity and time estimates - how long things take
The data least likely to exist as a report - and the one people fear most. You need two things per resource group: practical capacity (available minutes after breaks, meetings, training) and base times for the main activities. Neither comes from timesheets. Base times come from operational records (timestamps in the WMS, system logs) plus targeted observation - a few hours on the floor, not months of surveys.
5 · Complexity drivers - what makes some work slower
The characteristics that make one order different from another: rush vs. scheduled, fragile vs. standard SKU, new vs. repeat customer, split vs. consolidated delivery. These become the terms of the time equations. Most are already columns in your transaction data; the project’s job is deciding which ones matter.
The checklist
| Source | Feeds | Where it lives | If missing |
|---|---|---|---|
| General ledger / ERP | Cost pools | ERP · ERP export | Rare - accounting always exists |
| Payroll by department | Capacity cost rates | HR / payroll system | Use cost-centre personnel accounts from the GL |
| Transaction data | Activity volumes per output | ERP · WMS · billing · CRM | Start with invoice lines (ERP has them) |
| Capacity & base times | Time equations | System timestamps + observation | Estimate with the team, refine in month 2 |
| Complexity drivers | Equation terms | Columns in transaction data | Begin with 2-3 obvious ones, add as the model matures |
What you can skip (for now)
- Employee surveys. TDABC exists precisely to avoid the ABC survey ritual. Never start there.
- Timesheets. Self-reported time is the least reliable data in any company. Operational timestamps beat it every time.
- A cost-centre redesign. Model with the structure you have; restructure later if the model proves it’s needed.
- Real-time integration. Monthly exports are enough for the first year. Automate when the model has earned its place in the management routine.
- Perfect product costing history. The model replaces it - don’t clean what you’re about to retire.
The free Profit Check scores your cost-management maturity - including data readiness - in 5 minutes.
Take the Profit Check
The sequence that works
- Week 1: GL + payroll exports → cost pools and capacity rates. In parallel: map the 5-8 core processes.
- Week 2: transaction data load → volumes per output. Draft time equations with base times from records + observation.
- Week 3: first full allocation run → sanity-check with the people who run the processes. Their corrections are the best calibration data you will ever get.
- Month 2+: refine the equations where the money is - not everywhere. A model that is 95% right on 80% of cost beats one that is perfect on paper and never ships.
This is the exact sequence of our three-week ProfitAudit 360 diagnostic - data gathering runs inside the project, not before it. The full data-and-technology dimension of the framework is covered in Data & Technology for Costing.
Frequently asked questions
What is the minimum data needed to start?
Three things: a general ledger export with cost-centre detail, payroll costs by department, and one quarter of transaction data (orders, shipments or cases). That is enough for a first working model of one business area.
What if our data is not perfect?
Perfect data is not a prerequisite. Every TDABC model we have built started with imperfect data - mapping the gaps is part of the diagnostic, and the model itself shows which data is worth improving first.
Is ERP enough to build a TDABC model?
ERP covers the financial side: GL transactions, chart of accounts and invoice-level billing. You still need operational transaction data and capacity estimates - but ERP typically eliminates weeks of financial data preparation.
How long does it take to gather the data?
With standard ERP exports, one to two weeks - running in parallel with process mapping in the first phase of the three-week diagnostic, not before it.
Do we need timesheets?
No. TDABC was designed to avoid them: time equations are estimated from operational records and targeted observation, not from self-reported timesheets or ABC-style surveys.