Financial Modelling for Data Centres: Ten Hands-On Insights That Make the Numbers Useful

##

How to turn megawatts, cooling, hardware and utilisation into an investment case
6 September 2026 · micara Advisory Team

At two in the morning, a data centre can be consuming electricity, rejecting heat and ageing expensive equipment without selling a single unit of useful compute.

The lights are on. Pumps are moving water. Fans and chillers are maintaining the operating envelope. Servers are ready. From an engineering perspective, the facility is active. From a commercial perspective, it may be idle.

That difference is where many financial models begin to fail.

A data-centre model is not principally a long spreadsheet containing escalation rates, debt schedules and tax calculations. It is a translation system. It must translate a physical asset into saleable output, and saleable output into cash flow. If the translation is weak, increasingly elaborate finance does not improve the answer. It only makes the weakness harder to find.

Edward Bodmer's work on data-centre modelling makes this point in a particularly practical way. The decisive inputs are not confined to a conventional income statement. They include IT capacity, facility load, cooling demand, PUE, electricity price, hardware replacement, utilisation and the chosen unit of output. The model becomes useful only when these variables are connected transparently.

The following ten insights describe how to make that connection.

1. Begin with the product, not the building

A data centre can be described in square metres, racks, megawatts, GPUs or tokens. All are valid measurements. They are not interchangeable.

The correct denominator depends on what the business sells. A colocation provider may earn revenue per contracted kilowatt or rack. A GPU cloud may sell GPU-hours. An AI infrastructure platform may price reserved clusters, completed workloads or tokens. A hyperscale owner-operator may value the capacity through the economics of a wider digital service.

The model must decide this at the beginning because total cost of ownership is meaningless without a unit of useful output. A cost of $1 million can appear efficient per building, expensive per kilowatt and either attractive or disastrous per million tokens. The denominator determines what the result says.

This leads to a practical design rule: keep the model's physical production chain visible.

`Installed IT capacity → available compute capacity → utilised capacity → saleable output → revenue`

Each arrow needs its own assumption. If the workbook jumps directly from installed megawatts to revenue, it has hidden the most important commercial risks inside one cell.

2. Distinguish IT capacity from total facility demand

A 100 MW data centre is an incomplete description. Does it mean 100 MW available to IT equipment, or 100 MW drawn by the complete facility?

The distinction is fundamental. Servers, storage and networking consume IT power. Cooling systems, pumps, fans, lighting, transformers and other infrastructure add facility overhead. Power Usage Effectiveness, or PUE, links the two:

`Total facility energy = IT equipment energy × PUE`

If 100 MW refers to IT capacity and PUE is 1.20, the facility requires 120 MW at the corresponding load. If 100 MW refers to the grid connection, the IT capacity is lower. Confusing the two affects power cost, equipment sizing, output and revenue at the same time.

The notation in the model should therefore make the boundary explicit. `MW_IT` and `MW_facility` are clearer than a generic row labelled `MW`. The same discipline should be applied to capital expenditure: costs stated per kilowatt of IT load should not be mixed with costs per kilowatt of total site demand.

This sounds elementary. Yet one ambiguous capacity label can propagate through hundreds of formulas and produce an answer that is internally consistent but physically wrong.

3. Separate load factor from commercial utilisation

Load factor and utilisation are often treated as synonyms. They describe different things.

Load factor concerns the operation of the physical system: how much of the available electrical and cooling capacity is active over time. Commercial utilisation concerns how much useful capacity is sold or otherwise monetised. A facility may have to cool installed equipment, maintain redundancy and run supporting systems even when customer demand is below plan.

This is similar to a hotel. The building remains heated, staffed and secure when rooms are empty. Occupancy determines revenue, but many costs follow the existence and operation of the hotel rather than the number of occupied beds.

The data-centre model should therefore carry at least three separate lines:

1. installed IT capacity;
2. operational load or availability; and
3. commercial utilisation of saleable output.

The distinction becomes especially important during ramp-up. Commissioning may be complete while clusters are still being installed, customers are migrating workloads or software is being optimised. Fixed costs arrive before commercial utilisation reaches maturity. Collapsing these stages into a single percentage makes early cash flow look stronger than the asset's operating reality.

4. Build the operating engine before the financing structure

Debt can make a weak project look like a sophisticated transaction. It cannot make the project economically sound.

The operating model should work before debt, tax and shareholder distributions are added. The first version needs only the physical timeline, revenue engine, operating costs, capital expenditure, replacements and unlevered free cash flow. From that structure, the project return and the required selling price can be tested without the noise of financing.

This sequence has a second advantage: it prevents circularity from spreading too early. Interest during construction, debt sizing, tax shields, covenants and cash sweeps can create circular calculations that make a workbook difficult to audit. If the operating case is still changing, every change then disturbs the financing machinery as well.

A robust order of work is:

`Operations → unlevered cash flow → required price and project return → tax → debt → equity return`

The order is not merely tidy. It clarifies responsibility. Engineering and commercial teams can challenge the operating assumptions before treasury and lenders optimise the capital structure around them.

5. Use a monthly model where the asset changes monthly

Annual models are attractive because they are compact. Data centres, however, are constructed, commissioned, filled and refreshed in months.

An annual column cannot represent an eight-month construction programme cleanly. It struggles with a phased energisation, a six-month utilisation ramp or an IT equipment replacement in month 28. It also smooths electricity-price seasonality and cooling loads that change with temperature.

A monthly operating model is therefore usually the practical core. It can show construction flags, operation flags, days and hours per period, capacity additions, ramp-up, replacement events, inflation indices and weather-sensitive operating costs. An annual summary can then sit above it for reporting and reconciliation.

This is particularly useful for hardware refreshes. Replacing equipment at the end of a calendar year is an accounting convenience. Replacing it after a specified number of operating months reflects the asset. The difference changes both the timing of capital expenditure and the amount of output lost during installation.

The model should not become granular merely for the pleasure of detail. Monthly resolution is justified when it captures timing that can change value. Hourly resolution should be reserved for questions that genuinely depend on hours, such as merchant power exposure, renewable matching or battery dispatch.

6. Model capital expenditure as a series of vintages

The building and the compute equipment do not share one economic life.

The shell, grid connection and parts of the electrical system may continue serving the site through several generations of IT equipment. GPUs, networking components and liquid-cooling interfaces can become commercially inferior much sooner. Some assets are replaced completely. Others are retained, expanded or modified to support the next hardware generation.

A single capital-expenditure line hides these different clocks. A better model separates at least:

• IT equipment;
• electrical and mechanical infrastructure;
• building and site works; and
• later replacements or upgrades.

Each category should have its own commissioning date, useful operating period, replacement percentage and cost-development assumption. IT equipment prices may decline while the power density and supporting infrastructure required per rack increase. A blanket inflation rate cannot capture that combination.

The replacement logic should also ask what happens operationally. Does the whole hall stop? Can equipment be changed in phases? Does the refresh increase token output per kilowatt? Is legacy hardware moved to lower-value inference, retained as a reserve or sold?

This is where technical obsolescence becomes financial rather than rhetorical. The model does not need to predict the exact next chip. It needs to show what the investment case assumes when the current one is no longer competitive.

7. Make PUE responsive to load, temperature and time

PUE is useful, but it is often given more certainty than the underlying system deserves.

The cooling and electrical overhead of a data centre can change with ambient temperature, partial load, equipment condition and control strategy. An annual average may be appropriate for a high-level comparison. It is not enough for a model in which electricity is a major cost and operating conditions vary materially.

The practical improvement is to turn PUE from a fixed input into a small operating function. At minimum, the model can contain low-, base- and high-PUE cases. A stronger version links PUE to monthly temperature and load. An advanced case uses hourly weather and dispatch data where the project is exposed to hourly power prices or variable generation.

The electricity calculation should remain readable:

`IT energy = MW_IT × operating hours × load factor`

`Facility energy = IT energy × PUE(load, temperature, age)`

`Electricity cost = facility energy × delivered electricity price`

Keeping the steps separate makes errors visible. It also allows the modeller to test a cooling retrofit without changing the revenue engine, or to test lower utilisation without pretending that every facility cost falls in proportion.

8. Model electricity as a procurement portfolio

A flat electricity price is suitable for an initial screen. It is rarely sufficient for investment approval.

A data centre may combine grid purchases, a power purchase agreement, on-site generation, storage and merchant-market exposure. Each source has a different volume profile, indexation mechanism, credit exposure and relationship to the facility's load. A yearly average price can conceal expensive hours, imbalance costs and a mismatch between renewable production and continuous demand.

The model should first calculate physical consumption, then assign that demand to procurement sources. For each source, it should show the available volume, price rule, delivery profile and residual exposure. Batteries should be included only with an explicit operating rule: when they charge, when they discharge, what efficiency is lost and what capacity remains after degradation.

This is one of the points at which hourly modelling may become unavoidable. If the commercial claim depends on matching a variable renewable resource to a near-continuous load, an annual energy balance is not evidence. It merely proves that the totals happen to be similar.

Power modelling should also test price shape, not just price level. Two scenarios can have the same annual average and very different cash costs if one concentrates high prices in the hours when the facility cannot reduce consumption.

9. Solve for the required price, not only the expected return

Most models calculate an internal rate of return from an assumed selling price. The reverse question is often more useful: what price must the project earn to achieve the target return?

This can be solved by setting the net present value of unlevered free cash flow to zero at the target discount rate and changing the unit selling price. In spreadsheet terms, it is a goal-seek problem. In investment terms, it is a direct test of competitiveness.

Suppose the model calculates a required price per GPU-month, per kilowatt-month or per million tokens. That price can be compared with actual customer contracts, observable market offers or the internal value of the compute. The gap between the two is more informative than a single IRR calculated from an optimistic revenue assumption.

This approach also makes sensitivities intuitive. Higher electricity cost raises the required price. Slower utilisation raises it again because fixed costs and capital are spread over less saleable output. Better performance per watt may reduce it, but only if the software and workload can convert the theoretical performance into useful production.

The best output page therefore shows both directions: the return produced by an assumed price and the price required for a target return.

10. Treat transparency as a control, not a formatting preference

A model is often reviewed long after its author has moved on. At that point, cleverness becomes a liability.

Complex lookup chains, volatile indirect references and large array calculations can shorten an individual formula while making the business logic difficult to follow. The problem is not that such functions are always wrong. It is that they increase the distance between an assumption and its consequence.

A stronger structure separates constant inputs, time-series inputs, calculations, scenarios and outputs. It uses short formula chains, explicit units and clear timing flags. Source sheets preserve the evidence behind important assumptions, including the date, technology, geography and basis of each benchmark. Low, base and high values remain visible rather than being overwritten when a scenario changes.

This is consistent with the FAST principles of flexible, appropriate, structured and transparent modelling. The standard does not demand decorative uniformity. It asks the workbook to be usable, proportionate and understandable.

The rule matters even more when artificial intelligence is used for research. AI can generate a fast list of candidate inputs. It can also return materially different values when the prompt changes. Such numbers are hypotheses until they are checked against manufacturer data, operating records, contracts or other auditable evidence. The model should record the source and range, not merely retain the most convenient answer.

A practical review sequence

Before presenting the model to an investment committee, five tests reveal a great deal.

First, change the definition of capacity. If the workbook cannot distinguish IT megawatts from facility megawatts, stop.

Second, reduce commercial utilisation while holding the physical load assumptions where appropriate. If electricity and cooling costs disappear in exact proportion to revenue, inspect the operating logic.

Third, move the commissioning date and the first hardware replacement by several months. If the cash flow barely changes, the time flags are probably too coarse.

Fourth, set the required return and solve for the unit price. Then compare the result with a defensible market or internal value benchmark.

Fifth, ask another modeller to trace one unit of revenue and one unit of electricity cost from input to cash flow. If the path cannot be explained without the original author, the workbook is not yet an investment tool.

The model should expose the decision

The purpose of a financial model is not to manufacture certainty. It is to show which conditions the investment depends on.

For a data centre, those conditions are physical before they are financial. Capacity must be defined. Power must cross a clear boundary. Cooling must follow load and weather. Hardware must age and be replaced. Useful output must be sold. Only then can a price, a return and a financing structure mean what they appear to mean.

A good model therefore behaves less like a calculator and more like a well-organised argument. Every important conclusion can be traced to an operating mechanism. Every critical assumption has a unit, a source and a scenario. Every apparent efficiency can be challenged without dismantling the workbook.

The final number may still be uncertain. But the reason for that uncertainty will be visible—and that is what allows investors, engineers and operators to make a better decision.

---

Sources and further reading

1. Edward Bodmer, Data Center Modelling, including the linked model-development examples and downloadable workbooks.
2. The Green Grid, PUE: A Comprehensive Examination of the Metric.
3. FAST Standard Organisation, The FAST Standard.
4. NVIDIA, Power and Thermals: GB200 NVL Multi-Node Tuning Guide.