How to build a battery passport that stands up to scrutiny

If you want a battery passport that will survive customer due diligence, regulator questions, and internal audit, the best way to build a battery passport is to treat it as an evidence system, not a brochure. It has to do more than display a few sustainability claims. It needs to show where the battery came from, what it contains, how key values were calculated, who supplied each part of the data, and what changed over time.

In practice, that means starting with a defined scope, building from source records you can verify, and putting governance around the passport from day one. Teams that begin by designing a perfect front end or collecting every possible field usually create rework for themselves. The stronger approach is to decide what business and compliance outcomes the passport must support first, then build the data model, traceability rules, and operating controls around those outcomes.

A battery passport is a structured digital record for a battery, battery model, or battery batch, depending on the use case and the legal or customer requirement involved. It is meant to make information portable, consistent, and accessible across the value chain. For batteries, that usually includes technical specifications, composition, origin, sustainability information, and lifecycle events.

But simple record keeping is not enough. A usable battery passport should support at least five practical outcomes.

First, it should support market access and compliance. If you are selling into the EU, the passport needs to align with the information requirements that apply under the EU battery framework as those obligations come into force. If you are based in the UK, the position is different. The UK is not applying the EU Battery Regulation directly, but UK exporters placing batteries or products containing batteries on the EU market still need to meet EU requirements where those products are in scope. That is why we advise clients to map legal obligations by placing market, not just by company location. Our guide to battery passport rules for UK exporters selling into the EU is a useful starting point for that exercise.

Second, it should support customer assurance. OEMs, distributors, and procurement teams increasingly want defensible evidence on carbon footprint, responsible sourcing, recycled content, material composition, and end of life handling. They do not just want a PDF declaration. They want a chain back to source systems and named data owners.

Third, it should support operational decisions. Engineering, quality, aftersales, and service teams may need to identify affected batteries by chemistry, cell supplier, production lot, firmware version, or service event. A passport that cannot support recalls, warranty analysis, or remanufacturing decisions is missing part of its value.

Fourth, it should support lifecycle continuity. Batteries move through manufacture, integration into equipment or vehicles, installation, maintenance, repurposing, and recycling. Information needs to follow the asset through those stages in a controlled way.

Fifth, it should support scrutiny. That means an auditor, customer, or regulator can ask, “Where did this figure come from?” and you can answer with source records, calculation logic, timestamps, and version history.

One of the most common mistakes is to start by listing fields before deciding what the passport is actually for. Scope comes first.

Begin with the battery population. Are we covering portable batteries, industrial batteries, EV batteries, or only one of those categories? Are we building passports for cells, modules, packs, or finished products containing batteries? The answer matters because data ownership, identifiers, and legal obligations differ at each level.

Then define the lifecycle stages in scope for phase one. Many teams try to include raw material extraction through recycling from the outset. That is rarely realistic. A better first step is to identify the stages where you already have direct control or contractual leverage, such as cell procurement, pack assembly, final product integration, and placing on the market. You can then extend upstream and downstream once the core model works.

Next, decide which suppliers are in scope. We usually recommend ranking suppliers by a combination of spend, risk, and data criticality. For example:

• Cell manufacturers supplying in-scope batteries
• Cathode, anode, electrolyte, and separator suppliers where composition or sourcing claims matter
• Contract manufacturers assembling modules or packs
• Recyclers or take back partners where recovery data is part of the intended use case

You also need to define the use cases the passport must support first. Common examples include:

• Demonstrating readiness for EU market access
• Responding to OEM customer questionnaires
• Supporting carbon footprint disclosure
• Managing service, repair, and replacement history
• Enabling second life or end of life processing

Once those use cases are clear, the field list becomes easier to control. If a field does not support a legal requirement, a customer requirement, a business process, or a defined future phase, it should not be in the first release.

This is also the point to decide the level of granularity. Some data belongs at product model level, some at batch level, and some at serial number level. Treating everything as serial level creates cost and complexity. Treating everything as model level weakens traceability. The right answer is usually mixed. Nominal capacity may sit at model level, production date at batch or serial level, and service events at serial level.

If you are still selecting technology, this is where system design should follow scope, not lead it. Our article on choosing a digital product passport system in the UK explains the selection criteria we see most often in live projects.

A credible battery passport needs enough information to be useful, and enough structure to be defensible. We group the core data into four broad categories.

This is the backbone of the passport. It should let a user identify what the battery is, what it is designed to do, and how it should be handled. Depending on the product and market, that may include:

• Unique identifier for the battery, batch, or serialised unit
• Product family and model designation
• Manufacturer and economic operator details
• Battery category and intended application
• Chemistry and key material composition
• Rated capacity, voltage, energy, power, and cycle characteristics where relevant
• Weight and dimensions
• Safety and handling information
• Manufacturing date, site, and batch references
• Conformity related references where applicable

The point is not to dump every engineering attribute into the passport. It is to include the attributes needed for identification, compliance, safe use, and downstream decisions.

This is where many passports become vulnerable, because claims are included without enough support. Sustainability data should only be included where you have a documented methodology, a named source, and a process for updates.

Typical categories include:

• Carbon footprint values and the methodology used to derive them
• Recycled content, by material where required or commercially relevant
• Responsible sourcing indicators
• Information relevant to due diligence on raw materials
• Energy mix or production related environmental data, where this forms part of customer or regulatory disclosure

Be careful with derived values. If you state a carbon footprint figure, you need to know whether it came from primary supplier data, secondary datasets, or a hybrid approach. You also need version control over the calculation method. Otherwise, the passport becomes hard to defend when assumptions change.

This category answers where the battery and its key inputs came from. It does not always require full public disclosure of every upstream supplier, but it does require a controlled internal record of origin and source relationships.

That may include:

• Supplier identities and roles
• Country of manufacture for cells, modules, and packs
• Origin information for critical materials where collected
• Purchase order, batch, or shipment references linking one tier to the next
• Declarations, certificates, or due diligence records received from suppliers

The main question is whether we can connect a claim in the passport to a source document or system record. If not, it is not provenance, it is just text.

A battery passport should not stop at manufacture if the intended use includes service, repurposing, or end of life. Useful lifecycle fields often include:

• Installation date and installation context
• Service and maintenance records
• Repair or component replacement events
• State of health or diagnostic data where relevant and permitted
• Ownership or custody changes where these matter operationally
• Collection, take back, repurposing, and recycling outcomes

Not every user needs access to every field. But the passport architecture should allow lifecycle data to be appended in a controlled way.

The hard part is not deciding the fields. It is making the data traceable across ERP, PLM, MES, quality systems, supplier portals, spreadsheets, and third party declarations.

The first requirement is a clear identifier strategy. You need to decide which object is being identified at each level, such as cell, module, pack, finished product, batch, or serial number. Then you need cross references between them. If one supplier uses an internal lot code, another uses shipment IDs, and your plant uses a production order number, the passport needs a mapping layer that preserves those links.

Second, define the source of truth for each field. One owner, one source system, one update rule. For example:

• Product specifications from PLM
• Manufacturing lot and date from MES
• Supplier legal entity and purchase references from ERP
• Test and conformity records from QMS
• Carbon and recycled content declarations from approved supplier submissions

Without that discipline, teams end up reconciling competing versions of the same field.

Third, capture evidence, not just values. If a supplier declares recycled content, store the declaration reference, issue date, scope, and approval status alongside the value. If a carbon footprint is calculated, store the method version and calculation timestamp. This is what creates a chain of evidence.

Fourth, set rules for ingestion and validation. Supplier data should not flow straight into a live passport without checks. At minimum, validate format, completeness, unit consistency, identifier match, date logic, and whether the submitting party is authorised for that data element.

Fifth, design for exceptions. Some upstream data will be missing, delayed, or disputed. A robust passport can show status, such as pending, supplier declared, internally verified, or externally assured, rather than forcing false precision.

For industrial applications in particular, the data model often needs to support asset level traceability over a long service life. Our page on digital product passport approaches for industrial batteries looks at that challenge in more detail.

A battery passport becomes unreliable when nobody owns it after launch. Governance has to be explicit.

Start with ownership. We recommend assigning:

• A business owner accountable for the passport outcome
• Data owners for each major field group
• A technical owner for integrations and platform administration
• A compliance owner for legal interpretation and evidence retention
• Supplier management owners for external data collection and escalation

Then define validation rules by field type. Some data can be system validated. Some needs business approval. Some may require third party assurance, depending on the claim and the market expectation.

Access control is equally important. Not every stakeholder should see the same data. A customer may need product identity, sustainability disclosures, and handling information. Internal teams may need supplier names, costing references, and audit trails. Recyclers may need composition and dismantling information. Access should be role based and documented.

Change management is where trust is often won or lost. Battery data changes. Specifications are revised. Suppliers change. Calculation methods are updated. Service events occur. The passport needs:

• Version history
• Effective dates
• Audit logs
• Rules for superseding records
• A process for correcting errors without erasing the original trail

We also recommend a formal review cadence. Some fields should update event by event. Others can be reviewed monthly, quarterly, or on model revision. What matters is that the frequency is defined and tied to the risk of the data.

Retention matters too. If a claim may be challenged after sale, the supporting evidence needs to remain accessible for the required period under the relevant legal and contractual framework. That period may differ by market, sector, and claim type, so it should be part of your records policy from the outset.

The best way to build a battery passport is almost never a big bang programme. A phased rollout is faster, cheaper, and more defensible.

Phase one should be a narrow pilot. Choose one battery family, one market route, a manageable supplier set, and two or three priority use cases. For example, support EU customer disclosure, basic provenance, and service traceability for one industrial battery range. Build the minimum viable data model, connect the core systems, and prove that you can produce a passport with source backed evidence.

Phase two should stabilise governance. Once the pilot works, formalise data ownership, supplier onboarding rules, validation workflows, and access permissions. This is the point to document operating procedures, escalation paths, and exception handling.

Phase three should expand coverage. Add more battery families, more suppliers, and more lifecycle stages. Only then should you widen the field set significantly. Expansion works when the operating model is already tested.

Phase four should industrialise reporting and assurance. At this stage, focus on dashboarding, audit readiness, customer access patterns, and integration resilience. This is also where many organisations review whether their platform is still fit for scale.

The most common mistakes we see early are predictable:

• Starting with every possible field instead of a scoped use case
• Accepting supplier declarations without evidence metadata
• Failing to define identifier rules across tiers
• Mixing model, batch, and serial data without clear logic
• Treating the passport as a static compliance document
• Leaving governance until after the technical build
• Ignoring UK versus EU market differences when products cross borders

A battery passport that stands up to scrutiny is built on discipline. Clear scope. Controlled identifiers. Source linked evidence. Named owners. Versioned updates. If those elements are in place, the interface and reporting layer can evolve without undermining trust. If they are missing, no amount of polish will make the passport credible.

That is why we build battery passport programmes from the evidence chain outward. The goal is not just to publish data. It is to publish data that can be defended, maintained, and used across the full life of the battery.