No Portal Exists: Email, Peppol, or EDI for German E-Invoices
There is no German KSeF. Transmission is a commercial choice: email, Peppol, EDI, or a portal. Email of structured XML remains lawful. It is a weak authenticity channel. Here is how to pick.
No Portal Exists: Email, Peppol, or EDI for German E-Invoices
Germany's e-invoicing mandate is a format rule, not a clearance rule. Section 14 UStG tells you what an e-invoice is (EN 16931 structured data, in practice XRechnung or ZUGFeRD 2.0.1+ in the EN 16931 or Extended profile). It does not tell you how the file must travel. There is no federal B2B portal. The tax office sees the invoice at audit time, not at send time.
That gap is the whole operational problem. US invoicing products treat "send the PDF and track the open" as the product. In Germany that workflow fails twice: a plain PDF is not an e-invoice after the issuance dates, and an email open is not proof of authenticity, integrity, or delivery.
What the Law Allows
The BMF FAQ is deliberately undemanding about receipt capability: an existing email mailbox is enough for the 2025 receive duty. Intended dispatch routes, as listed in the BStBK FAQ (status 3 March 2026), include:
| Channel | What actually moves | Typical use |
|---|---|---|
| XRechnung XML, or ZUGFeRD PDF/A-3 with embedded XML, as an attachment | SME B2B, transition, buyers not on a network | |
| Peppol | EN 16931 document (XRechnung UBL or Peppol BIS Billing 3.0) via Access Points | Volume B2B, B2G, cross-border EU |
| EDI | Agreed structured messages, often already in retail and manufacturing | Existing EDI pairs |
| Supplier or buyer portal | Upload or pull of the structured file | Large-buyer onboarding |
| DE-Mail | Qualified electronic mail | Rare in practice |
None of these is mandated for B2B. The parties agree the channel. You cannot refuse a compliant e-invoice because you "only take PDF by email." You can agree a better pipe than email.
Why BStBK Calls Email a Stopgap
Email of a valid XRechnung or ZUGFeRD is lawful. The Federal Chamber of Tax Consultants still treats it as a temporary arrangement for three reasons.
- Interception. SMTP is not an authenticated invoice network. A mailbox compromise or a lookalike domain lets an attacker swap the attachment or the bank details inside a human-readable PDF layer.
- Integrity. Unless you add a qualified electronic signature, an EDI agreement, or a documented internal control procedure, you are relying on the file arriving unaltered. Email provides none of those by itself.
- GDPR. Invoice XML contains tax numbers, bank accounts, and line-level commercial data. Routing it through consumer mail hosts, forwarding chains, and "please print" inboxes is a disclosure you have to justify.
Authenticity of origin and integrity of content still have to be ensured. The BStBK list is: qualified electronic signature (QES), an EDI procedure, or an internal control procedure. "We got a read receipt" is not on that list.
Peppol Is a Network, Not a Format
Peppol is the pipe. XRechnung is the German CIUS of EN 16931. Peppol BIS Billing 3.0 is the OpenPeppol CIUS, UBL 2.1 only. They overlap.
An XRechnung in UBL syntax can travel as a Peppol BIS document through a certified Access Point. XRechnung in CII syntax cannot. Peppol BIS is the right default if you also invoice EU buyers or German public bodies on OZG-RE / ZRE. XRechnung CII remains useful for German-only email or portal upload.
KoSIT is the national Peppol Authority for Germany. Addressing uses a Peppol participant ID. For federal B2G, the receiver ID is commonly prefix 0204 plus the buyer's Leitweg-ID. For B2B you need the buyer's Peppol ID in master data before the first send. Guessing it from the VAT number fails.
Peppol is the only common German channel that is designed for machine-to-machine bulk. Email is not.
B2G Is Not B2B
Federal authorities sit behind OZG-RE (and ZRE). Issuers can send via Peppol, email, web upload, or manual entry. Peppol is the mass path. Länder run their own portals. Do not send a B2B XRechnung to a federal mailbox and call it done. The buyer tells you the portal and the Leitweg-ID at award. Missing BT-10 / Leitweg-ID is a business-rule rejection, not a transmission problem.
B2B has no equivalent of OZG-RE. If your buyer is not on Peppol, email of a compliant file remains legal after 1 January 2027. The 2027 and 2028 dates change the format you must issue. They do not outlaw email as a carrier of that format. Vendor blogs that say "email dies on 31 December 2026" are mixing format transition with channel.
A Practical Choice
| Situation | Channel to standardise on |
|---|---|
| Fewer than a few hundred B2B invoices a year, German buyers only | ZUGFeRD EN 16931 by email, plus a named invoice mailbox, plus an internal control checklist |
| Recurring volume, or any B2G | Peppol Access Point, XRechnung UBL / Peppol BIS 3.0 |
| Retail or industry pair that already runs EDI | Keep EDI; do not insert email "for e-invoicing" in the middle |
| Multi-market (PL, ES, DE) | Peppol plus the local clearance or five-corner connector; email is the fallback, not the system of record |
Master data is the real project. You need, per buyer: legal name, VAT ID, invoice mailbox or Peppol ID, Leitweg-ID if public, the profile they actually parse, and whether they still want a PDF visualisation next to the XML. Collect that before the 2027 issuance date. Do not collect it on the day the first XRechnung bounces.
Plandesk treats the structured file as the invoice and the channel as configuration: email for buyers who have only a mailbox, Peppol when the ID is present. Open tracking is not a delivery artefact. The artefact is the accepted structured record plus the transmission log of the channel you chose.
This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.