Processing e-invoices automatically: what has applied since 2025 and how it works in practice

Since 1 January 2025, every business in Germany has to be able to receive an e-invoice. From 2027, sending them becomes mandatory step by step. I have automated the processing of incoming e-invoices for clients, using DATEV, line-of-business software and Power Automate. This article covers the legal position, what such a workflow looks like and where it gets stuck in practice.

What applies to the e-invoice since 2025

The obligation covers invoices between businesses based in Germany. There is no transition period for receiving, only for sending. The deadlines are set out in section 27(38) of the German VAT Act, and the Federal Ministry of Finance explains them in its guidance letters and its own FAQ.

What counts as an e-invoice and what does not

An e-invoice is an invoice in a structured electronic format based on the European standard EN 16931. The invoice data comes as an XML data set that software can read in without anyone retyping it. A simple PDF does not meet this, even when it arrives by email. It counts as an “other invoice”.

Two formats are common in Germany. XRechnung is a pure XML data set. ZUGFeRD is a hybrid format: a PDF for reading, with the XML data embedded in it. ZUGFeRD counts as an e-invoice from version 2.0.1, except for the MINIMUM and BASIC-WL profiles. With ZUGFeRD, the embedded data is what matters. If it differs from the visible PDF, the XML data takes precedence.

Many people know XRechnung from invoices to public authorities. For VAT purposes, though, it is just as valid between businesses. Sender and recipient agree between themselves which valid format to use. According to the Ministry of Finance, a business that cannot technically accept a valid e-invoice has no right to receive a different invoice instead. Anyone automating incoming invoices should therefore be able to read both formats. In my projects, most of what has arrived so far has been ZUGFeRD. There is a practical reason: an XRechnung is a pure data set that cannot be read without suitable software, while a ZUGFeRD invoice opens like any PDF and can still be processed automatically. I send my own invoices as ZUGFeRD too.

How I process incoming e-invoices

The tools depend on what the client uses for bookkeeping. At my clients, that means DATEV, line-of-business software with a DATEV interface, and Power Automate from Microsoft 365. At its core, the workflow is always the same:

1. The e-invoice arrives by email in the company’s inbox.
2. An automated workflow, in Power Automate for example, recognises the invoice attachment.
3. It forwards the file to the accounting software’s interface or stores it where the accounting system picks it up.
4. Accounting checks and books the invoice as usual, just without retyping.

In my view, two points belong in every workflow like this. First, the original file has to be kept: the Ministry of Finance requires at least the structured part of an e-invoice to be stored unchanged. A printout or a converted view is not enough. Second, an automatic check of the format does not replace checking the content. Whether the VAT rate and the service are correct remains a job for accounting.

Why some ZUGFeRD invoices cannot be read

The problem I have come across most often in practice: the sender produces ZUGFeRD in a different version from the one the recipient’s software can process. The invoice arrives and the PDF opens, but the software does not read the embedded data correctly. For that invoice, the benefit of automation is gone.

Behind this lies a format that keeps developing. The Forum elektronische Rechnung Deutschland (FeRD), which publishes ZUGFeRD, now releases new versions twice a year. Version 2.4 has applied since 15 January 2026. For you, this means: ask the vendor of your accounting or line-of-business software which versions and profiles its import supports, and keep the software up to date. I expect the problem to ease from 2027, when many more businesses have to send e-invoices and maintain their software accordingly.

Does AI play a part in processing e-invoices?

Not at my clients so far. That is partly down to the format: an e-invoice already carries its data in structured form, so nobody needs to extract it from a PDF any more. AI would be more of an option for assigning cost centres or suggesting account codes. I have not implemented that for clients yet, so I cannot offer any experience with it.

How much time automation saves cannot be put into a single figure. It depends on how many invoices come in and what the process looked like before. What is certain is that transferring the data becomes less error-prone, because nobody retypes amounts, dates or invoice numbers any more.

Frequently asked questions

Is a PDF invoice an e-invoice?

No. A simple PDF counts as an “other invoice” because it has no structured format. Until the end of 2026, and for smaller businesses until the end of 2027, it may still be used if the recipient agrees. A ZUGFeRD file looks like a PDF but also contains the structured data, which makes it an e-invoice.

Do I have to be able to receive XRechnung even if I do not work for public authorities?

Yes. XRechnung is a valid format between businesses too. The contracting parties agree on the format. A business that cannot technically accept a valid e-invoice has no right to a different version. Your software should therefore be able to read both XRechnung and ZUGFeRD.

Is an email inbox enough to receive e-invoices?

Yes. According to the Ministry of Finance, an email inbox is sufficient, and it does not have to be one used only for e-invoices. For automatic processing, a dedicated address for invoices is still practical, because the workflow can then attach to exactly that inbox.

Sources

• Obligation to receive, transition periods, formats, PDF as “other invoice”, email inbox: Federal Ministry of Finance – Questions and answers on the introduction of the mandatory e-invoice (German, as of March 2026)
• Formats, precedence of the XML data, storage, validation, no right to an “other invoice”: Federal Ministry of Finance letter of 15 October 2025, III C 2 – S 7287-a/00019/007/243 (German)
• Definition of the e-invoice: Section 14 of the German VAT Act (UStG) (German)
• Transition periods for sending: Section 27(38) of the German VAT Act (UStG) (German)
• ZUGFeRD 2.4, in force since 15 January 2026: FeRD – New ZUGFeRD version 2.4 published (German)
• Twice-yearly release cycle: FeRD – Twice-yearly release cycle for ZUGFeRD (German)