Throughput accounting (TA) is Goldratt’s alternative to traditional cost accounting. Where traditional accounting charges each resource as its own cost centre, TA asks one question of the whole system: are we generating more value than we spend to stay open? Three numbers answer it: Throughput (T), Operating Expense (OE), and Investment (I).
Throughput (T) is revenue minus the variable costs of delivering it — raw materials, direct commissions, anything that rises with each unit produced. In manufacturing those variable costs can be large; in software they are usually small (per-usage API calls, per-transaction licensing), so T is close to the revenue value of work delivered. Operating expense (OE) is everything else spent to keep the system running: salaries, tools, hosting, licensing. These are period costs that do not move with individual units of output. Investment (I) is money tied up inside the system — work in progress that has not yet become throughput.
The goal is to raise T, reduce I, and hold OE flat — in that priority order. Raising T from a fixed OE base means every unit of output costs less. Cutting OE has a floor; raising T doesn’t.
T = Revenue − TVC · OE = all period costs · I = money tied up in the system
A five-person team: four developers, one reviewer. All paid £400/day. Review is the constraint — one project per day. Below is a pool of work. Select items and watch how the TA cost accumulates based on how much review time each one requires.
items need no review time. TA cost is £0 — run them for any expected benefit.
-
Select tech debt, training, and internal toolingzero cost, no T floor
None of them need review time. Direct T is £0 — they don’t generate revenue. But TA cost is also £0. The justification threshold is any positive benefit, however hard to quantify: improved productivity, fewer bugs. Under traditional costing each day here needs to show ROI against its daily rate; under TA the bar is any expected upside at all.
-
Add the minor UI change£600 T from one review day
One review day, £600 T — a rate of £600 per review day. OE is £2,000/day regardless of whether this runs or not; the UI change generates £600 more than an idle slot would. But at £600/day it’s a poor use of a slot that could deliver more. Traditional costing charges the reviewer’s £400/day and accepts it; TA surfaces the opportunity cost.
-
Swap the UI change for performance work£2,800/day — above the OE rate
Performance work also takes one review day and delivers £2,800 T — £2,800 per review day, above the £2,000/day OE rate. Same constraint time, higher return. The slot is better used here than on the UI change.
-
Add the payment integration£2,000/day — at the OE rate
Three review days, £6,000 T: exactly £2,000 per review day, matching the OE rate. Traditional costing prices those three review-days at £1,200 and accepts it easily. Under TA the slot rate is the benchmark — the payment integration clears it, the UI change doesn’t.
The utilisation trap
Traditional costing evaluates each team or process step as a cost centre with a daily rate attached to it. To justify that rate, the centre should be fully occupied — a developer sitting idle is a paid-for resource generating no project value. Capacity is planned to 100%; everyone is assigned, hours accounted for.
When review is the constraint, pushing developers to full occupancy produces PRs faster than review can clear them. The queue in front of review grows. WIP rises. Cycle time rises with it. Every utilisation metric looks healthy while delivery slows.
Traditional costing compounds the pressure by evaluating each cost centre individually for return on investment. A developer at £400/day is expected to generate £400/day of project value; a reviewer likewise. Each resource is optimised in isolation. Individual asset efficiency, though, is not system efficiency. When every step runs at capacity to justify its own cost, the constraint is overwhelmed and cycle time rises for the whole team. TA removes this framing: OE is the total cost of the system, measured once, and the only question is whether the system generates more T than it spends on OE.
OE is a period cost
Traditional project costing allocates a fraction of each person’s salary to each project based on the time they spend on it. A developer at £400/day spending five days on a project incurs £2,000 of labour cost, charged against that project.
Salaries are paid for the period regardless of which project runs through the system. Headcount, tooling, and hosting change OE — structural decisions that alter the period cost itself, regardless of which work runs through it.
Running one project instead of another changes T, not OE. Evaluate a project by whether it raises T enough to justify any OE change it requires.
The system runs whether it produces output or not. A project delivering £600 T from a review slot generates £600 more than an idle slot would — OE is identical in both cases. The TA cost per constraint day is a comparison benchmark: it shows the T rate a project must clear to be the best use of a slot over competing alternatives.
Non-constraint capacity is free
Any resource that isn’t the constraint has spare capacity, already paid for in OE. A developer waiting because the review queue is full isn’t wasting capacity — the process has no throughput to offer them right now. Their OE contribution is already sunk whether they sit idle or pick up more work.
Using that spare capacity on a project, on training, on technical debt, on process work costs the organisation nothing incremental. OE doesn’t change; T does. Every project that completes through spare non-constraint capacity generates value the system would not otherwise have produced.
This changes the justification threshold for work with indirect or hard-to-quantify value. Training improves future productivity and reduces errors; tech debt reduction lowers future maintenance cost and speeds up future feature work. Neither maps cleanly to a project delivery number. Under traditional costing, each day of attendee and trainer time needs to show ROI against its daily rate. Under TA the marginal cost is zero: any benefit, however modest, clears the bar.
Traditional costing charges £400/day for that developer anyway, loading internal tooling or automation work with cost it doesn’t bear. Finance rejects it; throughput accounting approves any of it on positive value alone.
A project that looks cheap under traditional costing because it uses only a small amount of each resource might still draw heavily on the constraint. Traditional misses it — every resource-day is priced the same. TA doesn’t: constraint time carries the full OE/day wherever the reviewer appears in the estimate.
The constraint carries the full cost
Because OE is fixed and throughput is limited by the constraint, cost per unit = OE ÷ constraint throughput rate. At £2,000/day OE and a constraint of one review per day, each delivered project costs £2,000 — not because of the reviewer’s salary, but because the reviewer’s rate determines how many projects the whole system completes, and the whole system’s cost is OE.
Raising the constraint rate to two reviews per day cuts the cost per project to £1,000. OE didn’t change. Headcount didn’t change. The improvement came entirely from raising throughput — the only lever that simultaneously raises output and lowers per-unit cost.
Constraint downtime cannot be recovered. An hour the reviewer spends in an all-hands or out sick is gone — the constraint has no spare capacity to draw on, unlike every other step. On a £2,000/day OE system, each lost constraint hour costs £250 of output. A non-constraint developer idle for the same hour has the same salary cost in payroll terms, but throughput is unaffected: their spare capacity would have been unused regardless.
Reallocation of capacity to the constraint has an outsized effect compared to the same reallocation anywhere else. Because all system costs are loaded onto the constraint rate, any improvement to that rate cascades through the whole cost model. Suppose two developers join the review process without adding headcount — redeployment from development. If the constraint rate rises from one review per day to three, cost per unit drops from £2,000 to £667 and T capacity triples. OE hasn’t changed.
Two things can shift the constraint to a different step, which changes the analysis entirely. Moving too many resources to review can leave development under-resourced: if the developer pool can no longer keep the reviewer supplied, development becomes the new constraint and the previous gain is partially offset. The signal is WIP building in front of development rather than review. A programme of complex architectural changes or security-sensitive features that take longer to review does the same without any staffing change: the effective constraint rate falls and cost per unit rises through the formula, with no visible headcount movement to explain it.
The scheduling filter
One question drives the scheduling decision: does the work load the constraint?
Work that uses only spare non-constraint capacity has zero marginal cost. Training, refactoring, smaller features, process improvements — if they don’t load the constraint, they clear the bar on any positive value.
Work that occupies the constraint has an opportunity threshold. At £2,000/day OE with one review per day, a project needing two review-days should generate at least £4,000 T to justify those slots over competing candidates. Traditional costing would require only £800 for the same project.
Spare developer time directed at the constraint earns a double return. Tooling that reduces review overhead or speeds up the review process costs nothing in OE terms to build. If it raises the constraint rate, T increases and cost per unit falls — upside at zero OE cost.
Takeaways
- — Traditional costing evaluates each step as its own cost centre. That creates pressure to maximise utilisation at every step — the behaviour that builds queues at the constraint.
- — OE is a period cost. Project selection doesn’t change it; structural decisions do.
- — Non-constraint spare capacity is free. Work that doesn’t load the constraint has zero marginal cost and clears the bar on any positive value.
- — Cost per unit = OE ÷ constraint rate. The constraint’s time is priced at the full system running cost per day, not the individual’s salary.
- — Schedule by constraint-loading. Work that doesn’t touch the constraint: approve on any positive value. Work that does: prioritise by T per constraint-day; OE ÷ constraint rate is the comparison threshold.
- — Non-constraint slack directed at the constraint is doubly free. Zero cost to apply; if it raises the constraint rate, T increases and cost per unit falls simultaneously.