PEPPOL eInvoicing für B2B-Shops in Deutschland 2026

Während sich die deutsche Diskussion 2025 noch stark um ZUGFeRD und XRechnung drehte, hat sich im Hintergrund ein anderes Format zum europäischen De-facto-Standard für grenzüberschreitendes B2B-eInvoicing entwickelt: PEPPOL. Im März 2026 zählt das Netzwerk laut Poppel/OpenPeppol bereits 3.597.971 Teilnehmer in 116 Ländern — ein Plus von über 1.173 Prozent in sechs Jahren (Poppel). Gleichzeitig zeigt das ATO Value Assessment Verarbeitungskosten von unter 5 Euro pro elektronischer Rechnung gegenüber 5 bis 15 Euro für papierbasierte Prozesse — eine Reduktion von 70 bis 80 Prozent (ATO Value Assessment). Für B2B-Shops in Deutschland heißt das: PEPPOL ist 2026 keine exotische Option mehr, sondern eine ernsthafte Alternative zur reinen XRechnung-Anbindung — vor allem bei internationalen Kunden.

Was PEPPOL ist und warum es 2026 zählt

PEPPOL steht für Pan-European Public Procurement Online und wurde ursprünglich als EU-Projekt zur Vereinfachung öffentlicher Beschaffung gestartet. Heute trägt OpenPeppol AISBL — eine internationale Non-Profit-Organisation mit Sitz in Brüssel — das Netzwerk. Im November 2025 zählte OpenPeppol nach eigenen Angaben 46 Mitgliedsländer und -territorien sowie 20 nationale Peppol Authorities (OpenPeppol). Für Deutschland nimmt diese Rolle die Koordinierungsstelle für IT-Standards (KoSIT) in Bremen wahr — und nicht etwa die Bundesdruckerei, wie gelegentlich falsch berichtet wird. KoSIT ist seit Juni 2018 die offizielle deutsche Peppol Authority und betreut zugleich den Standard XRechnung.

Anders als XRechnung oder ZUGFeRD ist PEPPOL kein Format, sondern ein vollständiges Netzwerk aus Identifikatoren, Datenformaten, Transportprotokollen und vertraglichen Regeln. Das wichtigste Datenformat innerhalb des Netzwerks ist PEPPOL BIS Billing 3.0 auf Basis von UBL 2.1 — laut Ionite mit 3.011.915 Teilnehmern und einem Anteil von 83,7 Prozent das dominierende eInvoicing-Schema im Netzwerk (Ionite). Belgien führt die Adoptionsstatistik mit 1.964.080 Teilnehmern und einem globalen Anteil von 54,6 Prozent klar an (Poppel).

Wirtschaftlich ist die Argumentation für strukturierte E-Rechnungen inzwischen erdrückend: Das Value Assessment der australischen Steuerbehörde ATO weist Verarbeitungskosten von 27 bis 30 US-Dollar pro Papierrechnung gegenüber unter 10 US-Dollar pro elektronischer Rechnung aus; in europäischen Studien liegen die Bandbreiten bei rund 5 bis 15 Euro für papierbasierte Prozesse gegenüber unter 5 Euro im strukturierten Format (ATO Value Assessment). Daraus errechnen Berater wie Valtatech einen typischen ROI-Horizont von drei bis sechs Monaten, in denen sich die Anbindungskosten amortisieren — bei gleichzeitig deutlich verkürzten Zahlungszielen, oft im Bereich von fünf Werktagen statt mehreren Wochen (Valtatech).

Das 4-Corner-Modell technisch erklärt

Im Kern beschreibt das 4-Corner-Modell vier Rollen entlang einer Rechnung: C1 ist der Sender (zum Beispiel ein Shopware-Shop), C2 der Sender-Access-Point, C3 der Empfänger-Access-Point und C4 das ERP- oder Buchhaltungssystem des Empfängers. Das Wichtige dabei: Sender und Empfänger müssen sich nicht gegenseitig kennen oder bilateral verbinden — sie kommunizieren nur mit ihrem jeweiligen Access Point, und dieser sucht über einen zentralen Verzeichnisdienst die Adresse des Empfänger-APs.

Genau dieses Prinzip macht PEPPOL skalierbar: Statt n×m Punkt-zu-Punkt-Verbindungen entsteht ein Hub-Netzwerk, in dem jeder Teilnehmer nur eine Anbindung pflegt. Inhaltlich basiert PEPPOL BIS 3.0 dabei auf UBL 2.1 als Standard-Syntax und implementiert ein sogenanntes CIUS (Core Invoice Usage Specification) der europäischen Norm EN 16931. Optional ist auch ein Mapping nach UN/CEFACT CII vorgesehen — was eine Brücke zu ZUGFeRD und Factur-X schlägt. Damit deckt PEPPOL semantisch dasselbe Datenmodell ab, das auch in XRechnung und ZUGFeRD genutzt wird, ergänzt es aber um Adressierung, Transport und Vertragsrahmen. Ein vereinfachter Pseudocode-Lookup zeigt das Prinzip:

# 1. Sender-AP berechnet Hash der Empfaenger-Participant-ID
PARTICIPANT_ID="0204:991-12345678" # 0204 = DE Leitweg-ID-Schema
MD5=$(echo -n "$PARTICIPANT_ID" | md5sum | cut -d' ' -f1)

# 2. SML-DNS-Lookup: B-Hash + SML-Domain ergibt SMP-URL
SML_HOST="B-${MD5}.iso6523-actorid-upis.edelivery.tech.ec.europa.eu"
SMP_URL=$(dig +short "${SML_HOST}" CNAME)

# 3. SMP-Abfrage: Welche Document-Types unterstuetzt der Empfaenger?
curl "https://${SMP_URL}/iso6523-actorid-upis%3A%3A${PARTICIPANT_ID}"

# 4. Document-Type-spezifischer Lookup: Endpoint-URL + X.509-Zertifikat
curl "https://${SMP_URL}/.../services/busdox-docid-qns%3A%3Aurn%3A...%3Abillingv3"

# 5. AS4-Versand der Rechnung an den ermittelten Empfaenger-AP
# (signiert, verschluesselt, mit MIME-Multipart-Body)

PEPPOL BIS 3.0 vs XRechnung vs ZUGFeRD

Alle drei Formate setzen inhaltlich auf der europäischen Norm EN 16931 auf — sie unterscheiden sich aber in Syntax, Transport und typischem Einsatzgebiet. Die folgende Tabelle zeigt die wichtigsten Unterschiede aus Shop-Sicht:

SML und SMP: Adressierung im Netzwerk

Damit das 4-Corner-Modell funktioniert, braucht es ein verteiltes Verzeichnis. PEPPOL nutzt dafür zwei Komponenten: den SML (Service Metadata Locator) und den SMP (Service Metadata Publisher). Der SML ist ein zentraler DNS-basierter Dienst — vergleichbar mit einem globalen Telefonbuch. Er kennt aber nicht die Endpoints selbst, sondern verweist nur auf den jeweils zuständigen SMP. Der SMP wiederum ist dezentral und gehört entweder dem Access-Point-Anbieter oder dem Teilnehmer selbst; er liefert den konkreten AS4-Endpoint, das X.509-Zertifikat und die Liste unterstützter Dokumenttypen.

Der Lookup folgt einem fest definierten Schema: Der MD5-Hash der Participant-ID wird mit einem Präfix zur SML-Domain kombiniert, dort als CNAME oder NAPTR aufgelöst und liefert die SMP-URL. Ein typisches Beispiel:

# Beispiel-Participant-ID: deutsche Leitweg-ID via Schema 0204
PID="0204:991-12345678-44"

# MD5-Hash der ID berechnen (lowercase, hex)
HASH=$(echo -n "$PID" | md5sum | awk '{print $1}')
# z.B. 8f3a2c... (32 Hex-Zeichen)

# SML-Hostname zusammensetzen
SML="B-${HASH}.iso6523-actorid-upis.edelivery.tech.ec.europa.eu"

# DNS-Auflösung -> SMP-Hostname
dig +short "$SML" CNAME
# -> smp.example-ap.eu.

# Direkter SMP-Call mit URL-encodierter Participant-ID
curl -s "https://smp.example-ap.eu/iso6523-actorid-upis%3A%3A0204%3A991-12345678-44"

AS4 als Transport-Protokoll

Für die eigentliche Übertragung zwischen den Access Points setzt PEPPOL auf AS4 — einen Standard auf Basis von ebMS 3.0, der ursprünglich für sichere B2B-Kommunikation entwickelt wurde. AS4 nutzt SOAP über HTTPS, signiert die Nachricht mit dem X.509-Zertifikat des Senders und verschlüsselt den Payload. Der Vorteil gegenüber älteren Protokollen wie AS2: AS4 ist standardisiert auf REST-nahen Transport, unterstützt komprimierte Payloads und liefert Empfangsbestätigungen (Receipts) zurück, die als rechtlicher Nachweis dienen können.

Aus Sicht des Shop-Betreibers entlastet AS4 das eigene System spürbar: Der Access Point kümmert sich um TLS-Terminierung, Zertifikatsmanagement, Wiederholungslogik bei Übertragungsfehlern und Logging — der Shop selbst muss nur einen sauberen UBL-Datensatz und die richtige Empfänger-PEPPOL-ID liefern. Das macht die Integration für Shopware-Shops deutlich einfacher als ein bilaterales EDI-Setup, bei dem für jeden Geschäftspartner separate Verbindungen, Schlüssel und Mappings verwaltet werden müssten. Genau dieser Effekt erklärt einen Großteil der Adoptionsdynamik der vergangenen Jahre.

Adoption-Vergleich: BE, IT, PL, FR, DE

Die internationale Adoption ist sehr unterschiedlich strukturiert. Belgien nutzt PEPPOL als nationales Pflicht-Backbone, Italien und Polen setzen auf Clearance-Modelle mit eigenen Plattformen, Frankreich kombiniert beides:

In Deutschland sind außerdem Bundesbehörden seit 27.11.2020 verpflichtet, E-Rechnungen über das Format XRechnung zu empfangen — laut e-rechnung-bund.de eine zentrale Voraussetzung für jede B2G-Anbindung (e-rechnung-bund.de). Italien hat mit dem zentralen Sistema di Interscambio (SDI) seit 2019 das international meistdiskutierte Clearance-Modell etabliert: Jede inländische Rechnung läuft als FatturaPA über die staatliche Plattform und wird dort vor Zustellung steuerlich validiert. Polens KSeF-Plattform geht den gleichen Weg — Großunternehmen mit einem Vorjahresumsatz über 200 Mio. PLN sind ab dem 1. Februar 2026 verpflichtet, alle weiteren VAT-pflichtigen Unternehmen ab dem 1. April 2026 (polnisches Finanzministerium). Frankreich kombiniert beides: Über die Public Portal Facture (PPF) sollen ab September 2026 große und mittlere Unternehmen verpflichtend strukturiert fakturieren, kleine ab September 2027 — wobei sowohl Factur-X als auch PEPPOL als zulässige Formate gelten.

ViDA: EU-Pflicht ab 01.07.2030

Die EU-Initiative VAT in the Digital Age (ViDA) setzt den langfristigen Rahmen: Ab dem 1. Juli 2030 wird strukturiertes eInvoicing für alle innergemeinschaftlichen B2B-Umsätze in der EU verpflichtend (EU-Kommission). Damit fällt ein heute noch verbreiteter Sonderstatus weg: Mitgliedsstaaten brauchen für nationale Pflicht-eInvoicing-Modelle keine Sondergenehmigung der EU mehr. Für Shop-Betreiber mit grenzüberschreitenden B2B-Kunden heißt das, dass sich der Aufwand für eine zentrale, normkonforme Anbindung lohnt.

1. 01.07.2030 ViDA Pillar 1: EU-weite Pflicht zu strukturierten eInvoices für intra-EU B2B-Umsätze und digitales Reporting (Digital Reporting Requirements, DRR)
2. Mitgliedsstaaten dürfen ihre eigenen nationalen B2B-Pflichten ohne Genehmigung Brüssels ausweiten
3. Verbindliche europäische Norm bleibt EN 16931 mit den nationalen CIUS-Profilen
4. Zwei-Tage-Frist (perspektivisch) für die Übermittlung an Steuerbehörden
5. Harmonisierung mit nationalen Clearance-Modellen wie Italien (SDI) und Polen (KSeF)

DE-Fristen 2025/2027/2028

1. 01.01.2025 — Empfangspflicht: Jedes inländische B2B-Unternehmen muss elektronische Rechnungen nach EN 16931 empfangen können (BMF / Wachstumschancengesetz)
2. 31.12.2026 — Ende der allgemeinen Übergangsfrist: Papier- und einfache PDF-Rechnungen sind ab 2027 in B2B nur noch eingeschränkt zulässig
3. 01.01.2027 — Sendepflicht für Unternehmen mit Vorjahresumsatz über 800.000 Euro: strukturierter Versand wird Pflicht (BMF)
4. 01.01.2028 — Sendepflicht für alle B2B-Unternehmen: unabhängig vom Umsatz greift die Pflicht zum strukturierten elektronischen Rechnungsversand (Wachstumschancengesetz)
5. 01.07.2030 — ViDA EU: Pflicht-eInvoicing für intra-EU B2B-Umsätze, harmonisiertes Digital Reporting (EU-Kommission)

Access-Point-Anbieter: Worauf achten?

Wer PEPPOL-fähig werden will, ohne selbst einen Access Point zu betreiben, schließt einen Vertrag mit einem zertifizierten Anbieter. Bei der Auswahl spielen aus Shop-Sicht typischerweise diese Kriterien eine Rolle: Zertifizierung als Peppol Service Provider durch eine nationale Authority, Unterstützung der relevanten Document-Types (BIS Billing 3.0, Order, Catalogue, Despatch Advice), klare SLAs für Verfügbarkeit und Bounce-Handling, REST-API für die Anbindung des Shop-Backends sowie revisionssichere Archivierung im Sinne der GoBD. Konkrete Anbieter empfehlen wir an dieser Stelle bewusst nicht — die Auswahl hängt von Volumen, Buchhaltungssystem, Region und Compliance-Anforderungen ab.

Shopware-Anbindung an PEPPOL

In der Praxis fügt sich PEPPOL als zusätzlicher Zustellweg in die bestehende Rechnungslogik eines Shopware-Shops ein. Der Shop bleibt führendes System für Rechnungserstellung und Belegnummern; ein Mapping-Service oder eine Middleware übersetzt das interne Datenmodell in UBL 2.1 BIS Billing 3.0 und übergibt es an den Access Point. Skizziert sieht ein typischer Workflow so aus:

<?php
// Skizze: Übergabe einer Shopware-Rechnung an einen PEPPOL-AP

final class PeppolDispatcher
{
    public function dispatch(Invoice $invoice): DispatchResult
    {
        // 1. Receiver-PEPPOL-ID aus Kundenstamm laden
        $receiverId = $invoice->getCustomer()->getPeppolParticipantId();
        if ($receiverId === null) {
            // Fallback: ZUGFeRD per E-Mail oder XRechnung-Portal
            return $this->fallbackChannel->dispatch($invoice);
        }

        // 2. Mapping Shopware-Order -> UBL 2.1 BIS Billing 3.0
        $ublXml = $this->ublMapper->mapInvoice($invoice);

        // 3. Schematron-Validierung gegen BIS 3.0 + DE-CIUS
        $this->validator->assertValid($ublXml);

        // 4. Übergabe an Access Point (REST-API des Providers)
        return $this->accessPointClient->send(
            receiver: $receiverId,
            documentType: 'urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0',
            payload: $ublXml,
        );
    }
}

5-Phasen-Implementierungsplan

1. Phase 1 — Analyse: Rechnungs-Volumen, Anteil B2B-Auslandskunden, vorhandene Formate (PDF, ZUGFeRD, XRechnung) sowie ERP- und DATEV-Anbindung erfassen
2. Phase 2 — Architektur: Entscheidung zwischen direktem Access-Point-Vertrag oder vorgeschalteter Middleware; Festlegung von Mapping-Verantwortung und Archivierungspfad
3. Phase 3 — Umsetzung: UBL-Mapping aus Shopware oder ERP, Schematron-Validierung, Anbindung der Provider-REST-API, Pflege der PEPPOL-IDs im Kundenstamm
4. Phase 4 — Test: End-to-End-Tests gegen die Test-Umgebung des Access Points, Validierung gegen offizielle BIS-3.0-Schematrons, Dokumentation der Receipts
5. Phase 5 — Rollout: Schrittweise Aktivierung pro Kundengruppe, Monitoring der Zustellquoten, Fallback-Pfad für nicht-PEPPOL-fähige Empfänger (z. B. ZUGFeRD per E-Mail)

PEPPOL als europäisches Rechnungs-Backbone nutzen

Mit der ViDA-Pflicht ab 2030, der nationalen Sendepflicht ab 2027/2028 und einer aktuellen Adoption von 3,6 Millionen Teilnehmern in 116 Ländern hat sich PEPPOL als europäisches Rückgrat für strukturiertes B2B-eInvoicing etabliert. Für deutsche Shop-Betreiber bedeutet das nicht zwingend einen Bruch mit der bisherigen E-Rechnungsstrategie — wohl aber, dass PEPPOL bei der Architekturentscheidung gleichberechtigt neben XRechnung und ZUGFeRD steht. Wer 2026/2027 ohnehin den nächsten Schritt seiner Buchhaltungs- und ERP-Integration plant, sollte PEPPOL bewusst als Option mitbewerten — gerade dort, wo internationale B2B-Kunden, Punchout-Kataloge oder grenzüberschreitende Beschaffung im Spiel sind. Wir begleiten diesen Schritt im Rahmen unserer Beratungsleistungen und der eigentlichen Programmierung.