How to Create an XRechnung: Step-by-Step Guide

To create an XRechnung, collect the required data, choose a syntax (UBL or CII), generate the XML file with software, a generator, the OZG-RE web form or by hand, validate it against the KoSIT rules, send it and archive it unaltered for eight years. For invoices to German authorities, the Leitweg-ID goes into field BT-10.

Last reviewed: September 2026. This article is general information, not tax advice.

If you just need the file, you can create an e-invoice without writing XML: our generator builds it from a form. This guide explains what happens behind the scenes, which fields are required and how to build an XRechnung manually. For background on the format and when it is mandatory, read What is XRechnung?.

What do you need before you start?

Settle four points before your first invoice:

1. Recipient: a public authority or a company? This decides the buyer reference and the delivery channel.
2. Buyer reference: for authorities, the Leitweg-ID (routing ID) from the order or contract; for companies, the reference your customer asks for.
3. Invoice address: the email address or platform where the customer receives e-invoices. You also need it as the buyer's electronic address (BT-49).
4. Version: make sure your software produces XRechnung 3.0. The current release is 3.0.2.

Step 1: Collect the required fields

Most errors come from missing data. The table lists what an XRechnung 3.0 needs for a simple invoice in euros:

Three details are easy to miss. First, § 14(4) UStG (German VAT Act) requires the full address of both parties, so enter the buyer's street too, even though the validation rules only enforce city and postcode. Second, units come from UN/ECE Recommendation 20, for example HUR for hour, DAY for day and C62 for one piece. Third, small businesses under the German small-business rule (Kleinunternehmer, § 19 UStG) that choose to issue an XRechnung use VAT category E at 0 %, give § 19 UStG as the exemption reason in BT-120 and state their tax number in BT-32.

To check the VAT content of any invoice regardless of format, use our German invoice requirements checker.

Step 2: Choose the syntax (UBL or CII)

XRechnung exists in two syntaxes. UBL 2.1 uses the root element Invoice (or CreditNote for credit notes) with the prefixes cbc and cac. CII uses rsm:CrossIndustryInvoice with the prefixes rsm, ram, udt and qdt. Both carry the same content, are legally equivalent, and public authorities must accept both.

In practice your software decides. UBL is common for XRechnung and easier to read; CII is the basis of ZUGFeRD. If you can produce both, use the one your recipient prefers. The comparison UBL vs. CII covers the differences.

Step 3: Generate the XRechnung

There are four ways to get the file:

With the generator

Our generator works in three steps:

1. Company data: invoice number, date, due date and currency, then your details with VAT ID, address, contact person, phone, email and IBAN. For the customer, enter the address and put the buyer reference in the field "Leitweg-ID / reference". If you leave it empty, the generator uses the invoice number; that is wrong for authorities, which need their Leitweg-ID there.
2. Line items: description, quantity, unit price and VAT rate per line.
3. Export: "XRechnung XML" produces a UBL file under XRechnung 3.0. ZUGFeRD is also available as XML or as a PDF/A-3.

To generate the file, the form data is sent briefly to our API; the invoice data is not stored. The generator always sets invoice type 380. Credit notes, corrected invoices (381, 384) or construction progress invoices need other software or direct XML editing.

With the OZG-RE web form

For invoices to federal authorities, the federal government offers an entry form on the OZG-RE platform. You register, type in the invoice and get a validation report with formal errors before you submit. This route does not help for states, municipalities or business customers.

By hand: a validated UBL skeleton

The example below is a complete, minimal XRechnung 3.0 in UBL: ten hours of consulting at €95 for a public authority. It passes the official KoSIT validator (configuration 3.0.2) with no errors and no warnings. The comments give the BT numbers; names, IBAN and Leitweg-ID are fictitious, but the Leitweg-ID's check digits are correct.

<?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> <!-- BT-24 -->
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID> <!-- BT-23 -->
  <cbc:ID>RE-2026-0142</cbc:ID>                            <!-- BT-1 -->
  <cbc:IssueDate>2026-09-28</cbc:IssueDate>                <!-- BT-2 -->
  <cbc:DueDate>2026-10-12</cbc:DueDate>                    <!-- BT-9 -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>           <!-- BT-3 -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <!-- BT-5 -->
  <cbc:BuyerReference>991-12345-73</cbc:BuyerReference>    <!-- BT-10 -->

  <cac:AccountingSupplierParty>                            <!-- BG-4 seller -->
    <cac:Party>
      <cbc:EndpointID schemeID="EM">invoice@example-gmbh.de</cbc:EndpointID> <!-- BT-34 -->
      <cac:PostalAddress>
        <cbc:StreetName>Musterstrasse 1</cbc:StreetName>   <!-- BT-35 -->
        <cbc:CityName>Bremen</cbc:CityName>                <!-- BT-37 -->
        <cbc:PostalZone>28195</cbc:PostalZone>             <!-- BT-38 -->
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode> <!-- BT-40 -->
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE123456789</cbc:CompanyID>         <!-- BT-31 -->
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Example GmbH</cbc:RegistrationName> <!-- BT-27 -->
      </cac:PartyLegalEntity>
      <cac:Contact>                                        <!-- BG-6 -->
        <cbc:Name>Anna Muster</cbc:Name>                   <!-- BT-41 -->
        <cbc:Telephone>+49 421 1234567</cbc:Telephone>     <!-- BT-42 -->
        <cbc:ElectronicMail>anna.muster@example-gmbh.de</cbc:ElectronicMail> <!-- BT-43 -->
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingCustomerParty>                            <!-- BG-7 buyer -->
    <cac:Party>
      <cbc:EndpointID schemeID="EM">invoices@example-agency.de</cbc:EndpointID> <!-- BT-49 -->
      <cac:PostalAddress>
        <cbc:CityName>Berlin</cbc:CityName>                <!-- BT-52 -->
        <cbc:PostalZone>10115</cbc:PostalZone>             <!-- BT-53 -->
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode> <!-- BT-55 -->
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Example Agency</cbc:RegistrationName> <!-- BT-44 -->
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:Delivery>
    <cbc:ActualDeliveryDate>2026-09-25</cbc:ActualDeliveryDate> <!-- BT-72 -->
  </cac:Delivery>

  <cac:PaymentMeans>                                       <!-- BG-16 -->
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>        <!-- BT-81 -->
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>              <!-- BT-84 -->
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:PaymentTerms>
    <cbc:Note>Payable within 14 days without deduction.</cbc:Note> <!-- BT-20 -->
  </cac:PaymentTerms>

  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">180.50</cbc:TaxAmount> <!-- BT-110 -->
    <cac:TaxSubtotal>                                      <!-- BG-23 -->
      <cbc:TaxableAmount currencyID="EUR">950.00</cbc:TaxableAmount> <!-- BT-116 -->
      <cbc:TaxAmount currencyID="EUR">180.50</cbc:TaxAmount> <!-- BT-117 -->
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>                                 <!-- BT-118 -->
        <cbc:Percent>19</cbc:Percent>                      <!-- BT-119 -->
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <cac:LegalMonetaryTotal>                                 <!-- BG-22 -->
    <cbc:LineExtensionAmount currencyID="EUR">950.00</cbc:LineExtensionAmount> <!-- BT-106 -->
    <cbc:TaxExclusiveAmount currencyID="EUR">950.00</cbc:TaxExclusiveAmount>   <!-- BT-109 -->
    <cbc:TaxInclusiveAmount currencyID="EUR">1130.50</cbc:TaxInclusiveAmount>  <!-- BT-112 -->
    <cbc:PayableAmount currencyID="EUR">1130.50</cbc:PayableAmount>            <!-- BT-115 -->
  </cac:LegalMonetaryTotal>

  <cac:InvoiceLine>                                        <!-- BG-25 -->
    <cbc:ID>1</cbc:ID>                                     <!-- BT-126 -->
    <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity> <!-- BT-129, BT-130 -->
    <cbc:LineExtensionAmount currencyID="EUR">950.00</cbc:LineExtensionAmount> <!-- BT-131 -->
    <cac:Item>
      <cbc:Name>Data migration consulting</cbc:Name>       <!-- BT-153 -->
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>                                 <!-- BT-151 -->
        <cbc:Percent>19</cbc:Percent>                      <!-- BT-152 -->
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">95.00</cbc:PriceAmount> <!-- BT-146 -->
    </cac:Price>
  </cac:InvoiceLine>
</ubl:Invoice>

If you rebuild it: the element order is fixed by the UBL schema and must not change. Dates use YYYY-MM-DD in UBL, amounts use a full stop as decimal separator and at most two decimal places. The arithmetic: 10 × 95.00 = €950.00 net (BT-131, BT-106, BT-109), 19 % VAT on that is €180.50 (BT-117, BT-110), giving €1,130.50 in total (BT-112, BT-115). If one of these totals is off, the rules BR-CO-10, BR-CO-15 or BR-CO-16 fire. Another complete xrechnung example is in our templates, and the CII paths are mapped in the guide to the XRechnung XML structure.

Step 4: Validate the XRechnung

Validate every file before sending, even when it comes from a proven template. A full check covers the XML schema of the syntax, the EN 16931 rules and the XRechnung rules (BR-DE). Load the file into our xrechnung viewer: it applies the official KoSIT rules, renders the invoice in readable form and explains each message. For automated pipelines there is the open-source KoSIT validator (opens in a new tab). Individual codes are explained under xrechnung validation errors, and our guide on how to fix XRechnung validation errors covers the usual causes.

The BMF letter of 15 October 2025 (opens in a new tab) from the Federal Ministry of Finance distinguishes three types of error. A format error means the file is not an e-invoice at all. A business-rule error without a VAT link, such as a missing BT-10, is irrelevant for VAT but still gets the invoice rejected by public-sector platforms. A content error, such as a wrong tax rate, puts the customer's input VAT deduction at risk even if the file is technically valid. According to the BMF, businesses may rely on the result of a suitable validation tool, so keep the validation report with the invoice.

Step 5: Send the XRechnung

The channel depends on the recipient:

• Federal authorities: only through the OZG-RE, which absorbed the former ZRE platform on 19 September 2025. Channels are web form, upload, email and Peppol. Register first and activate the channels you want to use.
• States and municipalities: through the portal your contracting authority names. Rules differ from state to state.
• Companies: usually as an email attachment to the customer's invoice address; larger customers may use Peppol or a supplier portal. An ordinary email inbox is enough to receive e-invoices.

Embed attachments such as timesheets in the file as Base64 instead of sending them separately. According to the federal FAQ (opens in a new tab), the federal platform accepts up to 200 embedded documents in PDF, PNG, JPG, CSV, XLSX and ODS format. Our guide to XRechnung attachments has the details.

Step 6: Archive the XRechnung

Invoices must be kept for eight years (§ 14b UStG, § 147 AO), counted from the end of the calendar year. Archive the XML file unaltered in its original form; a PDF view does not replace it. The OZG-RE is not an archive either: invoices are deleted there 28 days after they were made available or after their last status change. Our guide to e-invoice archiving explains what a GoBD-compliant archive looks like.

B2B vs. B2G: what is different?

You get the Leitweg-ID from the contracting authority. Our guide on how to get a Leitweg-ID explains where to find it. Before entering it, run it through our leitweg id validator, which checks the format and check digits. For B2B, the comparison XRechnung vs. ZUGFeRD helps you pick a format.

Common mistakes when creating an XRechnung

• BT-10 missing: every XRechnung needs a buyer reference, B2B included.
• Outdated identifier in BT-24: older programs still write the identifier of a 2.x version.
• Fields required since 3.0 missing: BT-23, BT-34 and BT-49 have been mandatory since version 3.0; the seller contact BG-6 even longer.
• Rounding differences: totals built from rounded line amounts no longer match the grand total.
• Wrong invoice type: the intended codes are 326, 380, 381, 384, 389 and the construction codes 875 to 877 (BR-DE-17); other codes trigger a warning. A corrected invoice (384) should cite the original invoice in BT-25.
• Edits after validation: if you change the XML by hand after the check, validate again.

More articles on the Leitweg-ID, formats and validation are collected in the XRechnung category.