Germany

Legal Requirements

Germany introduced mandatory B2B eInvoicing with the Wachstumschancengesetz (2024).
It uses a phased approach for introduction:

• 2025-01-01 (active)
  • Paper invoices no longer have priority
  • Each business MAY send electronic invoices (compliant to the law)
  • Each business MUST be able to receive electronic invoices (compliant to the law)
  • Other electronic formats (like PDF) MAY be used if both parties consent
• 2027-01-01
  • Businesses with a turnover > € 800 000 MUST send electronic invoices
  • Businesses with a turnover ≤ € 800 000 MAY continue to send other invoices
• 2028-01-01
  • All businesses MUST send electronic invoices
  • EDI systems MUST be adopted to the legal requirements.

On top of this timeline the VIDA requirements (mandatory cross-border electronic invoices per ~2030) will be added.

The following information from the German Ministry of Finance might also be helpful:

• Official statement on the usage of electronic invoices for German domestic B2B exchanges: official BMF page (German only)
• Official FAQs from the Ministry of Finance: FAQ on mandatory e-Invoicing per January 2025

e-Invoice Formats

The EN 16931 invoice formats are considered the baseline for e-Invoices.
Germany uses XML and hybrid invoice formats. The German specific XML-format is called XRechnung (don't translate to X-Invoice or so!) and the hybrid format (XML inside PDF) is called ZUGFeRD.
Personally, I recommend to use XRechnung as it is an easy-to-use XML format with a clear versioning and good documentation.

XRechnung

XRechnung is an XML based invoice format based on EN 16931. It is maintained by KoSIT (Koordinierungsstelle für IT-Standards), a government unit located in the city of Bremen. The official website is https://xeinkauf.de/xrechnung/.

Here are some facts around XRechnung

• Latest version: 3.0.2
• Downloads: https://xeinkauf.de/xrechnung/
• Development repositories: https://projekte.kosit.org/xrechnung/ and https://github.com/itplr-kosit/
• Validation rules: XML Schema and Schematron rules are available.
  • via the online tool ecosio Validator
  • via the online API provided on this site
  • via the download tool KoSIT Validator, requiring a Java runtime. Additionally, you need the XRechnung validation rules to perform actual validation.
• Visualization: several XSLT based solutions are available. See the collection of open source visualization tools for more details.
• Supported in Peppol: yes

Older versions of the XRechnung specification are also available, but it is recommended to always stay on the latest version.
Both the current and the old versions of XRechnung are following the EN 16931 rules.
Note: XRechnung comes in two general shapes - "regular" and "extension". Try to only use the regular (or CIUS) version - the extension requires bilateral agreement and are for specific use cases only.

ZUGFeRD

ZUGFeRD is a hybrid invoice. It is a PDF A/3 with an XML included.

Here are some facts around ZUGFeRD

• Latest version: 2.3.2
• Downloads: https://www.ferd-net.de/download-zugferd
• Development repository: not public
• Validation rules: XML Schemas and Schematron rules are available
• Visualization: as the PDF is an integral part of the format, no additional visualization is needed
• Supported in Peppol: yes, but only as Factur-X invoices between French end users

Here are some common-sense drawbacks of ZUGFeRD:

• By using PDF with an embedded XML, it's hard for non-technical people to access the primary electronic invoice. Especially nowadays where browsers and mail clients directly render the PDF, the access to the embedded file may even be impossible.
• People receiving a ZUGFeRD invoice may not even know, that they receive an electronic invoices because the attachment is well hidden.
• Transmitted data is obviously larger, compared to plain XML transmission.
• The versioning of ZUGFeRD invoices is very bad. All instances of ZUGFeRD 2.x use the same specification identifier so there is no way to pick the correct validation rules and you need to assume to always uses the latest version validation rules.
• Old versions of the specification are not officially available. Currently only the latest two versions can be accessed
• Each ZUGFeRD version comes in 5 different profiles (Minimum, Basic WL, Basic, EN 16931 and Extended), of which two (Minimum and Basic WL) are not even sufficient to fulfill the German legal requirements on invoices (so why specify them???).
• Earlier versions of ZUGFeRD did not build on top of the EN16931 that's why they are not considered valid electronic invoices. Only ZUGFeRD invoices using version 2.0.1 and later using one of the profiles "Basic", "EN 16931" and "Extended" are consider electronic invoices in Germany.
• ZUGFeRD and Factur-X try to share the same specification, but use different Customization IDs.
• The name of the XML invoice inside the ZUGFeRD PDFs changed from 2.0.1 (zugferd-invoice.xml) to 2.1 (factur-x.xml) - this is a backwards incompatible change
• ZUGFeRD created an "XRechnung profile" which means a PDF including an XRechnung XML invoice - this heavily adds to the confusion.
• The German Ministry of Finance clarified, that the PDF part of a hybrid invoices can be discarded - only the XML part is relevant and requires archiving etc. So why send it in such a complicated structure?

Personal recommendations

Of course I totally understand that receiving a PDF makes it easier, especially for SMEs. Therefore, my recommendation - if you believe the receiver is not able to handle the XML properly - is to send an XML and a PDF next to each other (like two attachments of an email). Compared to the "XML in PDF" version of ZUGFeRD it's quite obvious for the receiver what is the original invoice (XML) and what is the copy (PDF).