Die PSB ist ein zertifizierter Peppol Access Point und SMP (Service Metadata Publisher). Über die API konfigurieren Sie, welche Dokumenttypen eine Organisation empfangen kann, veröffentlichen Unternehmensdaten im Peppol Directory und verwalten die SMP-Registrierung. Dieser Artikel behandelt den technischen Hintergrund und die API-Endpoints, die Sie dafür verwenden.

Peppol verwendet ein 4-Corner-Modell: Der Absender (C1) sendet über seinen Access Point (C2) ein Dokument an den Access Point des Empfängers (C3), der es an den Empfänger (C4) weiterleitet. Das Routing erfolgt über zwei zentrale Komponenten:

• SML (Service Metadata Locator): ein zentrales DNS-Register, das auf den richtigen SMP des Empfängers verweist
• SMP (Service Metadata Publisher): enthält die Metadaten eines Empfängers, welche Dokumente er empfangen kann und über welchen Access Point

Wenn Sie über die PSB eine Rechnung versenden, führt die PSB automatisch einen SML/SMP-Lookup durch, um den richtigen Access Point des Empfängers zu finden. Als Integrator müssen Sie dies nicht selbst tun.

Die Peppol-Infrastruktur wird aktiv weiterentwickelt. Für Integratoren, die die PSB API nutzen, hat dies keine Auswirkungen: die PSB führt SML/SMP-Lookups automatisch durch. Nachfolgend die aktuellen Entwicklungen zur Information.

SML-Insourcing. OpenPeppol übernimmt die Verwaltung des SML von der Europäischen Kommission (DG DIGIT). Das Migrationsfenster wurde am 19. März 2026 geöffnet. Es gelten zwei separate Fristen: die Frist für SMP-Registrierungen ist der 31. Mai 2026, der Migrationszeitraum für AP-Lookup (DNS-Auflösung) wurde bis zum 31. August 2026 verlängert. OpenPeppol bespricht mit der Europäischen Kommission, ob auch die SMP-Registrierungsfrist verlängert werden kann. Für API-Integratoren ändert sich nichts an Endpoints oder Lookups: die PSB wickelt die Migration intern ab.

CNAME-zu-NAPTR-Migration. Die Migration von DNS-CNAME-Records zu NAPTR-Records für SML-Lookups wurde im März 2026 abgeschlossen. NAPTR ist seit dem 1. Februar 2026 verpflichtend. Die alten CNAME-Records wurden aus dem SMK-Testnetzwerk (4. März 2026) und dem SML-Produktionsnetzwerk (11. März 2026) entfernt. Dies ist eine interne DNS-Änderung in der Peppol-Infrastruktur. Die PSB verwendet bereits NAPTR und es sind keine Anpassungen an Ihrer Integration erforderlich.

PKI-G3-Migration. OpenPeppol bereitet den Übergang von PKI Generation 2 (G2) zu Generation 3 (G3) Zertifikaten vor. G3-Zertifikate werden für die gegenseitige Kommunikation zwischen Access Points verwendet. Das Peppol Testbed unterstützt seit März 2026 sowohl G2- als auch G3-Zertifikate, damit Service Provider vorab testen können. Ein verpflichtendes Übergangsdatum wurde noch nicht veröffentlicht. Für API-Integratoren ändert sich nichts: die PSB wickelt die Zertifikatserneuerung intern ab.

Peppol unterstützt neben Rechnungen auch logistische Dokumenttypen über die Peppol-Logistics-Spezifikation. Version 1.2 ist seit dem 16. März 2026 verpflichtend. Release 1.3 befindet sich bis zum 15. April 2026 im Member Review, mit voraussichtlicher Veröffentlichung am 18. Mai 2026.

Unterstützte Logistikdokumente:

• Despatch Advice (Lieferschein)
• Weight Statement
• Transport Execution Plan
• Waybill

Neue Funktionen in Release 1.3:

• ProductTraceID mit schemeID für ItemInstance
• DespatchAdviceTypeCode um Werte zur Anwendungsfall-Identifikation erweitert (101, 102, 112, 203-211, 303-311)
• DocumentStatusCode mit neuem Wert „55 - Notification only" für Änderungen nach Rechnungsstellung
• Waste Declaration Number als AdditionalItemProperty
• Neue Codeliste ProductTraceIDschemeIDCode

Release 1.3 verarbeitet die RFCs LLC-27 bis LLC-35, einschließlich ItemInstance-Alignment, Updates für Nicht-Rechnungsstellung und Sub-Treatment-Codes für Abfall.

Bei der Registrierung einer Party im eConnect SMP bestimmen Sie über Capabilities, welche Dokumenttypen diese Party empfangen kann. Jede Capability hat drei mögliche Zustände:

Der empfohlene Wert für neue Registrierungen ist inherited, es sei denn, eine Party muss ausdrücklich vom Standard abweichen.

Capabilities werden über den Peppol-Config-Endpoint konfiguriert:

PUT /api/v1/peppol/config/party/{partyId}

Im Request Body geben Sie den gewünschten Zustand pro Capability an. Ein Beispiel:

{
  "capabilities": {
    "invoices": "on",
    "selfbilling": "inherited",
    "invoiceResponse": "on",
    "orderOnly": "on",
    "orderAdvanced": "off"
  }
}

Das Peppol Directory ist das öffentliche Register aller Peppol-Teilnehmer. Durch die Veröffentlichung einer businessCard wird eine Party im Directory auffindbar. Die businessCard enthält:

Die businessCard wird über den Enrollment-Endpoint oder über die SMP-Konfiguration veröffentlicht. Nach der Veröffentlichung ist die Organisation unter directory.peppol.eu auffindbar.

Die PSB-API leitet keine Felder aus einem verknüpften Handelsregister ab. Unabhängig vom Identifier-Schema (KvK 0106, USt 9944, OIN 0190, GLN 0088 oder ein anderes) müssen sowohl names als auch ein address mit Ländercode explizit in der Payload enthalten sein. Ein Beispiel für eine korrekt konfigurierte businessCard:

"businessCard": {
  "names": {
    "value": "eVerbinding, eConnect",
    "state": "on",
    "description": "Business names."
  },
  "address": {
    "value": "Pelmolenlaan 16A, 3447 GW, Woerden, NL",
    "state": "on",
    "description": "Geographic information."
  },
  "emailAddress": {
    "value": "techsupport@econnect.eu",
    "state": "on",
    "description": "Technical contact"
  },
  "state": "on"
}

Der Ländercode (im Beispiel oben NL am Ende des address-Felds) muss explizit angegeben sein.

Diese Fehlermeldung ist diagnostisch eindeutig: In der übermittelten Payload fehlen names, oder das address-Feld enthält keinen Ländercode. Die Lösung besteht immer darin, diese Felder explizit in der businessCard-Payload zu ergänzen, und nicht in einer Änderung auf einer anderen Ebene (Party, Identifier, SMP-Capabilities). Die Meldung tritt in der Praxis relativ häufig bei der GLN-Integration (0088) auf, da GLN-Integrationspartner seltener ein Template verwenden, das diese Felder standardmäßig mitsendet. Die PSB zeigt für GLN kein anderes Verhalten als für andere Schemata.

Die vorherige Prüfung, ob ein Empfänger über Peppol erreichbar ist, erfolgt pro Dokumenttyp und über einen Advanced-Lookup-Endpoint:

Die Antwort zeigt die verfügbaren Kanäle, den ausgewählten Access Point und die unterstützten Dokumenttypen. Verwenden Sie diese Endpoints, um vorab zu validieren, ob eine Zustellung erfolgreich sein wird. Sie sind in allen Paketen unbegrenzt verfügbar (proaktive Routenerkennung/Discovery).

Hinweis: Bei einem SML/SMP-Mismatch am deliveryOption-Endpoint schlägt der Aufruf nicht sofort fehl. Es gibt kein Fail-fast-Handling in der Produktion: Der Aufruf läuft weiter und gibt erst nach etwa 30 Sekunden einen Timeout zurück. Berücksichtigen Sie dies in der Fehlerbehandlung Ihrer Integration.

Jede Party im SMP wird über einen Identifikator mit einem schemeID identifiziert. Die am häufigsten verwendeten Schemas:

Die PSB API akzeptiert sowohl die numerische schemeID als auch den Buchstabencode: 9925:BE0835689642 ist gleichbedeutend mit BE:VAT:BE0835689642. Bei externen Lookup-Tools (wie dem SMP-Lookup) müssen die offiziellen numerischen schemeIDs verwendet werden.

Eine Party kann mehrere Identifikatoren haben, aber jede Rechnung darf nur eine EndpointID enthalten.

In Belgien werden zwei Identifikatortypen für Peppol verwendet. Die Unternehmensnummer (KBO, schemeID 0208) ist die primäre Identifikationsnummer und für den Peppol-Empfang verpflichtend. Die Registrierung über die Umsatzsteuer-ID (schemeID 9925) ist optional, weshalb die Suche nach einer belgischen Organisation über die Unternehmensnummer häufiger erfolgreich ist als über die Umsatzsteuer-ID.

Die Unternehmensnummer lässt sich aus der Umsatzsteuer-ID ableiten, indem das Länderkennzeichen-Präfix (BE) entfernt wird. Beispiel: Umsatzsteuer-ID BE0835689642 entspricht der Unternehmensnummer 0835689642.

Beim Versenden eines Dokuments extrahiert die PSB die Peppol-ID aus dem EndpointID-Element in der XML. Dieses Element bestimmt, an welchen Empfänger das Dokument geroutet wird. Wenn die EndpointID fehlt oder falsch ausgefüllt ist, ist das Dokument nicht valide und erhält den Status InvoiceSentError.

Eine fehlerhafte XML wird nicht automatisch erneut versucht. Die Korrektur liegt beim Quellsystem (dem Softwarepaket, das die Rechnung generiert), nicht bei der PSB. Prüfen Sie vorab über queryRecipientParty, ob der Empfänger im Peppol-Netzwerk erreichbar ist.

Möchten Sie den gesamten Registrierungsprozess automatisieren? Lesen Sie den Artikel über die Enrollment API, mit der Sie Registrierung, Capabilities und Hooks in einem einzigen API-Aufruf konfigurieren.

• Peppol-Registrierung über die API (Enrollment)
• Migration zu oder von eConnect
• Multi-Channel-Zustellung konfigurieren
• Übersicht: die Procurement Service Bus (PSB)
• Was ist Peppol und wie funktioniert das Netzwerk?
• Auf Peppol registrieren (Plattform)