Why property feasibility models break in Excel

Short answer. Excel feasibility models break for structural reasons, not careless ones. The same eight failure modes recur in almost every spreadsheet audit. The good news is they are predictable, and the better news is they are avoidable.

Why this question keeps coming up

Almost every Australian residential developer has, at some point, found a six-figure error in a feasibility spreadsheet the night before IC. The pattern is not carelessness. It is structural. Excel is a blank canvas with no opinion about what a feasibility should look like, which means every analyst rebuilds the same logic from scratch, and the same mistakes appear in the same places.

The eight ways Excel feasibility models break

1. Hard-coded numbers inside formulas. The classic. A construction rate of 4,250 is typed into the GFA-to-cost line instead of pulled from an input cell. Search the formula bar for any literal that should be a reference.
2. Hidden tabs. Inherited models almost always have at least one. They usually carry the assumption that matters most.
3. Broken named ranges. The Name Manager is the second-most useful feature in Excel and the least-used. Names that point to deleted rows return zero silently.
4. Circular references in finance. Interest depends on a debt balance that depends on interest. Excel lets you turn iterations on and pretend it is fine, until the result starts drifting.
5. Out-of-date pricing. Comparable sales from six or twelve months ago used without an adjustment for the cycle.
6. Out-of-date statutory contributions. Council and state contribution schedules update every year. Most templates do not.
7. Annual cashflow only. Peak debt and IRR both fail under annual aggregation. The bank sizes against the monthly peak.
8. “Final” files that aren't.File naming is not version control. The “Final_v3_USE THIS ONE” pattern is how the wrong version gets emailed.

How to spot the eight in your own model

The 30-minute audit

Most feasibility spreadsheets can be audited in about half an hour. Run the checks in the table above before you circulate the model, not before IC. A spotted error is cheap. An unspotted one travels with the deck.

Why the same errors keep coming back

None of the eight failure modes are difficult to fix once you know they exist. The problem is that fixing them in one workbook does not stop them recurring in the next. Excel has no shared schema, no inherited constraints, no way to enforce that the construction rate appears in one place. Each new model starts at zero.

Common mistakes when fixing them

• Rebuilding instead of refactoring. The next analyst starts from scratch and reintroduces the same eight errors.
• Locking cells without documentation. A locked cell is a future mystery if no one knows why it is locked.
• Adding more tabs. Complexity is the source of risk, not the solution to it.
• Treating “Final” as a state. If the model is live, it is not final.

When to stop fixing and start replacing

If you run more than two or three feasibilities a month, the time spent auditing spreadsheets exceeds the cost of structured software inside the first month. If you run one a quarter, a clean template plus the 30-minute audit is fine. Match the tool to the workflow.

Practical takeaways

• Run the 30-minute audit before every IC.
• Treat the eight failure modes as a checklist, not a hindsight list.
• Move to structured software once you are running more than two feasibilities a month.
• Read peak debt off the monthly cashflow, never the annual rollup.