E-Invoicing Mandate 2027: Compliance as the Starting Point for Automated Finance Processes

Our Head of Business Integration & Architecture, Patrizio Doktor, explains how companies can meet the e-invoicing mandate without building yet another isolated solution.

For me, the 2027 e-invoicing mandate is above all an integration task. Formats and deadlines are fixed. What remains open in many companies is whether receiving, sending and partner connectivity run in one shared process or in several that know nothing of each other.

A Bitkom study of 1,103 companies shows how much needs to be done: shortly before 1 January 2025, the date from which receiving e-invoices became mandatory, only 45 % of companies in Germany were able to receive them. EDI formats dominate on the receiving side at 71 %, ZUGFeRD or Factur-X are used by 27 %, and the purely XML-based format XRechnung by 5 %.

The next stage follows on 1 January 2027. Companies with prior-year revenue of more than EUR 800,000 must issue domestic B2B invoices as e-invoices. From 2028, the obligation applies to all companies in principle, with exceptions such as small businesses and small-amount invoices up to EUR 250. The BMF circular on e-invoicing sets out the binding details, and the FAQ of the German Federal Ministry of Finance provide an overview. Many companies introduced a receiving solution in 2025, and a second one is now often being built for sending. That is where I see the real risk: every additional isolated solution brings its own mappings, its own validation rules and its own monitoring.

In this article, I explain what the mandate requires technically, which architectural approaches exist and how they lead to automated invoice processing.

What the 2027 e-invoicing mandate requires technically

An e-invoice is an invoice in a structured electronic format in line with the European standard EN 16931. A PDF sent by email does not meet this requirement and counts as an other invoice. In Germany, XRechnung and ZUGFeRD are widespread, and Peppol BIS Billing is added for cross-border exchange. Across Europe, the picture is not uniform. Italy made e-invoicing mandatory in 2019 via the state platform SdI, and Romania followed in 2024. Since 2026, obligations have applied in Belgium via the Peppol network and in Poland via the state platform KSeF. France has been introducing the mandate step by step since September 2026 via state-approved platforms, and Spain is expected to follow from 2027. In Austria, e-invoicing has so far only been mandatory for invoices to federal authorities. The EU initiative ViDA (VAT in the Digital Age) harmonises the rules for cross-border invoice exchange: from 1 July 2030, e-invoices and digital reporting will become mandatory for intra-EU B2B transactions, and by 2035 national reporting systems are to be aligned with the EU model.

The structured data set is therefore the leading part of the invoice, and it must contain all mandatory VAT information in full. In projects, I therefore rarely see the greatest effort in the format. It lies in the master data in the ERP system, meaning tax codes, order references and units of measure, and above all in the business cases: down-payment and final invoices, collective invoices referencing individual order items, credit notes and corrections must be represented correctly in the structured data set.

On top of this come business requirements that no format standard covers. In France, for example, every invoice must be classified as a supply of goods, a service or a mixed transaction. This classification must be prepared at business level and anchored in the process. Companies with foreign subsidiaries and mixed B2B, B2C and B2G business have to connect to different networks and platforms. Industry rules such as market communication under the German Energy Industry Act follow their own formats and are not designed for EN 16931. Bridges between the rule sets are needed here. All of this can be done, but it cannot be adopted one to one. Legal requirements have to be translated into business processes, and this effort is often underestimated.

Where isolated solutions emerge

Isolated solutions usually emerge along the deadlines. In 2025, a receiving portal or a mailbox with a converter was added, in 2027 a sending module in the ERP system follows, and EDI connections have existed with individual key accounts for years. Each of these components brings its own format logic, its own validation rules and its own error handling. According to Bitkom, 58 % of companies say they have largely or fully digitalised their processes in accounting, finance and controlling. Parallel invoicing streams break this continuity at the interface with customers and suppliers.

In most projects, the format question is solved quickly. The effort lies in deciding who handles validation errors, how attachments are assigned to the right invoice and how the status gets back into the ERP system. For me, this logic belongs in one layer, not in three.

Three architectural approaches to e-invoicing compared

I see three architectural approaches for implementation. They differ in where format conversion, validation and channel connectivity sit and how far automation reaches beyond pure compliance.

The approaches can be combined. In many landscapes, the ERP system remains the leading system for posting and master data, while an integration platform handles conversion, validation, sending and monitoring for all connected systems. Which approach fits depends less on technology than on processes. When selecting, I therefore look at:

• which invoice cases actually occur in the company and how the processes behind them work,
• which business areas are affected (B2B, B2C, B2G),
• in which countries and entities invoices are created and which deadlines apply there,
• how many ERP systems, networks and partner channels need to be connected, including existing EDI connections,
• which volumes and peak loads are to be expected, for example at month-end closing,
• where invoice data is stored, processed and archived in an audit-proof manner.

We often analyse a representative data extract from the production environment for this. This quickly shows which invoice cases really exist and where master data or mandatory information is missing, before the project starts.

From compliance to automated invoice processing

Structured invoice data is the prerequisite for automating incoming invoices. When line items, order numbers and tax information are machine-readable, incoming invoices are automatically matched against the purchase order and goods receipt, coded and forwarded for approval. On the outgoing side, the ERP system supplies the invoice data. Depending on the architecture, it generates the e-invoice itself, or an integration platform takes over this step: it transfers the data via an interface into the required format, whether XRechnung, ZUGFeRD, Peppol BIS or EDI, validates it and delivers it via the appropriate network depending on country and recipient, for example Peppol, a state platform or email. For tax purposes, the company itself always remains the invoice issuer, and the platform generates and sends the e-invoice on its behalf.

One topic that is underestimated in many projects is invoice attachments, both outgoing and incoming. Delivery notes, proofs of service, timesheets or terms and conditions must be assigned to the right invoice, partly embedded in the structured data set, partly as a separate document. On the outgoing side, they rarely come from a single system and are drawn from the ERP, business applications or a DMS. On the incoming side, they must be extracted from the e-invoice and assigned to the document in the ERP system. The DMS plays a central role in both directions: incoming and outgoing invoices, together with the structured data set and attachments, must be archived in a GoBD-compliant and audit-proof manner.

For me, the invoicing process therefore does not end with sending. Status messages, dunning, archiving and reporting depend on the same data. Anyone who plans e-invoicing as an integration project automates these steps at the same time.

Implementing e-invoicing: three principles

I apply three principles in every e-invoicing project:

01 Decouple format logic from the ERP system. Conversion and validation sit in a dedicated integration layer. New formats, additional countries or ViDA requirements are added there, without changes to the ERP system.

02 Validate before sending and posting. Validation rules in line with EN 16931 and country-specific requirements run automatically. Faulty invoices go to a clearly designated owner with a validation report before they reach customers or accounting.

03 Define monitoring and responsibilities. Every invoice is traceable throughout the process, and status and errors flow back into the ERP system. Business units, IT and operations share responsibility along defined interfaces. GoBD-compliant archiving is part of the same process.

E-invoicing as part of the integration architecture

The 2027 e-invoicing mandate initially concerns sending invoices. Companies that map incoming invoices, outgoing invoices and partner connectivity through a central integration layer reduce the number of interfaces and lay the foundation for automated invoice processing across countries and ERP systems.

It all starts with an inventory of today’s invoicing channels, formats and systems. For me, an e-invoicing project is successful when invoices are processed faster, more reliably and with less manual effort. This requires clear processes, clean system integration and as few sources of error as possible. More information on formats, ERP connectivity and operations is available on the E-Invoicing and Invoice Automation page.