Battery passport data fields that matter most

If you are building or reviewing a battery passport, the field list is the working backbone. It tells every team exactly which pieces of data must exist, how each one is defined, where it comes from, who owns it, and how it should be updated. Without that list, the passport quickly turns into a mix of PDFs, test reports, supplier declarations and system exports that cannot be trusted or reused.

The battery passport data fields list that matters most is not the longest one. It is the smallest complete set that supports regulatory disclosure, customer use, internal traceability and future updates. In practice, that means structuring the list around a few core groups, then governing every field properly so the data can survive audits, product changes and handoffs across the value chain.

A battery passport data fields list is the controlled inventory of data elements that make up a battery passport. Think of it as the schema, not the finished passport itself. It sets out the fields you require, such as battery identifier, chemistry, carbon footprint value, recycled content statement, dismantling instructions reference, or due diligence declaration status.

Its purpose is practical. It lets us standardise collection, validation, storage and exchange of battery passport data across suppliers, plants, compliance teams and customers. It also prevents the common problem where different teams use the same label for different things, or different labels for the same thing.

This list is not the same as a full battery passport record.

A full battery passport record is the populated instance for one specific battery model, batch, serial number, or product family, depending on how the passport is structured. It contains actual values, links, documents and status information.

It is also not the same as a customer-facing passport document or digital view. A document, portal page or QR-linked interface is only one presentation layer. The field list sits underneath that layer and defines what can appear there.

That distinction matters because many businesses start with the visible output first. They design a dashboard, a PDF or a landing page, then try to reverse engineer the data model later. That usually creates gaps, duplicate fields and poor traceability. We get better results when we define the field list first, then build the passport record structure and user interface around it.

In the EU context, the need for a structured list is driven by battery regulation requirements, expected delegated acts, and the wider direction of digital product data under ESPR. But the operational need is broader than EU compliance. The same list supports customer questionnaires, OEM onboarding, warranty handling, service access and end-of-life processes. If you need a wider view of expected content, see what data a battery passport needs.

Most useful battery passport field lists are built around five groups, identification, technical data, sustainability data, due diligence data, and circularity data.

These fields answer the basic question, what battery are we talking about?

Typical core fields include:

• Battery model name
• Product family
• Unique battery identifier
• Serial number or batch number, where applicable
• Manufacturer legal entity name
• Manufacturing site identifier
• Date of manufacture
• Country of manufacture
• QR code or digital identifier reference
• Bill of materials version
• Passport version and issue date

These fields are foundational because every technical or compliance value must be tied back to the correct product scope. If the scope is unclear, the rest of the passport is unreliable.

These describe the battery’s composition, performance and handling characteristics.

Typical examples include:

• Battery type and application
• Chemistry
• Cell format
• Rated capacity
• Nominal energy
• Nominal voltage
• Mass
• Dimensions
• Expected cycle life, where required and properly defined
• State of health methodology reference, if relevant to the use case
• Safety or transport classification references
• Performance test reference
• Software or firmware version, if it affects operation or diagnostics

Technical fields often look straightforward, but they need strict definitions. For example, “capacity” may mean rated capacity, measured capacity under a specified test condition, or residual capacity after use. A strong field list removes that ambiguity.

These are now central, not optional.

Typical fields include:

• Carbon footprint value
• Carbon footprint methodology reference
• Declared unit and system boundary
• Verification status
• Recycled content values, where required
• Renewable energy claim reference, if used in calculations
• Material composition summary
• Substance or hazardous material declarations
• LCA dataset version
• Data quality or representativeness note

For carbon-related fields in particular, storage duties and evidence handling matter just as much as the numeric value. We cover that in more detail in battery passport carbon data storage duties explained.

These show how upstream sourcing and risk management claims are supported.

Typical fields include:

• Raw material scope
• Smelter or refiner data reference, where collected
• Supplier due diligence declaration status
• Risk assessment completion status
• Corrective action status
• Audit or assurance reference
• Applicable policy reference
• Reporting period
• Responsible team or compliance owner

The exact due diligence fields depend on your position in the chain. A cell producer, pack assembler and raw material supplier will not all hold the same evidence directly. If you need to map supplier obligations more clearly, see whether raw material suppliers need passport data.

These support repair, reuse, repurposing and end-of-life treatment.

Typical fields include:

• Removability or replaceability information
• Safe disassembly instructions reference
• Repair information reference
• Diagnostic access information
• State of health data availability
• Collection or take-back information
• End-of-life handling guidance
• Material recovery information
• Waste code or classification reference, where relevant
• Second-life suitability statement, if applicable

These fields are often neglected early on because they sit outside the compliance team’s normal workflow. But they become important quickly once service teams, recyclers and downstream operators start using the passport.

A field list is only usable if each field is designed properly. A field name on its own is not enough. We recommend defining every field with at least the following attributes.

Use a clear operational name, not a vague label. “Total carbon footprint per battery” is better than “carbon”. “Manufacturing site country” is better than “origin”.

Write a one-sentence definition that removes ambiguity. If a field can be misunderstood, it will be. Definitions should state exactly what the value represents and what it excludes.

Where the field is quantitative, fix the unit. Do not allow free-text units. If energy is reported in kWh, state kWh. If mass is kg, state kg. If percentages are used, define whether they are mass share, recycled share, or another basis.

Set the data type and allowed structure. Examples:

• Text
• Integer
• Decimal with specified precision
• Date in ISO format
• Boolean
• URL
• Controlled vocabulary code
• Document reference ID

This is what allows system-to-system exchange and validation.

For many fields, free text creates chaos. Chemistry, product category, manufacturing country, verification status and document type usually need controlled values or code lists.

State where the value comes from. That might be supplier declaration, ERP master data, PLM record, test laboratory report, LCA model, manufacturing execution system, or compliance database.

Assign a business owner, not just a department. Someone must be accountable for the field being maintained and approved.

List the underlying proof required to support the field. This could be a test report, signed supplier declaration, certificate, audit report, bill of materials extract, or approved LCA file.

Define when the field must be reviewed or refreshed. Common triggers are product revision, annual reporting cycle, supplier change, methodology update, site change, or regulatory change.

Not every field applies to every battery. Mark whether the field is mandatory, conditional, or optional, and state the condition clearly.

Set the checks that determine whether a value is acceptable. This might include range limits, required document links, cross-field consistency checks, or approval workflow status.

Some fields are for internal control only. Others are customer-visible or regulator-visible. Mark whether the field is internal, shared on request, or published in the passport interface.

When we build a battery passport data fields list, this design layer is where most of the real value sits. It turns a spreadsheet of labels into a governed data model.

Battery passport data rarely lives in one place. Most of it is spread across commercial, engineering, manufacturing, compliance and supplier systems. A realistic field list should therefore map each field to its actual source landscape.

Upstream suppliers provide material declarations, origin information, due diligence statements, recycled content claims, and in some cases carbon or process data. The challenge is that supplier formats differ widely. Some send structured templates, others provide PDFs, certificates or email confirmations. Your field list should identify which supplier inputs are accepted and what evidence standard applies.

Internal manufacturing systems provide site data, production dates, batch links, line information and process references. Depending on your setup, this may sit in MES, ERP or shop-floor traceability tools.

ERP usually holds commercial and master data such as product codes, legal entity names, plant identifiers, approved supplier records and revision-controlled material data. It is often the best source for stable identity fields, but not for detailed technical or sustainability metrics unless the model has been extended for that purpose.

PLM is often the strongest source for engineering structure, bill of materials, component relationships, revision history and technical specifications. If the passport must follow engineering changes reliably, PLM should usually be one of the primary source systems.

Performance, safety and durability data often comes from internal test systems or external laboratories. The field list should distinguish between a measured value, a declared value and the test method reference. Those are not the same field and should not be merged.

Carbon footprint values, methodology references, system boundaries and allocation choices are often produced in dedicated LCA tools or sustainability reporting environments. These values need strong version control because the result may change when datasets, assumptions or boundaries change, even if the product itself does not.

Policy acknowledgements, supplier risk assessments, audit status, corrective actions and responsible sourcing records often sit in separate compliance tools. If these fields are pulled manually, define who performs the transfer and what approval step confirms the value is current.

Repair instructions, diagnostics access, firmware references and warranty-relevant identifiers may come from aftersales or service platforms rather than product design systems. This becomes particularly important for circularity and repair use cases. We cover the practical user side in how to give customers battery passport data they can use.

In EU practice, businesses often assume the final passport platform should become the source of truth. Usually it should not. The passport layer is better treated as the governed publication and exchange layer, while source systems remain authoritative for their own domains.

A usable field list is built in stages. If you try to define every possible field in one workshop, you usually get an overgrown catalogue that nobody can maintain.

List the real outcomes the passport must support. For example:

• Regulatory disclosure
• Customer data sharing
• Internal traceability
• Carbon reporting
• Repair and service access
• End-of-life handling

This prevents collecting data simply because it might be useful one day.

Decide whether the list applies to cells, modules, packs, stationary storage systems, or several levels. Also decide whether data is held at model, family, batch or serial level. Many field design problems are really scope problems in disguise.

Build a first draft under the five core groups, identification, technical, sustainability, due diligence and circularity. At this stage, include candidate fields without arguing about every format detail yet.

Mark each field as:

• Mandatory for compliance
• Mandatory for customer or operational use
• Conditional
• Nice to have

This is where the list becomes manageable. It also helps when delegated acts or customer requirements evolve, because you can expand from a governed core rather than rebuild from scratch.

Now add definition, unit, format, owner, source, evidence, update frequency and publication rule. This is the most time-consuming step, and the one most often skipped. Do not skip it.

For every field, record:

• Source system
• Current availability
• Data quality level
• Manual or automated collection
• Gap owner
• Target remediation date

This turns the field list into an implementation tool, not just a documentation exercise.

Create a simple governance model with named owners for each field group, change control for field definitions, and approval rules for published values. If a methodology changes, such as carbon calculation assumptions, the governance process must show which fields are affected and which records need republishing.

Populate the list for a small set of actual batteries. This exposes unclear definitions and hidden source issues fast. A field that looks easy in theory may turn out to require manual extraction from three systems and two supplier declarations.

Battery passport requirements are still developing. Your field list should therefore support versioning. Keep a change log, retire obsolete fields properly, and record from which date a definition applies. In the EU, this is especially important where regulation develops through implementing or delegated acts. National enforcement may also differ in practice, even where the underlying rule is EU-wide, so leave room for jurisdiction-specific handling where needed.

Do not expose a field externally just because it exists internally. Publish when the field has a clear definition, an owner, evidence, and a review process. That discipline matters more than visual polish.

A good battery passport is not built by collecting everything. It is built by deciding what matters, defining it properly, and maintaining it through product and regulatory change. The field list is where that discipline starts.

If you are refining your own battery passport data fields list, the test is simple. Can every field be understood the same way by engineering, compliance, procurement, sustainability and the customer? Can you show where the value came from, who approved it, and when it must be updated? If the answer is yes, the passport will be usable. If not, the list still needs work.