KBA eCoC und IVI 2.0 für Fahrzeughersteller in Deutschland
Fachliche Übersicht zu eCoC Deutschland, KBA-Kontext, IVI XML, Fahrzeugtypgenehmigung, EUCARIS, XMLDSig und eIDAS für Hersteller.
Worum es bei einer eCoC wirklich geht
Eine elektronische Konformitätsbescheinigung ist mehr als eine digitale Kopie der Papier-CoC. Für Hersteller wird der Datensatz selbst zum Compliance-Nachweis: VIN, Typgenehmigungsnummer, Erweiterung, Variante, Version und technische Werte müssen zur genehmigten Konfiguration passen. ElectronicCoC ist dort sinnvoll, wo diese Informationen nicht mehr zuverlässig in Tabellen, E-Mails und Einzeldateien verwaltet werden können. Für die tägliche Arbeit bedeutet das: Homologation darf nicht erst am Ende prüfen, ob ein Zertifikat plausibel aussieht. Die relevanten Daten müssen bereits beim Anlegen, Ändern und Freigeben der Fahrzeugakte kontrolliert werden.
KBA-Kontext und Typgenehmigungsdaten
Das KBA ist in Deutschland der zentrale Bezugspunkt für Typgenehmigungs- und CoC-Daten. Eine Plattform ersetzt keine Behörde, sie muss aber die Herstellerverantwortung unterstützen: Genehmigungsreferenzen, Varianten, Versionen, technische Daten und Korrekturen müssen vor der XML-Erzeugung konsistent sein. Besonders kritisch sind Änderungen über die Zeit. Eine Genehmigungserweiterung, eine technische Änderung oder eine neue Produktionszuordnung kann dazu führen, dass ein bisher korrekter Datensatz neu geprüft werden muss.
IVI XML, XMLDSig und eIDAS
IVI 2.0 beschreibt strukturierte Fahrzeuginformationen, die maschinenlesbar geprüft und ausgetauscht werden können. XMLDSig und eIDAS-Siegel schaffen Vertrauen in Herkunft und Unverändertheit. Sie ersetzen jedoch keine fachliche Datenprüfung. Erst wenn Genehmigungsbezug und technische Werte stimmen, sollte signiert oder gesiegelt werden. Teams sollten deshalb vermeiden, technische XML-Validierung als einzige Qualitätsprüfung zu behandeln. Ein Datensatz kann formal korrekt sein und trotzdem den falschen Genehmigungsstand, eine alte Version oder eine unvollständige Mehrstufeninformation enthalten. Genau diese Fälle sollten vor der Freigabe sichtbar sein.
- IVI XML aus geprüften Fahrzeugakten erzeugen.
- Technische XML-Prüfung und fachliche Konsistenz trennen.
- Fortgeschrittene oder qualifizierte Siegel pro Prozess klären.
- Korrekturen als neue Version mit Nachweis führen.
Praktischer Start für Deutschland
Ein belastbares Projekt beginnt mit einem überschaubaren Fahrzeugumfang. Homologation, Produktion, Qualität und IT sollten gemeinsam festlegen, welches System für welche Datenquelle maßgeblich ist. Im Pilot sollte mindestens ein realer Korrekturfall enthalten sein. Nur dann wird sichtbar, ob eine geänderte Variante, ein neuer Genehmigungsstand oder ein korrigierter technischer Wert sauber bis in XML, Signaturstatus und Archiv übertragen wird.
- Genehmigungsfamilie und Fahrzeugkategorien abgrenzen.
- Pflichtfelder und Datenquellen mappen.
- Validierungs- und Freigaberegeln definieren.
- Signatur-, Archiv- und Korrekturprozess dokumentieren.
Rolle von ElectronicCoC
ElectronicCoC verbindet Genehmigungsreferenzen, Fahrzeugdaten, IVI XML, Validierung, eIDAS-Workflow, ERP-Integrationsfähigkeit, Mehrstufenlogik und Audit Trail in einem Herstellerprozess. Der operative Nutzen liegt vor allem in einer gemeinsamen Sicht: Homologation sieht den Genehmigungsbezug, Qualität sieht offene Prüfungen, IT sieht Integrationsstatus und Compliance sieht Freigabe- und Archivnachweise.
- Zentrale Fahrzeugakte
- Validierungsworkflow
- XML-Erzeugung
- Auditierbare Freigabe
Mehrstufige Fahrzeuge und Aufbauhersteller
Gerade bei Aufbauherstellern müssen vorherige Stufen, geerbte Daten und finale Änderungen nachvollziehbar bleiben. Masse, Aufbauart, Achslasten oder Ausrüstung dürfen nicht als lose manuelle Werte in den finalen eCoC-Datensatz wandern. Ein strukturierter Prozess zeigt deshalb nicht nur den finalen Wert, sondern auch Herkunft, Stufe, Bearbeitungsstatus und Freigabe. So bleibt nachvollziehbar, warum der finale Datensatz zur konkreten Fahrzeugkonfiguration passt. Das reduziert Rückfragen, weil die Datenentscheidung nicht aus einzelnen Dateien rekonstruiert werden muss und Freigaben fachlich belastbarer werden.
Prüfpunkte für die Plattformwahl
- KBA-Referenzen modellierbar
- IVI XML validierbar
- eIDAS-Workflow steuerbar
- Mehrstufenfälle auditierbar
Typische Fehler
- Excel als Datenquelle der Wahrheit
- Varianten zu spät prüfen
- Signieren vor Validierung
- Korrekturen ohne Versionsspur
Für wen diese Seite ist
- Fahrzeughersteller
- Aufbauhersteller
- Homologation
- Compliance und Qualität
Abgrenzung
- Keine Verbraucher-CoC-Bestellung
- Kein Ersatz für KBA-Vorgaben
- Keine Rechtsberatung
Nützliche Referenzen
- KBA CoC data and vehicle type data - Public reference used for Germany eCoC, authority-context and vehicle-data planning.
- EUCARIS IVI service - Background on IVI and structured vehicle data exchange concepts for electronic Certificate of Conformity workflows.
- EU vehicle type approval framework - European vehicle type approval context for approval references, variants, versions and manufacturer responsibilities.
- eIDAS regulation - European trust-services context for electronic signatures, electronic seals, integrity and authenticity.
Geprüft: 2026-08-09. Electronic COC Fachreview
Häufige Fragen
Was ist eine eCoC?
Eine eCoC ist ein strukturierter elektronischer Nachweis, dass ein konkretes Fahrzeug zur genehmigten Konfiguration passt. Sie verbindet Fahrzeugdaten, Genehmigungsbezug, Validierung und Freigabehistorie.
Welche Rolle spielt das KBA?
Das KBA ist der deutsche Behördenkontext für Typgenehmigungs- und CoC-Daten. ElectronicCoC unterstützt die Herstellerseite, ersetzt aber keine behördliche Entscheidung.
Was ist IVI 2.0?
IVI 2.0 steht für strukturierte Initial Vehicle Information. Im eCoC-Prozess ordnet es VIN, Genehmigungsdaten, technische Werte und Mehrstufeninformationen in XML.
Warum ist XML wichtig?
XML macht Fahrzeugdaten maschinenlesbar und validierbar. Entscheidend bleibt aber, dass die Quellwerte regulatorisch korrekt und freigegeben sind.
Was leistet XMLDSig?
XMLDSig verbindet Signaturnachweise mit XML-Inhalt. Dadurch kann später erkannt werden, ob der signierte Datensatz verändert wurde.
Wie werden Korrekturen verwaltet?
Korrekturen sollten nicht überschreiben. Sie brauchen Grund, Verantwortlichen, neue Version, gegebenenfalls neue XML-Datei und nachvollziehbaren Archivstand.
Warum sind Varianten und Versionen kritisch?
Sie verbinden das konkrete Fahrzeug mit der genehmigten technischen Konfiguration. Eine falsche Zuordnung kann den ganzen eCoC-Datensatz fachlich unstimmig machen.
Kanonische Seite