An overwritten cell can change the decision.
Twenty-five years in a row, one of them different, changed at 23:40 under deadline, and nobody has looked at it since.
The expensive defects are boring
People expect a model audit to find sophisticated mistakes: a misapplied discount rate, a tax treatment that misreads the regime. Those turn up occasionally. What turns up constantly is duller and costs more.
The reason is structural. Sophisticated errors are made by people thinking hard, and people thinking hard tend to check their work. Overwritten cells are made at 23:40 under deadline, and by definition nobody is checking anything at 23:40.
Reading a model does not find it. Every formula looks reasonable in isolation, and the inconsistent one is reasonable too. Only a mechanical row-by-row comparison finds it, which is why that test runs first on any file, including ours.
What comes up, and why it matters
| Finding | Why it happens | Why it matters |
|---|---|---|
| One period in a row differs from its neighbours | A manual override under deadline pressure | Invisible and unbounded |
| Coverage definition drifts between sheets | Two people, two conventions, nothing written down | Headroom overstated wherever the looser definition applies |
| An assumption hard-coded inside a formula | A quick fix that was never unwound | Silent divergence once the assumption changes |
| Scenario switch does not reach every dependent line | The model grew after the switch was built | Sensitivities that understate the downside |
| Rounding plug has become material | A balancing figure nobody revisited | The statements tie for the wrong reason |
| Inflation applied off the wrong base year | An indexation row copied from a prior deal | Compounds across the full term |
| Degradation compounded on nameplate | The formula reads from the wrong column | Understates decline over twenty-five years |
| Solver block solved against stale inputs | Nobody pressed the button after the last edit | Every check row reads pass while the answer is wrong |
| Day count and stub period at first drawdown | Default conventions left in place | Moves the first test date, which is often the tightest |
Ordered by frequency. The first row is both the most common and the hardest to bound, which is why row-consistency testing runs before anything else.
Get an independent read
If a real commitment depends on the model and nobody outside the team has read it, that is usually reason enough.