Wer seine UDI-Daten heute noch in Excel-Listen, E-Mail-Anhängen und drei Artikelstämmen pflegt, hat ein Problem, das seit Jahren im ERP liegt und jetzt eine Rechnung schickt. Am 28.11.2026 ist es kein Compliance-Thema mehr, sondern ein Lieferstopp-Thema.
BfArM und EU-Kommission sagen das nur höflicher: Was bis Ende November keine EUDAMED-Registrierung hat, darf danach nicht mehr in Verkehr gebracht werden. Stand Ende Oktober 2026 bleibt dir dafür im Wesentlichen der November. Rechtsberatung ist dieser Text nicht. Welches deiner Systeme die Daten liefern soll, kannst du aber heute klären.
Was seit Ende Mai gilt und was am 28. November endet
Für Produkte, die vor dem Pflichtstart schon im Markt waren und weiter verkauft werden, formuliert das BfArM in seiner FAQ unmissverständlich: Solche Produkte „müssen bis zum 28. November 2026 in EUDAMED registriert sein“, und bis dahin nicht registrierte Produkte dürfen dann nicht mehr in Verkehr gebracht werden.
Für Produkte, die du seit Ende Mai erstmals in Verkehr bringst, gilt schon jetzt: erst registrieren, dann liefern. Kontrolliert wird das nicht vom BfArM, sondern von den Marktüberwachungsbehörden der Länder.
Dahinter steckt eine einfache Mechanik: Jedes EUDAMED-Modul startet seine eigene Uhr, sobald seine Funktionsfähigkeit im Amtsblatt steht. Die Verordnung (EU) 2024/1860 regelt das so: Sechs Monate nach der Bekanntmachung werden die zugehörigen Pflichten anwendbar, für Bestandsprodukte nach zwölf Monaten (Art. 123 Abs. 3 MDR; für In-vitro-Diagnostika parallel Art. 113 Abs. 3 IVDR).
Diese Bekanntmachung war der Beschluss (EU) 2025/2371, Amtsblatt vom 27.11.2025. Die Übersichtsseite der EU-Kommission bestätigt: Seit dem 28.05.2026 sind die ersten vier Module verpflichtend, darunter Akteursregistrierung und UDI/Produktregistrierung.
Zwei Details aus dem Q&A der Kommissionsdienststellen zur schrittweisen Einführung (Gradual Roll-out) machen den Berg kleiner. Du registrierst nicht jede Verkaufseinheit, sondern je Produktkennung: einmal pro UDI-DI, Chargen- und Seriennummern bleiben außen vor. Und ein Legacy-Produkt braucht keine eigene Registrierung, wenn „dasselbe Produkt“ bereits als MDR-Produkt registriert ist, also gleiche UDI-DI, Artikelnummer oder Handelsname ohne kennungsrelevante Änderung. Für einen Hersteller mit 300 Medizinprodukten bestimmt also die Zahl seiner Produktkennungen den Aufwand, egal wie viele Paletten er ausliefert.
Für Deutschland kommt dazu: Die Neuerfassung im DMIDS wurde laut BfArM zum Pflichtstart abgeschaltet. Wer bisher dort gemeldet hat, hat für neue Produkte seit Mai keinen zweiten Kanal mehr.
Manuell, XML-Upload oder Machine-to-Machine: die drei Wege zur EUDAMED-Registrierung
Die EU-Kommission beschreibt in ihren Guidelines on Data Exchange with EUDAMED drei Eingabewege. Die Weboberfläche: PC, Browser, Formular, Feld für Feld. Der XML-Upload über dieselbe Oberfläche: Du erzeugst XML-Dateien, die gegen die XSD-Schemas des EUDAMED-DTX-Dienstes validiert werden; die Erzeugung lässt sich automatisieren, der Upload bleibt ein Klick von Hand. Und Machine-to-Machine (M2M-DTX): Dein Backend spricht über einen eDelivery Access Point direkt mit EUDAMED, ohne menschliches Zutun.
| Weg | Was du brauchst | Wofür er taugt |
|---|---|---|
| Weboberfläche | Browser, EUDAMED-Zugang | Wenige Produkte, seltene Änderungen |
| XML-Upload | Export aus ERP/PIM gegen die DTX-XSDs, manueller Upload | Zu viele Produkte für die Formularerfassung, periodische Updates |
| Machine-to-Machine (M2M-DTX) | Eigener eDelivery Access Point On-Premises, Protokollimplementierung, Betrieb | Hohes Volumen, häufige Übermittlungen, eigene Produktdatenbank |
Die Kommission selbst dämpft die Erwartung an M2M: Es sei „die komplexeste und teuerste Lösung“, die nur unter Bedingungen sinnvoll ist, etwa wenn eine Datenbank außerhalb von EUDAMED existiert, das Volumen manuell nicht zu stemmen ist und häufig übermittelt wird. Dazu kommt der Access Point, der auf eigener Hardware installiert und gepflegt werden muss. Für einen Konzern mit zehntausend UDI-DIs ist das ein Projekt. Für einen Laborbedarf-Hersteller mit 300 Medizinprodukten ist es Overengineering.
Meine Empfehlung für den Mittelstand ist deshalb eindeutig: XML aus dem führenden System generieren, validieren, hochladen. Du bekommst die Datenqualität der Automatisierung ohne die Betriebslast einer Schnittstelle, die vielleicht viermal im Jahr sendet. M2M wird interessant, wenn Produktwechsel, Zertifikatsupdates und Vigilanzmeldungen zum Tagesgeschäft gehören.
Validierungsfehler beim XML-Upload und was kein Validator findet
Beispielszenario, bewusst vereinfacht: Ein Hersteller von Laborverbrauchsmaterial hat 1.200 Artikel im ERP, davon 300 Medizinprodukte, teils nach MDR (Klasse I und IIa), teils In-vitro-Diagnostika nach IVDR (Klasse A und B). Die regulatorischen Attribute pflegt Regulatory Affairs in einer Excel-Datei, die Produkttexte liegen im Shopsystem.
Der erste Exporter zieht alles zusammen, und die XSD-Validierung lehnt die Datei ab. Bei einem Teil der Produkte ist ein Pflichtfeld leer, weil es in der Excel-Datei nie eine Spalte dafür gab. Ein Textfeld überschreitet die zulässige Länge, weil die Shop-Bezeichnung hineinkopiert wurde.
Jetzt steht die Frage im Raum, wer das nachträgt und in welchem System.
Genau diese Fehlerklassen nennen die Guidelines der Kommission selbst, unter anderem Feldgrößen, Position der Tags und Pflicht- gegen Kannfelder; alles, was die XSD-Validierung nicht passiert, kommt zurück. Die Kommission rät ausdrücklich, die XML-Dateien automatisch zu erzeugen, um Validierungsfehler zu vermeiden.
Schwerer wiegt die Identifikation. Die Basic UDI-DI ist laut der UDI-Seite der Kommission der Hauptschlüssel in der Datenbank und der Zugangsschlüssel für alle produktbezogenen Informationen; die UDI-DI ist herstellerspezifisch je Produkt. Beide müssen aus einer der benannten Zuteilungsstellen stammen (GS1, HIBCC, ICCBBA, IFA).
Wenn in deinem ERP die GTIN im Artikelstamm steht, die Basic UDI-DI aber in einer Regulatory-Tabelle daneben, ist die Frage, wer gewinnt, wenn beide nicht zusammenpassen. Diese Frage beantwortet kein Validator; sie muss im System entschieden sein, bevor der Export läuft.
Dazu kommt die Kennungslogik bei Produktänderungen. Das Q&A der Kommissionsdienststellen stellt klar: Wurde das MDR-Produkt so geändert, dass eine neue UDI-DI fällig ist, gilt es nicht mehr als „dasselbe Produkt“ wie das Legacy-Produkt. Wer diese Zuordnung nicht im System, sondern im Kopf einer Regulatory-Kollegin führt, produziert Doppelregistrierungen oder Lücken.
UDI-Daten aus ERP und PIM: wer führt welches Feld
Jetzt der eigentliche Punkt. Die Frist zwingt dich zu einer Architekturentscheidung: Welches System ist für welches Produktdatenfeld die Wahrheit? Die EUDAMED-Registrierung ist nur ein weiterer Empfänger neben Klinik-Einkaufsportalen, PunchOut-Katalogen und dem B2B-Shop. Jeder dieser Empfänger will dieselben Stammdaten in leicht anderer Form. Wer sie viermal getrennt pflegt, muss sie auch viermal abgleichen.
Die Faustregel, die ich empfehle: Das ERP führt, was transaktional und identifizierend ist. Artikelnummer, GTIN beziehungsweise UDI-DI, Verpackungshierarchien, Chargen- und Seriennummernlogik, Status „in Verkehr“ oder „abgekündigt“. Ein PIM führt, was beschreibend, mehrsprachig und dokumentenlastig ist: Produktbezeichnungen, Risikoklasse und Nomenklatur-Codes, Gebrauchsanweisungen, Zertifikatsreferenzen, Marketingtexte. Die Trennlinie ist nicht dogmatisch, aber sie muss gezogen und dokumentiert sein.
Zurück zum Beispielhersteller mit seinen 300 Medizinprodukten. Für EUDAMED braucht er ein Mapping je Produkt: Das ERP liefert Kennungen und Status, das PIM liefert Bezeichnungen, Klassifizierung und Dokumentverweise, ein Exporter baut daraus das XML gegen die aktuelle XSD. Die Excel-Datei wird eingelesen, und genau dabei zeigt sich, warum sie danach weg muss.
Bei einem Teil der Produkte weicht der Handelsname in der Excel-Datei vom Shop ab, bei anderen fehlt die Basic UDI-DI ganz, und einige Artikel stehen im ERP auf „abgekündigt“, in der Excel-Datei aber noch auf „in Verkehr“. Jede dieser Abweichungen ist eine Entscheidung, die jemand treffen und dokumentieren muss. Im Beispiel will der Vertrieb beim Handelsnamen die Shop-Bezeichnung, Regulatory Affairs die aus der technischen Dokumentation. Beim Status entscheidet das ERP, weil dort die Abkündigung gebucht ist.
Derselbe Exporter erzeugt mit anderem Mapping auch den Katalog für die Klinik-Portale und den Shop-Feed. Dafür muss das PIM-System Freigabe-Workflows und Versionierung mitbringen, sonst weißt du beim Audit nicht, welcher Datenstand wann an EUDAMED ging. Ob sich dafür ein eigenes System rechnet, haben wir im Beitrag dazu, wann sich ein eigenes PIM wirklich lohnt, aufgeschlüsselt. Falls deine Produktgruppe später unter einen ESPR-Rechtsakt zum Digitalen Produktpass fällt, braucht auch er GTIN und Produktkennung. Das spricht dafür, das Mapping jetzt sauber aufzusetzen.
Ein Export, mehrere Zielformate. EUDAMED ist nur der Empfänger mit dem härtesten Datum.
Nach der Frist: Bescheinigungen bis 28.05.2027 und die laufende Pflege
Mit dem 28. November ändert die Arbeit nur die Richtung. Die nächste Falle sitzt im Modul „Benannte Stellen und Bescheinigungen“: Die Registrierung der Bescheinigungen ist Sache der Benannten Stelle, nicht deine. Trotzdem landet der Fehler bei dir, wenn die Basic UDI-DI auf dem Zertifikat nicht zu der passt, die du im UDI-Modul registriert hast. Dann lässt sich die Bescheinigung in EUDAMED keinem deiner registrierten Produkte zuordnen.
Die Fristen dazu stehen im Kommissionsdokument zur Übergangsfrist: Bescheinigungen, die nach MDR oder IVDR vor der Pflichtnutzung ausgestellt wurden, müssen bis zum 28.05.2027 registriert sein. Laut Q&A gilt diese 18-Monats-Frist nur für MDR- und IVDR-Produkte, die im UDI/Device-Modul registriert sind oder sein müssen; eingetragen wird jeweils nur die letzte Zertifikatsversion samt letzter Entscheidung. Neue Bescheinigungen seit dem Pflichtstart gehören sofort hinein.
Wer seine Produktregistrierung im November fertig hat, sollte deshalb bis Mai 2027 mit seiner Benannten Stelle abgleichen, ob beide Seiten dieselben Kennungen führen. Für den Beispielhersteller betrifft das nur die Artikel, an deren Konformitätsbewertung eine Benannte Stelle beteiligt war, abgeglichen je Basic UDI-DI auf der Bescheinigung.
Auch die Schnittstelle selbst bleibt in Bewegung. Solange EUDAMED nicht vollständig funktionsfähig ist, kündigt die Kommission Änderungen am DTX-Format laut Guidelines nur vier bis sechs Wochen vor einem Release an. Erst danach gilt der übliche Vorlauf von sechs Monaten, in denen alte und neue XSD parallel laufen.
Dazu kommen Produktänderungen mit neuer UDI-DI, Abkündigungen und Zertifikatsverlängerungen. Zwei Module, Vigilanz und klinische Prüfungen, sind laut Kommission noch in Entwicklung und werden ohne freiwillige Vorlaufphase verpflichtend. Der Exporter braucht deshalb eine Änderungshistorie und muss sich an neue XSD-Versionen anpassen lassen.
Fazit: Die Frist ist das kleinere Problem
Mit sauberen Stammdaten ist die EUDAMED-Registrierung bis Ende November ein überschaubares Projekt. Weil dafür im Wesentlichen der November bleibt, gilt eine klare Reihenfolge: Registrier, was da ist, notfalls über die Weboberfläche oder mit einer XML-Datei, die du einmal aus dem ERP ziehst und vor dem Upload bereinigst. Der Export aus ERP und PIM ist das Projekt für die Zeit danach, und er sollte jetzt parallel starten.
Wovon ich abrate, ist eine Insellösung, die EUDAMED bedient und sonst nichts. Setz den XML-Weg aus ERP und PIM auf, dokumentiere das Mapping, versioniere jede Übermittlung. Das trägt auch die Bescheinigungen bis Mai 2027, die Klinik-Portale und, sobald deine Produktgruppe erfasst ist, den Produktpass. Manuell über die Weboberfläche kommst du durch den November. Durch die Jahre danach kommst du nur mit Daten, die einmal stimmen und überall gleich ankommen.
