Map a battery bill of materials for passport readiness

If you need to understand how to map a battery bill of materials for a digital product passport, start by treating the BOM as a traceability structure, not just an engineering parts list. For passport readiness, we need a mapped record that shows what the battery is made of, how each level relates to the next, who supplied it, which documents support each claim, and which identifiers let us carry that data into passport workflows without rebuilding it every time.

In practice, that means defining the battery boundary first, then creating a data model that links pack, module, cell, component and material records to suppliers, declarations, test reports, certificates and version history. If we skip that structure and jump straight into collection, we usually end up with spreadsheets that are full of part names but weak on evidence, ownership and change control.

For passport work, the battery BOM is wider than the manufacturing BOM used on the shop floor, and more structured than a purchasing BOM used for buying parts. We need a scope that is detailed enough to support regulatory, sustainability and traceability disclosures, while still being maintainable.

The first task is to set the product boundary. Are we mapping:

• the complete battery pack placed on the market
• a replaceable battery sold as a unit
• a module supplied into a larger assembly
• a cell family that sits inside several pack variants

For most battery passport programmes, the practical top level is the market-facing battery product, usually the pack or battery system. Under that, we map the hierarchy that sits inside it: pack, subassembly, module, cell, component, homogeneous material or declared substance grouping, depending on the required depth.

That depth matters. A passport-ready BOM is not only a list of direct purchased items. It should normally cover:

• electrochemical cells
• modules and interconnects
• busbars, connectors and wiring
• battery management system assemblies
• enclosure and structural parts
• thermal interface materials and cooling-related parts where relevant
• labels and safety-critical markings
• key material layers or compositions where those support required disclosures

The right level of granularity depends on what we need to prove. If a declaration sits at component level, there is no benefit in pretending we have material-level certainty. Equally, if recycled content, critical raw material origin, carbon footprint inputs or restricted substance status depend on material composition, stopping at the component number is too shallow.

For EU-facing products, the battery passport direction of travel is clear, even where detailed implementing rules continue to develop. We should expect product identity, technical characteristics, manufacturer and economic operator data, conformity-related information, and sustainability evidence to be tied back to a defensible product structure. If we also sell into the UK, we should not assume the UK will mirror every EU data point on the same timeline. The safe approach is to build one governed BOM map that can feed both EU and UK reporting routes, with country-specific outputs layered on top.

A useful rule is this: if a BOM line affects safety, compliance, composition, origin, carbon calculation, repairability, replacement, or end-of-life handling, it belongs in scope for passport mapping.

Before we ask suppliers for anything, we need a mapping structure that tells us where each data point will live. This is the difference between a one-off compliance chase and a reusable passport data model.

We set up the model around five linked record types:

1. Product or item record This is the thing we are describing, such as a battery pack, module, cell, PCB assembly or sealing ring.

2. Relationship record This shows where the item sits in the hierarchy, including parent item, child item, quantity, unit of measure and effective dates.

3. Material or composition record This captures declared material type, composition statement, recycled content fields, substance information and any standard classification used internally.

4. Supplier record This identifies the legal entity, site where relevant, supplier code, role in the chain, contact owner and approval status.

5. Evidence record This links the item or material to a source document, declaration, test report, certificate, calculation file or contract-controlled data submission.

At minimum, each item in the BOM should have a stable internal identifier. If one part number has multiple revisions, each revision needs its own version logic. If one supplier part is dual-sourced, we should not collapse those sources into one record unless the evidence is genuinely interchangeable.

A practical field set often includes:

• internal part number
• supplier part number
• item description
• product level, such as pack, module, cell, component, material
• parent part number
• quantity per parent
• unit of measure
• revision or version
• lifecycle status
• supplier name and supplier ID
• manufacturing site, if known and needed
• country of origin fields where held
• document references
• evidence status
• owner inside our business
• last validation date

This is also the stage to decide which identifiers will travel into the passport layer. We usually need a product identifier for the battery placed on the market, plus internal keys that let us trace every supporting record. If we expect system-to-system exchange, we should define now whether our master record sits in PLM, ERP, a supplier portal, a compliance platform, or a dedicated passport layer. If that architecture decision is still open, it helps to review how a digital product passport works in practice and choosing an API for Digital Product Passports before we build ourselves into a dead end.

Once the structure is fixed, we collect data level by level. This reduces duplication and makes gaps visible much earlier.

At pack level, we usually gather the commercial and technical identity of the battery product:

• finished battery model or SKU
• internal product code
• revision and release status
• rated capacity, voltage and chemistry family
• intended application
• pack mass and dimensions where held
• manufacturer and responsible economic operator details
• top-level assembly BOM
• final assembly site
• conformity-related references

This data often sits across ERP, PLM, technical files, product specifications and regulatory documentation.

At module level, if the pack contains modules, we collect:

• module part number and revision
• quantity per pack
• module mass
• electrical configuration
• module assembly drawing or structure
• module supplier or in-house build status
• manufacturing site
• linked safety-critical parts

This usually sits in engineering BOMs, manufacturing BOMs and supplier technical packs.

At cell level, the focus becomes much more sensitive, because suppliers may treat composition and process data as confidential. We still need a mapped record that captures what we can substantiate:

• cell part number and format
• cell manufacturer
• manufacturing site, where disclosed
• chemistry designation
• quantity per module or pack
• cell mass
• declaration references for composition, restricted substances, recycled content or carbon data where available
• transport and safety documentation references

This data often sits in supplier specifications, incoming quality records, SDS where applicable, declarations and contract appendices.

At component level, we gather the parts that make up the battery assembly around the cells:

• BMS PCB assemblies
• semiconductors and sensing parts where they are managed as traceable components
• harnesses and connectors
• busbars
• fuses and contactors
• enclosure parts
• gaskets, seals and adhesives
• thermal pads and insulation
• fasteners if they are included in controlled BOM scope

For each, we want part identity, supplier, quantity, revision, material family and evidence links. A common mistake is to ignore consumables and joining materials. If an adhesive, potting compound or thermal interface material affects composition, repairability or end-of-life handling, we should not leave it out just because it is hard to source.

At material level, we capture declared composition where it is available and relevant. That may include:

• metal alloy type
• polymer type
• active material family
• electrolyte-related declarations
• coating or plating information
• recycled content values
• critical raw material statements
• substance compliance declarations

The source of truth at this level is rarely one system. It is usually a blend of supplier declarations, specifications, test reports, material data sheets, certificates and engineering assumptions that need to be clearly marked as assumptions until validated.

If we are working out how to map a battery bill of materials for a digital product passport, this is the point where discipline matters most. We should record not only the value, but also where it came from, who provided it, and whether it is item-specific, family-level, or generic.

We connect suppliers and evidence through explicit links, not by keeping documents in a shared folder and hoping the filename tells the story.

Each BOM line should point to a supplier record, and each supplier record should show:

• legal entity name
• supplier code
• site name and address where relevant
• role, such as cell manufacturer, module assembler, material supplier
• approved status
• contract or framework reference if used for data sharing
• internal owner, usually procurement, quality or compliance

Then each BOM line should also point to one or more evidence records. An evidence record should capture:

• document type
• document title
• issuing organisation
• issue date
• expiry or review date if applicable
• version number
• coverage, such as specific part, part family, site, or material grade
• storage location or controlled repository link
• validation status
• reviewer and review date

Typical evidence types include:

• supplier declarations of conformity
• material declarations
• recycled content declarations
• test reports
• safety data sheets
• certificates of analysis
• quality certificates
• country of origin statements
• carbon footprint calculation inputs or reports
• audit findings where these support due diligence
• contract-controlled data templates submitted by the supplier

The key is coverage. A certificate for a supplier site is not the same as a declaration for a specific part number. A declaration for a resin family is not automatically valid for every moulded component in the battery. We should therefore record whether a document applies to:

• one exact BOM line
• several listed part numbers
• a supplier part family
• a material grade
• a manufacturing site
• a process or management system only

That distinction helps prevent false confidence. It also makes later passport publication much easier, because we can trace every disclosure back to evidence with known scope.

Where supplier data is commercially sensitive, we can still map the existence of the evidence and store confidential detail in a controlled layer. Passport readiness does not require us to expose every source document publicly. It requires us to know what supports each data point and what can be disclosed under the relevant rules.

Before any passport publication, we need a formal gap and risk review. This is where many projects discover that the BOM is technically complete but not passport-ready.

We check for four kinds of weakness.

First, missing fields. Examples include:

• no supplier site for the cell
• no revision on a component declaration
• no quantity or unit of measure on a BOM line
• no evidence for a recycled content value
• no document date on a material declaration

Second, weak traceability. For example:

• one spreadsheet combines several product versions
• supplier declarations are family-level but used as item-level proof
• a sourcing change happened in purchasing but not in the passport data
• engineering and procurement use different part numbers for the same item

Third, version problems. We need to know:

• which BOM revision is the passport based on
• whether all linked documents match that revision period
• whether superseded documents are clearly marked
• whether change notices trigger passport review

Fourth, unclear ownership. Every critical field should have a named business owner. In practice, ownership often splits across engineering, procurement, quality, sustainability, compliance and IT. If nobody owns the cell manufacturer field, it will drift. If nobody owns evidence review dates, documents will expire unnoticed.

We recommend a simple control table for each major field:

• field name
• system of record
• business owner
• update trigger
• review frequency
• required evidence
• publication status

For EU exports, this governance step is especially important because the passport is not just a marketing data sheet. It sits in a compliance context. If our battery also moves through different regulatory routes in the UK, we should maintain one controlled core dataset and document which output fields are EU-only, UK-only, or common. That avoids parallel spreadsheets and conflicting statements. For a broader view of route planning, see choosing a digital product passport route for EU exports.

The final step is to convert the mapped BOM into governed data that our passport workflow can actually use. A mapped spreadsheet is a start, but it is not the end state.

Passport-ready data has three characteristics.

First, it is structured. Each item, supplier and evidence record has its own identifier and relationship logic. We can query it, update it and export it without manual rewriting.

Second, it is governed. We know which fields are mandatory, who approves them, what evidence supports them, and what happens when a part changes.

Third, it is reusable. The same mapped BOM should support multiple outputs, such as internal compliance reviews, customer questionnaires, regulatory disclosures, and the digital product passport itself.

In practice, that means turning the mapping into a controlled dataset with:

• mandatory field rules
• validation checks
• document linkage rules
• version control
• publication workflow
• audit trail
• access control for confidential supplier information
• export logic for passport schema or API feeds

We also separate core master data from derived passport fields. For example, the BOM hierarchy, part numbers, supplier IDs and evidence links should sit as durable master data. A passport statement, such as a product-level disclosure assembled from that data, should be generated from the governed source rather than maintained by hand.

If we are serious about learning how to map a battery bill of materials for digital product passport use, this is the shift that matters most. We stop treating the passport as a document exercise and start treating it as a data management discipline.

That also makes change management workable. When a cell source changes, or a module revision is released, or a new declaration arrives, we update the affected records once and let the passport workflow pick up the change through controlled rules. Without that model, every update becomes a manual hunt across files, and errors become inevitable.

A good mapped battery BOM does not need to contain every possible sustainability data point on day one. It does need clean structure, clear ownership, evidence links and a realistic level of granularity. Once those foundations are in place, the passport layer becomes far easier to build, maintain and defend.

If you are still designing the wider battery passport process, our guide to building a battery digital product passport is the next step after BOM mapping.