Battery Passport 2027: Checklist for the 18 February Deadline

18 February 2027 is a concrete date for many battery manufacturers, importers and other responsible economic operators. From that date, Article 77 of the EU Battery Regulation requires an electronic record for certain battery categories: the battery passport.

The battery passport is the first concretely dated expression of the Digital Product Passport. At first glance the deadline looks like an IT date. In reality, product identity, model data, individual information, evidence, access levels and responsibilities all have to be brought together beforehand. Starting with the QR code means starting at the wrong end.

Which batteries are in scope?

Article 77(1) of Regulation (EU) 2023/1542 names three groups:

• LMT batteries, meaning batteries for light means of transport,
• industrial batteries with a capacity greater than 2 kWh,
• electric vehicle batteries.

What decides is the specific product context. A technical DPP platform can support the classification, but it does not replace the assessment of the battery and of the company’s role.

What does the battery passport contain?

The regulation links information about the battery model with information specific to the individual battery. Annex XIII structures information groups and access levels. That produces a model which avoids duplicating general master data per battery, while still attaching individual states to the right object.

In practice the information falls into several areas:

Data area	Examples for project planning
Identity	Battery identifier, model reference, responsible economic operator
Properties	Capacity, composition and product-related technical information
Sustainability	Relevant declarations, values and evidence per applicable context
Circularity	Information on disassembly, replacement, treatment and recovery
Lifecycle	Individual events or condition information, where foreseen
Governance	Access role, source, release, version and update status

The full technical mapping should be done directly against Article 77, Annex XIII and further applicable rules. Rigid blog checklists are no substitute.

Model data and individual battery data

The separation reduces duplicated maintenance. At the same time, a change to the model must not silently alter already published individual passports. The data model therefore needs versions and clear validity relationships.

An example: updated technical documentation may apply to a model version. An individual condition value belongs to one specific battery. Both can appear in the same passport view, but internally they have to be managed differently.

Battery passport checklist for February 2027

Phase 1: scope and responsibility

At the start it has to be clear which products, sites and economic operators are in the project. Every relevant data field also needs a technical owner. Without that ownership, a technically visible field may simply go unchecked.

Phase 2: data inventory

Model data may sit in PLM, production data in ERP, condition data in the BMS and evidence in document stores. The inventory should capture not just system names but also quality, currency, identifiers and available interfaces.

Phase 3: rule and gap assessment

Requirements are applied to the specific battery context. The assessment has to distinguish mandatory, conditional, future-dated and non-applicable. A percentage alone is not enough; users need to understand which gap exists and why.

Phase 4: pilot and publication

A meaningful pilot does not just render one attractive sample battery. It runs through import, mapping, checking, evidence, release, scan and later update. Only then does it show whether the process works in day-to-day operation.

QR code and access levels

The battery passport is made accessible through a QR code. Behind the scan, the correct individual battery has to be identified. At the same time, the foreseen information access differs by actor. Public content should therefore be reachable without unnecessary friction, while protected areas use dependable authorisation.

At minimum, test:

• scannability on the real product or intended application point
• durable resolution of the identifier
• a language-appropriate, mobile passport view
• access with and without authorisation
• behaviour for blocked, replaced or updated records
• traceability of the published version

The most common project risks

Starting too late: data clarification and supplier communication usually take longer than the front end. Unclear identity: model and individual information get mixed up. Blanket completeness: a dashboard shows “done” although sources or evidence are missing. No exit strategy: the QR codes only work as long as one single provider stays unchanged – an independent DPP backup limits that risk. Manual one-off maintenance: updates and new batteries cannot be processed economically.

Conclusion

Battery Passport 2027 is a concrete reason to build DPP capability productively. The biggest lever is not a quickly generated QR code but clean identity, structured data, a versioned rule set and controlled operation. A platform that masters these fundamentals can absorb further product groups afterwards.