Post: Your offtake structure is only as good as the platform sitting underneath it

Your offtake structure is only as good as the platform sitting underneath it

Guest post by GridBeyond Business Development Director (AU), Mark Netto

Offtake structures — virtual tolls, PPAs, revenue floors, cap contracts — are becoming the default for sub-5MW projects seeking finance.

Most developers spend their energy negotiating the contract terms. Fewer ask whether their platform can actually execute them.

The gap between a platform built for contracts and one adapted for them shows up in three places:

• whether it can hold contracted and physical obligations simultaneously
• whether nominations become hard constraints in the optimiser
• whether settlement is visible and auditable from both sides of the contract

Getting this wrong doesn’t just affect revenue. It affects your ability to get the next project financed.

Getting an offtake structure across the line is one of the harder commercial problems in sub-5MW project development.

It takes time, negotiation, and usually a financier pushing for it. By the time a developer has a signed virtual toll or a firmed PPA, most of the energy has gone into the contract itself.

What often gets less scrutiny is the platform that has to execute it.

That is a problem — because an offtake structure places specific, non-trivial demands on a battery optimisation platform. Demands that a basic market access arrangement or auto-bidding tool was never designed to meet.

The platform has to hold two states simultaneously

A virtual toll commits a defined portion of the asset’s capacity to an offtaker for a defined period.

In a typical BESS arrangement (or portfolio of sub5MWs), that might be 25 MW of a 50 MW asset’s capacity — a virtual battery sitting inside the physical one.

The platform must track both simultaneously.

How GridBeyond’s contracts layer works.

The virtual battery is what the offtaker sees and nominates against. The physical battery is what the optimiser actually controls — with its own constraints around state of charge, ramp rates, FCAS obligations, and connection point limits.

These are not the same thing. The physical asset has boundaries the virtual one doesn’t know about.

A platform that doesn’t maintain both states in real time cannot honour the toll without compromising the physical asset, or protect the physical asset without breaching the toll.

The optimiser needs to see both — the contracted obligation and the physical envelope — and find the best dispatch decision within the intersection of the two.

This is the foundational requirement that separates platforms built for contracts from those that have tried to adapt.

Nominations have to become constraints, not requests

When an offtaker submits a nomination — say, 25 MW available for the evening peak — that instruction needs to become a hard constraint inside the optimiser before the trading day begins.

Not a note passed between systems. Not a manual override applied by someone at a desk.

A constraint that visibly shapes the recommended dispatch schedule from the moment it is received.

If the nomination lands in a separate workflow and gets reconciled against the optimiser’s decisions after the fact, you don’t have an integrated contracts layer.

You have a manual process with contractual consequences.

The distinction matters because the optimiser is making decisions every five minutes.

A nomination that isn’t embedded in that decision loop from the start will be in conflict with it — and resolving that conflict reactively, in real time, is exactly the kind of operational problem that generates settlement disputes and offtaker relationship damage.

Multiple contracts, one optimiser

As a portfolio grows, so does the complexity of the contract layer above it.

A developer with three assets might have a virtual toll on one, a firmed PPA on another, and a cap contract on the third.

Or a single asset might carry multiple contracts simultaneously — a virtual toll with one counterparty covering part of the capacity, and a merchant position on the remainder.

A platform that handles contracts as separate, manually configured add-ons cannot manage this cleanly.

The interactions between contracts — how they compete for the same physical capacity, how they are prioritised when constraints conflict, how their settlement positions are tracked independently — require a contracts layer that is native to the optimiser, not bolted on top of it.

The same platform logic that manages one virtual toll should be able to manage a firmed PPA, a contract for difference, or a revenue swap without requiring a different configuration for each structure.

And it should be able to manage combinations of these across the same asset or the same portfolio.

Settlement has to be visible from both sides

The same market event looks different to the owner and the offtaker.

A price spike that generates revenue for the owner represents a delivery obligation for the offtaker. A period of negative prices affects their respective positions differently depending on the contract terms.

A platform that can show both perspectives — same event, owner and offtaker each seeing their own P&L, reconciled against the contract terms — is one that a lender or equity partner can actually audit.

The data exists in most platforms. The question is whether it is presented in a form that makes contract performance legible to a third party.

Lenders and equity partners financing sub-5MW portfolios are asking harder questions than they were two years ago.

They want bid-level records, settlement reconciliation, and performance against contracted obligations presented in a way they can verify independently.

A platform that generates this data passively but can’t surface it cleanly is a platform that creates friction at exactly the wrong moment — due diligence, refinancing, or asset sale.

Offtakers want portfolios, not projects

It is also worth being clear about what the offtake market actually looks like in practice.

Most serious offtakers — retailers, gentailers, large C&I buyers — are not looking to contract a single sub-5MW asset.

The minimum we have seen in the market is around 10MW, and that was only because it represented the first tranche of a much larger portfolio under development.

In practice, offtakers typically want 50MW or more before the commercial conversation becomes serious.

That changes the framing of the contracts question entirely.

The offtake structure that makes a portfolio bankable at scale is not available at project one.

It becomes available somewhere between project five and project ten, depending on asset size.

Which means the platform decision made at project one needs to be made with that endpoint in mind — not just with the immediate project in view.

A platform that cannot handle multiple contracts across multiple assets simultaneously will not be able to support the offtake arrangement when it eventually becomes available.

By the time that limitation becomes apparent, the portfolio is already built on the wrong foundation.

Built to sell

For many developers, portfolio construction is not the end goal.

It is the mechanism for recycling capital — selling stabilised assets to infrastructure investors or funds, redeploying the proceeds into new development, and building the portfolio incrementally.

That exit path has its own requirements.

An acquirer or infrastructure fund buying a portfolio of sub-5MW BESS assets will conduct detailed due diligence on performance history, contract compliance, degradation trajectory, and operational record.

They want to see continuous, auditable data across every asset — not a patchwork of records from multiple platforms, multiple monitoring systems, and multiple market access arrangements.

A portfolio built on a single integrated platform, with consistent performance reporting and a clean contract layer from day one, is a materially easier asset to sell than one assembled across multiple vendor relationships.

That difference shows up in valuation, in the length of the due diligence process, and in the confidence of the buyer.

The platform decision made at project one is, in this sense, also a decision about what the portfolio looks like to a buyer at project eight.

Most developers don’t think about it that way early enough.

Closing

If you’re working through offtake structures for a current project and want to understand what the platform requirements look like in practice, feel free to reach out.

Series note

This is the sixth in a series on what separates high-performing sub-5MW battery portfolios.

Previous articles covered:

• core capabilities required for sub-5MW portfolios
• forecasting performance as the foundation of optimisation
• hybrid optimisation and where value is lost
• operational performance and the gap between modelled and realised outcomes
• the distinction between market participation and optimisation