Where unit economics mistakes actually hide: inputs, not arithmetic

The conceptual errors in unit economics get discussed a lot. The ones that actually ruin a model are duller: a cost counted twice, a period annualized that should not have been, a number compared against another number built on a different unit. They survive review because everything looks like arithmetic and arithmetic looks correct.

Nine of them below, grouped by where they enter: what goes into the model, how it is computed, and how it gets used afterwards.

What to take away

• Most broken models are broken by bookkeeping, not by concept. Check the inputs before you argue about the method.
• A model that cannot be compared against its own earlier versions cannot tell you whether anything improved.
• Write down what would change your mind before you compute. Afterwards every result reads as confirmation.

Mistakes in what goes into the model

1. Using revenue that never arrived. Invoiced is not collected. Refunds, chargebacks, unpaid balances and the share taken by a channel before the money reaches you all belong out of the revenue line, and all four are routinely left in because they are recorded somewhere else, or nowhere. A model built on what you billed describes a company with better customers than yours. What actually counts as receipts, and what is netted off before they are counted, has rules behind it, and IRS Publication 334 states them plainly for a small business.

2. Counting a cost twice, or in neither place. The classic double count is a cost sitting inside a variable line and again inside an overhead allocation. The classic omission is a cost that lives in a different department's budget and is therefore nobody's variable cost. Both are found the same way: list every material cost line in the business once, and mark each as caused by the unit or not. Anything unmarked is the bug.

3. Treating an internal allocation as a cost the unit caused. A transfer between your own teams is not evidence that a unit consumed anything. It may be a reasonable proxy, but it is a decision someone made, and it will change when the org chart does. Mark allocated costs as allocated and keep them visible, so a later reader can see which part of the answer is measurement and which part is convention. The distinction between a cost that was caused and a cost that was assigned is the central one in MIT's financial and managerial accounting course.

Mistakes in how it is computed

4. Comparing numbers built on different units. One team's figure is per order, another's is per customer, and the comparison is presented as a finding. This is the single most common way a unit economics discussion produces a wrong conclusion, and it is invisible because both numbers are correct. Label every figure with its unit, in the cell, not in a footnote.

5. Annualizing a period that contained something that will not repeat. A month with an unusual order, a one-off cost, a seasonal peak, or a single large refund, multiplied up into a year. The fix is not a longer period, though that helps. It is keeping the unusual item on its own line so that anybody can see what the figure would be without it.

6. Measuring only the customers who are still here. A cohort table built from current accounts has quietly removed everyone who left, which is exactly the population the model needed. The same error appears in survey work and in support records. Any measure of a relationship has to include the relationships that ended, and if your systems delete departed accounts, that is a data problem to fix before it is a modeling one. The definitional traps around this are set out in business model types metrics.

Mistakes in how the model is used

7. Changing an assumption without dating it. Somebody updates a figure, the model produces a better answer, and the previous version is gone. Now nothing can be compared to anything: you cannot tell whether the business improved or the assumptions moved. Keep versions, date every assumption, and note who changed it and why. This costs a minute and it is the difference between a model and a mood.

8. Choosing the unit that makes the answer work. When a model shows an uncomfortable result, there is always a redefinition available that improves it: a longer relationship, a different denominator, an exclusion of the hardest segment. Sometimes the redefinition is right. The test is whether you would have chosen it before seeing the result, and the way to make that testable is to write the definition down first. When a genuine redefinition is needed, it belongs with the other decisions in the business model types checklist.

9. Running sensitivity only on the comfortable variables. Most models are stress-tested on the inputs that are easy to vary and least likely to break anything. The useful version moves the assumptions the answer actually depends on: how long relationships last, what serving a customer costs at a larger volume, and how much of your acquisition would have happened anyway. If moving one of those by a plausible amount reverses the conclusion, that is the finding, and it should be reported as prominently as the headline.

The review that catches most of them

Give the model to someone who did not build it, with three instructions.

Half an hour of that will find more than a week of re-deriving formulas. The underlying method the review is checking against is set out in unit economics, and the model-level errors that sit above all of this are in business model types mistakes.

Common questions

How precise does the model need to be?

Precise enough to support the decision in front of you, and honest about which inputs are estimates. Many decisions survive being wrong about a small input, and stating that plainly is more useful than a false decimal.

Should we rebuild the model when the business changes?

Build a new one and keep the old, rather than restating history. A restated past makes every trend look smoother than it was, which is exactly the effect you were trying to avoid.

Who should be able to change the assumptions?

One owner, with changes visible. Anyone may propose one; only the owner applies it and records what moved.

We found a mistake in a published model. Now what?

Correct it, keep the earlier version, and note what changed. A quiet correction destroys the only thing a model has, which is the ability to be compared with itself.