Data Infrastructure for Cost Modeling: What You Need Before You Can Model

One of the most common barriers to implementing a proper cost model is the belief that you don’t have the data. Most of the time, that belief is partly right, but the gap is smaller than it appears.

Understanding what data you actually need (vs. what you think you need) is the first step.

The Three Data Requirements of TDABC

A TDABC model requires three types of data:

1. Financial data — cost pool totals. The total cost of each resource pool (department, team, or function) over a period. This comes from your chart of accounts. Almost every company has this, either from their ERP, accounting software, or SAF-T export. This is rarely the constraint.

2. Operational data — transaction volumes and types. The number and type of transactions processed by each resource pool: how many orders fulfilled, clients onboarded, invoices processed, quality checks performed, etc. This is the data that many companies lack at sufficient granularity.

3. Time estimates — how long each transaction type takes. The time required per transaction type in each resource pool. This does not require extensive historical data: a combination of system logs, operational metrics, and structured estimates from process owners is sufficient.

The Minimum Viable Dataset

You do not need a data warehouse, a business intelligence platform, or a full ERP to build a useful TDABC model. You need:

• A general ledger or chart of accounts segmented by department (to build cost pools)
• An operational report or manual count of key transaction types by department
• Time estimates per transaction type, validated with department heads

CostCtrl is designed to work with exactly this, plus SAF-T exports for companies in PT/ES/BR, which provides the financial layer automatically.

The Common Data Gaps (and How to Bridge Them)

Gap 1: No transaction-level operational data

Solution: Start with a 2-week activity sampling exercise. Department heads record their team’s activities in 30-minute blocks. This gives you an initial dataset sufficient for the first model iteration.

Gap 2: No time tracking by client or product

Solution: Use system logs as proxies (number of emails, tickets, orders) combined with time estimates per event type. Imprecise? Yes. Better than no model? Always.

Gap 3: No ERP / chart of accounts by department

Solution: Map your existing accounts to cost pools manually. A one-time exercise that takes 1–2 days for a mid-market company. Document the mapping so subsequent periods are automated.

Data Maturity as a Journey

The goal is not to achieve perfect data before building a model. The goal is to build a model with imperfect data, and then use the model to identify where data quality improvements will have the most impact on decision accuracy.

Often, 80% of the value comes from 20% of the data. The model shows you which 20%.

CostCtrl has a built-in data maturity assessment that tells you exactly which data gaps limit your model’s precision, and prioritises the gaps worth closing in the next 90 days.