Quick verdict: Both formats are permitted e-invoices under EN 16931. XRechnung is pure XML and mandatory for federal authorities; ZUGFeRD is a PDF/A-3 with embedded XML that people can read alongside. Odoo generates both in the standard and sets the format per customer. Choose XRechnung for public authorities, Peppol and automated recipients, ZUGFeRD for customers where someone reads the invoice.
The choice of format depends mainly on the recipient and how they process invoices. This guide compares XRechnung and ZUGFeRD, explains their implementation in Odoo 17 to 20 and shows the setting in the customer record. Both formats can meet the legal requirements. See the guide to e-invoicing with Odoo for the legal basis and deadlines.
The difference in one table
| Criterion | XRechnung | ZUGFeRD / Factur-X |
|---|---|---|
| Structure | pure XML file, no image part | hybrid: PDF/A-3 with embedded XML file |
| Readable without software | no | yes, the PDF image |
| Leading part | XML | XML (BMF circular of 15 Oct 2024, para. 31) |
| Profiles | none; XRechnung is the German specialisation (CIUS) of EN 16931 | several; MINIMUM and BASIC-WL do not count as e-invoices (paras. 25 and 30), all other profiles from version 2.0.1 do – e.g. EN 16931 (COMFORT), EXTENDED and XRECHNUNG |
| Permitted as e-invoice | yes (paras. 25 and 30) | yes from version 2.0.1, excluding MINIMUM and BASIC-WL (paras. 25 and 30) |
| Current version | 3.0.2, version of 31 Aug 2026 | 2.5.2, valid from 1 Sep 2026, identical to Factur-X 1.09.2 |
| Mandatory towards federal authorities | yes (§ 4 (1) ERechV) | no |
| State of Baden-Württemberg | yes | yes in the XRECHNUNG, EN 16931 (COMFORT) and EXTENDED profiles |
| Generation in Odoo | UBL syntax; Odoo 18–20 with XRechnung 3.0 identifier, Odoo 17 with 2.2 reference | CII syntax; EXTENDED profile only, no profile selector |
| Setting in Odoo | customer record → Accounting tab → Format | customer record → Accounting tab → Format; the XML is in every invoice PDF anyway |
| Transmission from Odoo | Peppol (XRechnung CIUS) or e-mail | e-mail as PDF attachment |
| Validation | KoSIT validator with the XRechnung configuration of 31 Aug 2026 | check the XML against EN 16931 and the PDF/A-3 compliance of the container |
| Recipient side | receiving system translates the XML into an invoice form | opening the PDF suffices for reading; posting is done from the XML |
For context: XRechnung is the standard the German public sector has set for its invoice receipt. ZUGFeRD comes from the business community; its current version 2.5.2 is identical to the French Factur-X 1.09.2 (FeRD, 4 August 2026). Both implement the European standard EN 16931, which § 14 (1) sentence 6 UStG references. The standard knows two syntaxes, UBL and CII; Odoo produces XRechnung in UBL and Factur-X in CII. For the recipient the syntax is immaterial – both are permitted.
The two standards are also maintained separately. KoSIT keeps XRechnung 3.0 in force until at least 31 July 2027 and published a preliminary version of XRechnung 4.0 in September 2026; the final version is expected in spring 2027 (xeinkauf.de). ZUGFeRD 2.5.2 has applied since 1 September 2026 (FeRD). Anyone issuing both formats therefore tracks two release calendars – an argument for making the choice per customer deliberately rather than sending both formats to the same recipient.
The decision in five questions
- Is the recipient a federal authority? Then XRechnung – no alternative (§ 4 (1) ERechV), with the Leitweg-ID in BT-10.
- Is the recipient a state or municipal authority? Check the state's requirement. Baden-Württemberg accepts XRechnung and ZUGFeRD in the XRECHNUNG, EN 16931 (COMFORT) and EXTENDED profiles (service-bw.de). When in doubt, XRechnung.
- Do you send via Peppol? Then XRechnung: via Peppol Odoo sends BIS Billing 3.0, XRechnung CIUS and NLCIUS (Odoo documentation 19.0), not ZUGFeRD.
- Does a person at the customer read the invoice before it is posted? Then ZUGFeRD: the PDF image keeps the approval workflow intact, and the XML is still processed by machine.
- Does the customer have an automated receiving system and no requirement? Then XRechnung: no image part, no PDF/A-3 container that could be faulty.
Record the answers for each customer, then store the selected format in their Odoo customer record.
When XRechnung
Public authorities. Invoices to federal authorities must be issued as XRechnung "in its current version" (§ 4 (1) ERechV), with the recipient's Leitweg-ID in field BT-10 (§ 5 (1) no. 1 ERechV). The federal states regulate their receipt themselves; Baden-Württemberg accepts XRechnung as well as ZUGFeRD in three profiles. For public-sector customers XRechnung is the safe choice: the federal government requires it, the state accepts it, and there is no image part that could deviate from the data set.
Peppol. Over the Peppol network Odoo sends the formats BIS Billing 3.0, XRechnung CIUS and NLCIUS according to the 19.0 documentation – ZUGFeRD is not on that list. Anyone choosing Peppol over e-mail (DATEV calls e-mail transmission "vulnerable") therefore uses XRechnung for German recipients. How to register is covered in the guide Registering for Peppol in Odoo.
Automated recipients. When the receiving system processes invoices entirely by machine, it does not need an additional visual representation. Pure XML avoids possible differences between that representation and the data.
Error classes. The BMF circular of 15 October 2025 distinguishes format errors (para. 6a), business-rule errors (para. 6b) and content errors (para. 35a). For XRechnung the KoSIT validator checks format and business rules; you keep the report as evidence (para. 35a).
When ZUGFeRD
Staff review. ZUGFeRD suits workflows where a person checks and approves the invoice. The PDF remains readable while the embedded XML is available for automated processing.
Existing customers. If you already email PDF invoices, ZUGFeRD lets you keep that transmission route. Recipients can read the invoice and also process its embedded XML data.
France. For its e-invoicing mandate – reception for all companies since 1 September 2026 – France permits UBL, CII and hybrid formats (impots.gouv.fr). Factur-X is the hybrid format and technically identical to ZUGFeRD. Anyone serving German and French customers from one Odoo database uses the same technology for both.
Caveat. The image part is a convenience, not a legal basis. If PDF and XML differ, the XML prevails (para. 31), and accounting must not rely on the image (IHK Lüneburg-Wolfsburg). And the PDF/A-3 container must be right: on 20 January 2026 the Verband elektronische Rechnung found around 18 % of ZUGFeRD invoices in e-mail traffic to be faulty, chiefly due to "non-compliant use of the mandatory PDF/A-3 standard" – an error class that does not exist for XRechnung.
How to set the format per customer in Odoo
Odoo stores the format for each customer individually, so XRechnung and ZUGFeRD can be used alongside each other in the same database.
- Open the customer record. On the customer, switch to the Accounting tab and select the e-invoice format in the Format field (Odoo documentation 17.0): XRechnung (UBL) or Factur-X (CII).
- Know the default. Even without a selection, according to the 17.0 documentation "every PDF generated by Odoo includes an integrated Factur-X XML file". A customer without a format choice therefore already receives a ZUGFeRD-capable file in the EXTENDED profile.
- Complete public-sector customers. Store the Leitweg-ID. In Odoo 20 it is written into BT-10 automatically when addressing scheme 0204 is selected. In Odoo 17 to 19, BT-10 stays empty and is output as "N/A"; an empty buyer reference is a business-rule error (BMF circular of 15 October 2025, para. 6b) that you must close before sending to authorities.
- Check a test invoice. Generate one test invoice per format. Check XRechnung with the KoSIT validator and the configuration of 31 August 2026; for Factur-X check the XML against EN 16931 and the PDF container for PDF/A-3. Keep the reports.
- Fix the transmission channel. XRechnung goes via Peppol or e-mail, ZUGFeRD via e-mail. Under the BMF circular of 15 October 2024 (para. 36) an interface, a shared storage location or a download portal are also permissible.
Anyone working with Odoo 17 checks XRechnung files with particular care: the source code of that version still references the XRechnung 2.2.0 schematron, while Odoo 18 to 20 carry the identifier for XRechnung 3.0.
Typical mistakes
Broken PDF/A-3 container. By far the most frequent cause of errors with ZUGFeRD (VeR, 20 January 2026). Check the container with a validator, not just the XML. Faulty files count as format errors and thus as other invoices (BMF circular of 15 October 2025, para. 6a) – with consequences for your customer's input VAT deduction.
MINIMUM and BASIC-WL profiles. They do not count as e-invoices (BMF circular of 15 October 2024, paras. 25 and 30). Odoo does not produce them – but watch for incoming invoices from suppliers using other software.
Checking only the image. If the visible PDF and the data set differ, accounting must not rely on the image part alone (IHK Lüneburg-Wolfsburg). Post from the imported XML.
Empty BT-10 to public authorities. Up to Odoo 19 it reads "N/A". For B2B this is immaterial – no Leitweg-ID is needed here according to the BMF FAQ, and a missing BT-10 is irrelevant for VAT purposes (para. 35a). For public authorities the Leitweg-ID is mandatory.
Sending XRechnung from Odoo 17 unchecked. The older schematron reference can lead to deviations from the current configuration. Validate before go-live.
The recipient side: what your accounting team may accept
The format question also arises in reverse. Since 1 January 2025 you must be able to receive e-invoices, and from 2027 your own input VAT deduction depends on the format of the incoming invoice: an other invoice where an e-invoice was mandatory does not in principle entitle you to deduct input VAT (BMF circular of 15 October 2024, para. 56). Your accounting team must therefore recognise what it receives.
- XRechnung from suppliers: the XML file arrives by e-mail or Peppol. Odoo converts it into a draft vendor bill on import; no OCR credits are consumed (Odoo documentation 19.0).
- ZUGFeRD from suppliers: the PDF contains the XML. Post from the XML, not from the image (para. 31). If you receive a ZUGFeRD PDF in the MINIMUM or BASIC-WL profile, it is not an e-invoice (paras. 25 and 30) – from 2027 request a compliant file once the supplier is obliged to issue.
- PDF without XML: an other invoice (para. 7). Until the end of 2026 it is permissible with your consent (§ 27 (38) no. 1 UStG); from 2027 only from suppliers below the turnover threshold or in the exempt cases, such as low-value invoices up to €250.
- Duty to check: technical validation does not replace "the recipient's duty to check" (BMF circular of 15 October 2025, para. 35a). You may rely on the technical result; keep the report.
Good-faith protection applies if you could assume that your supplier was using a transitional rule under § 27 (38) UStG (BMF circular of 15 October 2024, para. 59). A note on the supplier record recording who already issues e-invoices saves queries.
Both in parallel
Different formats can coexist in daily operation: for example, XRechnung via Peppol for public authorities, ZUGFeRD by email for business customers and Factur-X for French customers. Odoo uses the setting selected in each customer record.
The same applies on the incoming side: an e-mail alias accepts PDF and XML files and creates draft vendor bills; XML requires no OCR credits, and Peppol receipts land automatically in the purchase journal (Odoo documentation 19.0). How to set up this route is covered in the guide Automating incoming invoices.
For archiving the format is secondary too: invoices must be retained for eight years, and at least the structured part must remain intact in its original form (BMF circular of 15 October 2025, para. 60). For ZUGFeRD that means the complete PDF/A-3 file with its XML – not a printout or a regenerated PDF.
Next step
Try both formats with sample invoices in an Odoo trial database, available free at odoo.com with Ruetech registered as your partner. For a supported rollout by 1 January 2027 with acceptance at each stage, start with the readiness check or a consultation.
Request an e-invoicing consultation – we reply within one business day.