Ed Arnold's Advanced Topics for Value Models (published August 6, 2026) names five mistakes:

Read his piece for the mechanics. Each one is well explained there, and this post isn't going to re-litigate them.

The more interesting question: these are well documented, named, and written up by someone with twenty-plus years doing this work. Why do they keep happening anyway?

Ed’s own audience already knows what a reference-value error looks like. That's exactly why he could write the piece for them. The mistakes still make it into finished business cases, including from experienced people, because reading a diagnosis after the fact and catching the same error live, mid-build, under deal pressure, are different competencies. One is expertise. The other is a workflow.

Expertise tells you the mistake exists. It does not fire at the exact second you make it. A rep building a model at 6pm before a Friday deadline is not short on knowledge. They are short on attention, and every one of Ed's five is easiest to make precisely when attention is lowest. Knowing the pattern and noticing you are inside the pattern are two different acts.

We wrote about a version of this gap a few weeks ago: most reps aren't using AI to build the equation underneath a business case. They're using it to make an already-guessed number look more finished. Formatting versus engineering. This is the same problem, one layer over, at the review stage instead of the build stage.

Take the last one on Ed's list: forcing a single number where a range would hold up better. Nobody makes that mistake because they've never heard the argument for ranges. They make it because a single number is what the field wants, what the slide wants, and what the buyer seems to be asking for. The format produces the error, not ignorance of the theory.

And it is a real error. A value estimate isn't a fact, it's a distribution. One clean number reads as confidence, but it's false precision, and the first sharp question from the other side of the table exposes it. The practitioner who typed that number knew all of this. Knowing did not stop it from going into the model as a point estimate.

Now the first one: benchmarking against the wrong reference point. When the practitioner catches it, it costs a five-minute fix. When they don't, the person who catches it is the economic buyer, in the room, reviewing the case. "Our cost structure doesn't look like that." At that point, the reference-value error stops being a modeling note. It's the reason the whole business case just became a vendor claim instead of a shared analysis. Same mistake, two completely different outcomes, and the only variable is where in the workflow it got caught.

Not in a training session. Not in a QBR retrospective, three weeks after the number already went to the buyer. It has to happen at the moment the number is typed into the field, before it goes anywhere near a buyer.

Most teams don't have anyone with Ed's level of pattern recognition sitting beside every rep on every deal. The checklist exists, in an article. The enforcement point doesn't exist anywhere in the actual workflow.

A senior reviewer is the usual answer, and it works right up until it doesn't scale. One person cannot sit inside every model as it's built. So the check slides to the end and becomes a review, and a review only catches what it has time to read.

MEDDICC tells a rep the Metrics field is required. Arnold's piece tells a practitioner what a wrong answer in that field looks like. Neither one sits where the number actually gets produced, which is the only place a mistake gets caught before it costs anything. There are two ways to catch these, and only one of them catches them in time.

The difference isn't rigor. Both catch the same five mistakes. The difference is when, and when is the whole game. A mistake caught while the number is being built is a private edit. The same mistake caught after is a credibility problem you don't get to redo.

What are common mistakes in the model underneath a business case?

Ed Arnold's recent piece names five. Read it for how each shows up in practice.

Do experienced practitioners still make these mistakes?

Yes, by Ed's own framing. Knowing a mistake exists and catching it live are different skills.

Why do experienced people still force a single number instead of a range?

Because the format asks for one. A field, a slide, and a buyer's question all pull toward a single figure, even though a value estimate is really a distribution. Knowing that doesn't override the pressure in the moment.

How do I catch these errors before a buyer sees them?

Move the check to the point where the number is actually being produced, not to a review after the case is built.

What's the difference between reviewing a business case and building one correctly the first time?

Review depends on someone senior having the time to read every case closely. Building it correctly the first time doesn't.