PEPPOL eInvoicing for B2B shops in Germany 2026

While the German debate in 2025 still focused largely on ZUGFeRD and XRechnung, another format quietly turned into the European de facto standard for cross-border B2B eInvoicing: PEPPOL. By March 2026, the network already counted 3,597,971 participants across 116 countries — a growth of more than 1,173 percent in six years (Poppel). At the same time, the ATO Value Assessment puts processing cost below 5 EUR per electronic invoice versus 5 to 15 EUR for paper-based processes — a reduction of 70 to 80 percent (ATO Value Assessment). For B2B shops in Germany this means: in 2026 PEPPOL is no longer an exotic option but a serious alternative to a pure XRechnung connection — especially for international customers.

What PEPPOL is and why it matters in 2026

PEPPOL stands for Pan-European Public Procurement Online and started as an EU project to simplify public procurement. Today, OpenPeppol AISBL — an international non-profit headquartered in Brussels — runs the network. As of November 2025 OpenPeppol reported 46 member countries and territories as well as 20 national Peppol Authorities (OpenPeppol). For Germany, this role is held by the Coordination Office for IT Standards (KoSIT) in Bremen — and not by Bundesdruckerei, as is occasionally reported by mistake. KoSIT has officially been the German Peppol Authority since June 2018 and also maintains the XRechnung standard.

Unlike XRechnung or ZUGFeRD, PEPPOL is not a format but a complete network of identifiers, data formats, transport protocols and contractual rules. The most important data format inside the network is PEPPOL BIS Billing 3.0 based on UBL 2.1 — according to Ionite, with 3,011,915 participants and a share of 83.7 percent the dominating eInvoicing schema in the network (Ionite). Belgium clearly leads adoption with 1,964,080 participants and a global share of 54.6 percent (Poppel).

The economic case for structured invoicing has by now become hard to argue against: the Value Assessment by the Australian Taxation Office shows processing costs of 27 to 30 USD per paper invoice versus less than 10 USD per electronic invoice; European studies put the range at roughly 5 to 15 EUR for paper-based processes versus less than 5 EUR for structured formats (ATO Value Assessment). Consultancies such as Valtatech derive a typical ROI horizon of three to six months in which integration costs typically pay back — combined with significantly shorter payment terms, often around five working days instead of several weeks (Valtatech).

The 4-corner model explained technically

At its core, the 4-corner model describes four roles along an invoice: C1 is the sender (for example a Shopware shop), C2 the sender access point, C3 the receiver access point and C4 the receiver's ERP or accounting system. The key idea: sender and receiver do not have to know each other or maintain a bilateral connection — they only talk to their respective access point, and that access point looks up the receiver AP via a central directory service.

This is what makes PEPPOL scalable: instead of n×m point-to-point connections, a hub network emerges in which each participant maintains only one connection. Semantically, PEPPOL BIS 3.0 builds on UBL 2.1 as its standard syntax and implements a so-called CIUS (Core Invoice Usage Specification) of the European norm EN 16931. An optional mapping to UN/CEFACT CII is also defined, building a bridge to ZUGFeRD and Factur-X. PEPPOL therefore covers the same data model as XRechnung and ZUGFeRD, but adds addressing, transport and a contractual framework. A simplified pseudo-code lookup illustrates the principle:

# 1. Sender AP computes hash of receiver participant ID
PARTICIPANT_ID="0204:991-12345678" # 0204 = DE Leitweg-ID scheme
MD5=$(echo -n "$PARTICIPANT_ID" | md5sum | cut -d' ' -f1)

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

# 3. SMP query: which document types does the receiver support?
curl "https://${SMP_URL}/iso6523-actorid-upis%3A%3A${PARTICIPANT_ID}"

# 4. Document-type specific lookup: endpoint URL + X.509 certificate
curl "https://${SMP_URL}/.../services/busdox-docid-qns%3A%3Aurn%3A...%3Abillingv3"

# 5. AS4 dispatch of the invoice to the resolved receiver AP
# (signed, encrypted, MIME multipart body)

PEPPOL BIS 3.0 vs XRechnung vs ZUGFeRD

All three formats build semantically on the European norm EN 16931 — but they differ in syntax, transport and typical use case. The table below shows the key differences from a shop perspective:

SML and SMP: addressing inside the network

For the 4-corner model to work, a distributed directory is required. PEPPOL uses two components for this: the SML (Service Metadata Locator) and the SMP (Service Metadata Publisher). The SML is a central DNS-based service — comparable to a global phone book. It does not know the endpoints themselves, however; it only points to the responsible SMP. The SMP in turn is decentralised and belongs either to the access point provider or to the participant; it returns the actual AS4 endpoint, the X.509 certificate and the list of supported document types.

The lookup follows a defined scheme: the MD5 hash of the participant ID is combined with a prefix to form the SML hostname, which is resolved via CNAME or NAPTR and returns the SMP URL. A typical example:

# Example participant ID: German Leitweg-ID via scheme 0204
PID="0204:991-12345678-44"

# Compute MD5 hash of the ID (lowercase, hex)
HASH=$(echo -n "$PID" | md5sum | awk '{print $1}')
# e.g. 8f3a2c... (32 hex chars)

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

# DNS resolution -> SMP hostname
dig +short "$SML" CNAME
# -> smp.example-ap.eu.

# Direct SMP call with URL-encoded participant ID
curl -s "https://smp.example-ap.eu/iso6523-actorid-upis%3A%3A0204%3A991-12345678-44"

AS4 as the transport protocol

For the actual transmission between access points, PEPPOL relies on AS4 — a standard based on ebMS 3.0 originally designed for secure B2B communication. AS4 uses SOAP over HTTPS, signs the message with the sender's X.509 certificate and encrypts the payload. The advantage over older protocols such as AS2: AS4 is standardised on REST-style transport, supports compressed payloads and returns receipt acknowledgements that can serve as legal proof.

From a shop operator's perspective AS4 takes a noticeable load off the in-house system: the access point handles TLS termination, certificate management, retry logic for transmission failures and logging — the shop only needs to deliver a clean UBL data set and the right receiver PEPPOL ID. This makes the integration much easier for Shopware shops than a bilateral EDI setup, which would require separate connections, keys and mappings for every business partner. This very effect explains a large part of the adoption dynamics over the past years.

Adoption comparison: BE, IT, PL, FR, DE

International adoption is structured very differently. Belgium uses PEPPOL as a national mandatory backbone, Italy and Poland rely on clearance models with their own platforms, France combines both approaches:

In Germany federal authorities have additionally been required since 27.11.2020 to receive electronic invoices in XRechnung format — according to e-rechnung-bund.de a baseline requirement for any B2G connection (e-rechnung-bund.de). Italy established the most internationally discussed clearance model in 2019 with its central Sistema di Interscambio (SDI): every domestic invoice flows through the state platform as FatturaPA and is validated for tax purposes before delivery. Poland's KSeF platform follows the same path — large companies with prior-year turnover above 200m PLN must use it from 1 February 2026, all other VAT-liable companies from 1 April 2026 (Polish Ministry of Finance). France combines both: via the Public Portal Facture (PPF), large and medium-sized companies are scheduled to invoice in structured format from September 2026, smaller ones from September 2027 — with both Factur-X and PEPPOL accepted as valid formats.

ViDA: EU mandate from 01.07.2030

The EU initiative VAT in the Digital Age (ViDA) defines the long-term frame: from 1 July 2030 structured eInvoicing will be mandatory for all intra-EU B2B transactions (European Commission). With it, an exception that is still common today disappears: member states will no longer need a special EU derogation in order to introduce national mandatory eInvoicing. For shop operators with cross-border B2B customers this means that investing in a single, norm-conformant connection will pay off.

1. 01.07.2030 ViDA Pillar 1: EU-wide mandate for structured eInvoices on intra-EU B2B turnovers and Digital Reporting Requirements (DRR)
2. Member states may extend their national B2B mandates without a Brussels derogation
3. Mandatory European norm remains EN 16931 with national CIUS profiles
4. Two-day window (planned) for transmission to tax authorities
5. Harmonisation with national clearance models such as Italy (SDI) and Poland (KSeF)

German deadlines 2025/2027/2028

1. 01.01.2025 — receiving mandate: every domestic B2B company must be able to receive structured electronic invoices according to EN 16931 (BMF / Wachstumschancengesetz)
2. 31.12.2026 — end of the general transition period: paper and simple PDF invoices will only be allowed in B2B to a limited extent from 2027 onwards
3. 01.01.2027 — sending mandate for companies with previous-year turnover above EUR 800,000: structured dispatch becomes mandatory (BMF)
4. 01.01.2028 — sending mandate for all B2B companies: regardless of turnover, the structured electronic dispatch obligation kicks in (Wachstumschancengesetz)
5. 01.07.2030 — ViDA EU: mandatory eInvoicing for intra-EU B2B turnovers, harmonised digital reporting (European Commission)

Access point providers: what to look for

Anyone wanting to become PEPPOL-capable without operating an access point themselves signs a contract with a certified provider. From a shop perspective, the typical selection criteria are: certification as a Peppol Service Provider through a national authority, support for the relevant document types (BIS Billing 3.0, Order, Catalogue, Despatch Advice), clear SLAs for availability and bounce handling, a REST API for integrating the shop backend, and audit-proof archiving in line with the GoBD. We deliberately do not recommend specific providers here — the choice depends on volume, accounting system, region and compliance requirements.

Connecting Shopware to PEPPOL

In practice PEPPOL fits into the existing invoicing logic of a Shopware shop as an additional dispatch channel. The shop remains the leading system for invoice creation and document numbers; a mapping service or middleware translates the internal data model into UBL 2.1 BIS Billing 3.0 and hands it over to the access point. A typical workflow looks roughly like this:

<?php
// Sketch: handover of a Shopware invoice to a PEPPOL AP

final class PeppolDispatcher
{
    public function dispatch(Invoice $invoice): DispatchResult
    {
        // 1. Load receiver PEPPOL ID from customer master
        $receiverId = $invoice->getCustomer()->getPeppolParticipantId();
        if ($receiverId === null) {
            // Fallback: ZUGFeRD by email or XRechnung portal
            return $this->fallbackChannel->dispatch($invoice);
        }

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

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

        // 4. Hand over to access point (provider REST API)
        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-phase implementation plan

1. Phase 1 — analysis: capture invoice volume, share of B2B foreign customers, existing formats (PDF, ZUGFeRD, XRechnung) as well as ERP and DATEV connectivity
2. Phase 2 — architecture: decide between a direct access-point contract or an upstream middleware; define mapping responsibilities and archiving paths
3. Phase 3 — implementation: UBL mapping out of Shopware or ERP, schematron validation, integration of the provider REST API, maintenance of PEPPOL IDs in the customer master
4. Phase 4 — testing: end-to-end tests against the access point's test environment, validation against official BIS 3.0 schematrons, documentation of receipts
5. Phase 5 — rollout: gradual activation per customer group, monitoring of delivery rates, fallback path for non-PEPPOL receivers (e.g. ZUGFeRD by email)

Using PEPPOL as a European invoicing backbone

With the ViDA mandate from 2030, the German sending obligation from 2027/2028 and a current adoption of 3.6 million participants in 116 countries, PEPPOL has established itself as the European backbone for structured B2B eInvoicing. For German shop operators this does not necessarily mean breaking with the existing eInvoicing strategy — but it does mean that PEPPOL deserves an equal seat at the architecture table next to XRechnung and ZUGFeRD. Anyone planning the next step of their accounting and ERP integration in 2026/2027 anyway should deliberately evaluate PEPPOL as an option — particularly where international B2B customers, punchout catalogues or cross-border procurement are involved. We support this step both as part of our consulting services and the actual development work.