Skip to content
Request Demo

Energy Model Documentation Standards

Technical Guide • Intermediate • 3 min read

Audience
Model Developers • Lenders • Advisory Firms
Last Reviewed
July 2026
Updated
Version 1.0

Executive Summary

Documentation for an energy or power project financial model should record, at minimum, the source and confidence level of every technical assumption, the pricing basis for each revenue stack component, and the logic behind any circular debt sculpting calculation, in addition to the general model documentation practice applied to any financial model. This guide sets out this domain-specific documentation standard.

Key Takeaways

  • Every technical assumption (resource yield, degradation, availability, O&M cost) should be documented with its specific source and, where applicable, the confidence level it represents, not left as an unlabelled input figure.
  • Each component of the revenue stack (contracted, capacity, merchant) should be documented with its specific pricing basis and escalation mechanism, so a reader can trace exactly how each figure was derived.
  • Debt sculpting logic, particularly where circular, should be documented explaining the intended convergence mechanism and any manual override switches present in the workbook, including their intended use and current state.
  • Documentation should be updated whenever a technical assumption or revenue term is revised, maintaining a visible version history rather than only reflecting the assumptions current at initial model construction.
  • This domain-specific documentation standard extends, rather than replaces, the general model documentation practice applicable to any financial model.

Objective

This guide sets out the documentation standard specific to energy and power project financial models, within Energy Financial Modelling, extending the general Model Documentation Standards applicable to any financial model.

Technical Assumption Sourcing

Every technical assumption — resource yield, degradation, availability, O&M cost — should be documented with its specific source (the named independent technical report, equipment warranty, or O&M contract) and, where applicable, the confidence level it represents. An unlabelled input figure cannot be independently verified or reconciled against the underlying evidence it should be based on, consistent with the sourcing discipline described in Technical Assumption Review for Energy Models.

Revenue Stack Component Basis

Each component of the revenue stack — contracted, capacity, and merchant — should be documented with its specific pricing basis and escalation mechanism, so a reader can trace exactly how each figure was derived, rather than a single documented "revenue" line with no visibility into its constituent components' individual bases.

Debt Sculpting Logic and Manual Overrides

Where debt sculpting is circular, its intended convergence mechanism should be documented, since this is not always self-evident from the formulas alone. Any manual override switch present in the workbook — used for troubleshooting or temporarily breaking circularity — should be documented with its intended use and current state; an undocumented override left in an unintended position is a recurring source of audit findings in this domain, as illustrated in A Wind Farm's Understated Wake Effect Loss Surfaces After Financial Close and the general treatment in Circularity in Debt Models.

Maintaining a Version History

Documentation should be updated whenever a technical assumption or revenue term is revised, maintaining a visible version history rather than reflecting only the assumptions current at initial model construction. Documentation that has not been updated since the model's original build becomes misleading once the model has been revised to reflect newer technical reports, amended PPA terms, or actual operating data.

Common Pitfalls

Unlabelled technical assumption inputs. Entering a yield, degradation, or cost figure without documenting its source or confidence level undermines the model's verifiability.

Revenue stack documented as a single line. Documenting total revenue without breaking out each component's specific pricing basis obscures how the figure was actually derived.

Stale documentation. Documentation left unchanged after a material assumption update misrepresents the current basis for the model's outputs.

  • Document the specific source and confidence level of every technical assumption.
  • Document each revenue stack component's pricing basis and escalation mechanism separately.
  • Document debt sculpting convergence logic and the intended use and current state of any manual override.
  • Update documentation whenever a technical assumption or revenue term is revised, maintaining a visible version history.

Continue Reading

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

Why document the source and confidence level of every technical assumption?

Because a resource yield, degradation, availability, or O&M cost figure without a documented source and, where applicable, confidence level cannot be independently verified or reconciled against the underlying technical report or contract it should be based on, undermining the model's credibility to a lender or reviewer.

What should revenue stack documentation include?

The specific pricing basis and escalation mechanism for each component — contracted, capacity, and merchant — so a reader can trace exactly how each revenue figure was derived, rather than a single documented "revenue" line with no visibility into its constituent components' individual bases.

Why document debt sculpting logic specifically, especially where circular?

Because circular debt sculpting calculations depend on an iterative convergence mechanism that is not always self-evident from the formulas alone, and any manual override switch present in the workbook (used for troubleshooting or breaking circularity temporarily) should be documented with its intended use and current state, since an undocumented override left in an unintended position is a recurring source of audit findings in this domain.

How often should documentation be updated?

Whenever a technical assumption or revenue term is revised, maintaining a visible version history — documentation reflecting only the assumptions current at initial model construction becomes misleading once the model has been updated to reflect newer technical reports, revised PPA terms, or actual operating data.

Does this documentation standard replace general model documentation practice?

No — it extends the general model documentation practice applicable to any financial model with the domain-specific items (technical assumption sourcing, revenue stack component basis, debt sculpting convergence logic) that are particular to energy and power project models.

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.

Model Documentation Standards for Financial Models

Model documentation standards define what written records must accompany an institutional financial model to enable its outputs to be understood, verified, and relied upon by parties other than its original developer. The minimum documentation package for an institutional financial model includes an assumption log recording the source and rationale for every input, a version history recording all material changes, a model map describing the structure and purpose of each worksheet, instructions for use, and a disclosure of known limitations. The ICAEW Financial Modelling Code and the FAST Standard both establish specific documentation requirements that define institutional expectations.

Resource Yield Assessment

A resource yield assessment is a technical study, typically prepared by an independent engineer, estimating the expected energy resource available to a generation asset — solar irradiance, wind speed, or hydrology — expressed at defined confidence (exceedance probability) levels such as P50 and P90. Each confidence level serves a distinct modelling purpose, and using the wrong one for a given purpose is a common structural error in renewable energy financial models.

Energy Revenue Models

A power project's electricity revenue is rarely a single price applied to total output — it is typically a stack of contracted (PPA), capacity, and merchant components, each with its own price-setting mechanism and risk profile. This guide covers how to build that revenue stack as separately priced, explicitly modelled modules, and how to combine them into a single reconciled revenue output without losing the visibility each component requires.

Circularity in Debt Models

Circularity in debt models arises from the interdependence of interest expense and cash availability in the same period. In a project finance model, interest is charged on the drawn debt balance; the interest payment reduces available cash; available cash determines the repayment amount; the repayment amount determines the closing debt balance; and the closing balance determines the next period's interest charge. When a model calculates interest on the average of opening and closing balances, or when a cash sweep mechanism uses the same period's interest cost in determining sweep amounts, a circular dependency is introduced. The two principal resolution techniques are: calculating interest on the opening balance rather than the average balance, and using a defined debt repayment algorithm that determines the repayment amount without reference to the closing interest charge.

Request Demo