E-Invoice Examples Germany: Templates & Downloads 2026
Germany's B2B e-invoicing mandate is rolling out now. The receiving obligation has been active since January 1, 2025. The sending obligation starts January 1, 2027 for larger businesses and January 1, 2028 for all businesses.
Table of Contents
Germany's B2B e-invoicing mandate is rolling out now. The receiving obligation has been active since January 1, 2025. The sending obligation starts January 1, 2027 for larger businesses and January 1, 2028 for all businesses.
If you are an international business operating in Germany or a developer building invoicing into your product, you need working e-invoice examples right now — actual XML you can open, validate, and ship.
Key Takeaways
- Germany accepts two main e-invoice formats: XRechnung (pure XML) and ZUGFeRD (hybrid PDF/XML).
- Every e-invoice example Germany requires compliance with EN 16931.
- XRechnung is mandatory for B2G invoices and accepted for B2B from 2027.
- ZUGFeRD 2.x embeds structured XML inside a PDF/A-3 file.
What Does a German E-Invoice Actually Look Like?
A German e-invoice is not a PDF you email as an attachment.
According to KoSIT, a valid e-invoice in Germany is a structured electronic document that conforms to the European standard EN 16931. It must be machine-readable. It must contain mandatory fields like seller tax ID, line-item details, and payment terms in a defined schema.
Two formats dominate the German market:
| Feature | XRechnung | ZUGFeRD 2.x |
|---|---|---|
| Format | Pure XML (UBL or CII) | Hybrid PDF/A-3 + embedded XML |
| Human-readable? | No | Yes (PDF layer) |
| Machine-readable? | Yes | Yes (XML layer) |
| B2G mandatory? | Yes, since Nov 2020 | Accepted (EN 16931 profile or higher) |
| B2B ready for 2027? | Yes | Yes |
| Standard | EN 16931 / XRechnung spec | EN 16931 / ZUGFeRD spec |
| Maintained by | KoSIT | FeRD / AWV |
What Does an XRechnung Example Look Like in XML?
XRechnung is Germany's national implementation of EN 16931. It uses either UBL 2.1 or UN/CEFACT CII syntax.
Here is a simplified e-invoice XML sample for an XRechnung in UBL format:
<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>INV-2026-001842</cbc:ID>
<cbc:IssueDate>2026-04-21</cbc:IssueDate>
<cbc:DueDate>2026-05-21</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>BUYER-REF-04821</cbc:BuyerReference>
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyName>
<cbc:Name>Muster GmbH</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Hauptstrasse 12</cbc:StreetName>
<cbc:CityName>Berlin</cbc:CityName>
<cbc:PostalZone>10115</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>DE123456789</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:LegalMonetaryTotal>
<cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Software Development Services</cbc:Name>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount>
</cac:Price>
</cac:InvoiceLine>
</ubl:Invoice>Pro Tip: The CustomizationID field is what tells validators this is an XRechnung. Get it wrong and your invoice fails validation immediately.Notice the BuyerReference field. For B2G invoices in Germany, this is mandatory — it is the "Leitweg-ID" that routes your invoice to the correct government department.
How Does a ZUGFeRD Example Work?
ZUGFeRD embeds structured XML data inside a PDF/A-3 file. Your accountant sees a normal PDF, while your ERP system extracts the machine-readable XML automatically.
ZUGFeRD 2.3.3 supports six profiles:
| Profile | Use Case | EN 16931 Compliant? |
|---|---|---|
| Minimum | Basic header data only | No (internal use only) |
| Basic WL | Extended header, no line items | No (internal use only) |
| Basic | Standard B2B invoices | Yes |
| EN 16931 (Comfort) | Full EU standard compliance | Yes |
| Extended | Additional business fields | Yes (superset) |
| XRechnung | XRechnung-compliant XML in PDF container | Yes |
Here is a stripped-down ZUGFeRD example of the embedded CII XML:
<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>ZF-2026-00293</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260421</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<rsm:SupplyChainTradeTransaction>
<ram:ApplicableHeaderTradeAgreement>
<ram:SellerTradeParty>
<ram:Name>Muster GmbH</ram:Name>
</ram:SellerTradeParty>
<ram:BuyerTradeParty>
<ram:Name>Beispiel AG</ram:Name>
</ram:BuyerTradeParty>
</ram:ApplicableHeaderTradeAgreement>
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
<ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
<ram:DuePayableAmount>1190.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
</rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>Important: ZUGFeRD and Factur-X are technically the same format. France's Factur-X and Germany's ZUGFeRD merged in version 2.0.
XRechnung vs ZUGFeRD: Which E-Invoice Template Should You Use?
| Criteria | Choose XRechnung | Choose ZUGFeRD |
|---|---|---|
| Invoicing German government | Required | Accepted (EN 16931 profile or higher) |
| B2B invoicing after Jan 2027 | Accepted | Accepted |
| Recipient needs a visual PDF | Not ideal | Preferred |
| Your ERP supports both | Either works | Either works |
| Cross-border (France + Germany) | Requires mapping | Native (Factur-X = ZUGFeRD) |
| Developer integration effort | Lower | Higher |
How Do You Create Your Own German E-Invoice?
Option 1: Use an API (fastest)
Send JSON. Get valid XRechnung or ZUGFeRD back. Complyance's REST API handles schema validation, tax math, and PDF generation in one call.
Option 2: Use an open-source library
Libraries like mustangproject (Java) or factur-x (Python) let you build invoices in code.
Option 3: ERP or accounting software export
Tools like DATEV, lexoffice, and sevDesk now export XRechnung and ZUGFeRD natively.
Option 4: Manual XML creation
Suitable only for testing and development.
Pro Tip: Always validate against the official KoSIT validator before you send.
Do's and Don'ts for German E-Invoices
| Do | Don't |
|---|---|
| Include the Leitweg-ID for B2G invoices | Send a plain PDF and call it an "e-invoice" |
| Use the correct CustomizationID for XRechnung 3.x | Copy an old XRechnung 2.x identifier |
| Set InvoiceTypeCode to 380 for standard invoices | Use 381 (credit note code) for a regular invoice |
| Validate XML against the KoSIT schema before sending | Assume your ERP output is always valid |
| Embed XML as factur-x.xml in PDF/A-3 for ZUGFeRD | Embed it in a regular PDF |
| Include seller VAT ID (DE • 9 digits) | Omit tax registration for domestic invoices |
Related posts
Frequently Asked Questions
Germany requires EN 16931-compliant structured formats. XRechnung and ZUGFeRD 2.x (EN 16931 profile or higher) both qualify. A standard PDF does not count.
No. XRechnung is mandatory only for B2G invoices since November 2020.
Yes, but only with the EN 16931 (Comfort), Extended, or XRechnung profile.
Complyance offers a free e-invoice generator that produces valid XRechnung and ZUGFeRD files. KoSIT also publishes sample XRechnung files.
They are the same format since version 2.0. ZUGFeRD is the German branding; Factur-X is the French branding.
No. The Leitweg-ID is specific to B2G invoices.
The receiving obligation has been in effect since January 1, 2025. The sending obligation phases in from January 1, 2027 for businesses with prior-year revenue above EUR 800,000, and from January 1, 2028 for all businesses.
Yes. If you invoice a German B2B customer, you should send an EN 16931-compliant e-invoice.
Quick Summary
- Use XRechnung for German government invoices. It is pure XML.
- Use ZUGFeRD when your recipient needs a human-readable PDF with embedded structured data.
- Both formats comply with EN 16931 and satisfy Germany's B2B e-invoicing mandate.
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.
