SMP-Capabilities, Peppol Directory und businessCard über die PSB API konfigurieren.
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:
C1 Absender
C2 Access Point Absender
SML / SMP
C3 Access Point Empfänger
C4 Empfänger
SML/SMP Lookup
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. Version 1.3 ist seit dem 24. August 2026 verpflichtend.
Unterstützte Logistikdokumente:
Neue Funktionen in Release 1.3:
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:
onoffinheritedDer empfohlene Wert für neue Registrierungen ist inherited, es sei denn, eine Party muss ausdrücklich vom Standard abweichen.
invoicesselfbillinginvoice_bisv2reviewsinvoiceResponseordersorderOnlyorderAdvancedorderResponseorderResponseAdvancedCapabilities 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.
Both name(s) and country code are required when adding a business cardDiese 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:
POST /api/v1/{partyId}/salesInvoice/queryRecipientParty["0106:..."] oder { "partyIds": [...], "metaAttributes": {...} }; optional ?preferredDocumentTypeId, ?includeOptionsPOST /api/v1/{partyId}/purchaseOrder/queryRecipientParty?documentFamily=OrderGET /api/v1/peppol/deliveryOption?partyIds=...&documentFamily=...&isCredit=...partyId, documentTypeId, processId, protocol (As2/As4), url, certificateDie 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.
Im Peppol-Netzwerk verweist eine participantId in der SML auf genau eine SMP. Über einen Redirect-Datensatz in der SMP können bestimmte Kombinationen aus Dokumenttyp und Prozess-Identifier an eine sekundäre SMP weitergeleitet werden. Peppol unterstützt nur eine Redirect-Ebene: ein Redirect-Ziel darf selbst keinen Redirect enthalten.
Alternative Quellen für SMP-Lookups: peppolautoriteit.nl/discover (NPa), peppol.helger.com und directory.peppol.eu (nicht vollständig).
Jede Party im SMP wird über einen Identifikator mit einem schemeID identifiziert. Die am häufigsten verwendeten Schemas:
01060106:1234567801900190:0000000123456789000099449944:NL123456789B010208BE:EN0208:01234567899925BE:VAT9925:BE0835689642 (auch BE1xxxxxxxxx ist seit 2025 gültig)00880088:1234567890123Die 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.
NLCIUS-Validierungsregel, die verlangt, dass die schemeID der CompanyID den Wert 0190 (OIN) hat, wenn der Empfänger eine Behörde ist. Auf der Plattform müssen die Organisations-ID und "Senden über" denselben Identifier-Typ verwenden. Eine Abweichung führt zu einem Validierungsfehler am Dokument.
Wenn ein Lieferant meldet, dass eine Rechnung bei eConnect als Access Point zugestellt wurde, der Empfänger aber angibt, nichts erhalten zu haben, läuft die Diagnose auf Empfängerseite über die returnedMessageId.
Die returnedMessageId ist eine ID, die eConnect erzeugt, sobald das Access Point ein Dokument auf AS4-Ebene annimmt oder ablehnt. Sie hat in der Regel die Form GUID@econnect.eu. Mit dieser ID kann der Support die Rechnung im System nachschlagen und den Verarbeitungspfad weiterverfolgen.
Häufigste Ursachen, dass ein Dokument vom sendenden AP als "zugestellt" gilt, aber den Empfänger nicht erreicht:
Support-Pfad: mit der returnedMessageId kann der Support nahezu alle Dokumente über die Management API finden. Gelingt die Suche nicht, schaltet der Support TechSupport ein.
Mit on schalten Sie einen Dokumenttyp für eine bestimmte Party explizit ein, mit off explizit aus. Der Wert inherited bedeutet, dass die Party die Standardkonfiguration der Organisation übernimmt. Für neue Registrierungen ist inherited der empfohlene Wert, sofern eine Party nicht gezielt abweichen muss.
Nein. Die PSB führt SML/SMP-Lookups beim Versand von Dokumenten automatisch aus. Als Integrator brauchen Sie keine direkte Interaktion mit SML oder SMP. Auch bei Infrastrukturänderungen (etwa der CNAME-zu-NAPTR-Migration oder dem SML-Insourcing) ändert sich an Ihrer Integration nichts.
Eine businessCard ist nicht Pflicht, aber empfohlen. Ohne businessCard ist die Party über Peppol erreichbar (die SMP-Registrierung ist aktiv), aber nicht im Peppol Directory unter directory.peppol.eu auffindbar. Veröffentlichen Sie eine businessCard, um die Sichtbarkeit Ihrer Organisation zu erhöhen.
Die PSB-API leitet keine Werte aus einem verknüpften Handelsregister ab. Unabhängig vom Identifier-Schema (Handelskammer, USt-IdNr., OIN, GLN) müssen Sie bei jeder businessCard-Veröffentlichung sowohl names als auch eine address mit Ländercode explizit mitsenden. Die Meldung weist immer auf ein fehlendes names-Feld oder eine address ohne Ländercode hin. Die Korrektur ist das Ergänzen dieser Felder in der businessCard-Payload; Änderungen auf Party-, Identifier- oder SMP-Capability-Ebene beheben sie nicht.
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.
SMP-Endpoints ansehen