PEPPOL eInvoicing for B2B shops in Germany 2026

While the German debate in 2025 still focused largely on ZUGFeRD and XRechnung, another format quietly grew into a European backbone for cross-border B2B eInvoicing: PEPPOL. The Value Assessment by the Australian Taxation Office shows how wide the gap between paper and structured invoicing is: it puts average processing cost at 9.18 AUD per eInvoice versus 30.87 AUD per paper invoice (ATO). 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. In every connected country, OpenPeppol appoints a national Peppol Authority that enforces the rulebook locally and accredits service providers. 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. How far adoption can go at country level shows in Belgium: from 1 January 2026, structured electronic invoicing is compulsory there for nearly all transactions between VAT-liable enterprises (peppol.org).

The economic case for structured invoicing has by now become hard to argue against: the Value Assessment by the Australian Taxation Office puts average processing cost at 30.87 AUD per paper invoice, 27.67 AUD per PDF invoice and 9.18 AUD per eInvoice (ATO). How quickly a connection pays off in your own organisation depends on invoice volume, on how far accounting is automated and on the cost of the chosen access point — reliable figures for that only come from measuring your own process costs.

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.ap.example.

# Direct SMP call with URL-encoded participant ID
curl -s "https://smp.ap.example/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, suppliers invoicing the federal administration have been required since 27.11.2020 under section 3 of the E-RechV to submit their invoices electronically — according to e-rechnung-bund.de the basis of 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 — companies whose 2024 sales value including tax exceeded 200 million zloty 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 (section 27(38) UStG)
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 growing number of connected companies across Europe, 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.