Sending mandate from 2027: who, when, in what format

In a nutshell

From 1 January 2027 the second transition period of Germany’s e-invoicing mandate ends: companies with more than €800,000 prior-year revenue may only send B2B invoices in an EN 16931-compliant format — paper and plain PDF are out. From 1 January 2028 the same obligation applies to every company regardless of revenue.

The obligation to receive has already been in force since 2025 — see Germany E-Invoicing Mandate 2025.

Who is affected, and from when?

Date	Revenue threshold	Sending obligation
01 Jan 2025	—	none (receive only)
01 Jan 2027	> €800,000 prior-year revenue	yes, paper/PDF no longer allowed
01 Jan 2028	all companies	yes, no exemptions

The threshold refers to total revenue under § 19 UStG of the prior calendar year. Newly founded companies do not fall under the first step during their founding year.

Which formats are permitted?

Three formats meet the requirement:

• XRechnung — pure XML (UBL or CII)
• ZUGFeRD 2.x from profile EN16931 or XRECHNUNG
• Peppol BIS Billing 3.0

Not permitted:

• Paper invoices
• PDF without embedded XML (and no “photo of the PDF” either)
• ZUGFeRD 1.0 and the profiles MINIMUM / BASIC WL
• EDI formats without EN 16931 mapping (only in narrowly defined legacy-contract exceptions)

Technical requirements on the sending side

1. Invoice generator — produces XML/ZUGFeRD directly from the ERP or billing system
2. Validation before sending — against the EN 16931 Schematron and, if applicable, Peppol BIS rules
3. Transport — email with attachment, Peppol Access Point, direct submission to the recipient portal
4. Signature / immutability — not legally required for sending, but recommended for audit safety

Edge case: high-volume billing

Companies with high invoice volume (e-commerce, telco, utility) need a scalable generator no later than 2027. Critical metrics:

• Invoices per second at peak
• Validation throughput (Schematron is CPU-heavy)
• Archive storage (10 years × volume)

A typical mid-market setup processes 50–500 invoices per minute; large enterprises need 1,000+/minute. Dokmatiq scales horizontally — every API call is stateless.

Being ready for 2027 with the Dokmatiq API

# Invoice from ERP data → ZUGFeRD PDF
curl -X POST https://api.dokmatiq.com/v1/einvoice/zugferd \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -d '{
    "profile": "EN16931",
    "outputProfile": "PDF/A-3b",
    "stationery": { "firstPage": "…", "subsequentPages": "…" },
    "invoice": { ... }
  }'

# Validate before sending
curl -X POST https://api.dokmatiq.com/v1/einvoice/validate \
  --data-binary "@outbox.xml"

# Peppol-compliant UBL for Access Point delivery
curl -X POST https://api.dokmatiq.com/v1/einvoice/peppol \
  -d '{ "customizationId": "urn:fdc:peppol.eu:2017:poacc:billing:3.0", ... }'

Every endpoint returns either a finished document or a precise error list with BT/BR references — no guessing which Schematron rule failed.

Transition calendar for planning

• Q2 2026 — verify ERP support for EN 16931 export; if missing, plan API integration
• Q3 2026 — run parallel operation with selected customers (test sends, gather feedback)
• Q4 2026 — bring the archive pipeline live, migrate legacy data
• Q1 2027 — full operation, paper sending discontinued (for obligated companies)

Common pitfalls

1. Misreading the revenue threshold — prior-year revenue counts, not current
2. ZUGFeRD profile too small — BASIC WL is insufficient; EN16931 or XRECHNUNG is required
3. Signed PDF conflated with XML — a signed PDF is not an e-invoice in the new sense
4. Ignoring the recipient’s address method — Peppol ID, Leitweg-ID, email: the recipient dictates which transport channel is accepted