Most companies ticked off the receiving obligation of January 2025 by setting up a new mailbox. The issuance mandate arriving in January 2027 cannot be solved that way: it reaches directly into ERP, inventory management and invoicing. This guide separates the format question from the actual project work — and shows what has to be running by the deadline.
This article is an in-depth expert contribution from our content cluster. Discover the complete overview on our main page:IT Security & Compliance →
Four months until the first issuance deadline
The receiving obligation was an organisational matter, settled with a central mailbox. The issuance mandate arriving in January 2027 is an IT project: it touches master data, invoicing, delivery channel, validation and archiving all at once. Anyone starting in autumn 2026 will be negotiating in December with a fully booked ERP provider.
- The deadline is staggered, not uniform: From 1 January 2027, companies with prior-year revenue above 800,000 euros must issue e-invoices; from 1 January 2028 the obligation extends to all remaining domestic B2B companies. The receiving obligation has applied without exception since 1 January 2025.
- The format is the smaller half of the project: XRechnung and ZUGFeRD are both EN 16931 compliant and available in every serious ERP system. The effort lies in the quality of your master data, the delivery channel, validation before dispatch, and audit-proof archiving of the XML.
- Two transitional rules expire in 2027: Established EDI procedures that are not EN 16931 compliant remain permissible only until the end of 2027, and even then only with the recipient's consent. Anyone running proprietary EDIFACT today faces two migrations, not one.
1. The countdown: three dates, two different obligations
The legal basis for the e-invoice in Germany was created by the Growth Opportunities Act and anchored in the VAT Act. In practice, two entirely different obligations are routinely confused, even though they have little in common technically or organisationally.
The receiving obligation has been in force since 1 January 2025 and applies to all domestic B2B companies without any transition period and without a revenue threshold. It merely requires that a company is able to accept an e-invoice — formally, an email inbox already suffices. It is precisely this low bar that has left many businesses with the impression that the topic is closed.
The issuance obligation is of a different order. It requires every invoice to a domestic business recipient to be generated as a structured data record — produced by the system itself, not exported after the fact. And it arrives in stages.
All domestic B2B companies must be able to accept e-invoices. No revenue threshold, no transition period. From this date onwards a supplier may send you an XRechnung without asking first.
Companies with prior-year revenue above 800,000 euros must issue e-invoices. What counts is revenue in the preceding calendar year — in this case 2026, meaning the outcome is already being determined right now.
The obligation extends to all remaining domestic B2B companies regardless of revenue. At the same time, the option to rely on transitional arrangements ends.
Established EDI procedures that do not conform to EN 16931 may be used at the latest until the end of 2027 — and even then only with the invoice recipient's consent.
2. XRechnung, ZUGFeRD and EN 16931 kept apart
Much of the confusion arises because three terms are debated as if they sat on the same level, when in fact they belong to different layers. EN 16931 is the European standard and describes the semantic data model: which fields an invoice must contain, what they mean, and which business rules apply between them. It says nothing about how that data ends up in a file.
XRechnung and ZUGFeRD are the two implementations of that standard relevant in Germany. Both satisfy EN 16931 — they differ in the container, not in the content.
Comparison: XRechnung vs. ZUGFeRD
- Structure: A single XML file with no visual representation. Practically unreadable for humans without a viewer.
- Primary use case: Invoices to public sector clients, where XRechnung is the prescribed standard.
- Addressing: Generally requires a Leitweg-ID issued by the contracting authority.
- Advantage: Maximum clarity, no redundancy between image and data, compact file size.
- Drawback: Your customer cannot view the file without suitable software — which reliably generates questions in traditional mid-market companies.
- Structure: A PDF/A-3 file with embedded XML. One document, two ways of reading it.
- Primary use case: Classic B2B traffic, particularly with customers at differing levels of digital maturity.
- Release status: ZUGFeRD 2.4, published in early December 2025 and valid since 15 January 2026, superseding version 2.3.
- Advantage: The recipient sees a familiar PDF while software reads the structure. No discussion with customers required.
- Drawback: Two representations of the same facts that can diverge — which makes validation more important, not less.
The profile question in ZUGFeRD
ZUGFeRD offers several profiles with differing levels of detail. To satisfy the legal obligation, the EN 16931 profile (formerly labelled "Comfort") is the safe choice: it is fully standard compliant and equivalent in content to an XRechnung. Leaner profiles such as MINIMUM or BASIC WL deliberately carry less information and are insufficient for a complete VAT invoice. The EXTENDED profile goes beyond the standard and makes sense wherever industry-specific additional data has to be carried.
Expert tip: one format outbound, both formats inbound
Commit to exactly one outbound format — usually ZUGFeRD in the EN 16931 profile, because it generates no questions at the receiving end. Inbound, however, you must be able to process both: your suppliers decide for themselves what they send. An inbound pipeline that only understands PDF attachments will fail on the first pure XRechnung it meets.
3. The four expensive misconceptions
In conversations with mid-sized companies we encounter the same false assumptions again and again. Every one of them can leave a business believing it is prepared when it is not.
Misconception 1: "We have been emailing PDFs for years"
A PDF is a picture of an invoice, not a structured data record. German VAT law explicitly classifies it among other invoices, not among e-invoices. Even a cleanly produced PDF/A without embedded XML fails to meet the obligation. The difference is not the file extension but machine readability.
Misconception 2: "Our EDI has run for years, it stays as it is"
Established EDI procedures that do not conform to EN 16931 are permissible only until the end of 2027 — and even then only with the recipient's consent. Anyone sitting on a proprietary EDIFACT link therefore has a hard deadline and must plan that migration in parallel with the general changeover.
Misconception 3: "We archive the PDF, after all"
With an e-invoice, the structured data record is the original that matters for VAT purposes. The GoBD require exactly this XML to be retained unalterably and in machine-readable form throughout the entire retention period. Storing only the human-readable document and discarding the XML after processing destroys the original.
Misconception 4: "Our ERP vendor will simply switch it on"
The export component usually does exist. But it only fills the fields that are cleanly maintained in your master data. Missing tax numbers, inconsistent payment terms, free-text service descriptions and incomplete customer addresses mean the export runs while the resulting file violates the standard's validation rules.
4. The system question: where is the e-invoice created?
Once the format question is settled, the actual project work begins. It consists of four building blocks that have to be decided independently of one another — and this is precisely where it is determined whether the changeover takes an afternoon or a quarter.
Block 1: data source and master data quality
The standard demands fields that many invoicing systems have so far treated as optional: unambiguous customer identification, structured address data, correct tax categories per line item, machine-readable payment terms and a due date expressed as a date rather than as prose. Experience shows this is where most of the effort sits. Skip this step and you will later produce invoices that are technically generated but substantively invalid.
Block 2: generation — ERP, middleware or service provider
Three routes are viable. First, native generation inside the ERP, provided the vendor ships a standard-compliant module — the cleanest path where the licence exists. Second, an upstream middleware layer translating your existing invoice data export into ZUGFeRD or XRechnung — the pragmatic path for legacy systems no longer under active development. Third, an external service provider taking over the entire chain — the fastest path, though it creates a permanent dependency and recurring per-document costs.
Block 3: delivery channel
The law prescribes no particular transmission route. In practice email with the e-invoice attached dominates, because it requires no infrastructure. Public sector clients, by contrast, require delivery through their invoice receipt portals, and in international business the Peppol network is gaining ground, where delivery runs through certified access points instead of email. Decide this per customer segment rather than across the board.
Block 4: validation before dispatch
A Schematron validation checks not merely whether the XML is well-formed but whether the standard's business rules are observed — for instance whether tax categories, line items and invoice totals add up. This check belongs firmly before dispatch. A rejected invoice costs you not only time but, in case of doubt, pushes payment out by an entire payment run.
A realistic scenario
Consider a manufacturing company issuing roughly 400 outgoing invoices per month, running a grown ERP system, with a tax advisor connected via DATEV. The format decision — ZUGFeRD in the EN 16931 profile — is made in a single morning. Activating the export module in the ERP is a configuration task of a few hours.
The effort comes afterwards. Running a sample of 50 invoices through a validator typically shows that a double-digit percentage breaches the validation rules — usually because VAT identification numbers for EU customers are missing, because line items carry no unambiguous tax category, or because payment terms exist only as free text. Cleaning up that master data and adjusting the invoice templates is the real content of the project. How those data streams then flow cleanly into financial accounting is covered in detail in our article on ERP interfaces and the DATEV API.
5. The return channel: processing incoming invoices
The receiving obligation has formally existed since the start of 2025, but its practical relevance is now rising sharply: the more of your suppliers become subject to the issuance obligation from 2027, the more structured invoices land in your inbox. A mailbox alone will no longer keep you operational.
The good news is that the e-invoice makes inbound processing markedly simpler. Where OCR previously had to reconstruct amounts from pixels, the data now arrives exact and pre-validated. The error rate in document capture falls structurally, not statistically. How to build a fully automated pipeline on that foundation is set out in our master guide to no-touch accounting.
A central inbound channel instead of personal mailboxes. A dedicated address that all suppliers write to is the precondition for any automation.
Format detection and extraction: pure XML, a ZUGFeRD PDF with embedded XML, or a classic unstructured PDF — each case needs its own path.
Validation of the incoming record and automatic matching against purchase order and goods receipt. Discrepancies become the exception, not the rule.
Audit-proof archiving of the original XML with an audit trail — not merely of the human-readable document. Only then does handover to accounting follow.
6. Roadmap to 1 January 2027
The following sequence has proven itself because it pulls the decisions with the longest lead time to the front. Starting in the third quarter of 2026 leaves ample buffer for every step.
-
Step 1: establish applicability and your deadline
Determine prior-year revenue and with it your actual deadline — 2027 or 2028. Clarify special cases such as tax groups and affiliated companies with your tax advisor. This answer sets the pace of the entire project.
-
Step 2: inventory the outgoing invoice chain
Document exhaustively where outgoing invoices originate. In practice this is rarely just the ERP, but additionally spreadsheet templates in individual departments, a shop system and occasionally handwritten documents. Every one of these sources must either become standard compliant by the deadline or disappear.
-
Step 3: fix the format and generation route
Choose an outbound format (usually ZUGFeRD in the EN 16931 profile) and one of the three generation routes: native ERP module, upstream middleware or external service provider. Check the licensing position while you are at it — frequently the required module exists but has not been purchased.
-
Step 4: clean and validate master data
Produce a sample of real invoices and have them validated against the EN 16931 rule set. The resulting error list is your actual work plan. Expect several iterations before the share of clean documents settles reliably at one hundred percent.
-
Step 5: pilot operation with selected customers
Switch three to five cooperative customers over to e-invoicing and accompany the first complete cycle through to payment. Only once an invoice has not merely been sent but also processed and paid is the pipeline proven.
-
Step 6: archiving, rollout and documentation
Ensure the original XML is archived unalterably and in line with the GoBD, and record the procedural documentation. The gradual rollout across the entire customer base follows — sensibly completed well before the deadline rather than on it.
Quick check: are you ready for 2027?
Conclusion
Public debate around the e-invoicing mandate is conducted overwhelmingly as a format question — XRechnung or ZUGFeRD, XML or hybrid. That is understandable, but it obscures the part that actually consumes time. Both formats are mature, standard compliant and available in every serious ERP system. That decision is made in a single morning.
What takes months is the data quality underneath. An e-invoice is a contract checked by machine — and machine checking forgives nothing. Free-text fields, grown exceptions and tacit conventions between sales and accounting that worked for twenty years because a human looked at the result are exposed the moment a validator decides.
That, however, is precisely where the opportunity lies. Companies that use the changeover to sort out master data, invoice templates and the route into accounting once and properly gain more than compliance: they gain a solid foundation for every further automation, from automatic payment matching to daily financial reporting. The deadline then stops being a risk and becomes the occasion that finally funds a long-deferred project.
Do you have questions about the e-invoicing mandate?
Book a free initial consultationOur Regional Expertise
We are your digital partner – regionally anchored and successfully scaling across borders.
Is your invoicing ready for 1 January 2027?
We review your outgoing invoice chain from ERP to archive and tell you at a fixed price what needs to happen before the deadline.
Book your free strategy call nowExtended Specialized Glossary
E-Invoice
An invoice issued, transmitted and received in a structured electronic format that enables automated processing. Under German VAT law, a PDF sent by email is explicitly not an e-invoice.
EN 16931
The European standard defining the semantic data model for electronic invoicing. It specifies which fields an e-invoice must contain and how they are to be interpreted. XRechnung and the EN 16931 profiles of ZUGFeRD both implement this standard.
XRechnung
A purely XML-based invoice format and the German standard for invoices to public sector clients. The file contains no visual representation and is practically unreadable for humans without a dedicated viewer.
ZUGFeRD
A hybrid invoice format combining a PDF/A-3 file with embedded XML. The recipient sees an ordinary PDF while software reads the structured data. The current release is ZUGFeRD 2.4, valid since 15 January 2026.
PDF/A-3
An ISO-standardised PDF format for long-term archiving that permits arbitrary files to be embedded. This capability is the technical foundation of the hybrid ZUGFeRD format.
Peppol
An international network for the standardised exchange of electronic procurement documents. Invoices are delivered through certified access points rather than sent by email.
EDI (Electronic Data Interchange)
The classic, usually bilaterally agreed electronic data exchange between companies, for example via EDIFACT. Established EDI procedures that are not EN 16931 compliant remain permissible only until the end of 2027.
Leitweg-ID
A unique routing identifier issued by German public sector clients so that an incoming XRechnung can be assigned to the correct administrative unit. Without a valid Leitweg-ID the invoice is rejected.
Schematron Validation
A rule-based verification method that checks an XML invoice not only for syntactic well-formedness but against the business rules of EN 16931 — for example whether tax categories and totals are mutually consistent.
