E-Invoice Example for Germany: An XRechnung Explained Line by Line

An e-invoice example for Germany shows one thing above all: the invoice is an XML file, and each mandatory detail under Section 14(4) of the German VAT Act (§ 14 UStG) sits in its own element with a fixed EN 16931 business term (BT) number. Below we walk through an XRechnung 3.0 in UBL syntax, from BT-1 to BT-115.

This is for you if you have received your first XRechnung from a German customer, need to check what your ERP exports, or are building an integration. All data is fictitious: Muster GmbH bills Beispiel AG for ten hours of consulting and a training fee.

What is inside a German e-invoice?

A German e-invoice (E-Rechnung) is an invoice whose content is a structured data set under EN 16931, so software can read every detail without text recognition. That is the definition in § 14(1) UStG since 1 January 2025. For the full distinction from PDF and paper, read What Is an E-Invoice?.

The content is the same as on a paper invoice. The form is different:

The BT numbers are the common language. They come from the EN 16931 semantic data model and apply to every accepted syntax. XRechnung is the German implementation of the standard, specified by the Coordination Office for IT Standards (Koordinierungsstelle für IT-Standards, KoSIT). The current specification is XRechnung 3.0.2, which xeinkauf.de (opens in a new tab) says stays in force until at least 31 July 2027.

How is the example invoice structured?

A UBL XRechnung follows a fixed element order set by the XML schema. Our example has five blocks:

1. Header: identifiers, number, date, type, currency, buyer reference.
2. Seller (BG-4) and buyer (BG-7): names, addresses, electronic addresses, tax IDs, contact.
3. Delivery and payment: delivery date, payment means, IBAN, payment terms.
4. Tax and totals: VAT breakdown (BG-23) and document totals (BG-22).
5. Lines (BG-25): one per item.

The excerpts below are shortened and show one block each. A complete annotated file is available as our XRechnung example template.

Block 1: the header

<Invoice xmlns="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>RE-2026-0042</cbc:ID>
  <cbc:IssueDate>2026-10-09</cbc:IssueDate>
  <cbc:DueDate>2026-11-08</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>04011000-1234512345-06</cbc:BuyerReference>

Line by line:

• cbc:CustomizationID is the specification identifier BT-24. It tells the recipient and any validator which rule set the file follows; the xeinkauf.de:kosit:xrechnung_3.0 value means XRechnung 3.0. Without BT-24, EN 16931 rule BR-01 fails. With an outdated value, the KoSIT validator finds no matching scenario at all.
• cbc:ProfileID is the business process BT-23. EN 16931 leaves it optional; the XRechnung rules require it (PEPPOL-EN16931-R001, error level).
• cbc:ID is the invoice number BT-1 (§ 14(4) sentence 1 no. 4 UStG).
• cbc:IssueDate is the issue date BT-2 (no. 3). UBL always writes dates as YYYY-MM-DD.
• cbc:DueDate is the optional due date BT-9.
• cbc:InvoiceTypeCode is the invoice type BT-3. In code list UNTDID 1001, 380 is a commercial invoice and 381 a credit note; XRechnung allows only 326, 380, 381, 384 and 389 (BR-DE-17).
• cbc:DocumentCurrencyCode is the currency BT-5.
• cbc:BuyerReference is the buyer reference BT-10. XRechnung makes it mandatory (BR-DE-15). For public-sector buyers it holds the Leitweg-ID (buyer reference, BT-10), here the sample 04011000-1234512345-06. Between businesses, any reference the customer gives you works, such as a cost centre.

Block 2: seller and buyer

  <cac:AccountingSupplierParty><cac:Party>
    <cbc:EndpointID schemeID="EM">rechnung@muster-gmbh.example</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>Hauptstraße 42</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:PartyLegalEntity><cbc:RegistrationName>Muster GmbH</cbc:RegistrationName></cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:Name>Accounts</cbc:Name>
      <cbc:Telephone>+49 30 1234560</cbc:Telephone>
      <cbc:ElectronicMail>buchhaltung@muster-gmbh.example</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party></cac:AccountingSupplierParty>

• cbc:EndpointID is the seller electronic address BT-34, here an e-mail address with scheme code EM. XRechnung requires it (PEPPOL-EN16931-R020), and the buyer's BT-49 as well (PEPPOL-EN16931-R010).
• The address consists of street BT-35, city BT-37, post code BT-38 and country code BT-40. City and post code are mandatory under BR-DE-3 and BR-DE-4, the country code under BR-09. This covers no. 1 of § 14(4) UStG.
• cac:PartyTaxScheme/cbc:CompanyID with VAT is the seller VAT ID BT-31. The German tax number (Steuernummer) goes into BT-32 in a second PartyTaxScheme. One of the two must be present for VAT category S (BR-DE-16), matching no. 2.
• cbc:RegistrationName is the seller name BT-27 (BR-06). A different trading name goes into BT-28 in cac:PartyName.
• cac:Contact is the seller contact group BG-6 with contact point BT-41, phone BT-42 and e-mail BT-43. XRechnung requires all three (BR-DE-2, BR-DE-5 to BR-DE-7); EN 16931 alone does not. Foreign ERP systems often leave this group out.

The buyer block cac:AccountingCustomerParty has the same structure. Its name is BT-44 (BR-07); city and post code are BT-52 and BT-53 (BR-DE-8, BR-DE-9). A buyer contact group is not required.

Block 3: delivery date and payment

  <cac:Delivery><cbc:ActualDeliveryDate>2026-09-30</cbc:ActualDeliveryDate></cac:Delivery>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cbc:PaymentID>RE-2026-0042</cbc:PaymentID>
    <cac:PayeeFinancialAccount><cbc:ID>DE02120300000000202051</cbc:ID></cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:PaymentTerms><cbc:Note>Payable within 30 days without deduction.</cbc:Note></cac:PaymentTerms>

• cbc:ActualDeliveryDate is the actual delivery date BT-72 and satisfies no. 6 (time of supply). An invoicing period (BG-14) is the alternative. If both are missing, XRechnung reports BR-DE-TMP-32 at information level. It does not cause a rejection, but the VAT detail is still missing.
• cbc:PaymentMeansCode is the payment means code BT-81: 58 is a SEPA credit transfer, 30 a credit transfer in general. Payment instructions (BG-16) are mandatory in XRechnung (BR-DE-1). With code 30 or 58 the credit transfer group BG-17 must follow (BR-DE-23-a), and with 58, BT-84 should be a valid IBAN (BR-DE-19).
• cbc:PaymentID is the remittance information BT-83; the account cbc:ID is the IBAN BT-84.
• cac:PaymentTerms/cbc:Note holds the payment terms BT-20. An agreed early-payment discount (Skonto) goes here, in the fixed XRechnung syntax that BR-DE-18 checks.

Block 4: tax and totals

  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <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>

These are the amounts that no. 7 and no. 8 of § 14(4) UStG require. The EN 16931 calculation rules tie them together:

Amounts always use a dot as the decimal separator and no thousands separator. If a total is off by one cent, the matching BR-CO rule fails, for example BR-CO-10 for the line sum.

Block 5: the invoice lines

  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">850.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Description>Consulting on the e-invoicing switch, September 2026</cbc:Description>
      <cbc:Name>Consulting</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID><cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">85.00</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>

• cbc:ID is the line identifier BT-126 (BR-21).
• cbc:InvoicedQuantity is the quantity BT-129; its unitCode attribute is the unit BT-130. HUR means hour, C62 means one piece. Quantity and name together cover no. 5 ("quantity and type of supply").
• cbc:LineExtensionAmount is the line net amount BT-131: 10 × EUR 85.00 = EUR 850.00.
• cbc:Name is the mandatory item name BT-153 (BR-25); cbc:Description is the optional item description BT-154.
• cac:ClassifiedTaxCategory holds the line's VAT category BT-151 and rate BT-152.
• cbc:PriceAmount is the item net price BT-146 (BR-26).

The second line (a training fee, 1 × EUR 150.00 with unitCode="C62") has the same structure. Both lines add up to the EUR 1,000.00 in BT-106.

Which details does § 14 UStG require, and where are they?

The legal requirements do not change with e-invoicing. According to the BMF letter of 15 October 2025 (opens in a new tab) from the Federal Ministry of Finance, every mandatory detail must be in the structured part; a reference to a PDF attachment is not enough. For our example:

The full list, including special cases such as the reverse charge under § 13b UStG, is in German Invoice Requirements.

What does the same invoice look like as ZUGFeRD?

A ZUGFeRD invoice is a PDF/A-3 file with an embedded XML file, usually named factur-x.xml in ZUGFeRD 2.x. That XML does not use UBL but the Cross Industry Invoice (CII) syntax. The business terms stay the same; only the elements differ:

Two differences matter in practice. First, CII writes dates in format 102, meaning YYYYMMDD without hyphens. Second, BT-24 decides the rule set. A ZUGFeRD file in the EN 16931 profile carries urn:cen.eu:en16931:2017 and is checked against the EN 16931 rules only, without the German BR-DE rules. In the XRECHNUNG profile it carries the XRechnung identifier from block 1, and BT-10 and BG-6 become mandatory. If you are used to Factur-X from France, the CII structure is the same. Which profiles count as e-invoices is covered in ZUGFeRD Profiles and Versions, and both syntaxes with their namespaces are in XRechnung XML Structure.

Common mistakes when adapting a sample

Teams that start from a sample file usually trip over the same points:

How these errors fall into classes is explained in E-Invoice Format Error, Business Rule Error or Content Error?. KoSIT publishes official reference files for all test scenarios in its test suite, linked from xeinkauf.de (opens in a new tab).

How to read and check an e-invoice example with docutools.pro

1. View the file: open the XML in the XML viewer. It shows the tree and formats the file so you can find the blocks from this article. It runs in your browser, so the file does not leave your computer; it is free up to 500 KB. It does not run schema or business-rule checks.
2. Check the content: upload the file to the XRechnung validator, or click "Load sample invoice". The file is sent to our server for the check. "KoSIT validation" checks the way the KoSIT validator does (configuration 2026-08-31): XML schema, EN 16931 rules and, for XRechnung identifiers, the BR-DE rules.
3. Read the result: you see "KoSIT-conformant / Valid XRechnung" or "Not KoSIT-conformant" with the rule codes used in this article, plus the "Extracted data" table with number, date, parties, VAT IDs, totals and lines. The table does not show the Leitweg-ID, IBAN or addresses.
4. The ZUGFeRD counterpart: if you have the invoice as a PDF, use the ZUGFeRD extractor to extract the XML from the PDF via "Choose PDF" and "Download XML". Then upload that CII file to the viewer, which does not read PDFs.

The free plan includes two uploads per day of up to 500 KB each; unlimited checks come with the Pro plan. For more on who must issue and receive e-invoices, see our guides on the German e-invoicing mandate.

Sources

• § 14 UStG: issuing invoices (opens in a new tab), Gesetze im Internet (German)
• BMF letter of 15 October 2025 on mandatory e-invoicing (opens in a new tab), Federal Ministry of Finance (German)
• XRechnung: specification, versions and test suite (opens in a new tab), KoSIT / XStandards Einkauf
• XRechnung validator configuration releases (opens in a new tab), KoSIT on GitHub (rule texts for BR-DE, BR-CO and PEPPOL-EN16931)

Last reviewed: October 2026

This article is general information, not tax or legal advice.