E-Invoice Examples in Germany: XRechnung, ZUGFeRD & Peppol BIS 3.0

Germany’s e-invoicing mandate has created one very practical problem for businesses. Most companies understand the theory of structured invoices. Very few understand what an actual compliant invoice looks like in practice. That confusion usually starts with formats like XRechnung, ZUGFeRD and Peppol BIS Billing 3.0. This guide explains real E-invoice examples used in Germany, what changes between formats, and what businesses should actually pay attention to before implementation starts failing.

Key Takeaways

• Germany accepts multiple structured e-invoice formats including XRechnung, ZUGFeRD and Peppol BIS 3.0
• XRechnung is mandatory for many public sector invoicing scenarios in Germany and is also fully valid for B2B transactions. ZUGFeRD is often preferred in B2B environments because it combines structured XML data with a human-readable PDF.
• Peppol BIS 3.0 standardises invoice exchange across the Peppol network
• Most invoice failures happen because of missing mandatory XML fields, not because the XML file itself is invalid

What is an E-Invoice in Germany?

An e-invoice is not simply a PDF sent over email. Under Germany’s rules, the invoice must contain structured data that accounting and ERP systems can read automatically. Usually, this means XML-based formats like XRechnung or ZUGFeRD.

The confusion starts because some e-invoices still look like normal PDFs. But the important part is the embedded structured XML, not the visual invoice itself.

E-Invoice Formats Accepted in Germany

Germany currently supports multiple structured formats under the EN 16931 standard. This is where many businesses get confused because the formats solve slightly different operational problems.

1. XRechnung

XRechnung is Germany’s standard XML format mainly used for invoicing public authorities. It is highly structured and machine-readable. There is no human-readable invoice design unless businesses separately generate a PDF view.

If someone asks for an XRechnung invoice example, they are usually referring to the XML structure itself.

This is the format most federal authorities expect.

XRechnung: Pure XML, no visual layer

<?xml version="1.0" encoding="UTF-8"?>

<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">

  <rsm:ExchangedDocument>

    <ram:ID>INV-2024-001</ram:ID>

    <ram:TypeCode>380</ram:TypeCode>

  </rsm:ExchangedDocument>

</rsm:CrossIndustryInvoice>

2. ZUGFeRD

ZUGFeRD combines two things in one invoice:

• A visual PDF invoice
• Embedded XML structured invoice data

This makes ZUGFeRD easier for suppliers and finance teams because humans can still read the invoice normally while ERP systems process the XML in the background.

In practice, many private B2B companies prefer ZUGFeRD because it combines a readable PDF with structured XML data in a single file.

However, not every ZUGFeRD profile meets Germany's e-invoicing requirements. Businesses should use EN 16931-compliant profiles such as COMFORT or EXTENDED. Profiles like MINIMUM, BASIC and BASIC WL do not contain all mandatory invoice information required for EN 16931 compliance.

This distinction matters. A technically valid ZUGFeRD invoice may still fail to meet Germany's e-invoicing requirements if the wrong profile is used.

A typical ZUGFeRD example looks like a standard invoice on screen, but the compliant XML sits inside the PDF/A-3 file.

ZUGFeRD: Same XML structure, but embedded inside a PDF/A-3 file. The profile line is what matters most: 

<?xml version="1.0" encoding="UTF-8"?>

<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">

  <rsm:ExchangedDocumentContext>

    <ram:GuidelineSpecifiedDocumentContextParameter>

      <!-- Must be COMFORT or EXTENDED for EN 16931 compliance -->

      <ram:ID>urn:factur-x.eu:1p0:comfort</ram:ID>

    </ram:GuidelineSpecifiedDocumentContextParameter>

  </rsm:ExchangedDocumentContext>

</rsm:CrossIndustryInvoice>

3. Peppol BIS 3.0

Peppol BIS 3.0 is not just an invoice format. It is part of the Peppol exchange framework used for secure invoice transmission across networks.

Many businesses searching for a Peppol BIS 3.0 invoice example are actually trying to understand how invoice exchange works between buyer and supplier systems.

Peppol BIS 3.0 invoices are commonly used for:

• Cross-border invoicing
• Government procurement
• Automated supplier invoice exchange

The XML structure still follows EN 16931 principles, but transmission happens through the Peppol network.

Peppol BIS 3.0: UBL syntax (different from CII above), transmitted over the Peppol network: 

<?xml version="1.0" encoding="UTF-8"?>

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>

  <cbc:ID>INV-2024-001</cbc:ID>

  <cbc:IssueDate>2024-03-15</cbc:IssueDate>

  <!-- Endpoint IDs route the invoice through the Peppol network -->

  <cbc:EndpointID schemeID="0088">4012345000009</cbc:EndpointID>

</Invoice>

Mandatory Fields in a German E-Invoice (EU EN 16931 Standard)

This is where implementation problems usually begin.

A valid XML structure alone does not guarantee compliance. Missing mandatory fields often cause silent invoice rejection inside ERP systems or government portals.

A compliant German e-invoice generally requires:

Many businesses only realise field mapping problems after invoices begin failing in production. Especially during ERP integrations.

That part gets underestimated.

XRechnung E-Invoice Example

A standard XRechnung XML sample usually contains:

• Buyer reference
• Leitweg-ID for public authorities
• Structured tax breakdown
• Line-level invoice data
• XML-only invoice structure

Unlike traditional invoices, there is no designed visual layout. The XML itself becomes the invoice.

This is why finance teams often struggle initially. Humans are not supposed to read it manually.

Example search terms businesses commonly use:

• XRechnung example
• XRechnung XML sample
• Xrechnung invoice example

ZUGFeRD E-Invoice Example

A ZUGFeRD example typically looks like a normal PDF invoice to the user. But internally, it also contains structured XML data embedded within the PDF/A-3 document.

That dual-format structure is the reason many companies adopt ZUGFeRD for B2B invoicing.

It creates less operational resistance.

A standard ZUGFeRD XML example includes:

• Invoice metadata
• VAT calculations
• Structured line items
• Payment information
• Embedded EN 16931 compliant XML

Many businesses incorrectly assume any PDF invoice qualifies as ZUGFeRD. It does not. The XML embedding requirement is mandatory.

Peppol BIS 3.0 E-Invoice Example

A Peppol BIS 3.0 invoice example usually includes:

• Supplier and buyer Peppol IDs
• Structured XML invoice data
• Standardised invoice routing fields
• Cross-border compatible invoice structure

Peppol becomes especially important for businesses operating across multiple EU countries because supplier invoice exchange starts becoming standardised.

Without that standardisation, invoice interoperability becomes messy very quickly.

How to Choose the Right Format for Your Business

There is no single format that works best for every business. The right choice depends on both your systems and your customer's receiving capability.

If you invoice German public authorities, XRechnung is often required. For private sector transactions, many businesses use ZUGFeRD because it combines structured XML with a readable PDF. If your trading partners exchange invoices through the Peppol network, Peppol BIS 3.0 may be the better option.

Before selecting a format, consider:

• The formats your customers can receive and process
• Your ERP and accounting system capabilities
• Whether invoices need to be exchanged through the Peppol network
• Internal workflow requirements for invoice review and approval

One mistake businesses make is focusing only on invoice generation. In reality, the bigger challenge usually comes after implementation.

ERP mappings need maintenance. Supplier onboarding takes time. XML validations fail unexpectedly. Invoice delivery must be monitored and records must be archived correctly.

That is where most e-invoicing projects encounter problems after go-live.

Conclusion

Germany’s e-invoicing transition is pushing businesses away from visual invoices and towards structured invoice automation. Understanding real Germany e-invoice format examples is now becoming operationally important, not just technical.

XRechnung, ZUGFeRD and Peppol BIS 3.0 all solve different business requirements. Choosing the wrong structure can create reconciliation issues, supplier friction and invoice rejection problems later.

Most companies do not struggle because XML is complicated.

They struggle because invoice operations become fragmented across systems, suppliers and formats.

That usually surfaces much later than expected.