Quick verdict: Since 1 January 2025 you must be able to receive e-invoices; an inbox meets the duty but does not replace an orderly process. In Odoo, three channels feed one purchase journal: e-mail alias, Peppol inbox and OCR for paper and PDF. XML invoices cost no credits. What matters: checking the data record, purchase-order matching, approval and intact retention for eight years.
Reception duty since 2025: what you must be able to do
There is no transition period for receiving e-invoices. Since 1 January 2025 all businesses established in Germany must be able to accept e-invoices; for this it is sufficient that the recipient provides an e-mail inbox (BMF circular of 15 Oct 2024, para. 40). This also applies to small businesses (Kleinunternehmer): they may issue their own invoices as "other invoices" (BMF circular of 15 Oct 2025, para. 22), but according to the BMF FAQ they must still be able to receive.
The requirement is low, the risk is not. An "other invoice" – for instance a PDF without embedded data (BMF circular of 15 Oct 2024, para. 7) – does not, in principle, entitle you to deduct input VAT where an e-invoice was mandatory (para. 56). Good-faith protection applies if you could assume the supplier was using the transitional rule of Section 27(38) UStG (para. 59). From 2027 that assumption will be hard to justify for larger suppliers. The safe route is to demand structured data and to process it.
Until then and beyond, your inbound invoices remain mixed:
| What arrives | Why | For how long |
|---|---|---|
| E-invoices (XRechnung, ZUGFeRD, Peppol) | Issuing obligation from 1 Jan 2027 above EUR 800,000 prior-year turnover, from 1 Jan 2028 for all (Section 27(38) UStG) | permanently and increasingly |
| PDF and paper from domestic suppliers | Transition: until 31 Dec 2026 for all, until 31 Dec 2027 up to EUR 800,000 prior-year turnover (Section 27(38) nos. 1, 2) | until end of 2027 |
| Small amounts up to EUR 250, tickets, invoices from small businesses | may always be issued as "other invoices" (BMF circular of 15 Oct 2025, para. 22) | permanently |
| Invoices from foreign suppliers | The obligation applies only when supplier and recipient are both established in Germany (Section 14(2) sentence 2 no. 1 UStG) | permanently |
According to Bitkom, only 45 percent of German companies could receive e-invoices on 3 December 2024. A defined receiving process helps handle the additional XML invoices expected as the next deadlines approach.
Three inbound channels in Odoo
Each of the three channels creates a draft vendor bill in the purchase journal. This is where the shared review, purchase-order matching and approval process begins.
| Channel | What arrives | What Odoo makes of it | Cost |
|---|---|---|---|
| E-mail alias of the purchase journal | XRechnung XML, ZUGFeRD PDF, plain PDF | draft vendor bill; for XML the data is taken over directly | XML files need no OCR credits |
| Peppol inbox | UBL documents from registered senders | fetched several times a day, imported automatically as drafts | registration free; the documentation states no per-document fees |
| OCR (digitisation) | scans and PDFs without embedded data | text recognition, proposal for supplier, lines, amounts; draft | IAP service, one credit per document |
E-mail alias. Every purchase journal gets its own e-mail address. Whatever arrives there, Odoo turns into a draft bill – for XRechnung and ZUGFeRD from the structured data, without OCR (Odoo documentation 19.0). Two things to note for ZUGFeRD: the XML data is the authoritative part of the invoice (BMF circular of 15 Oct 2024, para. 31), and according to an analysis by the Verband elektronische Rechnung of 20 January 2026, around 18 percent of ZUGFeRD invoices sent by e-mail are faulty, mainly because of non-compliant use of the mandatory PDF/A-3 standard. ZUGFeRD files qualify as e-invoices from version 2.0.1, except the MINIMUM and BASIC-WL profiles (BMF circular of 15 Oct 2024, paras. 25, 30); a PDF in one of those two profiles is an "other invoice" and is treated as such. The alias is the channel with the largest volume and the largest need for checking.
Peppol inbox. Once your VAT ID is registered in Odoo, the system checks several times a day for new documents and imports them automatically as drafts into the purchase journal (Odoo documentation 19.0). The channel has no media break, no attachments anyone has to save, and a logged sender. DATEV describes sending e-invoices by e-mail as "anfällig" (vulnerable); Peppol is the answer to that. How registration works is described in Registering Peppol in Odoo.
OCR. Paper documents and PDFs without embedded data are captured through text recognition. Odoo provides an IAP service costing one credit per document (Odoo documentation 19.0). Check the recognised supplier, date, lines and amounts before posting. As more suppliers send structured data, fewer invoices need this route.
Tell suppliers your invoice email alias and Peppol details. Ask for XRechnung, ZUGFeRD or Peppol delivery and coordinate the change with them.
Check, do not trust
A fully populated draft still needs review. The following three rules from the BMF circulars define what must be checked:
| Rule | What it means | Basis |
|---|---|---|
| The data record is authoritative | For hybrid invoices the XML data forms the authoritative part. Where the visible PDF and the data record differ, accounting must not rely on the image alone. | BMF circular of 15 Oct 2024, para. 31; IHK Lüneburg-Wolfsburg |
| Error classes | Format errors turn the file into an "other invoice" (para. 6a). Business-rule errors, such as an empty BT-10 field, are rule violations (para. 6b). Content errors make the invoice non-compliant; all mandatory details must sit in the structured part, a link to an external source is not enough (paras. 35, 35a). | BMF circular of 15 Oct 2025 |
| Validation does not replace checking | The recipient remains obliged to check, but may rely on the technical result of a validation. Keeping the validation report is the recommended evidence. | BMF circular of 15 Oct 2025, para. 35a |
For the process in Odoo this means:
- Check the draft, not the image. Odoo builds the draft from the XML data. Accounting checks supplier, VAT ID, description of supply, tax rates and amounts in the draft; the attached PDF is a reading aid, not the basis.
- Validate technically. Odoo produces no KoSIT validation report. Set up an external validation step with the KoSIT validator – as a sample or automated per receipt – and file the report with the invoice. It is your evidence under para. 35a.
- Return faulty invoices. A faulty invoice is not "repaired in-house". You ask the supplier for a correction – as an e-invoice with a specific and unambiguous reference to the original invoice, which then applies retroactively (BMF circular of 15 Oct 2024, para. 57). Cash discounts require no correction; changes to the scope of supply do (BMF circular of 15 Oct 2025, paras. 51a, 51b).
- Classify recurring invoices. Contracts can be regarded as invoices; for a continuing obligation one e-invoice for the first partial-performance period with the contract attached is sufficient. For recurring invoices issued as "other invoices" before 1 January 2027 there is no duty to issue an additional e-invoice as long as the invoice details do not change (BMF circular of 15 Oct 2024, paras. 44–46). Rent, leasing and maintenance contracts often fall under this; do not demand a monthly XRechnung that does not have to exist.
- Document. Record supplier queries and replies as activities or notes on the bill. This keeps the path from invoice to posting traceable during an audit.
From draft to payment
The draft in the purchase journal is the start of the chain, not the end.
Purchase-order matching. Since Odoo 19 the system matches vendor bills imported from XML or OCR against purchase orders (Odoo 19 release notes). In Purchase you define whether bills are controlled against ordered or received quantities – the classic three-way match of order, receipt and invoice. Quantity or price deviations become visible on the document and go to Purchasing as a clarification case, not into the posting.
Approval. Agree who reviews, approves and posts invoices, for example by amount, cost centre or project. The bill remains a draft until it is posted. Name deputies to cover absences.
Posting. With posting the document becomes immutable; the German localisation l10n_de logs changes in line with the GoBD (Odoo documentation 19.0). Corrections are made by reversal and re-posting, not by editing.
Special cases. The rules also apply to self-billing credit notes, to supplies subject to reverse charge under Section 13b UStG, and where the recipient is a small business or a landlord (BMF circular of 15 Oct 2025, para. 17). Anyone issuing self-billing credit notes to suppliers is the issuer of an e-invoice themselves.
Payment. Posted bills flow into the payment proposal; discount deadlines are stored on the document. A cash-discount deduction requires no correction of the invoice (BMF circular of 15 Oct 2025, para. 51a). Hand-over to your tax adviser is in DATEV format; the options are described in Odoo DATEV integration.
| Step | Responsibility | Result |
|---|---|---|
| Receipt | alias, Peppol, OCR | draft in the purchase journal |
| Check | Accounting | data record checked, validation report filed |
| Matching | Purchasing | order, receipt and invoice agree |
| Approval | department or cost-centre owner | posting |
| Payment | Accounting | payment run, discount taken |
| Hand-over | Accounting | DATEV export to the tax adviser |
Archiving: eight years, intact
Invoices must be kept for eight years (Section 14b UStG). For e-invoices there is more: at least the structured part must be kept in a way that it remains intact in its original form (BMF circular of 15 Oct 2025, para. 60). Storage outside a GoBD-compliant system is, for VAT purposes alone, not a violation (para. 60) – but the GoBD continue to apply to the bookkeeping as a whole.
What this means in Odoo:
- Original file on the bill. Keep the received XML file, or PDF/A-3 with embedded XML, unchanged as an attachment to the posted bill. OCR output or a newly generated PDF does not replace it.
- Archive outside the inbox. Transfer invoices to the designated storage location so their availability does not depend on an email account remaining active or an inbox being left untouched.
- Change protection. Posted documents and their attachments must be protected against deletion and overwriting; the localisation provides the audit trail, you provide the permissions.
- Readability. An XRechnung is an XML file. The draft bill in Odoo is its readable rendering; for checks by third parties, keep a visualisation as well.
- Process documentation. Describe receiving channels, checks, approvals and retention. This documentation makes the process traceable for a tax audit.
Where the database runs decides backups and access; the options are compared in Odoo hosting in Germany.
KPIs you should measure
Useful targets depend on industry, invoice volume and supplier structure. Establish a baseline before the change, then compare these measures each month:
| KPI | Which question it answers | Where in Odoo |
|---|---|---|
| Share of structured inbound invoices (XML, Peppol) in all inbound invoices | How far along are your suppliers? | origin of the draft: alias with XML, Peppol, OCR |
| Share of automatically matched bills | How much PO matching runs without manual correction? | bills without a deviation note against the order |
| Lead time from receipt to posting | Where does it back up: checking, matching or approval? | draft date against posting date |
| Lead time from receipt to payment | Are you using discount deadlines? | posting date against payment date |
| Share of bills with validation or content errors | How cleanly do your suppliers deliver? | validation reports, correction requests |
| Number of correction requests per supplier | Whom do you talk to first? | activities on the document |
| OCR credits per month | What does the remainder of paper and PDF cost? | IAP consumption |
| Share of "other invoices" from obliged suppliers from 2027 | Where is your input-VAT risk? | OCR drafts with a domestic supplier above the turnover threshold |
Pay particular attention to the first and last measures: they show the effect of supplier communications and the share of invoices presenting input-VAT deduction risks from 2027.
Next step
Ruetech uses e-invoicing internally and has configured the Odoo workflow for clients in Germany and abroad.
- You want to know where your invoice intake stands: complete the readiness check – twelve questions, result shown on the page right away.
- You want to set up intake, checking and archiving with us: request an e-invoicing consultation. The scope of the service is described on E-invoicing with Odoo.
- You want to try the three channels yourself: create an Odoo test database.
The full overview of deadlines, formats and Odoo versions is in the guide E-invoicing with Odoo and on the topic page E-invoicing.