From 1 January 2027, domestic companies with prior-year revenue above EUR 800,000 may only send structured electronic invoices in the B2B sector, and from 2028 this applies to all domestic B2B transactions (Federal Ministry of Finance). The obligation to receive e-invoices has already been in force since 1 January 2025 -- yet only 45 percent of companies are technically able to do so (Bitkom Research, 2024). That makes 2026 the decisive preparation year. For anyone running a B2B store, the switch touches two systems at once: format-compliant invoice generation from the store and a clean handoff to ERP and accounting. This article explains the EN 16931-compliant formats ZUGFeRD and XRechnung, the outbound and inbound process, and the connection to the ERP as a concrete interface project.
Key takeaways
- Receiving e-invoices has been mandatory since 1 January 2025 regardless of company size; issuing them becomes mandatory on 1 January 2027 for companies above EUR 800,000 in prior-year revenue and on 1 January 2028 for all domestic B2B sales (Federal Ministry of Finance).
- Only a structured data set under EN 16931 counts as an e-invoice: XRechnung or ZUGFeRD from version 2.0.1 in the EN 16931 (Comfort) profile or higher. A plain PDF or a scan does not qualify, and the MINIMUM and BASIC-WL profiles fall short (Federal Ministry of Finance).
- Invoices generated natively from order data hold up better than XML extracted from a finished PDF, which breaks with every layout change. Validation fails when the VAT ID, payment terms, bank details or the routing ID are missing.
- Inbound processing means more than accepting a file: validate against the EN 16931 schema and business rules, show approvers a readable view, then pass the data set to ERP and accounting. Only 45 percent (Bitkom Research) can receive structured formats.
- Invoice format and bookkeeping integration stay separate building blocks: the mandate governs the format and the outbound and inbound process, while the accounting interface turns content into accounts and postings. The format can change without touching booking logic.
- The exemptions are narrow: small-value invoices up to EUR 250 gross, transport tickets, B2C sales and sales to companies based abroad (Federal Ministry of Finance). The XML is the original and must be archived unchanged and machine-readable for eight years.
What the E-Invoicing Mandate from 2027 Actually Means
The legal basis is the Growth Opportunities Act (Wachstumschancengesetz) of March 2024, which reorganized the VAT requirements for e-invoicing in the domestic B2B sector. The rollout is staggered: since 1 January 2025 every domestic company must be able to receive e-invoices. From 1 January 2027, companies with prior-year revenue above EUR 800,000 must issue their B2B invoices as e-invoices, and from 1 January 2028 this issuing obligation applies to all domestic B2B transactions (Federal Ministry of Finance). For revenue below the threshold, a transition rule remains in place until the end of 2027 that still permits paper or another electronic format with the recipient's consent.
The often-overlooked point: the receiving obligation already applies today, regardless of your own revenue. Anyone who receives an e-invoice from a supplier must be able to accept and process it. In practice, this is exactly where a gap is visible. Only 45 percent of companies can receive e-invoices in structured formats (Bitkom Research, 2024), while 55 percent use the e-invoice at least for outgoing invoices -- 30 percent frequently and 25 percent only in individual cases (Bitkom Research, 2024). For accounting overall, 58 percent say they have largely or fully digitalized their finance and controlling processes (Bitkom Research, 2024). So there is a noticeable gap between the legal requirement and actual implementation.
2026 Is the Preparation Year, Not 2027
What an E-Invoice Legally Is: the EN 16931 Standard
An e-invoice in the legal sense is not simply a digitally sent invoice but an invoice in a structured electronic format that can be read and processed by machine. The decisive reference is the European standard EN 16931, which defines the semantic data model and the core content of an invoice (Federal Ministry of Finance). Only this allows invoice data to be transferred directly into accounting and the ERP without manual capture -- which is the actual purpose of the switch.
Important for practice: a plain PDF invoice is not an e-invoice in the sense of the new rules, because it contains no structured data, only an image. It is treated as an other invoice and, once the transition periods expire, is no longer permitted in the mandated B2B sector. A scanned paper invoice does not meet the requirement either. This distinction surprises many companies that already consider their invoicing digitalized.
Structured
The invoice data exists as machine-readable XML, not as an image or text -- every field is clearly labeled and automatically processable.
EN 16931
The European standard defines the mandatory fields and the semantic model. Only those who meet it issue a valid e-invoice.
Machine-readable
Accounting and ERP take amount, tax rate, line items and payment data directly from the data set, without manual capture.
Verifiable
Every e-invoice can be checked against the schema and business rules of the standard -- faulty documents are caught before booking.
Audit-proof
The structured data set is the original and is archived unchanged. This supports traceability under GoBD.
Interoperable
Because all parties use the same standard, the exchange works uniformly across company and system boundaries.
ZUGFeRD and XRechnung: the Permitted Formats
In Germany, two formats meet the standard's requirements: XRechnung and ZUGFeRD from version 2.0.1 (Federal Ministry of Finance). XRechnung is a pure XML format, mainly used in dealings with public authorities. ZUGFeRD is a hybrid format: it combines a PDF/A-3 file for the human eye with an embedded XML data set for the machine. Both carry the same structured content and are legally equivalent -- the choice depends on the recipients and the existing system landscape.
With ZUGFeRD, the profile is decisive. The MINIMUM and BASIC-WL profiles do not map all tax-relevant mandatory fields in a structured way and are therefore not sufficient for a valid e-invoice; at least the EN 16931 (Comfort) profile or higher is required (Federal Ministry of Finance). Large trading relationships also often run over EDI formats such as EDIFACT, which, under the conditions named by the law, can likewise be used as a structured e-invoice. For market context: of around 560 billion invoices worldwide in 2024, about 125 billion were electronic, and the market for corresponding solutions is expected to grow to over EUR 22 billion by 2028 (VeR/billentis, 2025).
| Attribute | XRechnung | ZUGFeRD (from 2.0.1) |
|---|---|---|
| Structure | Pure XML | Hybrid: PDF/A-3 with embedded XML |
| Human-readable | Only with a viewer | Yes, directly as PDF |
| Typical use | Authorities and B2B | B2B and mixed recipients |
| Valid profiles | Standard-compliant | EN 16931 (Comfort) and higher |
| Not sufficient | not included | MINIMUM, BASIC-WL |
| Standard | EN 16931 | EN 16931 |
Structured Invoice Generation from the Store
The cleanest path is native generation of the e-invoice directly from the order data. The store holds all the relevant information -- line items, quantities, prices, tax rates, customer and delivery data -- and can produce a standard-compliant data set from it immediately. For Shopware in its open-source variant, this means: every completed order produces a ZUGFeRD or XRechnung file that is handed to the downstream systems in machine-readable form, rather than being reconstructed from a PDF after the fact.
The prerequisite is data completeness at the source. The standard requires certain mandatory fields that must be maintained consistently in the store: the correct VAT ID for intra-community transactions, unambiguous payment terms, bank details and -- in dealings with public authorities -- the routing ID (Leitweg-ID). If these fields are missing, validation fails. A well-maintained PIM integration and clean customer master data are therefore the quiet foundation of the format-compliant invoice. Anyone tidying up store data for upcoming requirements such as the digital product passport at the same time builds the basis for reliable invoice data.
Subsequent Conversion Versus Native Generation
Subsequent PDF conversion
An XML is extracted after the fact from the existing invoice PDF. Quick to set up, but error-prone.
- Fields are read from the layout, not from data
- Missing mandatory fields only surface during validation
- Any layout change can break the extraction
- Viable as a stopgap, not as the target state
Native generation from order data
The store produces the structured data set directly from the order. This is the robust target state.
- All mandatory fields come from the data source itself
- Validation against EN 16931 before dispatch
- PDF visualization and XML stem from one source
- Scales from a single document to high invoice volume
Receiving and Processing Inbound Invoices
The receiving side has been mandatory since 2025 and is often underestimated. Inbound e-invoices must be accepted, validated against the schema and business rules of the standard, and then processed. Robust processing checks whether all mandatory fields are present and plausible before the document enters booking. This catches faulty invoices before they create effort in accounting.
Processing also includes a human-readable presentation: clerks and approvers want to see the document, not read the XML. The structured original is therefore supplemented with a readable visualization and routed into the ERP or the approval process via defined paths. For B2B operators who manage their purchasing through a customer or B2B portal, the invoice inbound can be embedded into the existing role and approval processes.
- Technically accept and store inbound e-invoices
- Validate against the EN 16931 schema and business rules
- Automatically check mandatory fields and plausibility
- Provide a human-readable visualization for approval
- Hand the structured data set to ERP and accounting
- Archive the XML original unchanged
Handoff to ERP and Accounting
The invoice is generated or arrives -- what matters is what happens next. The structured data set must reach the ERP and accounting so that order, invoice and payment come together. This is exactly the heart of the project: connecting the format-compliant invoice with the downstream systems. It is a clearly delineated interface project that cleanly separates the outbound process (generate and send the invoice) from the inbound process (accept and book the invoice) and connects both to the ERP.
The distinction from a pure booking connection is important. The document export into financial accounting covers how journal entries and document images are transferred into the ledger and how accounts are assigned. The e-invoicing mandate sits one level before that: at the legally mandated invoice format and at the outbound and inbound process. The two levels interlock -- the format is the standard-compliant shell, the booking connection processes its content. Coordinating both avoids media breaks between store, ERP and tax advisor.
Keep the Format Level and Booking Level Cleanly Separate
Exemptions: Small Amount, B2C and Special Cases
Not every invoice falls under the issuing obligation. Small-amount invoices up to EUR 250 gross are exempt and may still be issued as an other invoice, as are transport tickets (Federal Ministry of Finance). The obligation also applies only to domestic B2B transactions: invoices to end consumers (B2C) and to companies based abroad are not covered. Certain tax-exempt transactions may also be excluded.
- Small-amount invoices up to EUR 250 gross: still permitted as an other invoice
- Transport tickets: exempt from the e-invoicing obligation
- B2C transactions: invoices to end consumers are not covered
- Foreign relation: transactions with companies based abroad are outside the domestic obligation
- Certain tax-exempt transactions: excluded depending on the type of service
Do Not Make the Exemptions the Rule
Why 2026 Is the Preparation Year
The time until 2027 is tighter than it looks. The DIHK digitalization survey 2026 rates the digitalization level of the German economy at 2.8 on average and surveyed nearly 5,000 companies for it; without better framework conditions, digital progress risks stagnating especially in the mid-market (DIHK, 2026). At the same time, the receiving figure of just 45 percent (Bitkom Research, 2024) shows how many companies do not yet meet even the obligation that has applied since 2025. Anyone who approaches the 2027 issuing obligation without a test-run buffer risks faulty documents in live operation.
Add to this the format usage: of the companies able to receive, 71 percent rely on EDI formats, 27 percent on ZUGFeRD/Factur-X and 5 percent on XRechnung (Bitkom Research, 2024). This variety means a B2B store should be able to generate and accept different formats. Anyone planning an ERP switch in parallel -- such as the move from SAP ECC to S/4HANA described in a separate article -- is best advised to couple both efforts through a stable interface layer, so that format and system change do not block each other.
Receiving capability is already mandatory and the issuing obligation is drawing closer: 2026 decides whether the switch becomes an orderly process or a last-minute scramble before the deadline.
Roadmap: Introducing E-Invoicing in Store and ERP
A rollout project can be broken into manageable phases. It begins with an inventory of the existing invoice processes and ends with a monitored production operation. Unlike a full ERP migration, introducing e-invoicing is achievable within a clear timeframe -- provided it starts in good time.
- Inventory: Capture the current outbound and inbound processes, data sources and data quality in the store.
- Define the format: Choose the ZUGFeRD profile and XRechnung by recipient structure, reconcile mandatory fields.
- Set up generation: Generate the native e-invoice from the store's order data and validate against EN 16931.
- Build receiving: Accept, validate and human-readably present inbound invoices.
- Connect the ERP: Hand outbound and inbound to ERP and accounting, close the document chain.
- Test run and go-live: Check with real documents, coordinate with the tax advisor, then go live under monitoring.
Starting Early Creates Room
Archiving and GoBD Compliance
For the e-invoice, the structured XML data set is the original -- not the PDF visualization. For retention, this means: the XML part must be archived unchanged and machine-evaluable, so that in the event of a tax audit it is available in its source format. Merely storing the PDF image is not enough, because the structured data is lost in the process. This aligns with the German principles for proper management and storage of books (GoBD).
Note the retention period: with the Fourth Bureaucracy Relief Act, the period for invoices was shortened from ten to eight years. A continuous, logged document chain -- from generation in the store through the handoff to the ERP to audit-proof archiving -- considerably eases the evidence obligations. Closing this chain cleanly is part of the interface project and the reason why the format, booking and archiving levels should be considered together.
Sources and Studies