Peppol-Entwicklerleitfaden: BIS Billing, SMP-Abfrage, AS4 und Antworten

Peppol ist ein Vier-Ecken-Netzwerk: Die Software des Senders (Ecke 1) übergibt ein Dokument an ihren Access Point (Ecke 2), der den Access Point des Empfängers (Ecke 3) über eine DNS- und SMP-Abfrage ermittelt und per AS4 zustellt; Ecke 3 reicht es an die Software des Empfängers (Ecke 4) weiter. Für einen Entwickler bedeutet das drei getrennte Probleme — ein Peppol-BIS-Billing-3.0-Dokument erzeugen, es mit der richtigen Teilnehmerkennung adressieren und einen akkreditierten Access-Point-Anbieter finden, der es befördert. KRONENWERK löst die ersten beiden selbst und delegiert das dritte an Storecove, einen akkreditierten Access-Point-Anbieter.

BIS Billing 3.0 ist EN 16931 mit den Einschränkungen von Peppol

Peppol BIS Billing 3.0 ist eine Core Invoice Usage Specification (CIUS) der EN 16931: Jedes Dokument, das dem BIS entspricht, entspricht auch der europäischen Norm, und das BIS ergänzt Anforderungen, die das Netzwerk zum Routen und Verarbeiten einer Rechnung braucht. Die aktuelle Veröffentlichung zum Zeitpunkt des Lesens ist Version 3.0.21 (Release Mai 2026). Sie bindet das semantische Modell an UBL 2.1 Invoice und CreditNote; CII wird auf Peppol für die Rechnungsstellung nicht verwendet.

Die Kennungen, die aus einer UBL-Datei eine Peppol-BIS-Rechnung machen, sind feste Zeichenketten:

Über die Kernregeln hinaus verlangt das BIS die elektronischen Adressen von Verkäufer und Käufer (cbc:EndpointID mit einer schemeID), eine Käuferreferenz oder Bestellreferenz, Zahlungsmittel mit einem Code und eine Handvoll Formatierungsvorgaben. Diese werden vom Peppol-Schematron (PEPPOL-EN16931-UBL.sch) als Regeln namens PEPPOL-EN16931-Rxxx durchgesetzt, zusätzlich zu den CEN-Regeln (CEN-EN16931-UBL.sch). Die Kernregeln selbst werden im EN-16931-Entwicklerleitfaden erklärt.

Teilnehmerkennungen

Ein Peppol-Teilnehmer wird über ein Schema und einen Wert adressiert, geschrieben als schema:wert — zum Beispiel 0208:0123456789 für eine belgische Unternehmensnummer oder 0204: gefolgt von einer Leitweg-ID für einen deutschen öffentlichen Auftraggeber. Die Schemacodes stammen aus der ISO-6523-Liste der International Code Designators, wie sie in der Policy for use of Identifiers von OpenPeppol gepflegt wird (Version 4.4.0, gültig ab dem 1. November 2025 zum Zeitpunkt des Lesens). Dieselbe Kennung erscheint an drei Stellen, und sie müssen übereinstimmen:

1. Im UBL-Dokument als cac:AccountingCustomerParty/cac:Party/cbc:EndpointID schemeID="0208" (BT-49) und das Gegenstück für den Verkäufer (BT-34).
2. Im Umschlag (SBDH) als Sender- und Empfängerkennung, mit dem Kennungsschema iso6523-actorid-upis.
3. Im SMP-Eintrag des Empfängers, wo die Abfrage stattfindet.

Welches Schema ein bestimmtes Unternehmen verwendet, hängt von seinem Land und davon ab, was es registriert hat. Belgien registriert unter 0208 (Unternehmensnummer), der deutsche öffentliche Sektor unter 0204, und USt-basierte Schemata wie 9925 (BE:VAT) oder 9930 (DE:VAT) existieren daneben. Kennungsschemata, ihre Formate und wie Sie die registrierte Kennung eines Partners finden, behandelt Peppol-Kennungen; das kostenlose Peppol-Kennungs-Werkzeug prüft das Format eines Werts.

Discovery: SML, DNS und SMP

Peppol hat kein zentrales Verzeichnis, das ein Sender abfragt. Der sendende Access Point ermittelt den Endpunkt des Empfängers dynamisch:

1. Die Teilnehmerkennung hashen. Die aktuelle SML-Spezifikation (1.3.0) verwendet einen U-NAPTR-Eintrag: Der Kennungswert wird in Kleinbuchstaben umgewandelt, mit SHA-256 gehasht, Base32-kodiert unter Entfernung nachgestellter „=“ und dem Schema und der SML-Zone vorangestellt. Die ältere CNAME-Form mit MD5-Hash und dem Präfix „B-“ wurde im von der Kommission betriebenen SML bei einer Bereinigung im Februar/März 2026 entfernt.
2. In der SML-Zone auflösen. Der Service Metadata Locator ist eine DNS-Zone, die jeden gehashten Teilnehmer auf den SMP abbildet, der seine Metadaten hostet. Die NAPTR-Antwort enthält die URL des SMP.
3. Den SMP abfragen. Der Service Metadata Publisher beantwortet zwei REST-Aufrufe: GET /{participantId} listet die Dokumenttypen auf, die der Teilnehmer empfangen kann, und GET /{participantId}/services/{documentTypeId} liefert den Endpunkt für einen davon — die AS4-URL, die Transportprofilkennung, das Zertifikat des Empfängers und die Prozesskennung. Die geltende SMP-Spezifikation ist 1.4.0.
4. Zustellen. Der sendende Access Point verschlüsselt und signiert die Nachricht für dieses Zertifikat und sendet sie an diese URL.

Der SML ist 2026 umgezogen. OpenPeppol hat den Locator von der eDelivery-Infrastruktur der Kommission ins eigene Haus geholt: Die Produktion wechselte von edelivery.tech.ec.europa.eu zu api.sml.prod.tech.peppol.org, und der Test-SML (früher SMK, acc.edelivery.tech.ec.europa.eu) zu api.sml.test.tech.peppol.org. SMP-Betreiber mussten ihre Registrierungen bis zum 31. Mai 2026 umziehen, und Access Points mussten ihre DNS-Abfragen bis zum 31. August 2026 umstellen. Teilnehmerabfragen werden unter iso6523-actorid-upis.participant.sml.prod.tech.peppol.org (Produktion) und …sml.test.tech.peppol.org (Test) aufgelöst.

Transport: AS4 über einen Access Point

Nachrichten laufen zwischen Access Points über das Peppol-AS4-Profil (Version 2.0.3, gültig ab dem 22. April 2024), einen ebMS3/AS4-Austausch mit Signatur und Verschlüsselung auf Basis von Zertifikaten der OpenPeppol-PKI. Nur akkreditierte Access Points besitzen diese Zertifikate: Um einer zu werden, unterzeichnet eine Organisation das Peppol Transport Infrastructure Agreement, besteht Konformitätstests und arbeitet nach den Service-Level-Regeln von OpenPeppol. Deshalb nutzen die meisten Softwareanbieter, KRONENWERK eingeschlossen, einen Anbieter, statt einen eigenen Access Point zu betreiben.

Das Geschäftsdokument wird in einen Peppol Business Message Envelope (SBDH, Spezifikation 2.0.2, in Kraft seit dem 2. Juli 2026) verpackt, der Sender, Empfänger, Dokumenttypkennung, Prozesskennung und eine Instanzkennung trägt. Der Umschlag ist das, worauf der Access Point routet; das UBL darin ist das, was die Software des Empfängers liest. Wenn Sie die API eines Access-Point-Anbieters integrieren, baut der Anbieter den Umschlag in der Regel aus wenigen Parametern, und Sie liefern nur das UBL und die Empfängerkennung.

Validierung und die Testumgebung

Ein sendender Access Point validiert jedes Dokument vor der Übertragung gegen das Peppol-Schematron und lehnt Fehlschläge ab. Validieren Sie zuerst auf Ihrer Seite mit denselben Artefakten: CEN-EN16931-UBL.sch und PEPPOL-EN16931-UBL.sch, herunterladbar aus der BIS-Billing-3.0-Dokumentation, ausgeführt mit einem beliebigen Schematron-Prozessor oder mit dem Peppol-Szenario des KoSIT-Validators. Die Regelkennungen PEPPOL-EN16931-R001 und folgende benennen die Peppol-spezifischen Fehler; BR-xx und BR-CO-xx die Kernfehler.

Für Ende-zu-Ende-Tests betreibt OpenPeppol ein Testnetzwerk mit eigenem SML (dem T-SML), eigener PKI und Test-Teilnehmerkennungen. Access-Point-Anbieter stellen es als Sandbox bereit: Dort gesendete Dokumente werden nur an Testteilnehmer zugestellt und erreichen nie einen echten Empfänger. Das Peppol-Testnetzwerk ist der richtige Ort, um Ihre Kennungsbehandlung und Ihren Umschlag vor der ersten produktiven Rechnung zu beweisen; ein Dokument, das validiert, aber an eine Kennung adressiert ist, die der Empfänger nie registriert hat, scheitert erst bei der Abfrage — und genau das zeigt Ihnen das Testnetzwerk.

Antworten: Nachrichten- und Rechnungsebene

Es gibt zwei Arten von Rückmeldung, und ein Sender sollte beide verarbeiten.

Transportquittung

Die signierte AS4-Quittung des empfangenden Access Points beweist, dass die Nachricht Ecke 3 erreicht hat. Sie sagt nichts über den Inhalt aus.

Message Level Response (MLR, BIS 3.0)

Eine UBL-ApplicationResponse, die der empfangende Access Point oder Empfänger an den Sender zurückschickt und das Ergebnis der Validierung meldet: AP angenommen (keine fatalen Fehler), RE abgelehnt (Konformitätsverstöße, Verarbeitung stoppt), AB bestätigt ohne Validierung. Ein Empfänger, der fatale Fehler findet, sollte per MLR ablehnen, auch wenn keine angefordert wurde.

Invoice Response (BIS 3.2)

Eine fachliche Antwort des Käufers — angenommen, abgelehnt, bezahlt, bedingt angenommen —, die im Profil „Rechnungsstellung mit Antwort“ (billing:02) verwendet wird. Optional und uneinheitlich verbreitet.

In der Praxis: Behandeln Sie eine fehlende AS4-Quittung als nicht zugestellt, ein MLR RE als Dokumentfehler, der zu beheben und erneut zu senden ist, und eine Invoice Response als Geschäftsereignis, das einem Menschen angezeigt wird.

Wie KRONENWERK das abstrahiert

Mit Einschränkungen unterstützt KRONENWERK erzeugt bei der Ausstellung belgischer Rechnungen Peppol BIS Billing 3.0 UBL, mit der Teilnehmerkennung des Kunden im Dokument und gegen das Peppol- und CEN-Schematron validiert, bevor die Rechnungsnummer verbraucht wird. KRONENWERK ist kein Peppol Access Point. Es sendet und empfängt über Peppol durch einen akkreditierten Access-Point-Anbieter (Storecove), sobald die Firma unter Einstellungen → Zustellung angebunden ist; Discovery, Umschlag, AS4-Transport und Quittungen übernimmt dieser Anbieter, und der produktive Versand hängt von diesem Konto und seiner Konfiguration ab. Über den Anbieter empfangene UBL-Rechnungen werden als Eingangsrechnungen eingelesen. KRONENWERK enthält bewusst keinen eigenen DNS- oder SMP-Client: Die SML-Migration von 2026 verlangte von KRONENWERK nichts, weil die Abfrage nie seine Aufgabe war.

Über die API legt ein Entwickler den Entwurf an (POST /invoices/drafts) und liest die ausgestellte Rechnung (GET /invoices/{number}); Ausstellung, Validierung und Versand erfolgen im Produkt, und der Webhook invoice.issued meldet die Ausstellung. Es gibt keinen Endpunkt, der rohes UBL einreicht, einen Teilnehmer nachschlägt oder eine MLR zurückgibt. Was die API rund um Peppol kann und nicht kann, beschreibt Peppol-Integration; der weitere Kontext steht auf der Peppol-Seite und unter Senden und Empfangen, die belgische Pflicht auf der Belgien-Übersicht und der Länderseite.