Energy Revenue Models
Executive Summary
Key Takeaways
- ✓ A power project's revenue should be decomposed into contracted (PPA), capacity, and merchant components, each modelled separately with its own price-setting mechanism, rather than a single blended tariff applied to total output.
- ✓ The contracted component should reference the specific PPA pricing formula, volume structure, and escalation mechanics rather than a flat contracted price.
- ✓ The merchant component should be modelled with a forward price curve and an explicit sensitivity range, since it is the revenue component carrying genuine market price risk.
- ✓ Blended revenue-per-unit assumptions are the most common construction shortcut in this domain and the most damaging to sensitivity testing, since they prevent any single revenue driver from being tested independently.
- ✓ The reconciled total revenue output should tie back to the sum of its components exactly, with no unexplained residual between the modelled components and the reported total.
Objective¶
This guide covers how to build a power project's electricity revenue stack within Energy Financial Modelling, decomposing contracted, capacity, and merchant revenue into separately priced, explicitly modelled components.
The Revenue Stack¶
Contracted (PPA) revenue. Priced according to the specific power purchase agreement's formula, volume structure, and escalation mechanics. See Power Purchase Agreement Modelling.
Capacity revenue. Paid for available capacity, independent of dispatch, and modelled separately from any energy revenue earned when the asset is actually dispatched. See Capacity Payment Models.
Merchant revenue. Sold at prevailing market price with no fixed contract, modelled through a forward price curve and an explicit sensitivity range rather than a static assumption. See Merchant Power Models.
Why Decomposition Matters¶
Each component carries a distinct risk profile: contracted revenue is near-certain within counterparty risk, capacity revenue depends on availability rather than dispatch, and merchant revenue carries genuine, open market price risk. A blended revenue-per-unit assumption applied across all output conceals which of these three profiles actually applies to a given portion of revenue, and prevents a reader from testing any one component's sensitivity independently of the others — for example, testing a downside merchant price scenario without also, incorrectly, flexing the contracted revenue that should be unaffected by market price movements.
Reconciling the Stack to a Total¶
The sum of the contracted, capacity, and merchant components should tie exactly to the model's reported total revenue figure. A residual between the sum of the components and the total indicates either a missing revenue source (a component not yet built into the stack) or double-counting (the same output volume attributed to more than one component), and should be resolved before the model is relied upon for any decision.
Relationship to LCOE¶
The revenue stack, once built, should be tested against the project's levelized cost of energy as a cross-check: a revenue stack whose blended realized price falls persistently below LCOE indicates either an unsustainable contract structure or an overly optimistic merchant price assumption.
Common Construction Pitfalls¶
Blended revenue-per-unit assumption. Applying a single price per unit of output across the full revenue build, rather than decomposing by component, is the most common and most damaging shortcut in this domain.
Escalation applied uniformly. Applying a single inflation or escalation assumption across contracted, capacity, and merchant components, when each may have its own contractual or market-driven escalation mechanic, misstates the revenue build's forward trajectory.
Unreconciled residual. Allowing the sum of modelled components to diverge from the reported total revenue figure without identifying and resolving the cause.
Recommended Practices¶
- Build contracted, capacity, and merchant revenue as separate, explicitly priced modules.
- Reconcile the sum of the components to the reported total revenue figure with no unexplained residual.
- Apply escalation and price assumptions specific to each component's actual contractual or market basis.
- Cross-check the blended realized revenue stack against LCOE as a sanity check on overall project economics.
Continue Reading¶
Related Pillars¶
Related Technical Guides¶
- Power Project Financial Model Structure
- Power Purchase Agreement Modelling
- Capacity Payment Models
- Merchant Power Models
Related Glossary¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
Why should energy revenue be decomposed rather than modelled as a single blended tariff?
Because contracted, capacity, and merchant revenue each have different price-setting mechanisms and risk profiles — a blended tariff conceals which component is actually driving revenue and prevents any one component from being sensitivity-tested independently of the others.
How should the contracted (PPA) revenue component be modelled?
Referencing the specific power purchase agreement's pricing formula, volume structure (take-or-pay versus as-available), tenor, and escalation mechanics, rather than a flat contracted price applied across the full term — see Power Purchase Agreement Modelling.
How should the merchant revenue component be modelled?
With a forward price curve reflecting the market the asset sells into and an explicit sensitivity range around that curve, since merchant revenue carries genuine, undetermined market price risk that a static assumption would understate — see Merchant Power Models.
What is the most common construction error in energy revenue modelling?
Applying a single blended revenue-per-unit assumption to total output, rather than decomposing revenue into its separately priced contracted, capacity, and merchant components — this is the single most damaging shortcut to sensitivity testing in this domain.
How should the revenue components reconcile to a total?
The sum of the contracted, capacity, and merchant components should tie exactly to the reported total revenue figure, with no unexplained residual — any gap indicates either a missing component or a double-counted one.
References
Related Articles
Energy Financial Modelling
Energy financial modelling is the discipline of building financial models for power generation assets, independent power producers, and renewable energy projects — structured around a technical output schedule and an electricity revenue stack that a standard corporate or general project finance model has no direct equivalent for. This page is the hub for the Knowledge Centre's energy and power modelling content: how a power project model is architected, how electricity markets and dispatch mechanics translate into revenue, and how power purchase agreements, capacity payments, and merchant exposure combine into a project's revenue structure. Technology-specific renewable energy models (solar, wind, storage, hydro, and others), technical and commercial modelling mechanics, and institutional practice for this asset class are indexed here as the domain expands.
Power Project Financial Model Structure
A power generation financial model is architected around a technical output schedule — generation volume for a variable-output asset or available capacity for a dispatchable one — that drives every downstream calculation: the electricity revenue stack, the operating cost build, and, where the asset is project-financed, debt sculpting and covenant testing. This guide sets out that architecture as a sequence of explicit, separately built modules, distinct from a standard corporate model's revenue-growth-first structure.
Power Purchase Agreement (PPA) Modelling
A power purchase agreement is rarely a single flat price for the life of a project — it typically carries a specific pricing formula, a defined volume structure (take-or-pay versus as-available), a tenor shorter than the asset's full operating life, and its own escalation mechanics. This guide covers how each of these PPA components should be built explicitly into a power project financial model, and how the model should represent the transition once the PPA expires.
Capacity Payment Models
Capacity payments compensate a generation asset for being available to generate, independent of whether it is actually dispatched, and require a distinct modelling treatment from energy (dispatch-based) revenue. This guide covers how capacity payment mechanics — availability testing, penalty and de-rating provisions, and contract tenor — should be built into a power project model as their own explicit revenue component.
Merchant Power Models
Merchant power revenue is sold at prevailing market price rather than under a fixed-price contract, carrying genuine, undetermined price risk that a static assumption understates. This guide covers how to build merchant exposure into a power project model: constructing a forward price curve, testing an explicit sensitivity range around it, representing any hedging arrangement, and modelling the merchant tail that follows PPA or contract expiry.
Levelized Cost of Energy
Levelized cost of energy (LCOE) expresses the average discounted cost of generating one unit of electricity over an asset's operating life, combining capital cost, operating cost, and expected output into a single comparable figure. It is the standard metric for comparing generation cost across technologies and projects on a like-for-like basis, independent of each project's specific financing or contract structure.