Mastering Germany’s E-Invoicing Mandate: Expert Q&A
Germany’s e-invoicing mandate is no longer a future IT project – it’s an active compliance reality. For companies with German legal entities and cross-border supply chains, this raises practical questions: why there is no single official format, where Peppol fits in, whether e-invoices can still be sent by email, and how long raw XML data must be archived.
On September 29, 2026, we hosted the webinar “Mastering Germany’s E-Invoicing Mandate”, featuring Comarch experts Michał Kacperek (DACH Consulting Director) and Rafał Trojanowski (Analyst & E-Invoicing Expert), and Victoria Etzold, Manager Tax Technology at PwC. The session sparked many questions from participants. Below, you will find the answers to the most pressing ones.
Mandate Scope, Timelines & E-Reporting
1. From 2027, is there any obligation in Germany to report invoices from international suppliers?
No. The German e-invoicing mandate applies only to domestic B2B transactions. No cross-border B2B or B2C transactions are covered. This is, however, expected in the future for intra-EU cross-border transactions (based on ViDA from July 1, 2030).
2. What about B2C invoices for e-commerce end-customers, for instance?
B2C transactions are not covered by the German e-invoicing mandate.
3. Does reverse charge refer to domestic reverse charge? Or does it include imported services?
The mandate for structured e-invoices applies to reverse charge transactions only if both the supplier and the recipient are domestically resident.
4. What are the e-reporting requirements and when do they apply?
This is not defined yet. Voluntary e-reporting should be possible in 2029, and mandatory from July 1, 2030. For now, it is not clear what will be the scope of e-reporting (if an excerpt from an invoice document or the entire invoice or invoice statuses, e.g. received, rejected, paid etc.).
5. Will the German government receive a copy of e-invoices (and if so, when)? Is that when ViDA goes live?
There will be an e-reporting mandate where you will inform the tax authority about your transactions. The planned ViDA mandate starts July 1, 2030, whereas a voluntary e-reporting should be available one year before.
6. Do we have to inform our customers about the switch to e-invoices?
No, this is required by law. Starting from January 1, 2027, you are obliged by law to issue e-invoices. It is the duty of both you and your partners to be compliant with legal requirements.
EDI & the Transitional Period
7. When is EDI seen as compliant?
Non-CEN-intercompatible EDI invoices are tolerated till the end of 2027. Starting from 2028, you will be required to switch to CEN-compliant formats. Please remember that EDIFACT is expected to be declared CEN-compliant, whereas so far this has not happened.
8. For what period will EDI be compliant before the switch to e-invoicing entirely?
EDI is allowed till the end of 2027. It can also be expected that EDIFACT will become CEN-compliant (similar to Spain), as companies cannot replace it that easily with XRechnung, ZUGFeRD or other current CEN-compliant formats.
9. EDIFACT is considered compliant till the end of 2027; is that correct?
This is correct. There is, however, a separate point regarding the CEN compliance of EDIFACT: from a technical point of view, the newest EDIFACT INVOIC is CEN-conformant, but it has not been declared CEN-compliant by the German tax authorities. It is possible that in the future EDIFACT will also be declared CEN-compliant.
Formats & Standards: XRechnung, ZUGFeRD and Peppol BIS
10. What is holding Germany back from evolving to BIS 4 instead of XRechnung 4?
Germany isn’t really choosing between them. They’re parallel tracks that depend on the same upstream standard. XRechnung 4.0 and Peppol BIS 4.0 are both built on the revised EN 16931-1:2026, so neither can finalize before it does.
KoSIT maintains XRechnung as Germany’s national CIUS, while OpenPeppol develops BIS 4.0, which is meant to merge BIS 3.0 and PINT. XRechnung in CII isn’t interchangeable with BIS 3.0, which is UBL-only. German practice, including ZUGFeRD, relies on CII.
XRechnung 4.0 won’t be backward compatible, so migration is a real cost. Realistically, Germany will keep XRechnung as the national layer and align it with BIS 4.0.
11. Compared to EDI, the XRechnung format does not distinguish between the Ordering party, Bill To party and Payer party. Only “Buyer” is allowed. What is the definition of “Buyer” then? Can it be defined as EDI BillTo (NAD+IV)?
EN 16931 requires one single legal entity to be identified as the primary contract partner. Under German VAT law, the BUYER (BG-7) must be the actual legal recipient of the supply (Leistungsempfänger).
12. Does the PDF part of ZUGFeRD need to be exactly the same as the XML part? The XML uses more fields than our current sales invoice PDF. May we use our current PDF for ZUGFeRD and embed the XML in it?
In hybrid invoice formats like ZUGFeRD/Factur-X, the structured XML dataset is strictly leading and dominant. If there is any discrepancy or contradiction between the visual PDF image and the XML data, the XML data prevails legally and operationally. That being said, the PDF visual part does not need to be a 100% field-for-field replica of the XML dataset. The solution is most likely compliant, provided the technical and legal requirements are met.
13. Can we use Peppol BIS and send it through email, without any contract or discussion with the customer?
According to legal requirements – yes. Peppol BIS (e.g. Peppol BIS Billing UBL Invoice V3 or Peppol BIS Billing CII Invoice V3) is EN 16931 compliant, so you can just send it. Please keep in mind that your customer may not be able to read the XML, so there is a clash between what is legally required and what is realistically possible.
Most companies discuss with their partners what format they wish to receive (there is no legal claim to it, as this is done based on the goodwill of the issuer). Please also consider a contractual format definition with your partners, as you can be contractually obliged to deliver one. So far, it has not been answered from the legal side whether such contractual clauses are permitted.
Transmission, Addresses & Agreements with Partners
14. As there is no obligation to send messages via the Peppol network, how are seller/buyer electronic addresses managed in Germany?
In Germany, there is no legal definition of this point. You can send and receive e-invoices as you wish or as you define it with your business partners. This is why, as of today, most German companies stick to sending e-invoices via email, to some extent via Peppol, or they keep their current upload/download supplier/customer portals or EDI. Comarch, however, recommends applying Peppol due to security and transparency reasons (e.g., encryption, MLS statuses if an e-invoice was received/rejected).
15. Do we need any official/signed agreement with customers/suppliers covering the communication process agreed between the parties?
Invoicing clauses are typical for supplier-customer contracts, of course. You can define the format and channel via a contractual clause (e.g., Peppol BIS 3.0 via Peppol or ZUGFeRD 2.5 via email), but you do not have to. In such a case, general provisions of German law apply. From a business point of view, and to maintain good supplier-customer relations, it is recommended to agree on it with your customers/suppliers.
16. When e-invoices are sent through Comarch, are they protected/secured enough that they can’t be intercepted and changed by a malicious third party, so that the e-invoice reaches the receiving party in its original form?
Via Peppol, yes, largely. AS4 messages travel over TLS and are digitally signed using Peppol PKI certificates, so any alteration in transit is detectable and the sender is authenticated. In case of non-Peppol channels (especially email), this is also ensured, whereas increasing email security is a bit more challenging. This is why Peppol is the recommended, safe, and proven channel.
Processing, Archiving & Audit
17. What if we receive an incoming e-invoice (AP flow) in a structured format (XML) through a third party, and it is then “ingested” into our ERP via AI automation into our AP procurement tool (i.e. by reading the PDF equivalent)? Would that still be considered compliant?
This process is correct from a legal point of view. The most important thing is that you receive a CEN-compliant e-invoice. How you process and validate it from a business perspective is your responsibility to ensure it remains compliant.
18. Is it required for a company to store a validation report on outgoing and incoming e-invoices as proof for the tax authorities?
No, storing a formal validation report for outgoing and incoming German e-invoices (E-Rechnung) is not explicitly mandated by law under GoBD or by the tax authority (Finanzamt).
However, you must prove compliance and data integrity. Under GoBD rules, the burden of proof rests on the taxpayer to demonstrate that incoming and outgoing structured files (e.g., XRechnung or ZUGFeRD) were authentic, unaltered, and properly processed upon receipt.
While archiving raw XMLs in an audit-proof system (GoBD-compliant archive) is mandatory, keeping automated validation logs or reports is strongly recommended as best practice during tax audits.
19. How long does the XML need to be archived? Is there a set time period before it can be purged? If it is received via LEDES XML v2.0, is this sufficient?
While the VAT-specific period has been set to 8 years, general accounting record-keeping requirements under the German Fiscal Code (Abgabenordnung – AO) and GoBD continue to require a 10-year retention period for tax-relevant books.
20. Is it OK if the XML is archived in a third-party platform (rather than in our ERP)?
Yes, archiving e-invoices in a third-party platform is fully permissible under German tax law.
Have more questions about Germany’s e-invoicing mandate, XRechnung, ZUGFeRD or Peppol?
