How should you evaluate battery passport software?
Start with a representative battery and the information process you need to operate, then ask each provider to demonstrate that process end to end. A polished public passport page is only one part of the system. The hard questions are whether it can link a stable identifier to the correct battery, ingest evidence from source systems, apply access rights, maintain accurate data and remain usable if the provider changes.
The EU Batteries Regulation assigns duties to economic operators; purchasing a platform does not transfer all legal responsibility to its vendor. Article 77(4) says the operator placing a battery on the market must ensure passport information is accurate, complete and up to date, although it may give another operator written authorisation to act on its behalf. This guide is a procurement framework, not a product ranking or compliance certification.
Prepare the demonstration before contacting vendors
Choose a non-sensitive sample with a model, two individual batteries and at least one change over time. Include an intentionally missing supplier value, a conflicting unit, a revised model specification and a battery whose status may change. Build a field register showing definitions, evidence, owners and access categories.
Ask every provider to use the same sample. A standardised scenario exposes differences that slide decks hide. It also separates what the product can do today from features described as planned.
Questions to put into the live demo
| Workflow | Ask the provider to show | What to inspect |
|---|---|---|
| Identity | Create and resolve a unit identifier from a QR scan | Uniqueness, wrong-record prevention, migration path |
| Import | Ingest model and unit data from source systems | Units, revisions, validation and missing values |
| Evidence | Trace a displayed claim to its source | Document version, approval, expiry or correction |
| Access | Open the same record as public reader and authorised roles | Field-level rights and downloadable data |
| Updates | Correct a field and record a status change | Permissions, history, prior values and linked records |
| Export | Export sample records and definitions | Structured usable data without provider lock-in |
| Continuity | Walk through supplier exit or service failure | Identifier resolution and ongoing availability |
Article 77(5) calls for open standards, interoperable, machine-readable, structured and searchable information without vendor lock-in. Article 78 addresses rights, integrity, security, privacy and availability after the responsible operator ceases activity. Ask a vendor to map a feature claim to the applicable provision and demonstrate the outcome, while recognising that technical details may depend on adopted measures and standards.
Who owns the data and the operating tasks?
Document where the data are stored, who can introduce or modify them, and how your organisation approves changes. Article 78 permits storage by the responsible operator or by an authorised operator acting on its behalf and limits the latter’s use of the data. Contract review should clarify data use, subcontractors, incident handling, backups, export rights, deletion and transition support.
Separate platform operator, legal duty holder, data source, and internal approver in the responsibility matrix. These roles can overlap, but the software interface should not hide them. Also ask who maintains identifiers and resolver domains if the service ends.
Can it handle real supplier data?
A supplier may send a PDF, a spreadsheet with different units or an updated declaration months later. Test whether the platform stores a value, the source version, the definition used and the decision that approved it. See whether a changed model specification applies prospectively to the right batteries rather than overwriting history for every unit.
Batch ingestion is useful, but validation feedback matters more than import speed alone. Request an error report that an operator can act on, not a silent “success” message for incomplete data. The supply-chain overview provides questions for upstream data requests.
How should you compare cost and implementation effort?
Estimate data cleanup, integration, supplier onboarding, identity management, access administration, training, hosting, ongoing review and eventual exit. Compare a fixed pilot scope across providers. Ask which services are included, which depend on custom work and what happens to data and QR links when a contract ends.
A practical scorecard can assign owners to each demonstration result: “works with our sample,” “works after configuration,” “requires development,” or “unverified.” Record evidence such as an export file or test account result. Avoid a single numerical “compliance score” that masks unresolved legal or data questions.
Red flags and next step
Be cautious when a provider treats a QR landing page as the entire passport, cannot explain access categories, refuses a structured export, cannot show change history, or claims universal compliance without identifying the battery category and legal provisions. A vendor may still have a useful component, but the limitation belongs in the decision record.
Run a bounded pilot with one battery type and a named internal owner. Confirm scope through the regulation guide, test the QR connection, and use the illustrative record to rehearse data questions before a procurement commitment.
Sources & further reading
Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.