The modelling errors that survive review because the arithmetic is correct and the structure is wrong, and the checks that catch each one before it reaches a decision.
Most damaging model errors are not broken formulas. They are structural: a cost counted twice, a cost counted nowhere, an assumption typed into a calculation, a stress that fails to propagate. These survive review because everything adds up, and they change decisions because the output looks authoritative. Here are the ones that recur, with the check that catches each.
Why these keep happening
A spreadsheet produces a confident number regardless of whether the structure behind it makes sense, and human review naturally gravitates towards checking arithmetic rather than challenging architecture. Reviewers trace formulas, find them correct and approve. The error sits one level above, in what was included, where it was placed and whether it moves when it should.
1. Hard-coding an assumption inside a calculation
A typed number buried in a formula is an assumption nobody declared and nobody can find. When a sensitivity is run, that number does not move, so the stress case quietly fails to stress. The model then reports that the deal is robust to a variable it never actually flexed, which is worse than not testing at all.
- Avoid it by: Keep every typed number in the inputs area and reference it from there, so the calculation area contains formulas only.
- Proof it is closed: A search for numeric constants in the calculation area returning nothing but years and zeros.
What it costs you: A false conclusion about resilience, reached with full confidence by everyone in the room.
2. Double counting between operating and capital schedules
Items on the boundary, such as a major air conditioning overhaul or a full refurbishment between tenancies, get included by the person building the cost schedule and again by the person building the capital schedule. Net operating income falls, which reduces the valuation, and cash falls again, which overstates the funding requirement. The error is invisible because both entries are individually reasonable.
- Avoid it by: Maintain one list of borderline items, assign each to exactly one schedule, and record the decision beside it.
- Proof it is closed: A reconciliation listing every borderline item with the schedule it was assigned to.
What it costs you: An understated value and an overstated funding need, both pulling the decision the same way.
3. Letting fixed costs fall with occupancy
Models often apply a single occupancy factor across the whole cost base, so a vacancy stress reduces insurance, servicing and common area utilities along with income. This is the opposite of reality, where almost all building costs continue regardless. The stress then shows a much softer impact than the asset would actually experience.
- Avoid it by: Group costs by driver, and ensure the fixed group is genuinely unaffected by the occupancy input.
- Proof it is closed: A test running occupancy down to a low level and confirming the fixed cost group does not move.
What it costs you: A vacancy stress that understates the damage by a substantial margin, which defeats its purpose.
4. Capitalising the wrong year at exit
A buyer at the end of year five purchases the income of year six, not year five. Capitalising the final year of your own ownership understates the exit by a full year of growth. Conversely, capitalising a year further out overstates it. The error is small per year and large in effect, because the exit dominates the present value.
- Avoid it by: Label the exit block explicitly with the year of income being capitalised and show that year in the block.
- Proof it is closed: An exit block in which the income being capitalised is visible and dated.
What it costs you: An exit value wrong by roughly one year of income growth, in the largest number in the model.
5. Forgetting the costs of selling
Agency, legal, marketing and preparation costs on disposal routinely disappear from models, along with any transaction tax applicable to the sale. Because they come off the exit, which carries most of the present value, their omission flatters the return more than almost any other single oversight.
- Avoid it by: Include an explicit selling cost line in the exit block and confirm the applicable transaction tax position with ZATCA for your circumstances.
- Proof it is closed: An exit block showing gross value, each deduction and net proceeds as separate lines.
What it costs you: An overstated exit of several per cent, landing entirely in the most heavily weighted line.
6. Escalating income without escalating costs
It is remarkably easy to apply a growth rate to rent and leave the cost schedule flat, particularly when costs were entered as a single annual figure. The resulting margin widens every year for no reason, and the effect compounds into both the income and the capitalised exit. Reviewers rarely catch it because each individual line looks fine.
- Avoid it by: Place both escalation assumptions adjacent on the inputs page so any difference between them is deliberate and visible.
- Proof it is closed: An inputs page showing rent and cost escalation side by side with a note on any divergence.
What it costs you: A compounding overstatement that grows with the length of the modelled hold.
7. Reporting results from a version nobody can identify
During a negotiation a model is revised repeatedly, and numbers quoted in emails, memos and meetings start to come from different versions. Eventually two people are arguing from different assumptions without realising it, and a decision is taken on a figure nobody can reproduce.
- Avoid it by: Version every file, stamp outputs with the version and date, and circulate only numbered versions.
- Proof it is closed: A version log recording what changed in each revision and who received it.
What it costs you: A decision based on a number that cannot be traced to any surviving version of the model.
A short check before you sign
- No numeric constants exist outside the inputs area.
- Every borderline cost is assigned to exactly one schedule and the assignment is recorded.
- An occupancy stress leaves fixed costs unchanged.
- The exit block names and shows the year of income being capitalised.
- Selling costs appear explicitly and the transaction tax position has been checked.
- Rent and cost escalation sit adjacent on the inputs page with any divergence explained.
If it has already happened
If a decision has already been taken on a model you now distrust, rebuild the output rather than auditing the old file. Take the assumptions page, construct a simple independent calculation of net operating income, the exit and the return, and compare it against the original. A materially different answer tells you where to look, and a similar answer tells you the structure was sound even if the presentation was poor. Then re-verify any regulatory or tax inputs, since those are amended from time to time and the advice specific to your structure comes from a licensed adviser.
Domira builds the numbers on a Saudi property with you before you commit: rent and cost evidence, condition and capital expenditure, the appraisal and the sensitivities that decide whether the deal survives a bad year. The investment decision stays yours, and so does the advice of your licensed tax and legal advisers.
Frequently Asked Questions
What are the most common errors in property financial models?
Structural ones rather than arithmetic: assumptions hard-coded inside formulas so stresses do not propagate, costs double counted across operating and capital schedules, fixed costs falling with occupancy, the wrong year capitalised at exit, selling costs omitted, and income escalated while costs are held flat. Each produces a confident number and each survives a review that only checks formulas.
How do I review someone else's property model?
Start with the assumptions page rather than the formulas, and ask where each number came from. Then run three tests: stress occupancy and confirm fixed costs do not move, check which year of income is capitalised at exit, and look for typed constants in the calculation area. Those three catch most of the errors that actually change decisions.
Should a property model be built monthly to avoid timing errors?
Monthly modelling catches liquidity problems that annual modelling hides, particularly where rent arrives infrequently or debt payments fall due regularly. It does not prevent structural errors, which occur at any periodicity. Build monthly where cash timing matters, report annually for comparison, and apply the same structural checks either way.
Have a Property Question?
Domira can help you navigate property, financing and investment decisions in Saudi Arabia. Speak with our team for an initial consultation.


