The prompt to build a TDABC model with AI
Time-Driven Activity-Based Costing turns one number, the cost per minute of a resource, plus how long each task takes, into the true cost of every order, product or customer. An AI assistant can build the whole model in one pass, but only if you stop it from inventing the figures. Here is the exact prompt we tested, the result it produced, and the guardrail that keeps it honest.
In short
Paste the prompt below into ChatGPT, Claude, Gemini or Copilot, replace the sample figures with your own department's data, and the assistant will compute practical capacity, the capacity cost rate, the cost of each activity, and, the part traditional costing hides, the cost of your unused capacity. The prompt forces it to show every formula and to flag every assumption, so you can audit the result instead of trusting it blind.
What the prompt is doing
Time-Driven Activity-Based Costing was set out by Robert Kaplan and Steven Anderson in Harvard Business Review in 2004 and in their 2007 book of the same name. The idea is simple. Take the total cost of a department and divide it by its practical capacity in minutes, the time people are actually available to work once you remove breaks, training and admin. That gives a cost per minute. Then estimate how many minutes each activity takes. Multiply, and every activity carries its fair share of cost. Anything left over is the cost of capacity you paid for but did not use, which is a number most cost systems quietly bury. If you want the full method, see our guide to building a TDABC model and to capacity costing. For the fields to pull out of the source systems first, see the cost model data extract.
The prompt
Replace the sample data with your own. Keep the rules at the top and the numbered steps. They are what make the difference.
You are a cost accountant specialising in Time-Driven Activity-Based Costing (TDABC), the method developed by Kaplan and Anderson. I want to build a TDABC model for one department. Work only from the data I give you. Do not invent any numbers, rates, or volumes. Where a figure is missing, ask for it or label it clearly as an assumption. Here is my data: - Department: Customer Service - People: 8 full-time agents - Paid hours per agent per month: 160 - Practical capacity factor: 80% (the rest is breaks, training, admin) - Total monthly cost of the department (salaries + supervision + systems + space): 32,000 EUR - Activities and estimated minutes per event: - Handle a standard order: 9 minutes - Handle a complex order: 22 minutes - Process a return: 17 minutes - Monthly volumes: standard orders 3,100; complex orders 540; returns 410 Do this, step by step and showing the formula at each step: 1. Compute practical capacity in minutes (people x paid hours x 60 x practical capacity factor). 2. Compute the capacity cost rate (total cost / practical capacity minutes), in EUR per minute. 3. Cost each activity (minutes per event x capacity cost rate). 4. Cost each activity at its monthly volume. 5. Sum the cost of used capacity, then show the cost of unused capacity (total cost minus cost of used capacity). 6. List every assumption you made. Output a clean table for steps 3 and 4, and flag any figure you could not derive from my data.
The sample numbers above are illustrative, not from any real client. Swap in your own department, headcount, cost and activity times.
A worked example, so you can see it run
This is the actual result the prompt produced on a current assistant, using the sample data above. We checked the arithmetic by hand. Notice what it does: it shows each formula, it separates used from unused capacity, and it ends with a list of assumptions rather than hiding them.
Step 1. Practical capacity
8 agents × 160 hours × 60 × 0.80 = 61,440 minutes per month
Step 2. Capacity cost rate
32,000 EUR ÷ 61,440 minutes = 0.5208 EUR per minute (about 31.25 EUR per hour)
Steps 3 and 4. Cost of each activity, at volume
| Activity | Minutes | Cost per event | Volume | Activity cost | Minutes used |
|---|---|---|---|---|---|
| Standard order | 9 | 4.69 | 3,100 | 14,531.25 | 27,900 |
| Complex order | 22 | 11.46 | 540 | 6,187.50 | 11,880 |
| Return | 17 | 8.85 | 410 | 3,629.17 | 6,970 |
| Total used | 24,347.92 | 46,750 |
Step 5. Used versus unused capacity
Total cost 32,000 − cost of used capacity 24,347.92 = 7,652.08 EUR of unused capacity (about 24% of what you pay for)
That last line is the insight. Almost a quarter of the money this department costs is not being absorbed by the three activities measured. In a traditional system that cost would be spread across the orders, making each one look more expensive than it is and hiding the real issue, which is spare capacity, not expensive orders.
Step 6. Assumptions it flagged
The model assumed these three activities are the department's only work, that the eight agents are interchangeable at one blended rate, and that the times and volumes given are accurate. It flagged the first as the one to check, because if agents also do work you did not list, the unused capacity figure is overstated. That honesty is the point. It tells you where the model could be wrong instead of presenting a single confident number.
What it costs you to run
This prompt is around 340 tokens of input, roughly 250 English words. A vague version, "help me build a TDABC model", is about 11 tokens, but it cannot produce the result above. In our test it invented a department, a headcount and a rate, then asked for the data anyway, which means a second full round before you get anything real. The structured prompt costs a few hundred extra tokens up front and saves you the wasted round and the work of spotting fabricated numbers.
Token figures are approximate and depend on the model. Portuguese and Spanish versions of the same prompt use more tokens per word than English.
The guardrail that matters
The single most important line in the prompt is this one. Keep it in every costing prompt you write.
Work only from the data I give you. Do not invent any numbers, rates, or volumes. Where a figure is missing, ask for it or label it clearly as an assumption.
For the full set of anti-hallucination guardrails, see how to stop AI inventing your numbers.
Three tiers you can climb
The prompt above is a solid start. What follows takes it further. Most people do not build a costing model in a single step; they start with one team, watch the numbers move, then widen the lens. So we have laid this out as three tiers.
Tier 1 builds a model for a single department and, in the same run, shows you the result three ways, traditional single-rate costing, ABC and TDABC, so you can see with your own numbers why the method matters. Tier 2 scales to several departments inside one company, with capacity maths, time equations and a multidimensional P&L on a month of data. Tier 3 turns the model into a reporting engine and dashboard, then asks the AI for the decisions: what to fix, drop or reprice.
A note before you start. These prompts produce a draft you can defend a conversation with, not a model you can defend to a board. The arithmetic will be right and the logic sound, but the numbers are only as good as the data you feed in, and a real model has to reconcile to your ledger and survive audit. That reconciliation, and the certainty that comes with it, is the work we do alongside you. Think of these tiers as the exact model we build with our clients, run first on illustrative data so you can see the shape of it.
One department, three methods side by side
The starting point for anyone who has heard that TDABC gives a truer cost but has never seen the difference on real figures. It builds a working model for one department and recalculates the same unit costs under traditional single-rate costing and under classic ABC, then lines the three up. You walk away understanding not just what TDABC says but why it disagrees with the number your current system reports. Good for a controller, a cost accountant, or a founder testing the idea.
You are a cost accountant specialising in Time-Driven Activity-Based Costing (TDABC). Work only from the data I give you. Do not invent any numbers, rates, or volumes. Where a figure is missing, ask me for it or label it clearly as an assumption before you use it. I want to cost one department three different ways on the same numbers, so I can see why the methods disagree. Step 1. Take my inputs. Ask me for, or use what I paste: - The department name and what it does. - Its total annual cost, split into people cost and other cost (space, systems, supervision, consumables). - Headcount, contracted hours per person per week, and working weeks per year. - The distinct activities the department performs (3 to 6), each with annual volume and a rough average time per event in minutes. - The cost objects I want a unit cost for (products, services, order types, customer types) and how many of each ran in the year. If any are missing, ask once, clearly, before continuing. Step 2. Build the TDABC model. - Theoretical capacity = headcount x hours/week x weeks/year x 60, in minutes. - Practical capacity = 80% of theoretical (state as the default and let me override; the 20% covers breaks, meetings, training, admin). - Capacity cost rate = total annual department cost / practical capacity in minutes. Show it per minute and per hour. - For each activity: cost per event = capacity cost rate x average minutes; activity cost = cost per event x annual volume. - Sum activity cost across all activities and compare it to the department total. The gap is unused (idle) capacity, priced in currency. Show it explicitly. - Assign activity costs to my cost objects by the time each one actually consumes, and give a TDABC unit cost per object. Step 3. Now cost the same department the traditional way. - Single overhead rate = total department cost / a single volume base (for example total units, or total labour hours). Ask me which base my current system uses if you are unsure. - Apply that one rate to every cost object. Give a traditional unit cost per object. Step 4. Now cost it with classic Activity-Based Costing (ABC). - Use the same activities as cost pools, but allocate each pool's full cost across cost objects using a driver, with no capacity concept. The whole department cost is absorbed; there is no idle-capacity line. - Give an ABC unit cost per object. Step 5. Put the three side by side. - One table: cost object | traditional unit cost | ABC unit cost | TDABC unit cost. - Explain, in plain language, why they differ. Be specific about two things: how the single rate cross-subsidises (which objects it over-costs and which it under-costs), and how TDABC differs from ABC by exposing idle capacity instead of burying it in the rates. - Name the one or two cost objects where the choice of method changes a decision (a price, a keep-or-drop call). Throughout: show every formula, show your working as tables, and list every assumption at the end in one block so I can correct it and have you rerun.
What to expect. A capacity calculation, a capacity cost rate per minute and per hour, an activity cost table with an idle-capacity line stated in money, and the three-column comparison that is the point of the exercise. Expect the traditional single rate to over-cost the simple, high-volume objects and under-cost the complex, low-volume ones; expect ABC to match TDABC on the objects but hide the idle capacity that TDABC surfaces.
Several departments, capacity, time equations, a multidimensional P&L
The working model. It takes a mid-sized business, a 160-person distribution company, starts from its customer-service department, then expands across the departments that actually consume resource to serve customers, builds a proper time equation for each, and rolls the result into a profit and loss you can slice by customer, product, channel and order type on a single month of data. For an FP&A analyst, a controller, or a CFO who wants cost-to-serve and multidimensional profitability rather than a flat gross margin.
You are a cost and profitability analyst who builds Time-Driven Activity-Based Costing (TDABC) models. Work only from the data I give you or the illustrative figures we agree. Do not invent numbers silently; when you need to assume something to keep moving, state the assumption on the line where you use it, and keep every assumption in a list at the end. Context. I run a distribution company: roughly 160 people, buying goods and selling them on to business customers. I want to start with the customer-service department, then expand into the other departments that consume cost to serve customers, and finish with a multidimensional P&L on one month of data. We will use illustrative data unless I paste my own. When you need illustrative inputs, propose sensible values for a 160-person distributor, label them clearly as illustrative, and let me change them. Step 1. Departments and resource pools. Model these resource pools, each as its own capacity pool: Customer Service, Warehouse and Fulfilment, Transport and Delivery, Purchasing, and Sales/Account Management. For each, ask me for or propose headcount, contracted hours per week, working weeks per year, and total annual cost (people cost plus space, systems, supervision). Compute for each pool: - Theoretical capacity in minutes = headcount x hours/week x weeks/year x 60. - Practical capacity = 80% of theoretical (default; let me override per pool). - Capacity cost rate = annual pool cost / practical capacity in minutes, shown per minute and per hour. Step 2. Time equations. For each pool, write a time equation that prices complexity rather than averaging it. Use the form: time = base minutes + (coefficient x driver) + ... For example, for Customer Service: minutes per order = 4 + 3 x (order lines) + 12 x (is_return) + 8 x (is_urgent) + 6 x (is_new_customer) Draft one equation per pool using drivers that make sense for a distributor (order lines, deliveries, pick locations, pallets, urgent flag, return flag, new-customer flag, calls). Show each equation, state the coefficients as illustrative, and let me correct them. Step 3. One month of data. Generate one month of illustrative transactions at the order-line level (or use my file if I paste one). Aim for a realistic spread: a few hundred orders across, say, 40 customers, 60 products, 2 channels (field sales and web), and a mix of order types (standard, urgent, return, sample). Each row should carry the fields the time equations need. Show me the schema first and a sample of ten rows before you run the full month, so I can approve it. Step 4. Cost the month. - For every order line, run each relevant pool's time equation to get minutes, multiply by that pool's capacity cost rate to get cost, and sum to a fully-loaded cost to serve per line. - Add the product cost (cost of goods) per line. - Per pool, total the minutes consumed, compare to practical capacity for the month, and report used versus idle capacity in minutes and in money. Step 5. Build the multidimensional P&L. From the costed transactions, build a P&L I can read along any of these dimensions: customer, product, channel, order type. For each dimension show revenue, cost of goods, cost to serve, and net margin in currency and in percent. Give me: - The top and bottom 5 customers by net margin in money. - The order types that lose money once cost to serve is loaded. - The channel comparison (field sales versus web) on net margin, not gross. - One table per dimension, plus a one-paragraph read of what the month is telling me. Throughout: show formulas and working as tables, keep illustrative values clearly labelled, and end with the full assumption list so I can swap in my real figures and have you rerun the whole model.
What to expect. Five capacity cost rates, five time equations, an approved transaction schema and a generated month of order-line data, a costed dataset with used-versus-idle capacity per department, and four cuts of the same P&L (by customer, product, channel, order type) in money and percent. The revealing outputs are usually the loss-making order types (urgents and small returns) and the channel gap once cost to serve is loaded rather than assumed away.
A year of data, a reporting model and dashboard, AI-driven decisions
The final tier turns the model into something a business runs on: a full year of transactions, a reporting layer and dashboard, and then the AI acting as an analyst that reads the finished model and tells you what to do, which customers and products to fix, drop or reprice, and where the idle capacity and the cross-subsidies are hiding. For a CFO, a private-equity operator, or a founder who wants the decisions, not just the numbers.
You are a profitability analyst and management accountant working with a Time-Driven Activity-Based Costing (TDABC) model. Work from the model and data we build here. Do not invent numbers silently; label every assumption where you use it and collect them in a list at the end. Your final job is not to produce numbers but to tell me what to do about them. Context. Continue the distribution-company model from before (customer service plus warehouse, transport, purchasing, sales; capacity cost rates and time equations already defined). If any of those are not in context, ask me to paste them or rebuild them briefly first. Step 1. Generate a full year of illustrative transactions. Extend the month to twelve months at order-line level. Build in realistic structure so the analysis has something to find: - Seasonality (for example a Q4 lift and a summer dip). - A long tail of small customers and a short head of large ones. - A handful of customers whose behaviour destroys margin (many urgents, high returns, tiny orders, heavy support), and a few quietly excellent ones. - A product range where some lines are high volume/low margin and some the reverse. Show me the yearly schema and summary statistics (row count, customers, products, channels, order types, total revenue) before going further, and label the whole dataset illustrative. Step 2. Cost the year and build the reporting model. - Run the time equations and capacity cost rates over every line to get cost to serve, then net margin per line. - Aggregate into a reporting layer with these views: a) Whale curve: customers ranked best to worst by net margin in money, cumulative profit plotted; report peak cumulative profit, final net profit, the ratio between them, and the profit given back by the tail. b) League tables by customer, product, channel and order type: revenue, cost of goods, cost to serve, net margin in money and percent. c) Capacity utilisation by department across the twelve months: used versus idle minutes and money, with the trend. Step 3. Build the dashboard. Produce a single dashboard view (as a structured layout I can recreate, or as a generated file if you can) with: the whale curve, the four dimension league tables, the capacity trend, and a KPI strip (total net margin, margin percent, idle capacity cost for the year, share of customers generating 100% of profit). Keep it clean and board-readable. Step 4. Give me the decisions (this is the point). Reading your own model, produce a prioritised action list. For each recommendation give the evidence from the numbers, the action, and the estimated annual profit impact at constant volume, labelled as an estimate: - Customers to FIX: what behaviour is destroying margin and the specific change (minimum order size, service-level change, urgency surcharge, channel move). - Customers to REPRICE: where a 1 to 5 percent move flips loss to profit; show the before and after. - Customers to consider DROPPING: only as a last resort, only after fix and reprice are shown not to work, and note the capacity that would free up and what it is worth. - Products/services to fix, reprice or rationalise, with the same logic. - The idle capacity: where it sits, what it costs for the year, and three management options (grow demand into it, reduce it, repurpose it). End with the five questions I should take to my controller before acting on any of this with real money. Throughout: show your working, keep illustrative values labelled, and be explicit that these are decisions to test against real ledger data, not instructions to execute blind.
What to expect. A year of structured illustrative transactions, a reporting layer (whale curve, four league tables, capacity trend), a dashboard layout or generated file, and the payoff: a ranked list of fix, reprice or drop actions with an estimated profit impact each, plus the idle-capacity options and the five questions to pressure-test with a controller. The AI should refuse to jump to "fire the customer" and put repricing and behaviour change first.
How these tiers map to the work we do with you
These are the exact conversations of a real engagement, run on your own data instead of illustrative figures. Tier 1 is how we show a finance team, in their own numbers, why the reported cost has been quietly wrong. Tier 2 is the shape of a live CostCtrl model, the multidimensional P&L clients keep going back to because it answers "which customer, which product, which channel, which order type" in one place. Tier 3 is the destination: not a one-off study but a reporting model the business steers by, reconciled to the ledger and certain from day zero. The prompts show the reasoning; the engagement makes it certain.
ABC vs traditional vs TDABC on the same numbers
Two prompts. The first is quick and needs almost no data. The second is the full side-by-side for a reader who wants to see every line of the disagreement.
Quick comparison, one activity, three methods
For the "aha" in 12 to 15 minutes. It costs a single high-mix and low-mix pair of objects three ways and shows exactly where the traditional single rate lies to you.
You are a management accountant. Work only from the numbers I give you and label any assumption. I want to see why traditional costing, ABC and TDABC give different answers on the same simple case. Take one support or processing team. I will give you: the team's total annual cost, its practical capacity in hours (or headcount and hours so you can compute it at 80% of theoretical), and two cost objects that behave very differently, one high-volume and simple, one low-volume and complex, with the annual volume of each and the average handling time per event for each. Cost both objects three ways: 1. Traditional: one overhead rate = total cost / total volume, applied equally per unit. 2. ABC: allocate the team's full cost to the two objects by their share of total handling time (full absorption, no idle concept). 3. TDABC: capacity cost rate = total cost / practical capacity in minutes; cost per object = rate x minutes consumed; show the idle capacity left over in money. Then give me one table (object | traditional | ABC | TDABC) and three sentences: which object the single rate over-costs, which it under-costs, and what TDABC shows that ABC hides. Show every formula.
Full side by side on a real dataset
For a controller ready to run it on an export. Same three methods across a full set of cost objects, with the cross-subsidy and the idle-capacity gap quantified, and a plain statement of which decisions flip depending on method.
You are a cost accountant. Work only from my data. Do not invent numbers; ask for anything missing or label it an assumption. I will paste these tables: 1) department.csv: total_annual_cost, people_cost, other_cost, headcount, hours_per_week, weeks_per_year, and the single volume base my current system uses (name it). 2) activity.csv: activity, annual_volume, avg_minutes_per_event, and for each activity how its events map to my cost objects. 3) objects.csv: cost_object, annual_quantity. Produce three full costings of the same objects: A. Traditional single-rate: total_annual_cost / total base units, applied to every object. Give a unit cost per object. B. ABC: treat each activity as a cost pool, allocate its full cost to objects by driver share (no capacity concept, full absorption). Give a unit cost per object. C. TDABC: practical capacity = 80% of theoretical (let me override); capacity cost rate = total_annual_cost / practical minutes; cost each object by minutes consumed; report unused capacity in money as a separate line. Then: - One comparison table: cost_object | traditional | ABC | TDABC | traditional-vs-TDABC gap %. - Quantify the cross-subsidy: total currency that the single rate moves from complex objects onto simple ones. - Quantify the idle capacity TDABC exposes and that ABC and traditional both bury in unit costs. - List the cost objects where the method changes a decision (a price floor, a keep-or-drop), and say which method you would trust for that decision and why. Show all formulas and working as tables. End with the assumption list so I can correct and rerun.
Make it a deliverable you can edit and show
Any prompt on this page produces analysis in the chat. This add-on turns that analysis into a file you can edit and show colleagues, an adjustable Excel model, a clean PDF, a short deck, or a diagram. Paste it after any tier or comparison prompt once the model has run.
Now package this into a deliverable I can edit and show colleagues. Ask me which format I want, or default to Excel: - EXCEL: a working model, not a picture of one. Put inputs (rates, capacities, time-equation coefficients, volumes) on one clearly marked input sheet, and drive every result with live formulas that reference those inputs, so when I change an assumption the whole model updates. Add a summary sheet with the key tables and, if the tool allows, a chart (whale curve or margin ranking). Label every assumption cell. - PDF: a clean, board-readable report, title, one-paragraph summary, the key tables, one chart, and an assumptions appendix. No chat formatting. - PPT: 5 to 7 slides, the question, the method in one slide, the headline numbers, the whale curve or league table, the recommended actions, next steps. - DIAGRAM: a single clear figure of the model (resource pools to capacity cost rates to time equations to cost objects to P&L), as an editable vector or a described layout I can rebuild. Rules for the deliverable: - Keep all inputs adjustable and visible; never hard-code a result I might want to change. - Carry through every assumption and label illustrative figures as illustrative. - Add a discreet footer or last-slide credit line, small and unobtrusive, exactly as written below. Credit line to embed (use verbatim, in the document footer or final slide): "Model scaffolding based on the Build a TDABC model prompt from costandprofitability.com/ai-costing-prompts/build-a-tdabc-model" Keep it to one small line; it should read as a quiet source note, not an advertisement.
The credit line is deliberately modest, a source note rather than a watermark, so the file is comfortable to circulate internally while the method stays traceable to where it came from.
When you need the real model
This prompt gives you a clean draft for one department from estimated times. A model your board or your auditor will trust is built on your real general ledger, reconciled to your accounts, and kept alive in software after the project ends. That is what we do. We build Time-Driven Activity-Based Costing models in CostCtrl and hand you a result you can defend, not a sketch.
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, Founding Partner
Cost and profitability practitioner for 25+ years. Presented the Damco cost-to-serve case at Managing for Profit (Amsterdam RAI, December 2009), on the same programme as Robert S. Kaplan.
Call +351 910 313 731
