Colocation billing models, explained
Space is the easy part. Power is where colocation contracts are actually settled — and where most billing systems quietly give up.
A colocation contract looks simple from the outside: a tenant rents racks, draws power, and pays monthly. In practice the invoice is three different pricing mechanisms stacked on top of each other, each with its own unit of measure, its own data source and its own argument waiting to happen.
Below are the five power billing models in common use in Australian data centres, what each one optimises for, and what it demands from the system that has to produce the invoice.
1. Committed capacity (take-or-pay)
The tenant contracts for a fixed capacity — say 420 kW — and pays for it whether they draw it or not. This is the model that underwrites construction: it converts an operator's capital commitment into predictable revenue, which is exactly what a lender wants to see.
It bills cleanly because there is nothing to meter. The complication is everything wrapped around it: ramp schedules where committed capacity steps up over the first 12–24 months, hold periods, early termination, and expansion rights that change the commitment mid-term.
What billing has to handle
2. Metered consumption
The tenant pays for what they actually draw, measured at the rack, the cage or the busway. Attractive to tenants, and increasingly expected by anyone who has grown up on cloud pricing. Much harder for the operator, who carries the risk of stranded capacity that was built but is not being paid for.
It also moves the billing system's dependency from the contract to the meter estate. Branch circuit monitoring and intelligent PDUs produce a lot of readings — a few hundred circuits polled every five minutes is millions of data points a month — and every one of them eventually has to reconcile against the site's NMI.
3. Greater-of
Bill the committed capacity or the metered draw, whichever is higher. This is the pragmatic middle: the operator keeps a revenue floor, the tenant accepts they will pay for genuine overuse.
It is also the model most likely to produce a disputed invoice, because it requires both mechanisms to be right simultaneously and the tenant only ever notices in the month the metered figure wins.
4. PUE recovery
IT load is only part of what a tenant costs the facility. Cooling, UPS losses, lighting and distribution all consume power that has to be recovered from somewhere. The usual mechanism is a PUE multiplier applied to each tenant's IT load, or a share of site overhead apportioned by IT load.
The number matters more than it used to. Facility efficiency is now rated, published and compared — NABERS rates Australian data centres across infrastructure, IT equipment and whole-facility efficiency, and government procurement has begun to lean on those ratings. A PUE figure that appears on a tenant invoice is a number the tenant can check against a public rating.
What billing has to handle
5. Energy pass-through
Rather than pricing power as a fixed rate, the operator passes through what they actually paid — spot exposure, hedged position, PPA-backed supply, network demand charges, environmental certificates — with a margin or management fee.
This is the model that turns a data centre operator into something that looks a lot like an energy retailer, and it is where most general-purpose billing platforms fall over. It needs interval data, a tariff engine that understands network demand charges, and the ability to explain a bill that changes because the market moved.
Side by side
| Model | Revenue predictability | Tenant appeal | Data it depends on |
|---|---|---|---|
| Committed kW | Highest | Low | Contract schedule only |
| Metered | Lowest | Highest | Sub-meter estate, 5-min interval |
| Greater-of | High | Moderate | Both — reconciled every cycle |
| PUE recovery | Moderate | Moderate | Site draw + total IT load |
| Pass-through | Variable, margin stable | High | Wholesale + network + meter |
What AI density changed
Every one of these models was designed when a well-filled rack drew 5 to 8 kW. AI training and inference racks draw 40, 60, and beyond, with liquid cooling attached. Three things break at once.
- Space stops being the unit. A tenant taking six racks at 60 kW is a bigger customer than one taking forty racks at 5 kW. Pricing per rack stops describing the relationship.
- Cooling costs diverge. Liquid-cooled halls and air-cooled halls no longer share an overhead profile, so a single facility-wide PUE multiplier over-charges one set of tenants to subsidise another.
- Compute becomes billable. Operators moving up the stack are selling GPU-hours, not just the space the GPUs sit in — which is a usage-based product with reserved, on-demand and burst tiers, commitment drawdown and overage.
That last one is the significant shift. The moment an operator sells compute rather than only space and power, they have taken on a rating problem that looks far more like telco or energy retail than traditional property: high-volume usage records, tiered rate cards, commitments drawn down over time, and tenants who expect to see it all reconciled on one statement.
The practical test
Whatever model you use, the billing system has to answer one question on demand, for any line on any invoice: where did this number come from? A committed figure traces to a contract clause and a ramp date. A metered figure traces to a set of interval reads. A PUE charge traces to the site total and the tenant's share. A GPU line traces to job records.
If those traces live in spreadsheets maintained by one person who understands them, the model is not the constraint — the system is.
All five models, one rating engine.
Utilities Group models committed capacity, metered draw, greater-of, PUE recovery and pass-through energy as first-class billable events — alongside cross-connects, remote hands and GPU-hours on the same contract.