Since 1 January 2025 e-invoicing in German B2B has no longer been a trend but an obligation. And that is precisely the sticking point: many companies can send PDFs today — but they are not yet properly set up for structured e-invoices to EN 16931 (XML), including receipt, processing, archiving and sound checking procedures.
The coming months will decide whether e-invoicing turns into a quiet process upgrade for you — or later into a noisy compliance case: queries in the invoice run, an approval process that stalls, arguments about the input VAT deduction and unnecessary effort in a tax audit.
For FRADECO the position is therefore clear: e-invoicing is not “just IT”. It is VAT compliance plus process design. In a German-French context a further dimension is added: anyone working across borders (a French company with a German VAT registration, a German group with French units, a shared service centre, a centralised ERP landscape) has to orchestrate invoice logic, master data and validation rules seamlessly across borders — otherwise media breaks, reconciliation effort and tax risks arise.
What an e-invoice is in law
The most important change of perspective first: in Germany an e-invoice is an invoice issued, transmitted and received in a structured electronic format that allows it to be processed automatically. The benchmark is the European standard EN 16931. In practice that means XML-based formats such as XRechnung or ZUGFeRD (with an EN 16931-compliant XML component).
In many cases a PDF therefore remains an “other invoice” — and not what the legislator means by an e-invoice.
Who the obligation applies to
The obligation applies to B2B turnover, where one business supplies another for that business’s purposes — for turnover that is taxable in Germany. Exempt turnover under § 4 Nr. 8 bis 29 UStG is excluded.
German-French situations that are frequently overlooked:
- French companies with German B2B turnover (construction sites, installations, supply chains, services with a German place of supply) need e-invoicing under German logic — regardless of how invoicing is done in France.
- Groups with central billing or ERP have to reflect German e-invoicing capability properly in templates, interfaces and validation rules. “We have a group template” is rarely enough in practice.
The transitional periods to 2028
The introduction is staggered. That sounds relaxed — but it is in fact a clear timetable:
- 1 January 2025 to 31 December 2026: the previous rules may still be used (paper or other electronic formats, in some cases with the recipient’s consent).
- 1 January 2027 to 31 December 2027: relief for issuers with total turnover of EUR 800,000 or less (previous year).
- from 1 January 2028: EN 16931 becomes standard operation in B2B as a rule — the room for “other invoices” narrows considerably.
The take-away: anyone who does not use 2026 and 2027 starts live in 2028 — and pays for it in time, risk and internal friction.
What stays outside the obligation permanently
Permanently outside the strict e-invoicing obligation are, among others:
- Small-value invoices (§ 33 UStDV) and travel tickets (§ 34 UStDV): still possible in any format.
- Small businesses (§ 19 UStG): no e-invoicing obligation on the outgoing side; billing can be done as an “other invoice” (paper, PDF and so on).
Important from a company’s point of view: in groups and on platforms in particular the supplier landscape is mixed. That means your incoming process has to handle e-invoices — even where not every supplier delivers perfectly straight away.
Why the XML file decides the input VAT deduction
The BMF has explained the application of e-invoicing comprehensively and set it out further in 2025 (corrections, additions, examples and practical notes). The message is unambiguous: technical quality and validation are becoming the standard.
The central point for finance and tax: it is the XML file that governs the input VAT deduction. Technology thereby becomes part of invoice verification, in addition to the classic check of the mandatory details.
In practical terms, errors fall into three categories:
- Format errors: the file does not meet the permissible technical requirements → the risk that it is not an e-invoice; the input VAT deduction may be at risk from 1 January 2028.
- Business rule errors: the file is an e-invoice but is “not proper” → input VAT possibly only after correction.
- Content errors: classic substantive defects (mandatory details, tax rate and so on) → not everything can be validated technically.
What follows from that: validation does not replace the commercial check — it becomes the additional layer that should be integrated cleanly into the process. And validation reports are worth a great deal as evidence of process in many setups.
The setup along the process chain
To stop e-invoicing becoming a permanent building site, a setup along the process chain is needed:
Receipt and processing
- Technical receipt and correct processing in the ERP or accounting system
- Clear responsibilities (AP / accounting / tax / IT) — without “ping-pong”
- EN 16931-compliant formats (XRechnung / ZUGFeRD with XML)
- Clean master data and mapping setup (VAT ID, tax codes, description of the supply, payment terms)
- Validation (tool or ERP module) plus the commercial check
- Documentation of the logic and the evidence (validation reports included)
- GoBD-compliant retention including machine readability of the XML data
The German-French angle
In a German-French environment different invoicing realities meet: French processes and formats, German VAT logic, group-wide ERPs, shared service centres. That does not make the subject harder — but it does make it less forgiving.
That is exactly where we come in:
- VAT classification DE/FR: which turnover is taxable in Germany — and therefore relevant for e-invoicing?
- Translating process and system: transferring the requirements of § 14 UStG and EN 16931 cleanly into ERP templates, workflows and internal controls.
- Audit readiness: auditable documentation and sound routines for incoming and outgoing invoices, including error handling and correction.