OpenPeppol heeft de Peppol SML overgenomen: waarom zoekopdrachten in de oude EC-zone ongemerkt verouderde resultaten opleveren

Op 2 september 2026 heeft OpenPeppol de overname afgerond van de Service Metadata Locator (SML), de op DNS gebaseerde directory die een verzendend Access Point vertelt waar de metadata van een ontvanger zijn gepubliceerd. Tot dan toe werd de SML door de Europese Commissie gehost onder edelivery.tech.ec.europa.eu. De dienst wordt nu door OpenPeppol beheerd onder participant.sml.prod.tech.peppol.org. Technisch gezien is de wijziging klein - er wordt een andere DNS-zone gebruikt - maar er is een neveneffect dat gemakkelijk over het hoofd wordt gezien: de oude zone reageert nog steeds, terwijl de antwoorden steeds vaker onjuist zijn.

Wat is er veranderd en wanneer?

• 19 maart 2026 - het migratievenster wordt geopend; de nieuwe OpenPeppol-zone begint de EC-zone te spiegelen.
• 31 mei 2026 - uiterste datum waarop SMP-providers hun registratie- en beheeraanroepen naar het OpenPeppol-endpoint moeten hebben verplaatst.
• 31 augustus 2026 - uiterste datum waarop Access Points en andere lookupclients hun DNS-zoekopdrachten naar de nieuwe zone moeten hebben omgeschakeld.
• 2 september 2026 - de OpenPeppol SML wordt het primaire systeem; de EC-omgeving maakt niet langer deel uit van de productieketen.
• September 2026 - de EC-zone wordt naar goeddunken van de Commissie buiten gebruik gesteld.

Waarom de oude zone niet alleen verouderd, maar ook gevaarlijk is

Een buiten gebruik gestelde zone zou luid en duidelijk falen: elke zoekopdracht zou "niet gevonden" opleveren en elk monitoringsysteem zou dat binnen enkele minuten opmerken. De oude EC-zone doet iets ergers. Ze blijft records teruggeven, maar SMP-providers die hun migratie hebben voltooid, schrijven er niet langer gegevens naartoe. Voor een client die nog steeds de oude zone raadpleegt, gebeuren daardoor ongemerkt drie dingen:

• deelnemers die na de omschakeling via een gemigreerde SMP zijn geregistreerd, bestaan niet - de zoekopdracht levert "niet geregistreerd" op;
• deelnemers die van de ene provider naar de andere zijn overgestapt, lijken nog bij hun oude provider te zitten;
• deelnemers die door een gemigreerde SMP zijn uitgeschreven, lijken nog steeds geregistreerd.

Er verschijnt geen foutmelding. Voor een groeiend deel van het netwerk worden de gegevens simpelweg niet meer bijgewerkt, één SMP tegelijk.

Hoe dit er in onze eigen gegevens uitzag

We schrijven hierover omdat het ons zelf is overkomen. De toewijzing aan een provider en de status "routeerbaar / niet routeerbaar" op elke deelnemerspagina worden bij ons afgeleid van SML-zoekopdrachten. Tussen 2 en 14 september 2026 gingen die zoekopdrachten nog steeds naar de oude zone. We ontdekten dit toen Michael Walther van The Invoicing Hub ons drie voorbeelden stuurde waarbij onze pagina afweek van de referentiezoekopdracht op peppol.helger.com: één deelnemer werd als niet routeerbaar weergegeven terwijl die dat duidelijk wel was (op 13 september geregistreerd via een gemigreerde SMP), en twee deelnemers werden na hun overstap naar respectievelijk Pennylane en ITEMS nog met hun vorige provider weergegeven.

Op 14 september hebben we alle zoekopdrachten omgeschakeld naar de OpenPeppol-zone en het netwerk 's nachts volledig opnieuw opgezocht. De cijfers laten zien hoe snel de twee zones uit elkaar gaan lopen:

• Van de ongeveer 183.000 deelnemers die we als "niet routeerbaar" hadden gemarkeerd en 's nachts opnieuw controleerden, bleken er 3.532 (ongeveer 1,9 %) wel degelijk in het netwerk geregistreerd te zijn. Ze waren voor ons alleen onzichtbaar omdat hun SMP al was gemigreerd.
• Bij deelnemers die in de week vóór de correctie waren geregistreerd, was het beeld veel slechter: in een steekproef van recente resultaten met "niet gevonden" waren 9 van de 10 onjuist.
• Van dag tot dag steeg het aantal deelnemers dat aan een provider was toegewezen met ongeveer 39.000 - ruwweg drie keer zoveel als op een normale dag - en kregen 18.800 deelnemers die als "onbekend" vermeld stonden alsnog een provider toegewezen. De grootste stijgingen waren te zien bij Pennylane (+8.558), Indy (+6.826), Banqup/Jefacture (+6.719), Saphety (+3.089) en Axway (+2.362). Een deel daarvan is normale dagelijkse groei; de rest komt doordat de twee zones weer met elkaar in de pas zijn gebracht.

De SMP's waarbij de twee zones in onze gegevens het sterkst van elkaar afweken, waren de partijen die vroeg waren gemigreerd, waaronder Pennylane, Jefacture (Banqup), peppolint (ITEMS), eezi, Odoo, Storecove en Myflowin. Registraties via SMP's die laat migreerden of via de grote nationale SMP's waren in beide zones nog steeds identiek.

Dit heeft twee gevolgen voor lezers van onze statistieken: de aantallen per provider en de cijfers voor "niet routeerbaar" veranderden op 15 september om technische redenen, niet door organische groei of klantverloop; daarnaast moet bij elke vergelijking van onze gegevens uit de periode 2-14 september met het actuele netwerk rekening worden gehouden met deze situatie.

Als u zelf Peppol-zoekopdrachten uitvoert

Iedereen die deelnemersverificatie, monitoring of analyses op de SML heeft gebouwd - integrators, ERP-leveranciers, aanbieders van ID-controles en onderzoekers - doet er goed aan te controleren welke zone door de code wordt geraadpleegd. De productiezone is iso6523-actorid-upis.participant.sml.prod.tech.peppol.org; de testzone (SMK) is iso6523-actorid-upis.participant.sml.test.tech.peppol.org. De hashing van de deelnemersidentificatie (Base32 van SHA-256, U-NAPTR-record) is niet gewijzigd, waardoor de omschakeling slechts een configuratiewijziging van één regel vergt. Een snelle manier om een resultaat te controleren is de tool voor het opzoeken van deelnemers op peppol.helger.com, die de OpenPeppol-zone al raadpleegt.

De les die wij hieruit trekken, reikt verder dan deze ene migratie: een discoveryservice die antwoorden blijft geven nadat deze niet langer gezaghebbend is, vormt een probleem voor de gegevenskwaliteit en niet voor de beschikbaarheid. Daarvoor is een ander soort controle nodig dan uptimemonitoring. Wij raadplegen de SML nu onmiddellijk opnieuw zodra een SMP een deelnemer niet meer kent, vernieuwen binnen een uur elke geopende deelnemerspagina waarvan de gegevens ouder zijn dan drie dagen, en tonen op elke deelnemerspagina een datum bij "Laatst geverifieerd".

Dankwoord

Onze dank gaat uit naar Michael Walther van The Invoicing Hub, die voor de tweede keer de moeite heeft genomen om onze deelnemerspagina's met het actuele netwerk te vergelijken en ons nauwkeurige, reproduceerbare voorbeelden te sturen. Zonder die voorbeelden zouden we de groeiende afwijking pas hebben opgemerkt zodra de Commissie de oude zone had uitgeschakeld.