How to Implement E-Invoicing in Germany: A Practical Business Checklist

How to Implement E-Invoicing in Germany: A Practical Business Checklist

Swathy

Published on Sep 28, 2026

Subscribe to our newsletter

Use this practical Germany E-Invoicing implementation checklist to prepare scope, data, tax mapping, formats, transmission, receiving, validation, testing, archiving, ERP, security, and go-live.

Knowing the German E-Rechnung rules is only the starting point. A successful implementation also depends on clean master data, correct tax mapping, ERP integration, receiving processes, validation, transmission, archiving, testing, and clear ownership across the business.

This checklist is designed to help Finance, Tax, IT, Procurement, Accounts Payable, Sales, and business leadership assess what must be ready before go-live.

Use this checklist for every item: Is it complete? Who owns it? What is missing? What is the target date?

Key Takeaways

• Start by determining which transactions are covered by the German E-Rechnung rules and which exceptions apply.
• Confirm the applicable issuing transition, while remembering that the ability to receive E-Rechnungen has applied since January 1, 2025.
• Map ERP and master data to the structured invoice information required by the applicable format.
• Select the invoice format and transmission method according to the transaction, customer, and legal requirements.
• Build validation, exception handling, and testing into the implementation rather than treating them as post-go-live activities.
• Preserve the structured invoice data and design the archive around German retention and integrity requirements.
• Treat B2G as a separate workstream because public-sector requirements can differ from ordinary B2B rules.
• Give Finance, Tax, IT, and business teams clear responsibilities before production.

1. Determine Your Legal and Transaction Scope

Before selecting software or changing ERP processes, identify which invoices your business actually needs to handle under the German rules.

Check the transaction categories

• Domestic B2B transactions between inländische Unternehmer are the main focus of the German VAT-law E-Rechnung requirement, subject to the applicable exceptions and transition rules.
• B2C transactions are generally outside the mandatory B2B E-Rechnung requirement.
• B2G transactions must be assessed separately because public-sector invoicing is governed by additional rules, including the federal E-Rechnungsverordnung for the federal administration.
• Cross-border transactions should be assessed separately because the German domestic B2B E-Rechnung rules do not simply apply to every international invoice.

Check the exceptions

Review whether your invoices fall into categories for which an E-Rechnung is not required, such as qualifying small-value invoices, certain exempt transactions, invoices issued by Kleinunternehmer under the applicable rule, and other statutory exceptions.

Do not design one workflow for every invoice type. Create a transaction matrix showing the applicable rule, format, transmission method, and exception for each material scenario.

2. Confirm the Applicable Deadline

Germany's transition period is based on the invoice issuer's circumstances and the date of the underlying transaction.

The €800,000 test refers to the invoice issuer's relevant previous-calendar-year total turnover under the German VAT rules. It is not based on the German customer's turnover or the value of an individual invoice.

If your business is implementing in 2026, use the remaining transition period for production testing rather than waiting until the mandatory issuing date.

3. Build a Finance and Master-Data Readiness Checklist

Structured invoicing exposes weaknesses in the underlying data. Review the source information before building the integration.

Customer and supplier master data

• Legal names should be accurate and consistent across systems.
• Addresses and country information should be complete and correctly structured.
• VAT identification numbers and other relevant tax identifiers should be maintained where required.
• Customer and supplier records should be checked for duplicates, obsolete records, and missing information.
• Public-sector customers should have the correct procurement and routing information recorded separately from ordinary B2B customers.

Item and service data

• Product and service descriptions should support a clear and understandable description of the supply.
• Tax categories and VAT treatment should be mapped correctly.
• Units of measure and quantity information should be available where relevant.
• Pricing, discounts, allowances, and charges should be represented consistently.

Invoice data

Review whether the source system can reliably provide the information required for the selected structured format, including invoice identifiers, dates, seller and buyer information, line items, tax information, totals, payment information, references, and relevant document types.

Do not assume that a field exists simply because it appears on a PDF invoice. Confirm where the value comes from, whether it is structured, and whether it can be transferred without manual re-entry.

4. Map Tax and Invoice Scenarios

The implementation should cover more than a standard domestic invoice.

Create a scenario matrix for the transactions your business actually performs, such as:

• Standard-rated domestic supplies.
• Zero-rated or exempt supplies where relevant.
• Reverse-charge transactions where applicable.
• Credit notes and invoice corrections.
• Advance, partial, and final invoices where applicable.
• Discounts, allowances, and charges.
• Recurring invoices and other high-volume invoice types.
• B2G invoices with authority-specific requirements.
• Cross-border transactions that follow different invoicing rules.

For each scenario, document the expected tax treatment, source fields, structured fields, validation rules, accounting treatment, and exception process.

This is where Finance and Tax should work together. The e-invoicing layer can transform data, but it should not be expected to correct an incorrect underlying tax treatment.

5. Select the Appropriate Invoice Format

Germany does not require ordinary B2B invoices to use XRechnung specifically. The selected format must satisfy the applicable legal requirements and customer requirements.

XRechnung

XRechnung is Germany's national implementation of the EN 16931 semantic model and is particularly important for public-sector invoicing. The current XRechnung standard is version 3.0, with the 3.0.2 technical bundle in use in 2026.

ZUGFeRD

ZUGFeRD is a hybrid format containing structured XML and a human-readable PDF representation. Under the BMF guidance, qualifying ZUGFeRD versions and profiles can meet the E-Rechnung requirements, but the exact profile matters. ZUGFeRD MINIMUM and BASIC-WL should not be treated as qualifying E-Rechnung profiles.

Other structured formats

An agreed structured format can also qualify where it satisfies the statutory conditions, including the ability to correctly and completely extract the required invoice information into an EN 16931-compliant or interoperable format. Certain EDI arrangements can therefore remain relevant.

Before choosing a format, document:

Before choosing a format, document the required profile and version, customer requirements, ERP capabilities, validation rules, and transmission method.

6. Design the Transmission Process

German VAT law does not prescribe one universal transmission channel for E-Rechnungen. Depending on the transaction and agreement, an E-Rechnung may be transmitted by email, electronic interface, portal, or another suitable method.

Peppol is an important option, especially where customers or public authorities require or support it, but it is a transmission network and interoperability framework, not the German invoice format itself.

For each customer group, document:

• The accepted invoice format and profile.
• The required endpoint or recipient identifier.
• The transmission channel.
• Required customer references or order information.
• The response or acknowledgement that can be expected.
• The process for failed transmission or rejected invoices.

For federal B2G invoices, verify the current submission requirements of the federal administration. The Leitweg-ID is used to address the public-sector recipient and is provided by the contracting authority. The federal rules also prescribe specific submission channels and invoice information.

7. Build a Dedicated Receiving Process

Receiving is not just the reverse of issuing. It has its own operational controls.

Since January 1, 2025, domestic businesses generally need to be able to receive E-Rechnungen. A dedicated e-invoicing platform is not legally required merely to receive them, because an email inbox can satisfy the basic receipt capability.

For a scalable process, define how incoming invoices are:

1. Received from email, portals, Peppol, interfaces, or other agreed channels.
2. Identified and checked for format and structural validity.
3. Matched to suppliers, purchase orders, and other business records where applicable.
4. Routed for accounting review and approval.
5. Recorded in the ERP or accounting system.
6. Retained with the required structured data and supporting information.

Do not treat technical validation as automatic approval for payment. Finance still needs to perform the commercial and accounting checks appropriate to the business.

8. Implement Validation and Exception Handling

Validation should be part of the implementation design, but it should not be described as a general statutory precondition for tax recognition.

A practical layered approach is:

The validation process should start with source data and syntax checks, continue through EN 16931 or applicable profile rules and business checks, and cover transmission and exception handling.

What to test

• XML structure and syntax should be checked against the applicable specification.
• EN 16931 business rules should be checked where the format is based on the standard.
• XRechnung-specific rules should be checked when XRechnung is used.
• ZUGFeRD invoices should be checked for both the structured XML and consistency with the visual component where applicable.
• Tax calculations, customer references, payment information, invoice types, and other business data should be checked in the appropriate finance process.

Use clear error handling so that users can identify what failed, where it failed, what must be corrected, and whether the invoice can be safely resubmitted.

9. Test the End-to-End Process Before Go-Live

A successful test should cover the complete transaction rather than only invoice generation.

Outgoing testing

The ERP sends invoice data to the e-invoicing layer for mapping and validation, after which the invoice is transmitted to the customer or authority and the status is tracked.

Incoming testing

The supplier sends the invoice for receipt and validation. The business then matches it against the relevant records, processes it in the ERP, obtains approval, and archives it.

Test both successful and failed scenarios, including:

• Valid invoices.
• Missing or invalid data.
• Tax calculation errors.
• Duplicate invoices.
• Credit notes and corrections.
• Attachments and hybrid invoices where relevant.
• Transmission failures.
• Customer or authority rejection.
• Temporary system or network outages.
• Retry and resubmission scenarios.

Also test realistic transaction volumes if the business processes large invoice volumes.

10. Prepare the Archive and Evidence Trail

Archiving should be designed before production begins.

Under §14b UStG, invoices generally need to be retained for eight years. For an E-Rechnung, at least the structured part must be retained so that it remains unaltered in its original form.

The archive should support:

• Preservation of the original structured invoice data.
• Reliable retrieval and access control.
• Traceability between the invoice and the accounting record.
• Retention and controlled deletion according to the applicable rules.
• Preservation of relevant supporting information and processing evidence where required by the business's accounting controls.

For hybrid invoices such as ZUGFeRD, do not assume that the PDF representation can replace the structured XML. The structured component must be preserved, and the treatment of the visual component should follow the applicable retention and accounting requirements.

11. Build IT and ERP Readiness

The IT workstream should document the complete technical architecture before development begins.

ERP and source-system assessment

• Identify every ERP, billing, accounting, procurement, and other system that creates or receives invoice data.
• Identify where each required invoice field originates.
• Record fields that are available, missing, derived, transformed, or manually entered.
• Confirm that invoice corrections and document relationships can be represented correctly.

Integration design

Define the interfaces between the source system, e-invoicing layer, validation components, transmission channels, and receiving systems.

The integration should also define authentication, error handling, retry logic, duplicate prevention, monitoring, logging, and recovery procedures.

Version management

Do not hard-code a one-time specification into the implementation. Maintain the applicable format, profile, validation rules, and technical components as versioned configuration so they can be updated when standards change.

12. Establish Security, Continuity, and Operational Controls

Security requirements should be assessed according to the architecture, data processed, vendors involved, and the organisation's own policies.

Before go-live, confirm:

• Access controls and user roles are defined.
• Credentials and API authentication are managed securely.
• Sensitive invoice data is protected in transit and at rest as appropriate.
• Logging and monitoring are enabled.
• Backup and recovery procedures are tested.
• Temporary outages do not silently lose invoices.
• Duplicate prevention and retry controls are in place.
• Support and escalation responsibilities are documented.

Security certifications such as ISO 27001 may be useful vendor-selection criteria, but they should not be presented as a universal German E-Rechnung legal requirement unless a specific rule or contract requires them.

13. Prepare Finance, Tax, IT, and Business Teams

E-invoicing implementation should have clear ownership across functions.

Users do not need to become XML specialists. They need to understand their role, recognise common errors, know who owns each exception, and know how to correct and retry a failed process.

14. Define Customer and Supplier Onboarding

Customer and supplier requirements should be captured as part of implementation rather than discovered after go-live.

For customers, confirm the accepted format, profile, delivery channel, identifiers, references, attachments, and support process.

For suppliers, confirm the channels through which incoming E-Rechnungen will arrive and how those invoices will be routed into Accounts Payable.

For B2G, obtain the exact requirements from the relevant contracting authority. For federal customers, this includes the correct Leitweg-ID and submission requirements. Requirements for Länder and municipalities should be checked with the relevant authority because public-sector implementation is not identical across Germany.

15. Select an E-Invoicing Platform or Service Provider

Vendor selection should be based on the actual German implementation rather than a generic feature list.

Legal and format coverage

Confirm that the provider supports the formats, profiles, validation rules, and transaction scenarios relevant to your business. Do not accept a general claim such as "Germany compliant" without understanding what is actually covered.

ERP and integration capability

Check whether the platform can integrate with the ERP and accounting systems already in use through APIs, connectors, files, or other appropriate interfaces.

Validation and error handling

Check whether validation results are understandable to Finance and Tax users and whether the system supports correction, revalidation, and controlled resubmission.

Transmission and receiving

Confirm the channels required by your customers and suppliers, including email, portals, APIs, Peppol, or customer-specific interfaces where applicable.

Data and archiving

Confirm how original structured invoices, attachments, metadata, processing information, and exports are handled. The business should retain control over its records and understand what the provider stores and for how long.

Security and service operations

Review authentication, access control, encryption, logging, incident handling, availability commitments, support, disaster recovery, and change-management procedures.

Version and regulatory change management

Ask how the provider handles changes to XRechnung, EN 16931 validation artefacts, customer requirements, and other relevant technical specifications.

16. Create a Go-Live Readiness Review

Before production, confirm that the following are complete:

• The legal and transaction scope has been approved.
• Applicable issuing and receiving requirements have been documented.
• ERP and master-data mappings have been tested.
• Required formats and profiles have been confirmed.
• Outgoing and incoming transmission channels have been tested.
• Validation and exception handling have been tested.
• B2G requirements have been tested where applicable.
• Archiving and retrieval have been verified.
• Users have been trained.
• Support and escalation procedures are active.
• Monitoring and recovery procedures are operational.

Do not treat a successful test environment as proof that production is ready. Test data often hides master-data, customer-specific, and operational problems that appear only with real transactions.

17. Monitor and Improve After Go-Live

Implementation does not end when the first invoice is sent.

Track practical measures such as:

• Validation error rate.
• Invoice rejection rate.
• Transmission failures.
• Manual intervention volume.
• Incoming invoice processing time.
• Exception resolution time.
• Duplicate invoice incidents.
• Recurring data-quality problems.

Use these results to fix problems at their source. If the same validation error appears repeatedly, review the ERP mapping or master data instead of correcting every invoice manually.

A Simple Germany E-Invoicing Readiness Assessment

Use the following five areas to assess implementation maturity.

For each area, record Complete / In Progress / Gap, assign an owner, and set a target date. This turns the checklist into an implementation plan rather than a document that is simply marked as reviewed.

How Complyance Can Support the Implementation

Depending on the product configuration and selected workflow, Complyance can provide an e-invoicing and compliance layer between source systems and invoice recipients. The relevant scope should be confirmed for the required German formats, integrations, validation, receiving, transmission channels, and archiving workflow.

A typical architecture can be represented as:

The ERP or accounting system sends invoice data to the e-invoicing layer for mapping and validation. The invoice is then transmitted to the customer or authority, while status information and records are retained.

The objective is to support the existing finance and ERP environment rather than assume that an organisation must replace its core system.

Conclusion

Germany e-invoicing implementation is not a single software installation. It is a coordinated change across tax rules, master data, invoice processes, ERP integration, transmission, receiving, archiving, testing, and people.

The most effective approach is to identify the applicable scope first, map the data and processes second, build and test the technical workflow third, and then monitor the production process continuously.

The key question is not simply whether the business has an e-invoicing tool. It is whether the business can reliably create, receive, validate, exchange, account for, and retain the right invoice data for every relevant transaction scenario.

About the Author

Swathy

Content Marketer

I’m a Content Marketer at Complyance, focused on e-invoicing. Over the years, I’ve created a wide range of content, including blog posts, whitepapers, and product guides, which have supported Complyance’s growth across markets such as the UAE and EU regions. My goal is to deliver content that is comprehensive, clear, accurate, and easy to understand, no matter how complex the topic.

Connect on LinkedIn