Der Service Metadata Publisher (SMP) ist das Adressbuch des Peppol-Netzwerks. Wenn ein Access Point (AP) ein Dokument versendet, verwendet er die Participant Identifier des Empfängers, um -- über den Service Metadata Locator (SML) und das Domain Name System (DNS) -- herauszufinden, bei welchem SMP der Empfänger registriert ist, welche Endpoint-URL angesprochen wird und welche Dokumenttypen unterstützt werden. Dieser Artikel beschreibt die Discovery-Kette Schritt für Schritt.

Peppol ist ein offenes Netzwerk: Es gibt keine zentrale Mailbox, die alle Dokumente empfängt und verteilt. Stattdessen betreibt jeder zertifizierte Dienstleister seinen eigenen SMP mit den Metadaten seiner Kunden -- welche Dokumente sie empfangen können, über welchen AP und mit welchen Zertifikaten sie signieren. Der sendende AP muss vor jeder Übertragung ermitteln, wohin das Dokument gesendet werden soll, und verwendet dafür den SMP des Empfängers.

Die SMP-Spezifikation ist ein Standard der Organization for the Advancement of Structured Information Standards (OASIS). eConnect ist auf der eDelivery-SMP-konformen Lösungsliste der Europäischen Kommission mit einer eigenen Implementierung aufgeführt.

Jede Organisation in Peppol hat mindestens eine Participant Identifier, aufgebaut aus einem Scheme und einem Value:

iso6523-actorid-upis::<scheme>:<value>

Das Scheme ist ein Code aus der Electronic Address Scheme (EAS)-Codeliste -- ein OpenPeppol-Register nationaler und internationaler Identifizierungssysteme. Die am häufigsten verwendeten EAS-Codes:

Eine vollständige Übersicht ist unter docs.peppol.eu/edelivery/codelists/ und in Peppol-ID und Identifikatoren verfügbar.

Der sendende AP beantwortet bei jedem Dokument drei Fragen:

1. Wo befindet sich der SMP des Empfängers? Lookup über SML / DNS NAPTR.
2. Welcher Endpoint und welches Zertifikat gehören zum gewünschten Dokumenttyp? Lookup gegen den SMP selbst.
3. Welches Peppol-Profil unterstützt der Empfänger? Die Antwort steht in der SMP-Antwort (BIS Billing V3, NLCIUS, PINT EU, usw.).

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu

B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   IN NAPTR 100 10 "U" "Meta:SMP" "!^.*$!https://smp.example.com/!" .

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587

GET https://smp.example.com/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<DocumentTypeId>

Die folgende End-to-End-Illustration zeigt, wie eine niederländische Participant Identifier (KvK-Nummer) zu einer konkreten Endpoint-URL führt:

1. Absender möchte Rechnung senden an:
   iso6523-actorid-upis::0106:54441587  (eConnect, EAS 0106 -- KvK)

2. Sender-AP führt DNS NAPTR-Lookup durch:
   B-<md5>.iso6523-actorid-upis.edelivery.tech.ec.europa.eu
   --> SMP-URL: https://smp.econnect.eu/

3. Sender-AP fragt SMP ab:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587
   --> ServiceGroup mit u.a. DocumentTypeId für NLCIUS-Rechnung

4. Sender-AP fragt ServiceMetadata für NLCIUS ab:
   GET https://smp.econnect.eu/iso6523-actorid-upis%3A%3A0106%3A54441587/services/<NLCIUS-DocumentTypeId>
   --> EndpointURI: https://ap.econnect.eu/as4
   --> Certificate: <X.509 / PKI-Zert.>
   --> TransportProfile: peppol-transport-as4-v2_0

5. Sender-AP erstellt SBDH mit Routing-Metadaten,
   signiert und sendet über AS4 + TLS an die EndpointURI.

Bei der Registrierung in einem SMP werden pro Organisation Capabilities pro Dokumentfamilie konfiguriert:

Jede Capability hat einen Wert on, off oder inherited. Der vollständige Satz an Capabilities bestimmt, welche Dokumenttypen der sendende AP im SMP finden kann -- und damit, wofür ein Empfänger tatsächlich erreichbar ist.

SMP-Lookups werden bei jeder Übertragung durchgeführt. Für Skalierung und Robustheit setzt der eConnect-SMP eine eigene Caching-Schicht ein: Lookups bleiben verfügbar -- auch wenn ein externer SMP vorübergehend nicht erreichbar ist -- indem gecachte Metadaten innerhalb der Gültigkeitsdauer wiederverwendet werden. eConnect garantiert 99,99% Uptime auf dem SMP.

Zwei ähnlich klingende Begriffe, die in der Praxis häufig verwechselt werden:

• Der SML (Service Metadata Locator) ist die zentrale DNS-Zone (edelivery.tech.ec.europa.eu für die Produktion), in der alle Participant Identifiers veröffentlicht werden und die auf den richtigen SMP verweist. Es gibt einen Produktions-SML und einen Test-SML; OpenPeppol übernimmt die Verwaltung von der Europäischen Kommission (Übergang bis Ende August 2026).
• Der SMP (Service Metadata Publisher) ist das Verzeichnis eines einzelnen Dienstleisters. Jeder SP betreibt seinen eigenen SMP für seine eigenen Kunden.

Vergleichbar mit DNS: Der SML ist das übergeordnete Telefonbuch, das auf das richtige regionale Verzeichnis verweist; der SMP ist dieses Verzeichnis mit den tatsächlichen Daten.

Neben dem maschinenlesbaren SMP gibt es zwei öffentliche Frontends für manuelle Nachschlagungen:

• Peppol Directory -- directory.peppol.eu: das öffentliche Register der Peppol-Teilnehmer mit Suchfunktion nach Organisationsname, Land und Participant ID. Asynchron und unzuverlässig für Erreichbarkeitsprüfungen: Das Directory ruft seine Daten periodisch von den SMPs ab und der Directory-Dienst ist manchmal vorübergehend nicht verfügbar. Dadurch kann eine Registrierung oder De-Registrierung verzögert -- oder gar nicht -- im Directory erscheinen. Eine Organisation kann also im Directory stehen, während der SMP-Lookup No valid delivery options / PartyId not found zurückgibt, oder umgekehrt. Verwenden Sie das Directory nicht als Beweis, dass jemand empfangen kann oder nicht.
• Peppol Lookup Service -- lookup.peppol.org, seit März 2026: fragt den SMP direkt ab und zeigt den aktuellen Publikationsstatus. Nützlich bei der Fehlerbehebung, wenn Directory und tatsächliche Registrierung auseinanderlaufen.

Für eine zuverlässige Antwort auf die Frage kann dieser Empfänger empfangen oder nicht muss eine echte SMP-Lookup durchgeführt werden -- nicht die Directory-Ansicht abfragen. Zwei öffentliche Tools führen die tatsächliche Peppol-Lookup durch (dieselbe Lookup, die der eConnect PSB ausführt):

• test.peppolautoriteit.nl/discover
• peppol.helger.com

Gelingt die Lookup in einem dieser Tools, ist der Empfänger erreichbar; schlägt sie fehl (PartyId not found / keine Delivery Options), ist der Empfänger für diesen Dokumenttyp tatsächlich nicht angeschlossen -- unabhängig davon, was das Peppol Directory anzeigt. Programmgesteuert liefert queryRecipientParty des PSB dasselbe, autoritative Ergebnis.

Im Peppol Directory zeigt das Feld „additional information“ den Namen des registrierenden Dienstleisters -- bei eConnect-PSB-Registrierungen steht hier „eConnect“. Dies sind SMP-Registrar-Metadaten des registrierenden SP und gehören nicht zur per Teilnehmer konfigurierbaren businessCard. Pro-Teilnehmer konfigurierbare Felder laufen über businessCard.names; das Feld „additional information“ liegt außerhalb dieses Bereichs und ist daher nicht pro Teilnehmer konfigurierbar -- auch nicht für White-Label-Partner, die über den eConnect-PSB-Endpoint registrieren.

Für Kunden, die programmgesteuert prüfen möchten, ob ein Empfänger erreichbar ist, bietet der eConnect Peppol Service Bus (PSB) den queryRecipientParty-Endpoint, der den SMP direkt abfragt und angibt, über welchen Kanal und in welchem Format der Empfänger erreichbar ist.

Eine Participant Identifier kann nur bei einem SMP gleichzeitig registriert sein -- andernfalls wüsste C2 nicht, wohin das Dokument gesendet werden soll. Bei einem Wechsel gilt ein Migrationsverfahren mit einem Migrationsschlüssel: Der aktuelle SMP erzeugt einen Schlüssel, und der neue SMP verwendet diesen, um die Registrierung nahtlos zu übernehmen. Während des Übergangs bleibt die Organisation erreichbar; der Identifier ändert sich nicht, sodass Handelspartner nichts bemerken. Siehe Peppol-Registrierung für das Verfahren bei eConnect.

Ein Empfänger kann in Peppol auffindbar sein -- die NAPTR-Lookup und SMP-Abfrage gelingen -- und dennoch keine Rechnungen empfangen können. Der SMP publiziert nämlich pro Dokumenttyp eine Capability. Das Empfangen von Rechnungen fällt unter invoices; das Zurücksenden eines Business-Status (BIS Invoice Response 3.0) fällt unter die separate Capability invoiceResponse. Dies sind unabhängige Registrierungen.

Ist ein Empfänger auf seiner Peppol-ID ausschließlich für Invoice Response transaction 3.0 registriert (invoiceResponse auf on, invoices auf off), findet der sendende AP keinen invoices-Endpoint im SMP. Es gibt dann keinen gültigen Lieferpfad für eine Rechnung, und die eConnect-Plattform meldet No valid delivery options beim Versenden. Der Empfänger kann über diese Kennung zwar einen Invoice Response zurücksenden, aber selbst keine Rechnung darauf empfangen.

Zwei Lösungswege:

1. Alternativer Übermittlungsweg: Bitten Sie den Kunden, den Empfänger zu kontaktieren und zu fragen, über welchen Kanal (E-Mail oder Lieferantenportal) die Rechnung übermittelt werden kann.
2. Andere Peppol-ID: Prüfen Sie, ob der Empfänger eine zweite Peppol-ID hat, auf der der Rechnungsdokumenttyp (invoices) registriert ist. Eine Organisation kann mehrere Identifiers mit je eigenen Dokumenttyp-Capabilities registrieren.

Bei Zweifeln prüfen Sie, welche Dokumenttypen ein Empfänger über den Peppol Lookup Service oder programmgesteuert über queryRecipientParty publiziert.