E-Invoice Mandate 2027: ERP Shop Interface

The mandatory e-invoice for domestic B2B transactions was introduced with the Growth Opportunities Act of March 2024 and is aligned with the European VAT in the Digital Age (ViDA) initiative (EDICOM). The legislator staggered the rollout so that companies can convert their processes and systems step by step. The key distinction is between the reception duty and the issuance duty: reception is already mandatory, while issuance becomes binding later.

Since 1 January 2025, every domestic company must be able to receive and process e-invoices per EN 16931 -- a recipient may no longer refuse a compliant e-invoice (EDICOM). For issuance, a transition period applies: until 31 December 2026 all companies may still send paper or PDF invoices, the latter with the recipient's consent (Federal Ministry of Finance). From 1 January 2027 this relief no longer applies to companies with prior-year turnover above 800,000 euro -- they must then issue structured e-invoices (DATEV). From 1 January 2028, finally, all domestic B2B companies are obliged to issue them (Federal Ministry of Finance).

A further relief concerns small-amount invoices: for invoices with a gross amount up to 250 euro there is no obligation for a structured e-invoice (Federal Ministry of Finance). Likewise, established EDI procedures that do not fully comply with the e-invoice standard remain permitted transitionally until the end of 2027, provided the parties agree on the format (Federal Ministry of Finance). Our article on EDI integration with EDIFACT describes how classic EDI flows fit into a modern architecture.

An e-invoice in the sense of the law exists when it is issued, transmitted and can be electronically processed in a structured electronic format and complies with the European standard series EN 16931 (Federal Ministry of Finance). In Germany, two formats primarily meet this requirement: XRechnung as a pure XML format and ZUGFeRD as a hybrid format from version 2.0.1 -- with the exception of the MINIMUM and BASIC-WL profiles (Federal Ministry of Finance). Both are named by DATEV as compliant standards (DATEV).

XRechnung is a purely structured dataset: an XML file per EN 16931 without a human-readable visual document. It is represented via the syntax variants UBL or CII and is fully machine-readable. A human needs a viewer to read the invoice. ZUGFeRD, by contrast, is a hybrid format: a PDF/A-3 file with an embedded XML dataset. The recipient sees a familiar PDF while the accounting software reads the structured data in parallel. ZUGFeRD thus combines human readability with machine processability.

The adoption of e-invoices is growing, but many companies are not yet set up end to end. By now, 43 percent of companies send e-invoices, and fewer than half (45 percent) can receive invoices as e-invoices at all (Bitkom). At the same time, almost all companies (96 percent) still receive invoices by email (Bitkom) -- a clear sign that the media break between PDF and structured dataset still dominates in practice. For outgoing invoices, 55 percent of companies already use the e-invoice, though only just under a third (30 percent) do so frequently (Bitkom).

In e-commerce, hundreds of documents quickly accumulate per day. Bringing these into a compliant format manually is neither economical nor reliable and ties up valuable working time. An ERP shop interface automates the entire path: as soon as an order is completed, the line-item data, tax rates, addresses and amounts are read from the store, processed in the ERP into an invoice with correct account assignment and generated as a ZUGFeRD or XRechnung document. The structured XML dataset then moves in a GoBD-compliant way into the DATEV accounting -- without anyone typing out a PDF or transferring fields manually.

The core of every e-invoice interface is a clean, traceable data flow. It begins with the order in the store and ends with the audit-proof posting document in DATEV. In between lie several processing steps that must each be clearly delimited and logged so that the document chain remains seamless.

The heart of this process is the mapping between store, ERP and accounting fields. Which line item goes to which revenue account, which tax code applies to intra-community deliveries and how shipping costs are posted -- all of this must be defined cleanly once. How such a field mapping is built methodically is deepened in our article on data mapping between ERP and store. For the subsequent reconciliation of payment receipts with open items, take a look at payment reconciliation in the ERP matching.

An often underestimated point is unambiguous referencing. Every document that travels the path from store via ERP to DATEV needs a continuous document number and a link to the original order. Only then can invoice, credit note and payment later be assigned beyond doubt to the same business transaction. For this, the interface keeps an assignment table that connects the store order number, ERP document number and DATEV reference. If an order is cancelled or partially returned, the interface generates a corresponding credit-note document that refers to the original document via the same reference -- a central building block for an audit-proof document chain.

The question of real-time versus batch is also decided at the data flow. With moderate order volume, a daily run that generates and hands over all documents collectively is usually sufficient. If the volume grows or documents are to be available immediately after order completion, the event-driven variant is suitable: a completed order immediately triggers the generation and validation of the e-invoice document. Both approaches can be mapped in the same middleware, so that a switch from batch to real time later usually remains possible without a rebuild. What matters is that every step -- reading, generating, validating, handing over -- is logged and that a faulty document is not silently lost but lands in a resubmission queue that the accountant can specifically rework.

With the e-invoice, the archiving requirements also change. Incoming electronic documents must be archived in the received format -- an e-invoice as XML may therefore not be converted into a PDF with only that PDF being stored (DATEV). What matters is the structured part, such as the XML dataset. With hybrid ZUGFeRD documents, the PDF part only needs to be retained additionally if it contains tax-relevant additional information not represented in the XML (DATEV).

The GoBD (Principles for the Proper Management and Storage of Books, Records and Documents in Electronic Form) require a seamless, unalterable and traceable document chain. An automated interface fulfills this systematically: every processing step is logged with a timestamp, every document receives a unique reference, and the original dataset is stored in an audit-proof way. This log serves as evidence of proper processing during a tax audit.

In practice, this means planning archiving into the data flow from the start instead of treating it as a downstream step. As soon as the interface has generated a document, it stores the XML dataset in audit-proof storage and records the time, format and profile. Incoming e-invoices from suppliers are subject to the same duty: they must be retained in the received format, not as a printed or converted image. A well-thought-out interface therefore covers both directions -- generating outgoing documents as well as the structured storage of incoming e-invoices. This keeps the document chain consistent and traceable across the entire business traffic, which saves time and discussion during a later audit.

Experience from integration projects reveals recurring stumbling blocks. Anyone who knows them from the outset avoids expensive rework shortly before the deadline. The most frequent problems do not arise in the technology but in the clean mapping of the VAT logic and the recipient-specific requirements.

The correct tax logic in particular deserves attention. The interface must determine the appropriate tax code for each document -- based on delivery country, customer status (B2B or B2C) and the validity of the VAT ID. This logic belongs in a central middleware so that it applies consistently across all sales channels and can be maintained in one place when laws change.

An e-invoice interface can be implemented in a structured way within a manageable time. The most important success factor is the early involvement of the tax advisor, who defines the account mapping and the tax codes. Anyone who starts the implementation well before the respective deadline gains time for low-risk parallel operation.

Merchants who want to embed their e-invoice interface in a larger integration strategy will find further approaches in our articles on the SAP Integration Suite and clean-core shop connection and on the migration to the Dynamics 365 BC API v2 shop connector. Both show how the invoice logic fits cleanly into modern ERP architectures.