A battery passport is more than a QR code on a product. It is an electronic record that connects the battery model, individual or pack identification, life-cycle data and access permissions to maintainable sources. This page maps the preparation work; it does not replace a product-specific assessment of scope or applicability.
1. Define the battery object first
Create a battery-object register covering category, model, capacity, chemistry, manufacturer, production site, batch or serial identifier, and the product or vehicle in which the battery is installed. Model-level data and individual-battery data should not be mixed. Record changes to materials, processes, sites or key parameters in a version history.
Set the responsibility boundary at the same time: identify the economic operator placing the battery on the market, the data maintainer, and the parties supplying manufacturing, use, repair, repurposing or recycling information. Keep the responsible party, data owner, source file and update date together instead of retaining only a final QR code.
2. Break the fields into evidence packages
Use Annex XIII of the Batteries Regulation to structure a field matrix. A practical starting point is five groups: battery identification and manufacturing; materials, composition and components; carbon footprint and calculation boundary; use, performance and durability; and information needed for dismantling, remanufacturing, repurposing and recycling. For each field, record the unit, measurement basis, life-cycle stage and source location.
A test report, carbon-footprint file or supplier statement is not by itself a complete passport. Each is only one source for relevant fields. The evidence package should also show the battery model, production site, version, period and method covered, with links to the BOM, energy records, production batch or maintenance record where relevant.
3. Build a source and version chain
Maintain a five-column register: field, source, owner, version and review date. Manufacturing data should connect to production and quality records; material data to the BOM and supplier declarations; carbon-footprint data to the system boundary, activity data and calculation file; and use-stage data to battery-management or after-sales records.
For supplier-provided fields, retain the original file, scope and permitted use. For estimated, unavailable or not-applicable fields, record the reasoning instead of silently inserting a default. Reassess affected fields after a material, factory, software or specification change.
4. Design the QR code and access permissions
Article 77 requires the passport to be accessible through a QR code linked to a unique identifier. The QR code is an access point, not the data itself. Document the identifier rule, the relationship between the QR code and the model or individual battery, version changes, availability checks and deactivation handling.
Annex XIII distinguishes public information, information available only to persons with a legitimate interest, and information for the Commission. Design permissions by role, field and purpose, and retain access logs and restrictions for data processors. Do not place every field needed by suppliers, repairers and recyclers on one undifferentiated public page.
5. Perform a human field review before release
Check the passport against the product label, technical file, declaration of conformity, carbon-footprint file and production batch. Select one model and trace its unique identifier back to the source documents, checking units, dates, versions and access rights. Mark unsupported fields as pending evidence rather than presenting them as established facts.
Primary source: Regulation (EU) 2023/1542, Article 77 and Annex XIII. Regulations, annexes and implementing measures may change; formal work should use the applicable official EU text and product facts at the relevant time.
