E-Invoicing 2026: What Online Shops Need to Know

Germany's e-invoicing mandate is fundamentally transforming B2B commerce. Since January 1, 2025, businesses established in Germany must be able to receive electronic invoices; consent is no longer required for this (§ 14 UStG). Issuing them is covered by a staged transition rule that runs out no later than December 31, 2027 (§ 27 (38) UStG). For online shops, this means: anyone supplying B2B customers needs a format based on the European standard – ZUGFeRD or XRechnung. In this article, you'll learn which deadlines apply, which format suits your shop, and how to implement the transition step by step.

Why the E-Invoicing Mandate Affects E-Commerce

Since January 1, 2025, German VAT law has distinguished two types of invoice. An electronic invoice is one that is issued, transmitted, and received in a structured electronic format and allows electronic processing (§ 14 UStG). Everything else counts as an other invoice, meaning an invoice transmitted in a different electronic format or on paper (§ 14 UStG) – a plain PDF included. This distinction is the core of the transition: it determines what a shop must be able to receive and what it is allowed to send.

Which format is permitted is set out in § 14 UStG. The structured electronic format must either comply with the European standard for electronic invoicing and the list of corresponding syntaxes under Directive 2014/55/EU, or be agreed between the issuer and the recipient. The agreed route carries an additional condition: the format must allow the correct and complete extraction of the information required by law from the electronic invoice into a format that complies with, or is interoperable with, that standard (§ 14 UStG). This is precisely why ZUGFeRD and XRechnung are the practical routes: both map the European standard.

The Legal Timeline: All Deadlines at a Glance

§ 14 UStG and the transition rule in § 27 (38) UStG set the dates by which online merchants must have adapted their invoicing processes:

ZUGFeRD vs. XRechnung: Which Format Fits?

Both formats satisfy the same requirement: they map the European standard for electronic invoicing that § 14 UStG references through Directive 2014/55/EU. The difference lies not in legal validity but in delivery: ZUGFeRD carries the structured XML inside a PDF/A-3 and therefore stays readable for people as well, while XRechnung is pure XML. For the question of whether an invoice meets the legal requirements, the choice between the two is irrelevant.

For most online shops, ZUGFeRD 2.x is the pragmatic choice: the hybrid format delivers a human-readable PDF invoice while simultaneously containing the structured XML data for machine processing. Integration with existing interfaces and ERP systems such as DATEV or SAP is possible with both formats.

ZUGFeRD Profiles: What Level of Detail Does Your Shop Need?

ZUGFeRD 2.x offers several profiles that differ in the depth of embedded XML data. The choice of profile directly impacts the level of automation and compliance capability of the e-invoice:

For most online shops, the EN 16931 (Comfort) profile or higher is the right choice, as it contains all mandatory fields of the European standard. Those who also serve public sector clients should implement the XRechnung profile directly – this is a subset of the ZUGFeRD standard and fully covers German B2G requirements. Everything else that matters when supplying public sector buyers is covered in a separate article. For invoices to federal contracting authorities, the electronic form is the rule anyway: under § 3 ERechV, issuers must create and transmit invoices electronically; exempt are, among others, invoices issued after a direct award up to an amount of €1,000 (§ 3 ERechV).

Decision Guide: ZUGFeRD or XRechnung for Your Use Case

The direction of travel is already settled in law: under Directive (EU) 2025/516, invoices will as a rule be issued as electronic invoices from July 1, 2030 for the purposes of the EU VAT Directive, and they must comply with the same European standard that German law refers to (Directive (EU) 2025/516). Anyone moving to ZUGFeRD or XRechnung today is not building for an interim solution.

• Pure B2B commerce without public sector clients: ZUGFeRD 2.x with EN 16931 profile – your customers receive a readable PDF with machine-readable XML data. Ideal for SME shops and trade businesses
• Mixed B2B and B2G: ZUGFeRD 2.x with XRechnung profile – you cover both recipient groups with a single format, eliminating the need for parallel processes
• Purely machine-based processing (high volumes): XRechnung as pure XML – minimal file size, maximum processing speed. Practical at high invoice volumes
• International B2B customers: ZUGFeRD 2.x / Factur-X – the German-French hybrid format is also used in France, Belgium, and Switzerland, facilitating cross-border invoicing

Duties at a Glance: Receiving, Issuing, Retention

The duty to receive knows no transition period and no revenue threshold. Any business in Germany buying a supply from another domestic business must be able to accept an electronic invoice; consent is no longer required for its transmission (§ 14 UStG). In practice that means an inbox that accepts XML attachments and PDF/A-3 files, and a way to store those files unchanged. The duty to issue, by contrast, is phased – it is the one that can be planned.

Three properties must hold for every invoice along its entire path: authenticity of origin, integrity of content, and legibility (§ 14 UStG). The law does not prescribe how this is achieved – any internal control procedure that creates a reliable audit trail between invoice and supply is sufficient (§ 14 UStG). A qualified electronic signature or an EDI procedure is expressly permitted, but not mandatory.

Practical Implementation for Online Shops

The transition to e-invoicing affects multiple areas of an online shop: from checkout through invoice generation to archiving and ERP connectivity. A structured approach typically avoids redundant work and compliance gaps.

1. Assessment: What invoice formats does your shop currently use? How many B2B invoices are generated monthly? Which ERP systems and accounting solutions are connected?
2. Format decision: ZUGFeRD 2.x or XRechnung? For most e-commerce scenarios, ZUGFeRD with the XRechnung profile is recommended – see the format comparison section above for details
3. Technical integration: Implement an e-invoicing module in the shop system. The XML structure must conform to EN 16931 and contain all mandatory fields per § 14 UStG
4. Set up validation: Every outgoing e-invoice should be validated against the EN 16931 schema. Invalid invoices can be rejected by the recipient
5. Adapt ERP connection: The DATEV interface or SAP integration must be able to import structured e-invoices and correctly process the XML data
6. Set up retention: Under § 14b (1) UStG, invoices must be retained for eight years; the period begins at the end of the calendar year in which the invoice was issued. The structured original must be preserved (§ 14b UStG)
7. Testing and go-live: Test parallel to the existing process, gather feedback from B2B customers, and transition gradually

Automation: From Manual Processes to Straight-Through Processing

The gain from automation lies not only in speed but in the audit trail. A structured record can be matched against order, delivery note, and incoming payment without being keyed in again – and that is exactly the reliable audit trail between invoice and supply that § 14 UStG requires (§ 14 UStG). What used to be an organizational routine with paper invoices becomes a traceable chain inside the system. Invoices without a structured record, on paper or as a plain PDF, do not bring this advantage: their data has to be extracted first, for example with AI document processing, before it fits into this chain.

For online shops with high transaction volumes, this translates to significant efficiency gains: incoming B2B orders are automatically linked with their corresponding e-invoice, payment receipts are matched directly, and booking data is passed to the ERP system or DATEV interface without media breaks. What used to move through accounting as a stack of paper becomes a record that can be checked, matched, and retained without being keyed in again.

Technical Integration into Shop Systems

The technical implementation of e-invoicing requirements depends on the shop system in use. Fundamentally, the development must cover three core areas: creating e-invoices in the correct format, validating against the EN 16931 schema, and connecting to downstream systems.

• Invoice generation: The shop system must be able to produce XML data in ZUGFeRD or XRechnung format. With ZUGFeRD, the XML file is embedded within a PDF/A-3 document
• Schema validation: Outgoing e-invoices should be automatically checked against the EN 16931 schema. Invalid invoices can be rejected by the recipient
• Reception capability: Incoming e-invoices (e.g., from suppliers) must be accepted and processed in structured format
• Interface connectivity: DATEV, SAP, or other ERP systems must be able to import e-invoice data in XML format – existing integrations need to be extended accordingly
• Retention in the original format: Under § 14b (1) UStG, the structured original must be retained for eight years and must meet the authenticity, integrity, and legibility requirements throughout that period (§ 14b UStG)

Especially for WooCommerce shops and other open-source systems, integration via dedicated plugins or middleware solutions that fully cover the EN 16931 standard is recommended. Professional consulting ensures the implementation fits your existing infrastructure.

Shopware: Integrating E-Invoicing in the Ecosystem

Shopware offers flexible options for e-invoicing integration through its plugin architecture. Extensions for ZUGFeRD and XRechnung are available through the Shopware Store, mapping the invoicing process directly in the admin backend. Key considerations for implementation include:

• Plugin selection: E-invoicing plugins should support the XRechnung profile within ZUGFeRD 2.x and include built-in validation against the EN 16931 schema
• Leverage Flow Builder: Shopware's Flow Builder enables automatic rules – for example: automatically generate ZUGFeRD invoices for B2B orders while continuing to send standard PDFs for B2C
• Customer group controls: B2B customers can automatically receive e-invoices via customer groups, while end consumers receive the familiar PDF format
• API integration: For custom solutions, the Shopware Admin API provides endpoints for programmatic invoice creation – useful when connecting to external ERP systems like SAP Business One

WooCommerce: E-Invoicing with Open-Source Tools

WooCommerce shops benefit from a broad plugin ecosystem. Both free and commercial extensions are available for e-invoice creation. Since WooCommerce is built on WordPress, e-invoicing functionality can be precisely integrated into existing workflows via hooks and filters:

• Adapt the existing invoice extension: An invoice plugin already in use can serve as a foundation – ZUGFeRD XML embedding is handled by an additional PHP library that produces a PDF/A-3 with embedded XML
• REST API for external systems: The WooCommerce REST API enables passing order data to external e-invoicing services and embedding the finished e-invoice back into the order
• Automatic format detection: Custom checkout fields allow customers to specify whether they prefer ZUGFeRD, XRechnung, or standard PDF
• Cron-based validation: A scheduled WordPress cron job can retrospectively validate outgoing invoices against the EN 16931 schema and flag defective documents for manual review

ERP Integration: DATEV, SAP, and Other Systems

The higher the invoice volume, the more each manual step weighs: what is a side task at twenty invoices a month ties up a full position at a multiple of that. Straight-through processing therefore pays off not above a particular number, but as soon as invoicing is regular and uniform.

DATEV Connectivity for E-Invoices

DATEV Unternehmen online and DATEV Rechnungswesen can directly process incoming e-invoices in ZUGFeRD and XRechnung formats. Your online shop's DATEV interface must meet the following requirements:

• DATEV Format Service: The DATEV Format Service enables automatic import of e-invoices and assignment to the correct booking accounts – without manual intervention
• XML mapping: The mapping of EN 16931 fields to the DATEV chart of accounts (SKR03/SKR04) must be correctly configured so that tax rates, general ledger accounts, and cost centers are automatically recognized
• Document image linking: With ZUGFeRD invoices, the PDF is stored as a document image in DATEV and linked to the accounting entry – significantly simplifying review by the tax advisor
• Batch processing: For high-volume shops, DATEV batch import enables processing hundreds of e-invoices in a single run

SAP Business One Integration

SAP Business One supports e-invoice receipt and dispatch through various channels. For online shops, integration via the Service Layer API or through middleware like the SAP Business One Integration Framework (B1IF) is typical:

• Document Parsing Framework: SAP B1 can automatically convert incoming ZUGFeRD/XRechnung XML files into accounts payable invoices via the Document Parsing Framework
• UDF extensions: User Defined Fields allow storing e-invoice metadata such as routing IDs or order references directly within the invoice document
• Outgoing invoices: SAP B1 can automatically generate outgoing invoices in ZUGFeRD format via add-ons or the DI API and send them to customers by email
• Intercompany scenarios: For corporate groups with multiple SAP instances, e-invoicing enables seamless document flow between entities without media breaks

Legal Consequences: What Actually Changes

Switching to electronic invoicing is first and foremost a legal obligation. The economic effect only materializes where the structured data is actually used – in matching, in posting, in retention. The comparison below shows how the two types of invoice differ in legal terms:

What the transition costs in an individual business depends on the existing infrastructure and cannot be stated in general terms. The direction, however, is predictable: the transition rule in § 27 (38) UStG is running out, and from July 1, 2030 the electronic invoice is the default under Directive (EU) 2025/516 as well. Every investment in structured invoice data therefore serves a requirement that is coming anyway – not an optional improvement.

Challenges and Obstacles in the Transition

In practice, the obstacles are rarely the format. More often they are invoice templates grown over years, in which mandatory details sit in places that cannot be mapped in a structured way; master data without a tax number or VAT ID; and processes in which the invoice is created only after dispatch. Clarifying these three points up front considerably shortens the actual technical changeover.

• Legacy systems: Older shop and ERP systems don't natively support EN 16931 – extensions or a system change may be required
• Lack of expertise: Correct implementation requires know-how in XML schema validation, PDF/A-3 generation, and ERP interfaces
• Supplier dependency: Incoming invoices from suppliers must also be processable in e-invoice format
• Parallel operation: During the transition phase, paper and e-invoice processes must run in parallel – this temporarily increases workload
• Training needs: Staff in accounting and order processing need training on the new processes

Common Mistakes When Implementing E-Invoicing

Almost all problems during the transition trace back to the same cause: the format question is solved technically, while the legal requirements for content, audit trail, and retention are left out. A file that technically complies with the standard but omits a mandatory detail under § 14 (4) UStG is not a proper invoice.

1. Misunderstanding PDF as e-invoice: A plain PDF without embedded XML data does not qualify as an e-invoice under the law. Even a PDF with an attached XML file is insufficient – with ZUGFeRD, the XML must be embedded within the PDF/A-3 container
2. Choosing the wrong ZUGFeRD profile: The Minimum profile does not contain sufficient data for EN 16931 compliance. Only the EN 16931 (Comfort), Extended, and XRechnung profiles fully meet the legal requirements
3. Skipping validation: Outgoing e-invoices are not checked against the official EN 16931 schema. Invalid invoices can be rejected by recipients, delaying payment receipts
4. Archiving in the wrong format: E-invoices must not be archived exclusively as printouts or converted PDFs. Under § 14b (1) UStG they must be retained for eight years and must meet the authenticity, integrity, and legibility requirements throughout that period (§ 14b UStG)
5. Not separating B2C and B2B: The e-invoicing mandate applies exclusively to B2B transactions between domestic businesses. A common mistake is issuing consumer invoices in e-invoice format, causing confusion
6. Not testing ERP imports: The XML data is generated correctly, but the import into DATEV or SAP was never tested. Field mappings, tax rate assignments, and chart of accounts must be validated upfront
7. Forgetting the routing ID: For invoices to public sector clients (B2G), the Leitweg-ID (routing ID) is a mandatory field. Without it, the invoice is rejected – a point frequently overlooked during implementation

Validation and Testing: Verifying and Securing E-Invoices

A robust validation process is the backbone of a functioning e-invoicing infrastructure. Defective e-invoices not only lead to rejections by recipients but can also have tax consequences – for instance, when input tax deduction is denied due to formal defects. Validation should occur at multiple levels:

Several validation tools are available for technical implementation: KoSIT (Coordination Office for IT Standards) provides the KoSIT Validator, an open-source tool that checks e-invoices against official Schematron rules. For automated workflows, this validator can be integrated into CI/CD pipelines or as middleware in the invoice dispatch process. Additionally, services like the ZRE portal (Central Invoice Receipt) offer online validation for XRechnung documents.

• Syntax validation against EN 16931 XSD schema configured
• Schematron rules for business logic activated
• PDF/A-3 conformity check for ZUGFeRD implemented
• Test dispatch to at least three different recipient systems completed
• Automatic error notification for validation failures configured
• Regular checks against updated Schematron versions scheduled

EU Perspective: ViDA and Cross-Border E-Invoicing

Directive (EU) 2025/516 amends the EU VAT Directive with effect from July 1, 2030. From that date, invoices are as a rule issued as electronic invoices for the purposes of the directive, and they must comply with the European standard for electronic invoicing (Directive (EU) 2025/516). Member States must adopt and publish the implementing provisions by June 30, 2030.

For online shops with customers elsewhere in the EU, this is more than a footnote. The standard that ZUGFeRD and XRechnung align with today is the same one the European rules will point to from 2030 (Directive (EU) 2025/516). Anyone moving cleanly to structured invoice data now does not have to walk the path a second time for cross-border business.

What ViDA Specifically Means for Online Shops

ViDA stands for 'VAT in the Digital Age' and covers more than the form of the invoice. Alongside the electronic invoice as the default, the directive introduces a reporting duty for intra-Community transactions and adapts the rules for platforms and for single VAT registration. For a shop’s invoicing process, the first point matters most: the invoice itself becomes the record that feeds the report.

The directive names two specific timings. For the invoice itself, from July 1, 2030 an invoice is to be issued no later than ten days after the chargeable event. The data is transmitted at the time the invoice is issued or should have been issued (Directive (EU) 2025/516). A deadline counted in business days after invoicing is not part of the directive.

Checklist: E-Invoicing Compliance for Your Online Shop

• Reception capability for e-invoices (EN 16931) confirmed
• Format selected: ZUGFeRD 2.x or XRechnung
• Shop system extended with e-invoicing module
• Schema validation for outgoing invoices implemented
• ERP/DATEV interface adapted for structured XML data
• GoBD-compliant archiving in original format set up
• Parallel operation paper/e-invoice tested during transition
• Accounting and order processing staff trained
• B2B customers informed about new invoice format
• Monitoring for validation errors and delivery issues activated

Frequently Asked Questions About E-Invoicing in E-Commerce