Where Do Battery Passport Data Points Actually Come From?

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.

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.

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. For the separate internal governance decision, see which system should own each approved product 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.

The table is deliberately grouped by evidence family rather than by all 71 rows. The 71-data-points page 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. For turning technical documents into controlled product data, see 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.

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 and how ERP, PIM and PLM connect to a DPP.

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. Access permissions are another separate question, covered by Battery Passport 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".

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:

1. Are both records about the same battery, model, variant, batch or item?
2. Do they mean the same thing?
3. Are they at the same granularity?
4. Are units, conditions and methods comparable?
5. Which record was effective for the relevant date or lifecycle state?
6. Which actor had authority to establish or approve the value?
7. 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.

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. If your immediate task is implementation sequencing for February 2027, use the Battery Passport 2027 readiness guide.

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.

Sources

• European Union, Regulation (EU) 2023/1542 concerning batteries and waste batteries
• European Commission, Digital Product Passport for Batteries
  European Commission
• European Commission, Digital Batteries Passport - data point by category, version 2.0
  Official guidance
• European Commission, Guidance to support preparations for the Digital Batteries Passport
  European Commission
• European Union, Commission Implementing Regulation (EU) 2026/1778 on the Digital Product Passport Registry
  Delegated act