Hoe Peppol via SML, DNS NAPTR en SMP de juiste ontvanger vindt: stap voor stap uitgelegd inclusief veelvoorkomende foutmeldingen.
De Service Metadata Publisher (SMP) is het adresboek van het Peppol-netwerk. Wanneer een Access Point (AP) een document verstuurt, gebruikt het de Participant Identifier van de ontvanger om -- via de Service Metadata Locator (SML) en het Domain Name System (DNS) -- uit te vinden bij welke SMP de ontvanger is geregistreerd, welke endpoint-URL het ontvangende AP aanroept, en welke documenttypen daar worden ondersteund. Dit artikel beschrijft de discovery-keten stap voor stap.
Peppol is een open netwerk: er is geen centrale postbus die alle documenten ontvangt en verdeelt. In plaats daarvan houdt elke gecertificeerde Service Provider een eigen SMP bij, met daarin de metadata van zijn klanten -- welke documenten zij kunnen ontvangen, via welk AP, en met welke certificaten zij ondertekenen. Het verzendende AP moet vóór elke verzending uitvinden waar het document naartoe moet, en gebruikt daarvoor de SMP van de ontvanger.
De SMP-specificatie is een Organization for the Advancement of Structured Information Standards (OASIS) -standaard. eConnect staat op de lijst van eDelivery SMP-conforme oplossingen van de Europese Commissie met een eigen implementatie.
Elke organisatie op Peppol heeft minimaal één Participant Identifier, opgebouwd uit een scheme en een value:
iso6523-actorid-upis::<scheme>:<value>
Het scheme is een code uit de Electronic Address Scheme (EAS) -codelijst -- een register van OpenPeppol met nationale en internationale identifier-systemen. De meest gebruikte EAS-codes:
iso6523-actorid-upis::0106:54441587iso6523-actorid-upis::0190:00000001820029336000iso6523-actorid-upis::9944:NL851306469B01iso6523-actorid-upis::0208:0899965307iso6523-actorid-upis::0204:991-01234-56iso6523-actorid-upis::0192:745707327iso6523-actorid-upis::0235:100123456700003iso6523-actorid-upis::0088:1548079098355Een volledig overzicht staat op docs.peppol.eu/edelivery/codelists/ en in Peppol ID en identifiers.
Het verzendende AP beantwoordt bij elk document drie vragen:
De Participant Identifier wordt MD5-gehasht en in lowercase hexadecimaal gecodeerd. De gehashte waarde wordt het meest linker label van een SML-domein, gevolgd door het Peppol-scheme en de SML-zone. Voor productie:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
In de Peppol-testomgeving staat een aparte SML-zone. Sinds maart 2026 worden voor productie en test uitsluitend NAPTR-records gepubliceerd -- de oude CNAME-records zijn verwijderd.
Het verzendende AP doet een DNS-query op het bovenstaande domein, op recordtype NAPTR (Naming Authority Pointer). Sinds 1 februari 2026 is NAPTR verplicht. De NAPTR-respons bevat een service-tag (Meta:SMP) en een regexp-veld dat naar de SMP-URL van de ontvanger wijst:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .
Resultaat: het AP weet op welke SMP-URL de ontvanger staat geregistreerd.
Met de SMP-URL bouwt het AP de specifieke metadata-URL voor deze Participant:
GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587
De SMP retourneert een ServiceGroup in XML met alle ondersteunde documenttypen. Per documenttype bevraagt het AP via een tweede request de ServiceMetadata:
GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>
De respons bevat de endpoint-URL, het transportprofiel, het proces en het PKI-certificaat van het ontvangende AP. Met deze informatie versleutelt en ondertekent C2 het document, opent een AS4-verbinding met C3 op de gevonden EndpointURI, en levert af.
Onderstaande end-to-end illustratie laat zien hoe een Nederlandse Participant Identifier (KvK-nummer) leidt tot een concrete endpoint-URL:
1. Verzender wil factuur sturen naar:
iso6523-actorid-upis::0106:54441587 (eConnect, EAS 0106 -- KvK)
2. AP verzender doet DNS NAPTR-lookup:
B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
--> SMP-URL: https://smp.econnect.eu/
3. AP verzender bevraagt SMP:
GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
--> ServiceGroup met o.a. DocumentTypeId voor NLCIUS-factuur
4. AP verzender bevraagt ServiceMetadata voor NLCIUS:
GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
--> EndpointURI: https://ap.econnect.eu/as4
--> Certificate: <X.509 / PKI-cert>
--> TransportProfile: peppol-transport-as4-v2_0
5. AP verzender bouwt SBDH met routeringsmetadata,
ondertekent en verstuurt via AS4 + TLS naar de EndpointURI.
Bij registratie in een SMP worden per organisatie capabilities per documentfamilie geconfigureerd:
invoicesselfbillinginvoiceResponseorderOnlyorderAdvancedorderResponsepintProfilesmls / mlrPer capability geldt een waarde on, off of inherited. De volledige set capabilities bepaalt welke documenttypen het verzendende AP in de SMP kan vinden -- en daarmee waarop een ontvanger feitelijk bereikbaar is.
SMP-lookups worden bij elke verzending uitgevoerd. Voor schaal en robuustheid past de eConnect-SMP een eigen caching-laag toe: lookups blijven beschikbaar -- ook als een externe SMP tijdelijk niet bereikbaar is -- door gecachte metadata te hergebruiken binnen de geldigheidsperiode. eConnect garandeert 99,99% uptime op de SMP.
Twee gelijkende termen die in de praktijk vaak worden verward:
edelivery.tech.ec.europa.eu voor productie) waarin alle Participant Identifiers worden gepubliceerd, en die naar de juiste SMP wijst. Er is één productie-SML en één test-SML; OpenPeppol neemt het beheer over van de Europese Commissie (transitie tot eind augustus 2026).Vergelijk het met DNS: de SML is het top-level telefoonboek dat verwijst naar het juiste regioboek; de SMP is dat regioboek met de feitelijke gegevens.
Naast de machine-leesbare SMP zijn er twee publieke front-ends voor handmatige opzoekingen:
Voor klanten die programmatisch willen controleren of een ontvanger bereikbaar is, biedt de eConnect Peppol Service Bus (PSB) het queryRecipientParty-endpoint dat de SMP direct bevraagt en aangeeft via welk kanaal en formaat de ontvanger bereikbaar is.
Een Participant Identifier kan slechts bij één SMP tegelijk geregistreerd zijn -- anders zou C2 niet weten waar het document heen moet. Bij overstap geldt een migratieprocedure met migratiesleutel: de huidige SMP genereert een sleutel, de nieuwe SMP gebruikt die om de registratie naadloos over te nemen. Tijdens de overgang blijft de organisatie bereikbaar; de identifier verandert niet, dus handelspartners merken niets. Zie Peppol-registratie voor de procedure bij eConnect.
SMP not found / NAPTR-resolutie faaltqueryRecipientPartyService not foundNo valid delivery optionsinvoices-capability niet geactiveerd -- zie sectie hieronderCertificate expired / invalidEndpoint not reachablequeryRecipientParty timeoutEen ontvanger kan wél vindbaar zijn op Peppol -- de NAPTR-lookup en SMP-bevraging slagen -- en tóch geen facturen kunnen ontvangen. De SMP publiceert namelijk per documenttype een capability. Het ontvangen van facturen valt onder invoices; het terugkoppelen van een business-status (BIS Invoice Response 3.0) valt onder de losse capability invoiceResponse. Dit zijn onafhankelijke registraties.
Staat een ontvanger op zijn Peppol-ID uitsluitend geregistreerd voor Invoice Response transaction 3.0 (invoiceResponse op on, invoices op off), dan vindt het verzendende AP geen invoices-endpoint in de SMP. Er is dan geen geldig bezorgpad voor een factuur, en het eConnect-platform meldt No valid delivery options bij het verzenden. De ontvanger kan via die identifier wel een Invoice Response terugsturen, maar er zelf geen factuur op ontvangen.
Belangrijk: dit is geen storing aan de kant van eConnect of de verzender -- het is een correcte weergave van wat de ontvanger in zijn eigen SMP heeft gepubliceerd.
Twee oplossingsrichtingen:
invoices) wél geregistreerd staat. Een organisatie kan meerdere identifiers registreren met per identifier eigen documenttype-capabilities.Controleer bij twijfel welke documenttypen een ontvanger publiceert via de Peppol Lookup Service of programmatisch via queryRecipientParty.
De Peppol Directory (directory.peppol.eu) is een asynchroon register dat periodiek gegevens ophaalt bij SMP's. Het kan achterlopen op de feitelijke registratiestatus. De Peppol Lookup Service (lookup.peppol.org) bevraagt de SMP rechtstreeks en geeft de actuele status. Voor troubleshooting is de Lookup Service leidend.
Een ontvanger kan in het Peppol-register staan maar uitsluitend geregistreerd zijn voor Invoice Response (capability invoiceResponse), en niet voor het ontvangen van facturen (capability invoices). Er is dan geen geldig bezorgpad voor een factuur. Controleer via queryRecipientParty of de Peppol Lookup Service welke capabilities actief zijn, en neem contact op met de ontvanger voor een alternatief aanleverpunt of een ander Peppol-ID.
Een wijziging in de feitelijke SMP-registratie is bij de volgende verzending direct werkzaam: het verzendende AP bevraagt bij elke verzending de SMP opnieuw. Externe portalen zoals directory.peppol.eu of peppolcheck.be kunnen achterlopen door hun eigen cachingstrategie. Voor de autoritatieve status is de Peppol Lookup Service of een directe SMP-bevraging via queryRecipientParty leidend.
Ja. Een organisatie kan meerdere Participant Identifiers registreren -- elk op een eigen EAS-scheme (bijvoorbeeld KvK én BTW-nummer). Per identifier kunnen eigen documenttype-capabilities worden ingesteld. Als een factuur op het ene ID wordt geweigerd met No valid delivery options, kan het de moeite waard zijn te controleren of de ontvanger een ander Peppol-ID heeft met de invoices-capability geactiveerd.
Meer over Peppol ID en identifiers