EU Batteries Regulation Battery Passport Data Model Template

Start the schema with a scope table before adding Annex XIII fields. Article 77 covers LMT batteries, industrial batteries above 2 kWh, and electric vehicle batteries. Other battery categories may still need labels, QR-code information, conformity records, due-diligence information, or waste instructions under other provisions, but Article 77 does not make every battery a passport record.

Each covered battery needs a passport reachable through the Article 13(6) QR code. The QR code must link to the unique identifier attributed by the economic operator placing the battery on the market, so the identifier table should be the stable join between product master data, QR artwork, passport endpoints, service systems, and second-life or recycling records.

Annex XIII point 1 is the public model-data block. Build it as a governed battery-model table because those fields describe the battery model, not live telemetry from one physical battery. The table should include the value shown in the passport, the unit or controlled vocabulary, and the evidence artifact that proves it.

A useful public table has one row per field category and one source-of-truth owner. Do not publish a flat list of unverified values: attach the legal basis, the source system, the evidence reference, the validation rule, and the event that forces recalculation or republication.

Do not put every passport field behind the same public endpoint. Annex XIII point 1 is public. Under Article 77(2), point 2 model data is accessible to notified bodies, market surveillance authorities, the Commission, and persons with a legitimate interest. Annex XIII point 3 test-report results are for notified bodies, market surveillance authorities, and the Commission. Annex XIII point 4 individual-battery data is for persons with a legitimate interest.

Model the access rule as metadata on each field group. Article 77(9) leaves further detail to an implementing act on which legitimate-interest persons get access and to what extent they may download, share, publish, or re-use the information. Keep the matrix versioned, record the act and effective version used, and do not hard-code broader rights than the applicable source supports.

The passport data model should be API-ready from the start. Article 77 requires open standards, an interoperable format, transfer through an open interoperable data exchange network without vendor lock-in, and data that is machine-readable, structured, and searchable.

Article 78 adds operational requirements: free access based on access rights, storage by the responsible operator or authorised processor, availability if the responsible operator ceases activity in the Union, restricted write and update rights, authentication, reliability, integrity, security, privacy, and fraud prevention.

Use the evidence register as the implementation spine for the passport build. Each row should be testable by product compliance, engineering, sustainability, supply chain, service, and IT before any QR code is released.

The register is intentionally field-level: it should show what value appears in the passport, where it came from, who can access it, who can update it, and what event forces a review or republication.