Battery Passport Implementation: A Data Plan

Most battery passport plans are drawn as a software project, with data collection shown as one workstream among several. That ordering is wrong, and it is the reason programmes that look on schedule in mid-2026 will not be ready in February 2027.

The passport itself is generated. The evidence behind it is negotiated, tier by tier, with parties who have no obligation under the regulation and no particular reason to help. Everything else in the plan should be sequenced around that fact.

Step 1 — Fix scope per product line

Before anything else, establish which of your batteries are in scope and in which category. The tests are set out in which batteries need a passport, and the answer determines how many supplier relationships you need to open.

Do this per product line rather than per company. A manufacturer with an LMT pack and an industrial pack has two categories with different durability expectations and frequently different cell suppliers, which means two parallel data efforts rather than one.

Step 2 — Decide the identity level

Pack, module or cell. This decision is close to irreversible, because every downstream record attaches to whatever identifier you choose, and changing it later means re-issuing identity for product already in the field.

Cell-level identity is what allows a recycled content claim made at cell level to be traced from the pack a customer scans. If your commercial position depends on such claims, the cost is justified. If it does not, pack and module is usually sufficient and materially cheaper to operate.

Step 3 — Put data clauses into purchase terms

This is the highest-value action available and the one most frequently deferred. A data clause added to purchase terms takes effect at the next order, which means a clause agreed in month two reaches production roughly a year earlier than one agreed in month twelve.

1. Require the specific fields rather than a general obligation to cooperate on compliance.
2. Require evidence with an asserting party and a date, not values in a spreadsheet.
3. Require notification when a formulation or source changes, because passports go stale silently.
4. Set a response window, since without one requests are answered last.

The second point is what separates a passport from a claim. A figure transcribed from an email cannot be verified by anyone downstream; a figure signed by the party that produced it can be, which is the mechanism described in verifiable credentials explained.

Step 4 — Run a gap report per product line

Ask each supplier what they can provide today, not what they intend to provide by 2027. The answer to the first question is evidence; the answer to the second is a plan, and plans from parties with no regulatory obligation have a poor completion rate.

Map the responses against the field list in battery passport data fields. What emerges is usually that identification and dismantling data is available immediately, carbon footprint is available as a generic figure only, and recycled content and due diligence evidence are not available at all.

Step 5 — Decide what to do where evidence is refused

Some suppliers will decline. At low order volumes this is common, particularly for cathode formulation detail and for due diligence evidence reaching mineral origin, both of which are treated as confidential.

There are three responses and no fourth. Consolidate onto fewer suppliers so your order size supports the request; buy through an assembler willing to carry the data obligation contractually; or substitute the supplier. All three take months, which is why the gap report has to happen early enough for them to be options.

Step 6 — Integrate state of health

State of health is the only field that changes after sale, and it comes from the battery management system through a fleet or service platform. The integration itself is straightforward; the decisions around it are not.

Agree the sampling policy jointly between engineering and compliance, because it is both a disclosure decision and an engineering one. Record each update as a dated event rather than overwriting a value, so the degradation history survives — the reasoning is set out in battery passport vs battery management system.

Step 7 — Generate, carry and resolve

Only now does the software work begin in earnest, and it is the least uncertain part of the programme. Identifiers are assigned, carriers are generated, the record resolves to the right view per reader, and the restricted tier is enforced by the access policy the regulation requires.

Issue passports for one product line first. This proves the pipeline end to end and produces something demonstrable, which matters internally. It does not prove that the evidence behind the fields is complete, and presenting it as though it does is how programmes lose a quarter.

What to measure while the programme runs

The first three predict the outcome. The last two are the ones usually reported to steering committees, because they move early and reliably, which is exactly why a programme can look healthy for a year and then miss.

A realistic eighteen-month shape

Two things about this shape are worth stating plainly. The software work occupies three months near the end, and the final quarter is reserved for the gaps identified in month five — because those are the ones that were never going to close quickly, and pretending otherwise is how the last quarter becomes a crisis.