UNFCCC Additionality Tool

Additionality:

You hear a lot about how important it is for a project to be additional, but what exactly does additionality mean?

In the regulated Clean Development Mechanism (CDM) market established by the Kyoto Protocol, a project must show that:

• The project would not have occurred without the revenues generated by the sale of offsets.
• The project goes beyond a “business as usual” scenario
• Greenhouse gas emissions are lower with the project than they would have been without the project.

Any project that can sufficiently demonstrate these three points is deemed additional. The United Nations Convention for Climate Change (UNFCCC) created an Additionality Tool in order to help projects demonstrate these three points. The following summary of the Additionality Tool is meant to acquaint you with the process of proving additionality.

The Additionality Tool can be broken down into four steps: alternative scenario identification, investment analysis, barrier analysis, and common practice analysis. The barrier analysis is only required if the investment analysis finds negative results, otherwise it is optional.

Common Practice Analysis:

The first step is to identify realistic and credible alternatives to the proposed project. For example, an alternative scenario to a wind farm could be a solar farm that produces that same amount of electricity. Every proposed alternative must be comparable in terms of output produced (ie. Electricity, reduced GHG emissions, etc.) and comply with all mandatory applicable legislation and regulation.

Alternative scenarios are also identified based on the investor’s interest. For example, if the main investor in a project invests in only solar farms, then a wind farm is not a viable alternative.

If no other credible and viable alternatives are identified, then the project is not additional.

Investment Analysis:

The next step is to determine if any of the alternative scenarios are financially or economically more attractive than the proposed project. The project developer can choose between three analysis options: simple cost analysis, investment comparison analysis, and benchmark analysis.

Simple Cost analysis- The premise of this analysis is simple, a developer adds up all the economic benefits of a project and subtracts the economic costs. The project must show that the only economic benefits are CDM related income.

Investment comparison analysis- This analysis gathers benchmark financial indicators such as IRR, NPV, cost benefit ratio, or unit cost of service in pre and post CDM income scenarios. The project passes this test if the scenario after CDM income is introduced creates a much more practical investment opportunity than the pre CDM income scenario.

Benchmark analysis- The benchmark analysis is similar to the investment analysis, except a benchmark value is used to evaluate the pre and post CDM income profitability. This benchmark value is the standard return on investment in a market for a project of a particular risk profile. The pre CDM scenario must produce an investment indicator below that of the benchmark value, while the post CDM scenario produces an indicator above the benchmark value.

Barrier Analysis:

The goal of this analysis is to identify barriers that prevent the implementation of the proposed project while not hindering the implementation of at least one of the alternatives. These barriers can be technological, meaning the technology would be difficult to implement in the proposed area; investment/financial, the project faces unrealistic costs or rates of return; or prevailing practice, the project is a first of its kind and the local infrastructure cannot fully meet its needs. Clear and transparent documentation must be provided to prove these steps.

The proposed project passes this test if it faces barriers that at least one alternative does not.

Common Practice:

The project developer should identify similar projects in the area. An abundance of similar projects in the area may disprove that the project faces significant barriers that hinder its implementation. If any similar projects are identified, the developer must explain how the existence of such projects does not contradict the project’s additionality. The project is not additional if this fails to be explained in a convincing manner.