Battery warranty disputes are expensive and slow. They're also usually avoidable — not because operators avoid the underlying degradation events, but because most operators don't have the documentation they would need to prevail in a dispute when one occurs. IEC 62619 Section 8.3 defines what that documentation looks like. Most BESS sites aren't collecting it.
This is a field guide to what IEC 62619 warranty documentation actually requires, where most operations teams fall short, and what a compliant evidence package looks like in practice. We've worked through enough post-incident documentation exercises to know that the typical gap isn't technical — it's procedural. The data often exists. Getting it into the right format and retaining it for the right duration is where things break down.
What IEC 62619 Section 8.3 Actually Requires
IEC 62619 is the safety standard for secondary lithium cells and batteries used in stationary applications. Section 8.3 addresses operational record-keeping requirements. The standard specifies that operators must maintain records demonstrating that the battery was operated within the manufacturer's specified conditions throughout the warranty period. Those conditions typically include:
- Voltage limits: minimum and maximum cell and pack voltage during both charging and discharging
- Current limits: maximum charge and discharge current (absolute and relative to rated C-rate)
- Temperature limits: operating temperature range at the cell or module level during cycling, and storage temperature during standby periods
- SoC operating range: depth of discharge and maximum SoC for normal operation
- Charge protocol compliance: evidence that fast charge protocols, if used, were applied only under the conditions specified in the manufacturer's application note
The standard does not mandate a specific data format or storage system. What it requires is that the records are retrievable, verifiable, and cover the entire warranty period at sufficient granularity to demonstrate compliance with each parameter. That last point — sufficient granularity — is where most operators fail.
The Granularity Gap
Many BESS sites log operational data at the pack or string level, aggregating cell-level readings before storage. Pack-level voltage is a series sum; pack-level temperature is typically an average or a single sensor value for a multi-module rack. When a cell failure occurs and the manufacturer's warranty team asks for evidence that cells were not operated outside voltage limits, pack-level logs cannot answer that question. The answer requires per-cell voltage logs.
A manufacturer's warranty team reviewing a claim will ask for the peak voltage and minimum voltage recorded at each cell during the period in question. If your historian stores only pack terminal voltage, you cannot produce this. The warranty claim fails — not because your cells were operated outside limits, but because you cannot demonstrate that they weren't.
In our experience reviewing warranty disputes, the documentation failure almost always predates the cell failure event by months or years. The moment you commission a BESS, you need to be logging at the cell level and retaining those logs for the full warranty period. Walking back to implement this after a cell event has already occurred is too late.
What a Compliant Evidence Package Contains
A well-structured IEC 62619-compliant warranty evidence package for a specific cell event should contain:
| Evidence Element | Granularity Required | Retention Period |
|---|---|---|
| Cell voltage time series | Per cell, ≤60 sec intervals | Full warranty period + 12 months |
| Cell temperature time series | Per module or per cell, ≤60 sec intervals | Full warranty period + 12 months |
| Current time series | Per string, ≤60 sec intervals | Full warranty period + 12 months |
| BMS alarm and event log | All triggered alarms with timestamp, cell/module ID, and parameter value | Full warranty period + 12 months |
| Capacity test records | Per rack or string, with test protocol noted | Full warranty period + 12 months |
| Maintenance action log | Date, technician ID, action taken, cells/modules affected | Full warranty period + 12 months |
| Charge protocol records | Evidence that fast-charge events (if any) complied with manufacturer specs | Full warranty period + 12 months |
The 12-month buffer beyond the warranty period matters because warranty disputes often surface months after the warranty technically expires. Manufacturers will contest a claim filed in month 11 based on an event they assert occurred outside warranty scope; having clean records extending past the formal warranty end date removes that line of argument.
The Tamper-Evident Requirement
IEC 62619-compliant records must be demonstrably tamper-evident. This means the data storage and retrieval system must be able to show that records were not modified after the fact. This is a requirement that catches many operators off-guard — standard CSV exports from a SCADA historian do not, by themselves, satisfy tamper-evidence requirements. A CSV file can be edited after export with no audit trail.
Tamper-evident options include:
- Cryptographic hashing of exported records at the time of export, with hash values stored separately (e.g., on a write-once storage medium or in a third-party logging service)
- Immutable time-series databases with write-locked historical partitions (some industrial historians support this natively)
- Third-party data custody services that accept telemetry streams and provide certified audit logs
- Blockchain-anchored record attestation (increasingly available through specialized industrial IoT platforms)
For most BESS operators, the practical approach is a combination of: retaining the original historian data in write-locked form, generating and retaining cryptographic hashes of records at regular intervals, and documenting the chain of custody for any data exports used in warranty claims. This doesn't require specialized infrastructure beyond what a careful IT policy can establish.
Common Documentation Failures in Warranty Claims
Based on the pattern of warranty disputes we've seen documented in industry proceedings, the failures cluster into four categories:
- Missing cell-level resolution. Pack-level data was retained; cell-level data was not logged or was overwritten on a rolling buffer without long-term archival.
- Gap periods in the record. Communication failures between the BMS and historian created data gaps — sometimes hours, sometimes days — during exactly the periods the manufacturer's team is most interested in examining.
- Inconsistent timestamps. BMS and SCADA clocks were not synchronized, creating timestamp discrepancies that make it impossible to correlate events across systems. A 5-minute clock drift across three systems creates a reconstructed timeline that looks doctored even when it isn't.
- No formal SoC operating range enforcement documentation. The BMS was programmed with operating limits, but no record was retained showing what those limits were and that they matched the manufacturer's specifications at the time of commissioning — and at every subsequent firmware update.
Each of these failures is procedural, not technical. The fixes are: configure the historian to retain cell-level data for the full warranty period, implement a watchdog process that alerts on data gaps longer than a defined threshold, synchronize all system clocks to a common NTP source, and document BMS parameter configurations at commissioning and after every change.
Preparing Before an Event, Not After
The right time to build your warranty documentation infrastructure is during commissioning. By the time a cell event has occurred, you are in reactive mode — trying to reconstruct a record that should have been building automatically since day one.
A commissioning-time documentation checklist should include:
- Confirm historian is configured to retain cell-level voltage, temperature, and current at ≤60-second resolution for the full warranty period duration
- Confirm historian storage capacity is sufficient for this retention period and that no rolling overwrite policy will delete old data
- Document all BMS operating limits (voltage, current, temperature, SoC range) and sign off that these match manufacturer specifications
- Establish NTP synchronization across BMS, inverter, SCADA, and historian clocks with monitoring for clock drift
- Run an initial full capacity test and retain the results as the commissioning baseline
- Establish a data export and cryptographic hashing schedule for archival of historical records
None of this is technically complex. It's largely a configuration and process discipline exercise. But it needs to be done at commissioning, not retrofitted two years in when the first warranty claim is being assembled under time pressure.
IEC 62619 warranty documentation is not a legal formality — it's the operational backbone of asset protection for a storage project. The manufacturers who sold you the cells know exactly what records you'll need in a dispute. The ones who arrive unprepared to that dispute almost never win it.
