E-Invoicing Mandate: Preparing Shop and ERP in Time
Since 1 January 2025 every company based in Germany must be able to receive e-invoices. From 2027 larger companies must also issue B2B invoices in a structured format, and from 2028 the obligation applies to all domestic B2B transactions (German Federal Ministry of Finance). We set up format-compliant invoice creation in your Shopware shop and connect it to ERP and accounting.
2027
issuing obligation above 800,000 € prior-year revenue (BMF)
2028
issuing obligation for all domestic B2B transactions (BMF)
45%
of companies can receive e-invoices (Bitkom Research, 2024)
EN 16931
European standard for the invoice data model
Fixed prices · net plus VAT
- Outbound and inbound processes thought through separately, implemented together
- ZUGFeRD from 2.0.1 and XRechnung under EN 16931 from the same order data
- Validation against schema and business rules before handover to the ERP
- Fixed project price after the free inventory of your current setup
We implement format-compliant invoice creation and the handover to ERP or accounting as an integration project: standard integration from 4,900 €, custom integration with a dedicated transformation layer from 12,900 €. As part of a new B2B shop from 14,900 €. Extensions and special logic by effort: 119 € per hour, daily rate 940 €. Ongoing interface care from 249 € per month. All prices net plus VAT.
E-invoicing is not a formatting question for the accounting department but a data topic spanning the entire ordering process. Anyone selling in B2B creates invoice data where the order arises — in the shop and in the ERP. As a specialised B2B e-commerce agency we set up structured invoice creation under EN 16931, connect it to your ERP through a robust integration layer and build the inbound process for supplier invoices. This page explains the deadlines, the permitted formats and the typical project sequence. Legal details should be clarified with your tax adviser if in doubt — we deliver the technical implementation.
The Deadlines of the E-Invoicing Mandate at a Glance
What the E-Invoicing Mandate Means in Practice
The legal basis is the German Growth Opportunities Act of 2024, which reorganised the VAT requirements for electronic invoicing in domestic B2B business. Introduction is phased: since 1 January 2025 every company based in Germany must be able to receive e-invoices. From 1 January 2027 companies with prior-year revenue above 800,000 euros must issue their domestic B2B invoices as e-invoices, and from 1 January 2028 this issuing obligation applies to all domestic B2B transactions (German Federal Ministry of Finance). These figures reflect the current state of publications; the applicable version of the rules is always decisive.
The most frequently overlooked point is the inbound side. It already applies today and regardless of your own revenue: anyone receiving an e-invoice from a supplier must be able to accept and process it. In practice there is a gap here — only 45 percent of companies can receive e-invoices in structured formats (Bitkom Research, 2024). For shop operators this means acting on two fronts: receiving now, and format-compliant issuing with sufficient lead time before the respective deadline.
Preparation needs lead time, not the deadline
What an E-Invoice Legally Is: the EN 16931 Standard
An e-invoice within the meaning of the rules is not simply an invoice sent digitally but an invoice in a structured electronic format that can be read and processed automatically. The decisive framework is the European standard EN 16931, which defines the semantic data model and the core content of an invoice (German Federal Ministry of Finance). Only this makes it possible to transfer invoice data into accounting and ERP without manual entry — which is the actual purpose of the changeover.
Particularly important in practice: a plain PDF invoice is not an e-invoice under the new rules, because it contains no structured data, only an image. It counts as an „other invoice“ and is no longer sufficient in the regulated B2B area once the transitional periods expire. A scanned paper invoice does not meet the requirement either. This distinction surprises many companies that have long considered their invoicing to be digitalised.
Structured, not depicted
Invoice data exists as machine-readable XML, not as an image or free text. Every field is unambiguously labelled and can be processed automatically — from the net amount and the tax rate to the individual line item.
Standard-compliant under EN 16931
The European standard defines the mandatory fields and the semantic model. Only those who meet it issue an e-invoice within the meaning of the rules. This applies to ZUGFeRD from version 2.0.1 as well as to XRechnung.
Directly processable
Accounting and ERP take amount, tax rate, line items and payment data straight from the data set. Manual entry is eliminated, and with it the most common source of errors in the invoicing run.
Verifiable before posting
Every e-invoice can be validated against the schema and business rules of the standard. Faulty documents surface before they enter posting — saving queries to suppliers and later corrections.
Archivable in an audit-proof way
The structured data set is the original and is archived unalterably. Simply storing the PDF image is not sufficient, because the structured data is lost in the process. This supports traceability under the German GoBD principles.
Interoperable across systems
Because all parties use the same standard, exchange works consistently across company and system boundaries — even where supplier and customer run completely different ERP systems.
ZUGFeRD and XRechnung: the Permitted Formats
In Germany two formats meet the requirements of the standard: XRechnung and ZUGFeRD from version 2.0.1 (German Federal Ministry of Finance). XRechnung is a pure XML format and is widespread in dealings with public sector clients. ZUGFeRD is a hybrid format: it combines a PDF/A-3 file for the human eye with an embedded XML data set for machine processing. Which format makes sense is decided by your recipient structure — and in many cases the answer is „both“.
| Characteristic | XRechnung | ZUGFeRD (from 2.0.1) |
|---|---|---|
| Structure | Pure XML | Hybrid: PDF/A-3 with embedded XML |
| Human readable | Only with a viewer or visualisation | Yes, directly as a PDF |
| Typical use | Public sector clients and B2B | B2B and mixed recipient groups |
| Sufficient profiles | Standard-compliant variant | EN 16931 (Comfort) and above |
| Not sufficient | not included | MINIMUM and BASIC-WL |
| Underlying standard | EN 16931 | EN 16931 |
Format diversity is the norm, not the exception
What Has to Happen in Shop and ERP
The technically cleanest route is native creation of the e-invoice directly from the order data. The shop holds all relevant information — line items, quantities, prices, tax rates, customer and delivery data — and can generate a standard-compliant data set from it immediately, instead of reconstructing it later from a PDF. For Shopware in the Community Edition this means: every completed order produces a ZUGFeRD or XRechnung file that is handed over to downstream systems in machine-readable form.
The prerequisite is data completeness at the source. The standard requires certain mandatory details that must be maintained consistently in the shop: the correct VAT ID for intra-Community transactions, unambiguous payment terms, bank details and — in dealings with public sector clients — the routing ID. If these fields are missing, validation fails. A well-maintained PIM integration and clean customer master data are therefore the quiet foundation of a format-compliant invoice.
Outbound and Inbound as One Integration Project
One format layer for both directions
Outbound and inbound are two topics in business terms, but technically the same task: translate structured invoice data in a standard-compliant way, validate it and hand it to the right system. We therefore build a shared format layer that produces ZUGFeRD or XRechnung from order data and checks incoming documents against the same rules before they reach the ERP.
- Creation from order data instead of reconstruction from the PDF
- Validation against schema and business rules before handover
- One rule set for outbound and inbound, one monitoring for both
Receiving and Processing Incoming Invoices
The inbound side has been mandatory since 2025 and is regularly underestimated. Incoming e-invoices must be accepted, validated against the schema and business rules of the standard and then processed. Robust processing checks whether all mandatory details are present and plausible before the document enters posting. This way faulty invoices are identified before they create work in accounting.
- Accept incoming e-invoices technically and store them in a structured way
- Validate against the EN 16931 schema and the business rules
- Check mandatory details and plausibility automatically, report deviations
- Provide a human-readable visualisation for clerks and approvers
- Hand the structured data set over to ERP and accounting
- Archive the XML original unalterably and in a machine-analysable form
Processing explicitly includes a human-readable display: clerks and approvers want to see the document, not read the XML. The structured original is therefore supplemented with a readable visualisation and routed into the ERP or the approval process along defined paths. Anyone steering purchasing through a B2B portal can embed invoice receipt directly into the existing role and approval processes.
Can you already receive e-invoices today?
The obligation to receive already applies, the obligation to issue is phased in. We review your existing shop and ERP landscape and show in a free initial conversation which steps make sense in which order.
Exceptions: Small Amounts, B2C and Foreign Transactions
Not every invoice falls under the issuing obligation. Small-amount invoices up to 250 euros gross are exempt and may still be issued as an „other invoice“, as may travel tickets (German Federal Ministry of Finance). The obligation also applies only to domestic B2B transactions: invoices to consumers and to companies established abroad are not covered. Certain VAT-exempt transactions may also be excluded — which ones apply in your individual case should be checked from a tax perspective if in doubt.
- Small-amount invoices up to 250 euros gross: still permitted as an „other invoice“
- Travel tickets: exempt from the issuing obligation
- B2C transactions: invoices to consumers are not covered
- Foreign transactions: business with companies established abroad does not fall under the domestic obligation
- Certain VAT-exempt transactions: excluded depending on the type of service
Do not build the process around the exceptions
Archiving and GoBD Compliance
With an e-invoice the structured XML data set is the original, not the PDF visualisation. For retention this means: the XML part must be archived unalterably and in a machine-analysable form so that it is available in its original format in the event of a tax audit. Simply storing the PDF image is not sufficient, because the structured data is lost. This corresponds to the German principles for the proper keeping and retention of books (GoBD).
The retention period also deserves attention: the Fourth Bureaucracy Relief Act shortened the retention period for invoices from ten to eight years. A continuous, logged document chain from creation in the shop through handover to the ERP to audit-proof archiving considerably eases the burden of proof. Closing this chain cleanly is part of the integration project and the reason why format, posting and archive levels should be considered together.
How this differs from an accounting integration
A Typical Project in Six Steps
An introduction project can be structured into manageable phases. It starts with an inventory of the existing invoicing processes and ends with monitored productive operation. Unlike a complete ERP migration, introducing e-invoicing can be delivered within a clear time frame — provided it starts with sufficient lead time. The effort depends above all on how clean the master data is and how well the existing ERP interface is documented.
Inventory of the current setup
We record the current outbound and inbound processes, the systems involved and the data quality in the shop. This shows which mandatory fields already exist, which customer and tax data need to be added and whether the ERP side offers a usable interface.
Define formats and profiles
Based on your recipient structure we determine which formats are created: ZUGFeRD in a sufficient profile, XRechnung or both in parallel. At the same time we compare the mandatory fields of the standard with the data available in shop and ERP and name the gaps.
Set up creation
Native creation is connected to the order data: every completed order produces a standard-compliant data set that is validated against EN 16931 immediately. Error cases are logged and do not slip unnoticed into dispatch.
Build the inbound process
In parallel the inbound process is built: incoming documents are accepted, validated, displayed readably and routed into the approval path. Conspicuous documents are flagged instead of being passed on to accounting unchecked.
Connect ERP and archive
Outbound and inbound are handed over to ERP and accounting, the document chain is closed and audit-proof storage of the XML original is set up. Only then is the process continuous rather than format-compliant in one place only.
Test run and go-live
Before the switchover we run a test with real documents and align the results with your tax adviser. The process then goes live under supervision; we accompany the first weeks with monitoring of the format layer as part of our maintenance services.
The Key Points on E-Invoicing in a B2B Shop
- The obligation to receive has applied since 2025 to every company based in Germany; the obligation to issue starts in 2027 and 2028 respectively (BMF)
- Permitted are XRechnung and ZUGFeRD from 2.0.1 in a sufficient profile — a plain PDF invoice is not enough
- Creation belongs at the source: from the order data in shop and ERP, not reconstructed from the PDF afterwards
- The XML original is the document to be retained; standard integration from 4,900 € net, custom from 12,900 €
Basis of the information on this page