How to build a battery digital product passport

If you need to know how to create a digital product passport for batteries, the practical answer is this: start by fixing scope, then build a controlled data model, then connect each battery to a reliable record that can be updated over time. Most projects fail when teams begin with a long list of fields before deciding which products, markets and legal entities the passport must actually cover.

A battery passport is not just a compliance file in a new format. It is a structured product record that has to serve different users at different points in the battery lifecycle, from placing on the market and customer due diligence through to service, repurposing and end of life handling. To make it work, we need product, compliance, engineering, procurement, quality, IT and operations involved from the outset.

A battery digital product passport exists to make key product, sustainability, technical and compliance information available in a consistent, traceable way. In practice, it helps prove what the battery is, who placed it on the market, what it contains, how it should be handled, and which supporting evidence stands behind those claims.

For batteries sold into the EU, the regulatory driver is the EU Battery Regulation and the connected digital product passport framework. The exact obligations depend on battery type, use case and timing, but businesses should expect passport requirements to matter first for categories already under the closest scrutiny, especially industrial batteries, electric vehicle batteries and light means of transport batteries. Portable batteries can also be affected by wider battery rules, but the passport rollout and detailed data expectations are not identical across all categories.

If you are based in the UK, the position is different. The UK has its own product regulation framework after Brexit, and while many businesses align their data model to EU requirements because they export or supply EU customers, the UK does not simply copy every EU rule on the same timetable. That matters if you manufacture in Great Britain, place batteries on the EU market through an EU entity, or move products through Northern Ireland. For exporters, the safest approach is usually to design the passport to meet EU market access needs while keeping your legal entity and market logic clear. Our guide to battery passport rules for UK exporters selling into the EU explains where those distinctions matter.

A useful battery passport normally covers five things.

First, product identity. This includes the battery model, variant, capacity, chemistry, intended application, manufacturer details and the economic operator responsible for placing it on the relevant market.

Second, technical characteristics and safe use information. This can include performance parameters, handling instructions, maintenance conditions, disassembly information and any required warnings.

Third, sustainability and sourcing data. Depending on the applicable rules and customer expectations, this may include carbon footprint information, recycled content, due diligence statements, origin-related evidence and material composition data.

Fourth, conformity and supporting documentation. A passport is stronger when each claim can point back to a declaration, test report, bill of materials extract, supplier statement, audit record or approved calculation.

Fifth, lifecycle and traceability information. This is what makes the passport more than a static PDF. The record should support updates, version control and links to service, repair, second life use or end of life treatment where required.

No single team owns all of that. Engineering usually owns technical specifications and design changes. Procurement owns supplier declarations and upstream evidence. Compliance interprets the legal requirements and controls approval. Quality manages validation, nonconformities and traceability discipline. IT or digital teams handle identifiers, integrations and access control. Operations and aftersales often hold service and serialisation data. If one of those groups is missing, the passport will be incomplete or unreliable.

Before collecting anything, define exactly which batteries need a passport and under which market conditions. This is the point where projects either become manageable or drift into endless data gathering.

Start with the product population. Decide whether the passport will apply at battery model level, battery pack level, serialised unit level, or a mixture of those. For some data, such as chemistry or rated capacity, model level may be enough. For other data, such as manufacturing batch, serial number or service history, you may need unit level traceability.

Then define the market scope. Ask which jurisdictions matter in the next 12 to 24 months. A battery sold only in the UK may not need exactly the same public-facing passport content as one placed on the EU market. A battery shipped from the UK to an EU distributor may require an EU-based economic operator in the data model. A battery entering Northern Ireland may need separate treatment because Northern Ireland goods rules can diverge from Great Britain practice.

Next, define the legal entities involved. Many groups discover too late that the manufacturer, importer, authorised representative and brand owner are not the same company. Your passport has to show the correct responsible operator for the market in question. That means mapping legal manufacturer, production site, placing-on-market entity and any importer or distributor roles.

Supply chain boundaries come next. Decide how far upstream you need to go for each data type. For example, do you need cell-level information from a cell supplier, pack-level information from your own assembly, and material declarations from component suppliers? Do you need mine or smelter information for due diligence, or is your current obligation satisfied by approved supplier declarations and policy evidence? These decisions affect both workload and contract requirements.

Finally, set the required level of detail for each field. Not every data point needs the same granularity. A common mistake is asking for serial-level evidence where a controlled model-level declaration would do, or publishing a summary where customer or regulator review may require the underlying document. We usually define each field against four questions:

• What is the exact field definition?
• At what level is it maintained, model, batch or serial?
• Who approves it?
• What evidence supports it?

That discipline prevents a passport from becoming an unstructured document dump.

If you are still deciding the operating model, our article on choosing a digital product passport for industrial batteries is a useful next step.

Once scope is fixed, map the data. This means building a field-by-field inventory, not just a list of broad topics.

In most battery passport projects, the core data set includes:

• Product identifier
• Battery category
• Brand and model name
• Variant or configuration code
• Serial number or batch number, where applicable
• Manufacturer legal name and address
• Placing-on-market entity
• Production site
• Date of manufacture or production period
• Battery chemistry
• Capacity and key electrical characteristics
• Weight and composition data
• Safety and handling information
• Conformity declarations
• Carbon footprint or related calculation outputs, where required
• Recycled content or material origin data, where required
• Due diligence and sourcing evidence
• Repair, disassembly or end of life information
• Version and last update date

Then identify the supporting evidence behind each field. This is often more important than the field itself. If the passport states nickel content, what document proves it? If it states carbon footprint, what methodology, boundary and approval record sit behind the number? If it identifies a production site, does that come from the ERP, the MES, or a manually maintained plant list?

Typical source systems include ERP for product master and legal entity data, PLM for design and specification data, MES for production records, QMS for approvals and nonconformities, supplier portals for declarations, LCA tools for environmental calculations, and document management systems for certificates and declarations. In smaller organisations, some of this may still sit in spreadsheets. If so, treat that as a control risk and document the ownership clearly.

Every field should have a named data owner. Not just a department, a person or role with approval authority. For example:

• Engineering owns chemistry, capacity and technical specifications
• Procurement owns supplier declarations and upstream evidence requests
• Compliance owns regulatory interpretation and release approval
• Quality owns validation rules and exception handling
• Sustainability or ESG owns carbon and recycled content methodology
• IT owns system interfaces, identifiers and access controls

Where data is supplied by third parties, define acceptance criteria. We should not load a supplier statement into a passport simply because it arrived. It needs checks for completeness, date, version, legal entity, product match and whether the declaration actually answers the field requirement.

This is also where we identify gaps. Missing data is normal in the first mapping exercise. What matters is classifying the gap correctly. Is the data unavailable, not yet requested, held in the wrong format, or available but not governed? Each gap needs an owner and a remediation path.

A battery passport only works if users can find the right record quickly and trust that it belongs to the battery in front of them.

Start with the identifier strategy. Each passport should be linked to a stable product identifier, and where needed, to a unique unit identifier. In practice, that often means a model code plus serial number or batch number. The identifier printed on the battery, label or packaging must match the identifier used in the passport system. If you have multiple internal codes across ERP, PLM and manufacturing systems, create a cross-reference table before launch.

The access method is usually a QR code or similar machine-readable carrier attached to the battery, its packaging, or accompanying documentation. The code should resolve to a controlled digital record, not to a static file that cannot be updated. For some products, the public view may show a web page with selected passport data, while authenticated users can log in for deeper information.

That leads to the access model. In most cases, we separate the passport into at least three views.

A public view contains information that should be widely accessible, such as product identity, basic technical and handling information, and selected sustainability data.

A customer or service view contains more detailed operational content, such as maintenance instructions, service bulletins, warranty-linked records or contract-specific documents.

A regulator or compliance view contains controlled evidence, approval history and restricted data that should be available on request or via permissioned access rather than published openly.

This split matters because some passport information is commercially sensitive, security-sensitive or simply too detailed for public display. The legal requirement is not usually to publish every internal record to everyone. It is to make the required information available to the right party in the right form.

Structure matters too. We should store data as structured fields wherever possible, with linked documents as evidence, rather than relying on one large PDF. Structured data is easier to validate, update, filter by market and expose through different access views. If you are assessing platform options, our guide to how compliance teams assess digital product passport suppliers covers the controls worth checking early.

A battery passport is not complete on the day it goes live. It needs a governed process for release, updates and periodic checks.

Begin with validation rules. For each field, define format rules, permitted values, mandatory status and evidence requirements. For example, if a battery category is industrial, certain technical and compliance fields may be mandatory before release. If a carbon footprint value is present, the system should also require a methodology reference, calculation date and approval record.

Then define release gates. A practical model is:

• Draft, data collected but not approved
• Review, functional owners have checked their fields
• Approved, compliance has signed off for market use
• Published, the passport is visible through the access channel
• Superseded, replaced by a newer version but retained for audit

Change control is essential. If engineering changes chemistry, cell supplier, pack design, rated capacity or manufacturing site, someone must assess whether the passport needs updating. The trigger should sit inside the existing change process, such as engineering change notice, supplier change notification, deviation approval or new product introduction workflow. Do not rely on someone remembering to update the passport afterwards.

Keep an audit trail. That means retaining prior versions, approval dates, approver names, evidence documents and the reason for change. If a customer asks which data was valid for a battery shipped six months ago, we should be able to answer without reconstructing the record from emails.

Set review intervals as well as event-driven updates. Some data changes only when the product changes. Other data, such as certificates, policy statements or due diligence evidence, may need periodic refresh even if the product itself is unchanged.

For audits or customer requests, prepare an evidence pack structure in advance. A strong passport process lets us produce the visible passport record and the underlying proof set quickly, including declarations, calculations, supplier statements, approval logs and revision history. If your team is still comparing system approaches, our overview of a digital product passport system for UK operations sets out the practical selection points.

Do not start with every battery you make or sell. Start with one line that is important enough to matter, but contained enough to manage.

The best pilot candidate usually has a clear product structure, a manageable supplier base, known export or compliance exposure, and stakeholders who will engage with the process. An industrial battery line is often a good choice because the regulatory and customer expectations are already concrete enough to test the model properly.

For the pilot, define a fixed objective. For example, issue production-ready passports for one battery family sold into one target market, using live source data and a real access method. Then measure the pilot against practical criteria:

• How many required fields were available from source systems?
• How many needed manual intervention?
• Which evidence documents were missing or inconsistent?
• How long did review and approval take?
• Where did identifier mismatches occur?
• Which changes could not be captured cleanly?
• What questions did customers, auditors or internal reviewers ask that the passport did not answer well?

Use the pilot to improve definitions, not just fill gaps. If one field repeatedly causes confusion, rewrite the field definition. If supplier evidence arrives in unusable formats, change the request template. If review takes too long, reduce unnecessary approvers and make ownership clearer.

Only scale once the workflow is repeatable. That means the data model is stable, owners are trained, validation rules work, and the identifier and access model are proven in real use. Scaling too early usually creates hundreds of inconsistent passports that later need rework.

Building a battery digital product passport is not mainly a formatting exercise. It is a product data governance exercise with compliance consequences. If we set scope properly, map the data to real owners and evidence, and pilot on one battery line before rollout, we can create passports that are useful in operations and credible in front of customers and regulators.