Data Centre Financial Model Checklist
Executive Summary
Key Takeaways
- ✓ Data centre models combine standard financial modelling discipline with capacity, power cost, and tenant concentration mechanics that require their own, sector-specific checklist items.
- ✓ Capacity should be checked against all three co-binding constraints, power, space, and cooling, since a model tracking only one can overstate achievable revenue if a different constraint actually binds first.
- ✓ Revenue should be decomposed into occupancy, pricing, and density tier mix rather than reviewed as a single blended growth assumption, since each driver carries a different risk profile and sourcing requirement.
- ✓ Tenant contract and concentration risk warrants particular scrutiny for hyperscale-anchored facilities, where revenue is typically concentrated in a single long-dated contract rather than diversified across many tenants.
Objective¶
This checklist verifies the sector-specific mechanics of a data centre financial model: capacity constraint tracking, revenue driver decomposition, power and cooling cost structure, and tenant contract and concentration risk. It exists as a distinct checklist because these mechanics do not appear in a generic corporate or real estate model and are not covered by the general Financial Model Audit Checklist, which this checklist assumes has already been applied.
Applicability¶
Applicable when a financial model is being built or reviewed for a colocation, hyperscale, or enterprise data centre ahead of a financing decision, investment approval, or transaction. Most directly applicable to colocation and hyperscale facilities; an enterprise/captive facility should additionally apply the internal chargeback and cost-efficiency considerations described in Enterprise Data Centre Models.
Checklist¶
| # | Check Item | Why It Matters | Evidence to Collect |
|---|---|---|---|
| 1 | Capacity is tracked against all three co-binding constraints, power, space, and cooling, not floor space alone | A model tracking only one constraint can overstate achievable revenue if a different constraint actually binds first | Capacity constraint schedule showing power, space, and cooling headroom |
| 2 | Revenue is decomposed into occupancy, price per unit of committed capacity, and density tier mix as separable assumptions | A blended revenue-per-rack assumption conceals which driver is responsible for a forecast change or historical variance | Revenue driver decomposition schedule |
| 3 | Billed (contracted) capacity is modelled as the revenue driver, distinct from actual utilised capacity | Under a take-or-pay structure, revenue is protected by billed capacity regardless of utilisation, and conflating the two can misstate revenue durability | Billed vs. utilised capacity schedule |
| 4 | Gross new bookings and gross churn are tracked separately, not netted into a single occupancy growth figure | A net figure conceals whether growth is coming from strong bookings, low churn, or both | Gross bookings and churn schedule |
| 5 | Power cost is modelled from total facility power (IT load times PUE), not IT load alone | Modelling from IT load alone understates total consumption and cost by the PUE multiplier | Power cost derivation showing PUE application |
| 6 | Cooling cost is modelled as a distinct line linked to PUE and climate-specific free cooling assumptions | Blending cooling into a generic power cost line obscures its technology and climate-driven cost behaviour | Cooling cost schedule and technology/climate assumptions |
| 7 | For hyperscale or other single-tenant-anchored facilities, a distinct tenant concentration downside scenario is modelled | Concentrated counterparty risk in a single anchor tenant is a materially different risk driver from diversified colocation churn | Tenant concentration scenario output |
| 8 | Capex drawdown is matched to phased capacity delivery tranches, not a single blended completion date | A mismatch between capex and revenue phasing misstates both financing requirement and debt service coverage | Capex and revenue phasing schedule by tranche |
| 9 | SLA service credit provisions are modelled as a contingent revenue deduction, not ignored | Assumes perfect service level performance absent an explicit contingent deduction, overstating revenue | SLA provision documentation and modelled deduction |
| 10 | Contract escalators are applied per each contract's actual terms, not a single blended portfolio assumption | A blended escalator can misstate the run-rate revenue base where escalator rates vary across the contract book | Contract-level escalator schedule |
| 11 | Staffing and other largely fixed operating costs are modelled independent of occupancy level, not scaled with revenue | Misrepresents a cost category driven by required operational coverage, not occupancy or revenue | Operating cost schedule showing fixed vs. variable split |
| 12 | Where the operator runs multiple business models (colocation, hyperscale, enterprise), each revenue stream is modelled separately | Blending business models with fundamentally different risk and revenue mechanisms obscures which segment drives performance | Segment-level revenue and risk schedule |
Common Failures¶
- Capacity modelled against floor space alone, overstating achievable revenue where power or cooling actually binds first.
- Revenue modelled as a single blended rate per rack, with no visibility into whether occupancy, pricing, or density mix is driving a forecast change.
- Power cost modelled from IT load without applying PUE, materially understating total facility power cost.
- No distinct tenant concentration scenario for a hyperscale-anchored facility, understating concentrated counterparty risk.
Recommended Evidence¶
A completed data centre model review should be accompanied by the capacity constraint schedule, the revenue driver decomposition schedule, the power and cooling cost derivation, and, where relevant, the tenant concentration scenario output. The table above is structured for direct use in model governance documentation, a lender due diligence file, or an audit working-paper file.
How to Use This Checklist¶
Apply the Financial Model Audit Checklist first for general structural integrity, then work through this checklist against the model's capacity, revenue, and cost schedules. See Financial Model Audit for Data Centres for broader industry audit context.
Continue Reading¶
Related Pillars¶
Related Technical Guides¶
Related Industries¶
Related Checklists¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What makes a data centre financial model different from a standard corporate or real estate model, for review purposes?
It combines standard financial modelling discipline with capacity-constraint, power cost, and tenant concentration mechanics specific to the sector, none of which appear in a generic corporate or conventional commercial real estate model, and each of which can materially affect revenue and cost independent of headline occupancy growth.
Why should capacity be checked against power, space, and cooling together?
Because a facility's actual sellable capacity is the minimum of all three constraints, and a model tracking only floor space, for example, can materially overstate achievable revenue if power or cooling actually binds first, particularly as tenant rack density rises.
Why should revenue be reviewed as three separate drivers rather than one growth rate?
Because occupancy, pricing, and density tier mix can each move independently and for different reasons, and a single blended revenue growth assumption prevents a reviewer from identifying which driver is actually responsible for a forecast change or a variance against history.
Should this checklist be used alongside the general Financial Model Audit Checklist?
Yes. This checklist adds the data-centre-sector-specific items; the general Financial Model Audit Checklist should be applied first for baseline structural integrity, formula correctness, and documentation standards.
Related Articles
What Is a Financial Model Audit?
A financial model audit is an independent, structured examination of an Excel based financial model to confirm that its mechanics, logic, and outputs are reliable enough to support a decision. It is not a check of whether the assumptions are optimistic or conservative. It is a check of whether the model actually calculates what its author believes it calculates. Every year, lenders extend debt, investment committees approve capital, and boards sign off on transactions using numbers that came out of a spreadsheet nobody outside the immediate deal team has independently verified. A financial model audit exists to close that gap before it becomes expensive.
Data Centre Financial Modelling
Data centre financial modelling is the discipline of modelling a data centre operator's revenue, cost, and capital structure from its capacity-denominated drivers, power, space, and cooling capacity, rack density, and tenant contract structure, rather than the generic market-price and headcount-growth drivers used in most corporate models, or the pure occupancy-and-lease-term drivers of conventional commercial real estate. This page is the hub for the Knowledge Centre's data centre financial modelling content: how colocation, hyperscale, and enterprise business models each require a distinct model architecture, how rack revenue and occupancy are decomposed into their separable underlying drivers, and how capacity planning and financial KPIs tie the model together, as this domain expands to cover operations, revenue, investment, and governance practice across the sector.
Financial Model Audit for Data Centres
Data centre financial models sit between real estate and infrastructure modelling conventions: phased, capacity-driven capex drawdown funds build-to-suit or colocation facilities, while power procurement and pass-through mechanics, and long-dated tenant or hyperscale offtake agreements, determine the revenue and cost structure. Power availability and cost pass-through in particular is a mechanic that does not appear in standard commercial real estate models. This page sets out the modelling risks specific to data centres, the audit findings that recur in build-to-suit and colocation financings, and what lenders typically expect before extending development or acquisition debt.
Data Centre Capacity Planning Models
Data centre capacity is jointly constrained by power, floor space, and cooling capability, and the binding constraint can shift as tenant rack density changes. This guide sets out how to model capacity planning across all three constraints simultaneously, how phased capacity delivery should be scheduled against demand, and why treating any single constraint as the sole capacity driver risks overstating achievable revenue.