SAP E-Invoicing in Germany: Requirements, Integration and Compliance

SAP E-Invoicing in Germany: Requirements, Integration and Compliance

Swathy

Published on Sep 28, 2026

Subscribe to our newsletter

Understand SAP e-invoicing in Germany, including German requirements, XRechnung and ZUGFeRD support, SAP workflows, Peppol, integration, testing, and compliance controls.

If your business already runs on SAP, Germany's E-Rechnung mandate does not mean you need to replace your ERP.

The bigger question is:

Can your SAP environment create, receive, validate, transmit, and retain the structured invoices required in Germany?

SAP Document and Reporting Compliance provides Germany-specific electronic-document capabilities, but the available processes depend on the SAP product, release, licensing, configuration, and connected services.

SAP's Germany documentation covers electronic customer and supplier invoices, XRechnung, ZUGFeRD-related profiles, email transmission, Peppol exchange, and incoming electronic-invoice processes. For an SAP customer, implementation is therefore less about adding an e-invoice function and more about connecting the existing invoice process to the applicable German compliance requirements.

What Does SAP E-Invoicing Mean in Germany?

SAP e-invoicing is the process of using invoice data created in an SAP source application to produce a structured electronic invoice and then sending or receiving it through the appropriate channel.

For outbound invoices, the process can involve creating an electronic document from the SAP source invoice, applying the relevant German rules and validation, generating the required invoice format, and transmitting it to the customer.

For incoming invoices, the process can involve receiving a structured invoice, processing and validating it, mapping the data into the relevant SAP workflow, completing any required review or matching, and recording the invoice in the accounting process.

SAP's Document and Reporting Compliance framework can create electronic document instances from supported source documents and can also support documented processes for electronic documents received from business partners.

What Are the Germany E-Invoicing Requirements for SAP?

The SAP configuration must ultimately produce and process invoices that meet the applicable German E-Rechnung rules.

Germany's framework is based on structured electronic invoice data. The format may follow EN 16931 and its syntax list, or may be another agreed structured format that permits the legally required information to be extracted correctly and completely into an EN 16931-compliant or interoperable format.

The German VAT-law E-Rechnung requirement mainly concerns covered B2B transactions between businesses established in Germany or in relevant German VAT territories. The transaction scope, exceptions, transition periods, and establishment facts must be checked before configuring the SAP process.

An SAP team should therefore check:

• The transaction should be assessed to determine whether it falls within the German E-Rechnung scope.
• The invoice format should be selected according to the legal requirements and customer or recipient requirements.
• The required invoice information should be available and accurate in SAP.
• The generated invoice should be checked against the applicable syntax and business rules.
• The transmission method should be appropriate for the recipient and transaction.
• The original structured invoice data should be retained in a compliant, retrievable form. The business remains responsible for retention even when SAP, a connected archive, or an external provider performs the technical storage. Where relevant, retention should also cover related visual documents, attachments, validation evidence, and transmission records.

The SAP system is only one part of this process.

A compliant SAP implementation needs the business data, German rules, format, validation, transmission, receiving, and retention to work together.

Transaction Type Matters

The same SAP system may handle domestic B2B, B2C, B2G, cross-border, reverse-charge, tax-exempt, and small-value invoices. These categories can have different German invoicing treatment, so the eDocument process should be selected by transaction type rather than applied universally.

Which German E-Invoice Formats Can SAP Support?

Two formats are particularly important in the German market:

XRechnung is a structured XML invoice.

ZUGFeRD is a hybrid PDF/A-3 document containing embedded structured XML.

SAP documentation describes XRechnung scenarios using the UN/CEFACT Cross Industry Invoice (CII) syntax. SAP also documents ZUGFeRD-related profiles, including the ZUGFeRD XRechnung profile and configurable profiles such as ZUGFeRD Comfort in relevant processes.

The fact that SAP supports documented ZUGFeRD-related processes does not mean that every ZUGFeRD profile is valid for every German use case. The business must verify the profile assigned to each customer and whether the resulting invoice satisfies the applicable German requirements.

XRechnung should not be treated as a PDF/A-3 document. A standard XRechnung is structured XML, while the PDF/A-3 wrapper is associated with hybrid ZUGFeRD scenarios.

The important question for an SAP team is therefore not simply whether SAP supports XRechnung.

It is:

Which German format and profile does each customer require, and can the SAP process generate and process it correctly?

SAP Outbound E-Invoicing Workflow

For customer invoices, the process can begin with an invoice created in an SAP source application.

SAP's documented processes can create an electronic document from the source invoice. The electronic document can then be processed through the relevant Germany process and transmitted to the customer.

Depending on the configured SAP process, the email may contain the XML as an attachment or a PDF/A-3 document with the structured XML embedded. In SAP's documented email process, the structured XML invoice can be attached to an email and sent to the customer's email address stored in customer master data.

SAP also documents electronic customer invoice submission through Peppol Exchange when the required Document and Reporting Compliance cloud integration, onboarding, recipient configuration, and other prerequisites are in place.

This means businesses can have different transmission routes depending on the recipient and the configuration of their SAP landscape.

SAP Incoming E-Invoicing Workflow

Germany's mandate also makes receiving important.

SAP documents processes for receiving electronic supplier invoices, including email-based receipt and Peppol-based receipt in supported environments. Incoming automation solutions and other connected components may also be involved.

Receipt and technical validation do not necessarily mean automatic posting.

Supplier matching, purchase-order matching, tax review, duplicate checking, approval, and exception handling may still require configuration or human review.

A practical incoming process can therefore involve receiving the E-Rechnung, processing and validating the structured data, identifying the supplier, matching the invoice where applicable, completing approval or exception handling, posting it to the accounting process, and retaining the original invoice data.

What Happens If SAP Receives an XML Invoice by Email?

SAP's Germany documentation covers XML invoices received by email.

For SAP's documented incoming-email process, the received XML must comply with the applicable CEN/EN 16931 requirements, and SAP identifies XRechnung as Germany's national Core Invoice Usage Specification. The exact inbound requirements depend on the SAP product, release, and configured process.

The receiving process can then apply the relevant checks and continue into the SAP supplier-invoice workflow.

This can be useful for businesses that begin with email-based receipt before introducing a more automated exchange channel.

SAP and Peppol in Germany

Peppol is another possible part of the SAP e-invoicing architecture.

The roles should be kept separate:

• German E-Rechnung rules determine the legal requirements applicable to the invoice.
• XRechnung or another qualifying invoice format structures the invoice data.
• Peppol provides a governed network and exchange framework for electronic documents.

SAP's current documentation describes electronic customer invoice submission through Peppol Exchange using SAP Document and Reporting Compliance cloud edition. SAP also documents receiving supplier invoices through Peppol access points in supported scenarios.

Peppol Exchange provides the network exchange path. SAP still needs to generate the appropriate invoice format, apply the relevant business rules, configure the recipient endpoint, and process the transmission response.

The customer must be reachable through Peppol, and the relevant participant identifier and endpoint configuration must be available.

A Peppol access point does not by itself guarantee that an invoice complies with German invoice-content requirements.

SAP Master Data Matters More Than It Looks

A technically correct SAP configuration can still produce invoice problems if the underlying master data is incomplete.

SAP's Germany documentation includes customer and business-partner master-data requirements as part of electronic invoice processes.

Businesses should review the following information:

• Customer legal name should be complete and consistent with the recipient's required identification.
• Address information should be accurate and complete.
• Tax identifiers should be maintained where required for the transaction.
• Customer identifiers should be available when required by the invoice format or recipient.
• Payment information should be accurate where applicable.
• Delivery information should be available where required.
• Buyer references should be maintained when required by the recipient or public-sector process.
• Format and transmission preferences should be configured according to customer requirements.

For many German public-sector workflows, the Leitweg-ID is a required routing identifier. The exact requirement depends on the authority and applicable federal, state, or municipal process. The supplier should obtain the correct Leitweg-ID from the public-sector customer or procurement documentation rather than deriving it from ordinary customer master data. It is generally not required for ordinary B2B invoices.

Incomplete or incorrect master data can therefore cause an invoice to fail even when the SAP configuration itself is correct.

The business remains responsible for compliant retention.

Validation should normally take place before an invoice is transmitted to the customer.

Validation can identify issues such as:

• Missing required information can prevent the invoice from satisfying the applicable requirements.
• Invalid identifiers can cause recipient or business-rule checks to fail.
• Incorrect invoice calculations can create inconsistencies in the structured invoice data.
• Invalid XML structure can prevent the document from being processed.
• Invoice-specification rules can identify content that does not meet the applicable format or business rules.

In documented Germany scenarios, SAP Document and Reporting Compliance can send electronic document data to connected cloud services for business-rule checks and return the result to the eDocument process. The exact validation scope depends on the product, release, service, configuration, and invoice format.

A practical process should allow an invoice to be checked, corrected when necessary, checked again, and then transmitted.

This is safer than sending the invoice first and discovering a structural or business-rule problem after delivery.

SAP Integration Challenges Businesses Should Expect

SAP e-invoicing projects can become complicated because the ERP is usually connected to many other systems.

A business may have SAP source applications, SAP modules, tax configuration, customer master data, an e-invoicing service, transmission channels, and external billing or commerce platforms.

The implementation team should therefore review the complete invoice flow rather than configuring only the invoice output.

SAP Version and Support Level

Check the exact SAP product, deployment model, release, support package, and available Germany functionality.

The evaluation should confirm whether the system is SAP S/4HANA Cloud, SAP S/4HANA private cloud, SAP S/4HANA on-premise, SAP ERP, or another SAP environment.

The team should also confirm whether SAP Document and Reporting Compliance is licensed and activated, whether cloud edition services are required for specific validation or Peppol functions, which scope items and country versions are active, which SAP Notes and support packages apply, whether custom or external source systems are involved, how incoming email and Peppol invoices are processed, where original XML files are retained, and what happens if a connected cloud service is unavailable.

Source Applications

Identify where invoices originate.

SAP documents electronic document creation from supported source applications such as customer billing and other supported documents.

If invoice data originates outside SAP, the integration can be different.

SAP documents scenarios for creating and submitting electronic documents from external systems, subject to the relevant API and configuration requirements.

This matters for businesses that use SAP as the financial system but operate separate billing, commerce, subscription, or other source platforms.

External Systems

External systems can introduce additional mapping and integration requirements.

The implementation should identify where invoice data is created, where tax information is maintained, where customer identifiers are stored, and which system is responsible for transmission and status handling.

The exact integration approach depends on the SAP environment, source application, connected services, and target transmission channel.

Some SAP landscapes use SAP Business Network or another connected invoice-automation service for supplier invoice receipt, conversion, matching, or workflow. This should not be assumed to be part of every SAP Document and Reporting Compliance implementation.

Should You Build German E-Invoicing Directly Into SAP?

Not every company needs to put all compliance logic inside SAP.

For a simple SAP environment with one country and a limited number of invoice workflows, native SAP capabilities may be sufficient for the required processes, subject to the product, release, licensing, and configuration.

For a multinational business, the situation can be different.

The company may need to manage German formats and requirements alongside different formats, transmission methods, validation rules, and reporting obligations in other countries.

Future regulatory changes can also introduce new validation, reporting, or exchange requirements.

In that situation, a dedicated e-invoicing compliance layer can sit between SAP and external customers or transmission channels.

This architecture can keep the ERP focused on business transactions while a compliance layer handles country-specific e-invoicing requirements.

Whether that approach is appropriate depends on the customer's SAP landscape, existing SAP capabilities, countries covered, integration strategy, and operational requirements.

SAP E-Invoicing Compliance Checklist

Before going live, an SAP team should check:

1. Scope: The team should identify which German transactions require E-Rechnungen and which exceptions or transition rules apply.
2. SAP version: The team should confirm that the required Germany functionality is available in the specific SAP product and release.
3. Source data: The team should verify that SAP contains all required invoice information.
4. Master data: The team should confirm that customer and supplier records are complete and accurate.
5. Format: The team should verify that the system can generate the required structured format or agreed structured format.
6. Validation: The team should confirm how invoices are checked before transmission and what validation services are involved.
7. Transmission: The team should confirm whether invoices will be sent by email, Peppol, customer-specific portals, or another permitted method.
8. Receiving: The team should verify how incoming structured invoices are received and processed.
9. Exceptions: The team should define what happens when an invoice fails validation, transmission, matching, or another processing step.
10. Retention: The team should confirm that the original structured invoice data is retained in an unaltered and retrievable form.
11. Monitoring: The team should confirm how finance and IT teams can monitor invoice processing, failures, and relevant transmission responses.
12. Updates: The team should define who monitors German regulatory, format, and SAP changes.

This checklist turns SAP e-invoicing from a technical project into a complete finance and compliance process.

SAP E-Invoicing Component Architecture

SAP e-invoicing in Germany may involve multiple components depending on the customer's environment and requirements.

The exact architecture depends on the SAP product, release, transaction type, licensed services, configuration, and required transmission channel.

Testing SAP E-Invoicing Before Go-Live

Testing should cover the invoice scenarios that the business will actually process.

• Domestic B2B invoices should be tested against the applicable German scope and format requirements.
• Invoices with multiple tax rates should be tested to confirm that the tax data is represented correctly.
• Credit notes should be tested to confirm that the correct invoice type and reference information are generated.
• Advance and final invoices should be tested where these transaction types are used.
• Foreign customer invoices should be tested separately because their legal and technical treatment can differ.
• B2C transactions should be tested separately from covered B2B E-Rechnung scenarios.
• B2G invoices with a Leitweg-ID should be tested against the applicable authority's requirements.
• XRechnung email delivery should be tested to confirm that the structured XML is generated and transmitted correctly.
• ZUGFeRD output should be tested with the specific profile required by the relevant customer.
• Peppol submission should be tested with the intended participant and endpoint configuration.
• Incoming supplier XML should be tested through the intended receiving process.
• Duplicate invoices should be tested to confirm that duplicate handling works as intended.
• Invalid buyer references should be tested to confirm that errors are detected and handled.
• Failed validation should be tested to confirm that the invoice can be corrected and reprocessed.
• Failed transmission should be tested to confirm that the failure is visible and the invoice can be handled appropriately.
• Corrected and reprocessed invoices should be tested to confirm that exception workflows work correctly.

How Complyance Can Work With SAP

At Complyance, we approach SAP e-invoicing as a compliance and integration workflow rather than simply as a file-conversion task.

Depending on the customer's SAP landscape, Complyance can complement SAP's native capabilities or provide an external compliance and exchange layer for German and other country-specific workflows.

The exact capabilities should be confirmed for the customer's intended architecture, including SAP integrations, supported invoice formats and profiles, validation scope, receiving capabilities, archiving features, transmission methods, and status or error-handling functions.

For an architecture where Complyance is used as an external compliance layer, it can sit between the SAP source system and the relevant e-invoicing channels.

This approach can help businesses keep SAP as the source of their financial data while using an additional compliance layer for Germany and other markets where required.

For businesses operating across several countries, the approach can also reduce the need to build separate country-specific e-invoicing logic directly into SAP, depending on the overall architecture.

Conclusion

SAP can be a strong foundation for Germany's E-Rechnung requirements, but the ERP alone does not make an implementation compliant.

A complete implementation needs the invoice data, applicable rules, structured format, validation process, transmission method, receiving process, exception handling, monitoring, and retention arrangements to work together.

Businesses should first understand their German transaction scope.

They should then check their SAP product and release, licensing, master data, invoice formats, validation services, transmission channels, incoming invoice process, retention architecture, and exception handling.

For companies already using SAP, the goal should not necessarily be to replace the ERP.

The goal should be to connect SAP's existing finance workflows with a reliable German e-invoicing process that fits the company's legal, technical, and operational requirements.

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