FMAE for Developers
Executive Summary
Key Takeaways
- ✓ Developers build financial models to access finance and inform investment decisions, but most development models are not built with the same rigour applied to institutional model audit standards.
- ✓ Structural errors in development models — wrong DSCR, incorrect IRR, disconnected sensitivity tables — are discovered by lenders, equity partners, or investment committees at the worst possible moment.
- ✓ FMAE provides a pre-submission structural quality gate that identifies critical errors before any external submission.
- ✓ Use cases span lender submission preparation, equity partner due diligence, internal investment committee approval, pre-financial close model lock, and joint venture model review.
- ✓ FMAE is the developer's own structural check; it does not replace the bank-commissioned independent model audit CP, but it substantially reduces the risk of that audit finding critical errors.
The Problem Developers Face¶
Developers — real estate developers, infrastructure sponsors, energy project developers, and mixed-use development companies — build financial models as the primary analytical tool for every project they pursue. The development model is how a project gets financed: it is the document that tells lenders whether the project is bankable, tells equity investors whether it meets their return threshold, and tells the developer's own board whether the project should proceed.
The consequences of getting that model wrong are significant. An overstated equity IRR leads to a board approval that should not have been given. An understated construction cost leads to a debt size that leaves the developer short of funds. An incorrect DSCR calculation produces a compliance certificate that may not accurately reflect the project's financial position.
Developers face a specific challenge that distinguishes them from banks and advisory firms: they are not model audit specialists. They build models to understand their projects, not to produce auditable deliverables for third parties. The model is typically built by one person, reviewed informally, and then submitted to a lender or equity partner who will apply far more scrutiny to it than went into its construction.
By the time a bank's credit team flags a material error in a developer's submitted model, the developer has typically already presented that model to their board, used it to negotiate equity terms, and committed to a timeline that assumes the model is correct. Discovering the error at the lender stage creates delay, renegotiation, and sometimes deal failure.
What Developers Need¶
A developer needs their financial model to be structurally correct before it goes to any third party — lender, equity partner, or board. Specifically:
- Confirmation that the debt capacity calculation is arithmetically correct and produces the right DSCR
- Confirmation that the equity IRR calculation is using the right cash flow series and the right function
- Confirmation that sensitivity analysis outputs are formula-driven and connected to the correct inputs
- A documented record that the model has been reviewed, which can be retained in the project file and disclosed to lenders on request
- The ability to correct errors before they are discovered externally — which is always better than having lenders or investors discover them
Developers do not need a three-week manual audit for every project model. They need a rapid, reliable check that identifies structural problems before the model leaves the developer's team.
How FMAE Addresses Developer Needs¶
FMAE performs deterministic structural audit of financial models. For developers, this creates a practical quality gate that can be applied before any model submission.
Pre-submission model check. Before submitting a financial model to a bank's credit team, an equity partner, or the developer's own investment committee, FMAE is run to identify structural errors. Critical findings are corrected before submission. The developer submits a model that has been systematically reviewed rather than one that has only been checked informally.
DSCR and equity IRR verification. FMAE independently verifies the key output metrics — DSCR, LLCR, equity IRR, project IRR — by recomputing them from the model's inputs and comparing against the model's displayed values. If the model's displayed DSCR differs from the recomputed value, FMAE identifies this as a finding. See DSCR and Equity IRR.
Construction cost and drawdown verification. FMAE identifies structural errors in the construction cost and drawdown schedule — hardcoded values where formula-driven calculations should be, broken references in the drawdown waterfall, and inconsistencies between the construction cost and the financing plan.
Sensitivity analysis validation. FMAE verifies that sensitivity tables are connected to the model's input cells. A sensitivity table that has been manually populated rather than formula-driven will not update when assumptions change. A lender reviewing such a table is looking at stale numbers.
Fast red flag output. For time-sensitive situations — where the developer needs a rapid view on a model received from a joint venture partner or an acquired site vendor — FMAE produces a red flag report quality output quickly, identifying the highest-priority structural issues for the developer's immediate consideration.
Typical Developer Use Cases¶
Lender submission preparation: Before submitting the development model to the bank's project finance team, the developer runs FMAE. Structural findings are resolved internally. The bank receives a model that has cleared a systematic structural check. This reduces the time spent in back-and-forth with the bank's credit team on model corrections, and reduces the risk of the bank's model audit CP identifying a critical error that delays financial close.
Equity partner due diligence: Before sharing the development model with a prospective equity partner, the developer runs FMAE. An equity partner reviewing a model that contains a structural error in the IRR calculation may conclude that the equity return is lower than the developer's presentation implies, damaging the negotiation. Identifying and correcting this before the model is shared avoids the problem.
Internal investment committee: Before presenting to their own investment committee or board for project approval, the developer runs FMAE. If the committee approves on wrong numbers, the developer is exposed to both financial loss and governance risk. Clearing the model structurally before the committee presentation removes that risk.
Pre-financial close model lock: At financial close, the developer's model is the reference document for the life of the loan. FMAE is run immediately before financial close to confirm that the model being locked is structurally clean. Any structural errors introduced during the final round of assumption updates are identified before the model is locked, not discovered during the first covenant compliance calculation.
Joint venture model review: Where the developer receives a financial model from a joint venture partner that will be used as the basis for the partnership's investment analysis, FMAE is used to assess the model's structural integrity before the developer's team builds their analysis on it.
The Developer's Position in the Model Audit Process¶
Developers occupy a specific position in the project finance model audit ecosystem: they are the model builder, not the model auditor. The third-party model audit CP is commissioned by the developer but serves the lenders. The developer pays for the audit but the audit is primarily an assurance tool for the bank.
FMAE gives developers a distinct capability: their own structural quality check, independent of the bank-commissioned audit, that serves the developer's interest in having a correct model before lenders see it.
There is a practical financial logic to this. The cost of a model error discovered by the developer before lender submission is: internal time to correct, no delay. The cost of a model error discovered by the bank's credit team during review is: time, credibility damage, potential renegotiation of terms, and risk of deal delay at a commercially sensitive moment. The cost of a model error discovered after financial close is: covenant recalculation, potential lender consent process, and reputational risk.
Front-loading the model quality check — using FMAE before any external submission — is the most cost-effective position for a developer to take.
What FMAE Does Not Cover¶
FMAE performs structural audit of the model's internal logic. It does not:
- Assess whether the project's commercial assumptions are correct or market-consistent
- Provide property valuation, construction cost estimation, or market demand forecasting
- Replace the independent model audit certificate required as a lender CP
- Provide legal advice on development agreements, planning obligations, or financing documents
- Assess the project's physical or technical feasibility
Developers using FMAE should understand it as a structural quality gate, not as a substitute for the full development due diligence process.
Continue Reading¶
Prerequisites¶
- What Is a Project Finance Model Audit? — the parent pillar
Related Pillars¶
Related Glossary¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
At what stage of the development lifecycle should FMAE be used?
FMAE is most valuable at the points immediately before external submission: before lender submission, before equity partner disclosure, before investment committee presentation, and before financial close. It can also be used earlier in the development process as a quality check during model construction, allowing the developer's team to identify and resolve structural issues before the model reaches its final form.
Does FMAE replace the need for an independent model audit CP at financial close?
No. Where the loan agreement requires an independent model audit certificate from an approved third-party firm as a condition precedent, that requirement must be satisfied by a qualified independent firm. FMAE is the developer's own internal quality check. Its value is in identifying and resolving structural errors before the model is submitted to the independent auditor, reducing the time and cost of that external process.
What types of development models can FMAE audit?
Confirm current model compatibility through the FMAE product documentation. The tool is designed for Excel-based financial models, which includes the majority of real estate development models, infrastructure feasibility models, and project finance models used in the development industry.
How quickly does FMAE produce results?
FMAE processes models in minutes to hours depending on model complexity. For a developer working to a lender submission deadline, the turnaround time is fast enough to allow findings to be reviewed and corrected on the same day.
Related Articles
What Is a Project Finance Model Audit?
A project finance model audit is a financial model audit applied to the specific class of model used to finance infrastructure, energy, and long dated capital projects: debt sculpted, multi decade, cash flow driven structures with mechanics that do not appear in a typical corporate model. It is frequently a formal condition of financial close, not an optional check, and lender requirements for it exist almost entirely inside non public bank credit policy rather than any single consolidated public source. This page defines what makes project finance models structurally distinct, why lenders require independent verification of them specifically, and what the audit process looks like in this context.
Model Audit Certificate
A model audit certificate (also referred to as a model audit report or model assurance certificate) is a formal written document issued by an independent auditor or model review firm confirming that a financial model has been independently reviewed, describing the scope of the review, identifying findings, and providing a level of assurance about the model's arithmetical accuracy and internal consistency. In project finance, a model audit certificate is typically a condition precedent (CP) to financial close, meaning that lenders will not fund the first drawdown until the certificate has been delivered by an approved independent reviewer.
Equity IRR
Equity IRR (Equity Internal Rate of Return) is the discount rate at which the net present value of all equity cash flows — comprising the initial equity investment as a negative cash flow and subsequent distributions and terminal proceeds as positive cash flows — equals zero. It measures the annualised return earned by equity investors on capital contributed to a project or transaction, calculated on post-debt-service cash flows only. Equity IRR is distinct from Project IRR, which is calculated on total project cash flows before financing. Equity IRR is always higher than Project IRR in a positively leveraged transaction because debt amplifies equity returns. It is lower than Project IRR when leverage is negative — that is, when the cost of debt exceeds the unlevered return of the project.
Financial Close
Financial close is the contractual milestone in a project finance transaction at which all conditions precedent (CPs) to the financing are satisfied or waived, all financing documents are executed, and lenders fund the first drawdown of debt. It marks the transition from the development and negotiation phase of a project to the construction and execution phase. Financial close is also referred to as financial closing or closing date. It is distinct from commercial close, which refers to the execution of the underlying commercial agreements (offtake, concession, construction contract) before financing is confirmed. In the context of financial modelling, financial close is the date from which the base case financial model is locked, the debt terms are crystallised, and the model becomes the contractual reference document against which covenant compliance and drawdown conditions are tested.
Project Finance Model
A project finance model is a financial model built to analyse the economics of a capital project that is financed on a non-recourse or limited-recourse basis. In a non-recourse structure, lenders rely solely on the cash flows generated by the project — and the security over the project's assets — for repayment of the debt. They have no recourse to the equity sponsors' wider balance sheets. The project finance model is the primary analytical tool through which all parties — sponsors, lenders, advisers, and government agencies — evaluate the project's financial viability, structure the debt, negotiate terms, and, after financial close, monitor the project's ongoing financial performance.
Conditions Precedent
Conditions precedent (CPs) in project finance are the contractual requirements that must be satisfied, waived, or deferred before a lender is obliged to advance funds under a loan facility. CPs are set out in the financing agreements and typically include: provision of executed project documents, evidence of regulatory approvals, insurance certificates, legal opinions, and in most institutional project finance transactions, an independent financial model audit certificate confirming that the financial model has been reviewed and that specified checks have been completed. Financial close cannot occur until all material CPs have been satisfied.
Red Flag Report
A red flag report is a rapid, high-level assessment of a financial model designed to identify critical or significant issues without conducting a full, exhaustive independent audit. It provides a targeted view of whether a model contains material errors, structural weaknesses, or significant limitations that would affect its fitness for a specific purpose — typically a pending investment decision, a financing transaction, or a commercial negotiation. A red flag report is sometimes called a preliminary model review, a model health check, or a model screening assessment. The defining characteristic is scope limitation: it is a rapid review that identifies significant issues, not a comprehensive verification of every formula and reference.