Grid Scale Battery Storage Software: Bidding a Nine Figure Asset Without Burning the Warranty

Why a battery owner ends up between the market and the warranty

A 200 megawatt hour project has three parties with three different clocks. The market wants an offer curve for tomorrow, submitted by a deadline, that treats the asset as an economic object. The warranty provider treats the same asset as a chemistry object with an annual throughput allowance, a temperature envelope and a depth of discharge profile, and it will read the operating data before it honours a capacity payment or an augmentation claim. The offtaker treats it as a contractual object with availability obligations and penalty language. Nothing in the control room reconciles the three, so the asset manager does it in a spreadsheet on Thursday afternoons.

The stack is usually the integrator's energy management system for real time control, the battery management system exposing cell and rack telemetry in its own schema, a power conversion system from a different vendor with its own limits, a market interface or a third party bidder, and a workbook where somebody tracks cycles against the annual allowance. Each piece works. What is missing is a single record where a bid decision knows the remaining throughput budget for the year, and where a throughput claim can be traced back to the dispatch instructions that consumed it.

The cost of that gap is concentrated and late. You do not notice a throughput overrun in March. You notice it in November when the annual figure is close to the allowance and the remaining months of the year have to be bid conservatively, giving up the highest value hours of the winter. Or you notice it two years later when a capacity fade claim gets questioned and the evidence you can produce is a workbook with no link to the underlying operating data.

Problem 1: the bid does not know what the warranty already spent

Bidding a battery is a state-dependent problem. The value of discharging at 6pm depends on what you did at 2pm, what you expect at 8am tomorrow, and how much of your annual energy throughput you have already used. Most bidding workflows in practice handle the first two and ignore the third, because the third lives in a different system owned by a different person.

Tesla Autobidder and Fluence Mosaic are serious optimisation products and they will produce better offer curves than a spreadsheet. The practical issue for an independent owner is that the constraint set that matters most to you, the specific throughput and depth of discharge language in your warranty and the specific availability definition in your offtake, is not a first class input you control. Wartsila GEMS and Powin StackOS are strong controls layers, but they arrive with the hardware, which means a portfolio built with two integrators ends up with two operating systems and no common view. Stem Athena runs as a managed optimisation service, which suits owners who want the decision outsourced and frustrates owners who want the logic and the data to be theirs.

A custom build makes the warranty a hard constraint inside the bid workspace rather than a report beside it. Remaining annual throughput, remaining cycle budget, depth of discharge distribution and temperature exposure are live numbers, and the offer curve is generated against them. When the model wants to bid an aggressive four hour discharge in August, it can price the opportunity cost of the throughput it consumes against the expected value of the winter hours it forfeits. That is the calculation the spreadsheet cannot do and it is where the money is.

Problem 2: your telemetry comes from three vendors who disagree

The battery management system reports state of charge its own way. The power conversion system reports power at a different point of measurement with a different sign convention and a different sampling rate. The revenue meter reports what the market will actually settle. Add a site controller and a SCADA historian and you have five sources that will not agree on how much energy moved through the asset in a given hour.

This is not a rounding problem. Warranty throughput is usually defined at a specific point of measurement, and if you have been tracking a different one, your entire annual figure is wrong in a direction you will discover during a claim. Meanwhile availability under the offtake is defined against yet another basis, typically tested capacity under specified conditions, which nobody is computing continuously.

A custom build establishes one canonical energy accounting model per site, defines each metric at the point of measurement its contract specifies, and reconciles the sources continuously with the differences visible rather than smoothed away. When the battery management system and the revenue meter diverge beyond a tolerance, that is an alarm, not a data cleaning step. Owners who do this find instrument and configuration faults that were quietly distorting performance numbers for months.

Problem 3: proving the claim years later

Capacity fade is normal and contracted for. The argument is never about whether the battery degraded, it is about whether it degraded faster than the guarantee because of chemistry or because of how you operated it. The provider will ask for operating data covering the period in question. If your answer is an export from a historian that has been resampled, gap-filled and partially retained, you are negotiating from a weak position on a claim worth millions.

The same applies to augmentation. Deciding when to add capacity, and proving to a lender or an investment committee that the timing is justified, requires a degradation record that ties measured capacity tests to the operating history that produced them. Vendor platforms will show a degradation curve. Very few will let you reconstruct exactly which operating decisions produced it, and none of them will still be your platform if you change integrators.

A custom build treats the operating record as evidence from the start. Raw telemetry retention is a deliberate policy decision rather than a historian default, capacity test results are structured records linked to the conditions under which they were run, and the throughput ledger is append only so the numbers presented in a claim can be walked back to source. This is unglamorous engineering and it is the part that pays for itself in a single dispute.

What a custom BESS build has to include

• A canonical energy accounting model per site, with each contractual metric defined at its own point of measurement and reconciled across the battery management system, power conversion system and revenue meter.
• A live constraint engine holding state of charge floors and ceilings, annual and lifetime throughput budgets, depth of discharge limits and temperature envelopes drawn from the actual warranty text.
• A bid preparation workspace that produces offer curves against those constraints and prices the opportunity cost of throughput consumed today against expected value later in the contract year.
• An append only throughput and cycle ledger built for evidence, with retention policy set by claim requirements rather than storage cost.
• Capacity test records as structured objects linked to operating conditions, feeding a degradation and augmentation plan.
• Offtake settlement checking, so availability and delivered energy under the contract are computed independently rather than accepted from the counterparty statement.
• Portfolio views that work across sites built by different integrators, which is the whole reason an owner builds rather than accepting the integrator's tool.

What it costs and how long it takes

From the storage and generation work Digital Heroes has delivered, the pattern is consistent. A first release covering telemetry reconciliation, the warranty constraint model and a bid workspace with a defensible throughput ledger runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding automated offer submission, degradation and augmentation planning, offtake settlement checking and portfolio reporting across sites runs $200,000 to $500,000 phased over 8 to 14 months.

Cost drivers specific to storage: the number of distinct hardware combinations in the portfolio, because a second integrator means a second telemetry schema and a second set of control interfaces. Direct market participation, since automated offer submission carries certification and failure handling obligations that a decision support tool does not. Co-located solar or wind, because shared point of interconnection constraints change the optimisation from a battery problem into a hybrid plant problem. And the state of your historian, because projects where telemetry was never architected start with a data archaeology phase nobody budgeted for.

What keeps the cost down: starting with the constraint engine and the ledger before the optimiser. Owners consistently overvalue the bidding algorithm and undervalue knowing, accurately and daily, how much of the year's throughput has been spent. The second thing is worth more and costs less.

Build versus buy, and when buying is right

Buy, or rather use what came with the project, if you own one site under a tolling agreement where the offtaker directs dispatch. Your job is availability and the integrator's system plus a monthly report is proportionate. Buy if you are merchant on a single asset and genuinely happy to run it as a managed service, because Stem or a similar arrangement removes a real staffing problem and the fee is knowable.

Build when two or more of these are true. You own three or more sites and at least two integrators, so no vendor tool covers the portfolio. You are merchant or partly merchant and your revenue depends on your own bidding judgement. Your warranty throughput tracking lives in a workbook and you cannot state today's remaining annual budget without opening it. You are approaching an augmentation decision and need a degradation record that survives investment committee scrutiny. Or you are planning to change integrator on the next project and refuse to inherit a third operating system.

The threshold is ownership of the decision. If someone else decides when your battery charges and discharges, buy. If you decide, and the decision is constrained by contracts that no vendor product reads, build the thing that reads them.

How to choose a developer for battery storage software

Ask them where they would measure throughput and why. The right answer is a question back: what does your warranty specify, alternating current or direct current side, and at which meter. A developer who answers immediately without asking has not read a warranty and is about to build you a number you cannot use.

Ask how they would handle disagreement between the battery management system and the revenue meter. You want to hear that the difference is surfaced and alarmed, not reconciled silently. Silent reconciliation is how instrument faults survive for a year.

Ask what they have integrated. Battery management systems, power conversion systems, site controllers and market interfaces are four separate engineering problems and the vendor names matter. A firm that has done two of the four will say so, and that is a better sign than a firm that claims all of them without naming one.

Ask who owns the code, the cloud accounts and the historian, in writing before kickoff. In storage this matters because the operating record is evidence in a future claim, and evidence you cannot access on your own terms is not evidence. At Digital Heroes the client owns the repository and the infrastructure from the first commit. Start by asking your asset manager for the remaining annual throughput budget on every site as of today. If that takes more than a minute to answer, you already know what to scope first.