Data Centre Financial Model Template
Executive Summary
Key Takeaways
- ✓ A data centre financial model template should move from capacity constraints, through revenue driver decomposition, to power and cooling cost, and finally to contract and concentration risk testing, in that order, since later modules depend on the capacity and revenue drivers established earlier.
- ✓ The capacity section should establish power, space, and cooling as three co-binding constraints before any revenue is projected, since revenue cannot exceed the facility's actual sellable capacity under whichever constraint binds first.
- ✓ The revenue section should be built as separable drivers, occupancy, price per unit, and density tier mix, not a single blended growth rate, so the model can show which driver is responsible for a forecast change.
- ✓ This template is the model structure; the underlying sector-specific mechanics (capacity planning, power cost, contract terms) should follow the modelling guides referenced throughout this pillar.
Purpose¶
This template sets out a consistent section-by-section structure for a data centre financial model, within Data Centre Financial Modelling, so the model moves traceably from capacity constraints and decomposed revenue drivers to a fully connected cost and cash flow structure rather than presenting a revenue or margin conclusion with no visible supporting driver chain.
Template Structure¶
1. Capacity Constraints. Power, floor space, and cooling capacity established as three co-binding constraints, with the actual binding constraint identified. See Data Centre Capacity Planning Models.
2. Business Model Classification. Colocation (wholesale/retail), hyperscale build-to-suit, or enterprise/captive, each requiring its own revenue and risk architecture. See Data Centre Business Models.
3. Occupancy and Density Mix. Billed capacity, actual utilisation, and available headroom, tracked by density tier. See Data Centre Occupancy & Utilisation Models.
4. Pricing and Revenue. Price per unit of committed capacity by density tier, cross-connect and network revenue, and contract escalation terms. See Rack Revenue Models and Data Centre Pricing Models.
5. Customer Contract Terms. SLA service credits, renewal options, and early termination risk by material contract. See Data Centre Customer Contract Models.
6. Power and Cooling Cost. Total facility power (IT load times PUE), load factor, utility tariff structure, and cooling technology cost. See Data Centre Power Consumption Models and Data Centre Cooling Cost Models.
7. Full Operating Cost Structure. Maintenance, staffing, security, and insurance as distinct, activity-linked cost categories. See Data Centre Operating Cost Models.
8. Capacity Delivery and Capex. Phased capex drawdown matched to capacity delivery tranches, for expansion or new development. See Data Centre Capacity Planning Models.
9. Scenario and Sensitivity Summary. Correlated downside/upside scenarios (including tenant concentration where relevant) and individual driver-level sensitivities presented side by side. See Data Centre Scenario Analysis and Data Centre Sensitivity Analysis.
Why This Structure Matters¶
Each section in this template exists to prevent a specific failure mode documented elsewhere in this pillar: skipping the capacity constraint section can lead to a facility overstating achievable revenue against a power- or cooling-constrained ceiling, the specific risk illustrated in A Colocation Portfolio's Blended Occupancy Figure Masks a Power-Constrained Capacity Ceiling; and a contract terms section that does not model renewal risk explicitly can overstate terminal cash flow, the risk illustrated in A Hyperscale Acquisition's Take-or-Pay Assumption Unravels After a Tenant Renegotiation.
How to Use This Template¶
Populate each section in the order presented, since later sections depend on the capacity and revenue drivers established earlier, the power and cooling cost section cannot be meaningfully built without the occupancy and density mix assumptions already in place. Re-source each driver assumption from the facility's own current operating data on a rolling basis, rather than holding the model's original assumptions static across successive reporting periods.
Continue Reading¶
Related Pillars¶
Related Technical Guides¶
Related Case Studies¶
- A Colocation Portfolio's Blended Occupancy Figure Masks a Power-Constrained Capacity Ceiling
- A Hyperscale Acquisition's Take-or-Pay Assumption Unravels After a Tenant Renegotiation
Related Products¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What is the purpose of this template?
To give a data centre operator or model developer a consistent, defensible model structure, moving from capacity constraints through decomposed revenue drivers to power/cooling cost and contract risk testing, ensuring no step is skipped or collapsed into a blended assumption that would obscure the model's diagnostic value.
Why does the template establish capacity constraints before revenue?
Because a facility's actual sellable capacity is the minimum of its power, space, and cooling constraints, and revenue projected without first establishing this ceiling risks overstating achievable capacity if a constraint other than floor space actually binds first.
Does this template replace the underlying sector-specific modelling guides?
No. This template structures the overall model; the underlying mechanics for each module, capacity constraint calculation, revenue driver decomposition, power and cooling cost derivation, contract term modelling, should follow the modelling guides referenced throughout this pillar.
How often should a model built on this template be updated?
On a rolling basis as new occupancy, pricing, power cost, or contract data become available, with driver assumptions re-sourced from the facility's own current operating data at each update rather than held static from the model's original build.
Related Articles
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.
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.
Rack Revenue Models
Rack revenue is the core billing unit of colocation data centre revenue, priced per rack, per kW of committed power, or a hybrid of the two, with premium pricing for higher-density racks. This guide sets out the mechanics of rack-based pricing, density tiering, and how to model power draw billing and contract escalation without conflating them into a single blended average rate per rack.
Data Centre Operating Cost Models
A data centre operating cost model should separate power, cooling, maintenance, staffing, security, and insurance into distinct, activity-linked cost categories rather than a single blended operating cost percentage of revenue. This guide sets out the full operating cost structure, how each category's driver differs, and why a blended cost assumption conceals which category is actually responsible for a margin change.