OpenPeppol hat die Peppol-SML übernommen: Warum Abfragen der alten EC-Zone unbemerkt veraltete Ergebnisse liefern

Am 2. September 2026 schloss OpenPeppol die Übernahme des Service Metadata Locator (SML) ab. Dieses DNS-basierte Verzeichnis teilt einem sendenden Access Point mit, wo die Metadaten eines Empfängers veröffentlicht sind. Bis dahin wurde die SML von der Europäischen Kommission unter edelivery.tech.ec.europa.eu gehostet. Nun wird sie von OpenPeppol unter participant.sml.prod.tech.peppol.org betrieben. Technisch ist die Änderung gering - es handelt sich lediglich um eine andere DNS-Zone. Doch sie hat eine leicht zu übersehende Nebenwirkung: Die alte Zone antwortet weiterhin, ihre Antworten sind jedoch zunehmend falsch.

Was sich wann geändert hat

• 19. März 2026 - Das Migrationsfenster öffnet sich, und die neue OpenPeppol-Zone beginnt, die EC-Zone zu spiegeln.
• 31. Mai 2026 - Frist für SMP-Anbieter, ihre Registrierungs- und Verwaltungsaufrufe auf den OpenPeppol-Endpunkt umzustellen.
• 31. August 2026 - Frist für Access Points und andere Abfrage-Clients, ihre DNS-Abfragen auf die neue Zone umzustellen.
• 2. September 2026 - Die OpenPeppol-SML wird zum Primärsystem; die EC-Umgebung ist nicht mehr Teil der Produktionskette.
• September 2026 - Die EC-Zone soll nach Ermessen der Kommission außer Betrieb genommen werden.

Warum die alte Zone nicht nur veraltet, sondern gefährlich ist

Eine außer Betrieb genommene Zone würde unübersehbar ausfallen: Jede Abfrage würde "nicht gefunden" zurückgeben, und jedes Monitoring würde dies innerhalb weniger Minuten bemerken. Die alte EC-Zone verhält sich jedoch problematischer. Sie liefert weiterhin Einträge zurück, wird von SMP-Anbietern, die ihre Migration abgeschlossen haben, aber nicht mehr aktualisiert. Aus Sicht eines Clients, der noch immer die alte Zone abfragt, geschehen unbemerkt drei Dinge:

• Teilnehmer, die nach der Umstellung über ein migriertes SMP registriert wurden, existieren nicht - die Abfrage liefert "nicht registriert" zurück;
• Teilnehmer, die von einem Anbieter zu einem anderen gewechselt sind, scheinen weiterhin bei ihrem früheren Anbieter zu sein;
• Teilnehmer, die von einem migrierten SMP abgemeldet wurden, erscheinen weiterhin als registriert.

Es tritt kein Fehler auf. Stattdessen werden die Daten für einen wachsenden Teil des Netzwerks einfach nicht mehr aktualisiert - ein SMP nach dem anderen.

Wie sich das in unseren eigenen Daten zeigte

Wir schreiben darüber, weil es uns selbst passiert ist. Unsere Zuordnung zu Anbietern und die Kennzeichnung "routebar / nicht routebar" auf jeder Teilnehmerseite basieren auf SML-Abfragen. Vom 2. bis 14. September 2026 liefen diese Abfragen noch über die alte Zone. Aufmerksam wurden wir darauf, als Michael Walther von The Invoicing Hub uns drei Beispiele schickte, bei denen unsere Seite von der Referenzabfrage auf peppol.helger.com abwich: Ein Teilnehmer wurde als nicht routebar angezeigt, obwohl er eindeutig routebar war, da er am 13. September über ein migriertes SMP registriert worden war. Zwei weitere Teilnehmer wurden nach ihrem Wechsel zu Pennylane beziehungsweise ITEMS noch mit ihrem vorherigen Anbieter angezeigt.

Am 14. September stellten wir sämtliche Abfragen auf die OpenPeppol-Zone um und lösten die Daten des Netzwerks über Nacht erneut auf. Die Zahlen vermitteln einen Eindruck davon, wie schnell sich die beiden Zonen auseinanderentwickeln:

• Von den etwa 183.000 Teilnehmern, die wir als "nicht routebar" gekennzeichnet hatten und über Nacht erneut prüften, waren 3.532 (etwa 1,9 %) tatsächlich im Netzwerk registriert. Für uns waren sie nur deshalb unsichtbar, weil ihr SMP bereits migriert war.
• Bei den Teilnehmern, die in der Woche vor der Korrektur registriert worden waren, fiel das Bild deutlich schlechter aus: In einer Stichprobe aktueller "nicht gefunden"-Ergebnisse waren 9 von 10 falsch.
• Im Tagesvergleich stieg die Zahl der Teilnehmer mit Anbieterzuordnung um etwa 39.000 - ungefähr dreimal so stark wie an einem normalen Tag. Zudem erhielten 18.800 zuvor als "unbekannt" geführte Teilnehmer eine Anbieterzuordnung. Die größten Zuwächse verzeichneten Pennylane (+8.558), Indy (+6.826), Banqup/Jefacture (+6.719), Saphety (+3.089) und Axway (+2.362). Ein Teil davon entfällt auf das gewöhnliche tägliche Wachstum, der Rest darauf, dass der Unterschied zwischen den beiden Zonen aufgeholt wurde.

Die größten Abweichungen zwischen den beiden Zonen fanden wir in unseren Daten bei SMPs, die früh migriert waren - darunter Pennylane, Jefacture (Banqup), peppolint (ITEMS), eezi, Odoo, Storecove und Myflowin. Registrierungen über SMPs, die spät migriert waren, oder über die großen nationalen SMPs waren in beiden Zonen noch identisch.

Für Leser unserer Statistiken ergeben sich daraus zwei Konsequenzen: Die Anbieterzahlen und die Werte für "nicht routebar" veränderten sich am 15. September aus technischen Gründen, nicht aufgrund organischen Wachstums oder natürlicher Abwanderung. Zudem sollten Vergleiche unserer Daten vom 2. bis 14. September mit dem Live-Netzwerk nur unter Berücksichtigung dieses Umstands vorgenommen werden.

Wenn Sie eigene Peppol-Abfragen betreiben

Wer Teilnehmerprüfungen, Monitoring oder Analysen auf Basis der SML entwickelt hat - darunter Integratoren, ERP-Anbieter, ID-Prüfdienste und Forschende -, sollte kontrollieren, welche Zone der eigene Code abfragt. Die Produktionszone lautet iso6523-actorid-upis.participant.sml.prod.tech.peppol.org; die Testzone (SMK) ist iso6523-actorid-upis.participant.sml.test.tech.peppol.org. Das Hashing der Teilnehmerkennung (Base32 von SHA-256, U-NAPTR-Eintrag) bleibt unverändert, sodass für die Umstellung lediglich eine Konfigurationszeile geändert werden muss. Eine schnelle Möglichkeit zur Überprüfung eines Ergebnisses bietet das Teilnehmerabfrage-Tool auf peppol.helger.com, das bereits die OpenPeppol-Zone abfragt.

Die Lehre daraus reicht für uns über diese eine Migration hinaus: Ein Discovery-Dienst, der weiterhin antwortet, obwohl er nicht mehr maßgeblich ist, verursacht ein Datenqualitätsproblem und kein Verfügbarkeitsproblem. Dafür ist eine andere Art der Prüfung erforderlich als ein reines Verfügbarkeitsmonitoring. Wir fragen die SML nun sofort erneut ab, sobald ein SMP einen Teilnehmer nicht mehr kennt. Außerdem aktualisieren wir jede aufgerufene Teilnehmerseite, deren Daten älter als drei Tage sind, innerhalb einer Stunde und zeigen auf jeder Teilnehmerseite das Datum der "Letzten Überprüfung" an.

Danksagung

Unser Dank gilt Michael Walther von The Invoicing Hub, der sich bereits zum zweiten Mal die Mühe gemacht hat, unsere Teilnehmerseiten mit dem Live-Netzwerk abzugleichen und uns präzise, reproduzierbare Beispiele zu schicken. Ohne diese hätten wir die zunehmenden Abweichungen erst bemerkt, wenn die Kommission die alte Zone abgeschaltet hätte.