BatteryPass-Ready: Conformance Testing for the EU Digital Battery Passport

Most companies preparing for the EU Digital Battery Passport are working from one source of truth: their own reading of Regulation 2023/1542 and Annex XIII. That is a problem, because "compliant" has, until recently, been impossible to verify against anything authoritative. You could build a passport, believe it conformed, and have no way to confirm it would actually be accepted.

That changed with the release of the BatteryPass-Ready test environment — the first concrete, near-official conformance harness for the battery DPP. It lets you check your data and your system against a shared reference implementation built directly on the current standardization and regulatory drafts. This guide is a practical walkthrough of what it tests and how to use it.

What BatteryPass-Ready Is

BatteryPass-Ready is a project of the BatteryPass-Ready Consortium, funded by the German Federal Ministry for Economic Affairs and Energy. It publishes two things that matter for compliance teams: a data model (machine-readable JSON schemas plus documentation) and a test environment that validates passports and DPP systems against that model.

The data model is a new development — it is not an update of the older "Battery Pass" content model previously published on GitHub. It builds on the DIN DKE Spec 99100 and incorporates more recent regulatory and standardization developments, as captured in the BatteryPass-Ready Data Attribute Longlist v1.3 (published March 2026). The schema files and documentation are released under a Creative Commons Attribution licence.

The Two Things It Tests

The environment is split into two independent modules that answer two different questions.

Both modules require a free account, and both provide immediate, structured feedback so you can identify and fix issues early. Data validation is the faster win and the natural starting point; system-level testing is a larger integration effort.

The Data Model: One Master Schema, Five Categories

Under the hood there is a single master schema that defines every data element, and a set of category-specific schema files that each select the relevant subset and mark which elements are mandatory. There are five battery-category schemas:

Each category enforces a different set of required fields, so validating a file against the wrong schema produces failures that do not reflect real data quality problems. The single most important step before validating is choosing the schema that matches the battery the passport describes.

The master schema groups every data element into seven components:

• Identifiers and product data — DPP identifiers, economic operator and manufacturer information, manufacturing place and date, warranty, battery category, mass, and status
• Performance and durability — capacity, voltages, power capability, round-trip efficiency, internal resistance, cycle life, temperature behavior, and more (by far the largest mandatory block)
• Battery materials and composition — chemistry, critical raw materials, hazardous substances, and cathode/anode/electrolyte materials
• Battery carbon footprint — the footprint per functional unit, broken down by lifecycle stage, plus a performance class and study link
• Circularity and resource efficiency — dismantling and spare-part information, recycled content shares, renewable content, and end-of-life guidance
• Supply chain due diligence — the due diligence report and third-party assurances
• Symbols, labels and documentation of conformity — collection symbols, the EU declaration of conformity, and test reports

How "Mandatory" Is Defined

Whether a given field is required is not a single yes/no — the model distinguishes the legal source of the obligation per battery category using a four-symbol notation:

This distinction matters in practice. A field marked x for EV may be o or n.a. for a stationary battery, which is exactly why the per-category schemas exist. It also means some "mandatory" fields trace to standardization drafts rather than the regulation text itself — useful context when you are deciding how hard to chase a particular data point.

Why the Data Shape Surprises People

If you have only read Annex XIII prose, the schema's structure can be unexpected in two ways that routinely cause validation failures.

Every value carries its unit

Values are not bare numbers. Each measured field is a small object that pairs the magnitude with its unit code. A percentage is not 12.5 — it is an object containing the value and the percent unit. Capacity, voltage, power, energy, mass, and carbon footprint all follow this wrapped pattern, each with its own defined unit codes (Ah, V, W, kWh, kg, kgCO2-eq/kWh, and so on).

Controlled vocabularies, exact spellings

Several fields accept only specific coded values, and the spelling is exact. Battery chemistry must be one of a fixed set of codes (for example Li-ion NMC, Li-ion LFP, Pb). Battery status uses original, re-used, remanufactured, repurposed, waste — note the hyphen in re-used. The DPP status field uses its own capitalized vocabulary, and each category schema fixes its own battery-category value. Free-text that "means the same thing" will fail.

Three content areas are worth flagging because they are commonly stored in a form the schema will not accept:

• Carbon footprint must be expressed as a per-functional-unit figure and broken down across lifecycle stages (raw material acquisition, main production, distribution, end of life), plus a performance class. A single aggregate number is not enough.
• Recycled content is split into pre-consumer and post-consumer shares for nickel, cobalt, and lithium — not one figure per metal.
• Performance and durability is the heaviest block, and several of its fields are inherently dynamic — state of charge, fades, time spent in extreme temperatures, deep-discharge events. These come from a battery management system and evolve over the battery's life, so capturing them is a different problem from the static nameplate data.

System-Level Testing and the Test Adapter

The second module goes beyond a single file. It exercises how your system behaves inside a network of interacting DPP participants — economic operators, backup providers, and emulated services standing in for the EU Registry. The test executor calls your system's lifecycle API directly, using the standardized interfaces defined in EN 18222, sending the same requests a real participant would in production.

To make those tests repeatable and automatable, your system also exposes a small, testing-only component called a Test Adapter. It implements two endpoints:

• PUT /TestSetup — called before each test case to bring your system into the required precondition state.
• PUT /TestTeardown — called afterward to restore a clean baseline.

Setup runs a short list of commands that the test environment defines:

The adapter is not part of your production system and is active only during testing. Because it brings the system to a known state before each run and resets it after, the whole flow can be wired into a CI/CD pipeline. The environment also ships preconfigured example interfaces, so you can run a complete test and understand the flow before connecting your own system at all.

How to Get Started

1. Create a free account and open the Resources section to download the five JSON schema files and the data model documentation. They are the authoritative definition of what is required — reviewing the schema for your category before you export anything prevents the most common structural errors.
2. Pick your category and generate one file. Produce a single passport JSON for one real unit, in the wrapped, coded shape the schema expects, and validate it against the matching category schema.
3. Validate locally first, then upload. The schema files are standard JSON Schema, so you can validate offline in seconds against the category file rather than iterating through the web UI. Once it is clean locally, confirm it in the Data Validation module.
4. Close the data gaps. Because validation is structural today, a file can pass with representative values in fields you have not yet sourced — but those gaps are your real punch list. Treat each placeholder as a field to capture before production: battery mass, warranty, the performance block, the carbon-footprint breakdown, and the recycled-content split.
5. Plan the system-level work separately. If you operate your own DPP system, the lifecycle API conformance audit and the Test Adapter are a meaningful build. Use the example interfaces to learn the flow, then schedule the integration with room to spare before February 2027.

The Bottom Line

For a compliance program, the value of BatteryPass-Ready is risk reduction on the thing that matters most: proving the passports you produce are actually conformant, rather than assuming it. The data-validation module turns a vague worry — "are we doing this right?" — into a precise, testable answer and a concrete list of what to fix. The system-level module does the same for interoperability. Neither is a legal certification, but together they are the closest thing the industry has to a dress rehearsal for the real mandate.

If you want a deeper grounding in the underlying obligations, our companion guides cover the EU Digital Battery Passport requirements and the EU DPP Registry Implementing Regulation.