Was ist Peppol BIS 3.0? Eine praktische Entwicklereinführung

Wenn Sie in Europa Software für das Rechnungswesen entwickeln, werden Sie früher oder später auf Peppol stoßen.

Für viele Entwickler ist die erste Begegnung verwirrend: XML überall, seltsame Bezeichner, SMP- und SML-Discovery, UBL-Rechnungen, EN16931-Regeln, Validierungsfehler mit kryptischen Meldungen.

Dieser Artikel erklärt Peppol BIS Billing 3.0 aus einer praktischen Ingenieursperspektive. Ohne Unternehmens-Buzzwords. Nur die Teile, die Entwickler tatsächlich verstehen müssen.

Was ist Peppol?

Peppol ist ein europäisches Interoperabilitätsnetzwerk für den Austausch elektronischer Geschäftsdokumente. Der häufigste Anwendungsfall ist die elektronische Rechnungsstellung.

Statt PDFs per E-Mail zu senden, übermitteln Lieferanten strukturierte Rechnungsdokumente direkt zwischen Systemen. Eine Peppol-Rechnung ist maschinenlesbar, standardisiert, validiert und automatisch verarbeitbar.

Das erlaubt Buchungssystemen und ERP-Plattformen, Rechnungen mit minimalem manuellem Aufwand zu verarbeiten.

Was bedeutet BIS 3.0?

BIS steht für Business Interoperability Specifications. Peppol BIS Billing 3.0 definiert:

• Rechnungsstruktur
• Pflichtfelder
• Validierungsregeln
• erlaubte Codelisten
• Transportanforderungen

Die Syntax basiert auf UBL 2.1 und EN16931. In der Praxis: EN16931 definiert das semantische Rechnungsmodell, UBL definiert die XML-Syntax, und Peppol fügt Interoperabilitätsregeln obenauf hinzu. Mehr zum EN16931-Semantikmodell finden Sie in Understanding EN16931.

Warum Europa auf obligatorische E-Rechnung zusteuert

Mehrere EU-Länder bewegen sich in Richtung verbindlicher elektronischer Rechnungsstellung. Beispiele sind Belgien, Deutschland, Frankreich, Polen und Italien. Regierungen möchten USt.-Betrug reduzieren, automatisierte Steuerverarbeitung, interoperables öffentliches Beschaffungswesen und standardisierten Rechnungsaustausch.

Das macht Peppol-Kenntnisse zu Infrastrukturwissen.

Wie sieht eine Peppol-Rechnung aus?

Eine Peppol-Rechnung ist ein UBL 2.1 XML-Dokument.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <cbc:CustomizationID>
    urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1
  </cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>INV-2025-001</cbc:ID>
  <cbc:IssueDate>2025-11-12</cbc:IssueDate>

  <cac:AccountingSupplierParty>
    <!-- seller details -->
  </cac:AccountingSupplierParty>

  <cac:AccountingCustomerParty>
    <!-- buyer details -->
  </cac:AccountingCustomerParty>

  <cac:LegalMonetaryTotal>
    <!-- totals -->
  </cac:LegalMonetaryTotal>
</Invoice>

Im Gegensatz zu PDFs sind diese Dokumente für die maschinelle Verarbeitung gedacht. Ein einziges ungültiges Feld kann zur Ablehnung führen.

Die Rolle von EN16931

EN16931 ist der europäische semantische Rechnungsstandard. Er definiert Konzepte wie Rechnungsnummer, USt.-Betrag, Käuferkennung, Zahlungsbedingungen und Steueraufschlüsselungen. Peppol BIS 3.0 baut auf diesem Semantikmodell auf.

Deshalb sehen Entwickler häufig Referenzen wie BT-10, BT-49 und BR-CO-10. Das sind Business Terms und Business Rules, die von EN16931 definiert werden.

Häufige Entwickler-Schmerzpunkte

Die meisten Peppol-Implementierungen stoßen letztendlich auf dieselben Probleme.

Namespace-Probleme. UBL verwendet viele XML-Namespaces. Falsche Deklarationen führen zu kryptischen Parser-Fehlern, bevor überhaupt Business-Logik ausgeführt wird.

Validierungsfehler. Schematron-Validierungsfehler können schwer zu debuggen sein. Die Fehlermeldungen referenzieren BR-Codes, die die EN16931-Spezifikation zur Interpretation erfordern.

Bezeichnerformate. Teilnehmer-IDs und Endpunkt-IDs sind streng. Ein belgisches Unternehmen, das das Unternehmernummern-Schema 0208 verwendet, muss exakt diesen Schema-Code als Präfix verwenden.

XML-Signaturen. Kanonisierungsprobleme brechen häufig die Signaturvalidierung. Das ist eine besonders unangenehme Fehlerkategorie, weil das XML beim Lesen korrekt aussieht und die Signatur gültig ist, sie aber nicht gegeneinander verifizieren. Weitere Details finden Sie in XML signature validation pitfalls in Peppol.

Länderspezifische Profile. Deutschland, Belgien und Frankreich wenden jeweils zusätzliche Anforderungen über die Basisspezifikation Peppol BIS 3.0 hinaus an. Ein für ein Land gültiges Dokument kann für ein anderes ungültig sein.

SMP- und SML-Discovery

Peppol verwendet einen DNS-ähnlichen Discovery-Mechanismus. Der Ablauf funktioniert ungefähr so:

1. Hash der Teilnehmerkennung bilden
2. DNS-Hostname aus dem Hash konstruieren
3. SML (Service Metadata Locator) abfragen, um den SMP des Teilnehmers zu finden
4. SMP (Service Metadata Publisher) abfragen, um Service-Metadaten abzurufen
5. Unterstützte Dokumenttypen und Endpunkt-URLs ermitteln
6. Dokument über einen Access Point zustellen

Die SMP-Antwort ist selbst ein signiertes XML-Dokument. Diese Signatur verursacht die oben erwähnten Kanonisierungsprobleme.

Warum PDF-Rechnungen nicht ausreichen

Traditionelle PDF-Rechnungen sind menschenlesbar. Peppol-Rechnungen sind maschinenlesbar. Viele moderne Systeme kombinieren beides: PDF/A-3 für die visuelle Darstellung, eingebettetes XML für die Automatisierung.

Das ist die Grundlage von Factur-X und ZUGFeRD. Einen Vergleich, wie diese Formate zueinander in Beziehung stehen, finden Sie in Factur-X vs ZUGFeRD vs XRechnung vs Peppol.

Der schwierige Teil

Gültiges UBL XML zu erzeugen ist nicht der schwierige Teil. Der schwierige Teil besteht darin, XML zu erzeugen, das die reale Interoperabilitätsprüfung besteht:

• Schematron-Validierung über mehrere nationale Regelwerke
• SMP-Discovery mit dynamischen Namespace-Präfixen
• XML-Signaturverifizierung bei re-serialisierten Dokumenten
• Länderspezifische Pflichtfelder, die nicht in der Basisspezifikation stehen
• Rundungsregeln, die je nach Rundung pro Position oder pro Dokument unterschiedliche Ergebnisse liefern

In kommenden Artikeln werden wir behandeln: EN16931 im Detail, UBL vs. CII, SMP-Discovery-Interna, XML-Signatur-Fallen und häufige Peppol-Validierungsfehler.

Die echten Kosten des schwierigen Teils sind nicht das Lesen der Spezifikation. Es ist der operative Aufwand: Schematron-Regelwerke bei jedem Peppol-BIS-Release auf dem neuesten Stand halten, SMP-Discovery-Fehler graceful behandeln, länderspezifische Regelvariationen für Deutschland, Belgien, Frankreich und Polen pflegen.

SealDoc ist eine API, die diese Schicht übernimmt. Sie reichen Ihre Rechnungsdaten als JSON-Payload ein. Die API erzeugt das UBL-Dokument, führt EN16931- und Peppol-BIS-3.0-Schematron-Validierung durch, führt die SMP-Discovery durch, verpackt das Dokument in einem AS4-Umschlag und liefert es an den Access Point des Empfängers. Wenn der Empfänger nicht erreichbar ist oder das Dokument die Validierung nicht besteht, erhalten Sie eine strukturierte Fehlermeldung, die genau angibt, welcher Schritt fehlgeschlagen ist und warum.

Für Tests und Debugging akzeptiert der öffentliche SealDoc-Validator UBL- und CII-Rechnungsdateien und gibt einen klartextlichen Bericht über jede verletzte EN16931- und Peppol-BIS-3.0-Regel zurück, mit der BT-Nummer und dem Business-Rule-Code. Keine Anmeldung erforderlich.