# Which e-invoice formats are usable in Germany in 2026? - Date: 2026-04-20 - Reading time: 7 min read A practical Germany format guide for April 2026: when to use XRechnung, ZUGFeRD, UBL or CII, what still counts as a non-structured invoice, and how to ## Article overview This article explains Which e-invoice formats are usable in Germany in 2026? as a practical reference for European e-invoicing. It defines the topic in plain language, places it in the compliance context, and connects the explanation to invoice formats such as XRechnung, ZUGFeRD/Factur-X, UBL, and CII. This guide is for businesses invoicing German customers that need a practical answer, not a format list copied from standards documents. As of April 20, 2026, businesses in Germany must be able to receive structured e-invoices for domestic B2B transactions. Issuers can still use the statutory transition rules, so 2026 is the time to decide which structured formats you can actually produce, validate, and support in day-to-day operations. ## How to use this guide Use the article as a starting point before changing a finance or ERP workflow: identify the applicable country rule or standard, decide which structured format is expected, validate the generated XML, and keep a documented exception process for invoices that require manual review. ## First answer: what counts as an e-invoice in Germany The German BMF FAQ defines an e-invoice as a structured electronic format that enables electronic processing and complies with EN 16931 or is interoperable with it. A plain PDF is still an electronic document, but since January 1, 2025 it is classified as a “non-e-invoice” (sonstige Rechnung), not as a structured e-invoice. That is why the practical question is not "Can I email a PDF?" but "Can my process generate structured invoice data that the recipient can process and a validator can check?" ## The formats most teams should care about For The formats most teams should care about, review these points before moving on. - **XRechnung**: the standard choice for many German public-sector workflows and other XML-first processes where the recipient needs structured data rather than a PDF-led document. - **ZUGFeRD / Factur-X**: useful when you need a human-readable PDF plus embedded structured invoice data in one document. - **UBL**: relevant for PEPPOL or recipient channels that standardize on UBL syntax. - **CII**: relevant where your tooling or recipient ecosystem is built around Cross Industry Invoice syntax. ## How to choose the right format For How to choose the right format, this sequence gives the practical order of work. - Start with the recipient requirement, not your preferred format. Some recipients or channels are explicit. - Choose XRechnung when the target process is a German public-sector workflow or another XML-first process that does not rely on the PDF itself. - Choose ZUGFeRD when the recipient wants a readable PDF and your team still needs structured data for automation and validation. - Choose UBL or CII when your transmission channel, PEPPOL setup, or trading partner ecosystem already standardizes on that syntax. - Validate the output with the relevant rule set before you decide the format is ready for production. ## What does not solve the problem on its own For What does not solve the problem on its own, review these points before moving on. - Sending a standard PDF and assuming it has become compliant because it was created electronically. - Picking one format globally without checking the recipient channel or buyer requirement. - Manually editing XML after validation failures instead of fixing the source data or mapping logic. - Skipping a review step for invoices with weak source quality, discounts, mixed VAT treatments, or missing buyer identifiers. ## Official baseline for Germany Use the [BMF FAQ on Germany’s mandatory e-invoicing rules from January 1, 2025](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html) as the legal baseline for domestic B2B invoicing. For practical rollout, pair that legal view with your recipient requirements, validator output, and internal exception process. ## Test the format before you lock the rollout Invoice-Converter.com lets teams test XRechnung, ZUGFeRD, and UBL conversion paths against real invoice inputs so you can decide based on recipient fit and validator results, not guesswork. [Compare conversion paths](/en/convert) ## FAQ ### Is a normal PDF an e-invoice under the German 2026 rules? No. In the domestic B2B context, an e-invoice must use a structured electronic format that supports electronic processing. A plain PDF is classified as a non-e-invoice (sonstige Rechnung) and does not meet that standard by itself. ### Should I always choose XRechnung for Germany? Not always. XRechnung is required or preferred in many German public-sector and XML-first workflows, but some B2B flows are better served by ZUGFeRD or another EN 16931-compatible format, depending on the recipient’s requirements. ### Can one ERP output support multiple German invoice formats? Yes, if your mapping layer is designed for it. Many teams keep one source invoice model and generate different structured outputs depending on the customer and channel. ## Official references - [BMF E-Rechnung FAQ](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html) - [KoSIT XRechnung releases](https://github.com/itplr-kosit/validator-configuration-xrechnung/releases) - [FNFE-MPE Factur-X resources](https://fnfe-mpe.org/factur-x/)