# Where Do Battery Passport Data Points Actually Come From?

Source: https://activatedigital.ai/knowledge/digital-product-passport/batteries/data-origins
Last verified: 25 September 2026
Summary: Battery Passport data comes from multiple evidence families, not one database. Map each fact to its origin, evidence, governed record and update path.

Battery Passport data does not come from one database. It is assembled from assigned identity, engineering and supplier evidence, technical testing, regulated calculations, conformity records, battery-management data and lifecycle telemetry, then governed and published with provenance.

## Direct answer

Once a Battery Passport field is known to be relevant, map it through four separate layers:

**required fact → fact origin → evidence object → governed record → passport publication or update**

Those layers can sit with different actors and systems.

A supplier declaration can support a composition fact without becoming the approved value. A laboratory can create a test result without owning the product master. A PLM or PIM can govern an approved value without being where the fact originated. A passport service can publish the value without becoming its evidence authority.

The European Commission's current Battery Passport preparation guidance, version 2.0 dated 15 August 2026, brings together 71 data points. That document is useful for preparation, but the Commission is explicit that it does not add legal requirements and is not an authoritative interpretation of the legislation. The 71 rows should not be treated as 71 universal duties that all become mandatory on 18 February 2027.

If you first need to confirm **which batteries need a passport**, use [Battery Digital Product Passport requirements](https://activatedigital.ai/knowledge/digital-product-passport/batteries). If you need to establish **which data points apply to a battery**, use our guide to [the 71 Battery Passport data points and their applicability](https://activatedigital.ai/knowledge/digital-product-passport/batteries/71-data-points). This page starts with the next question: where does an applicable fact actually come from?

## Four layers behind one Battery Passport value

The easiest way to avoid bad data architecture is to stop using the word "source" for four different jobs.

| Layer | What it means | Battery example |
|---|---|---|
| **Fact origin** | Where a fact is assigned, measured, observed or calculated | A model identifier is assigned; a laboratory measures capacity; a BMS observes a state-of-health parameter |
| **Evidence object** | The artefact that substantiates the fact | Controlled product master, BOM, test report, supplier declaration, calculation file, conformity record or BMS record |
| **Governed record** | Where the approved value and provenance are controlled for reuse | PLM, ERP, PIM, QMS, LIMS, evidence repository or lifecycle data store, depending on the fact and the business |
| **Passport publication or update** | How the approved value is exposed and kept current in the passport | The responsible economic operator, directly or through an authorised service provider, publishes or updates the passport value |

This distinction matters because the four layers often do not line up neatly.

If a supplier portal contains a chemistry declaration, that may be useful evidence. It does not automatically make the supplier portal the governed record for your passport. If a value sits in ERP, that does not prove ERP created or verified the fact. If a DPP platform publishes the final value, it does not become the origin of the underlying battery truth.

For the cross-category version of this distinction, see [where product facts become true](https://activatedigital.ai/knowledge/evidence/where-product-facts-become-true). For the separate internal governance decision, see [which system should own each approved product fact](https://activatedigital.ai/knowledge/product-data/which-system-owns-each-fact).

## The main source families behind Battery Passport data

The 71 preparation rows span several evidence families. There is no single database or enterprise application that legitimately covers them all.

The systems in the last column below are **operational examples**, not systems prescribed by EU law.

| Source family | Typical Battery Passport facts | Primary fact origin and evidence | Typical governed record |
|---|---|---|---|
| **Assigned identity and master data** | Unique identifier, economic operator, manufacturer, model and serial or batch identity | Authorised identity assignment, controlled product master, registration or production records | MDM, ERP, PIM, serialisation or passport-registration service |
| **Engineering, BOM and supplier evidence** | Chemistry, hazardous substances, critical raw materials, detailed composition, part numbers and dismantling information | Engineering BOM, material declarations, controlled supplier evidence and analytical evidence where needed | PLM, material-compliance system, supplier-evidence repository |
| **Technical testing and measurement** | Capacity, power capability, resistance, efficiency, expected life and compliance test results | Controlled test or measurement process, test report and method record | QMS, LIMS, test-data repository and controlled product record |
| **Regulated calculations and sustainability methods** | Carbon footprint, recycled-content shares and other method-governed sustainability outputs when applicable | Approved method, scoped input dataset, calculation file and any required verification | LCA or calculation system plus controlled declaration or technical file |
| **Conformity and compliance records** | Declaration of conformity, marking information, safety and waste information | Technical file, approved declarations, labels, test reports and compliance records | QMS, conformity repository or controlled document system |
| **Article 14 BMS data** | Specified state-of-health and expected-lifetime parameters for covered battery classes | Battery management system output with the correct parameter semantics and battery identity | BMS or governed lifecycle data store |
| **Lifecycle and use telemetry** | Battery status, cycles, negative events, operating conditions and state of charge where applicable | Timestamped service, event or telemetry records linked to the individual battery | Lifecycle, service, vehicle, device or cloud data store |

The table is deliberately grouped by evidence family rather than by all 71 rows. The [71-data-points page](https://activatedigital.ai/knowledge/digital-product-passport/batteries/71-data-points) remains the place to work out applicability and timing.

## Identity and manufacturing facts start with assignment or production, not inference

Some Battery Passport facts exist because an authorised process assigns them. Others become true when a production event occurs.

A model identifier should come from the controlled identity for that model. A serial or batch identifier should stay attached to the battery or production population it actually represents. Place and date of manufacture should be supported by the production or release record for the relevant battery, batch or item.

That sounds simple, but it blocks several common shortcuts.

A manufacturer's registered address is not evidence of the factory that made the battery. The date printed on a PDF is not the battery's manufacture date. A similar SKU is not the represented battery. A generated identifier is not a substitute for an identifier that has already been assigned.

The practical rule is to keep **identity, granularity and effective date** attached to the value from the start.

## Engineering and supplier evidence is useful input, not automatic governed truth

Composition data often starts upstream. Engineering teams may hold a BOM or material specification while suppliers hold declarations, substance information or component-level evidence.

That does not mean "supplier says it" is enough.

Before a supplier-supported value becomes a governed Battery Passport fact, check that the evidence is tied to the correct material, component, model or production state. Check the semantic scope, units or concentration where relevant, effective date and the authority of the issuing actor.

A declaration for the right chemistry family can still be the wrong evidence if it covers a different formulation, concentration range, component or revision.

For the broader handling of supplier documentation, use [how to validate supplier evidence](https://activatedigital.ai/knowledge/evidence/supplier-evidence). For turning technical documents into controlled product data, see [technical file to governed product data](https://activatedigital.ai/knowledge/product-data/technical-file-to-governed-product-data).

## Test results need the method and represented battery, not just the number

Performance and durability information comes from controlled testing, measurement or permitted calculation.

For a test-derived value, retain enough evidence to answer:

- Which battery, model, variant or sample did the test represent?
- What parameter was actually measured?
- Which method or standard and edition were used?
- What were the test conditions and units?
- What was the result?
- Who approved or issued the record?
- Which governed passport value does the result support?
A number copied from a specification sheet is not interchangeable with a measured result simply because both use the same unit.

The same point applies to regulated calculations. A mathematically plausible formula is not automatically a legitimate regulatory method. Where legislation or a recognised method controls the calculation, the method, scoped inputs and calculation output should stay together as evidence.

If the reader needs the generic document-evidence model rather than the battery-specific mapping, see [documents as product-data evidence](https://activatedigital.ai/knowledge/evidence/documents).

## Which Battery Passport data actually comes from the BMS?

**Some specific data does. The Battery Passport as a whole does not.**

Article 14 of the Batteries Regulation is the important legally named source-system case. It requires up-to-date state-of-health and expected-lifetime parameters listed in Annex VII to be contained in the battery management system for stationary battery energy storage systems, LMT batteries and EV batteries.

For EV batteries, the state-of-health parameter is state of certified energy, or SOCE. The Annex VII parameter set for stationary battery energy storage systems and LMT batteries is different.

That legal BMS requirement should not be generalised into "Battery Passport data comes from the BMS".

Identity, manufacturer information, composition, supplier evidence, conformity records, regulated calculations and baseline test evidence do not become BMS facts just because the battery has a BMS.

There is a second distinction for lifecycle use data. Cycles, negative events, operating conditions and state of charge may be captured efficiently through a BMS, vehicle, device or cloud telemetry architecture. The Regulation does not make one universal technical source the sole evidence route for every such field. The data still needs individual-battery identity, parameter semantics, timestamp and provenance.

## Model information and individual-battery information cannot be mixed

A Battery Passport combines information that can be stable at model level with information that belongs to one battery and changes through use.

Model or baseline information can include manufacturer identity, approved specifications, model-level composition, conformity documentation and baseline test values when the relevant legal and semantic conditions allow reuse.

Individual or lifecycle information can include current performance, state of health, battery status, cycle history, negative events, operating conditions and state of charge.

The danger is copying a model average into an individual field because the names look similar.

A baseline capacity for a model is not automatically the current capacity of a battery after use. A model's expected performance is not evidence of the current state of health of one unit. A generic fleet average is not a substitute for an individual-battery observation.

Whenever a value can change with use, the governed record needs the individual identity, effective time and update history needed to distinguish the current state from the baseline.

## ERP, PLM, PIM, QMS and LIMS are mappings, not legal answers

EU battery law generally defines the information, responsibility and evidence semantics. It does not usually tell a company to store a particular field in ERP, PLM, PIM, QMS or LIMS.

Those systems can still be the right operational home for an approved value.

A PLM may govern engineering composition. A QMS or LIMS may control test evidence. ERP may hold production or commercial master data. PIM may distribute an approved customer-facing subset. A lifecycle platform may hold individual-battery events.

The right question is not "Which system is the Battery Passport source of truth?"

It is:

**For this fact, where did it originate, what evidence establishes it, which controlled record owns the approved value and what event should update it?**

If you are designing the enterprise architecture behind that answer, use [which system owns each fact](https://activatedigital.ai/knowledge/product-data/which-system-owns-each-fact) and [how ERP, PIM and PLM connect to a DPP](https://activatedigital.ai/knowledge/guides/dpp-erp-pim-plm-integration).

## The DPP Registry is not the source of the battery fact

The EU DPP system is decentralised. The detailed Battery Passport information is maintained by the responsible economic operator while the DPP Registry provides the registration and indexing layer.

That makes the Registry important for passport identity and registration. It does not turn the Registry into the origin of chemistry, test results, state of health or supplier evidence.

The same is true of the hosting or passport-publishing layer. Publishing a value and establishing a value are different jobs.

For the data-location architecture, use [what the EU DPP Registry stores and where passport data lives](https://activatedigital.ai/knowledge/regulation/where-passport-data-lives). Access permissions are another separate question, covered by [Battery Passport access rights](https://activatedigital.ai/knowledge/digital-product-passport/batteries/access-rights).

## One evidence object can support several fields

Battery Passport preparation becomes much more manageable when you collect evidence objects rather than asking people to type passport fields one by one.

A controlled evidence object can support several distinct facts if it genuinely contains evidence for each of them.

Examples include:

- a product identity and manufacturing record supporting several assigned or production facts
- an engineering BOM and material-compliance pack supporting multiple composition facts
- a performance and durability test pack supporting several measured parameters
- a controlled carbon-footprint study supporting the relevant carbon result when the applicable method and scope are satisfied
- a conformity technical file supporting declaration, marking and test-report evidence
- a BMS or lifecycle record supporting several individual parameters where the record actually contains them
This is **evidence compression**, not semantic compression.

One test report supporting capacity and resistance does not mean capacity proves resistance. One BOM containing chemistry and part numbers does not mean either field proves the other. Every extracted value still needs the correct identity, scope, method and provenance.

## When evidence is missing, ask for the smallest useful evidence object

The fastest safe next step is usually not "please fill this field". It is "please provide the smallest evidence object that can establish the missing fact".

| If you cannot establish... | Ask for the smallest useful next evidence object | Do not substitute... |
|---|---|---|
| Place or date of manufacture | Production, release or lot-genealogy record for the represented battery or batch | Company address or document date |
| Chemistry or detailed composition | Exact engineering BOM/material record plus the supplier declaration or analytical evidence needed for the disputed material | Chemistry family, marketing name or neighbouring SKU |
| A test-derived performance value | Test report or diagnostic record tied to the represented model or battery, with method, units and conditions | Catalogue value from another variant |
| A regulated sustainability result | Applicable calculation or declaration pack with method, scoped inputs and required verification | Generic industry average or free-form calculation |
| Current state-of-health parameter covered by Article 14 | BMS output for the identified battery, with parameter meaning and timestamp | Model average or design target |
| Lifecycle status or use event | Timestamped work order, event record or telemetry linked to the individual battery and responsible actor or device | Inference from age, model or missing data |

This approach reduces manual collection while keeping the evidence chain intact.

## What to do when two sources disagree

There is no safe universal rule that says "ERP wins", "the latest file wins" or "the supplier certificate wins".

When two credible values conflict, test the conflict in this order:

- Are both records about the same battery, model, variant, batch or item?
- Do they mean the same thing?
- Are they at the same granularity?
- Are units, conditions and methods comparable?
- Which record was effective for the relevant date or lifecycle state?
- Which actor had authority to establish or approve the value?
- Can the difference be resolved from evidence without inference?
If not, keep the value **CHECK/UNKNOWN** and obtain the missing evidence.

A missing value is safer than a confident but unsupported value. Absence of evidence is not zero, not "not applicable" and not permission to copy a nearby value.

ActivateDigital applies this model for you, and will [map each value to its origin, its evidence and its governed record](https://activatedigital.ai/battery-passport-software).

## A practical Battery Passport data-origin workflow

Once you know a field is relevant, the preparation sequence is straightforward.

### 1. Define the exact fact

Record the semantic definition, units, model or individual-battery level and any category or timing condition.

### 2. Identify where the fact becomes true

Is it assigned, produced, measured, calculated, declared, observed by the BMS or generated through a lifecycle event?

### 3. Nominate the evidence object

Name the smallest controlled artefact that can substantiate the value. Do not stop at vague labels such as "supplier data" or "technical documentation".

### 4. Validate the evidence

Check identity, scope, units, method, date, authority and provenance.

### 5. Govern the approved value

Decide which controlled record owns the approved answer for reuse. Treat PLM, ERP, PIM, QMS, LIMS and similar systems as operational architecture, not legal prescriptions.

### 6. Define the update rule

State what should trigger a refresh. That could be a product revision, a new test, a supplier evidence change, a lifecycle status event, a BMS observation or another governed change.

### 7. Publish only the governed value

The passport should expose the approved value appropriate to its access class, while retaining the provenance needed to explain where it came from and when it changed.

The responsible economic operator remains accountable for keeping the Battery Passport information accurate, complete and up to date. A supplier, laboratory, BMS or service provider can contribute evidence without taking over that responsibility.

For the broader Battery journey, return to the [Battery Passport category hub](https://activatedigital.ai/knowledge/category/batteries). If your immediate task is implementation sequencing for February 2027, use the [Battery Passport 2027 readiness guide](https://activatedigital.ai/knowledge/digital-product-passport/batteries/2027-readiness).

## What would change this page

This page should be reviewed if any of the following happens:

- the Commission publishes a newer Battery Passport data-point guidance version than V2.0 dated 15 August 2026
- the Batteries Regulation or Annex XIII changes the information requirements or model versus individual-battery structure
- Article 14 or Annex VII changes the legally named BMS parameter requirements
- new delegated or implementing measures change the applicable method or timing for carbon footprint, recycled content or other method-governed fields
- new official technical rules prescribe a source or update mechanism that is currently only an operational mapping
- the Article 77(9) access-rights implementing act changes how restricted information must be exposed, without confusing access rights with evidence authority
- a new current Knowledge page takes over this exact data-origin intent before integration
Status checked for the Commission's Battery Passport guidance: **25 September 2026**.

## Keep exploring

The questions this page usually raises next.

- [CompareNext questionHow Do You Prepare a Battery Passport for February 2027 While Rules Move?A dated September 2026 guide to Battery Passport readiness for 18 February 2027: what is fixed, what can be tested now and what…→](https://activatedigital.ai/knowledge/digital-product-passport/batteries/2027-readiness)
- [Another angleNext questionWhich System Should Own Each Product Fact?Learn how to choose the authoritative source for each product fact, separate system of record from evidence and resolve conflicts…→](https://activatedigital.ai/knowledge/product-data/which-system-owns-each-fact)
- [CompareNext questionWhat Does EN 18060:2025 Change for the EU Battery Passport?What EN 18060:2025 changed on 16 September 2026 for EV battery conformity evidence, and what it did not change for the EU Battery…→](https://activatedigital.ai/knowledge/digital-product-passport/batteries/en-18060-2025)

## Sources

- [European Union, Regulation (EU) 2023/1542 concerning batteries and waste batteries](https://eur-lex.europa.eu/eli/reg/2023/1542/2026-08-13/eng)
- [European Commission, Digital Product Passport for Batteries](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en) European Commission
- [European Commission, Digital Batteries Passport - data point by category, version 2.0](https://single-market-economy.ec.europa.eu/document/download/cd1e5e6c-4a4a-4b99-995a-49eb6916187e_en?filename=Digital+Batteries+Passport+-+data+point+by+category.pdf) Official guidance
- [European Commission, Guidance to support preparations for the Digital Batteries Passport](https://single-market-economy.ec.europa.eu/news/guidance-support-preparations-digital-batteries-passport-2026-08-21_en) European Commission
- [European Union, Commission Implementing Regulation (EU) 2026/1778 on the Digital Product Passport Registry](https://eur-lex.europa.eu/eli/reg_impl/2026/1778/oj) Delegated act