E-invoicing: B2B mandatory since 01.01.2025
Germany's Wachstumschancengesetz made electronic invoicing mandatory in B2B. Receiving must be possible for everyone since 01.01.2025. Sending is staggered: from 01.01.2027 for everyone with turnover above EUR 800k, from 01.01.2028 for all B2B. PDF alone is not enough — structured XML is required.
What it's about
An 'e-invoice' under German law is an invoice in a structured electronic format that allows machine processing. PDF files are not e-invoices — even when sent electronically. Two formats apply in Germany: XRechnung (pure XML standard, mandatory in B2G) and ZUGFeRD from profile EN 16931 (PDF with embedded XML, more common in practice). Both must satisfy the EN 16931 mandatory fields and pass the KoSIT validator.
The legislator phases the duties on purpose: receiving became mandatory for every B2B business on 01.01.2025 — regardless of size or turnover. Sending has a transition period: until end of 2026, paper and PDF invoices may still be sent with the recipient's consent; from 01.01.2027, companies with turnover above EUR 800k are obliged; from 01.01.2028 all remaining B2B senders. Even small businesses (Kleinunternehmer under § 19 UStG) are not exempt — at minimum they must be able to receive.
The background is an EU-wide initiative against the VAT gap (keyword ViDA — 'VAT in the Digital Age'), which will eventually mean near-real-time reporting to the tax authority. Whoever sends structured invoices today is prepared for the next stage. Without a correct e-invoice: no input VAT deduction — and the GoBD retention duty still applies, 8 years, immutable.
Who is affected
- All B2B businesses in Germany — from solo trades to corporations. No turnover threshold on receipt; from 2028 also on sending.
- Small businesses (Kleinunternehmer, § 19 UStG) — they must be able to receive and read e-invoices, even if not yet obliged to issue them.
- Contractors to public authorities — B2G has been XRechnung-mandatory since 2020 (federal and state e-invoicing regulations).
- Landlords with commercial letting to businesses (office, shop, warehouse) — rent is a B2B turnover.
- Associations and foundations with taxable commercial operations (sponsoring, advertising, sales to businesses).
- Tax advisors and accounting service providers — they need to serve clients in both directions (receipt and sending).
- Online shops with B2B customers (SaaS, digital goods, physical products) — including cross-border, if the recipient is in Germany.
What is mandatory
- Receiving capability since 01.01.2025 (email inbox for XRechnung/ZUGFeRD).
- Structured format per EN 16931 (XRechnung CIUS or ZUGFeRD profile EN 16931).
- Validation against the KoSIT validator (Schematron check for XRechnung).
- Mandatory fields: service/delivery date, VAT ID, order reference, bank details.
- Discount terms in structured fields, not free text.
- GoBD-compliant 8-year archive, immutable (hash-secured).
- No format change on receipt: the original XML is the invoice.
- On errors: cancellation + new invoice, no after-the-fact editing.
- Document inbound timestamp and receipt proof (date, time, sender) — GoBD requires traceability from arrival.
- Automatic detection of XML attachment vs. descriptive PDF: XML is the invoice, PDF only the visualisation — processes must separate them.
- Use the transition rule until 31.12.2026 with documentation: paper/PDF sending only with documented recipient consent — otherwise inadmissible from 2027.
What I take care of
- Implementation of an e-invoice generator (XRechnung 3.0.x or ZUGFeRD 2.3+).
- Validation against the KoSIT validator before every send (no 'just ship it').
- GoBD-compliant archive in Supabase Storage with hash lock and write protection.
- Receiving path: email inbox + parsing (extract XML, validate, import into accounting).
- Integration with DATEV export or existing ERP (lexware, SAP, etc.).
- Migration of legacy PDF invoices: assess which ones still need conversion.
- Status dashboard: received/sent/open/rejected invoices.
- Test suite with valid + intentionally broken XRechnungen (missing VAT ID, wrong date format, invalid schema) as regression protection before every deploy.
- Rejection workflow: automatic email to accounting with the KoSIT error in plain text (no XML wall of text) — including correction hints.
Legal basis
German Wachstumschancengesetz (Art. 23) · § 14 UStG · GoBD (principles for proper computer-aided accounting) · EN 16931 · CIUS XRechnung
Frequently asked
- What is the difference between XRechnung and ZUGFeRD?
- XRechnung is pure XML — no human-readable form. Standard in the German B2G area (authorities), works for B2B too. ZUGFeRD from profile EN 16931 is a hybrid: PDF with embedded XML — humans see the PDF, software reads the XML. ZUGFeRD is more common in practice, both are legally equivalent.
- Can I just have a PDF invoice 'converted' into an e-invoice?
- Not reliably. PDF-to-XRechnung conversion would have to interpret text via OCR and heuristics — error-prone (VAT rates, order numbers, discount terms). Cleaner: generate the invoice structured from master data from the start, NOT backwards from the PDF. Legacy stock can be converted, but every result needs review.
- Do I still need to keep incoming e-invoices as PDFs?
- No — and it would be problematic. The original is the XML file. You must keep that GoBD-compliant for 8 years, unchanged (hash-locked). Generating a PDF preview is fine, but it's an attachment/preview, not the original. Anyone who throws away the XML and only keeps the PDF has lost the original.
- I'm a Kleinunternehmer under § 19 UStG — am I exempt?
- From sending, yes (for now); from receiving, NO. Since 01.01.2025 you must accept and be able to read structured e-invoices. That doesn't mean 'pull the PDF from your inbox' — it means extract, validate and archive the XML attachment. Sending is added from 01.01.2028 if you still issue B2B invoices by then.
- What happens if I still accept PDF invoices without XML?
- Formally, since 2025 that is no longer a proper invoice under § 14 UStG — the tax office can deny input VAT deduction. Enforcement is lenient during the 2025/2026 transition, but relying on that is a mistake. Cleaner path: politely inform the sender once and ask for XRechnung or ZUGFeRD — most have it available anyway.
- What about invoices from other EU countries?
- Other EU formats are permitted if they are EN 16931-compliant. The Peppol BIS Billing 3.0 standard is widespread, EN-16931-based and delivered via the Peppol network. Important: check the format with a validator and test compatibility with your accounting software — not every ERP handles Peppol out of the box.
Need support?
Let's talk for 30 minutes. I'll look at your situation and tell you what makes sense as a next step.
Book a slot