Battery passport data requirements

What data is required for a battery passport?

The legal starting point is Annex XIII of Regulation (EU) 2023/1542, read with Articles 77 and 78. Annex XIII covers public information about the battery model, other model information with restricted access, information for authorities and notified bodies, and data about an individual battery for persons with a legitimate interest. The exact field mapping depends on battery category and applicability. A simple spreadsheet headed “passport data” is a useful inventory, but it is not the regulation itself.

A workable project records each field’s definition, source, evidence, responsible owner, access category and update rule. This guide explains that method and illustrates important data families. It is not an exhaustive legal checklist.

Separate model information from individual-battery information

A model may have a defined chemistry, rated capacity or reference test. An individual unit has its own identity and may acquire status and use-related information over time. Mixing the two levels creates duplication and can make an update to one unit appear to change every battery of the model.

The introductory passport guide explains why these layers belong to one connected record, not necessarily one public screen.

Which Annex XIII groups need attention?

The public model section includes information from Annex VI Part A and entries concerning material composition, carbon footprint information, responsible sourcing, recycled and renewable content, technical performance, the EU declaration of conformity and waste-prevention information. Several entries refer to other provisions; their applicability must be checked there rather than assumed from the field name alone.

Other sections cover detailed composition and dismantling information for restricted audiences, test reports for specified bodies, and individual-battery information such as performance and durability values, state of health, status and use-related data. “Restricted” does not mean optional. “Public” does not mean an operator can publish unsupported claims. Read the current Annex XIII and Article 77 access provisions before designing the public view.

Build a field register that can survive a review

For each candidate field, record at least:

1. Legal reference and applicability: exact provision, battery category, condition and any unresolved interpretation.
2. Definition and unit: what the value means, its unit, test method or reference condition.
3. Data level: model, batch or individual battery, with a rule for versioning.
4. Source and evidence: source system, document ID, test report or supplier declaration, with revision.
5. Owner and approver: who supplies, checks and maintains the data internally.
6. Access and update rule: intended legal audience, edit rights and events requiring review.
7. Status: verified, pending, not applicable with reason, or needing specialist review.

This register prevents a blank field from quietly becoming an estimate. It also shows whether the problem is missing data, unclear definitions, unverified evidence or a system integration. The supply-chain overview addresses supplier requests.

A practical example: a changing specification

Suppose engineering changes a cell component while procurement continues to receive the previous supplier revision for some units. A single “current chemistry” field can obscure which model revision and which batteries are affected. A better register links the value to the approved model revision, source evidence and effective unit or production range. The passport presentation can then retrieve the correct information for a scanned unit.

This is an information-governance example, not a prescribed legal data model. It demonstrates why identifiers, revisions and evidence should be tested together.

How should access be mapped?

Annex XIII distinguishes publicly accessible model information from several restricted categories. Article 78 requires access and modification rights to be restricted according to the applicable access rules, and calls for authentication, integrity, security and privacy. Separate at least the ability to read, introduce, modify and approve information. A public visitor, an authorised operator and a regulator do not necessarily have the same view or permissions.

Avoid using a single “private” flag for every field. Document the applicable audience and the reason for that classification. Where implementing details affect legitimate-interest access, verify the adopted measures before finalising permissions.

Test the register with one battery

Take a representative unit and trace a small set of fields from scan or identifier back to evidence. Include one missing supplier value, one revised specification and one lifecycle change. Ask someone outside the data-entry team to find the source, determine which version applies and identify who can correct an error. A failure is valuable at pilot stage: it points to a process to fix before scale.

Then test export and migration using the same record. Article 77(5) and Article 78 make interoperability and continuity material questions, not merely procurement preferences. The software evaluation guide turns this into a vendor demonstration script, and the fictional example record shows a safe learning format.

Common mistakes

• Treating a list of Annex XIII headings as a verified database schema.
• Assigning every supplier-provided number to “public” without access review.
• Recording a value without unit, method, evidence or revision.
• Conflating a model specification with a measurement or event for one battery.
• Labelling a field “not applicable” without documenting why.
• Assuming a vendor’s template transfers responsibility for accuracy away from the operator.

Map legal obligations from the current consolidated text and any applicable adopted measures. Internal owners in a planning table do not replace the responsibilities assigned by the regulation.