Why warranty disputes are won or lost in SCADA data

A utility BESS warranty typically guarantees the lower of two limits — capacity retention (e.g. ≥70% SoH at 10 years) and energy throughput (a cap in MWh or equivalent full cycles) — whichever is reached first. Around those sit operating-window conditions: an SoC window (often 10–95%), a temperature window (often 0–35 °C cell), cycles-per-day and C-rate limits. Violate a condition and the OEM can decline a claim.

When a pack degrades faster than expected, both sides reach for the data. The operator wants to show the degradation is anomalous and the asset was run within spec. The OEM wants to find a window violation that explains the fade as the operator’s fault. The argument is won by whoever can produce the cleaner, more complete record — not by whoever has the better physics.

A defensible claim package usually needs: SoH versus the contracted curve, cell-level voltage histograms, the last 90 days of temperature and SoC traces, and the relevant BMS fault events. Reconstructing that after a dispute starts is hard and looks weak. Capturing it continuously makes the claim self-evident.

• Annualised SoH degradation exceeds 2× the contracted curve over a rolling 90-day window.
• A single capacity test shows a >5 percentage-point drop versus the previous test.
• More than ~2% of cells in a string show >50 mV voltage deviation at 50% SoC.

Continuous instrumentation can also reveal that your own dispatch caused the degradation: high-SoC overnight dwell on an NMC asset, or C-rate exceedances during peak hours. That is not a reason to avoid the data — it is the reason to see it first, so you can correct dispatch before it becomes the OEM’s defence and before the warranty headroom is gone.