Throughput Accounting Theory of Constraints: Worked Example

The throughput accounting theory of constraints method ranks decisions by one number: throughput per hour of the constraint. This walkthrough computes throughput, investment, and operating expense for a small production line, then uses those figures to score a make/buy choice, a rush order, and an improvement project, showing where TA and cost accounting disagree.

What are the three measures in throughput accounting?

Throughput accounting uses three measures: Throughput (T), Investment (I), and Operating Expense (OE). The identity is simple: Net Profit = T − OE, and Return on Investment = (T − OE) ÷ I. The Theory of Constraints community defines these terms precisely, and the definitions matter because each one excludes things cost accounting includes.

Throughput: revenue minus totally variable cost

T = sales revenue − totally variable cost. Totally variable means the cost exists only if you sell that unit: raw materials, per-unit commissions, freight you pay per order. Direct labour is excluded unless it is genuinely paid per unit produced, which is rare.

Investment: money tied up in the system

I = inventory + equipment + anything you bought that sits in the system. It does not appear in the profit calculation; it appears in ROI, where it divides rather than subtracts.

Operating expense: what you pay regardless of volume

OE = salaries, rent, depreciation, utilities: everything you pay whether the line runs or not. The discipline of sorting every cost into T or OE is where most first-pass models go wrong, and where a scoping tool like Improve First (account setup here) forces the decision early.

How do you calculate throughput per constraint hour?

The example line: three stations, one constraint

Take a line with three stations. Station A (milling) takes 12 minutes per unit, Station B (assembly) takes 20 minutes, and Station C (packing) takes 8 minutes. Station B is the binding constraint: it can produce 3 units per hour, and the whole line ships at 3 units per hour, no matter how fast A and C run.

Station	Cycle time	Capacity (units/hr)	Role
A – Milling	12 min	5	Non-constraint
B – Assembly	20 min	3	Constraint
C – Packing	8 min	7.5	Non-constraint

Computing T per unit at the constraint

Say each unit sells for $90 and carries $40 in truly variable cost (materials, freight, sales commission). Throughput per unit, T, is $90 − $40 = $50. Throughput per constraint hour is T divided by the constraint's cycle time in hours: $50 ÷ (20/60) = $50 ÷ 0.333 = $150 per constraint hour. That single number is your ranking currency for every decision on this line.

Why the constraint's clock is the only clock that matters

An hour lost at Station B is an hour of the whole line's output gone, permanently. An hour lost at A or C costs nothing if buffer stock covers it. So improvement value is measured in constraint hours recovered, not minutes shaved anywhere. If you cut Station B to 18 minutes, capacity rises to 3.33 units/hr and T/CU becomes $150. If you cut Station A to 10 minutes, T/CU stays $150 and nothing changes.

Run this arithmetic yourself in the Constraint Impact Calculator on Improve First; the tool emails a client-ready scoping report you can attach to your engagement letter under its terms of use.

How does throughput accounting differ from cost accounting for decision-making?

Cost accounting allocates overhead to products and judges each one on fully-absorbed margin. Throughput accounting treats operating expense as fixed in the short term and judges decisions on throughput per constraint hour. Same factory, different answers.

The allocation trap with a numeric example

A line has one constraint running 2,000 hours a year. Product A sells for $100, material cost $40, so throughput is $60 and it takes 0.5 constraint hours: $120 per constraint hour. Product B sells for $150, material $90, throughput $60, but takes 1.0 constraint hour: $60 per constraint hour.

Cost accounting adds overhead at, say, $50 per labour hour. Product A absorbs $25 of overhead and shows $35 profit; Product B absorbs $50 and shows $10 profit. On that basis, A looks like the better product and B gets starved of capacity.

Where the two methods disagree on the same order

The long paragraph:

Here is the trap in action. Cost accounting ranks A above B because A carries less allocated overhead per unit, so a conventional analyst would push sales toward A and quote B reluctantly or at a premium. But the constraint can only produce 2,000 hours, and A consumes twice the constraint time per dollar of throughput. Filling the constraint with A yields $120 per hour; filling it with B yields $60 per hour, so the ranking holds here, but reverse the numbers and cost accounting still picks the same "cheap-overhead" product while throughput accounting picks the one that earns more cash per constraint hour. A published worked example of this product-mix reversal appears in the throughput accounting literature (Wikipedia, Throughput Accounting). The decision that matters is not which product is "profitable" but which one pays the constraint best, which is why a first-pass model like the Constraint Impact Calculator ranks options by constraint hours, not absorption.

Which one matches cash flow

Throughput is revenue minus truly variable cost, usually materials, so it is close to cash. Allocated overhead is an arithmetic artefact: it only changes when volume or the allocation base changes. Exploit, subordinate, and elevate decisions all cash out at the constraint, so TA's ranking is the one that predicts whether the bank balance moves.

How do you rank improvement projects using TA metrics?

Rank every candidate by delta-T per constraint hour, then by payback in operating expense. Delta-T is the extra throughput the project frees at the constraint, not the labour it saves elsewhere. A project that speeds up a non-constraint has a delta-T of zero, however impressive the cycle-time reduction looks on a slide.

Ranking rule: biggest delta-T at the constraint first

Say the constraint runs 2,000 hours a year and currently yields $40 of throughput per hour ($80,000 total). Project A cuts constraint setup time by 10%, adding 200 constraint hours: delta-T of $8,000. Project B automates a downstream station with no effect on the constraint: delta-T of $0. Project A wins on the ranking rule even if B costs less, because B never touches the limiting resource.

Testing whether the constraint moves after the fix

Model the post-improvement line before quoting the engagement. If Project A lifts constraint capacity by 10%, check which station becomes the new limit. The worked example at https://improvefirst.com/examples/manufacturing-line-capacity shows this shift explicitly, so you can tell the client whether the next dollar should follow.

What to do when two projects look equal

Tie-break on payback: divide project cost by the annual delta-T. A $4,000 fix returning $8,000 pays back in six months; a $10,000 fix returning the same takes fifteen. Rank the cheaper one first, then re-run the model, because the first fix may change the second's delta-T.

When should you reject an order under throughput accounting?

The accept/reject test in three lines

1. Compute the rush order's throughput per constraint minute: (selling price − truly variable cost) ÷ minutes it consumes at the constraint.
2. Compare it to your best current product's T per constraint minute.
3. Accept only if it beats that benchmark, or the constraint has idle capacity anyway.

This is the core of throughput accounting: decisions rank by T per constraint unit, not by margin per unit. Goldratt's argument in The Haystack Syndrome is that cost-based ranking systematically undervalues whatever exploits the constraint (Investopedia's theory of constraints summary).

The rush order worked through

Say the constraint runs 2,400 minutes per week. A rush order pays $9,000, has $1,500 in material, and needs 600 constraint minutes: T = $7,500, or $12.50 per constraint minute. Your best product earns $11 per constraint minute. Accept, but only if you can resequence around existing committed work.

When a 'profitable' order starves the constraint

Flip the numbers: rush order at $8 per constraint minute against your best product at $11. A 40% margin order looks profitable on a quote sheet, yet every constraint minute it takes removes $3 of throughput elsewhere. Reject it, or reprice it above $11 per minute. The same logic applies to make/buy: buying out a subassembly frees constraint minutes worth more than the outsourcing premium. The Constraint Impact Calculator runs this comparison as part of a scoping report; it does not handle resequencing or drum-buffer-rope scheduling, so confirm the schedule yourself before committing.

How do you connect the constraint to the P&L using TA?

The TA income statement identity

Throughput accounting collapses the income statement to three lines: Net Profit = Throughput minus Operating Expense. Throughput is sales revenue minus totally variable cost, usually materials. Operating Expense is everything else, fixed in the short run. Because OE is fixed, any change in T flows dollar-for-dollar to NP, which is what makes the constraint the lever on the P&L.

Turning an extra constraint hour into a profit number

Take the constraint's throughput per hour, say $400 per constraint minute hour, and multiply by the hours you recover. Recovering 10 constraint hours a week through less downtime or less rework adds $4,000 of weekly throughput. With OE unchanged, net profit rises by roughly $208,000 a year. That is the delta-T case for the improvement.

What to show the client's CFO

Present one page: current T, OE, and NP; the projected delta-T from the constraint change; and the resulting NP. Note where the constraint moves next, since the delta-T assumption dies when it does. That single sheet is the scoping report you email before quoting the deeper engagement.

What data do you need to start with throughput accounting?

The four inputs you actually need

For a first-pass scoping model you need four things: selling price per unit, totally variable material cost per unit, routing times per step, and your best guess at where the constraint sits. Throughput is price minus material cost; everything else is operating expense for now. That is enough to compute throughput per constraint hour and rank the three decisions in this article.

Getting routing times without a time study

Ask the supervisor for nominal cycle times, then sanity-check the constraint step against weekly output. If the line ships 400 units on a 40-hour week, the constraint takes about 6 minutes per unit regardless of what the routing sheet says. Sequence your own work the same way Goldratt's five focusing steps do: exploit the constraint before you spend anything elevating it (Theory of Constraints).

Turning the dataset into a client-ready scoping report

Improve First's calculator takes these four inputs, computes throughput per constraint hour, and emails a client-ready scoping report showing where the constraint moves next. ProcessModel and DO.Impact require more build effort for a scoping pass. The honest gap: Improve First's model is static, so it will not simulate arrival variability the way a full discrete-event tool would.

Which tools support a first-pass TA model?

What a scoping tool must do for TA

A first-pass tool has three jobs: compute throughput per constraint hour from inputs you can gather in a day, rank candidate decisions against that number, and flag where the constraint moves once you act. Anything beyond that belongs in the paid engagement.

Running the same criteria over the options

ProcessModel and FlowVisual lean toward simulation and visualising flow, which helps show the constraint but does less arithmetic on throughput per constraint hour. DO.Impact and Praxie sit closer to structured improvement workflows than to TA scoping math. KaiNexus covers broader improvement management, which is heavier than a scoping pass needs.

Where the Constraint Impact Calculator falls short

Improve First's Constraint Impact Calculator handles the three jobs above and emails a client-ready report, but it is a scoping tool only: no simulation, no drum-buffer-rope scheduling, no ongoing tracking. If the engagement wins approval, you will rebuild the model in something heavier.