A QR Code Is Not a Battery Passport

Most battery passport conversations start in the wrong place: the QR code. Which format, which resolver, which vendor prints the label. It’s a natural place to start — the QR code is the visible artifact, the thing you can point to and say “we have passports now.” It’s also, of everything the regulation requires, the trivial part.

The QR code is a doorway. From 18 February 2027, scanning it must lead somewhere: to a structured record of what the battery is, what it contains, and how it performs — accurate, complete, and the responsibility of whoever placed that battery on the EU market. The passport is what’s behind the door. And what’s behind the door, for most distributors and importers, currently looks like this:

The battery exists in the ERP under two part numbers, because two suppliers were onboarded four years apart and nobody reconciled them. The chemistry and capacity live in a description string, not in fields. The recycled-content figure came from a supplier spreadsheet, with no document behind it. The datasheet on file predates the product’s last revision. Point a QR code at that, and you haven’t built a passport — you’ve built a public window onto your data problem, with your company’s name on the liability.

The inversion worth internalizing

Passport-readiness projects tend to allocate effort in inverse proportion to difficulty. The data carrier, the label, the front-end — heavily discussed, easily bought, quickly commoditizing. The data layer — one resolved identity per battery, mandatory attributes as structured values, an evidence document behind every claim, freshness tracked instead of assumed — barely discussed, impossible to buy off a shelf, and the actual determinant of whether the passport is defensible.

Here’s the test that cuts through it: pick one battery SKU and try to produce, right now, the resolved record, the structured mandatory fields, and the source document for each claim you’d publish. If that takes an afternoon of hunting through PDFs and reconciling duplicate records, the QR code is not your bottleneck, and no passport vendor solves what you just experienced.

What the door should open onto

The work that makes the scan mean something is catalog data operations: resolve each battery-containing product to one canonical record; extract the mandatory attributes from datasheets into structured, normalized fields with the source and date attached; flag every claim that has no evidence and every certificate that has expired; and keep that record current as suppliers revise documents — then let whatever generates your passport draw on it. That’s the layer Claro runs, and it’s deliberately not a passport front-end: the front-ends will multiply and commoditize; the defensibility of what they publish won’t.

The distributors who’ll be calm in February 2027 aren’t the ones who picked a QR vendor early. They’re the ones who can answer, for every battery they place on the market, the question the QR code merely forwards: what, exactly, is this product — and how do you know?

Want to try the one-SKU test on your own data? Book a 30-minute call and bring a battery-related supplier feed.

FAQ

Isn't the QR code the main battery passport requirement? +

The QR code is the access mechanism. The passport is the structured, accurate, evidenced data record it links to — and the operator placing the battery on the market is responsible for that data being correct and complete.

What should come before choosing battery passport software? +

Making the underlying data defensible: one resolved identity per battery, mandatory attributes as structured fields, a source document behind every claim, and tracked freshness. The passport front-end can only publish what that layer provides.

---

Related reading

• What is the EU Battery Passport?
• Battery passport readiness: the 7 data gaps