Your digital battery passport is ready. But how do you know whether it actually meets European requirements? And how can you verify that your DPP software provider has implemented the necessary technical standards? These are two critical questions for battery manufacturers, importers and other economic operators preparing for the EU Battery Regulation.
Under Article 77(1) of Regulation (EU) 2023/1542, from 18 February 2027 every LMT battery, every industrial battery with a capacity greater than 2 kWh and every electric vehicle battery "placed on the market or put into service" must have a battery passport. Creating a QR code or publishing a page of battery specifications is not enough: the passport must meet requirements on information content, accuracy, accessibility, interoperability and technical operation set by Articles 77 and 78 and Annex XIII.
Companies no longer have to rely only on their own interpretation of these requirements. The BatteryPass-Ready project has opened a publicly accessible test environment where organisations can validate their battery passport data and test the technical interoperability of their DPP systems. This article explains how to use it, step by step.
What is BatteryPass-Ready?
BatteryPass-Ready is a research project funded by the German Federal Ministry for Economic Affairs and Energy (BMWE). It is led by Fraunhofer IPK, with acatech, GEFEG mbH and TU Berlin as project partners, and more than 100 associate and supporting partners contribute to it. Its objective is to help companies prepare for the European battery passport requirements through practical validation tools, implementation guidance and interoperability testing.
The test environment was launched on 24 June 2026 and is available at batterypass-ready.gefeg.com. It is free to use, but requires an account. Its documentation describes it as a research project and a prototype, and the project's resources page calls it the first version, so expect the interface and the scope of the tests to keep changing.
The environment has two complementary modules:
| Testing module | What it verifies | Who should use it |
|---|---|---|
| Data Validation | Whether an uploaded battery passport JSON file matches the schema for its battery category (structure and syntax) | Battery manufacturers, importers, compliance teams and DPP providers |
| System-Level Testing | Whether a DPP system's Lifecycle API behaves as expected when a TestExecutor calls it in a simulated network, with an emulated EU registry and backup provider | DPP solution providers, developers and enterprise IT teams |
A perfectly structured battery passport does not mean that the software hosting and managing it is interoperable. Likewise, an interoperable DPP platform cannot guarantee that every manufacturer has supplied accurate and complete data for its batteries. Both data quality and system interoperability must be considered.
Part 1: Test your battery passport data
The first part is mainly intended for battery manufacturers and other economic operators responsible for battery passport information. It lets you test whether a specific passport dataset meets the structural requirements of the BatteryPass-Ready data model. You do not need to build a DPP platform to run this first validation.
Step 1: Access the BatteryPass-Ready test environment
Open https://batterypass-ready.gefeg.com/. The platform is free, but you need to register an account, which asks for your name, organisation, email address and a password. Once logged in, you will see the two areas, Data Validation and System-Level Testing. For this first part, use Data Validation.
Important: the test environment is not the official EU registry. The real one is the digital product passport registry set up under the Ecodesign for Sustainable Products Regulation (Regulation (EU) 2024/1781, Article 13(1)), into which Article 77(10) of the Battery Regulation requires the battery passport's unique identifier to be uploaded. BatteryPass-Ready only emulates a registry for testing purposes. We explain what the real registry checks in What the EU DPP registry validates.
Step 2: Download the reference data model
Before submitting a passport, understand the data structure the validator expects. On 27 August 2026, BatteryPass-Ready published the Data Attribute Longlist v2.0 and the Data Model v2.0, incorporating regulatory and standardisation developments. At the time of the last review, the current schema release was v2.0.1.
The BatteryPass-Ready resources page links:
- the Data Attribute Longlist v2.0;
- the "User Stories from a Technical Perspective v1.0" document, which describes the interactions between actors in the DPP system;
- the Data Model repository on GitLab, where the JSON schemas live.
The data model defines the expected structure of the information: data elements, formats, units and controlled vocabularies. Download the schema for your battery category and use it as the reference when preparing the data to be tested.
Step 3: Identify the correct battery category
Battery categories have different information requirements, so the data model provides five category schemas:
- Electric vehicle batteries (EV)
- Light means of transport batteries (LMT)
- Stationary industrial batteries above 2 kWh
- Other industrial batteries above 2 kWh
- Industrial batteries without a battery management system (BMS), a full schema of its own
Since v2.0, each schema also has a "Feb27" variant covering the requirements that apply from 18 February 2027. Select the schema and variant that correspond to the battery you are testing. A 10 kWh stationary energy-storage battery, for example, belongs under the stationary industrial schema, not the EV schema. The fields and validation expectations differ, and choosing the wrong category produces irrelevant errors or misleading results.
Step 4: Prepare your battery passport as a JSON file
The Data Validation module works with structured data, so you need a JSON representation of the passport that follows the BatteryPass-Ready schema. A website, a PDF or a QR code alone is not sufficient for this test. If you use a DPP software solution, ask your provider for a JSON export compatible with the applicable schema.
Depending on the battery category and the data model version, the file may include:
- Identification and operator information: unique battery identifier, battery model and category, economic operator and manufacturer information, manufacturing information.
- Technical characteristics: battery chemistry, rated capacity, voltage characteristics, mass, performance and durability parameters.
- Sustainability and circularity: material composition, carbon footprint information where relevant, recycled content where applicable, and information supporting dismantling, recycling and other lifecycle activities.
- Regulatory documentation: declarations of conformity, required labels and symbols, relevant documents and references.
The structure must comply with the selected schema. A measurement may have to contain both a numerical value and its unit rather than a bare number, and some attributes accept only prescribed values instead of free text. If parts of the data come from cell or module suppliers, see what to do when supplier data is missing.
Practical tip: start with one representative battery passport. Once the process works for one product, repeat it for your other categories and configurations.
Step 5: Open the Data Validation module
In the test environment, open Data Validation, select the battery category schema according to the options offered, and upload your JSON file. Before you start the validation, confirm that:
- the file contains a single passport dataset in the expected structure;
- the selected schema corresponds to the battery category;
- the data is correctly formatted;
- you are using the current version of the data model.
Then launch the validation.
Step 6: Review the validation results
The platform checks the JSON file against the schema and returns validation feedback. At the time of the last review, the checks covered structure and syntax only; plausibility checks are planned. Typical findings include:
| Example issue | What it means | How to address it |
|---|---|---|
| Required field missing | An expected attribute has not been provided | Add the required data |
| Incorrect data type | A number, string or object does not match the schema | Correct the JSON structure |
| Invalid unit | A measurement uses an unsupported or incorrectly coded unit | Use the prescribed unit representation |
| Invalid enumeration value | A field contains a value outside the permitted list | Select an accepted code |
| Incorrect nesting | An attribute is not in the expected object structure | Correct the data hierarchy |
A supplier might describe the battery chemistry in commercial terms, for example, while the model expects a standardised code. The validator may reject the value even though a person understands it. Machine-readable interoperability requires more than putting information into a digital document.
Step 7: Correct the errors and run the test again
Review each problem the validator reports. Your technical or DPP team should correct the JSON structure or, more often, the data mapping that produced it, then export the passport again and rerun the validation until the file passes.
Do not fix only the sample file if the error originates in your production data mapping, or it will reappear in every other passport you generate. The goal is to correct the source system or transformation, not to obtain one successful validation result.
Step 8: Know what a successful validation does not prove
A pass is an important milestone, but it has limits. The Data Validation module checks whether the data conforms to the machine-readable schema; it does not establish that the values are true. For example:
- a declared battery mass can have the correct format and still be wrong;
- a carbon footprint value can be structurally valid without proving that the calculation behind it is correct;
- a supplier declaration can be correctly referenced without its authenticity being established;
- a placeholder value can satisfy a format check while being unsuitable for a production passport.
Plausibility checks are planned, but even they will not replace your own verification. Manufacturers need separate processes for the accuracy, completeness, applicability and supporting evidence of their product data. Under Article 77(4), the economic operator placing the battery on the market must ensure that the passport information is accurate, complete and up to date; it may give another operator written authorisation to act on its behalf, but it keeps that responsibility.
Passing data validation is evidence of structural conformity within the tested scope, not a substitute for the economic operator's obligations.
Part 2: Test your DPP solution provider
The second module goes beyond individual passport data and asks a different question: can the DPP system correctly communicate, exchange data and perform the required operations with the other actors in the battery passport system? This matters most when you are choosing a DPP solution provider. A platform can display an attractive battery passport and still lack the interfaces needed for a scalable regulatory implementation.
Step 9: Understand what the system tests evaluate
In System-Level Testing, a backend component called the TestExecutor calls your system's Lifecycle API inside a simulated network that includes an emulated EU registry and an emulated backup provider. At launch, the environment offered 11 test scenarios across three use cases, and an update planned for October 2026 was to cover most of the test cases from the User Stories document.
Depending on the scenario, the tests can examine whether the system:
- creates and maintains battery passport data through the Lifecycle API;
- handles the operations around placing a battery on the market;
- responds to requests from other actors in the expected machine-readable format;
- applies the relevant access rights and credentials;
- interacts correctly with the emulated registry and backup provider.
Each test compares the actual behaviour of the system with the expected result. The scenarios will evolve as the project incorporates new standards, requirements and feedback.
Step 10: Ask your DPP provider for a test environment
Unlike data validation, system testing requires technical access to the DPP software. If you use an external provider, ask it to make a suitable test environment available. The provider should be able to supply:
- a test instance of its DPP system;
- the Lifecycle API endpoint;
- the Test Adapter that BatteryPass-Ready requires (see Step 11);
- test credentials or another suitable authentication mechanism;
- technical support for configuring and running the tests.
Companies developing their own DPP software will normally handle this through their engineering team. Run the tests in a controlled environment rather than exposing production data unnecessarily.
Step 11: Configure your system in System-Level Testing
Log in, open System-Level Testing and choose the role your system plays: Economic Operator or Backup Provider. Then provide two endpoints:
- Lifecycle API: the interface through which your DPP system performs the passport operations under test.
- Test Adapter: a dedicated interface that lets the test environment prepare your system for automated execution.
The Test Adapter exposes two operations:
PUT /TestSetupcreates the starting conditions for a scenario. Its commands includeinsertBatteryPass,bringBatteryToMarketandissueCredentials.PUT /TestTeardownreturns the system to a controlled state afterwards.
These functions exist for test automation and should not be confused with the production interfaces exposed to business users. The details are in section 4.4 of the BatteryPass-Ready documentation.
Important: this configuration requires technical work by the DPP provider. A manufacturer buying a hosted DPP solution should not be expected to build the Test Adapter itself. If you are evaluating a provider for the backup role, our article on certified DPP backup providers explains what that role involves.
Step 12: Select and execute the test scenarios
Once your system is connected, select the available scenarios. Each one simulates an event or request in the battery passport lifecycle, for example an external actor requesting specific information from the DPP system. Execution follows four stages:
- Setup: the test environment prepares the data and system conditions through the Test Adapter.
- Execution: the TestExecutor sends the predefined requests to your Lifecycle API.
- Validation: the responses are compared with the expected results.
- Reporting: the platform records and presents the outcome.
This reveals interoperability problems that a browser-based review of a battery passport would never show.
Step 13: Analyse the system test results
Inspect the result of each scenario, including the individual test steps and any reported differences between expected and actual behaviour. Typical issues are:
- an API operation returning an unexpected response;
- required data not returned in the expected format;
- an unsuccessful information request;
- missing or incorrect access controls;
- a lifecycle operation leaving the system in the wrong state;
- an interface behaving differently from the technical specification.
When a test fails, the provider should analyse the execution details, fix the cause and repeat the test. A meaningful assessment covers all relevant available scenarios, not one demonstration of a successfully retrieved passport. The objective is repeatable interoperability, not one successful API call.
Step 14: Request evidence of the test results
If you are buying a DPP solution, do not rely solely on the provider's statement that its platform is compliant. Ask for evidence of the tests performed:
| What to request | Why it matters |
|---|---|
| Date of testing | Confirms when the assessment was performed |
| Test environment and data model version | Identifies the reference implementation |
| Applicable specifications | Shows which technical requirements were tested |
| Role and scenarios executed | Establishes the actual scope of the assessment |
| Individual test results | Shows which scenarios passed or failed |
| Outstanding issues | Identifies known limitations |
| Retesting policy | Explains how conformity is maintained as requirements evolve |
Ask, too, whether the provider has completed both the data validation and the system tests. They verify different aspects of the solution.
Part 3: What a successful test actually means
BatteryPass-Ready offers a valuable, independent framework for checking battery passport implementations. But there is an important difference between passing technical conformance tests and holding a formal regulatory certification. The documentation itself is explicit: "Results should be treated as indicative feedback, not as a certification or a substitute for formal conformity assessment."
BatteryPass-Ready is not the EU registry, and its results do not certify that a battery or a DPP implementation meets every applicable requirement. It evaluates defined aspects of passport data and system behaviour against its reference model and test scenarios, so a result must always be read together with the test scope, the version and the requirements covered. Other matters still need separate verification, including:
- the accuracy of product-specific technical and sustainability information;
- the supporting evidence for manufacturer declarations;
- the applicable conformity assessment obligations;
- the physical marking and QR code requirements;
- operational security and data availability;
- restrictions on access to confidential information;
- changes introduced by later regulatory or technical updates.
A robust compliance programme combines BatteryPass-Ready testing with internal quality controls and legal assessment. Questions the regulation still leaves open are covered in EU battery passport 2027: the open questions.
Step 15: Establish a continuous validation process
DPP conformity is not a one-off milestone. Regulation and standards keep evolving, and DPP platforms are updated throughout their life. Repeat the relevant tests when:
- you introduce new battery categories;
- passport data structures change;
- new software versions are deployed;
- APIs are modified;
- BatteryPass-Ready publishes updated schemas or test scenarios;
- regulatory or technical specifications change.
This catches data-format and interoperability problems before they affect large numbers of live battery passports, and gives you ongoing evidence of technical readiness.
Part 4: GoodsTag passed the BatteryPass-Ready test scenarios
At GoodsTag, we believe digital product passport compliance should be demonstrated through practical testing, not simply claimed. GoodsTag is a BatteryPass-Ready partner, and we have tested our Battery DPP solution in the BatteryPass-Ready test environment. Our implementation passed the test scenarios run and was reported as fully conformant within the evaluated test scope.
This gives additional confidence that the platform aligns with the data and interoperability requirements BatteryPass-Ready evaluates, and it reflects our approach of building passports on standardised identifiers, structured data exchange and interoperable infrastructure. As with any BatteryPass-Ready result, it relates to the scenarios and versions evaluated. It is not a certification, neither of the platform nor of the regulatory compliance of any individual battery.
Why this matters for battery manufacturers
Choosing a DPP provider is not just about generating digital passports. Manufacturers need confidence that the solution supports the required technical architecture, manages structured product information and interacts with the other systems in the battery passport ecosystem. With the technical side tested, manufacturers can focus on the remaining critical task: collecting, verifying and maintaining accurate data for their batteries.
Whether you are preparing your first battery passport, reviewing an existing implementation or evaluating providers, structured conformance testing belongs in your preparation for February 2027. You can explore the free test environment directly, or contact GoodsTag to discuss your compliance and integration requirements.
Sources
- Regulation (EU) 2023/1542 on batteries and waste batteries, Articles 77 and 78 and Annex XIII
- Regulation (EU) 2024/1781 (Ecodesign for Sustainable Products Regulation), Article 13
- BatteryPass-Ready project page
- BatteryPass-Ready resources
- BatteryPass-Ready launches test environment for the digital battery passport
- Now published: Data Attribute Longlist v2.0 and Data Model v2.0
- BatteryPass Data Model repository (JSON schemas)
- BatteryPass-Ready test environment
- BatteryPass-Ready test environment documentation
Last review: 10 October 2026. The testing interface and scenarios may evolve.
