Der Batteriepass wird am 18. Februar 2027 verpflichtend, und damit stellt sich eine Frage, auf die es bislang keine gute Antwort gab: Woher wissen Sie, ob das System Ihres Anbieters tatsächlich konform ist? Die Aussage „wir halten uns an die Norm“ ist für sich genommen wertlos. Deshalb hat das Projekt BatteryPass-Ready — der vom Bund geförderte Nachfolger des im Februar 2025 abgeschlossenen Battery-Pass-Projekts — eine Konformitätsprüfung für das Datenmodell von CEN-CENELEC JTC24 veröffentlicht — und wir haben sie vollständig durchlaufen, von null bis zu elf grünen Tests. Dieser Artikel beschreibt, was wir dabei gemessen haben, was wir falsch gemacht haben, und was wissenswert ist — ob Sie nun bei uns sind oder anderswo.
Schemavalidierung und Konformitätsprüfung sind nicht dasselbe
Beides wird leicht verwechselt, beweist aber völlig Unterschiedliches.
| Schemavalidierung | Konformitätsprüfung | |
|---|---|---|
| Was wird geprüft? | eine eingereichte Datei | ein laufendes System, über das Netz |
| Worauf antwortet sie? | „Sind die eingereichten Daten korrekt?“ | „Verhält sich das System so, wie es die Norm vorschreibt?“ |
| Was sieht sie NICHT? | fehlende Felder, Zugriffsrechte, Versionierung, ausgehende Meldungen | — |
| Wie lange dauert es? | Sekunden | das System muss vorbereitet werden: Testadapter, Zugangsdaten, externe Dienste |
Die Prüfung verlangt keine Datei von Ihnen — sie ruft Sie auf. Sie bereitet den Zustand vor (legt Pässe an, stellt ein Zugriffstoken aus) und führt dann die Szenarien gegen Ihre laufende Schnittstelle aus. Das beweist erheblich mehr, und es ist erheblich schwerer zu bestehen.
Die wichtigste Lektion: ein grüner Validator bedeutet keine Abdeckung
Unser eigener Batteriepass hatte beim offiziellen Validator monatelang „alle Tests bestanden“. Wir hielten unser Modell daraufhin für vollständig. Dann haben wir anders gemessen: Wir haben jedes Blattfeld des offiziellen Datenmodells genommen und geprüft, wie viele davon wir tatsächlich ausgeben können.
Das Ergebnis: 129 von 211. Also 61 %.
Zweiundachtzig Felder fehlten — darunter vierzehn Feldgruppen, die unser Schema überhaupt nicht kannte: der absolute CO₂-Fußabdruck, die zertifizierte und die verbleibende nutzbare Energie, die Cadmium-/Blei-Kennzeichnung, die Garantiedauer, das Datum der Inbetriebnahme, die Zahl der Überladungs- und Tiefentladungsereignisse, die Risikoindizes der Lieferkette. Und — am aufschlussreichsten — der Rezyklatanteil je Material (Kobalt, Lithium, Nickel, Blei), den wir tatsächlich gespeichert hatten, nur in anderer Form, und deshalb nie abgebildet haben.
Warum hat uns nichts gewarnt? Weil ein Validator prüft, ob das Eingereichte korrekt ist — nicht, ob es ausreichend ist. Über ein fehlendes optionales Feld wird er sich nie beschweren. Das ist die gefährlichste Fehlerklasse: Sie beruhigt ohne Grundlage.
Die Abdeckung wird bei uns inzwischen von einem eigenen Werkzeug gemessen, und ein Test wacht darüber, damit sie nicht unbemerkt zurückfällt. Derzeit steht sie bei 100 % — mit einem einzigen bewusst ausgelassenen Feld, dessen Grund dokumentiert ist: Das Format der Kennung für die Inhaltsspezifikation wird vom Schema nicht beschrieben und taucht im offiziellen Musterdokument nicht auf — und erfundene Kennungen senden wir nicht.
Die 11 Tests — und was sie in der Praxis bedeuten
| Test | Was wird geprüft? | Was bedeutet das in der Praxis? |
|---|---|---|
| Lesen über die Kennung | die DPP-Kennung liefert genau ihren eigenen Pass | zwei Pässe können nicht verwechselt werden |
| Lesen über die Produktkennung | liefert die aktive Version des Produkts | es gehen die aktuellen Daten hinaus, keine alte Version |
| Ein Datenelement lesen | ein einzelnes Feld lässt sich für sich abrufen | Partner müssen nicht das ganze Dokument laden |
| Zugriffsfilterung | die Antwort wird Feld für Feld nach Rolle gefiltert | die Öffentlichkeit sieht nicht, was sie nicht sehen darf |
| Zurückgezogener Pass | ein zurückgezogener Pass wird im normalen Lesezugriff nicht ausgeliefert | ungültige Daten bleiben nicht im Umlauf |
| Vollständige Aktualisierung | eine Änderung erzeugt eine neue, nachvollziehbare Version | was sich wann geändert hat, bleibt nachweisbar |
| Ein Datenelement ändern | genau ein Feld ändert sich, sonst nichts | keine Nebenwirkungen auf andere Daten |
| Ein Attribut hinzufügen | ein neues Unterfeld lässt sich ergänzen | der Pass ist erweiterbar, nicht eingefroren |
| Ein Attribut löschen | null löscht das Feld | falsche Daten lassen sich entfernen, nicht nur überschreiben |
| Berechtigungsprüfung | kein Schreibzugriff ohne Schreibrecht | ein Leselink berechtigt niemanden zum Bearbeiten |
| Inverkehrbringen | ist die Kopie beim Backup-Anbieter angekommen und wurde das Register benachrichtigt? | die Pflicht ist keine Frage der Erklärung — sie wird geprüft |
Die letzte Zeile ist die wichtigste. Die Verordnung (EU) 2023/1542 ist nicht damit erfüllt, dass Sie die Daten halten: Sie müssen zusätzlich bei einem unabhängigen Anbieter gespeichert werden, und das Inverkehrbringen ist zu melden. Die Prüfung liest nicht Ihre Erklärung — sie kontrolliert, ob der Aufruf tatsächlich erfolgt ist.
Was wir falsch gemacht haben — sieben konkrete Fälle
Dieser Abschnitt ist am nützlichsten, wenn Sie selbst integrieren. Jeder Punkt ist ein echtes, gemessenes Scheitern, keine Theorie; keiner davon wäre bei einer Schemavalidierung aufgefallen.
1. Die Form einer Fehlermeldung ist Teil der Norm
Wir starteten mit unserer eigenen Form {"error":{"code","message"}}. Die Spezifikation erwartet stattdessen ein message-Array, dessen Einträge jeweils Typ, Text, Code und Zeitstempel tragen. Wer sein eigenes Fehlerformat ausliefert, scheitert an den Fehlerbehandlungstests — und der Partner kann es ebenso wenig auswerten.
2. Die Antwort auf ein Datenelement muss in den Feldnamen eingebettet sein
Wird ein einzelnes Datenelement abgefragt, darf nicht das nackte Objekt zurückkommen, sondern das Objekt unter seinem Feldnamen:
| Falsch | Richtig |
|---|---|
{ "name": "…", "postalAddress": "…" } |
{ "economicOperatorInformation": { "name": "…" } } |
Wir lieferten byteweise identischen Inhalt und scheiterten trotzdem — und starrten eine Weile darauf, bis wir den Diff-Bericht des Testausführers selbst ausgegeben haben.
3. „Zuletzt geändert“ ist nicht der Zeitpunkt der Auslieferung
Das war der hinterhältigste Punkt. Wir schrieben den Auslieferungszeitpunkt in lastUpdated, sodass zwei aufeinanderfolgende Lesezugriffe nie dasselbe Dokument ergaben. Die Vergleichstests (unsere Kopie ↔ die Kopie beim Backup-Anbieter) hingen damit vom Glück auf die Sekunde ab: mal bestanden sie, mal nicht. Wenn Sie das im eigenen System sehen, suchen Sie den Fehler nicht im Netz — das Feld bedeutet den tatsächlichen Änderungszeitpunkt des Passes.
4. Ein zurückgezogener Pass ist für alle 404
Wir nahmen an, der Wirtschaftsakteur müsse seinen eigenen zurückgezogenen Pass weiterhin sehen. Falsch: Über diese maschinelle Schnittstelle wird ein zurückgezogener Pass an niemanden ausgeliefert, auch nicht an den Eigentümer. Aufbewahren müssen Sie ihn selbstverständlich (Behörden können ihn rückwirkend anfordern), im normalen Lesezugriff darf er aber nicht erscheinen.
5. Der Zustand „zurückgezogen“ kommt aus dem Dokument
Die Prüfung legt ein Dokument im Zustand archiviert an, und der Status steht im Dokument selbst — nicht in einem separaten Befehlsfeld. Wer das übersieht, legt den Pass als aktiv an, und dem Test „ein zurückgezogener Pass ist nicht lesbar“ fehlt der Gegenstand.
6. Fehlende Rolle: 401, nicht 403
Semantisch wäre 403 (Forbidden) die richtige Antwort, wenn jemand authentifiziert ist, aber kein Schreibrecht hat. Im Vokabular der Prüfung heißt dieser Fall jedoch „Unauthorized“, und bei einer 403 bricht der Testausführer mit Fehler ab — er sieht sich die Antwort gar nicht erst an. Die offizielle Spezifikation führt 403 für Aktualisierungen überhaupt nicht auf.
7. Das Register will das Dokument nicht
Bei der Meldung des Inverkehrbringens haben wir den vollständigen Pass übermittelt. Das Register fragt jedoch nach drei Kennungen: Product_ID, Backup_ID, Operator_ID. Die Backup_ID ist genau das, was Ihnen der Backup-Anbieter zurückgibt — das heißt: die Reihenfolge liegt fest: erst sichern, dann melden. Aus der Norm lässt sich das nicht herauslesen, nur aus dem Scheitern.
Hinzu kommt: Eine Aktualisierung, die an den Backup-Anbieter für einen dort nicht vorhandenen Pass geht, ergibt 401, nicht 404 — auf den Statuscode lässt sich also keine „noch nicht vorhanden“-Logik bauen. Unsere Sicherung wechselt deshalb in beide Richtungen zwischen Anlegen und Aktualisieren.
Zugriffsstufen: die leiseste Fehlerquelle
Das JTC24-Datenmodell legt Feld für Feld fest, wer was sehen darf. Das ist keine Zierde: Es folgt aus der Verordnung, und die Prüfung misst es Feld für Feld.
Ein eigens dafür gebautes Audit fand hier vier Abweichungen. Drei waren der Öffentlichkeit zugänglich, obwohl sie es nicht sein durften:
- die Kennung des Wirtschaftsakteurs — nur notifizierte Stellen, Behörden und die Kommission dürfen sie sehen;
- die Kennung der Fertigungsstätte — derselbe Kreis;
- die Kathoden-, Anoden- und Elektrolytmaterialien — für Reparaturbetriebe, Recycler und Erwerber, nicht für die breite Öffentlichkeit.
Die vierte lief in die andere Richtung: Wir hatten den Sorgfaltspflichtenbericht verborgen, den die Verordnung öffentlich vorsieht. Ebenfalls ein Fehler — nur mit umgekehrtem Vorzeichen.
Warum ist dieser Bereich gefährlich? Weil das Versagen lautlos ist. Ist ein Feld versehentlich öffentlich, bricht nichts ab, warnt nichts, die Seite funktioniert einwandfrei — es verlassen schlicht mehr Daten das System als vorgesehen. Nur gezielte Messung findet das.
Was gar nicht an der Norm hing
Lange Zeit scheiterten die meisten Tests daran, dass unsere ausgehenden Aufrufe überhaupt nicht ankamen. Die Fehlermeldung lautete: unable to get local issuer certificate. Der HTTP-Client unseres Servers besaß keinen brauchbaren Wurzelzertifikatsspeicher, während die Zertifikatskette der Gegenseite einwandfrei war.
Das ist lehrreich, weil es jeden ausgehenden Aufruf betrifft — den Zahlungsdienstleister, den E-Mail-Versand, Webhooks — und das Symptom sich am anderen Ende zeigt: Dort passiert einfach nichts. Wenn Ihr System „gemeldet“ sagt, der Partner davon aber keine Spur hat, prüfen Sie das zuerst.
Zwei Lehren: Führen Sie die Wurzelzertifikate mit, statt darauf zu vertrauen, dass der Server sie hat — und schalten Sie die Zertifikatsprüfung niemals ab. Sie versenden Passdaten; eine ungeprüfte Verbindung würde genau das Vertrauen zerstören, für das das ganze System existiert.
„Speicherbar“ und „rechtlich vollständig“ sind zweierlei
Eine letzte Lektion, die nicht die Norm betrifft, sondern die Software. Jedes System hat ein technisches Minimum: jene wenigen Felder, ohne die kein sinnvoller Datensatz entsteht (Bezeichnung, Artikelnummer, Kategorie). Bei uns sind das 12 Felder.
Wir haben für eine E-Auto-Batterie genau diese zwölf ausgefüllt und die rechtliche Vollständigkeit gemessen. Das Ergebnis: 17 %. Achtundfünfzig Felder fehlten.
Nennt die Oberfläche diese zwölf „Pflichtfelder“, signalisiert sie, dass Sie fertig sind — doch darüber entscheidet kein Bußgeld. Deshalb warnt unser Editor jetzt vor dem Speichern, wenn ein Pass rechtlich unvollständig ist: Er zeigt den Prozentsatz, die fehlenden Felder und die Rechtsgrundlage. Er blockiert nicht — Daten sammeln sich oft schrittweise an, und es ist nicht Aufgabe der Software zu entscheiden, wann ein Pass „fertig“ ist —, aber er lässt ihn nicht mehr lautlos hinaus.
Bei der Anbieterwahl lohnt sich die Frage nach genau diesem Unterschied: Warnt mich das System, wenn ich einen rechtlich unvollständigen Pass ausstelle?
Was ein grünes Ergebnis NICHT bedeutet
Das gehört deutlich gesagt, denn der Markt ist voll mehrdeutiger Behauptungen:
- Es ist kein amtliches Zertifikat. Die Prüfung ist das Werkzeug eines Industriekonsortiums, keine EU-Akkreditierung. Wer sie besteht, ist deshalb nicht „EU-zertifiziert“.
- Es geht nicht um Ihre Daten. Gemessen wird, dass sich das System korrekt verhält — nicht, dass Ihr Pass vollständig ist. Das bleibt Ihre Verantwortung.
- Es ersetzt keine Registrierung. Der semantische EU-Katalog für Batterien ist noch nicht in Betrieb; bis dahin kann niemand einen Batteriepass tatsächlich registrieren.
- Es gilt nicht für immer. Das Datenmodell hat Versionen und Profile; der ab Februar 2027 verbindliche Satz ist enger als das vollständige Modell. Was heute konform ist, muss bei der nächsten Version neu gemessen werden.
Sieben Fragen an Ihren Anbieter
Wenn Sie Batteriepässe ausstellen müssen, zeigen diese Fragen binnen Minuten, wo ein System steht:
- Besteht es die offizielle Konformitätsprüfung? Welche Tests sind grün? „Normkonform“ ist für sich genommen keine Antwort.
- Wie viel Prozent des offiziellen Datenmodells kann es ausgeben? Ein Schemavalidator sagt Ihnen das nicht — das muss eigens gemessen werden.
- Verarbeitet es die Zugriffsstufen Feld für Feld? Bitten Sie um ein konkretes Beispiel: Wer darf die Kennung des Wirtschaftsakteurs sehen?
- Kommt eine Kopie beim Backup-Anbieter an, und gibt es eine nachprüfbare Spur? „Haben wir das gemeldet?“ muss eine belegbare Antwort haben.
- Was geschieht mit einem zurückgezogenen Pass? Bleibt er für Behörden erhalten und verschwindet zugleich aus dem normalen Lesezugriff?
- Warnt es mich, wenn ich einen rechtlich unvollständigen Pass ausstelle? Oder lässt es ihn lautlos durch?
- Was geschieht mit meinen Daten, wenn ich den Anbieter wechsle? Die Pass-URL gehört zum Produkt, nicht zum Anbieter — dazu haben wir einen eigenen Artikel über den Anbieterwechsel geschrieben.
Wo steht Veridyn?
Unser System besteht alle 11 Tests der BatteryPass-Ready-Konformitätsprüfung — dreimal hintereinander wiederholt, damit nicht der Zufall entscheidet — und kann jedes abbildbare Feld des offiziellen Datenmodells ausgeben. Die Prüfung sieht sich keine Datei an: Sie spricht das laufende System an, über dieselbe genormte Schnittstelle (CEN-CENELEC JTC 24 Lebenszyklus-API, EN 18222), die auch das übrige Batterie-Ökosystem nutzt.
Die Beschreibung der maschinellen Schnittstelle finden Sie in der Entwicklerdokumentation, und in der Live-Demo können Sie sie in Betrieb sehen — dort ist das JTC24-Dokument herunterladbar. Wenn Sie Batteriepässe ausstellen müssen, eröffnen Sie ein kostenloses Konto.
Die Zahlen — die 11 Tests einzeln, die Abdeckung des offiziellen Datenmodells nach Datengruppen, die ausgegebenen Profile und ein herunterladbares Musterdokument — haben wir auf unserer Batteriepass-Seite an einer Stelle zusammengefasst.