From Perfect-Foresight Dispatch to a Financeable Battery Revenue Case
The previous posts built a dispatch framework. Given a price path, operating costs and a state-of-charge constraint, it can produce an optimal schedule and a revenue benchmark.
That benchmark is not automatically a forecast and certainly not automatically a financing case.
For illustration, this post keeps the old 100 → 72 → 61 bridge visible, but changes what it means:
Perfect-foresight benchmark 100.0
Illustrative forecast / operating adjustments × 0.72
= Illustrative achievable case 72.0
Illustrative lender crediting assumption × 0.85
= Illustrative financing case 61.2
Neither 72% nor 61% is a market benchmark. They are scenario outputs. The actual bridge has to be measured from forecast-driven backtests, equipment availability, degradation / augmentation assumptions, market frictions, contract structure and the lender’s own revenue-crediting methodology.
That distinction matters because storage debt financing is still constrained by perceived technical risk and unpredictable power-market cash flows — a challenge DOE’s Loan Programs Office identifies explicitly for commercial storage deployment.
This post closes the series by separating three questions that are often collapsed into one number:
- what could the asset earn with perfect information?
- what is it expected to earn with real information and real equipment?
- what portion of that expected cash flow will the financing actually credit?
ℹ️ Note: All bridge factors below are labelled assumptions or measured outputs. None should be copied into another project without reproducing the calculation.
From theoretical dispatch to financing case:
flowchart LR
A[Perfect-foresight benchmark] -->|forecast-driven dispatch + physical operating case| B[Achievable operating forecast]
B -->|contract terms + lender revenue crediting + coverage case| C[Financing case]
Why Perfect Foresight Overstates
Because the model knew tomorrow's prices and the operator will not.
Perfect-foresight dispatch is a useful analytical upper bound because it lets the optimizer see the realized price path. A live operator instead acts on forecasts, bids, awards and updated market information, so forecast-driven performance has to be measured separately.
That upper-bound schedule can select ex post best charge / discharge opportunities without forecast error. A live operator sees imperfect information, and forecast errors can affect both price level and ordering.
Level errors — the forecast peak is $80 and the outturn is $95. Costly but recoverable; the battery still discharged into a good hour.
Ordering errors — the forecast says the peak is at 18:00 and it arrives at 17:00. Expensive, because the battery either discharged early into a lower price or held through the actual peak waiting for one that never came.
The second is what the storage-value rule from the discharge post is genuinely exposed to. A rule that holds for something better is only as good as its belief that something better is coming.
Do not import a generic foresight factor. Measure it where possible by replaying the historical dispatch with the forecasts or information that were actually available at each decision time, then compare that result with the perfect-foresight benchmark.
Move Physical Effects Into the Physical Model
Availability, degradation and market frictions should not automatically be three multiplicative haircut factors.
Availability. Model actual planned / forced outage windows, derates and communication / auxiliary constraints where data exist. A flat 97% factor is a worked shortcut and can misstate value if outages correlate with high-price periods.
Degradation. Prefer an annual usable-MWh / MW trajectory plus explicit augmentation plan. Degradation changes the feasible dispatch and capacity accreditation; multiplying revenue by 0.90 can double-count or mis-time the effect.
Market / settlement frictions. Include the real items the optimization omitted: auxiliary load, imbalance / settlement rules, fees, bid execution, interval granularity and other market-specific charges.
The worked multiplicative bridge can still be used for screening:
Perfect-foresight benchmark 100.0
× forecast-performance assumption 0.85
× availability shortcut 0.97
× degradation shortcut 0.90
× friction shortcut 0.97
= worked achievable case 72.0
But each factor should be replaced by a modeled mechanism as the project matures.
Do Not Pre-Decide Which Adjustment Matters Most
In the worked bridge, forecast error happens to be the largest deduction. That is not a general storage result.
Another project can be dominated by:
- availability / outage concentration;
- capacity fade or augmentation;
- nodal basis and congestion;
- ancillary-service rule changes;
- tolling performance deductions;
- interconnection limits;
- forecast / bidding quality.
The investment decision should therefore publish:
Adjustment
Source / evidence
Revenue stream affected
Base-case impact
Downside impact
Owner / counterparty bearing the risk
Then management can see where better data, engineering, contracting or forecasting actually creates value.
What a Lender Will Lend Against
Whatever the financing documents, lender case and independent market / technical diligence support.
There is no universal lender multiplier such as 0.85 applied to an “achievable” merchant battery forecast.
A lender can instead:
- size primarily to contracted toll / capacity payments;
- credit a portion of merchant revenue under a defined consultant case;
- use P50 / P90 / downside price and dispatch cases;
- apply higher DSCR to merchant cash flow;
- limit the merchant tail / tenor credited;
- sweep excess cash or require reserve support.
The correct model therefore has a lender-case bridge, not a generic haircut:
Operating revenue case
→ lender-approved price / dispatch assumptions
→ lender-approved availability / degradation
→ contracted vs merchant revenue treatment
→ CFADS
→ DSCR / PLCR / leverage sizing
Public storage contracts show why contract form matters. Energy Vault disclosed a tolling structure with a Monthly Floor that is reduced based on availability and round-trip efficiency, plus a share of net market revenue above the effective floor. APS disclosed storage PPAs granting charge / discharge rights in exchange for fixed monthly capacity payments. Those structures create different bankability from a fully merchant optimizer arrangement.
A toll therefore does not necessarily “remove forecast error entirely” for the owner: performance deductions, availability, RTE, throughput, default and residual merchant-sharing provisions still matter.
Apply the Bridge Per Revenue Stream
Each revenue stream has different operational and credit exposure.
| Revenue stream | Main operating dependency | Contract / credit treatment to test |
|---|---|---|
| Energy arbitrage | forecast, SOC, spreads, execution, degradation | merchant forecast methodology / haircut / DSCR |
| Ancillary services | qualification, award, SOC, deployment, performance | market-rule and lender treatment |
| Capacity | accreditation, availability, performance obligations | cleared / contracted payment and penalty regime |
| Toll / lease floor | contract availability, RTE, throughput and default terms | counterparty credit + contract formula |
| Merchant upside above a floor | market performance after contract deductions | often treated separately from base contracted layer |
So build the revenue bridge per stream, then sum the resulting cash flows.
Do not assume capacity has zero forecast risk or a “small lender haircut” merely because it is paid on MW; accreditation and performance can change. Do not assume ancillary awards are known enough to avoid forecasting; market prices, qualification and deployment still matter.
Who Bears the Forecast and Dispatch Risk?
The executed route-to-market, tolling or optimization agreement decides.
Possible structures include fixed fees, revenue shares, floors, guarantees, tolls or hybrid incentives. The useful diligence questions are:
- who controls bids and dispatch;
- who bears price / forecast error;
- who bears degradation and augmentation cost;
- what throughput / SOC / warranty constraints the optimizer must respect;
- what benchmark governs incentive fees;
- what happens if availability or RTE falls below the contract standard;
- who receives merchant upside and who funds downside shortfalls.
An optimiser paid on gross revenue can have different incentives from an owner exposed to battery degradation. Align that with explicit throughput / lifetime economics rather than a generic $30/MWh charge.
The Test That Validates a Model
One check separates a credible storage revenue forecast from an optimistic one, and it is cheap.
Backtest against a period the model has not calibrated to, using only information available at the time. Give the dispatch logic archived forecasts / market information rather than outturn prices, and compare the result with the perfect-foresight upper bound and, where genuinely comparable, realized project or fleet benchmarks.
The gap to perfect foresight is an information / execution diagnostic rather than a universal “forecast error factor.” A gap to a realized benchmark also needs normalization for node, duration, availability, market products and commercial strategy.
Two failure signals worth naming.
A model that matches perfect-foresight revenue has been given information it will not have. Check whether the price series used for the dispatch decision is the same one used for settlement.
A model with no idle hours across a broad historical sample deserves scrutiny. It may be valid in an unusually rich multi-product case, but check SOC feasibility, cycling economics, throughput limits and whether the optimizer is using hindsight information.
The Benchmark Problem
Fleet revenue benchmarks are useful reality checks and weak project forecasts.
Before comparing a project with a fleet or index, normalize at least:
- node / zone;
- duration and MW/MWh ratio;
- commissioning vintage;
- availability / outages;
- revenue streams included;
- route-to-market arrangement;
- ancillary qualifications;
- cycling and degradation policy.
Use a benchmark to ask why the project should differ, not to replace the project dispatch model.
For validation, prefer a clean out-of-sample test: run the strategy on historical periods it did not calibrate to, using only the forecasts / market information available at the time, and compare both revenue and physical behavior with a perfect-foresight upper bound.
How Do You Build the Bridge in Excel?
Build a layered bridge whose mechanisms can be audited.
1. Hindsight benchmark
PF_PerfectForesightRevenue
Use outturn prices only to establish the upper-bound dispatch benchmark.
2. Forecast-driven operating case
PF_ForecastDrivenRevenue
PF_ForesightRetention = ForecastDriven / PerfectForesight
Measure this from archived forecasts where possible.
3. Physical case
Replace generic haircut factors with:
Annual usable MW / MWh
availability / outage schedule
efficiency / auxiliary consumption
degradation and augmentation
SOC / ancillary constraints
4. Contract / settlement layer
Toll / floor formula
availability / RTE deductions
optimizer fee / revenue share
market fees and settlement
counterparty / termination terms
5. Lender case
Lender-approved revenue streams
lender price / dispatch case
CFADS
DSCR / PLCR / leverage
merchant tail / sweep assumptions
Worked shortcut — clearly labelled
If a screening model still uses the old illustrative factors:
100 × 0.85 × 0.97 × 0.90 × 0.97 = 72.0
72.0 × illustrative 0.85 financing sensitivity = 61.2
Report those as scenario sensitivities, never as “achievable revenue” and “bankable revenue” facts.
What Do Operators and Lenders Actually Check?
- Was the dispatch optimised against outturn prices or against forecasts?
- What foresight factor is applied, and was it measured or assumed?
- Does the backtest use only information available at the time?
- Is degradation applied to revenue, or only to the capacity schedule?
- What does the lender credit, and is merchant revenue in the debt sizing at all?
- Is there a toll or floor converting any of this into contracted revenue?
- Which adjustment is largest, and is effort going there?
Frequently Asked Questions
Why does a backtest overstate battery revenue?
Because it optimises against prices that actually occurred. A real operator dispatches against a forecast, and forecast errors — particularly in the timing of the peak rather than its level — cost revenue that the backtest never gives up.
How much is lost between optimised and achievable?
There is no universal percentage. In the old worked shortcut the factors reduced 100 to 72, but a real project should measure forecast performance and model availability, degradation, auxiliary load and settlement mechanics directly.
What will a lender lend against?
Whatever the approved lender case supports after contract, consultant, technical and coverage-ratio assumptions. Some financings emphasize contracted toll / floor revenue; others can credit defined merchant cases. There is no universal 61% retention factor.
How do you measure the foresight factor?
Run the dispatch model twice over the same historical period — once with outturn prices and once with the forecasts that were actually available at the time. The ratio is the factor, measured on your market and your strategy.
Should the bridge be applied to total revenue?
No. Build it by revenue stream because energy, ancillary, capacity and toll payments have different physical, contractual and credit risks.
Who bears the forecast gap in practice?
The contract decides. Read dispatch control, revenue share / floor, availability, RTE, throughput, guarantee and termination provisions before allocating the risk.
Where should effort go to close the gap?
Where the project-specific bridge shows the largest value leakage or uncertainty. That can be forecasting, availability, degradation, contract design, basis, interconnection or market-product eligibility.
Closing: Separate the Upper Bound, Operating Case and Financing Case
A perfect-foresight dispatch is useful because it tells you what the physical asset could have earned with hindsight.
It is not a forecast.
The next step is not to multiply it by a universal “operator factor” and then a universal “lender haircut.” It is to rebuild the revenue through the information, physical, contractual and credit constraints the project will actually face.
That produces three numbers worth keeping separate:
Hindsight / theoretical benchmark
Forecast-driven operating case
Lender-approved financing case
The bridge between them is more valuable than any one percentage because it identifies who bears each risk and what would have to change to improve the financeable cash flow.
That closes the standalone sizing-and-dispatch series. The next analytical layer is co-location: once storage shares an interconnection with generation, the same SOC and dispatch logic has to operate inside a second asset's output and grid constraint.
Sources: NREL SAM — front-of-meter battery dispatch, degradation and replacement modeling · Energy Vault SEC filing — 10-year tolling Monthly Floor adjusted for availability and round-trip efficiency, plus market-revenue upside share · Ormat 2026 filing — storage portfolio includes merchant and fixed tolling revenues and seeks additional tolling to reduce volatility · Pinnacle West / APS 2026 filing — storage PPAs with charge/discharge rights and fixed monthly capacity payments · ERCOT current Nodal Protocols · Dezzmond analysis; 0.85/0.97/0.90/0.97 and 61.2% figures are illustrative sensitivity inputs only.