E-Invoicing Switch 2027: The Project Plan for German Companies Above €800,000

A great deal has been written about the German e-invoicing mandate, and almost all of it is aimed at freelancers and the self-employed. The companies facing the first hard deadline are different: if your total turnover in 2026 exceeds €800,000, you must send structured e-invoices from 1 January 2027. For you the transition period ends a full year earlier than for everyone else.

The gap between "we can receive e-invoices" and "we can issue e-invoices" is routinely underestimated. Receiving is a mailbox question. Issuing is a master-data question, and master data is the reason these projects run late.

This article is not another overview of the deadlines. It is a project plan: what to do in what order, where the switch usually gets stuck, and which invoice types are special cases.

The short version

• Your deadline is 1 January 2027 if your total 2026 turnover exceeded €800,000. What counts is the issuer's turnover, not the recipient's.
• The 2026 figure decides it, not the current year. If you are close to the line, plan for 2027 anyway: the number is only final after year-end closing, but the project needs lead time.
• The bottleneck is master data, not software: missing VAT IDs, incomplete recipient addresses, missing Leitweg-IDs for public-sector customers.
• EDI expires on 31 December 2027. If you invoice via EDI today, you have a second switch ahead and should plan both together.
• Not every invoice becomes an e-invoice: small amounts up to €250 gross, travel tickets, B2C and many tax-exempt supplies stay out of scope.
• Schedule the test run for Q4 2026. An e-invoice your customer rejects is a payment delay, not a formatting detail.

First check: are you actually in the 2027 stage?

The threshold is total turnover in the prior year, 2026, as defined in § 19 (3) UStG. Three points that are regularly misread:

• What counts is the issuer's turnover. Whether your customer is large or small makes no difference to your obligation.
• It is total turnover, not the B2B share. A retailer with €600,000 B2C and €300,000 B2B is above the line.
• The threshold is checked once, for the following year. It is not a rolling limit like the €100,000 in the small-business scheme.

If you are unsure which stage applies, the e-invoicing mandate check is faster: five questions, one date.

The project plan in five phases

Count backwards from 1 January 2027. Starting in Q3 2026 leaves room for a real test run; starting in December means your test run happens with live customers.

Phase 1: Take stock

Before you talk about software, you need three lists:

• Which invoice types do you issue? Standard invoices, progress and final invoices, recurring invoices, self-billed credit notes, cancellations, small-value invoices. Every type has to find its way through the new format.
• Who are your recipients? Domestic businesses (in scope), public authorities (in scope, plus Leitweg-ID), consumers (out of scope), customers abroad (out of scope).
• Where do your invoices originate today? Usually in more places than expected: the ERP system, accounting, a subscription tool, an Excel template in sales.

The third list is the uncomfortable one. Every source that produces PDFs today must either deliver structured data by the deadline or be switched off.

Phase 2: Clean up master data

This is where the actual work sits. An e-invoice is machine-readable, and machines are unforgiving about mandatory fields where a human PDF reader was generous.

In practice: export your customer master, check for gaps in exactly these fields, and close them before you change the format. For public-sector customers, ask for the Leitweg-ID actively — nobody sends it unprompted, and without it the receiving platform rejects the invoice.

Phase 3: Choose the format

Two formats are available for German B2B, both compliant with EN 16931:

• ZUGFeRD from version 2.0.1 — a PDF with embedded XML. Your customer still sees an ordinary PDF while the machine reads the XML. The pragmatic choice for a mixed customer base.
• XRechnung — pure XML with no visual rendering. The standard in the public sector, effectively mandatory for public-sector customers.

Two traps:

• The ZUGFeRD MINIMUM and BASIC-WL profiles do not meet the requirements. They do not contain a complete invoice and do not qualify as an e-invoice for VAT purposes. If you use MINIMUM today because it was enough for bookkeeping data, you have to move.
• For hybrid invoices, the XML part has been the authoritative one since 2025. If the PDF view and the XML differ, the XML governs. Generating both from the same source is therefore a requirement, not an elegance.

The full comparison is in XRechnung vs. ZUGFeRD.

Phase 4: Settle the transmission route

The format says nothing about how the invoice reaches the recipient. Three routes are common:

• Email — legally sufficient for B2B and by far the most common route. An attachment is enough.
• Peppol — a transport network many authorities and larger companies receive through. Access runs via an access point.
• Portal upload — via ZRE or OZG-RE for federal authorities, or a supplier portal for some corporate customers.

Most mid-sized issuers will get through 2027 on email. As soon as public authorities are among your customers, Peppol is worth a look.

Phase 5: Validate and test

A formally defective e-invoice is not a proper invoice. That puts your customer's input-VAT deduction in question until a correct version arrives — in practice, a disputed invoice and a delayed payment.

So two steps belong before the deadline:

1. Technical validation. Check generated files against the schema, for example with the KoSIT validator. Errors typically show up in code lists, tax rates and rounding.
2. A real test run with real customers. From October 2026, send selected customers an e-invoice alongside the PDF and have them confirm their system accepts it. Two or three rounds is normal.

Special cases that standard projects miss

• Progress and final invoices. The final invoice has to deduct the progress invoices already billed. In the XML that is a dedicated section, not free text.
• Self-billing. If your customer issues the invoice, the e-invoicing obligation sits with them — but you have to be able to process and archive the credit note.
• Cancellations and corrections. The correction document references the original via BillingReference. Details in cancellation and correction invoices.
• Recurring invoices. Rental agreements and subscriptions billed with a single standing invoice need a decision: an e-invoice per period from now on, or keep the contract as the invoice substitute.
• Small amounts up to €250 gross. Permanently exempt under § 33 UStDV. It is usually still worth including them rather than maintaining two processes.

Do not forget archiving

Sending is not the end of it. The structured part of an e-invoice must be retained unaltered for eight years (§ 14b (1) UStG). Since the second GoBD amendment of 14 July 2025, archiving the XML component is sufficient provided the other GoBD requirements are met.

A PDF printout does not replace the original, and a folder on a network drive does not satisfy the immutability requirement. If you have been filing PDFs, this needs a deliberate decision. What GoBD-compliant means in practice is covered in GoBD-compliant bookkeeping.

Timeline: counting back from 1 January 2027

Frequently asked questions

Does the €800,000 refer to my turnover or my customer's?

Yours. What counts is the issuer's total turnover in the prior year, 2026, under § 19 (3) UStG. The size of the recipient makes no difference to your obligation to issue.

We are just below €800,000. Should we switch anyway?

Usually yes. The figure is only final at year-end closing, but the project needs months of lead time. If 2026 turnover does cross the line, the obligation applies from 1 January 2027 with no grace period. And 2028 catches you regardless.

Is emailing PDFs enough?

Not from your deadline onwards. A PDF is an "other invoice" regardless of how it is sent. Only a structured, machine-readable data set compliant with EN 16931 meets the requirement. A PDF with embedded XML (ZUGFeRD from 2.0.1) does meet it.

Do we have to use Peppol?

No. Email is sufficient for B2B. Peppol becomes relevant when your customers receive through it — primarily public authorities and larger companies with connected inbound platforms.

What happens to our EDI connections?

EDI procedures remain permitted until 31 December 2027. After that, those invoices must comply with EN 16931 too. If you run EDI, it makes sense to plan both switches together.

How do we test that our e-invoices arrive?

In two stages: first validate technically against the schema, for example with the KoSIT validator, then test with selected customers in parallel operation. Schedule Q4 2026 for this, not December.

What happens if we miss the deadline?

An invoice in the wrong format is not a proper invoice for VAT purposes. That puts your customer's input-VAT deduction in question until you supply a correct one. The practical risk is therefore less a fine than a disputed invoice and a late payment.

Conclusion

Switching to e-invoicing is not an IT project. It is a master-data project with an IT component. Starting the inventory in Q3 2026 leaves time for what these efforts actually hinge on: incomplete customer records, missing Leitweg-IDs, and invoice types nobody thought of in the first draft.

The rest is tooling. With Norman, XRechnung and ZUGFeRD come straight out of your ordinary invoices, including validation, correction logic and GoBD-compliant storage of the XML original — with no separate compliance project running alongside.