Die deutschen Regeln der XRechnung — was über die EN 16931 hinaus gilt

Pflicht, was die Norm nur erlaubt

Die meisten BR-DE-Regeln prüfen keine neue Angabe, sondern eine, die die EN 16931 als optional führt: Ort und Postleitzahl von Verkäufer und Käufer (BR-DE-3, BR-DE-4, BR-DE-8, BR-DE-9), eine Kontaktstelle mit Telefonnummer und E-Mail-Adresse (BR-DE-2, BR-DE-5 bis BR-DE-7) und die Zahlungsangaben (BR-DE-1). Eine Rechnung, die europaweit gültig wäre, scheitert in Deutschland deshalb oft an Feldern, die im Mapping nie jemand befüllt hat.

Die bekannteste Regel der Familie ist BR-DE-15: Die Käuferreferenz (BT-10) muss angegeben sein. Bei Rechnungen an die öffentliche Verwaltung steht dort die Leitweg-ID, über die der Empfänger die Rechnung zuordnet — fehlt sie, ist die Rechnung nicht valide.

Zahlungsangaben müssen zur Zahlungsart passen

BR-DE-23, BR-DE-24 und BR-DE-25 prüfen die Zahlungsangaben gegen die gewählte Zahlungsart: Eine Überweisung braucht eine Bankverbindung (BG-17), eine Kartenzahlung Kartendaten (BG-18), eine Lastschrift Mandatsdaten (BG-19). Die Varianten mit -a melden, was fehlt, die Varianten mit -b, was zu einer anderen Zahlungsart gehört und trotzdem gefüllt ist.

Dazu kommen die Formatprüfungen: die IBAN bei Überweisung und Lastschrift (BR-DE-19, BR-DE-20), bei Lastschrift außerdem Gläubiger-ID und belastetes Konto (BR-DE-30, BR-DE-31), und das Skonto in den Zahlungsbedingungen (BR-DE-18), für das die XRechnung eine eigene Textsyntax festlegt.

BR-TMP: was mit der Fassung vom 2. September hinzukam

Mit dem Regelwerk v2026-08-31, veröffentlicht am 2. September 2026, kamen vier BR-TMP-Regeln hinzu: BR-TMP-6 und BR-TMP-7 prüfen das Format von Datumsangaben — in UBL JJJJ-MM-TT, in CII achtstellig mit format="102" —, und nach BR-TMP-4 und BR-TMP-5 darf eine Anlage (BG-24) in CII nur noch eine Bezeichnung und eine eingebettete Datei tragen. Alle vier melden eine Warnung, keinen Fehler.

BR-TMP-2 wurde mit derselben Fassung verschärft: Eine externe Dokumentadresse in BT-124 ohne vollständige URL ist seitdem ein Fehler statt einer Warnung. Wer dort einen internen Pfad verschickt, bekommt die Rechnung abgewiesen.

Alle deutschen Regeln

Mit dem offiziellen Regeltext und zu jeder Regel Ursache und Behebung.

• BR-DE-1

  Zahlungsangaben (BG-16) fehlen

  Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten.

  Was die Regel verlangt

  Jede XRechnung muss Angaben zur Zahlung enthalten (Gruppe BG-16, "PAYMENT INSTRUCTIONS") — mindestens, auf welchem Weg gezahlt wird.

  Warum sie ausgelöst wird

  Viele Systeme drucken die Bankverbindung nur in den Fußtext der PDF-Rechnung. Im strukturierten Datensatz fehlt sie dann vollständig, obwohl sie für den Menschen sichtbar ist. Der Ausdruck prüft dabei nur, ob die Gruppe überhaupt vorhanden ist: ein leeres cac:PaymentMeans erfüllt BR-DE-1 bereits. Was darin stehen muss, verlangen andere Regeln — die Zahlungsart BT-81 fordert BR-49, nicht BR-DE-1.

  Wie Sie es beheben

  Füllen Sie die Gruppe BG-16 strukturiert: Zahlungsart (BT-81) und je nach Zahlungsweg die Kontoangaben, etwa IBAN in BT-84. Freitext im Rechnungsfuß genügt nicht. Welche Kontogruppe dazugehört, entscheidet der Schlüssel in BT-81: bei Überweisung (30, 58) verlangt BR-DE-23-a die Gruppe BG-17, bei Kartenzahlung (48, 54, 55) BR-DE-24-a die Gruppe BG-18, bei Lastschrift (59) BR-DE-25-a die Gruppe BG-19 — und jeweils nur diese eine.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentTerms>
    <cbc:Note>Zahlbar innerhalb von 14 Tagen auf DE02120300000000202051</cbc:Note>
  </cac:PaymentTerms>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:PaymentTerms>
    <cbc:Note>Zahlbar innerhalb von 14 Tagen</cbc:Note>
  </cac:PaymentTerms>

  Was der Validator prüft

  UBLcac:PaymentMeans

  CIIrsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans

• BR-DE-2

  Ansprechpartner (BG-6) fehlt

  Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden.

  Was die Regel verlangt

  Jede XRechnung muss die Gruppe „SELLER CONTACT“ (BG-6) enthalten — einen Ansprechpartner des Verkäufers mit Kontaktdaten. Die EN 16931 stellt diese Gruppe frei; verpflichtend wird sie erst durch die deutsche CIUS, auch im B2B-Fall.

  Warum sie ausgelöst wird

  Rechnungsvorlagen führen Kontaktdaten meist nur im Briefkopf. Beim Mapping in das strukturierte Format wird die Kontaktgruppe dann komplett ausgelassen, weil es im internen Datenmodell kein Pflichtfeld dafür gibt. Der Ausdruck prüft nur, ob die Gruppe da ist: ein leeres cac:Contact erfüllt BR-DE-2 bereits — und löst sofort BR-DE-5, BR-DE-6 und BR-DE-7 aus, denn für Ansprechpartner, Telefon und E-Mail gibt es je eine eigene Regel.

  Wie Sie es beheben

  Übermitteln Sie BG-6 mit Ansprechpartner (BT-41), Telefon (BT-42) und E-Mail (BT-43). In UBL ist das cac:AccountingSupplierParty/cac:Party/cac:Contact, in CII ram:SellerTradeParty/ram:DefinedTradeContact. Alle drei Felder müssen einen Wert tragen: die Ausdrücke prüfen mit normalize-space, ein leeres Element oder ein Leerzeichen genügt nicht.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcac:Party/cac:Contact

  CIIram:DefinedTradeContact

• BR-DE-3

  Ort des Verkäufers (BT-37) fehlt

  Das Element "Seller city" (BT-37) muss übermittelt werden.

  Was die Regel verlangt

  In der Anschrift des Verkäufers (BG-5) muss der Ort stehen: BT-37, in XRechnung Pflicht, in der EN 16931 dagegen nicht. Gemeint ist ausschließlich die Anschrift des Verkäufers — für den Käufer gilt BR-DE-8, für eine abweichende Lieferanschrift BR-DE-10.

  Warum sie ausgelöst wird

  Die Anschrift liegt intern oft als eine zusammenhängende Adresszeile vor. Ohne saubere Trennung in Straße, PLZ und Ort bleibt das Stadtfeld im strukturierten Datensatz leer. Ein leeres Element hilft dann nicht weiter: der Ausdruck prüft mit normalize-space, ein <cbc:CityName/> ohne Inhalt oder mit einem Leerzeichen zählt als nicht übermittelt.

  Wie Sie es beheben

  Übermitteln Sie den Ort in BT-37: in UBL cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CityName, in CII ram:SellerTradeParty/ram:PostalTradeAddress/ram:CityName. Adressen im Stammdatensatz einmal sauber in Einzelfelder zerlegen. Die PLZ daneben verlangt BR-DE-4, und beides zusammen fällt meist gemeinsam auf.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcbc:CityName[boolean(normalize-space(.))]

  CIIram:CityName[boolean(normalize-space(.))]

• BR-DE-4

  PLZ des Verkäufers (BT-38) fehlt

  Das Element "Seller post code" (BT-38) muss übermittelt werden.

  Was die Regel verlangt

  In der Anschrift des Verkäufers muss die Postleitzahl stehen (BT-38) — geprüft wird nur, dass etwas drinsteht, nicht ob es eine PLZ ist. Die EN 16931 verlangt BT-38 gar nicht; erst die deutsche CIUS macht das Feld zur Pflicht, für den Käufer entsprechend BR-DE-9.

  Warum sie ausgelöst wird

  Wie beim Ort steckt die PLZ meist in einer kombinierten Adresszeile und wird beim Export nicht als eigenes Feld befüllt. Ein Platzhalter kommt dabei technisch durch: die Existenzprüfung ist der einzige Ausdruck im ganzen Regelwerk, der BT-38 überhaupt anfasst — Länge, Ziffern oder Land prüft weder XRechnung noch die EN 16931. „00000“ besteht die Validierung und fällt erst beim Empfänger auf.

  Wie Sie es beheben

  Übermitteln Sie die PLZ in BT-38: in UBL cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:PostalZone, in CII ram:SellerTradeParty/ram:PostalTradeAddress/ram:PostcodeCode. In CII heißt das Element PostcodeCode, nicht PostalCode — beim Mapping von Hand geht das regelmäßig daneben. Der Ort daneben ist BR-DE-3.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:StreetName>Musterstraße 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcbc:PostalZone[boolean(normalize-space(.))]

  CIIram:PostcodeCode[boolean(normalize-space(.))]

• BR-DE-5

  Kontaktstelle (BT-41) fehlt

  Das Element "Seller contact point" (BT-41) muss übermittelt werden.

  Was die Regel verlangt

  Die Kontaktstelle des Verkäufers (BT-41) muss besetzt sein: ein Name oder eine Abteilung, an die sich der Käufer wenden kann. Die EN 16931 führt BT-41 als optionales Feld und prüft es nirgends — verpflichtend wird es erst durch die deutsche CIUS.

  Warum sie ausgelöst wird

  Das Feld existiert in vielen Rechnungssystemen schlicht nicht; erfasst sind nur Firmenname und Adresse. Beim Export bleibt BT-41 dann leer, obwohl BG-6 übermittelt wird. Ein leeres Element hilft nicht: der Ausdruck prüft mit normalize-space. In CII genügt dafür eines von zwei Elementen — ein Dokument, das nur ram:DepartmentName trägt, besteht BR-DE-5; nach UBL konvertiert muss derselbe Text in das eine cbc:Name.

  Wie Sie es beheben

  Übermitteln Sie eine Person oder Abteilung, etwa „Buchhaltung“ oder „Max Mustermann“: in UBL cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Name, in CII ram:SellerTradeParty/ram:DefinedTradeContact/ram:PersonName oder ram:DepartmentName. Telefon und E-Mail derselben Gruppe verlangen BR-DE-6 und BR-DE-7, die getrennt melden.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcbc:Name[boolean(normalize-space(.))]

  CII(ram:PersonName,ram:DepartmentName)[boolean(normalize-space(.))]

• BR-DE-6

  Telefonnummer (BT-42) fehlt

  Das Element "Seller contact telephone number" (BT-42) muss übermittelt werden.

  Was die Regel verlangt

  Der Ansprechpartner des Verkäufers braucht eine Telefonnummer (BT-42) — als Fehler, der die Rechnung zurückweist. Ob dort überhaupt eine Nummer steht, prüft erst BR-DE-27, und das nur als Warnung.

  Warum sie ausgelöst wird

  Die Telefonnummer steht im Briefkopf der PDF, ist aber im Datenmodell keinem Kontakt zugeordnet — beim Erzeugen des strukturierten Datensatzes fehlt sie dann. BR-DE-6 selbst verlangt nur einen nicht-leeren Wert: „auf Anfrage“ erfüllt die Regel. Erst BR-DE-27 sieht nach, ob mindestens drei Ziffern vorkommen, und meldet als Warnung statt als Fehler.

  Wie Sie es beheben

  Übermitteln Sie die Nummer in BT-42: in UBL cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:Telephone, in CII ram:SellerTradeParty/ram:DefinedTradeContact/ram:TelephoneUniversalCommunication/ram:CompleteNumber. In CII gibt es daneben DirectTelephoneUniversalCommunication und MobileTelephoneUniversalCommunication — beide zählen für BR-DE-6 nicht, und die EN 16931 warnt zusätzlich über CII-SR-234, wenn sie überhaupt vorkommen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcbc:Telephone[boolean(normalize-space(.))]

  CIIram:TelephoneUniversalCommunication/ram:CompleteNumber[boolean(normalize-space(.))]

• BR-DE-7

  E-Mail-Adresse (BT-43) fehlt

  Das Element "Seller contact email address" (BT-43) muss übermittelt werden.

  Was die Regel verlangt

  Der Ansprechpartner des Verkäufers braucht eine E-Mail-Adresse (BT-43) — ein Fehler, der die Rechnung zurückweist. Ob die Adresse überhaupt wie eine Adresse aussieht, prüft BR-DE-28, und das nur als Warnung.

  Warum sie ausgelöst wird

  Wie bei Telefonnummer und Ansprechpartner steht die Adresse im Briefkopf, aber nicht als strukturiertes Kontaktfeld im Datenmodell. BR-DE-7 nimmt dabei jeden nicht-leeren Text an — „siehe Website“ erfüllt die Regel. Die Form prüft erst BR-DE-28, und schwächer als der eigene Regeltext verspricht: verlangt werden dort zwei Zeichen links und rechts vom @ und kein Punkt daneben, der kompilierte Ausdruck lässt aber ein einzelnes Zeichen und einen Punkt direkt vor dem @ durch.

  Wie Sie es beheben

  Übermitteln Sie die Adresse in BT-43: in UBL cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail, in CII ram:SellerTradeParty/ram:DefinedTradeContact/ram:EmailURIUniversalCommunication/ram:URIID. In CII gehört sie in ram:URIID — steht sie stattdessen in ram:CompleteNumber, wie es die Telefongruppe nahelegt, zählt sie für BR-DE-7 nicht, und die EN 16931 warnt über CII-SR-238.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:Contact>
        <cbc:Name>Buchhaltung</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLcbc:ElectronicMail[boolean(normalize-space(.))]

  CIIram:EmailURIUniversalCommunication/ram:URIID[boolean(normalize-space(.))]

• BR-DE-8

  Ort des Käufers (BT-52) fehlt

  Das Element "Buyer city" (BT-52) muss übermittelt werden.

  Was die Regel verlangt

  Die Anschrift des Käufers muss den Ort tragen (BT-52) — die EN 16931 verlangt nur das Land, der Ort kommt aus der deutschen CIUS. Gemeint ist die Rechnungsanschrift des Käufers, nicht die des Verkäufers (BR-DE-3) und nicht eine abweichende Lieferanschrift (BR-DE-10).

  Warum sie ausgelöst wird

  Meist liegt die Anschrift im Quellsystem nur als eine zusammengezogene Zeile vor („Musterstraße 1, 10115 Berlin“) und wird beim Mapping nicht in Einzelfelder zerlegt — der Ort landet dann nirgends. Ein leeres Element zählt dabei nicht: der Ausdruck prüft mit normalize-space. Und bei öffentlichen Auftraggebern ersetzt die Leitweg-ID in BT-10 die Anschrift nicht — sie ist eine Routing-Kennung, die Gruppe BG-8 muss trotzdem vollständig sein.

  Wie Sie es beheben

  Übermitteln Sie den Ort strukturiert in BT-52: in UBL cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:CityName, in CII ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CityName.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:CityName>Bonn</cbc:CityName>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingCustomerParty>

  Was der Validator prüft

  UBLcbc:CityName[boolean(normalize-space(.))]

  CIIram:CityName[boolean(normalize-space(.))]

• BR-DE-9

  PLZ des Käufers (BT-53) fehlt

  Das Element "Buyer post code" (BT-53) muss übermittelt werden.

  Was die Regel verlangt

  Die Anschrift des Käufers muss eine Postleitzahl tragen (BT-53) — BR-DE-8 verlangt daneben den Ort, BR-DE-4 dasselbe beim Verkäufer. Eine Ausnahme für Länder ohne Postleitzahlensystem gibt es nicht: der Ausdruck sieht das Länderkennzeichen gar nicht an.

  Warum sie ausgelöst wird

  Dieselbe Wurzel wie bei BR-DE-8: unzerteilte Adresszeilen. Zusätzlich trifft es Rechnungen an Käufer in Ländern ohne Postleitzahlensystem, weil das Feld dort schlicht leer bleibt — und die Regel kennt dafür keine Ausnahme, weder über BT-55 noch sonst. Ein leeres Element genügt ebenfalls nicht: geprüft wird mit normalize-space.

  Wie Sie es beheben

  Übermitteln Sie die Postleitzahl in BT-53: in UBL cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cbc:PostalZone, in CII ram:BuyerTradeParty/ram:PostalTradeAddress/ram:PostcodeCode. Hat das Land des Käufers keine Postleitzahlen, tragen Sie ein, was dort postalisch verwendet wird: geprüft wird nur, dass etwas dasteht, nicht ob es eine gültige PLZ ist.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:CityName>Bonn</cbc:CityName>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PostalAddress>
        <cbc:CityName>Bonn</cbc:CityName>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:PostalAddress>
    </cac:Party>
  </cac:AccountingCustomerParty>

  Was der Validator prüft

  UBLcbc:PostalZone[boolean(normalize-space(.))]

  CIIram:PostcodeCode[boolean(normalize-space(.))]

• BR-DE-10

  Lieferanschrift ohne Ort (BT-77)

  Das Element "Deliver to city" (BT-77) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird.

  Was die Regel verlangt

  Sobald eine Lieferanschrift (Gruppe BG-15, „DELIVER TO ADDRESS“) übermittelt wird, muss sie den Ort (BT-77) enthalten. Ohne Lieferanschrift greift die Regel nicht.

  Warum sie ausgelöst wird

  Eine halb befüllte Lieferanschrift: sobald die Adressgruppe im Dokument steht, füllt das Quellsystem nur die Felder, die es kennt — übrig bleibt etwa ein Land ohne Ort. Ein reines Lieferdatum löst die Regel dagegen nicht aus: BT-72 steht in UBL als cac:Delivery/cbc:ActualDeliveryDate neben der Adresse, nicht darin. Der Ausdruck unten zeigt die Bedingung übrigens nicht — sie steckt im Kontext der Regel, dem Pfad cac:Delivery/cac:DeliveryLocation/cac:Address, den der Export weglässt. Deshalb liest sich BR-DE-10 dort wie BR-DE-3 und BR-DE-8.

  Wie Sie es beheben

  Entweder die Lieferanschrift vollständig übermitteln (Ort in BT-77: UBL cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:CityName, CII ram:ShipToTradeParty/ram:PostalTradeAddress/ram:CityName) — oder die Gruppe BG-15 ganz weglassen, wenn Sie keine Lieferanschrift angeben wollen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:Delivery>
    <cac:DeliveryLocation>
      <cac:Address>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:Address>
    </cac:DeliveryLocation>
  </cac:Delivery>

  <cac:Delivery>
    <cac:DeliveryLocation>
      <cac:Address>
        <cbc:CityName>Bonn</cbc:CityName>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:Address>
    </cac:DeliveryLocation>
  </cac:Delivery>

  Was der Validator prüft

  UBLcbc:CityName[boolean(normalize-space(.))]

  CIIram:CityName[boolean(normalize-space(.))]

• BR-DE-11

  Lieferanschrift ohne PLZ (BT-78)

  Das Element "Deliver to post code" (BT-78) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird.

  Was die Regel verlangt

  Sobald eine Lieferanschrift (BG-15) im Dokument steht, muss sie die Postleitzahl tragen (BT-78) — den Ort daneben verlangt BR-DE-10. Die EN 16931 fordert in dieser Gruppe nur das Land (BT-80, über BR-57); Ort und Postleitzahl kommen aus der deutschen CIUS.

  Warum sie ausgelöst wird

  Wie bei BR-DE-10 eine unvollständig befüllte Gruppe — die beiden Fehler treten fast immer gemeinsam auf, weil dasselbe Mapping beide Felder auslässt. Wer BG-15 öffnet, verpflichtet sich damit auf drei Felder: das Land verlangt schon die Norm über BR-57, Ort und Postleitzahl kommen über BR-DE-10 und BR-DE-11 hinzu. Ein leeres Element zählt auch hier nicht: geprüft wird mit normalize-space.

  Wie Sie es beheben

  Ergänzen Sie die Postleitzahl in BT-78: in UBL cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PostalZone, in CII ram:ShipToTradeParty/ram:PostalTradeAddress/ram:PostcodeCode. Oder lassen Sie BG-15 ganz weg, wenn die Lieferanschrift der Rechnungsanschrift entspricht.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:Delivery>
    <cac:DeliveryLocation>
      <cac:Address>
        <cbc:CityName>Bonn</cbc:CityName>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:Address>
    </cac:DeliveryLocation>
  </cac:Delivery>

  <cac:Delivery>
    <cac:DeliveryLocation>
      <cac:Address>
        <cbc:CityName>Bonn</cbc:CityName>
        <cbc:PostalZone>53113</cbc:PostalZone>
        <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
      </cac:Address>
    </cac:DeliveryLocation>
  </cac:Delivery>

  Was der Validator prüft

  UBLcbc:PostalZone[boolean(normalize-space(.))]

  CIIram:PostcodeCode[boolean(normalize-space(.))]

• BR-DE-14

  Umsatzsteuersatz (BT-119) fehlt

  Das Element "VAT category rate" (BT-119) muss übermittelt werden.

  Was die Regel verlangt

  Der Umsatzsteuersatz (BT-119, „VAT category rate“) muss für jede Steuerkategorie übermittelt werden — auch dann, wenn er 0 beträgt. Die EN 16931 erlaubt über BR-48 genau eine Ausnahme, die Kategorie O (nicht steuerbar); die deutsche CIUS streicht sie.

  Warum sie ausgelöst wird

  Bei steuerbefreiten oder Reverse-Charge-Rechnungen (Kategorien E, AE, Z) lassen viele Systeme den Prozentsatz weg, weil er inhaltlich „nichts aussagt“. XRechnung verlangt ihn trotzdem. Die Regel sitzt auf der Aufschlüsselung BG-23 und meldet deshalb je Kategorie ohne Satz einmal. Gegenüber BR-48 sind es zwei Unterschiede: dort ist die Kategorie O ausgenommen, und dort genügt ein vorhandenes Element — BR-DE-14 prüft mit normalize-space auf einen tatsächlichen Wert, ein leeres cbc:Percent reicht also nicht.

  Wie Sie es beheben

  Schreiben Sie BT-119 immer, bei befreiten Kategorien explizit mit dem Wert 0: in UBL cac:TaxCategory/cbc:Percent, in CII ram:ApplicableTradeTax/ram:RateApplicablePercent.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:TaxCategory>
    <cbc:ID>E</cbc:ID>
    <cbc:TaxExemptionReason>Kleinunternehmer nach § 19 UStG</cbc:TaxExemptionReason>
    <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
  </cac:TaxCategory>

  <cac:TaxCategory>
    <cbc:ID>E</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cbc:TaxExemptionReason>Kleinunternehmer nach § 19 UStG</cbc:TaxExemptionReason>
    <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
  </cac:TaxCategory>

  Was der Validator prüft

  UBLcac:TaxCategory/cbc:Percent[boolean(normalize-space(.))]

  CIIram:RateApplicablePercent[boolean(normalize-space(.))]

• BR-DE-15

  Leitweg-ID / Käuferreferenz (BT-10) fehlt

  Das Element "Buyer reference" (BT-10) muss übermittelt werden.

  Was die Regel verlangt

  Jede XRechnung braucht eine Käuferreferenz in BT-10 — bei Rechnungen an die öffentliche Verwaltung ist das die Leitweg-ID. Sie routet die Rechnung an die richtige Stelle. Geprüft wird allerdings nur, dass das Feld nicht leer ist: Aufbau und Prüfziffer sieht sich das Regelwerk nirgends an.

  Warum sie ausgelöst wird

  Das Feld fehlt fast immer dann, wenn eine bestehende Rechnungsvorlage aus dem B2B-Geschäft übernommen wurde: dort wird die Käuferreferenz selten benötigt, für XRechnung ist sie jedoch verpflichtend. Beim eigentlichen Risiko hilft die Prüfung nicht — der einzige Ausdruck im ganzen Regelwerk, der BT-10 anfasst, ist diese Existenzprüfung. „Test“ oder eine veraltete Leitweg-ID bestehen die Validierung und scheitern erst im Rechnungseingangsportal, das die Route nicht kennt.

  Wie Sie es beheben

  Übernehmen Sie die vom Rechnungsempfänger mitgeteilte Leitweg-ID beziehungsweise Käuferreferenz in BT-10. In UBL ist das cbc:BuyerReference, in CII ram:BuyerReference. Auch im B2B-Fall ist das Feld Pflicht: dort steht die Referenz, um die der Käufer gebeten hat — eine Bestellnummer etwa.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>

  Was der Validator prüft

  UBLcbc:BuyerReference[boolean(normalize-space(.))]

  CIIrsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerReference[boolean(normalize-space(.))]

  Weiterlesen

  • Leitweg-ID: Aufbau, Prüfziffer und Format prüfen

• BR-DE-16

  Verkäufer steuerlich nicht identifizierbar

  Wenn in einer Rechnung die Steuercodes S, Z, E, AE, K, G, L oder M verwendet werden, muss mindestens eines der Elemente "Seller VAT identifier" (BT-31), "Seller tax registration identifier" (BT-32) oder "SELLER TAX REPRESENTATIVE PARTY" (BG-11) übermittelt werden.

  Was die Regel verlangt

  Bei den Steuercodes S, Z, E, AE, K, G, L oder M muss der Verkäufer steuerlich identifizierbar sein: USt-IdNr., Steuernummer oder BG-11. Gemeint sind die Umsatzsteuer-Identifikationsnummer (BT-31), die Steuernummer (BT-32) und der steuerliche Vertreter (BG-11) — eines der drei genügt.

  Warum sie ausgelöst wird

  Kleinunternehmer nach § 19 UStG verwenden den Code E und haben oft keine USt-IdNr. Dann fehlt häufig auch die Steuernummer, weil sie im bisherigen Rechnungslayout nie erfasst wurde. Der UBL-Ausdruck unten zeigt dabei Variablen statt Werte: supportedVATCodes steht für die acht Codes S, Z, E, AE, K, G, L und M, BT-31orBT-32Path für cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID mit Inhalt. Und die Syntaxen sind hier nicht deckungsgleich: in UBL zählt jede Kennung unter PartyTaxScheme, in CII nur eine Registrierung mit schemeID VA oder FC.

  Wie Sie es beheben

  Tragen Sie mindestens eines der drei Elemente ein. Ohne USt-IdNr. ist BT-32 (Steuernummer) der übliche Weg — in UBL als cac:PartyTaxScheme/cbc:CompanyID mit cac:TaxScheme/cbc:ID gleich FC, in CII als ram:SpecifiedTaxRegistration/ram:ID mit schemeID FC.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:Party>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>

  <cac:Party>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>12/345/67890</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>FC</cbc:ID></cac:TaxScheme>
    </cac:PartyTaxScheme>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>

  Was der Validator prüft

  UBL(not( ($BT-95-UBL-Inv = $supportedVATCodes or $BT-95-UBL-CN = $supportedVATCodes) or ($BT-102 = $supportedVATCodes) or ($BT-151 = $supportedVATCodes) ) or (cac:TaxRepresentativeParty, $BT-31orBT-32Path))

  Variablen darin

  $BT-95-UBL-Inv

  cac:AllowanceCharge/cac:TaxCategory/cbc:ID[ancestor::cac:AllowanceCharge/cbc:ChargeIndicator = 'false' and following-sibling::cac:TaxScheme/cbc:ID = 'VAT']

  $supportedVATCodes

  ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M')

  $BT-95-UBL-CN

  cac:AllowanceCharge/cac:TaxCategory/cbc:ID[ancestor::cac:AllowanceCharge/cbc:ChargeIndicator = 'false']

  $BT-102

  cac:AllowanceCharge/cac:TaxCategory/cbc:ID[ancestor::cac:AllowanceCharge/cbc:ChargeIndicator = 'true']

  $BT-151

  (cac:InvoiceLine | cac:CreditNoteLine)/cac:Item/cac:ClassifiedTaxCategory/cbc:ID

  $BT-31orBT-32Path

  cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID[boolean(normalize-space(.))]

  CIInot((rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:TypeCode = 'VAT' and rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M')) or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge/ram:CategoryTradeTax = 'VAT' and rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge/ram:CategoryTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M')) or (rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:TypeCode = 'VAT' and rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M'))) or ((rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[normalize-space(@schemeID)='VA' or normalize-space(@schemeID)='FC'][boolean(normalize-space(.))], rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTaxRepresentativeTradeParty))

• BR-DE-17

  Rechnungstyp (BT-3) nicht zugelassen

  Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).Warnung

  Was die Regel verlangt

  Der Rechnungstyp (BT-3) soll einer der zugelassenen UNTDID-1001-Codes sein: 326, 380, 384, 389, 381, 875, 876 oder 877. BR-DE-17 meldet als Warnung, nicht als Fehler — eine Rechnung mit einem anderen Code wird deswegen nicht abgewiesen.

  Warum sie ausgelöst wird

  Der Standardwert vieler Systeme ist 380 (Handelsrechnung) und damit korrekt. Abweichungen entstehen meist bei Gutschriften oder Abschlagsrechnungen im Baugewerbe, wo ein selbst gewählter Code eingetragen wurde. Häufiger noch trifft es Codes, die die EN 16931 über BR-CL-01 zulässt und XRechnung nicht aufführt — 383 für die Belastungsanzeige etwa oder 386 für die Vorauszahlungsrechnung. Die Rechnung ist dann normkonform und löst trotzdem diese Warnung aus. Beide Syntaxen prüfen dieselben acht Codes; im UBL-Ausdruck stehen sie nur hinter dem Variablennamen supportedInvAndCNTypeCodes.

  Wie Sie es beheben

  Ordnen Sie Ihren internen Belegtyp einem der zugelassenen Codes zu — 380 für die normale Rechnung, 326 für die Abschlagsrechnung, 381 für die Gutschrift. Von diesen acht Codes ist die 381 der einzige, den BR-CL-01 in UBL nicht in cbc:InvoiceTypeCode annimmt: dort gehört sie in cbc:CreditNoteTypeCode eines CreditNote-Dokuments.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cbc:InvoiceTypeCode>RE</cbc:InvoiceTypeCode>

  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

  Was der Validator prüft

  UBLnormalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodes

  Variablen darin

  $supportedInvAndCNTypeCodes

  ('326', '380', '384', '389', '381', '875', '876', '877')

  CIInormalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')

• BR-DE-18

  Skonto-Format in BT-20 falsch

  Skonto Zeilen in […] müssen diesem regulärem Ausdruck entsprechen: […]. Die Informationen zur Gewährung von Skonto müssen wie folgt im Element "Payment terms" (BT-20) übermittelt werden: Anzugeben ist im ersten Segment "SKONTO", im zweiten "TAGE=n", im dritten "PROZENT=n". Prozentzahlen sind ohne Vorzeichen sowie mit Punkt getrennt von zwei Nachkommastellen anzugeben. Liegt dem zu berechnenden Betrag nicht BT-115, "fälliger Betrag" zugrunde, sondern nur ein Teil des fälligen Betrags der Rechnung, ist der Grundwert zur Berechnung von Skonto als viertes Segment "BASISBETRAG=n" gemäß dem semantischen Datentypen Amount anzugeben. Jeder Eintrag beginnt mit einer #, die Segmente sind mit einer # getrennt und eine Zeile schließt mit einer # ab. Am Ende einer vollständigen Skontoangabe muss ein XML-konformer Zeilenumbruch folgen. Alle Angaben zur Gewährung von Skonto müssen in Großbuchstaben gemacht werden. Zusätzliches Whitespace (Leerzeichen, Tabulatoren oder Zeilenumbrüche) ist nicht zulässig. Andere Zeichen oder Texte als in den oberen Vorgaben genannt sind nicht zulässig.

  Wortlaut in CII

  Skonto Zeilen in […] muessen diesem regulärem Ausdruck entsprechen: […]. Die Informationen zur Gewährung von Skonto müssen wie folgt im Element "Payment terms" (BT-20) übermittelt werden: Anzugeben ist im ersten Segment "SKONTO", im zweiten "TAGE=n", im dritten "PROZENT=n". Prozentzahlen sind ohne Vorzeichen sowie mit Punkt getrennt von zwei Nachkommastellen anzugeben. Liegt dem zu berechnenden Betrag nicht BT-115, "fälliger Betrag" zugrunde, sondern nur ein Teil des fälligen Betrags der Rechnung, ist der Grundwert zur Berechnung von Skonto als viertes Segment "BASISBETRAG=n" gemäß dem semantischen Datentypen Amount anzugeben. Jeder Eintrag beginnt mit einer #, die Segmente sind mit einer # getrennt und eine Zeile schließt mit einer # ab. Am Ende einer vollständigen Skontoangabe muss ein XML-konformer Zeilenumbruch folgen. Alle Angaben zur Gewährung von Skonto müssen in Großbuchstaben gemacht werden. Zusätzliches Whitespace (Leerzeichen, Tabulatoren oder Zeilenumbrüche) ist nicht zulässig. Andere Zeichen oder Texte als in den oberen Vorgaben genannt sind nicht zulässig.

  Was die Regel verlangt

  Skonto-Angaben in den Zahlungsbedingungen (BT-20) müssen einem festen maschinenlesbaren Format folgen: #SKONTO#TAGE=n#PROZENT=n.nn#, je Angabe eine Zeile, alles in Großbuchstaben, Prozent mit Punkt und genau zwei Nachkommastellen.

  Warum sie ausgelöst wird

  Die Regel prüft ausschließlich Zeilen, die mit # beginnen. Ein freier Satz wie „2 % Skonto bei Zahlung innerhalb von 14 Tagen“ wird ignoriert und fällt nicht durch — er ist für den Empfänger allerdings auch nicht maschinell auswertbar. Der Fehler entsteht beim halb korrekten Versuch: PROZENT=2 statt PROZENT=2.00, ein Leerzeichen zu viel oder der fehlende Zeilenumbruch am Ende. Der offizielle Regeltext lässt oben zwei Stellen offen, weil das Regelwerk sie erst beim Prüfen einsetzt: den Namen des Elements und den Ausdruck selbst. Er lautet (^|\r?\n)#(SKONTO)#TAGE=([0-9]+#PROZENT=[0-9]+\.[0-9]{2})(#BASISBETRAG=-?[0-9]+\.[0-9]{2})?#$ und sagt drei Dinge, die im Fließtext fehlen: TAGE nimmt nur ganze Zahlen, PROZENT kein Vorzeichen, BASISBETRAG ausdrücklich auch ein Minus.

  Wie Sie es beheben

  Schreiben Sie den Eintrag exakt als #SKONTO#TAGE=14#PROZENT=2.00# und schließen Sie ihn mit einem Zeilenumbruch ab. Prozentwerte immer mit Punkt und genau zwei Nachkommastellen. Bezieht sich das Skonto nur auf einen Teilbetrag, folgt als viertes Segment #BASISBETRAG=n.nn#. Kein zusätzliches Leerzeichen, kein weiterer Text in derselben Zeile.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentTerms>
    <cbc:Note>2 % Skonto bei Zahlung innerhalb von 14 Tagen</cbc:Note>
  </cac:PaymentTerms>

  <cac:PaymentTerms>
    <cbc:Note>#SKONTO#TAGE=14#PROZENT=2.00#
  Zahlbar innerhalb von 30 Tagen netto</cbc:Note>
  </cac:PaymentTerms>

  Was der Validator prüft

  UBLevery $line in cac:PaymentTerms/cbc:Note[1]/tokenize(. , '(\r?\n)')[starts-with( normalize-space(.) , '#')] satisfies matches ( normalize-space ($line), $XR-SKONTO-REGEX) and matches( cac:PaymentTerms/cbc:Note[1]/tokenize(. , '#.+#')[last()], '^\s*\n' )

  Variablen darin

  $XR-SKONTO-REGEX

  '(^|\r?\n)#(SKONTO)#TAGE=([0-9]+#PROZENT=[0-9]+\.[0-9]{2})(#BASISBETRAG=-?[0-9]+\.[0-9]{2})?#$'

  CIIevery $line in rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:Description[1]/tokenize(. , '(\r?\n)')[starts-with( normalize-space(.) , '#')] satisfies matches ( normalize-space ($line), $XR-SKONTO-REGEX ) and matches( rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:Description[1]/tokenize(. , '#.+#')[last()], '^\s*\n' )

  Variablen darin

  $XR-SKONTO-REGEX

  '(^|\r?\n)#(SKONTO)#TAGE=([0-9]+#PROZENT=[0-9]+\.[0-9]{2})(#BASISBETRAG=-?[0-9]+\.[0-9]{2})?#$'

• BR-DE-19

  IBAN bei Überweisung (BT-84) ungültig

  "Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird.Warnung

  Was die Regel verlangt

  Wird als Zahlungsmittel SEPA-Überweisung angegeben (BT-81 mit Code 58), soll die Kontoverbindung (BT-84) eine korrekte IBAN sein. Geprüft wird nur bei Code 58 und nur als Warnung: Code 30, die allgemeine Überweisung, kommt ungeprüft durch.

  Warum sie ausgelöst wird

  Meist ein Tippfehler in der IBAN — oder Code 58, obwohl gar keine SEPA-Überweisung gemeint ist. Leerzeichen sind dagegen unkritisch: die Funktion xr:checkIBAN entfernt erst allen Whitespace und rechnet dann die Prüfziffer nach ISO 7064 nach, also die ersten vier Zeichen ans Ende, Buchstaben als 10 bis 35, Ergebnis modulo 97 muss 1 sein. „DE02 1203 0000 0000 2020 51“ besteht die Prüfung deshalb genauso wie dieselbe IBAN ohne Leerzeichen.

  Wie Sie es beheben

  Übermitteln Sie die IBAN mit gültiger Prüfziffer in BT-84 (UBL cac:PayeeFinancialAccount/cbc:ID, CII ram:PayeePartyCreditorFinancialAccount/ram:IBANID) — oder wählen Sie den passenden Zahlungsmittelcode, wenn es keine SEPA-Überweisung ist. Zulässig ist außerdem nur die IBAN-Form selbst: zwei Buchstaben, zwei Ziffern, danach höchstens dreißig weitere Zeichen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

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

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

  Was der Validator prüft

  UBLnot(normalize-space(cbc:PaymentMeansCode) = '58') or xr:checkIBAN(string(cac:PayeeFinancialAccount/cbc:ID))

  CIInot(normalize-space(ram:TypeCode) = '58') or xr:checkIBAN(string(ram:PayeePartyCreditorFinancialAccount/ram:IBANID))

• BR-DE-20

  IBAN bei Lastschrift (BT-91) ungültig

  "Debited account identifier" (BT-91) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 59 SEPA als Zahlungsmittel gefordert wird.Warnung

  Was die Regel verlangt

  Bei SEPA-Lastschrift (BT-81 mit Code 59) soll das zu belastende Konto (BT-91) eine korrekte IBAN enthalten — geprüft wird die Prüfziffer, und nur als Warnung. Gemeint ist das Konto des Käufers, nicht das eigene: die Daten stammen aus dem Mandat, das Ihnen der Kunde erteilt hat.

  Warum sie ausgelöst wird

  Meist ein Tippfehler in einer IBAN, die aus dem Mandat übernommen wurde — und anders als beim eigenen Konto fällt das intern niemandem auf, weil die Nummer nie wieder benutzt wird. Leerzeichen sind unkritisch: xr:checkIBAN entfernt erst allen Whitespace und rechnet dann die Prüfziffer nach ISO 7064 nach. Um die Lastschrift herum hängen drei Fehler an derselben Gruppe: BR-DE-25-a verlangt bei Code 59 die Gruppe BG-19, BR-DE-31 darin das Konto BT-91 und BR-DE-30 die Gläubiger-Identifikation BT-90.

  Wie Sie es beheben

  Übermitteln Sie die IBAN des zu belastenden Kontos mit gültiger Prüfziffer in BT-91: in UBL unter cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID, in CII direkt als ram:PayerPartyDebtorFinancialAccount/ram:IBANID. Die Mandatsklammer gibt es nur in UBL — in CII steht das Konto ohne sie.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
      <cac:PayerFinancialAccount>
        <cbc:ID>DE02120300000000202052</cbc:ID>
      </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
      <cac:PayerFinancialAccount>
        <cbc:ID>DE02120300000000202051</cbc:ID>
      </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

  Was der Validator prüft

  UBLnot(normalize-space(cbc:PaymentMeansCode) = '59') or xr:checkIBAN(string(cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID))

  CIInot(normalize-space(ram:TypeCode) = '59') or xr:checkIBAN(string(ram:PayerPartyDebtorFinancialAccount/ram:IBANID))

• BR-DE-21

  Kennung ist keine XRechnung (BT-24)

  Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.Warnung

  Was die Regel verlangt

  Die Spezifikationskennung (BT-24) soll die des Standards XRechnung sein — genau drei Werte sind zugelassen, und die Regel warnt nur. Sie sagt dem Empfänger, dass die Rechnung nach XRechnung erstellt wurde, und in welcher Variante.

  Warum sie ausgelöst wird

  Häufig steht dort nur die EN-16931-Kennung ohne den XRechnung-Teil, eine veraltete Versionsnummer oder ein Tippfehler im URN. Im Ausdruck unten erscheinen die drei zugelassenen Werte nur als Variablennamen; ausgeschrieben stehen sie im nächsten Abschnitt.

  Wie Sie es beheben

  Übermitteln Sie die Kennung der Variante, die Sie tatsächlich erzeugen — in UBL als cbc:CustomizationID, in CII in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. Für die CIUS ist das urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0; die Extension hängt daran #conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0 an, die CVD-Variante #compliant#urn:xeinkauf.de:kosit:xrechnung:cvd_0.9. Achten Sie auf die Version: in der Kennung steht 3.0, nicht die Patch-Version des Regelwerks.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>

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

  Was der Validator prüft

  UBLcbc:CustomizationID = $XR-CIUS-ID or cbc:CustomizationID = $XR-EXTENSION-ID or cbc:CustomizationID = $XR-CVD-ID

  Variablen darin

  $XR-CIUS-ID

  concat('urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_', $XR-MAJOR-MINOR-VERSION )

  $XR-EXTENSION-ID

  concat($XR-CIUS-ID, '#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_' ,$XR-MAJOR-MINOR-VERSION )

  $XR-CVD-ID

  concat($XR-CIUS-ID, '#compliant#urn:xeinkauf.de:kosit:xrechnung:cvd_' , $CVD-MAJOR-MINOR-VERSION )

  $XR-MAJOR-MINOR-VERSION

  '3.0'

  $CVD-MAJOR-MINOR-VERSION

  '0.9'

  CIIram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-CIUS-ID or ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-EXTENSION-ID or ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-CVD-ID

  Variablen darin

  $XR-CIUS-ID

  concat('urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_', $XR-MAJOR-MINOR-VERSION )

  $XR-EXTENSION-ID

  concat($XR-CIUS-ID, '#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_' ,$XR-MAJOR-MINOR-VERSION )

  $XR-CVD-ID

  concat($XR-CIUS-ID, '#compliant#urn:xeinkauf.de:kosit:xrechnung:cvd_' , $CVD-MAJOR-MINOR-VERSION )

  $XR-MAJOR-MINOR-VERSION

  '3.0'

  $CVD-MAJOR-MINOR-VERSION

  '0.9'

  Weiterlesen

  • ZUGFeRD Extended oder XRechnung: welche Kennung Sie verschicken

• BR-DE-22

  Zwei Anlagen mit gleichem Dateinamen

  Das "filename"-Attribut aller "EmbeddedDocumentBinaryObject"-Elemente muss eindeutig sein

  Wortlaut in CII

  Not all filename attributes of the embeddedDocumentBinaryObject elements are unique

  Was die Regel verlangt

  Alle eingebetteten Anlagen einer Rechnung müssen unterschiedliche Dateinamen tragen — unterschieden werden sie nur darüber. Der Empfänger legt sie unter genau diesem Namen ab.

  Warum sie ausgelöst wird

  Der Generator vergibt einen konstanten Namen — jede Anlage heißt „anlage.pdf“ oder „attachment.pdf“. Bei genau einer Anlage fällt das nie auf; die zweite löst den Fehler aus. Die beiden Syntaxen schauen dabei unterschiedlich weit: in UBL zählt der Ausdruck nur die Anlagen auf Dokumentebene, in CII sucht er mit // im ganzen Dokument und erfasst damit auch Belegverweise, die an einer Rechnungsposition hängen. Dieselbe Rechnung kann in CII also auffallen und in UBL nicht.

  Wie Sie es beheben

  Vergeben Sie je Anlage einen eindeutigen Dateinamen im filename-Attribut (UBL cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename, CII ram:AttachmentBinaryObject/@filename) — am einfachsten den Originalnamen der Datei, notfalls mit laufender Nummer.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AdditionalDocumentReference>
    <cbc:ID>1</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="anhang.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>2</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="anhang.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  <cac:AdditionalDocumentReference>
    <cbc:ID>1</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="stundennachweis.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>
  <cac:AdditionalDocumentReference>
    <cbc:ID>2</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="lieferschein.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  Was der Validator prüft

  UBLcount(cac:AdditionalDocumentReference) = count(cac:AdditionalDocumentReference[not(./cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename = preceding-sibling::cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject/@filename)])

  CIIcount(//ram:AdditionalReferencedDocument) = count(//ram:AdditionalReferencedDocument[not(./ram:AttachmentBinaryObject/@filename = preceding-sibling::ram:AdditionalReferencedDocument/ram:AttachmentBinaryObject/@filename)])

• BR-DE-23-a

  Überweisung ohne Bankverbindung (BG-17)

  Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), muss BG-17 "CREDIT TRANSFER" übermittelt werden.

  Was die Regel verlangt

  Bei einer Überweisung (BT-81 mit Code 30 oder 58) muss die Gruppe BG-17 mit der Empfängerbankverbindung im Dokument stehen. Wer eine Überweisung verlangt, muss sagen, wohin — die IBAN darin fordern dann BR-50 und BR-61 aus der Norm, nicht diese Regel.

  Warum sie ausgelöst wird

  Die Bankverbindung steht nur im PDF-Fußtext oder im Freitext der Zahlungsbedingungen, nicht als strukturierte Gruppe. Der Code 58 wurde gesetzt, BG-17 aber nie gemappt. Der Ausdruck unten zeigt davon nichts — dort steht allein cac:PayeeFinancialAccount, also die bloße Existenz der Gruppe. Die Bedingung sitzt im Kontext der Regel, im Muster cac:PaymentMeans mit dem Prädikat auf den Codes 30 und 58, und die Regel meldet je Zahlungsweg einmal: bietet die Rechnung zwei an, kann derselbe Code zweimal im Bericht stehen.

  Wie Sie es beheben

  Übermitteln Sie BG-17 mit mindestens der IBAN des Empfängerkontos (BT-84): in UBL cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID, in CII ram:PayeePartyCreditorFinancialAccount/ram:IBANID.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  </cac:PaymentMeans>

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

  Was der Validator prüft

  UBLcac:PayeeFinancialAccount

  CIIram:PayeePartyCreditorFinancialAccount

• BR-DE-23-b

  Überweisung mit fremden Zahlungsdaten

  Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), dürfen BG-18 und BG-19 nicht übermittelt werden.

  Was die Regel verlangt

  Bei einer Überweisung (BT-81 mit Code 30 oder 58) dürfen keine Kartendaten (BG-18) und keine Lastschriftdaten (BG-19) danebenstehen. BR-DE-23-a ist das Gegenstück und verlangt die passende Gruppe BG-17.

  Warum sie ausgelöst wird

  Das System schreibt alle vorhandenen Zahlungsinformationen immer mit — etwa das gespeicherte Lastschriftmandat des Kunden, obwohl diese eine Rechnung per Überweisung gezahlt werden soll. Die beiden Syntaxen ziehen die Grenze dabei verschieden: in UBL prüft der Ausdruck nur die Kinder desselben cac:PaymentMeans, in CII starten zwei der drei Lastschrift-Prüfungen an der Dokumentwurzel. Eine Rechnung, die zwei Zahlungswege anbietet — eine Überweisung und daneben eine Lastschrift mit Mandat —, besteht deshalb in UBL und scheitert in CII.

  Wie Sie es beheben

  Übermitteln Sie zu jedem Zahlungsweg nur die passende Gruppe: bei 30 und 58 ausschließlich BG-17. Kartendaten und Mandatsangaben weglassen — oder den Code korrigieren, wenn tatsächlich per Lastschrift eingezogen wird. In CII reicht das nicht: solange eine Überweisung dabei ist, darf im ganzen Dokument keine Mandats- oder Gläubigerangabe stehen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayeeFinancialAccount>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

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

  Was der Validator prüft

  UBLnot(cac:CardAccount) and not(cac:PaymentMandate)

  CIInot(ram:ApplicableTradeSettlementFinancialCard) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID)

• BR-DE-24-a

  Kartenzahlung ohne Kartendaten (BG-18)

  Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau BG-18 "PAYMENT CARD INFORMATION" übermittelt werden.

  Was die Regel verlangt

  Bei einer Kartenzahlung (BT-81 mit Code 48, 54 oder 55) muss die Gruppe BG-18 mit den Kartendaten im Dokument stehen. Was darin zu stehen hat, regelt BR-51: die letzten Stellen der Kartennummer, nie die vollständige PAN.

  Warum sie ausgelöst wird

  Kartenzahlung kommt in Rechnungsprozessen selten vor; wird der Code doch gesetzt (etwa weil bereits per Karte gezahlt wurde), fehlt die zugehörige Gruppe fast immer. Der Ausdruck unten verrät davon nichts: dort steht nur cac:CardAccount, die bloße Existenz der Gruppe. Die drei Codes stehen im Kontext der Regel, im Muster auf cac:PaymentMeans, und geprüft wird je Zahlungsweg einzeln.

  Wie Sie es beheben

  Übermitteln Sie BG-18 mit der maskierten Kartennummer (BT-87, nur die letzten Stellen — niemals die vollständige PAN): in UBL cac:PaymentMeans/cac:CardAccount, in CII ram:ApplicableTradeSettlementFinancialCard.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
  </cac:PaymentMeans>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
    <cac:CardAccount>
      <cbc:PrimaryAccountNumberID>******1234</cbc:PrimaryAccountNumberID>
      <cbc:NetworkID>NA</cbc:NetworkID>
    </cac:CardAccount>
  </cac:PaymentMeans>

  Was der Validator prüft

  UBLcac:CardAccount

  CIIram:ApplicableTradeSettlementFinancialCard

• BR-DE-24-b

  Kartenzahlung mit fremden Zahlungsdaten

  Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), dürfen BG-17 und BG-19 nicht übermittelt werden.

  Was die Regel verlangt

  Bei Kartenzahlung (BT-81 mit Code 48, 54 oder 55) dürfen weder Überweisungsdaten (BG-17) noch Lastschriftdaten (BG-19) danebenstehen. BR-DE-24-a ist das Gegenstück und verlangt die passende Gruppe BG-18.

  Warum sie ausgelöst wird

  Die eigene Empfänger-IBAN wird gewohnheitsmäßig in jede Rechnung geschrieben, auch wenn der gewählte Zahlungsweg gar keine Überweisung ist — genau dieses Standardfeld bringt die Kartenzahlung zu Fall. Die Codes 48, 54 und 55 stehen dabei nicht im Ausdruck, sondern im Kontext der Regel auf cac:PaymentMeans, und geprüft wird je Zahlungsweg einzeln. Wie bei BR-DE-23-b sieht UBL nur die Kinder desselben Zahlungswegs an, während in CII die beiden Lastschrift-Prüfungen an der Dokumentwurzel ansetzen.

  Wie Sie es beheben

  Bei Kartenzahlung nur BG-18 übermitteln. Die sonst übliche Empfänger-IBAN (BG-17) für diese Rechnung weglassen — oder den Zahlungsmittelcode auf 58 ändern, wenn in Wahrheit überwiesen werden soll.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
    <cac:CardAccount>
      <cbc:PrimaryAccountNumberID>******1234</cbc:PrimaryAccountNumberID>
      <cbc:NetworkID>NA</cbc:NetworkID>
    </cac:CardAccount>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
    <cac:CardAccount>
      <cbc:PrimaryAccountNumberID>******1234</cbc:PrimaryAccountNumberID>
      <cbc:NetworkID>NA</cbc:NetworkID>
    </cac:CardAccount>
  </cac:PaymentMeans>

  Was der Validator prüft

  UBLnot(cac:PayeeFinancialAccount) and not(cac:PaymentMandate)

  CIInot(ram:PayeePartyCreditorFinancialAccount) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID)

• BR-DE-25-a

  Lastschrift ohne Mandatsdaten (BG-19)

  Wenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), muss genau BG-19 "DIRECT DEBIT" übermittelt werden.

  Was die Regel verlangt

  Wird als Zahlungsmittel SEPA-Lastschrift angegeben (BT-81 mit Code 59), muss die Gruppe BG-19 („DIRECT DEBIT“) übermittelt werden — mit den Angaben, die den Einzug tragen: Mandatsreferenz, Gläubiger-ID und zu belastendes Konto.

  Warum sie ausgelöst wird

  Der Code 59 wird gesetzt, weil per Lastschrift eingezogen wird — Mandatsreferenz und Gläubiger-ID leben aber im Debitorenstamm und wurden nie in das Rechnungsformat gemappt. Die Messlatte ist dabei in beiden Syntaxen eine andere: UBL verlangt das Element cac:PaymentMandate selbst, CII lässt eines von dreien genügen — Mandatsreferenz, Gläubiger-ID oder die IBAN des Zahlers. Ein CII-Dokument mit bloßer Gläubiger-ID und ohne Mandat besteht BR-DE-25-a also, das entsprechende UBL-Dokument nicht. Der Code 59 steht nicht im Ausdruck, sondern im Kontext der Regel, und geprüft wird je Zahlungsweg einzeln.

  Wie Sie es beheben

  Übermitteln Sie BG-19: Mandatsreferenz (BT-89, UBL cac:PaymentMandate/cbc:ID, CII ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID), Gläubiger-ID (BT-90) und das zu belastende Konto (BT-91). Siehe auch BR-DE-30 und BR-DE-31, die die letzten beiden einzeln prüfen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  </cac:PaymentMeans>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
      <cac:PayerFinancialAccount>
        <cbc:ID>DE02120300000000202051</cbc:ID>
      </cac:PayerFinancialAccount>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

  Was der Validator prüft

  UBLcac:PaymentMandate

  CII/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID

• BR-DE-25-b

  Lastschrift mit fremden Zahlungsdaten

  Wenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), dürfen BG-17 und BG-18 nicht übermittelt werden.

  Was die Regel verlangt

  Wird als Zahlungsmittel SEPA-Lastschrift angegeben (BT-81 mit Code 59), dürfen keine Überweisungsdaten (BG-17) und keine Kartendaten (BG-18) übermittelt werden.

  Warum sie ausgelöst wird

  Der häufigste Fall der drei b-Regeln: die eigene Bankverbindung steht als BG-17 in jeder Rechnung, aus Gewohnheit — bei einer Lastschrift hat sie dort nichts zu suchen, eingezogen wird vom Konto des Käufers. In CII ist die Verbotsliste länger als in UBL: dort stehen neben dem Empfängerkonto und der Kartengruppe auch die Bank des Empfängers und die des Zahlers darauf, weil CII sie als eigene Elemente neben dem Konto führt statt darin.

  Wie Sie es beheben

  Bei Lastschrift nur BG-19 übermitteln und die Empfängerbankverbindung (BG-17) für diese Rechnung weglassen. Diese Regel sieht dabei nur den einen Zahlungsweg an: zwei Wege nebeneinander — eine Überweisung und eine Lastschrift als getrennte cac:PaymentMeans — verbietet sie nicht. In CII scheitert eine solche Rechnung trotzdem, aber an BR-DE-23-b.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayeeFinancialAccount>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
    <cac:PaymentMandate>
      <cbc:ID>MANDAT-2026-0007</cbc:ID>
    </cac:PaymentMandate>
  </cac:PaymentMeans>

  Was der Validator prüft

  UBLnot(cac:PayeeFinancialAccount) and not(cac:CardAccount)

  CIInot(ram:PayeePartyCreditorFinancialAccount) and not(ram:PayeeSpecifiedCreditorFinancialInstitution) and not(ram:PayerSpecifiedDebtorFinancialInstitution) and not(ram:ApplicableTradeSettlementFinancialCard)

• BR-DE-26

  Korrektur ohne Rechnungsbezug (BG-3)

  Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.Warnung

  Wortlaut in CII

  Wenn im Element Invoice type code (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.

  Was die Regel verlangt

  Eine Rechnungskorrektur (BT-3 mit Code 384) soll die vorausgegangene Rechnung nennen, in der Gruppe BG-3 „PRECEDING INVOICE REFERENCE“. Gemeldet wird das als Warnung, nicht als Fehler — sonst weiß der Empfänger allerdings nicht, was korrigiert wird.

  Warum sie ausgelöst wird

  Die Korrektur wird als eigenständiger Beleg erzeugt, und die Nummer der Ursprungsrechnung steht nur im Freitext („Korrektur zu Rechnung 2026-0815“) statt im strukturierten Feld. Ausgelöst wird die Regel allein vom Code 384: eine Gutschrift mit 381 oder eine Schlussrechnung mit 877 prüft sie nicht. Und sie verlangt nur die Gruppe, nicht deren Inhalt — ein leeres cac:InvoiceDocumentReference genügt ihr bereits und scheitert dann an BR-55, das die Nummer BT-25 darin fordert.

  Wie Sie es beheben

  Übermitteln Sie die Nummer der korrigierten Rechnung in BG-3 (BT-25): in UBL cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID, in CII ram:InvoiceReferencedDocument/ram:IssuerAssignedID.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

  <cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>RE-2026-0041</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>

  Was der Validator prüft

  UBL((not(normalize-space(cbc:InvoiceTypeCode) = '384' or normalize-space(cbc:CreditNoteTypeCode) = '384') or (cac:BillingReference/cac:InvoiceDocumentReference)))

  CIInot(normalize-space(rsm:ExchangedDocument/ram:TypeCode) = '384') or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument)

• BR-DE-27

  Telefonnummer zu kurz (BT-42)

  In BT-42 sollen mindestens drei Ziffern enthalten sein.Warnung

  Was die Regel verlangt

  Die Telefonnummer des Ansprechpartners (BT-42) soll mindestens drei Ziffern enthalten — eine Plausibilitätsprüfung, keine Formatvorschrift, und gemeldet als Warnung.

  Warum sie ausgelöst wird

  Das Feld ist mit einem Platzhalter gefüllt („-“, „0“, „n/a“), weil BR-DE-6 irgendeinen Wert verlangt und das Quellsystem keine Durchwahl kennt. Der Ausdruck dahinter ist .*([0-9].*){3,}.* auf dem mit normalize-space bereinigten Wert: drei Ziffern irgendwo im Text, in beliebiger Reihenfolge und mit beliebigem Zeichen dazwischen. „+49“ und „0“ fallen damit durch, „Durchwahl 123“ und sogar „2026“ bestehen.

  Wie Sie es beheben

  Tragen Sie eine echte erreichbare Nummer ein (UBL cac:Contact/cbc:Telephone, CII ram:DefinedTradeContact/ram:TelephoneUniversalCommunication/ram:CompleteNumber). Format ist frei — +49 30 1234567 genügt; nur aus weniger als drei Ziffern darf sie nicht bestehen.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:Contact>
    <cbc:Name>Buchhaltung</cbc:Name>
    <cbc:Telephone>-</cbc:Telephone>
  </cac:Contact>

  <cac:Contact>
    <cbc:Name>Buchhaltung</cbc:Name>
    <cbc:Telephone>+49 30 1234567</cbc:Telephone>
  </cac:Contact>

  Was der Validator prüft

  UBLmatches(normalize-space(cbc:Telephone), $XR-TELEPHONE-REGEX)

  Variablen darin

  $XR-TELEPHONE-REGEX

  '.*([0-9].*){3,}.*'

  CIImatches(normalize-space(ram:TelephoneUniversalCommunication/ram:CompleteNumber), $XR-TELEPHONE-REGEX)

  Variablen darin

  $XR-TELEPHONE-REGEX

  '.*([0-9].*){3,}.*'

• BR-DE-28

  E-Mail-Adresse unplausibel (BT-43)

  In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen.Warnung

  Was die Regel verlangt

  Die E-Mail-Adresse des Ansprechpartners (BT-43) soll plausibel aufgebaut sein: genau ein @, kein Leerzeichen, ein Punkt in der Domain. Der Regeltext verlangt dabei mehr, als der Ausdruck prüft — gemeldet wird ohnehin nur eine Warnung.

  Warum sie ausgelöst wird

  Platzhalter wie „-“ oder „keine“, zwei Adressen in einem Feld („a@firma.de; b@firma.de“) oder ein abgeschnittener Wert mit Punkt am Ende. Der Regeltext klingt dabei strenger, als die Prüfung ist: er verlangt zwei Zeichen links und rechts vom @, keinen Punkt daneben und keinen am Anfang. Der Ausdruck ^[^@\s]+@([^@.\s]+\.)+[^@.\s]+$ setzt davon nur einen Teil durch — a@b.c mit einem einzigen Zeichen links besteht ebenso wie a.@b.c und .@b.c. Zuverlässig durchfallen: fehlendes @, zwei @, ein Leerzeichen im Wert, eine Domain ohne Punkt und ein Punkt am Ende.

  Wie Sie es beheben

  Tragen Sie genau eine gültige Adresse ein, etwa rechnung@firma.de (UBL cac:Contact/cbc:ElectronicMail, CII ram:EmailURIUniversalCommunication/ram:URIID). Mehrere Empfänger gehören nicht in das Feld — wählen Sie ein Funktionspostfach.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:Contact>
    <cbc:ElectronicMail>rechnung@muster.de, buchhaltung@muster.de</cbc:ElectronicMail>
  </cac:Contact>

  <cac:Contact>
    <cbc:ElectronicMail>rechnung@muster.de</cbc:ElectronicMail>
  </cac:Contact>

  Was der Validator prüft

  UBLmatches(normalize-space(cbc:ElectronicMail), $XR-EMAIL-REGEX)

  Variablen darin

  $XR-EMAIL-REGEX

  '^[^@\s]+@([^@.\s]+\.)+[^@.\s]+$'

  CIImatches(normalize-space(ram:EmailURIUniversalCommunication/ram:URIID), $XR-EMAIL-REGEX)

  Variablen darin

  $XR-EMAIL-REGEX

  '^[^@\s]+@([^@.\s]+\.)+[^@.\s]+$'

• BR-DE-30

  Gläubiger-ID (BT-90) fehlt

  Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Bank assigned creditor identifier" BT-90 übermittelt werden.

  Was die Regel verlangt

  Enthält die Rechnung Lastschriftdaten (BG-19), muss darin die Gläubiger-Identifikationsnummer (BT-90) stehen — die SEPA-Kennung, unter der Sie als Zahlungsempfänger einziehen dürfen.

  Warum sie ausgelöst wird

  Die Gläubiger-ID ist einmal je Unternehmen vergeben und liegt in der Buchhaltung, nicht im Rechnungsdatensatz — beim Mapping wird sie schlicht vergessen. Der CII-Ausdruck besteht aus vier Variablen: BT-89 ist ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID, BT-90 ist ram:CreditorReferenceID, BT-91 die IBAN des Zahlers, und BG-19-not-existing heißt, dass keines der drei vorkommt. Daraus folgt eine Eigenheit: trägt ein CII-Dokument allein die Gläubiger-ID und weder Mandatsreferenz noch Zahler-IBAN, scheitert BR-DE-30 — obwohl genau das Feld vorhanden ist, das die Regel verlangt.

  Wie Sie es beheben

  Übermitteln Sie Ihre Gläubiger-ID (Format DE98ZZZ09999999999) in BT-90. In UBL gehört sie normalerweise unter den Verkäufer: cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID mit schemeID="SEPA". Nur wenn der Zahlungsempfänger ein anderer ist als der Verkäufer, steht sie stattdessen unter cac:PayeeParty — die Prüfung akzeptiert beide Stellen. Legen Sie cac:PayeeParty nicht eigens dafür an: die Gruppe verlangt dann auch einen Namen (BR-17). In CII ram:CreditorReferenceID.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="SEPA">DE98ZZZ09999999999</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBLnot(cac:PaymentMeans/cac:PaymentMandate) or (cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID[@schemeID='SEPA'] | cac:PayeeParty/cac:PartyIdentification/cbc:ID[@schemeID='SEPA'])

  CII(($BT-89-path or $BT-91-path) and $BT-90-path) or $BG-19-not-existing

  Variablen darin

  $BT-89-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID

  $BT-91-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans/ram:PayerPartyDebtorFinancialAccount/ram:IBANID

  $BT-90-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID

  $BG-19-not-existing

  not(exists(($BT-89-path, $BT-90-path, $BT-91-path)))

• BR-DE-31

  Belastetes Konto (BT-91) fehlt

  Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Debited account identifier" BT-91 übermittelt werden.

  Was die Regel verlangt

  Enthält die Rechnung Lastschriftdaten (BG-19), muss darin das zu belastende Konto (BT-91) stehen — die IBAN des Käufers, von der eingezogen wird.

  Warum sie ausgelöst wird

  Die Kunden-IBAN liegt im Mandat beim Zahlungsdienstleister oder im Debitorenstamm und wird aus Vorsicht nicht in den Rechnungsdatensatz übernommen — die Regel verlangt sie dort aber. In CII steht sie in einem Ausdruck aus vier Variablen, spiegelbildlich zu BR-DE-30: verlangt wird BT-91, sobald eines der drei Lastschriftfelder vorkommt. Steht allein die Zahler-IBAN da und weder Mandatsreferenz noch Gläubiger-ID, scheitert BR-DE-31 trotzdem. Zusammen mit BR-DE-30 heißt das für CII: Gläubiger-ID und Zahler-IBAN müssen beide vorhanden sein, die Mandatsreferenz BT-89 bleibt optional.

  Wie Sie es beheben

  Übermitteln Sie die IBAN des zu belastenden Kontos in BT-91: in UBL cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID, in CII ram:PayerPartyDebtorFinancialAccount/ram:IBANID. Zur IBAN-Korrektheit siehe BR-DE-20.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:PaymentMandate>
    <cbc:ID>MANDAT-2026-0007</cbc:ID>
  </cac:PaymentMandate>

  <cac:PaymentMandate>
    <cbc:ID>MANDAT-2026-0007</cbc:ID>
    <cac:PayerFinancialAccount>
      <cbc:ID>DE02120300000000202051</cbc:ID>
    </cac:PayerFinancialAccount>
  </cac:PaymentMandate>

  Was der Validator prüft

  UBLnot(cac:PaymentMeans/cac:PaymentMandate) or (cac:PaymentMeans/cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID)

  CII(($BT-89-path or $BT-90-path) and $BT-91-path) or $BG-19-not-existing

  Variablen darin

  $BT-89-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID

  $BT-90-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID

  $BT-91-path

  rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans/ram:PayerPartyDebtorFinancialAccount/ram:IBANID

  $BG-19-not-existing

  not(exists(($BT-89-path, $BT-90-path, $BT-91-path)))

• BR-TMP-2

  Anhang-Adresse nicht absolut (BT-124)

  BT-124 "External document location" muss eine absolute URL mit gültigem Schema enthalten.

  Was die Regel verlangt

  Verweist die Rechnung auf ein extern gespeichertes Dokument (BT-124), muss dort eine absolute Adresse mit Schema stehen. Ein Dateiname, ein Laufwerkspfad oder eine Adresse ohne Schema fallen durch.

  Warum sie ausgelöst wird

  Der Wert stammt meist unverändert aus dem eigenen Dokumentenmanagement, wo relative Pfade und Netzlaufwerke normal sind. Für den Empfänger ist ein solcher Pfad nicht auflösbar: er zeigt auf einen Rechner, den es bei ihm nicht gibt. Geprüft wird das mit ^([a-zA-Z])([a-zA-Z0-9+.-])+:.* — also allein, ob vor einem Doppelpunkt ein Schemaname steht. Ob die Adresse erreichbar oder überhaupt eine Web-Adresse ist, prüft niemand: mailto:, ftp: und auch file:///C:/anhang.pdf bestehen. Der interne Pfad rutscht also durch, sobald ihn jemand als Datei-URL schreibt. Zwei Unterschiede zwischen den Syntaxen kommen dazu: CII prüft nur Verweise mit dem Typcode 916, und CII lässt ein fehlendes Adressfeld durchgehen, während UBL es als Fehler wertet.

  Wie Sie es beheben

  Tragen Sie eine absolute URL mit Schema ein — in UBL unter cac:AdditionalDocumentReference/cac:Attachment/cac:ExternalReference/cbc:URI, in CII unter ram:URIID. Wenn das Dokument nicht öffentlich erreichbar ist, hängen Sie es besser als eingebettetes Objekt an, statt einen internen Pfad zu verschicken.

  Im XML

  Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

  <cac:AdditionalDocumentReference>
    <cbc:ID>ANL-2026-0042</cbc:ID>
    <cac:Attachment>
      <cac:ExternalReference>
        <cbc:URI>www.beispiel.de/anlagen/stundennachweis.pdf</cbc:URI>
      </cac:ExternalReference>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  <cac:AdditionalDocumentReference>
    <cbc:ID>ANL-2026-0042</cbc:ID>
    <cac:Attachment>
      <cac:ExternalReference>
        <cbc:URI>https://www.beispiel.de/anlagen/stundennachweis.pdf</cbc:URI>
      </cac:ExternalReference>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  Was der Validator prüft

  UBLmatches(cbc:URI, $XR-URL-REGEX)

  Variablen darin

  $XR-URL-REGEX

  '^([a-zA-Z])([a-zA-Z0-9+.-])+:.*'

  CIInot(exists(ram:URIID)) or (matches(ram:URIID, $XR-URL-REGEX))

  Variablen darin

  $XR-URL-REGEX

  '^([a-zA-Z])([a-zA-Z0-9+.-])+:.*'

• BR-TMP-3

  Preisbasismenge (BT-149) widersprüchlich

  Wenn BT-149 (Item price base quantity) sowohl in GrossPriceProductTradePrice als auch in NetPriceProductTradePrice vorhanden ist, müssen die Werte identisch sein. Wenn BT-150 (unit of measure code) auf dem NetPrice-Pfad vorhanden ist, muss es auch auf dem GrossPrice-Pfad vorhanden und identisch sein.

  Was die Regel verlangt

  Steht die Preisbasismenge (BT-149) sowohl beim Bruttopreis als auch beim Nettopreis einer Position, müssen beide Werte identisch sein — und trägt der Nettopreis eine Maßeinheit (BT-150), muss der Bruttopreis dieselbe tragen.

  Warum sie ausgelöst wird

  Der Bruttopreis wird häufig nachträglich ergänzt, wenn ein Rabatt auf Positionsebene abgebildet werden soll. Die Basismenge wird dabei aus einer anderen Quelle gefüllt oder ganz weggelassen, und schon widersprechen sich die beiden Preisblöcke. Die Regel gibt es nur in CII, weil nur dort Brutto- und Nettopreis je eine eigene Basismenge tragen — in UBL existiert das Paar nicht, das sich widersprechen könnte. Beim Maßeinheitencode weicht der Ausdruck außerdem vom Regeltext ab: verlangt wird dort, dass eine Einheit am Nettopreis auch am Bruttopreis steht; geprüft wird nur, dass zwei vorhandene Einheiten übereinstimmen. Fehlt sie am Bruttopreis, besteht die Rechnung.

  Wie Sie es beheben

  Füllen Sie ram:BasisQuantity in GrossPriceProductTradePrice und NetPriceProductTradePrice aus demselben Feld, einschließlich des unitCode-Attributs. Wenn Sie keine abweichende Basismenge brauchen, lassen Sie sie in beiden Blöcken weg statt nur in einem.

  Im XML

  Ausschnitt in CII — die Regel gilt nur für diese Syntax.

  <ram:GrossPriceProductTradePrice>
    <ram:ChargeAmount>100.00</ram:ChargeAmount>
    <ram:BasisQuantity unitCode="C62">1</ram:BasisQuantity>
  </ram:GrossPriceProductTradePrice>
  <ram:NetPriceProductTradePrice>
    <ram:ChargeAmount>90.00</ram:ChargeAmount>
    <ram:BasisQuantity unitCode="C62">10</ram:BasisQuantity>
  </ram:NetPriceProductTradePrice>

  <ram:GrossPriceProductTradePrice>
    <ram:ChargeAmount>100.00</ram:ChargeAmount>
    <ram:BasisQuantity unitCode="C62">10</ram:BasisQuantity>
  </ram:GrossPriceProductTradePrice>
  <ram:NetPriceProductTradePrice>
    <ram:ChargeAmount>90.00</ram:ChargeAmount>
    <ram:BasisQuantity unitCode="C62">10</ram:BasisQuantity>
  </ram:NetPriceProductTradePrice>

  Was der Validator prüft

  CIInot(ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:BasisQuantity and ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:BasisQuantity) or (ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:BasisQuantity = ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:BasisQuantity and (not(ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:BasisQuantity/@unitCode and ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:BasisQuantity/@unitCode) or ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:BasisQuantity/@unitCode = ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:BasisQuantity/@unitCode))

• BR-TMP-4

  Anlage mit zwei Bezeichnungen (BT-123)

  BT-123 "Supporting document description" (ram:Name) darf innerhalb von "Additional supporting documents" (BG-24) höchstens einmal vorkommen.Warnung

  Was die Regel verlangt

  Innerhalb einer Anlage (BG-24) darf die Bezeichnung des Dokuments (BT-123) höchstens einmal vorkommen — eine Warnung, kein Fehler. Mehrere Namen für dieselbe Anlage sind nicht zulässig — für ein zweites Dokument gehört eine zweite BG-24-Gruppe angelegt.

  Warum sie ausgelöst wird

  Tritt auf, wenn mehrere Anhänge in eine Gruppe geschrieben werden, statt je Anhang eine Gruppe zu erzeugen: die Schleife hängt ram:Name mehrfach an denselben Knoten. Der Empfänger kann dann nicht mehr zuordnen, welcher Name zu welcher Datei gehört.

  Wie Sie es beheben

  Legen Sie pro Anhang eine eigene ram:AdditionalReferencedDocument-Gruppe mit genau einem ram:Name an. BR-TMP-4 ist die richtig zugeschnittene Fassung von CII-SR-475: die CEN-Regel hängt am ram:ApplicableHeaderTradeAgreement und zählt deshalb die Namen aller 916-Dokumente zusammen. Zwei Anhänge mit je einem Namen sind für BR-TMP-4 in Ordnung und lösen CII-SR-475 aus — beide melden allerdings nur eine Warnung.

  Im XML

  Ausschnitt in CII — die Regel gilt nur für diese Syntax.

  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-1</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Stundennachweis August</ram:Name>
    <ram:Name>Materialliste August</ram:Name>
  </ram:AdditionalReferencedDocument>

  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-1</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Stundennachweis August</ram:Name>
  </ram:AdditionalReferencedDocument>
  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-2</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Materialliste August</ram:Name>
  </ram:AdditionalReferencedDocument>

  Was der Validator prüft

  CIIcount(ram:Name) <= 1

• BR-TMP-5

  Anlage mit zwei Dateien (BT-125)

  BT-125 "Attached document" (ram:AttachmentBinaryObject) darf innerhalb von "Additional Supporting documents" (BG-24) höchstens einmal vorkommen.Warnung

  Was die Regel verlangt

  Innerhalb einer Anlage (BG-24) darf höchstens ein eingebettetes Dokument (BT-125) stehen — eine Warnung, kein Fehler. Zwei Dateien in derselben Gruppe sind nicht zulässig, auch wenn das Schema sie technisch erlaubt.

  Warum sie ausgelöst wird

  Mehrere Anhänge werden in eine einzige Gruppe geschrieben, wie bei BR-TMP-4. Weil jede Gruppe nur eine Bezeichnung und einen Dokumenttyp trägt, verliert der Empfänger die Zuordnung zwischen Datei und Beschreibung.

  Wie Sie es beheben

  Erzeugen Sie je Datei eine eigene ram:AdditionalReferencedDocument-Gruppe mit genau einem ram:AttachmentBinaryObject, inklusive mimeCode und filename. Die Dateinamen müssen sich dabei unterscheiden — dafür sorgt BR-DE-22. BR-TMP-5 ist die richtig zugeschnittene Fassung von CII-SR-476: die CEN-Regel hängt am ram:ApplicableHeaderTradeAgreement und zählt die Dateien aller 916-Dokumente zusammen, sodass zwei sauber getrennte Anhänge sie auslösen.

  Im XML

  Ausschnitt in CII — die Regel gilt nur für diese Syntax.

  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-1</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Nachweise August</ram:Name>
    <ram:AttachmentBinaryObject mimeCode="application/pdf" filename="stunden.pdf">JVBERi0xLjcK</ram:AttachmentBinaryObject>
    <ram:AttachmentBinaryObject mimeCode="application/pdf" filename="material.pdf">JVBERi0xLjcK</ram:AttachmentBinaryObject>
  </ram:AdditionalReferencedDocument>

  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-1</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Stundennachweis August</ram:Name>
    <ram:AttachmentBinaryObject mimeCode="application/pdf" filename="stunden.pdf">JVBERi0xLjcK</ram:AttachmentBinaryObject>
  </ram:AdditionalReferencedDocument>
  <ram:AdditionalReferencedDocument>
    <ram:IssuerAssignedID>ANL-2</ram:IssuerAssignedID>
    <ram:TypeCode>916</ram:TypeCode>
    <ram:Name>Materialliste August</ram:Name>
    <ram:AttachmentBinaryObject mimeCode="application/pdf" filename="material.pdf">JVBERi0xLjcK</ram:AttachmentBinaryObject>
  </ram:AdditionalReferencedDocument>

  Was der Validator prüft

  CIIcount(ram:AttachmentBinaryObject) <= 1

• BR-TMP-6

  Datumsformat in UBL falsch

  Datumsangaben in UBL müssen im Format JJJJ-MM-TT (YYYY-MM-DD) übermittelt werden.Warnung

  Was die Regel verlangt

  Datumsangaben in einer UBL-XRechnung müssen als JJJJ-MM-TT geschrieben werden, also 2026-08-26 — geprüft als Warnung. Die Regel greift dabei nicht auf jedem Datumsfeld, sondern auf sieben benannten: IssueDate, DueDate, StartDate, EndDate, ActualDeliveryDate, TaxPointDate und PaymentDueDate, an jeder Stelle im Dokument und auch in referenzierten Belegen.

  Warum sie ausgelöst wird

  Das deutsche Anzeigeformat 26.08.2026 wandert in den Datensatz, weil das Datum als bereits formatierte Zeichenkette aus der Rechnungsvorlage übernommen wird statt als Datumswert. Auch amerikanische Reihenfolgen und angehängte Uhrzeiten fallen hierunter.

  Wie Sie es beheben

  Formatieren Sie Datumswerte beim Schreiben des XML explizit nach ISO 8601 (JJJJ-MM-TT) und übernehmen Sie niemals die Ausgabe der Anzeigeschicht. Eine Uhrzeit gehört nicht in ein Datumsfeld — vergleiche BR-TMP-7 für dieselbe Regel in CII.

  Im XML

  Ausschnitt in UBL — die Regel gilt nur für diese Syntax.

  <cbc:IssueDate>26.08.2026</cbc:IssueDate>
  <cbc:DueDate>2026-09-25T00:00:00</cbc:DueDate>

  <cbc:IssueDate>2026-08-26</cbc:IssueDate>
  <cbc:DueDate>2026-09-25</cbc:DueDate>

  Was der Validator prüft

  UBLmatches(normalize-space(text()), '^\d{4}-\d{2}-\d{2}$')

• BR-TMP-7

  Datumsformat in CII falsch

  Datumsangaben in UNCEFACT/CII müssen das Attribut format="102" tragen und im Format JJJJMMTT (YYYYMMDD) übermittelt werden.Warnung

  Was die Regel verlangt

  Datumsangaben in CII werden anders geschrieben als in UBL: als JJJJMMTT ohne Trennzeichen, also 20260826, und das umgebende Element muss das Attribut format="102" tragen, das genau dieses Muster ankündigt.

  Warum sie ausgelöst wird

  Fast immer wird das Attribut vergessen oder auf 610 beziehungsweise 616 gesetzt, während der Wert weiterhin achtstellig ist. Ebenso häufig wird das ISO-Format aus der UBL-Ausgabe übernommen, wo Bindestriche richtig sind — in CII sind sie es nicht. Geprüft werden dabei drei Elemente: udt:DateTimeString, qdt:DateTimeString und udt:DateString. Und ein falsches Attribut bleibt selten bei dieser Warnung: BR-03 sucht das Rechnungsdatum in CII als udt:DateTimeString mit format 102, sodass ein fehlendes oder falsches Attribut das Datum für BR-03 verschwinden lässt — und das ist ein Fehler, keine Warnung.

  Wie Sie es beheben

  Schreiben Sie das Datum als udt:DateTimeString mit format="102" und acht Ziffern. Wer beide Syntaxen erzeugt, sollte die Formatierung an genau einer Stelle je Syntax haben, sonst wandert früher oder später die eine Schreibweise in die andere Ausgabe — vergleiche BR-TMP-6.

  Im XML

  Ausschnitt in CII — die Regel gilt nur für diese Syntax.

  <ram:IssueDateTime>
    <udt:DateTimeString format="610">2026-08-26</udt:DateTimeString>
  </ram:IssueDateTime>

  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260826</udt:DateTimeString>
  </ram:IssueDateTime>

  Was der Validator prüft

  CIInormalize-space(@format) = '102' and matches(normalize-space(text()), '^\d{8}$')