Common XRechnung validation errors (BR-DE-*) and how to fix them

By evoicely · Last checked 20 October 2026

BR-DE-* errors come from Germany's XRechnung rules, which add required fields on top of EN 16931. Almost all of them mean a field is missing. The ones invoices generated from Stripe trip over most are BR-DE-15 (no buyer reference), BR-DE-2 and BR-DE-5 to 7 (no seller contact with name, phone and email), BR-DE-1 (no payment instructions), BR-DE-16 (no seller VAT ID or tax number) and BR-DE-8/9 (customer without a city or postcode). Each section below gives the official rule text, translated, why it fires, and the XML that satisfies it. To see which rules your own file breaks, upload it to our free validator.

Quick reference

Rule texts are quoted from the XRechnung 3.0.2 Schematron and the EN 16931 rules 1.3.16, as bundled in KoSIT's validator configuration of 31 August 2026 (XRechnung Schematron, EN 16931 validation artefacts). The BR-DE texts are German in the original; the translations are ours. The XML fragments are UBL, cut from one complete fictional invoice that passes these rules.

BR-DE-15: buyer reference missing

Das Element "Buyer reference" (BT-10) muss übermittelt werden. The buyer reference (BT-10) must be present.

XRechnung requires BT-10 on every invoice, not only for public authorities. For a public body it's the Leitweg-ID; for a business customer, whatever reference you agreed on, such as a PO or customer number. Stripe has no buyer reference field, so a converter has to take it from metadata. An empty element doesn't count, and also triggers PEPPOL-EN16931-R008.

<cbc:BuyerReference>PO-4711</cbc:BuyerReference>

In CII it's ram:BuyerReference inside ram:ApplicableHeaderTradeAgreement.

BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7: seller contact

• BR-DE-2: Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden. The seller contact group must be present.
• BR-DE-5: the seller contact point (BT-41) must be present.
• BR-DE-6: the seller contact telephone number (BT-42) must be present.
• BR-DE-7: the seller contact email address (BT-43) must be present.

EN 16931 makes the seller contact optional; XRechnung makes all three fields mandatory. A Stripe invoice carries your business name, but no structured contact person, phone and email for the seller, so they have to come from your own settings. The contact point can be a department; it doesn't have to be a person's name.

<cac:AccountingSupplierParty>
  <cac:Party>
    ...
    <cac:Contact>
      <cbc:Name>Buchhaltung</cbc:Name>
      <cbc:Telephone>+49 30 1234567</cbc:Telephone>
      <cbc:ElectronicMail>billing@beispiel-software.example</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:AccountingSupplierParty>

In UBL, cac:Contact comes after cac:PartyLegalEntity inside cac:Party; the XML schema rejects it in the wrong order.

BR-DE-1: payment instructions missing

Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten. An invoice must contain payment instructions (BG-16).

In UBL that's a cac:PaymentMeans element with a payment means type code (BT-81, from the UNTDID 4461 code list). It's required even when the invoice is already paid, which is the normal case for a Stripe subscription charged to a card. For an invoice the customer still has to pay by bank transfer, use code 58 (SEPA credit transfer) with your IBAN:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

For an invoice that's already paid, see the next section for card codes, or use code 1 (instrument not defined), which needs no further details, and show the payment in the prepaid amount (BT-113, cbc:PrepaidAmount) so the amount due is 0.

BR-DE-23-a and BR-DE-24-a: code and details don't match

• BR-DE-23-a: if BT-81 is a credit transfer code (30, 58), CREDIT TRANSFER (BG-17) must be present. Without an IBAN, EN 16931's BR-61 fires as well.
• BR-DE-24-a: if BT-81 is a card payment code (48, 54, 55), exactly one PAYMENT CARD INFORMATION group (BG-18) must be present.

The -b variants of both rules forbid mixing: with a transfer code, no card or direct debit details; with a card code, no bank account or direct debit. A card payment looks like this:

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
  <cac:CardAccount>
    <cbc:PrimaryAccountNumberID>4242</cbc:PrimaryAccountNumberID>
    <cbc:NetworkID>VISA</cbc:NetworkID>
  </cac:CardAccount>
</cac:PaymentMeans>

Never put the full card number in an invoice. EN 16931's BR-51 says that, under the card payment security standards, at most the first 6 and last 4 digits may be shown; the last four are enough.

BR-DE-16, BR-S-02 and BR-CO-26: seller VAT ID or tax number

BR-DE-16: if the invoice uses VAT category codes S, Z, E, AE, K, G, L or M, at least one of the seller VAT identifier (BT-31), the seller tax registration identifier (BT-32) or a seller tax representative (BG-11) must be present. If the seller's VAT ID is simply missing, you'll usually see three errors at once: BR-DE-16, EN 16931's BR-S-02 (the same requirement for standard-rated lines) and BR-CO-26 (the seller must be identifiable by a seller identifier, legal registration identifier or VAT identifier).

On a Stripe invoice your VAT ID is in account_tax_ids, if you've added it in Stripe. With a VAT ID:

<cac:PartyTaxScheme>
  <cbc:CompanyID>DE123456789</cbc:CompanyID>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:PartyTaxScheme>

If you only have a German tax number (Steuernummer), it goes in BT-32: a cac:PartyTaxScheme with tax scheme FC instead of VAT. That satisfies BR-DE-16 and BR-S-02 but not BR-CO-26, because BT-32 isn't one of the identifiers BR-CO-26 accepts. Add a seller legal registration identifier (BT-30, for example your commercial register number, in cac:PartyLegalEntity/cbc:CompanyID) or a seller identifier (BT-29).

A VAT ID must start with its country code, DE123456789 rather than 123456789; otherwise BR-CO-09 fires.

BR-DE-8 and BR-DE-9: buyer city and postcode

BR-DE-8: the buyer city (BT-52) must be present. BR-DE-9: the buyer post code (BT-53) must be present. The seller's equivalents are BR-DE-3 and BR-DE-4. If the buyer has no address at all, EN 16931's BR-10 fires instead, and without a country code BR-11.

Stripe doesn't require an address on a customer: the invoice's customer_address can be null (Invoice object). Collect the billing address at checkout or add it to the Customer before the invoice is finalized; after that, Stripe no longer updates the invoice's copy.

<cac:PostalAddress>
  <cbc:StreetName>Hauptstraße 5</cbc:StreetName>
  <cbc:CityName>München</cbc:CityName>
  <cbc:PostalZone>80331</cbc:PostalZone>
  <cac:Country>
    <cbc:IdentificationCode>DE</cbc:IdentificationCode>
  </cac:Country>
</cac:PostalAddress>

PEPPOL-EN16931-R020 and R010: electronic addresses

Seller electronic address MUST be provided (R020) and Buyer electronic address MUST be provided (R010). These carry Peppol IDs but are part of the XRechnung 3.0 rules. The electronic address (BT-34 for the seller, BT-49 for the buyer) is where the invoice can be delivered. Outside Peppol, an email address with scheme EM works:

<cbc:EndpointID schemeID="EM">billing@beispiel-software.example</cbc:EndpointID>

It comes before the postal address in cac:Party. Without the schemeID attribute you get BR-62 (seller) or BR-63 (buyer); with a scheme that isn't on the EAS code list, BR-CL-25. For the buyer, the customer's email on the Stripe invoice (customer_email) is the natural choice, unless the buyer gave you a Peppol ID or a dedicated invoice address.

PEPPOL-EN16931-R008: empty elements

Document MUST not contain empty elements. A generator that writes every field, even when the Stripe value is null, produces things like <cbc:Note></cbc:Note>. The fix is in the generator: leave an element out when there's no value. The error's location tells you which element was empty.

BR-CO-14, BR-CO-15, BR-CO-16: totals don't add up

• BR-CO-14: Invoice total VAT amount (BT-110) = Σ VAT category tax amount (BT-117).
• BR-CO-15: Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
• BR-CO-16: Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) - Paid amount (BT-113) + Rounding amount (BT-114).

These checks are exact to the cent. They usually fire when the totals are copied from one place (Stripe's total) and the VAT breakdown is recalculated somewhere else. Stripe rounds tax per line, so its VAT per rate can differ by a cent from taxable amount × rate. The per-category check (BR-CO-17, BR-S-09) tolerates that: in the current rules, the difference has to be less than one currency unit. So use Stripe's own tax amounts per rate, and derive BT-110, BT-112 and BT-115 from them, rather than mixing Stripe's totals with your own VAT calculation. Amounts may have at most two decimals: 29.970 fails BR-DEC-23.

BR-AE-10 and BR-AE-02: reverse charge

When you sell to a business in another EU country under the reverse charge, the VAT category is AE with rate 0. Two rules catch most mistakes:

• BR-AE-10: the VAT breakdown for reverse charge must have an exemption reason code (BT-121) meaning reverse charge or the reason text (BT-120) "Reverse charge".
• BR-AE-02: an invoice with reverse-charge lines must contain the seller's VAT ID (or tax registration or tax representative's VAT ID) and the buyer's VAT ID (BT-48) or legal registration identifier (BT-47).

In Stripe that's a customer with tax_exempt set to reverse and a VAT ID in customer_tax_ids. The breakdown then looks like this:

<cac:TaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cbc:TaxExemptionReasonCode>VATEX-EU-AE</cbc:TaxExemptionReasonCode>
  <cbc:TaxExemptionReason>Reverse charge</cbc:TaxExemptionReason>
  <cac:TaxScheme>
    <cbc:ID>VAT</cbc:ID>
  </cac:TaxScheme>
</cac:TaxCategory>

Whether reverse charge applies to a sale is a tax question, not a validation one; the rules only check that the invoice is consistent once you've decided.

BR-DE-21 and "no scenario matched": the specification identifier

BR-DE-21 (a warning): the specification identifier (BT-24) should match the identifier of the XRechnung standard. For XRechnung 3.0 that's:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>

In practice you rarely see BR-DE-21 itself. The KoSIT validator only runs the XRechnung rules when BT-24 matches one of the identifiers it knows, so a file with a wrong or outdated identifier, such as xrechnung_2.3, is rejected with "no scenario matched" and no rule messages at all. If you get a rejection without errors, look at BT-24 first. The KoSIT validator guide explains how scenarios work.

Warnings and notes that don't make a file invalid

• BR-DE-19 (warning): with code 58, the payment account (BT-84) should be a correct IBAN. It fires on a wrong check digit, which usually means a typo that would send the money nowhere. Fix it even though it's only a warning.
• BR-DE-27 (warning): the seller phone number (BT-42) should contain at least three digits. Placeholders like "-" trip it.
• BR-DE-28 (warning): the seller email (BT-43) should contain exactly one @, with at least two characters on each side.
• BR-DE-TMP-32 (information): the invoice should state the date of supply, through an actual delivery date (BT-72), an invoicing period (BG-14) or a period on every line (BG-26). Stripe subscription lines have a service period you can use.
• BR-DE-17 (warning): the invoice type code (BT-3) should be one of 326, 380, 384, 389, 381, 875, 876 or 877. A normal invoice is 380, a credit note 381.

Checking your fix

Fix one group of errors at a time and check again: a missing parent element can hide errors in its children. Our validator lists each finding with its location in the document, and shows the invoice in readable form, so you can see the field you just added.

Related guides

• How to validate an XRechnung: the KoSIT validator, its scenarios and its report.
• Mapping a Stripe invoice to EN 16931: where each of these fields comes from in Stripe.
• What is a Leitweg-ID: the buyer reference for public-sector customers.
• How to open and read an XRechnung XML file.

Where evoicely fits

Check your XRechnung for these errors, free and without signing up. evoicely fills these fields when it turns your Stripe invoices into XRechnung and ZUGFeRD: seller contact, VAT ID and IBAN from settings you set once, the buyer reference from metadata, and each file checked against these rules before it goes out. Get started: it's free for 10 e-invoices a month.

This is general information, not legal or tax advice. Passing the validation rules doesn't settle questions such as which VAT treatment applies; check what applies to your business with your tax advisor.