E-Invoicing with Odoo: XRechnung, ZUGFeRD and Peppol

Quick verdict: Since 1 January 2025 every business established in Germany must be able to receive e-invoices. From 1 January 2027 businesses with prior-year turnover above €800,000 must issue them; from 2028 everyone must. Odoo generates XRechnung and ZUGFeRD from version 17, and Peppol registration is free. The work lies in master data, validation and archiving – not in the software.

This guide helps management, finance and IT plan e-invoicing in Odoo. It explains the legal deadlines, the standard capabilities of versions 17 to 20 and the setup process. Deadlines and legal provisions are accompanied by their sources. Your tax adviser assesses your individual circumstances; Ruetech handles the technical implementation.

What applies from when

The e-invoicing obligation for domestic business-to-business supplies stems from the Wachstumschancengesetz (BGBl. 2024 I Nr. 108 of 27 March 2024). Under § 14 (2) sentence 2 no. 1 UStG it applies when both the supplier and the recipient are established in Germany. The legislator phased the introduction (§ 27 (38) UStG):

The threshold refers to total turnover under § 19 (2) UStG in the preceding calendar year. A company with more than €800,000 total turnover in 2026 issues e-invoices from 1 January 2027. Anyone below the threshold has one more year – but must switch by 1 January 2028 as well.

There is no transition on the receiving side. Since 1 January 2025 every business established in Germany must be able to accept an e-invoice. Under the BMF circular of 15 October 2024 (para. 40) an e-mail inbox is sufficient. This also applies to small businesses (Kleinunternehmer): they may continue to issue other invoices but "must nevertheless be able to receive e-invoices" (BMF FAQ, as of 23 March 2026).

A fine is provided for: anyone who fails to issue an invoice, or fails to issue it on time, contrary to § 14 (2) sentence 2 UStG risks a fine of up to €5,000 under § 26a (2) no. 1 UStG. In practice a different risk weighs heavier: an other invoice issued where an e-invoice was mandatory does not in principle entitle the recipient to deduct input VAT (BMF circular of 15 October 2024, para. 56). From 2027 your customers therefore have a tangible reason to reject non-compliant invoices. That is the mechanism that enforces the change in the market – not the fine.

For the managing director this means: the deadline is in the statute and does not move with the project plan. For the IT lead: the receiving channel must work today. For the finance lead: from 2027 your own input VAT deduction depends on the format of incoming invoices.

What an e-invoice is – and what it is not

§ 14 (1) sentence 3 UStG defines an electronic invoice as "an invoice that is issued, transmitted and received in a structured electronic format and enables electronic processing". Everything else is an "other invoice" (sonstige Rechnung) – including the PDF attached to an e-mail. The BMF is explicit: a PDF without embedded structured data is an other invoice (BMF circular of 15 October 2024, para. 7).

Under § 14 (1) sentence 6 UStG the format must comply with the European standard EN 16931, referenced by Directive 2014/55/EU. Alternatively, issuer and recipient may agree on another format, provided a "correct and complete extraction" of the invoice data is possible.

Permitted formats

In hybrid formats such as ZUGFeRD the XML part is the leading part (BMF circular of 15 October 2024, para. 31). If the PDF image and the data set differ, the data set prevails. Your accounting team must therefore not rely on the image alone (IHK Lüneburg-Wolfsburg).

XRechnung 3.0 remains in force until at least 31 July 2027. KoSIT published a preliminary version of XRechnung 4.0 in September 2026; the final version is expected in spring 2027 (xeinkauf.de). For validation, KoSIT provides validator 1.6.3 and the XRechnung configuration of 31 August 2026 (EN 16931 schematron 1.3.16).

Three classes of error

The BMF circular of 15 October 2025 distinguishes three types of error that your accounting team must keep apart:

• Format error (para. 6a): the file does not comply with the standard. The invoice counts as an other invoice – with the consequences for input VAT deduction.
• Business-rule error (para. 6b): the file breaches a business rule of the standard, e.g. an empty "BT-10 Buyer reference".
• Content error (para. 35a): a mandatory field is missing or wrong. The invoice is then not proper. A missing BT-10, by contrast, is "irrelevant for VAT purposes".

All mandatory fields must sit in the structured part; a link to an external document is not enough (para. 35). The transmission channel is free: e-mail, interface, shared storage location or download portal (BMF circular of 15 October 2024, para. 36).

Exemptions

The obligation to issue has exemptions. In these cases you may continue to issue an other invoice:

No exemption applies, however, to self-billing credit notes under § 14 (2) sentence 5 UStG, to supplies under § 13b (reverse charge), § 24, § 25 and § 25a UStG, or to invoices addressed to small businesses or landlords (BMF circular of 15 October 2025, para. 17). Anyone supplying a small business therefore issues an e-invoice to them once the obligation to issue applies to the supplier.

What Odoo can do – by version

The e-invoicing functions for Germany are not part of the German localisation. The documentation page on the Germany localisation contains no e-invoicing section in versions 17 to 20, and Germany is absent from the list of country-specific e-invoicing details (Odoo documentation 19.0 and 20.0). There is no l10n_de_edi module. Generation of XRechnung and Factur-X lives in the generic account_edi_ubl_cii module, which is part of Odoo Community from 17.0 to 20.0.

The XRechnung and Factur-X details come from the module's source code in branches 17.0 to 20.0. Odoo 18, 19 and 20 carry the identifier urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Odoo 17 builds on Peppol BIS 3 and still references the older schematron de.xrechnung:ubl-invoice:2.2.0. Anyone issuing from Odoo 17 therefore validates invoices against the current KoSIT configuration with particular care before go-live. For Factur-X all four versions use the identifier urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended – Odoo produces the EXTENDED profile and offers no profile selector. That is permissible; EXTENDED is not among the excluded profiles.

The Odoo 20 release notes (September 2026) contain no entry on Germany or XRechnung. The most important change for German users is in the source code: Odoo 20 writes the Leitweg-ID stored on the customer into field BT-10 automatically when addressing scheme 0204 is selected. Up to version 19, BT-10 stays empty and is output as "N/A".

Peppol

According to the Odoo 19.0 documentation, Odoo acts as both Peppol access point and SMP. Registration is free and available in Odoo Community; Germany is among the eligible countries. Supported formats for sending are BIS Billing 3.0, XRechnung CIUS and NLCIUS. Incoming documents are checked several times a day and imported automatically as drafts into the purchase journal. A demo mode with an "Odoo Demo ID" is available for testing. Anyone already registered with another access point must deregister there first. Odoo SA is listed by OpenPeppol as "AP Certified" and "SMP Certified". The documentation says nothing about per-document fees or volume caps. Our guide Registering for Peppol in Odoo covers the registration step by step.

Incoming invoices

An e-mail alias converts incoming PDF and XML files into draft vendor bills. XML files require no OCR credits; OCR recognition of PDF images is a paid IAP service at one credit per document (Odoo documentation 19.0). Since Odoo 19, imported bills are matched against the purchase order. Details in the guide Automating incoming invoices with Odoo.

DATEV

The German localisation l10n_de (Community) provides the GoBD audit trail. The Enterprise module l10n_de_reports delivers the "DATEV DATA (ZIP)" and "DATEV ATCH (ZIP)" exports for your tax adviser. How the handover to DATEV works in detail is covered in the guide Odoo DATEV integration.

What Odoo does not provide

• No profile selector for Factur-X. Odoo produces EXTENDED only. Anyone needing another profile requires a customisation.
• No built-in validation report. KoSIT validation runs outside Odoo; you keep the report as evidence (BMF circular of 15 October 2025, para. 35a).
• No Factur-X for self-billing vendor bills. For vendor bills you issue yourself as self-billing credit notes, Odoo generates no Factur-X file according to a forum report on Odoo Online 19.2 Enterprise.
• No Leitweg-ID mapping before version 20. For Odoo 19 a third party sells a module l10n_de_e_invoice with ISO/IEC 7064 check-digit validation for 499 US dollars – an indication of how many users have to close this gap.

E-invoice generation and Peppol connectivity are included in Community. Planning therefore centres on master data and validation. The standard functions remain available through version upgrades.

Setting up Odoo in six steps

1. Check master data

All mandatory invoice fields must sit in the structured part (BMF circular of 15 October 2025, para. 35). First check your own company in Odoo: full name, address, VAT identification number or tax number, bank details. Then the customers: VAT identification number, invoice e-mail, and for public authorities the Leitweg-ID. Incomplete master data is the most common cause of content errors – and the software cannot invent it.

2. Set the invoice format per customer

In Odoo the e-invoice format is set per customer: on the customer record, Accounting tab, Format field (Odoo documentation 17.0). The options are XRechnung (UBL) and Factur-X (CII, EXTENDED profile). Even without this setting, according to the 17.0 documentation every invoice PDF generated by Odoo includes an embedded Factur-X XML file. Public authorities require XRechnung; for business customers their receiving system decides. The criteria are in our decision guide XRechnung or ZUGFeRD.

3. Register for Peppol

Peppol is not mandatory for B2B invoices, but it is the more robust route: DATEV calls e-invoices sent by e-mail "vulnerable" (DATEV guide, as of 03/2026). Register in demo mode first, verify receipt, then switch to live operation. You do not need a Leitweg-ID for B2B traffic (BMF FAQ, as of 23 March 2026).

4. Generate and validate a test invoice

Generate one test invoice per format to a real customer with real master data. Check the XML file with KoSIT validator 1.6.3 and the XRechnung configuration of 31 August 2026. For Factur-X, additionally check whether the PDF container is PDF/A-3 compliant – 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 PDF/A-3 standard. Keep the validation report: the BMF states that a business "may rely on the technical result of a validation" and that "it is advisable to keep the validation report as evidence" (BMF circular of 15 October 2025, para. 35a). Also have the test invoice read in by a customer's receiving system.

5. Set up incoming invoices

Set up the e-mail alias for incoming bills and share the address with your suppliers. Invoices arriving via Peppol land automatically as drafts in the purchase journal. Define who reviews the drafts: validation does not replace "the recipient's duty to check" (BMF circular of 15 October 2025, para. 35a). From Odoo 19, purchase-order matching makes this review easier.

6. Settle the archiving

Invoices must be retained for eight years (§ 14b UStG). Under the BMF circular of 15 October 2025 (para. 60), at least the structured part must be kept "so that it remains intact in its original form". In Odoo the XML file sits as an attachment on the record; the l10n_de localisation logs changes. The BMF also notes that storage outside a GoBD-compliant system is, for VAT purposes alone, "not a breach" (para. 60) – your other bookkeeping duties are unaffected. An e-mail inbox is not an archive.

The ten most common mistakes

1. "A PDF by e-mail is an e-invoice, isn't it?" It is not (BMF circular of 15 October 2024, para. 7; DATEV: "A PDF is not an e-invoice"). In Odoo you set the format per customer; every generated PDF then contains the Factur-X XML, or you send the XRechnung file.

2. "We only receive, so we are not affected." The obligation to receive has applied to everyone since 2025, including small businesses (DATEV guide, BMF FAQ). And the obligation to issue is coming: 2027 above €800,000 prior-year turnover, 2028 for everyone. In Odoo: set up the e-mail alias, register for Peppol, check the turnover threshold for 2027.

3. The e-mail inbox as archive. The XML file must remain intact for eight years (para. 60). An inbox does not achieve that. In Odoo: XML as attachment on the record, retention period documented.

4. Checking only the PDF image. If image and data set differ, the data set prevails (para. 31; IHK Lüneburg-Wolfsburg). In Odoo: import the vendor bill from the XML file, do not retype it from the PDF.

5. Leitweg-ID confusion. No Leitweg-ID is needed in B2B (BMF FAQ). In B2G it is mandatory in BT-10 (§ 5 (1) no. 1 ERechV). And the state's "Zentraler Rechnungseingang Baden-Württemberg (ZRE)" is not the decommissioned federal ZRE. In Odoo 20: store the Leitweg-ID on the customer; in 17 to 19: have BT-10 added.

6. Wrong ZUGFeRD profile or broken PDF/A-3 container. MINIMUM and BASIC-WL are not e-invoices (paras. 25 and 30); 18 % of ZUGFeRD invoices are faulty, mostly because of the PDF/A-3 container (VeR, 20 January 2026). In Odoo: EXTENDED is the default and permissible; check PDF/A-3 with a validator.

7. E-mail instead of Peppol. E-mail transmission is "vulnerable" (DATEV). According to Bitkom, on 3 December 2024 only 45 % of companies could receive e-invoices and 5 % used XRechnung. In Odoo: Peppol is free and in the Community scope.

8. Blind trust in validation. You may rely on the technical result, but the duty to check the content remains (para. 35a); an other invoice does not entitle you to deduct input VAT (para. 56). In Odoo: review step in draft status, validation report as attachment.

9. Forgetting recurring invoices. For contracts and continuing obligations, one e-invoice for the first partial-performance period with the contract attached is sufficient; other recurring invoices issued before 2027 remain valid as long as the details do not change (paras. 44–46). In Odoo: first invoice as e-invoice with the contract attached.

10. Corrections as PDF. A correction must itself be an e-invoice and reference the original unambiguously (para. 57); early-payment discounts need no correction (para. 51a). In Odoo: create the credit note from the original invoice and check the reference in the XML.

Special cases

Recurring invoices and contracts

Contracts can be regarded as invoices (BMF circular of 15 October 2024, paras. 44–46). For a continuing obligation – rent, maintenance, licences – one e-invoice for the first partial-performance period is sufficient, with the contract attached. For recurring invoices issued before 1 January 2027 as other invoices, "there is no obligation to issue an additional e-invoice as long as the invoice details do not change". If the amount or the scope of supply changes, you issue a new e-invoice.

Credit notes and special supplies

The rules also apply to self-billing credit notes under § 14 (2) sentence 5 UStG, to reverse charge under § 13b, to flat-rate farming under § 24, to travel services under § 25 and to margin-scheme supplies under § 25a UStG, as well as to invoices addressed to small businesses and landlords (BMF circular of 15 October 2025, para. 17).

Corrections

A correction is made as an e-invoice with a "specific and unambiguous reference" to the original invoice and takes effect retroactively (BMF circular of 15 October 2024, para. 57). Changes to the taxable amount under § 17 UStG, such as early-payment discounts, require no correction (BMF circular of 15 October 2025, para. 51a). Changes to the scope of supply do require one – optionally as a credit note referencing the original under § 31 (5) UStDV (para. 51b).

Input VAT deduction

An other invoice issued where an e-invoice was mandatory does not in principle entitle the recipient to deduct input VAT (BMF circular of 15 October 2024, para. 56). It is cured by an e-invoice referencing the original (para. 57). Good-faith protection applies if the recipient could assume that the issuer was using a transitional rule under § 27 (38) UStG (para. 59). For your accounting team from 2027 this means: check incoming invoices above €250 from domestic suppliers for a structured file.

Invoices to the federal government (B2G)

Invoices to federal authorities are governed by the E-Rechnungsverordnung. Issuers have been obliged since 27 November 2020 (§ 3 (1) in conjunction with § 11 (3) ERechV); direct awards up to €1,000 are exempt (§ 3 (3) no. 1). The format is XRechnung "in its current version" (§ 4 (1)), and the recipient's Leitweg-ID is mandatory (§ 5 (1) no. 1). It goes into field BT-10 and consists of coarse address, fine address and check digit, e.g. 991-1234512345-06; issuers need no Leitweg-ID of their own (e-rechnung-bund.de). The ZRE and OZG-RE platforms were merged in September 2025; the federal ZRE was switched off at the end of 2025, leaving OZG-RE. The federal states regulate their own invoice receipt.

Baden-Württemberg

Issuers invoicing state authorities in Baden-Württemberg have generally been obliged to e-invoice since 1 January 2022 (service-bw.de). Invoices up to €1,000 net are exempt until 31 December 2026; from 1 January 2027 the threshold falls to €250 gross. The state accepts ZUGFeRD only in the XRECHNUNG, EN 16931 (COMFORT) and EXTENDED profiles. Transmission channels are web upload, e-mail and Peppol via the state's own "Zentraler Rechnungseingang Baden-Württemberg (ZRE)". The acronym is the same as that of the decommissioned federal platform – a frequent confusion. Via Peppol you reach the state's receipt without a portal upload; Odoo 20 fills in the Leitweg-ID automatically. The EXTENDED profile that Odoo produces is one of the three profiles the state accepts.

France, Austria, Switzerland, EU

For entities or customers abroad, account for each country’s requirements. A single Odoo database can store formats by customer and legal entity.

France. Since 1 September 2026 all companies must receive e-invoices; large companies and ETIs issue them. PMEs and micro-enterprises follow on 1 September 2027. Exchange runs through a "plateforme agréée", a private company registered by the state; UBL, CII and hybrid formats are permitted (impots.gouv.fr). Odoo is on the DGFiP list of platforms meeting all conditions including the interoperability tests (registration number issued 15 April 2026; list modified 22 September 2026). Factur-X and ZUGFeRD are technically identical – ZUGFeRD 2.5.2 corresponds to Factur-X 1.09.2.

Austria. Invoices to the federal government have had to be electronic since 1 January 2014 (§ 5 IKT-Konsolidierungsgesetz), in ebInterface or UBL via the Unternehmensserviceportal or Peppol. No obligation towards other recipients arises from this (erechnung.gv.at). For B2B: "Austria currently has no national e-invoicing obligation" (EY Austria, 18 August 2026).

Switzerland. No B2B mandate. The ESTV treats paper, electronic and digital invoices equally for VAT; electronic records have the same evidential value provided the GeBüV requirements are met; the retention period is ten years (MWST-Info 16, section 1.4.2). Suppliers to the federal administration have issued electronically since 1 January 2016 for contract values above CHF 5,000. The QR-bill is a payment part, not an EN 16931 e-invoice.

EU. The "VAT in the Digital Age" (ViDA) package was adopted on 11 March 2025 and has been in force since 14 April 2025 (Directive (EU) 2025/516). From 1 July 2030 digital reporting and e-invoicing apply to intra-EU B2B supplies; national systems are harmonised by 1 January 2035.

How we proceed

Ruetech issues its own invoices as e-invoices and has implemented Odoo e-invoicing for clients in Germany and abroad. Our work follows five steps:

1. Readiness check. Questions on turnover, customer structure, Odoo version, incoming invoices and archiving give an initial assessment of your current setup, with an immediate result. Open the readiness check.
2. Setup. Master data, format per customer, Peppol registration, Leitweg-IDs for public-sector customers – in the order above, with acceptance per step.
3. Test run. Test invoices per format, KoSIT validation, PDF/A-3 check, reading in at the customer and at your tax adviser. The validation reports go into your records.
4. Go-live. Switch-over on a fixed date you determine – before 1 January 2027 if your prior-year turnover exceeds €800,000.
5. Aftercare. Review of the first invoice runs, adaptation to the following year's XRechnung version, support with queries from your customers.

See Introducing e-invoicing with Odoo for the full service scope. To explore Odoo first, you can create a free trial database with Ruetech as your partner at odoo.com.

You can mention your interest in a video course or live session in your enquiry. We will let you know once a date is confirmed.

Request an e-invoicing consultation – we reply within one business day.

Further reading

• XRechnung or ZUGFeRD? A decision guide for Odoo
• Registering for Peppol in Odoo (Germany): step by step
• Automating incoming invoices with Odoo
• Switching e-invoicing from Lexware, Sage 100, Navision and SAP B1 to Odoo
• Odoo DATEV integration
• Everything on e-invoicing with Odoo