Where Do Battery Passport Data Points 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.

The layers often sit with different people. A supplier portal may provide a chemistry declaration without becoming your governed passport record. A value in ERP does not prove that ERP created or verified it. Publishing a value does not make a platform the origin of the underlying battery fact.

For the cross-category evidence question, see where product facts become true. The internal ownership decision is addressed later in this guide.

Make the evidence state visible

Receiving a file, finding a value and approving that value are different events. Use clear states so the next person knows what has actually been established. The labels below are editorial examples, not a claim about the literal field names or automated controls in ActivateDigital's software.

These are not ten mutually exclusive steps. A value can be extracted and conflicting. An operator-only declaration can subsequently be confirmed. Applicability, evidence strength, approval and validation are separate attributes. Owner confirmation does not turn a modelled estimate into a measurement or certify the whole passport.

The main source families behind Battery Passport data

The passport draws on several evidence families. No single database or enterprise application legitimately originates all of them. The systems below are operational examples, not storage products prescribed by EU law. Article 14 is a specific case where the Regulation does name the BMS. 1

An externally published datasheet can be a useful acquisition route. A controlled internal catalogue may contain the same value with better revision control. A confidential supplier pack may establish a fact that neither public source contains. Treat these as different evidence routes, with an owner and an approval decision for each. Our BatteryPass-Ready v2.0 test on public maker data compares what public documents offer with the records a maker holds.

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.

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

Preserve the source's precision. If the evidence establishes only a manufacturing month and year, do not invent a day to satisfy an export format. Resolve the representation with the applicable schema owner while retaining the true source value. Annex VI Part A distinguishes manufacturer information, manufacturing location and manufacturing month/year. 1

What the responsible operator normally supplies

The economic operator's identity and authority are business facts to establish through the appropriate records. They should not be predicted from a brand name or inferred from a product image. Registry verification and permission to update the hosted passport are also separate matters. 1 5

A document may be confidential even where a particular fact drawn from it must be public. Keep evidence access and passport-field access separate. These owner inputs are part of a credible operating process, not a failure to extract public data.

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.

A supplier assertion needs to be checked before it becomes a governed fact. Confirm the material, component, model or production state it covers. Check its semantic scope, units or concentration, effective date and issuing actor. A declaration for the right chemistry family can still concern a different formulation, concentration range, component or revision.

Keep the source wording alongside the normalised value where interpretation matters. “LFP” can establish a stated chemistry description; it does not by itself establish the detailed composition of the cathode, anode and electrolyte required in Annex XIII point 2(a). 1

A useful request names the fact, the represented battery and the smallest document that would establish it. Getting evidence out of suppliers explains the request and response record. For turning technical documentation into controlled values, 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 a calculation permitted for the intended purpose. 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 specification-sheet number is not interchangeable with a measured result simply because both use the same unit. “Rated capacity”, “capacity measured on this sample” and “remaining capacity of this used battery” are distinct assertions.

The same discipline applies to regulated calculations. A mathematically plausible formula is not automatically a permitted regulatory method. Where legislation controls a sustainability calculation, retain the method, scoped inputs, calculation output and any required verification together. Article 7 and Article 8 have their own conditions and application dates; collecting evidence does not make every associated passport field immediately due. 1 3

For the wider document-evidence model, see documents as product-data evidence.

Which Battery Passport data actually comes from the BMS?

Specified health and expected-lifetime parameters do. The Battery Passport as a whole does not.

Article 14(1) requires up-to-date data for the Annex VII parameters in the BMS of stationary battery energy storage systems, LMT batteries and EV batteries from 18 August 2024. For EV batteries, the Annex VII health parameter is state of certified energy, or SOCE. The parameter set for stationary storage and LMT batteries is different. That duty must not be extended to every industrial battery by assumption. 1

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

Cycles, negative events, operating conditions and state of charge may be collected through a BMS, vehicle, device or service architecture. Annex XIII point 4(d) does not prescribe one universal telemetry platform. Each record still needs the individual battery's identity, a defined parameter, a timestamp and provenance. 1

Starting values and observations during use

Annex XIII distinguishes performance and durability values at market placement and status changes, health information under Article 14, battery status and data generated through use. A new battery therefore needs the applicable starting information; it does not need a fictional service history. 1

The Commission FAQ clarifies that use-generated fields may initially be empty, while status and applicable performance/durability values are needed. It associates health information with BMS-equipped batteries and gives no equivalent blanket exemption for point 4(d) use data. Its update guidance calls for relevant dynamic information at status changes or when such changes are considered, with more frequent updates where needed, feasible and proportionate. It does not prescribe continuous connectivity or a universal weekly interval. 6

Define the actual process: which device or service visit supplies the observation, who checks its identity and meaning, who is authorised to accept it and which event updates the passport. Never fill an unobserved health field with “100%” merely because the battery is new.

The October guidance contains category-specific conditions for individual-battery fields. Use the field-applicability guide linked above for the detailed mapping; retain the underlying legal clause and source version in your own record. 3

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. That structure comes directly from Article 77(2) and Annex XIII. 1

Model or baseline information can include manufacturer identity, approved specifications, model-level composition, conformity documentation and baseline test values where their scope supports reuse. Individual information can include current performance, health, 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 does not establish current capacity after use. Expected model performance does not prove one unit's health. A fleet average does not replace an individual observation.

For every changing value, retain the item identity, effective time, baseline reference and update history. Keep the original baseline when a later observation arrives. The practical design question is when lifecycle data needs to follow the individual product.

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. 1

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 DPP architecture is decentralised. The operator responsible under Article 77, or an operator authorised to act on its behalf, stores the passport data. The Registry provides identifiers, registration information and the indexing layer; it does not centrally host every detailed passport fact. 1 5 7

The Registry matters for identity, registration and discovery. It is not the origin of chemistry, capacity tests, health observations or supplier evidence. A registration response cannot establish whether a source document describes the correct battery. Regulation (EU) 2026/1778 itself distinguishes automated registration checks from substantive compliance verification. 5

For the architecture, see what the EU DPP Registry stores and where passport data lives. For the separate question of who may read or update the governed value, use Battery Passport access rights.

One evidence object can support several fields

Preparation becomes more manageable when you collect evidence objects rather than asking people to retype fields one by one. A controlled object can support several facts if it actually contains evidence for each of them.

Useful 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 result when its method and scope apply.
• A conformity technical file supporting declaration, marking and test-report evidence.
• A BMS or lifecycle record supporting several individual parameters that it actually records.

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 retains its own definition, scope, method and provenance.

Store the document once, then link each supported fact to the relevant page, table or record. Keep the issuer, evidence holder, version, effective date and access conditions with it. That also makes the downstream evidence handoff more useful than sending an unexplained number to the next operator.

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

A precise request gives the recipient a fact to establish and a document to find. It also makes clear which part can be reused from existing evidence.

For example: “Please provide the released capacity test report for model X, revision B, covering the stated test conditions and identify the person who can approve it for the passport.” This is an illustrative request, not a claim about a real manufacturer.

Log what was requested, from whom, when and what would close the gap. A supplier's silence does not prove zero content, non-applicability or the absence of an internal record.

For the four public rows no manufacturer publishes yet, the smallest useful object is set out per field in what goes in a battery passport when the manufacturer hasn’t published the data.

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”. Check apparent conflicts 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 level of detail?
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 guessing?

If it cannot, keep the affected value CHECK/UNKNOWN and obtain the missing evidence. Retain both records and the decision. Absence of evidence is not zero, not “not applicable” and not permission to copy a nearby value.

Worked example: three capacity values for one battery model

Illustrative example only. The values below are fictional and extend the distinction between model capacity, a test result and an individual observation. They are not manufacturer measurements or ActivateDigital performance results. Assume a rechargeable stationary industrial battery above 2 kWh, with a BMS.

The three numbers do not yet establish a contradiction. They describe different assertions. If the report's test conditions should establish the same rated value and expose a material discrepancy, that becomes an engineering issue to resolve rather than a reason to select the most convenient number.

Multiplying the stated ratings gives 51.2 V × 100 Ah ÷ 1,000 = 5.12 kWh. That is a reproducible engineering estimate from rated inputs. Label it RULE_DERIVED, with the formula and assumptions. It does not establish measured usable energy, remaining energy or a legally accepted calculation for another field. Nor does dividing 83 by 100 establish every category's legally required health parameter: EV SOCE, for example, has its own meaning. 1

Once the relevant owners accept the supported facts, the governed record can retain the model rating, the sample test and the individual observation separately. The export can then be tested without losing why each value exists.

ActivateDigital's battery workflow starts from product identity and existing documents, so useful evidence can be reused and the remaining questions directed to their owners. See Battery Passport software to assess the current beta workflow with your own evidence. The software's current offer is distinct from approval of your facts or proof that a live passport meets every obligation. 9

A practical Battery Passport data-origin workflow

Start with one representative battery and make each handoff reviewable.

1. Establish identity and applicability. Confirm the finished battery, category, model and individual identity. Record the legal clause, relevant date and guidance version for each field.
2. Acquire the best available evidence. Reuse public manufacturer documents and controlled internal records. Request private evidence only where it adds something necessary.
3. Extract candidates with provenance. Retain the original value and passage. Normalise units carefully. Record calculations separately from direct assertions.
4. Resolve differences. Check meaning, scope, method, dates and authority. Leave unresolved candidates visibly unresolved.
5. Obtain the relevant approvals. Assign the technical or business owner for each fact and the responsible operator for the passport. Record written delegation where another operator acts on its behalf. 1
6. Maintain the governed record. Store the accepted value with its evidence, approval, access class, effective version and update trigger.
7. Test the intended representation and service. Record schema/profile version, input and result. Test permissions and lifecycle behaviour separately. A local structural check, an external API/profile test and EU Registry registration answer different questions. 5 8
8. Check readiness for lawful publication and continued use. Confirm applicable content, accuracy, identity, permitted access and the operating arrangements for updates. Publish the appropriate view and retain change history. 1

A rejected JSON export may reveal a missing required property, an incorrect type or a profile mismatch. It does not by itself show that extraction failed. Equally, a structurally valid export does not demonstrate source truth, legal completeness, live authorisation or successful production registration.

This is where the commercial value becomes practical: less duplicate entry, clearer supplier requests and a known owner for the unresolved work. Reuse what the evidence supports, then ask for the specific private declaration or in-service input that only the responsible actor can provide.

For implementation sequencing, use Battery Passport 2027 readiness. To choose a different battery question, return to the Battery Passport category hub.

What would change this page

This page was checked on 28 October 2026, using the Commission's v3.2 guidance dated 19 October 2026. Its source and ownership model should be reviewed when:

• The Batteries Regulation or Annex XIII changes the required information or its model/individual scope.
• Article 14 or Annex VII changes the specified BMS parameters.
• A delegated or implementing measure changes a calculation method, application date or required representation.
• New official technical rules prescribe a source or update mechanism that is currently an operational choice.
• The Article 77(9) instrument changes restricted-access implementation. Access entitlement must remain separate from evidence authority.
• New guidance or a revised technical profile changes the assumptions used in an export or test.

The August guidance and its launch announcement remain historical references. Current field decisions should use the checked October edition alongside the applicable law. 3 4

Sources

• Binding law: Regulation (EU) 2023/1542, consolidated text dated 13 August 2026. Articles 7, 8, 14, 77 and 78; Annex VI Part A, Annex VII and Annex XIII. Legal clauses take precedence over guidance and test profiles.
• Commission index: Digital Product Passport for Batteries, checked 28 October 2026. Records the 19 October guidance update.
  European Commission
• Official nonbinding guidance: Digital Batteries Passport: data points by category, v3.2, 19 October 2026. Cover and relevant tables checked against the downloaded PDF. Use this edition alongside the applicable law for current field decisions.
  Official guidance
• Historical context: Commission guidance launch announcement, 21 August 2026. Retained as source history, not as the current field map.
  European Commission
• Binding Registry framework: Commission Implementing Regulation (EU) 2026/1778, especially Article 8 and recital 16 on registration checks and substantive compliance.
  Delegated or implementing act
• Official nonbinding clarification: Commission Battery Passport FAQ, first edition, manuscript completed September 2026, checked 28 October 2026. Sections 2, 6 and 8. The dynamic-data discussion above is an editorial paraphrase, not the legal text.
• Official operational description: The DPP Registry, checked 28 October 2026. Indexing and decentralised hosting.
  European Commission
• Industry technical testing: BatteryPass-Ready changelog, 16 October 2026, schema v2.0.1 and profile/API testing. This is a non-government technical source.
• Product offer: ActivateDigital Battery Passport software, public beta description checked 28 October 2026. Cited for the offered workflow, not as independent certification or a verified completion-rate benchmark.