Two obligations, not one
The most common confusion arises because "e-invoicing obligation" means two different things that take effect at different times:
The obligation to receive. Every business must be able to accept and process e-invoices. This stage has no transition period and no turnover threshold.
The obligation to issue. Invoices must be issued as e-invoices. This stage is staged and keyed to company size.
🔴 The mistake that follows: a business reads about a transition period, applies it to its own situation, and does nothing for now. But the period only concerns issuing. The receiving side already applies — and it applies to everyone.
The timeline
| Stage | In force since / from | For whom |
|---|---|---|
| Able to receive e-invoices | January 2026 | all businesses |
| Issuing e-invoices | staged by turnover | larger businesses first |
| Issuing with no exceptions | final stage | all businesses |
The current position per country — mandate, date and formats — is in our country overview and comes from the spec registry, not from this page.
What counts as an e-invoice
The decisive sentence: an e-invoice is structured and machine-processable. A classification follows from that which surprises many people:
| Form | E-invoice? |
|---|---|
| Paper | 🔴 no |
| Scanned paper as PDF | 🔴 no |
| Ordinary PDF from the printer | 🔴 no |
| XRechnung (XML) | 🟢 yes |
| ZUGFeRD from the EN 16931 profile | 🟢 yes |
| ZUGFeRD in the MINIMUM profile | 🔴 no |
The last row is the uncomfortable one. A MINIMUM file is a ZUGFeRD, carries the marque, contains XML — and still does not meet the standard, because it lacks lines and a complete tax breakdown.
💡 If someone sells you a PDF as an e-invoice, ask for the profile, not the format.
What you actually have to do
On the receiving side
- Name an address for e-invoices. An inbox is technically enough. It should not, however, be the personal mailbox of one employee who also takes holidays.
- Be able to read out the structured original. Not look at the PDF — recover the data from the XML. With ZUGFeRD it sits inside the PDF's attachments.
- Check. Otherwise you book data nobody has reviewed.
- Retain. The original, not a printout of it.
Point 4 is the one most often missed. The retention duty attaches to the structured file. A PDF printout of an XRechnung is not a retainable original.
On the issuing side
- Fix a format per recipient group. Public authorities expect XRechnung, business customers usually ZUGFeRD.
- Validate before sending. The most common causes of rejection are business rules, not XML faults — and all of them are detectable beforehand.
- Complete your master data. The surprisingly frequent blocker: missing seller contacts, country codes or structured payment details, because they previously lived only in the PDF template.
Small businesses
For receiving there is no exception. Anyone who receives invoices must be able to accept, read out and retain e-invoices, regardless of the small business scheme.
For issuing, small businesses are currently favoured. That is a relief, not a free pass: the receiving side remains.
The European frame
Germany is not acting alone here. With the ViDA reform package the EU is pushing the same direction: structured invoices as the default, plus a reporting duty for cross-border turnover.
For businesses invoicing only domestically that changes little for now. For everyone else it is the reason not to treat the topic as a German peculiarity: the formats are European, and some neighbouring countries are further along.
The advice if you are late
Start with receiving, not with issuing. That obligation already applies and has no transition period, it takes less effort to satisfy, and it pays back immediately — every incoming e-invoice you read out in structured form saves a manual entry.