The Data You Need to Build a TDABC Model (And What You Can Skip)

Every TDABC project starts with the same question: what data do we need? The honest answer is less than you think — and the wrong answer drowns the project before it starts.

Most failed cost projects do not fail because of missing data. They fail because teams try to gather everything before building anything. They spend three months in data collection, lose executive patience, and never get to results.

The right approach is the opposite: start with the minimum viable dataset, build a working model, and refine from there.

The Five Data Sources You Actually Need

1. General Ledger (last 12 months)
Cost centre level detail. Account-level granularity. This gives you the total cost pool — what you are allocating from. No GL, no model.

2. Headcount and Compensation by Role
Full cost (salary + employer charges + benefits) by employee, grouped by department or function. You need this to derive capacity cost rates per resource pool. Anonymised aggregates work fine; you do not need individual names.

3. Operational Volumes by Activity Type
How many transactions, orders, clients, units, procedures, calls — whatever the work output is. Monthly granularity is the floor; weekly is better. Without volume data, you cannot calculate time consumed per activity.

4. Revenue by Product / Service / Client
At the same granularity you intend to analyse profitability. If you want to see margin per client, revenue per client is non-negotiable. If you want margin per SKU, same logic.

5. Time Equations Input (subject matter expert interviews)
Not timesheets. Not surveys distributed to every employee. Just structured conversations with 3-8 people who know how the work actually happens. Two hours per role gives you 80% of what you need.

What You Can Skip (For Now)

The data items most companies waste weeks chasing — and that you do not need for the first model build:

Detailed timesheets. TDABC was specifically designed to avoid the timesheet trap. Time equations replace timesheets. If you already have timesheets, fine — they are a useful sanity check. But do not start the project by deploying them.

Activity-based budgets. You are building the cost model that will inform future budgets. You do not need an activity-based budget to start.

Perfect master data. If your customer or SKU master is messy, fix the top 80% by volume and accept noise in the long tail. The model will still produce actionable insights from imperfect master data.

Real-time data feeds. Batch loads at the start. Real-time integration is a nice-to-have once the model is producing value, not a prerequisite to building it.

The Sequencing That Works

The fastest TDABC implementations follow a sequence:

Week 1: GL extract, headcount data, top-level revenue split. Build the cost pools and assign costs to resource groups. You can now answer: “What does each department cost us?”

Week 2: SME interviews to write time equations for the top 5-10 activity types. Operational volumes for those activities. You can now calculate cost per activity event.

Week 3: Revenue allocation to products/clients. First Whale Curve. You now have a working profitability model — imperfect, but actionable.

Week 4 onwards is refinement: more activity types, more granular allocations, scenario modelling. But you have a model that delivers value from week 3.

Why This Matters for the Workshop

At our upcoming TDABC workshops in Porto, Lisbon, and Online, participants build a full TDABC model in a single day — using exactly this approach. Five data inputs, structured methodology, working model by the end of the day.

The constraint is not data availability. The constraint is methodology discipline.

Join us in Porto on 16 June, Lisbon on 18 June, or Online on 30 June + 1 July to see how it works in practice — with your own data, if you bring it.