Financial simulation

Background

As part of the simulator, we need to calculate the financial results of the asset given its solar generation and the expected prices on the markets. There are several important aspects to calculate the overall financial performance:

1. trading simulation
2. calculation of PPA settlements for assets with PPAs
3. calculation of expenses (capex and opex)
4. calculation of revenues

Calculation logic

Trading simulation

The simulator models participation in both day-ahead spot markets and balancing markets to provide a more complete picture of potential revenue opportunities for your assets.

Day-ahead spot market participation

We generate a bid for each day based on "simulated" forecasts. We create these forecasts by taking the expected actuals and introducing an error based on a certain expected RMSE. For assets with batteries, this bid will also depend on the results of the battery simulation.

We then calculate the imbalance based on the difference between the "real" generation and the plan submitted.

note

We are currently not simulating the effect of real-time battery adjustment to minimize imbalance. This will tend to slightly underestimate the revenues from battery operations. We plan to add this aspect in the future.

Balancing market participation

For assets with batteries, the simulator also models participation in the primary reserve offline market (一次オフライン枠). This allows you to evaluate additional revenue opportunities from providing frequency regulation services.

Supported assets

All assets with battery storage can participate in balancing markets, regardless of battery capacity.

info

In practice, individual assets must have a capacity of at least 1 MW to participate in the market. Assets with smaller capacities can participate only when aggregated, provided their total capacity meets or exceeds 1 MW. To simplify the current implementation, all assets with batteries are treated as eligible for participation.

Trading period

In the simulation, participation in the day-ahead spot market is prioritized over the balancing market. Because day-ahead operations mainly occur during solar generation hours, balancing market trades are restricted to a fixed nighttime period (provisioning period):

• Start: 18:00
• End: 6:00

During this period, batteries can provide frequency regulation services while still participating in day-ahead spot market trading during other hours.

Bid calculation

The simulator follows a two-step process:

1. Day-ahead spot market optimization: First, the battery optimization determines charging and discharging schedules for the full day based on solar generation, state of charge (SoC), and expected spot market prices.

2. Balancing market bids: Next, for the nighttime provisioning period (18:00-6:00), balancing market bids are calculated based on the battery capacity. In the event that balancing market and day-ahead spot commitments overlap, day-ahead spot operations take precedence and balancing market participation is excluded for those hours.

Operational assumptions

• During the provisioning period, the battery is assumed to provide upward adjustment and downward adjustment in equal amounts, resulting in no net change of SoC. To ensure sufficient capacity for balancing market operations, 50% of the capacity is reserved.

info

The current implementation does not account for efficiency losses, self-discharge, or battery degradation during balancing market operations.

• All submitted bids are assumed to clear (be accepted by the market).

Revenue calculation

Balancing market revenues are calculated based on capacity compensation:

• You can input an expected annual price in JPY/kW as part of your scenario assumptions
• The simulator calculates compensation from the total bid volume and this price
• Settlements are assumed to occur within the same month as the trades

Be aware that the model does not account for any compensation resulting from real frequency response activations.

info

For simplicity, the current implementation focuses on spot and balancing markets. We do not simulate intraday markets or other ancillary services such as secondary/tertiary reserves. These will be added in future versions.

Transaction fees Transaction fees are set annually by EPRX and calculated in yen per kW per 30-minute interval. Total participation fees are based on the latest published rates and are recorded as an OPEX item in the simulation results. For future years, the most recent fee is assumed to remain constant. For the latest fees, refer to this link.

PPA settlement calculation

For assets part of a PPA, we also calculate the settlements between the IPP and the offtaker, which will affect the total revenues.

Strike price calculation

The strike price depends on the PPA scheme:

• fixed: equal to the fixed PPA price
• fixed with inflation escalation: equal to the PPA price in the first year of the PPA contract, then increasing every year according to inflation assumptions in the scenario.
• fixed with escalation: equal to the PPA price in the first year of the PPA contract, then increasing every year according to the escalation factor in the contract.
• discount floor/collar: equal to the market price multiplied by a discount factor ($<=1$) and limited by optional floor and/or ceiling prices.

Settlement amount calculation

There are two main types of PPAs: physical and virtual. For physical PPAs, which include offsite, onsite, and self-wheeling PPAs, the energy produced by the plant during the validity of the PPA contract is not traded in the market, thus the trading simulation in these cases is not performed during the PPA period. All the energy produced is bought directly by the offtaker, and paid at the strike price, which represents the main revenues for the IPP.

For virtual PPAs, the energy is sold to the market, but later a settlement amount is calculated and there may be a transfer of funds between IPP and offtaker, depending on the market conditions. The settlement amount $S$ in this case is calculated as:

$S = P_{strike}(t) - P(t)$

$S$ the price (per kWh) that the offtaker needs to pay the IPP, or viceversa if the value is negative.

example

If during a certain slot $S$=4.5 JPY/kWh and the generation is 400 kWh, the offtaker will need to pay the IPP 1,800 JPY for that slot.

Expense calculation

We calculate expenses for each assets including capital expenses (CAPEX) and operational expenses (OPEX). The CAPEX depend on the CAPEX payment in input.

OPEX costs include:

• Operations and management (O&M). Assigned at the last day of the month.
• Asset management. Assigned at the last day of the month.
• Land lease. Assigned at the last day of the year.
• Insurance. Assigned at the last day of the year.
• Decommission reserve. This is paid only from year 11, and is assigned at the COD date of the asset.
• Inverter replacement. This is assigned at the same COD date of the asset, and is charged at the end of the inverter warranty period. So if the COD is 1 April 2020 and warranty is 10 years, the first payment will be on 1 April 2030.
• Property tax. This depends on a tax rate that can be set in input. The cost is assigned at the end of May of each year, assuming 17 years depreciation of the original taxable CAPEX expenses.
• Other OPEX, for generic/miscellaneous expenses. Assigned at the last day of the year.

Revenue calculation

The revenues are calculated by summing all the different components: revenues from the markets (day-ahead trades), balancing market revenues, imbalance cashflows, subsidy cashflows, and PPA settlements.

The total cashflow can then be calculated by subracting all the costs from the revenues.

IRR calculation

We calculate the yearly internal rate of return (IRR) on a monthly basis. We first calculate the monthly IRR, then we translate it into yearly IRR with this formula:

$\text{IRR} = (1 + \text{IRR}_{\text{monthly}})^{12} - 1$

info

There may be cases where IRR cannot be calculated. This may be due to missing or incomplete data (eg. missing CAPEX information) or because the calculated IRR would produce extreme values, which generally indicates that there are issues with the input data.