Battery Passport Data Model: Model, Batch and Individual Battery Data

The architecture in one sentence

A compliant battery passport data model should separate model facts, batch context and the individual battery record. Model data can be reused across identical units. Batch data can connect a production run to its units. Individual data needs its own persistent identity because performance, state of health and usage history belong to one physical battery.

This is the architecture that makes battery traceability scalable without losing the “digital serial-number” function of the passport.

The legal foundation is Regulation (EU) 2023/1542. Article 77(2) requires each in-scope battery passport to contain information about the battery model and information specific to the individual battery, including information resulting from use. Annex XIII defines the required data layers. The EU Digital Product Passport Registry then supplies the common infrastructure for identifier registration and model, batch and item relationships.

The result is not three unrelated passports. It is one passport record with linked levels of granularity.

Start with the legal layers, not your ERP tables

Annex XIII does not begin with a generic “product master” or a database schema. It divides information by subject and access level:

This gives the implementation team two design constraints:

1. not every field is public; and
2. not every field is static.

The model must therefore support both data inheritance and controlled, time-stamped updates.

Model data: the reusable technical baseline

Model data describes the battery version whose units share the same relevant technical characteristics and model identifier. That is the meaning of “battery model” in Article 3(19) of the Batteries Regulation.

For public access, Annex XIII point 1 lists a substantial set of model fields, including:

• the information from Annex VI Part A, such as manufacturer, category, manufacturing place and date information, weight, capacity, chemistry, hazardous substances, extinguishing agent and critical raw materials;
• material composition, chemistry and critical raw materials;
• carbon-footprint information;
• responsible-sourcing information;
• recycled and renewable content;
• rated capacity, minimum, nominal and maximum voltage;
• original power capability and limits;
• expected lifetime and reference test;
• capacity threshold for exhaustion for EV batteries;
• temperature range when not in use;
• calendar-life warranty period;
• initial and cycle-life energy efficiency;
• internal cell and pack resistance; and
• the relevant c-rate.

These fields are candidates for a model object in the data system. A unit can reference the model object rather than duplicating the same values in every record. That reduces inconsistent edits and makes a model revision visible.

Do not use model inheritance to hide unit-level differences. If a field can vary by battery, manufacturing event or lifecycle event, it needs an explicit rule for whether it is inherited, overridden or recorded at the individual level.

Batch data: useful middle context, but do not misstate the law

Batch is the layer between model and item. It can capture manufacturing-run context such as:

• production date range;
• manufacturing plant or line;
• cell or module supplier lot references;
• quality release and inspection results;
• material or process changes;
• carbon-footprint calculation context where the relevant declaration is model per plant; and
• a set of individual battery identifiers produced together.

Batch data is valuable for investigations, recalls, supplier traceability and efficient data loading. It is also part of the common DPP Registry architecture. Commission Implementing Regulation (EU) 2026/1778, Article 8, requires the Registry to support the level specified by applicable Union law, namely model, batch or item. Where a passport is created at item level, the corresponding batch and model identifiers must be linked when those designs exist. Where it is created at batch level, the model identifier must be linked when a model exists.

The legal caution is important: Annex XIII of the Batteries Regulation expressly describes model-level and individual-battery information. It does not create a separate universal “batch data section” with a complete list of mandatory fields. Treat batch as a relationship and operational grouping unless a battery-specific act, data specification or other applicable Union rule requires a batch-level field.

In other words, batch is an important implementation layer, but it must not be presented as a third Annex XIII category with invented mandatory content.

Item data: the battery's identity and lifecycle record

The individual battery record is the part that answers “which physical battery is this?” Article 77(3) requires the passport to be accessible through a QR code linked to a unique identifier attributed to the battery. Article 3(66) defines that unique identifier as a unique character string identifying batteries and enabling a web link to the passport.

Annex XIII point 4 requires individual-battery information including:

The unique identifier should be persistent. An update to state of health should update the individual passport record, not create a new identity for the same unchanged battery. A new identity is required when the law requires a new passport after preparation for reuse, preparation for repurposing, repurposing or remanufacturing. In that case, the new passport links back to the original passport or passports under Article 77(7).

A practical model-to-item relationship

A useful logical structure is:

Manufacturer
  -> Manufacturing plant
      -> Battery model
          -> Production batch
              -> Individual battery item
                  -> Lifecycle events
                  -> Access-controlled passport views

The physical and digital identity path is:

Individual battery item
  -> unique battery identifier
  -> QR data carrier
  -> battery passport endpoint
  -> model, batch relationship and item data

The batch is not a replacement for the item identity. It is a grouping that makes the item record easier to operate. If the same model is produced in two plants, the model-level data may need plant-specific context. This is especially relevant to carbon footprint declarations: Article 7(1) requires a carbon-footprint declaration for each battery model per manufacturing plant.

Identifier design: distinguish three things

Teams often use “the identifier” to mean several different values. Separate them explicitly:

The QR code is a data carrier, not a fourth business object. It encodes or resolves to the identifier and the passport access route. The Commission Registry's registration identifier should not be silently substituted for the battery's identifier without checking the applicable technical requirements.

The ESPR also requires a persistent unique product identifier connected through a data carrier and refers to ISO/IEC 15459 standards. The Batteries Regulation specifically requires the QR code and unique identifier to comply with the ISO/IEC 15459-1 through 15459-6 standards or equivalent standards.

Access architecture: one record, different views

A battery passport should not be implemented as one unrestricted JSON response. Article 77(2) and Annex XIII create access tiers, while Article 78 requires access to be free of charge and based on the relevant rights.

The product team should define at least these views:

1. Public model view: the information in Annex XIII point 1.
2. Legitimate-interest model view: the detailed composition, parts, dismantling and safety information in point 2.
3. Authority view: test reports and other information reserved for notified bodies, market-surveillance authorities and the Commission.
4. Legitimate-interest individual view: state of health, status and usage-related data in point 4.
5. Operator edit view: authenticated users who are allowed to introduce, modify or update data.

The Commission's implementing act under Article 77(9) must specify which people have a legitimate interest and how far they may download, share, publish and reuse the relevant data. As of 13 August 2026, the underlying access categories are in the Regulation, but detailed permissions should be verified against the final implementing act before launch.

Commercially sensitive data should be minimized for each role. A recycler may need dismantling instructions and composition data without needing every internal business field. An energy-market participant may need individual battery information relevant to using that battery in an energy market context. Role-based access is part of the data model, not an afterthought added to the website.

Dynamic data requires event history, not overwrite-only fields

For lifecycle data, a single “current state” column is not enough. Keep both the current value and an auditable event history.

A practical event structure can include:

The Regulation requires accuracy, completeness and currency under Article 77(4), data authentication and integrity under Article 78(g), and restricted update rights under Article 78(f). These requirements favor versioned records, source provenance and controlled workflows.

Registry architecture: central index, decentralized detailed data

The EU DPP system is hybrid. ESPR Article 13 establishes a central Registry for unique identifiers and specified registration data. The detailed passport data is stored by the responsible economic operator or an authorized service provider under Article 78(c) of the Batteries Regulation and the ESPR framework.

The Commission Implementing Regulation 2026/1778 makes this operational. The Registry validates the data structure and required granularity, stores relevant identifiers and metadata, and creates a unique persistent registration identifier after successful validation. The full battery data remains available through the operator's passport endpoint or authorized provider.

For system architecture, this means:

• the Registry is not your entire battery database;
• your platform must provide a stable, resolvable passport endpoint;
• identifier uniqueness needs governance outside a QR-image generator;
• Registry registration status and passport data version must be tracked separately; and
• the passport must remain available even if the original operator ceases activity.

The DPP Registry was launched with a testing environment on 20 July 2026. Registration is available through a secure user interface or API. Build your integration so that Registry validation, retries, versioning and proof of registration are observable operational states.

Data-quality controls before publication

Use these controls for each layer:

Model controls

• Validate model identifier uniqueness within the manufacturer's namespace.
• Require a controlled chemistry vocabulary.
• Keep manufacturing-plant context where carbon-footprint rules require model-per-plant declarations.
• Version model data instead of silently changing historical values.
• Distinguish mandatory fields from voluntary additions.

Batch controls

• Require an immutable batch identifier once units are released.
• Link every unit to one or more production contexts with clear business rules.
• Preserve supplier lot references without exposing commercially sensitive information to the wrong role.
• Use batch relationships for recall and investigation workflows.
• Do not infer a unit's state of health from a batch average unless the field is explicitly a batch-level value.

Individual controls

• Generate a persistent unique identifier before the physical QR carrier is printed.
• Ensure one identifier resolves to one intended battery record.
• Validate the identifier and QR destination against the final product serial or manufacturing record.
• Store timestamped source and measurement context for dynamic fields.
• Prevent unauthorized edits while allowing the roles required by Article 78.
• Test reuse, repurposing, remanufacturing and recycling transitions.

What is binding, and what is implementation guidance?

Binding now

• Article 77's 18 February 2027 obligation for each covered battery.
• Model and individual battery information in Article 77(2) and Annex XIII.
• QR access to the unique battery identifier under Article 77(3).
• Accurate, complete and up-to-date data under Article 77(4).
• Article 13's QR-code obligation for all batteries from 18 February 2027.
• Packaging and accompanying-document exception under Article 13(7).
• New passport and linked history after reuse, repurposing or remanufacturing under Article 77(7).
• Registry registration under Article 77(10) and ESPR Article 13.
• Registry granularity and identifier-linking rules in Implementing Regulation 2026/1778 Article 8.

Implementation inference or recommended practice

• A normalized model, batch and item database schema.
• A specific JSON or API shape for the detailed operator-hosted passport.
• A particular QR image-generation supplier.
• A specific batch-field list beyond what applicable law requires.
• Event sourcing and immutable audit logs as the chosen technical pattern, although they are strongly advisable for accuracy, integrity and update governance.
• Treating the Registry-generated registration identifier as the same value as the battery's unique identifier.

Keeping these categories separate protects both the product team and the reader. The Regulation sets the compliance result. It does not prescribe your complete ERP, MES, PLM or service architecture.

Build the data model before the label

The QR code is the last visible step. A robust battery passport system starts with the unit definition, model governance, identifier issuance, batch relationships, access policy and lifecycle event handling. When those layers are correct, QR generation and Registry registration become controlled outputs of the data model.

DPPAutomate helps manufacturers map Annex XIII fields to their systems, connect model, batch and individual records, protect access by role, manage updates and generate QR-linked passport endpoints. See the DPPAutomate platform, or first review What Is a Battery Passport? and the EU Battery Passport Deadline Tracker.

Continue through the cluster

Use this architecture with the battery passport QR-code guide, the DPP identifier hierarchy, and the bulk issuance workflow. For the broader rule across product groups, see whether every product needs a separate DPP.

Sources and legal references

• Regulation (EU) 2023/1542, consolidated text, especially Articles 3(19), 3(66), 13, 77 and 78.
• Regulation (EU) 2023/1542, Annex XIII, information to be included in the battery passport.
• Regulation (EU) 2024/1781, ESPR, especially Articles 9 to 13 and Annex III.
• Commission Implementing Regulation (EU) 2026/1778, especially Articles 1, 8, 9, 10 and 12.
• European Commission, Digital Product Passport for Batteries, current implementation overview.
• European Commission, DPP Registry now live, 20 July 2026, current Registry status and API/UI information.
• European Commission, DPP FAQs, non-binding explanations of identifiers, access and architecture.

Legal note: this article is an educational implementation guide, not legal advice. Confirm the applicable battery category, current consolidated law, implementing acts and technical specifications before making a compliance decision.