Peppol ist ein europäisches Vier-Ecken-Netzwerk zum Austausch elektronischer Rechnungen: Du übergibst den Beleg an einen zertifizierten Access Point, der ihn über das Netz an den Access Point des Empfängers zustellt. Für inländisches B2B ist Peppol in Deutschland nicht vorgeschrieben — die E-Mail genügt. Über eine E-Rechnung API bereitest du die Anbindung vor, indem Erzeugung und Versand getrennt bleiben; bei Fortlauf ist der Peppol-Versand geplant und noch nicht als Rail verfügbar.

„Muss ich für die E-Rechnung an Peppol?“ ist eine der häufigsten Entwicklerfragen — und die Antwort trennt zwei Ebenen, die oft verwechselt werden: Erzeugung (das strukturierte Dokument) und Übertragung (der Weg zum Empfänger). Dieser Beitrag erklärt, was Peppol technisch ist, wann es überhaupt relevant wird und wie eine E-Rechnung API die Anbindung vorbereitet. Wichtig vorab: Bei Fortlauf ist der Peppol-Versand geplant, nicht live — jede Fähigkeit unten, die den tatsächlichen Peppol-Transport betrifft, ist Roadmap.

Was Peppol ist: das Vier-Ecken-Modell

Peppol (Pan-European Public Procurement OnLine) ist ein standardisiertes Netzwerk für den Austausch von Geschäftsdokumenten, getragen von OpenPeppol. Der Transport läuft im Vier-Ecken-Modell:

  1. Ecke 1 — Sender: dein System bzw. deine abrechnende Software.
  2. Ecke 2 — sendender Access Point: ein zertifizierter Dienst, der den Beleg ins Netz einspeist.
  3. Ecke 3 — empfangender Access Point: der Access Point des Empfängers.
  4. Ecke 4 — Empfänger: das Zielsystem, das den Beleg entgegennimmt.

Du selbst sprichst also nie direkt mit dem Empfänger, sondern immer mit einem Access Point. Die Adressierung übernimmt eine Registry: Über SML (Service Metadata Locator) und SMP (Service Metadata Publisher) findet der sendende Access Point anhand der Peppol-Teilnehmer-ID des Empfängers heraus, wohin und in welchem Format zugestellt werden darf.

Peppol-Format ≠ XRechnung, aber dieselbe Norm

Über Peppol wird für Rechnungen üblicherweise Peppol BIS Billing 3.0 transportiert — eine UBL-Ausprägung, die wie XRechnung ein CIUS der EN 16931 ist. Das heißt: dasselbe semantische Kernmodell (BG-/BT- Felder), nur eine andere nationale Einschränkung und Syntax. Wer aus einem sauberen EN-16931-Datenmodell erzeugt, hat die inhaltliche Grundlage für Peppol bereits — der Unterschied liegt in der Ausprägung und im Transport, nicht in den Geschäftsdaten.

Die elektronische Adresse des Empfängers (Peppol-Teilnehmer-ID) trägt ein Schema-Präfix, etwa 0204 für die Leitweg-ID im deutschen Behördenkontext (siehe Leitweg-ID (BT-10)) oder 0088 für eine GLN. Diese Adresse ist das, was der Access Point zur Zustellung braucht.

Im Fortlauf-Datenmodell trägst du den reinen Wert ein — die Leitweg-ID oder eine E-Mail-Adresse, ohne 0204:-Präfix. Das Schema leitet der Dienst beim Rendern selbst ab (0204 für eine Leitweg-ID, EM für eine E-Mail). Ein mitgeschicktes Präfix macht den Wert ungültig.

Ist Peppol in Deutschland Pflicht? Nein.

Für inländisches B2B ist in Deutschland kein bestimmtes Übertragungsnetz vorgeschrieben — eine E-Rechnung nach EN 16931 per E-Mail ist ein zulässiger Weg, Peppol ist optional. Die Wege im Überblick erklärt E-Rechnung übermitteln: E-Mail, Peppol und die zulässigen Wege; wie sich Peppol in die E-Rechnungspflicht insgesamt einordnet, steht unter Compliance.

Peppol ist damit heute vor allem dort relevant, wo viele Partner ohnehin angebunden sind — im Behördenumfeld und bei größeren Counterparties. Für einen deutschen SMB-Empfänger, der seine Rechnung per E-Mail entgegennimmt, bringt Peppol 2026 oft keinen Mehrwert.

Erzeugung und Versand trennen — so bereitest du Peppol vor

Die entscheidende Architekturregel: Erzeuge den Beleg einmal, wähle den Kanal unabhängig. Wenn deine Integration die Erzeugung sauber vom Versand trennt, ist ein späterer Peppol-Kanal ein additiver Schritt — kein Umbau am Erzeugungscode.

Der Erzeugungs-Flow ist heute live: strukturierte Daten rein, EN-16931-Beleg raus.

Bash
# 1) Rechnung anlegen (Server rechnet die Summen)
#    buyerElectronicAddress trägt die elektronische Adresse des Empfängers (BT-49).
#    Fortlauf erwartet den Wert OHNE Schema-Präfix — eine Leitweg-ID oder eine
#    E-Mail-Adresse; das Schema (0204 bzw. EM) leitet der Dienst selbst ab.
curl -sS -X POST "$FORTLAUF_API_URL/invoices" \
  -H "Authorization: Bearer $FORTLAUF_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "currency": "EUR",
    "documentTarget": "b2g",
    "buyer": {
      "name": "Kreisverwaltung Wehrenbrock",
      "addressLine1": "Poststraße 9",
      "postalCode": "49811",
      "city": "Wehrenbrock",
      "countryCode": "DE"
    },
    "buyerElectronicAddress": "<LEITWEG-ID>",
    "buyerReference": "<LEITWEG-ID>",
    "invoiceTypeCode": "380",
    "lineItems": [
      { "description": "Datenaustausch-Anbindung, Betrieb (Q4 2026)", "quantity": "3",
        "unitCode": "MON", "unitPriceNet": "760.00", "taxRatePercent": "19" }
    ]
  }'

# 2) Ausstellen — Nummer wird vergeben, XML gerendert + validiert
curl -sS -X PATCH "$FORTLAUF_API_URL/invoices/$ID/finalize" \
  -H "Authorization: Bearer $FORTLAUF_API_KEY"

# 3) Den EN-16931-Beleg abholen (XRechnung-XML oder ZUGFeRD/Factur-X-PDF)
curl -sS "$FORTLAUF_API_URL/invoices/$ID/xml" \
  -H "Authorization: Bearer $FORTLAUF_API_KEY" -o rechnung-$ID.xml

Das Feld buyerElectronicAddress (die elektronische Adresse des Empfängers, BT-49) ist im Datenmodell bereits vorhanden — genau die Angabe, die ein Access Point zur Zustellung braucht. Deine Integration ist damit auf der Datenseite vorbereitet, während der Peppol-Transport selbst geplant ist.

Roadmap-Hinweis, ehrlich gesagt: Einen Endpunkt „über Peppol versenden“ gibt es in der API heute nicht als produktiven Rail. Wir zeigen hier bewusst keinen erfundenen Peppol-Call. Der Versand über einen zertifizierten Access Point ist geplant und wird — der Trennung von Erzeugung und Zustellung folgend — als zusätzlicher Kanal ergänzt, ohne dass sich der oben gezeigte Erzeugungs-Flow ändert.

Access Point: warum man ihn nicht selbst baut

Ein Peppol-Access-Point muss zertifiziert und im Netz registriert sein; den betreibt man in der Regel nicht selbst, sondern bindet einen an. Für dich als Integrator heißt das: Der Wert einer API liegt darin, dass ein Vertrag und eine Schnittstelle Erzeugung, Format-Pflege und — perspektivisch — den Netzzugang kapseln, statt dass du dich um SML/SMP-Registrierung, Zertifikate und Peppol-BIS-Konformität selbst kümmerst.

Was das für deine Integration heute bedeutet

  • Trenne Erzeugung und Versand. Erzeuge den EN-16931-Beleg einmal; halte den Zustellkanal austauschbar. Dann ist Peppol später ein Schalter, kein Rewrite.
  • Führe die elektronische Adresse mit. buyerElectronicAddress (BT-49) ist die Peppol-relevante Angabe — pflege sie schon jetzt sauber, auch wenn du heute per E-Mail zustellst. Trag den Wert ohne Schema-Präfix ein (Leitweg-ID oder E-Mail); das Peppol-Schema ergänzt der Access Point bzw. die Ausgabeschicht.
  • Erwarte keinen Peppol-Zwang im inländischen B2B. Plane für E-Mail als Standardweg und Peppol als Option, nicht umgekehrt.

Der gezeigte Code ist illustrativ: Die vollständige Dokumentation steht dir in der API-Referenz zur Verfügung. Base-URL und Test-Key bekommst du mit dem Sandbox-Zugang im Entwickler-Bereich. Wie die Erzeugung im Detail aussieht, zeigt E-Rechnung per API; die Formate erklären XRechnung und ZUGFeRD / Factur-X.

Selbst ausprobieren? Der Zugang ist kostenlos und ohne Karte — Produkt-Einstieg für Entwickler →

Oder den eigenen Abrechnungsfluss konkret durchsprechen: 30 Min, technisch, mit dem Gründer →

Häufige Fragen

Brauche ich Peppol für die E-Rechnungspflicht in Deutschland?
Nein. Für inländisches B2B ist in Deutschland kein bestimmtes Übertragungsnetz vorgeschrieben — eine E-Rechnung nach EN 16931 (XRechnung oder ZUGFeRD) per E-Mail ist ein zulässiger Weg. Peppol ist ein optionaler Kanal, der vor allem im Behördenumfeld und bei größeren Partnern genutzt wird. Ein inländischer B2B-Peppol-Zwang besteht bis auf Weiteres nicht.
Wie funktioniert der Peppol-Versand über eine API technisch?
Peppol arbeitet im Vier-Ecken-Modell: Sender → sendender Access Point → empfangender Access Point → Empfänger. Über eine API übergibst du den erzeugten EN-16931-Beleg samt der elektronischen Adresse des Empfängers (Peppol-Teilnehmer-ID); der Access Point ermittelt über SML/SMP die Zustelladresse und transportiert das Dokument als Peppol BIS Billing 3.0 (UBL). Der Versand ist damit ein eigener Schritt nach der Erzeugung.
Kann ich mit Fortlauf schon über Peppol versenden?
Nein — der Peppol-Versand ist geplant, aber noch nicht als Rail verfügbar. Heute erzeugt Fortlauf XRechnung und ZUGFeRD/Factur-X und versendet ausgestellte Rechnungen per E-Mail über den eigenen SMTP-Zugang des Unternehmens (ein zulässiger B2B-Weg). Die API ist bewusst so geschnitten, dass Erzeugung und Zustellung getrennt sind, sodass ein Peppol-Kanal später ergänzt werden kann, ohne deinen Erzeugungscode zu ändern.