| Financial Modeler Pro

<p>A mixed-use model I rebuilt earlier this year, hospitality and residential, in Saudi Arabia, had over 40,000 rows in a single input tab. Other tabs ran past 15,000 rows each.</p>

<p>It was built by a well-resourced advisory team. The technical depth was there. The numbers reconciled. The calculations worked.</p>

<p>But when the sponsor opened it, they could not explain a single assumption. When the lender opened it, they asked for a "shorter version." When the investment committee opened it, they sent it back.</p>

<blockquote>A template and a defensible model are not the same thing.</blockquote>

<p>A template packs everything in. A defensible model strips out what does not need to be there, so what remains can be defended.</p>

<p>This distinction matters more in KSA real estate than in almost any other modeling context, because the audiences are unforgiving. Sponsors expect to walk through every line. Lenders run their own stress tests on top of the model. Investment committees challenge the assumptions before they touch the numbers. A model that cannot stand up to all three audiences will not close a deal.</p>

<h2>Why bloated templates fail at the IC table</h2>

<p>Most templates that arrive on my desk have one of three problems, and often all three at once:</p>

<ol>

<li><strong>The input layer is buried.</strong> Critical drivers sit inside 40,000-row tabs alongside intermediate calculations, lookup tables, and historical data. The user cannot tell what is an assumption and what is a derived value.</li>

<li><strong>The calculation flow is manual.</strong> Cells reference other cells across tabs in unpredictable patterns. Changing one driver requires manually updating six places. Errors propagate silently.</li>

<li><strong>The output layer is built for the modeler, not the audience.</strong> Outputs are wide tables of monthly cash flows that no IC member will read. There is no summary view. No sensitivity table. No clear path from inputs to IRR.</li>

</ol>

<p>The result is a model that technically works but cannot be defended in a room. The lender's credit team will not approve it. The IC will not vote on it. The sponsor will not sign off on the assumptions because they cannot find them.</p>

<figcaption>The structural difference: bloated packing versus deliberate layering.</figcaption>

</figure>

<h2>What separated the rebuild from the original</h2>

<p>The rebuilt version of the model I described above had four characteristics. Each one is intentional. None of them are technical magic. They are discipline.</p>

<h3>1. A clear input layer</h3>

<p>Every assumption sits in one named place, with a label, a unit, and a source. No assumptions are buried inside calculation cells. The user can find any driver in under ten seconds.</p>

<h3>2. Fully automated calculation flow</h3>

<p>Change a single driver in the input layer, and the change moves through the entire model without manual intervention. Construction phasing, revenue cohorts, financing drawdown, returns, all update together.</p>

<h3>3. Auditable structure</h3>

<p>Any number on the output sheet can be traced back to its source in three clicks or less. Drill from IRR to net cash flow to operating cash flow to EBITDA to revenue. Every link is direct and named.</p>

<h3>4. A presentation layer designed for the audience</h3>

<p>The output is built for the IC, the lender, and the sponsor, not for the modeler. One-page summary. Clean returns table. Sensitivity grid. Capital stack waterfall. The output answers the questions the audience will actually ask.</p>

<h2>Why I build every model from scratch</h2>

<p>This is why I build every project model from scratch instead of starting from a pre-built template.</p>

<p>Each transaction has its own land structure, its own cohort logic, its own financing rhythm, its own IC. A residential pre-sales project in Riyadh has nothing in common with a hospitality refurbishment in Jeddah, beyond the spreadsheet they both live in. Forcing the project to fit a generic template either omits the specifics that matter (and the lender finds them) or stuffs them into the wrong places (and the IC sees the mess).</p>

<p>A model that respects the specifics of a transaction will always defend itself better than one shaped around a generic shell.</p>

<blockquote><strong>The Practitioner Principle:</strong> The job of a financial model is not to demonstrate complexity. It is to support a decision.</blockquote>

<h2>What this means for sponsors and developers</h2>

<p>If you have inherited a model that looks like the one I rebuilt, the rebuild is always easier than the original. Most of the time, the structural work takes a fraction of the time it took to create the original mess, because the rebuild starts from the audience and works backward, not from the assumptions and works forward.</p>

<p>The harder problem is knowing it needs to be rebuilt before the IC tells you so.</p>

<hr>

<p><strong>Working on a transaction that needs senior modeling support?</strong></p>

<p>I take on selective advisory engagements for real estate developers, family offices, and investors across KSA and the GCC. Feasibility studies, IC presentations, capital structuring, and the kind of rebuild work this article describes.</p>

<p><a href="https://www.linkedin.com/in/meetahmaddin/">Get in touch on LinkedIn →</a></p>

A template is not a defensible model.