Executive Summary

For a decade, the BESS conversation focused on price per kilowatt-hour. That conversation is effectively over. BloombergNEF’s December 2025 survey put stationary-storage battery pack prices at $70/kWh, down 45% year-over-year and now the lowest-priced segment of the lithium-ion market, with chemistry converged across tier-one suppliers inside narrow engineering bands. Hardware is now table stakes. The differentiation (the returns, the bankability, the grid value) has moved up the stack to the software that decides when to charge, when to discharge, which market product to bid into, and how to sequence revenue streams across an operating day.

Three forces have converged in 2026 to lock this shift in place. First, market structure matured: FERC Order 841 (final 2018, enforcement 2019) and FERC Order 2222 (2020) opened ISO/RTO wholesale markets to BESS and aggregated DERs, but only in 2024–2025 have MISO, CAISO, PJM, and ERCOT implementations reached real operational depth. Second, deployment scale crossed a threshold: ERCOT alone passed 12 GW of installed battery capacity in Q3 2025 (Modo Energy), making merchant BESS the dominant US frontier. Third, compliance became a data problem. EU Regulation 2023/1542 introduces the Battery Passport mandate on 18 February 2027, converting every BESS above 2 kWh into a reportable, auditable data entity.

The practical implication for technology leaders is direct. Single-market dispatch, running a battery as an energy-arbitrage asset only, leaves the most profitable products on the table. Co-optimized dispatch across energy, regulation, reserves (RegUp, RegDown, RRS, ECRS, NonSpin), and capacity markets delivers materially higher revenue per megawatt-hour, but it requires forecasting, optimization, integration, and settlement infrastructure that most developers either under-build or outsource to black-box vendors. Project finance has caught up: lenders now treat operational SLAs, uptime guarantees, and software performance warranties as core underwriting items for BESS.

This paper maps the five-layer anatomy of a modern BESS control stack, quantifies the revenue gap between single-market and multi-market dispatch, names the failure modes that keep most projects in the bottom quartile, and lays out a build/buy/integrate decision framework for technology teams choosing how to own this layer. The conclusion is pragmatic: in 2026, a BESS project is a software project with a battery attached.

Why a Battery Is Only as Valuable as Its Dispatch Stack

For most of the last decade, the central question in battery energy storage was “how cheap can the cells get.” That question has been answered. BloombergNEF’s December 2025 survey reports volume-weighted stationary-storage battery pack prices at $70/kWh — down 45% year-over-year and now the lowest-priced segment of the lithium-ion market, below the EV pack average ($99/kWh) for the first time. Year over year, the cost curve continues to bend. Chemistry selection has converged: LFP for grid-scale duration, NMC for mobility and certain high-power applications. Tier-one cell suppliers (CATL, BYD, LG Energy Solution, Samsung SDI, Tesla) ship cells that perform within narrow engineering bands. For a merchant BESS developer procuring cells in 2026, cell selection has become a commodity sourcing exercise.

The implication is uncomfortable for anyone whose business model was built on hardware differentiation. If the cells are the same, the inverters are the same, and the enclosures are commodity-grade, every project starts at the same physical baseline. The operational and financial outcomes diverge from that baseline, sometimes by 30–50% on revenue, based entirely on the layer of software, control logic, and market integration that sits above the hardware. That layer is energy storage software: the forecasting, optimization, dispatch, telemetry, and settlement infrastructure that turns a physical battery into a revenue-producing market participant.

This shows up concretely in quarterly earnings, in project finance covenants, and in the spread between what a top-quartile operator earns per installed megawatt-hour and what a bottom-quartile operator earns on identical hardware. The battery is the asset. The control stack is the business.

What Energy Storage Software Actually Does

“Energy storage software” is a phrase that hides more than it reveals. It describes a five-layer stack, with each layer doing a specific job and failing in recognizable ways when under-built or misintegrated. A technology leader evaluating a BESS project, or a lender underwriting one, needs to understand the layers as distinct functions with distinct accountability.

At the physical base sits the Battery Management System (BMS), which monitors cell voltage, current, temperature, and state of charge, and enforces safety limits. The BMS is mandatory safety hardware that sits below the control stack: the nervous system of the physical asset. Above it, the Energy Management System (EMS) integrates the BMS with site-level controllers (inverter, transformer, auxiliary loads) and exposes dispatch setpoints. Above the EMS, the dispatch optimization engine decides what those setpoints should be. It forecasts price and reserves, runs the co-optimization that sequences revenue streams across markets, and produces bids and schedules. Above the optimizer, the market interface and telemetry layer sends bids into ISO/RTO systems, receives awards and dispatch instructions, translates them into EMS commands, and streams operational data back for settlement. Finally, the settlement and reporting layer reconciles operational data against market awards, computes revenue, generates the evidence trails that lenders and regulators now require, and increasingly feeds compliance systems like the coming EU Battery Passport.

Layer What it does Common failure mode Default build/buy posture
Battery Management System (BMS) Role: Cell-level monitoring and safety enforcement — voltage, current, temperature, state of charge, cell balancing. Failure: Treated as “software” and bundled with higher layers, blurring accountability for cell-safety vs. dispatch logic. Posture: Buy — from the cell/pack vendor; hardware-specific and safety-critical.
Energy Management System (EMS) Role: Site-level integration of BMS with inverter, transformer, and auxiliary loads; exposes dispatch setpoints. Failure: Rules-based scheduler marketed as an “optimizer”; cannot co-optimize across market products. Posture: Integrate — buy a validated EMS core and extend under operator architecture.
Dispatch Optimization Engine Role: Forecasts prices and reserves, runs co-optimization across energy + ancillary + capacity markets, produces bids and schedules. Failure: Outsourced to a third-party “autobidder”; operator concedes the layer where revenue differentiation actually lives. Posture: Build — this is the differentiating layer.
Market Interface & Telemetry Role: Submits bids into ISO/RTO systems, receives awards and real-time dispatch signals, streams operational data back for settlement. Failure: Dispatch latency >5 seconds on ancillary awards; structurally excludes the fastest-paying products. Posture: Integrate — use pre-certified protocol accelerators (IEEE 2030.5, SunSpec, OpenADR) and own the integration logic.
Settlement & Reporting Role: Reconciles operational data against ISO awards, computes revenue, produces lender and regulator audit trails; feeds EU Battery Passport. Failure: Settlement drift goes undetected for quarters; revenue variance gets misattributed to “market conditions.” Posture: Build — owned infrastructure with vendor components for regulated file formats only.

The single most common mistake in BESS projects is treating these layers as one system, usually because a hardware vendor sells a bundled “software” offering that confuses the BMS with the EMS, or an EMS provider claims to have a “dispatch engine” that is in fact a rules-based scheduler. Each of these layers has a different build/buy economic profile, a different failure mode, and a different integration pattern. Treating them as a single procurement line item is how bottom-quartile projects are born.

Revenue Stacking Is a Software Problem, Not a Market Problem

The phrase “revenue stacking” has become the shorthand for what separates profitable BESS operators from the rest. It is also widely misunderstood. Revenue stacking is, first and foremost, a software capability. Every major US ISO has the product set required to stack revenue: energy arbitrage, regulation up and down, spinning and non-spinning reserves, and capacity. ERCOT, California (CAISO), PJM, MISO, and NYISO all clear multiple product markets simultaneously. Market design has allowed revenue stacking for years. The binding constraint has always been the operator’s software.

Running a BESS against a single product (say, energy arbitrage only) is conceptually simple: forecast nodal price spreads, charge when low, discharge when high. Running a BESS against five product markets simultaneously is a different class of problem. The optimizer must jointly maximize expected revenue across product markets while respecting state-of-charge constraints, throughput warranties, degradation cost functions, and real-time dispatch signals. It must do so under price uncertainty, ancillary-award uncertainty, and the compound risk that a real-time energy dispatch can strand the battery in a state that forecloses the next hour’s ancillary commitment.

The revenue gap is consistent and large. ERCOT’s merchant BESS economics, which a companion piece in this sprint unpacks in detail, illustrate the point: operators running co-optimized dispatch across energy + ECRS + RRS have materially outperformed energy-only operators since ECRS launched in June 2023, and industry tracking from Modo Energy has repeatedly shown 30–50% revenue deltas in top-versus-bottom-quartile comparisons on similar hardware. The same pattern holds in CAISO (energy + RegUp/RegDown + Resource Adequacy) and in PJM (energy + synchronized reserve + capacity).

Market / product Single-market dispatch (energy arbitrage only) Multi-market (co-optimized) dispatch Approximate revenue delta
ERCOT (Texas) Revenue streams: Day-ahead and real-time energy arbitrage only. Revenue streams: Energy + RRS + ECRS + RegUp/Down + NonSpin, jointly co-optimized. Delta: +35–50% per installed MWh (Modo Energy benchmarks, 2024–2025).
CAISO (California) Revenue streams: Day-ahead and real-time energy arbitrage only. Revenue streams: Energy + RegUp/RegDown + Resource Adequacy capacity. Delta: +25–40% per installed MWh.
PJM Revenue streams: Energy arbitrage only, nodal LMP. Revenue streams: Energy + Synchronized Reserve + Regulation + capacity auction. Delta: +20–35% per installed MWh.
Software requirements Stack needed: Single-product forecaster; rules-based EMS scheduler; basic SCADA telemetry. Stack needed: Multi-product forecaster; co-optimization engine (MIP/stochastic); sub-second dispatch telemetry; reconciled settlement layer. Delta: Step-change in build/buy commitment — not an incremental upgrade.
Hardware requirements Hardware: Identical — cells, inverter, BMS. Hardware: Identical — cells, inverter, BMS. Delta: Zero. The revenue differentiation is entirely in software.

None of this is exotic math. It is the standard mixed-integer programming and stochastic optimization that quantitative trading desks have run for decades, applied to a physical asset with duration, throughput, and cycle-life constraints. The challenge sits in the surrounding integration: price forecasting pipelines, real-time dispatch telemetry, market-award processing, and the discipline to let the optimizer actually drive the EMS rather than be overridden by rules-of-thumb from the operator’s trading desk.

Why Most BESS Projects Leave 30–50% of Revenue on the Table

If the markets allow stacking and the algorithms are well understood, why do so many projects underperform? Because each of the control-stack layers has a specific failure mode, and in most projects, several of them fire at once.

The most common is dispatch latency. ISO real-time markets clear on five-minute intervals; ancillary dispatch signals can require response in seconds. A BESS whose software stack takes 60 seconds to translate an award into a BMS command is structurally incapable of capturing the fastest-paying product. This is rarely a hardware limit (the inverter and BMS can respond in sub-second time frames) and almost always a middleware and integration issue.

The second is price forecasting quality. Bids against energy and ancillary products depend on forward price views. Operators using stale, low-resolution, or single-source forecasts systematically underbid against sophisticated counterparties. The gap between a good and a mediocre forecast is material: it translates directly into missed awards, forced curtailment, and suboptimal state-of-charge trajectories.

The third is co-optimization discipline. An operator who bids the same battery into energy and ancillary in a naïve way, without the joint optimization that accounts for the state-of-charge path across cleared awards, can win both and then be unable to deliver one of them, triggering performance penalties that wipe out the revenue gain.

The fourth is SOC management across market day. A battery discharged into the morning ramp because the energy-arbitrage model said so is no longer available to bid into the afternoon ancillary market when the reserve price spikes. Projects that optimize each hour in isolation, rather than across the market day, systematically concede the highest-paying hours.

The fifth, and most insidious, is settlement drift. When operational telemetry does not reconcile cleanly against ISO market awards, real revenue diverges from expected revenue. The variance is invisible without a disciplined settlement layer. When it surfaces in quarterly results, operators often attribute it to “market conditions” rather than to the settlement infrastructure that failed to catch it.

Each of these failure modes is a software problem. Each has a specific fix. Swapping cells addresses none of them.

The Bankability Case — What Lenders and IPPs Now Require

The shift has moved into project finance. For most of the post-FERC-841 era, BESS underwriting focused on cell warranties, EPC quality, and offtake contracts. In 2026, lenders have begun requiring explicit contractual coverage of the software layer, because they have watched projects with excellent hardware underperform against pro forma revenue assumptions and traced the variance to dispatch and settlement software.

The new underwriting asks fall into three categories. Operational SLAs specify minimum uptime for the dispatch stack, time-to-recovery guarantees for integration failures, and penalty structures for missed dispatch windows. Performance warranties increasingly extend beyond round-trip efficiency of the hardware to include software-layer commitments: forecast accuracy thresholds, settlement reconciliation tolerances, and market-award capture rates. Evidence requirements for quarterly draw-downs on project debt now frequently include exports of the settlement layer’s reconciliation records alongside the standard invoice package.

For developers, the implication is that software procurement now sits inside the financial close, alongside EPC and offtake diligence. For incumbent IPPs and utilities, platform decisions made two or three years ago may be re-examined against what lenders will actually accept on the next refinance. And for aggregators participating in wholesale markets under FERC Order 2222 frameworks, the bankability discussion has extended into the VPP and aggregator platform layer. The performance of the aggregator’s dispatch system is becoming a diligence item for the underlying asset owners whose batteries the aggregator is monetizing.

The broader lesson: BESS is transitioning from a project-finance asset class underwritten primarily on hardware warranties to one underwritten as a software-plus-hardware hybrid. The EU Battery Regulation and its Battery Passport mandate, explored in a companion piece, will tighten this further, because the Passport makes the software layer’s ability to produce audited lifecycle data into a compliance obligation embedded in every asset’s lifecycle.

Building or Buying a BESS Control Stack: A Decision Framework

Every operator serious about BESS economics in 2026 faces the same decision: how much of the control stack to build, how much to buy, how much to integrate from specialist vendors. The right answer is rarely “all build” and almost never “all buy.” It is almost always a deliberate mix, chosen layer by layer.

The key dimensions are ownership and differentiation (does this layer carry a strategic advantage?), integration depth (how tightly must it couple to the rest of the stack?), regulatory and protocol exposure (how fast does the landscape change?), and talent economics (can the team realistically hire and retain for this layer?). These dimensions produce different answers at each layer of the stack. BMS is a clear buy: it is hardware-specific, safety-critical, and regulated; a utility or IPP has no business building one. Market interface and protocol integration (ERCOT, CAISO, PJM, IEEE 2030.5 for utility BESS programs, SunSpec, OpenADR) is a high-value integrate. The accelerator model, where pre-built and pre-certified protocol components are owned by the operator and extended under their architecture, delivers the speed-to-market of a vendor purchase with the long-term flexibility of in-house ownership.

Control-stack layer Strategic differentiation Integration depth required Regulatory & protocol exposure Recommended posture
BMS Differentiation: None — safety and cell chemistry are commodity. Integration: Tight to pack; vendor-specific. Exposure: UL, IEC safety certifications. Posture: Buy from cell/pack vendor.
EMS Differentiation: Moderate — site architecture and supervisory logic. Integration: Bridges BMS, inverter, grid-tie. Exposure: IEEE 1547, grid-code-specific. Posture: Integrate — buy a validated core, extend under operator architecture.
Dispatch Optimizer Differentiation: High — revenue-per-MWh lives here. Integration: Reads from forecast and market layers; writes to EMS. Exposure: Evolves with market-rule changes (FERC 841, 2222, ECRS, capacity reforms). Posture: Build — this is the moat.
Market Interface / Protocol Differentiation: Low — the protocol is standardized. Integration: Deep — must hit every ISO/RTO and utility program in the portfolio. Exposure: High — IEEE 2030.5, SunSpec, OpenADR, OCPP, IEC 61850, Rule 21, CSIP-Australia. Posture: Integrate — pre-certified accelerators with full source code ownership; extend under operator architecture.
Settlement & Reporting Differentiation: Moderate — audit quality and lender-grade evidence trails. Integration: Reads telemetry and market awards; writes to finance and compliance systems. Exposure: ISO settlement file formats, EU Battery Passport data model. Posture: Build — vendor components only for regulated file formats.

The dispatch optimization engine is the layer most worth owning, for one simple reason: revenue differentiation lives there. Operators that outsource the optimizer to a third-party dispatch vendor, however capable the vendor, concede the part of the stack that most directly determines their revenue per megawatt-hour. They also concede the ability to steer the optimizer toward their specific portfolio strategy, risk tolerance, and co-product obligations (PPA deliveries, capacity commitments, behind-the-meter load support). For a utility running a program like PacifiCorp’s Wattsmart Battery Program on IEEE 2030.5, or for an aggregator building a European DSO signaling layer, the dispatch and optimization layer is the platform itself.

Settlement, telemetry, and compliance are best built as owned infrastructure with specialist vendor components for the regulated interfaces (ISO settlement file formats, Battery Passport data models) and with the operator owning the reconciliation logic and the audit trail.

From Cells to Markets — Why the Software Layer Is Codibly’s Specialty

The argument so far has been technology-first and market-first, deliberately. It lands in a specific place: the layer where BESS hardware meets market participation is engineering work. That means battery management system development, dispatch orchestration, protocol integration (IEEE 2030.5, SunSpec, OpenADR, IEC 61850, Modbus), and platform engineering for energy markets and trading. It is Codibly’s home ground.

Codibly sits at this intersection as the technical partner for utilities, IPPs, and aggregators that have decided the software layer is theirs to own. The engagement model is pragmatic: pre-certified protocol accelerators (IEEE 2030.5, OpenADR 2.0b, SunSpec, EnergyHub/Uplight integrations) that cut protocol-level build from twelve-plus months to six to eight weeks, paired with custom engineering on the dispatch, optimization, settlement, and capacity-market participation layers where the operator’s revenue differentiation actually lives. The accelerators ship with full source code ownership and perpetual license, which matches how lenders increasingly want the software layer documented: as owned infrastructure with a complete code trail.

In a recent engagement with a US IPP running roughly 1.8 GW of merchant BESS across ERCOT and CAISO, the work has been exactly what this paper describes: architecting the co-optimization engine, integrating ISO market interfaces, standing up the settlement reconciliation layer, and building out the telemetry and audit surface that the lenders required at the next refinance. Publicly, Codibly’s engagement with a California BESS provider delivered IEEE 2030.5 CSIP compliance under Rule 21 in eight weeks. With SolarEdge in Australia, the work was multi-DNSP IEEE 2030.5 CSIP-Australia integration: the same architectural pattern applied to a different grid code, making clear that the protocol-integration layer generalizes cleanly across jurisdictions when built correctly.

The through-line is consistent. In 2026, a BESS that can participate in wholesale markets, meet utility program requirements, and clear compliance audits is the product of deliberate engineering on the control stack. The cells are procured. The software is built.

Hardware Has Become Table Stakes. The Moat Moved.

The BESS industry in 2026 is in an odd position: the cost curve on hardware has delivered on a decade of promises, and the resulting abundance has exposed a truth that was always going to surface. Cheap cells produce cheap projects. Competitive projects come from deliberate software.

The gap will widen. FERC Order 2222 is moving aggregated DERs into wholesale markets across every US ISO; ERCOT will continue to be the world’s largest merchant BESS laboratory; CAISO and PJM will tighten their hybrid and capacity rules; the EU Battery Passport will turn compliance into a first-class software concern. Every one of these forces rewards operators whose control stack is built to last: operators who can integrate a new market product in weeks, plug into a new utility program on IEEE 2030.5 in a few sprints, and produce the audit surface that a lender, a regulator, or a sustainability officer now routinely asks for.

For technology leaders at utilities, IPPs, aggregators, and developers, the decision has narrowed to a single question: how deliberately to own the software layer. Operators who treated the control stack as a post-commissioning IT line item are the ones whose next refinance is going to ask uncomfortable questions. Operators who treated it as the core of the business are the ones whose next refinance is going to be routine.

Codibly’s view, reinforced every quarter by what we see on the ground from Texas to California to the UK and the Nordics, is that the moat has already moved. The next three years will make that visible to everyone else.