Battery passport options compared for smoother compliance

A battery passport is only useful if it helps us answer real compliance questions with evidence we can stand behind. In practice, that means connecting material and product data across multiple tiers, keeping a reliable chain of custody, and making the right information available to customers, regulators, auditors and internal teams without rebuilding the process every quarter.

There is no single implementation model that suits every manufacturer, importer or brand owner. Spreadsheet workflows can get a pilot moving. ERP-led builds can fit businesses with strong internal systems. Specialist platforms usually handle supplier onboarding, document control and passport publishing better. Consortium models can reduce duplication where many parties need to exchange the same data. The right choice depends on how complex our battery supply chain is, how mature our data governance already is, and how much audit pressure we expect.

A battery passport is not just a digital label. For a Digital Product Passport for battery supply chain programmes to work in the real world, it has to perform a set of operational jobs consistently.

First, it has to identify the product correctly. That sounds obvious, but it is where many programmes fail. We need a clear way to distinguish between cell, module, pack and finished product level records, and to link those records across manufacturing stages. If a pack contains cells from more than one lot, or if a module is reworked, the passport structure has to cope with that without losing traceability.

Second, it has to collect and preserve evidence, not just claims. A supplier declaration that a material is responsibly sourced is not enough on its own. We need supporting documents, version control, issue dates, expiry dates where relevant, and a clear link between each document and the material, facility, batch or component it supports. Typical evidence can include certificates of analysis, declarations of conformity, due diligence statements, recycled content declarations, facility certifications, transport records and test reports.

Third, it has to manage chain of custody. In battery supply chains, data often changes hands several times before it reaches the final economic operator placing the product on the market. A passport system needs to show who provided which data, when it was provided, what product or lot it relates to, and whether it was verified, estimated or inherited from an upstream source.

Fourth, it has to support controlled sharing. Not every party should see every field. Some information is commercially sensitive, some is supplier-confidential, and some may be intended only for regulators or specific customers. A usable passport model needs role-based access, field-level visibility rules where necessary, and a practical way to publish public-facing data separately from restricted compliance records.

Fifth, it has to be updateable. Battery products change. Suppliers change. Test results are revised. New regulatory guidance appears. If we cannot update records without breaking the audit trail, we will either create a compliance gap or bury our team in manual work. Good change control means preserving previous versions, logging approvals and showing what changed and why.

Finally, it has to support reporting in more than one direction. We may need to answer customer questionnaires, prepare for notified body or market surveillance queries, provide internal management reports, and publish information in a format that downstream users can actually consume. A passport that stores data but cannot export it cleanly is only half built.

Most battery passport projects fall into four broad models, spreadsheet-led, ERP-led, specialist platform, and consortium or ecosystem approaches. Each can work, but each places the burden in different places.

Spreadsheet-led programmes are usually the fastest way to start. We can define required fields, send templates to suppliers, collect declarations and compile a central register with relatively little upfront spend.

The strengths are speed and flexibility. If the scope is still moving, spreadsheets let us test which data points are realistic, which suppliers can respond, and where the gaps are. For a pilot covering a limited battery range, this can be entirely sensible.

The trade-offs appear quickly. Version control becomes difficult, especially where several teams are editing files. Supplier responses arrive in inconsistent formats. Attachments become detached from the records they are supposed to support. Approval workflows are weak. Audit trails are patchy unless we impose strict discipline. Spreadsheets also struggle with hierarchical product structures, many-to-many supplier relationships, and repeated updates over time.

In other words, spreadsheet-led approaches are often good for learning, but poor for scale.

ERP-led models use our existing enterprise systems as the backbone. Material master data, supplier records, batch traceability, bills of materials and production history may already sit there, so it is natural to extend that environment.

The main advantage is integration with operational truth. If our ERP already controls purchasing, manufacturing and inventory, then product identity and transaction history can be pulled from a governed source instead of being recreated elsewhere. This can reduce duplicate data entry and improve consistency between compliance records and actual production records.

The weakness is that most ERP environments were not designed specifically for battery passport workflows. Supplier evidence collection, document expiry management, external collaboration, selective data sharing and passport publication often require custom development or additional tooling. That can make implementation slower, more expensive to change, and more dependent on internal IT resources or a systems integrator.

ERP-led approaches tend to work best where we already have strong master data governance, a capable internal team, and a clear long-term architecture. They are less attractive where supplier onboarding and external evidence exchange are the hardest parts of the problem.

A specialist platform is usually the most direct route to a functioning battery passport process. These platforms are built around supplier data collection, validation workflows, document management, traceability structures and controlled sharing.

The strengths are practical. We can onboard suppliers through structured requests, validate submissions, link evidence to components and materials, manage approvals, and publish the right outputs without building everything from scratch. Platforms also tend to cope better with changing regulatory requirements because configuration can be updated faster than a bespoke ERP build.

This model is often the best fit when compliance teams need to move quickly and when the supply chain includes many external partners with varying digital maturity. It is also usually easier to create a usable operating model around a specialist tool than around a folder of templates and email trails.

The main trade-offs are integration and governance. We still need to decide which data remains in ERP, PLM or quality systems, and which sits in the passport platform. We also need to avoid creating another silo. A specialist platform works best when it is treated as part of a wider data architecture, not as a standalone repository that no one reconciles.

For teams comparing options, our guide to choosing a digital product passport for industrial batteries is a useful next step.

Consortium and ecosystem models are built around shared data exchange between multiple market participants. This can be attractive in battery value chains because many upstream actors supply several customers and do not want to answer the same request in ten different formats.

The clear benefit is standardisation. If miners, refiners, cathode producers, cell makers and OEMs can exchange data through a common model, everyone spends less time translating requests and rekeying information. It can also improve consistency where industry-agreed schemas or governance rules exist.

The trade-offs are slower decision-making and less control. Shared models often require compromise on data fields, workflows and timing. If our own reporting needs are more advanced than the common standard, we may still need an internal layer on top. Consortium participation also does not remove our responsibility for due diligence, review and audit readiness. Shared infrastructure can help move data, but it does not make weak data strong.

Battery passport design often fails when we assume every tier can provide the same kind of data in the same way. They cannot. The collection model has to reflect the role each supplier plays.

At mining level, the challenge is usually site-level and material-level evidence. Data may relate to extraction site identity, facility certifications, due diligence processes, country of origin and shipment records. The product mapping to later battery components is often indirect. We may need to accept that some upstream data is provided at site, period or shipment level rather than at finished battery serial number level.

Processors and refiners usually sit in the middle of the traceability problem. They transform inputs, blend sources and ship standardised outputs to multiple customers. Here, mass balance logic, lot traceability and documented allocation rules matter. If the same facility processes material from several sources, the passport system needs a defensible method for linking output claims to input evidence.

Cell manufacturers generally provide the most technically structured product data. They can often support batch, lot or serial level records, performance data, chemistry details, component declarations and manufacturing information. But they also tend to protect process data closely. That means our collection model must distinguish between what is required for compliance and what remains confidential.

Pack assemblers add another layer of complexity because they combine cells, electronics, housing and other components into a product sold under a different identifier. This is where parent-child relationships become essential. We need to show how upstream cell data rolls into pack-level records, and how additional assembly-stage evidence, testing and declarations are attached.

Downstream partners, including distributors, OEM customers, service providers and recyclers, usually need access rather than primary data entry. They may contribute service history, repair events, collection information or end-of-life handling data, but they are often consumers of passport information first. If we design the system as though every downstream party is a full data owner, we add friction for no gain.

Country scope matters too. In the EU, battery passport obligations sit within a broader regulatory framework for batteries placed on the Union market. If we operate in the UK, we need to distinguish between EU placing-on-market requirements and UK-specific product, waste and due diligence obligations where these diverge. The practical result is that we may need one operating model with jurisdiction-specific outputs, not separate systems for every market.

The easiest way to compare options is to ask where each model places the burden.

With spreadsheet-led approaches, the burden sits heavily on internal coordination. Compliance teams chase suppliers, clean data, reconcile versions and maintain the audit pack manually. Supplier burden is also high because templates change, guidance is inconsistent and there is usually no structured portal or validation at the point of entry. Short-term cost can look low, but long-term cost rises through labour, rework and weak audit readiness.

With ERP-led models, internal IT and change control carry more of the weight. Once built well, the process can be robust, but changes are rarely light-touch. Every new field, workflow or external reporting format may need formal development, testing and release management. Audit readiness can be strong where transactional traceability is mature, but supplier collaboration often remains awkward unless supported by another layer.

With specialist platforms, the compliance workload shifts toward governance rather than administration. Our team still defines rules, reviews exceptions and approves evidence, but less time is spent on formatting, chasing and filing. Supplier burden is usually lower because requests are structured and repeatable. Audit readiness tends to improve because records, versions and approvals are captured in one place. The main risk is poor integration discipline, if teams start storing the same data in several systems without clear ownership.

With consortium models, some burden moves outward into shared standards and shared infrastructure. That can reduce duplicated supplier requests and improve consistency across the chain. But it can also create dependency on external governance timetables. If a shared schema does not yet support a field we need for a customer or regulator, we still have to solve that gap ourselves.

Cost should also be judged over the life of the programme, not at procurement stage alone. The cheaper model at the start is often the one that creates the highest internal workload later. This is especially true once supplier populations grow, product variants multiply and evidence starts expiring and needing renewal.

If we are evaluating tools in detail, our checklist on how compliance teams vet digital product passport suppliers helps structure that review.

The right route depends less on what sounds advanced, and more on where our constraints really are.

If we are early in the process, still defining scope, and working with a narrow product set, a spreadsheet-led pilot can be sensible. We should treat it as a discovery phase with an exit plan, not as the permanent operating model.

If we already have strong ERP governance, clean supplier and product masters, and internal development capacity, an ERP-led route may be efficient. This is especially true where batch traceability is already embedded in manufacturing operations. We should still test carefully whether the external collaboration and publishing pieces are realistic inside that architecture.

If our biggest challenge is collecting, validating and sharing evidence across a broad supplier base, a specialist platform is usually the most practical route. It lets us establish process discipline faster and adapt as requirements mature. For many organisations, this becomes the operating core, integrated with ERP, PLM and quality systems rather than replacing them. Our digital product passport platform is designed around exactly that model.

If we sit in a highly networked supply chain where many partners are pursuing the same data exchange problem, a consortium or ecosystem approach may be worth joining. We should do so with clear eyes. Shared infrastructure is useful, but we still need our own internal controls, ownership model and reporting logic.

A few selection questions usually clarify the decision quickly:

• Are our main data gaps internal, or upstream with suppliers?
• Do we need to support batch, serial or aggregated reporting?
• How often will records need updating after initial publication?
• Which teams own product, supplier, quality and compliance data today?
• How many suppliers will need to submit evidence directly?
• Do customers need access to selected passport data, or only our internal team?
• Are we preparing for one market first, or several jurisdictions at once?

The best battery passport option is the one that lets us maintain traceability, preserve evidence, control access and respond to change without turning compliance into a manual rescue operation. If we choose with that operating reality in mind, smoother compliance is a realistic outcome, not just a procurement promise.

For a broader view of where these programmes fit across sectors and product types, see our industry approaches to digital product passports.