EU Battery Passports Begin in 2027: What Document Architecture Is Needed?

A battery's QR code opens its passport. A repairer needs restricted dismantling information, while a purchaser sees public product data. Behind those views, the operator must connect each value to the correct battery, accepted source version, and responsible party.

Design three connected layers: the structured passport, its registry registration, and the governed evidence repository. From February 18, 2027, Article 77 of the EU Batteries Regulation requires passports for light means of transport (LMT) batteries, electric vehicle batteries, and industrial batteries above 2 kWh placed on the market or put into service. Assess the relevant finished battery and category before designing the record.

Separate the hosted passport from registration and evidence

The Commission describes a decentralised battery-passport system: the responsible operator maintains detailed information. The EU registry is a separate service. Registration does not move the complete passport or its supporting repository into a central public database.

1. 1 · Evidence

   Govern source records

   Keep accepted documents, source versions, responsible owners, and approval history.

2. 2 · Passport

   Publish structured views

   Expose applicable fields through the appropriate public or restricted access path.

3. 3 · Registry

   Manage registration

   Connect the battery identity and hosted passport to the required registry record.

The registry's user interface and API are covered by Implementing Regulation (EU) 2026/1778. Build a registration adapter with explicit submission states, responses, error handling, and reconciliation. A failed network response should leave a registration outcome to investigate, rather than silently marking the battery ready.

Keep battery identity distinct from document identity

Model the finished battery, battery model, economic operator, hosted passport, registry response, and supporting documents as related records. A document identifier is useful for retrieving evidence; it should not accidentally become the regulated battery identifier. Resolve the identifier standard and attribution process separately from repository storage.

Where a model-level report supports many individual batteries, keep the shared source relationship and the population it covers. A model revision should trigger an impact assessment; it should not overwrite evidence for every previously manufactured battery without review.

Apply the right fields at the right time

The Commission's data-point guidance, version 3.2 of October 19, 2026 (PDF) distinguishes category-specific and conditional fields from information not due at the February 2027 launch. It identifies carbon-footprint, recycled-content, and due-diligence entries that are not yet required then. Read this preparatory guidance alongside the applicable legislation and acts; it is not a substitute for them.

Turn the reviewed field list into an applicability matrix with a source, category, effective date, expected format, unit, owner, and validation rule. Distinguish “not applicable,” “not yet required,” “not yet generated,” and “missing required evidence.” Those states should drive different review and publication behaviour. Recheck the matrix when guidance or an underlying obligation changes.

Make access decisions at the field and document boundaries

Public passport information does not make every supporting file public. Publish a defined projection of approved fields, with separate authorisation for restricted data and source documents. Check access on APIs and downloads as well as on the visible page.

As reviewed on November 12, 2026, the Commission's battery-passport FAQ still describes the final restricted-data access act as pending. Keep legitimate-interest categories and permitted operations configurable. The FAQ also distinguishes operator-managed passport access from the registry's registration and metadata role; registry verification should not become a blanket entitlement to restricted evidence.

Work through a 6 kWh industrial battery

Suppose an operator is preparing a finished 6 kWh industrial battery for the EU market after the passport requirement applies. Its compliance team has confirmed the category and applicable fields. A manufacturing system identifies the individual battery, while an engineering repository supplies the accepted model documentation.

1. Bind the first publication

   Connect the battery and model identities to the accepted manufacturer information, relevant engineering records, and approved field set. Retain the exact source versions and validation results used for this publication.

2. Exercise each access path

   Scan the QR code as a public reader, then test an authorised restricted-data user. Confirm that public model information is visible while restricted dismantling evidence cannot be retrieved through a guessed repository URL.

3. Reconcile registration

   Submit the required registry information through the chosen integration and retain its response. Simulate a timeout, investigate the original submission, and demonstrate that the local readiness status reflects the reconciled result.

4. Correct an accepted value

   If engineering corrects a model designation or replaces a supporting report, identify the affected battery population. Review the change, publish the approved correction, and retain the relationship between the earlier and current publication.

Plan lifecycle handover and service continuity

Article 77 requires a new passport linked to its predecessor after specified reuse, repurposing, or remanufacturing operations. Article 78 also requires availability after the responsible operator ceases activity. Define handover and continuity arrangements with the parties that will operate them, including identities, domains, hosting, keys, and authorised updates.

Preserve predecessor relationships explicitly rather than copying a folder and treating it as a new identity. Test exports with structured fields, source references, classifications, and version history. The passport ceases to exist after recycling under Article 77; supporting-record retention is a separate assessment, so do not equate passport closure with deleting every source record or serving the public passport indefinitely.

Test the architecture before launch

• Confirm the finished battery, applicable category, responsible operator, and field applicability dates.
• Keep battery identifiers, document identifiers, and registry responses distinct but linked.
• Trace a published field to an approved source version and responsible owner.
• Test field, API, and source-document permissions for every intended audience.
• Reconcile a registration timeout and a corrected publication without losing history.
• Exercise a lifecycle handover, continuity export, and appropriate passport closure.

Build a controlled relationship between identity, data, and evidence

A working passport connects the right battery to current, appropriately accessible information and its supporting evidence. Separate publication, registration, and document governance so each can be validated and maintained as requirements and lifecycle responsibilities change.

Regulatory sources reviewed: November 12, 2026, including the August 13 consolidated regulation, October 19 data-point guidance, and current Commission FAQ. Validate subsequent acts, standards, and category-specific requirements before launch.