Skip to content
Request Demo

Take-or-Pay Contract

Glossary Term • Intermediate • 2 min read

Audience
Model Developers • Lenders • Investment Committees
Last Reviewed
July 2026
Updated
Version 1.0

Executive Summary

A take-or-pay contract is a common structure in hyperscale and larger colocation agreements under which the tenant is obligated to pay for its contracted capacity, whether measured in power, space, or both, regardless of whether it fully utilises that capacity during the contract term. This structure gives the operator a revenue floor independent of the tenant's actual utilisation pattern, which is particularly important during phased migrations or ramp-up periods when contracted capacity can materially exceed currently utilised capacity.

Key Takeaways

  • A take-or-pay contract obligates the tenant to pay for contracted capacity regardless of actual utilisation, giving the operator a revenue floor independent of the tenant's usage pattern.
  • This structure is common in hyperscale and larger colocation agreements, and is particularly relevant during phased migrations, when contracted capacity can materially exceed currently utilised capacity.
  • A financial model should recognise revenue from the contracted (take-or-pay) capacity schedule, not from an assumed utilisation curve, since the contract protects revenue regardless of utilisation.
  • Take-or-pay protects revenue but does not eliminate counterparty credit risk; if the tenant's financial position deteriorates or it exercises an early termination right where available, the revenue floor can still be at risk.

Definition

A take-or-pay contract obligates a data centre tenant to pay for its contracted capacity, power, space, or both, regardless of whether it fully utilises that capacity during the contract term.

Why It Matters to the Financial Model

This structure gives the operator a revenue floor independent of the tenant's actual utilisation pattern, which is particularly relevant during phased migrations or ramp-up periods, when contracted capacity can materially exceed currently utilised capacity. A hyperscale data centre model should recognise revenue from the contracted (take-or-pay) capacity schedule defined in the offtake agreement, not from an assumed utilisation curve, since the contract structure is what actually protects the revenue. See Data Centre Occupancy & Utilisation Models for the broader billed-versus-utilised capacity distinction this structure relies on.

Limits of Take-or-Pay Protection

Take-or-pay protects against utilisation shortfall risk but does not eliminate counterparty credit risk. If the tenant's financial position deteriorates, or it exercises an early termination right where the contract permits one, the revenue floor the structure otherwise provides can still be at risk, which is why downside scenarios for a take-or-pay-anchored facility should separately test tenant-specific counterparty risk.

Continue Reading

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

What is a take-or-pay contract in the data centre context?

A contract structure obligating the tenant to pay for its contracted power or space capacity regardless of whether it actually utilises that full capacity during the contract term, giving the operator a revenue floor independent of the tenant's actual usage pattern.

Why is take-or-pay common in hyperscale agreements specifically?

Because hyperscale tenants frequently contract for capacity ahead of a phased migration or growth ramp, and the operator needs revenue certainty to support the capital investment in building that capacity, which a take-or-pay structure provides regardless of how quickly the tenant actually ramps utilisation.

How should a model reflect a take-or-pay contract?

By recognising revenue from the contracted capacity schedule defined in the offtake agreement, not from an assumed utilisation curve, since the take-or-pay structure is what actually protects the revenue, independent of the tenant's utilisation pace.

Does take-or-pay eliminate all revenue risk?

No. It protects against utilisation shortfall risk but does not eliminate counterparty credit risk; if the tenant's financial position deteriorates or it exercises an early termination right where the contract permits one, the revenue floor the take-or-pay structure otherwise provides can still be at risk.

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.

Hyperscale Data Centre Models

Hyperscale data centre models finance a facility developed and leased to a single large cloud or technology tenant under a long-dated contract, structured around phased, capacity-denominated capex drawdown rather than a single completion event. This guide sets out how to model phased delivery, contracted revenue recognition, and the concentrated counterparty and power availability risks distinctive to this business model.

Data Centre Occupancy & Utilisation Models

Data centre occupancy modelling requires distinguishing three related but distinct capacity states: billed (contracted) capacity, actually utilised capacity, and total available capacity. This guide sets out how to model each state and the ratios between them, and why conflating billed occupancy with actual utilisation misrepresents both revenue durability and the facility's true remaining capacity headroom.

Request Demo