XRechnung Extension — wann die strengeren Regeln greifen

Zwei Ausprägungen, ein Regelwerk

XRechnung kennt die CIUS, die die europäische Norm einschränkt, und die Extension, die sie erweitert. Welche gilt, entscheidet die Spezifikations-Kennung (BT-24): trägt sie den Extension-Bezeichner, greifen die BR-DEX-Regeln zusätzlich.

Das ist die häufigste Verwirrung an dieser Stelle. Ein BR-DEX-Fehler auf einer Rechnung, die gar keine Extension sein sollte, bedeutet fast immer eine falsche BT-24 — siehe BR-DE-21.

Was die Extension hinzufügt

Vor allem Unterpositionen: eine Position darf untergeordnete Positionen enthalten, was die normale CIUS nicht erlaubt. Daran hängen die meisten BR-DEX-Regeln — dass eine Unterposition ihre eigene Steuerinformation trägt, dass die Beträge der Unterpositionen zur übergeordneten Position aufgehen.

Benutzen Sie die Extension nur, wenn Sie diese Strukturen wirklich brauchen. Sie schränkt den Kreis der Empfänger ein, die die Rechnung verarbeiten können, und die Regeln oben kommen ohne Gegenleistung obendrauf.

Und sie gibt es nur in UBL. Die Regeln zu Unterpositionen — BR-DEX-02 und BR-DEX-03 — sind für UBL formuliert und für CII gar nicht vorhanden; stattdessen meldet BR-DEX-15 auf einer CII-Datei mit ram:ParentLineID, dass XRechnung das Konzept dort nicht kennt. Wer Unterpositionen braucht, kann also nicht in CII liefern, und damit auch nicht als ZUGFeRD.

Ein Zugewinn steht dem gegenüber, der nichts mit Positionen zu tun hat: BR-DEX-01 erlaubt der Extension einen siebten MIME-Typ für eingebettete Anlagen, application/xml, den die CIUS über BR-CL-24 nicht zulässt. Beide Listen stehen unten bei der jeweiligen Regel.

Zwei der fünfzehn Regeln sind übrigens Warnungen, keine Fehler: BR-DEX-02, dessen Text „soll“ sagt und nicht „muss“, und BR-DEX-15. Eine Rechnung wird deswegen nicht abgewiesen — der Bericht führt sie, und der Empfänger entscheidet.

Alle Extension-Regeln

Welches Feld die Regel bewacht, und darunter der offizielle Regeltext.

• BR-DEX-01

  MIME-Typ der eingebetteten Anlage (BT-125)

  Das Element […] "Attached Document" (BT-125) benutzt einen nicht zulässigen MIME-Code: […]. Im Falle einer Extension darf zusätzlich zu der Liste der mime codes (definiert in Abschnitt 8.2, "Binary Object") der MIME-Code application/xml genutzt werden.

  7 zulässige Werte · application/pdf, application/vnd.oasis.opendocument.spreadsheet, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/xml, image/jpeg, image/png, text/csv

  Was die Regel verlangt

  Trägt die Rechnung die Extension-Kennung, muss jede eingebettete Anlage (BT-125) einen von sieben MIME-Typen tragen: die sechs aus BR-CL-24 — application/pdf, image/png, image/jpeg, text/csv und die Tabellenformate .xlsx und .ods — und zusätzlich application/xml. Verglichen wird Zeichen für Zeichen; „application/PDF“ besteht nicht. Anders als BR-CL-24 prüft die Regel auch eine Anlage ganz ohne mimeCode — in CII, wo das Schema das Attribut nicht verlangt, fällt eine solche Anlage erst hier auf.

  Warum sie ausgelöst wird

  Der MIME-Typ wird meist ungeprüft übernommen — aus der Dateiendung oder von der Bibliothek, die die Datei einliest. Für XML ist text/xml verbreitet, zugelassen ist aber nur application/xml; ebenso scheitern image/jpg statt image/jpeg und das generische application/octet-stream. Word-Dokumente, ZIP-Archive und alte .xls-Dateien sieht die Liste gar nicht vor.

  Wie Sie es beheben

  Setzen Sie mimeCode auf genau einen der sieben Werte, so geschrieben wie in der Liste — in UBL an cac:AdditionalDocumentReference/cac:Attachment/cbc:EmbeddedDocumentBinaryObject, in CII an ram:AdditionalReferencedDocument/ram:AttachmentBinaryObject. Andere Formate wandeln Sie vor dem Einbetten in PDF um. Der Wert application/xml gilt nur mit der Extension-Kennung in BT-24: auf einer CIUS-Rechnung weist BR-CL-24 denselben Anhang ab. In der Extension meldet BR-CL-24 ihn zwar weiterhin, entscheidet dort aber nicht mehr über die Annahme — die KoSIT-Konfiguration stuft die Regel für die Extension zum Hinweis herab.

  Im XML

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

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0</cbc:CustomizationID>
  <cac:AdditionalDocumentReference>
    <cbc:ID>ANL-1</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="text/xml" filename="stueckliste.xml">PD94bWwgdmVyc2lvbj0iMS4wIj8+</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0</cbc:CustomizationID>
  <cac:AdditionalDocumentReference>
    <cbc:ID>ANL-1</cbc:ID>
    <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/xml" filename="stueckliste.xml">PD94bWwgdmVyc2lvbj0iMS4wIj8+</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
  </cac:AdditionalDocumentReference>

  Was der Validator prüft

  UBL.[@mimeCode = 'application/pdf' or @mimeCode = 'image/png' or @mimeCode = 'image/jpeg' or @mimeCode = 'text/csv' or @mimeCode = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' or @mimeCode = 'application/vnd.oasis.opendocument.spreadsheet' or @mimeCode = 'application/xml']

  CII.[@mimeCode = 'application/pdf' or @mimeCode = 'image/png' or @mimeCode = 'image/jpeg' or @mimeCode = 'text/csv' or @mimeCode = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' or @mimeCode = 'application/vnd.oasis.opendocument.spreadsheet' or @mimeCode = 'application/xml']

• BR-DEX-02

  Positionsnetto aus den Unterpositionen (BT-131)

  Der Wert von "Invoice line net amount" (BT-131) einer "INVOICE LINE" (BG-25) oder einer "SUB INVOICE LINE" (BG-DEX-01) soll der Summe der "Invoice line net amount" (BT-131) der direkt darunterliegenden "SUB INVOICE LINE" (BG-DEX-01) entsprechen.Warnung

  Was die Regel verlangt

  Hat eine Rechnungsposition Unterpositionen (BG-DEX-01), soll ihr Nettobetrag (BT-131) genau der Summe der Nettobeträge ihrer direkt darunterliegenden Unterpositionen entsprechen — auf jeder Ebene, auch wenn Unterpositionen selbst wieder welche haben. Verglichen wird exakt, ohne Rundungstoleranz. Die Regel warnt nur und meldet sich einmal für die ganze Rechnung: die Fundstelle ist das Dokument, nicht die Position, die nicht aufgeht.

  Warum sie ausgelöst wird

  Typisch ist ein Paket- oder Setpreis: die übergeordnete Position trägt den Paketpreis, die Unterpositionen listen die Teile zu ihren Einzelpreisen, und die Summe weicht ab. Dieselbe Warnung erscheint, wenn die Unterpositionen nur ein Stück beschreiben, die Position aber drei berechnet, oder wenn ein Rabatt nur an der übergeordneten Position steht. Es genügen schon einzeln gerundete Unterpositionen: dreimal 33,33 ergibt 99,99, nicht 100,00.

  Wie Sie es beheben

  Leiten Sie die Unterpositionen aus dem Betrag der übergeordneten Position ab: Paketpreis und Rabatt auf die Teile verteilen, Mengen auf die Gesamtmenge der Position hochrechnen, den Rundungsrest einer Unterposition zuschlagen. In die Summe der Positionsnettobeträge (BT-106) geht nur die übergeordnete cac:InvoiceLine ein — BR-CO-10 zählt cac:SubInvoiceLine nicht mit —, korrigiert werden im Zweifel also die Unterpositionen. Unterpositionen gibt es nur in UBL (cac:InvoiceLine/cac:SubInvoiceLine/cbc:LineExtensionAmount); auf einer CII-Datei mit ram:ParentLineID meldet sich stattdessen BR-DEX-15.

  Im XML

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

  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
    <cac:SubInvoiceLine>
      <cbc:ID>1.1</cbc:ID>
      <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
      <cbc:LineExtensionAmount currencyID="EUR">899.00</cbc:LineExtensionAmount>
    </cac:SubInvoiceLine>
    <cac:SubInvoiceLine>
      <cbc:ID>1.2</cbc:ID>
      <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
      <cbc:LineExtensionAmount currencyID="EUR">398.00</cbc:LineExtensionAmount>
    </cac:SubInvoiceLine>
  </cac:InvoiceLine>

  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1200.00</cbc:LineExtensionAmount>
    <cac:SubInvoiceLine>
      <cbc:ID>1.1</cbc:ID>
      <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
      <cbc:LineExtensionAmount currencyID="EUR">840.00</cbc:LineExtensionAmount>
    </cac:SubInvoiceLine>
    <cac:SubInvoiceLine>
      <cbc:ID>1.2</cbc:ID>
      <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
      <cbc:LineExtensionAmount currencyID="EUR">360.00</cbc:LineExtensionAmount>
    </cac:SubInvoiceLine>
  </cac:InvoiceLine>

  Was der Validator prüft

  UBL(every $invoiceline in /ubl:Invoice/cac:InvoiceLine[ exists (./cac:SubInvoiceLine) ] satisfies $invoiceline/xs:decimal(cbc:LineExtensionAmount) = sum($invoiceline/cac:SubInvoiceLine/xs:decimal(cbc:LineExtensionAmount))) and (count( //cac:SubInvoiceLine [count(cac:SubInvoiceLine) > 0 and xs:decimal(cbc:LineExtensionAmount) = sum(cac:SubInvoiceLine/xs:decimal(cbc:LineExtensionAmount))]) = count(//cac:SubInvoiceLine [count(cac:SubInvoiceLine) > 0]))

• BR-DEX-03

  Steuerangabe je Unterposition (BG-DEX-06)

  Eine Sub Invoice Line (BG-DEX-01) muss genau eine "SUB INVOICE LINE VAT INFORMATION" (BG-DEX-06) enthalten.

  Was die Regel verlangt

  Jede Unterposition (BG-DEX-01) muss in ihrem Artikel genau eine Steuerangabe tragen, die Gruppe BG-DEX-06 — ein cac:ClassifiedTaxCategory, nicht keins und nicht zwei. Das gilt auf jeder Ebene, auch für Unterpositionen von Unterpositionen. Gezählt wird nur das Element: Kategorie, Steuersatz und Steuerschema darin prüft BR-DEX-03 nicht. Wie bei BR-DEX-02 ist die Fundstelle die Rechnung als Ganzes, nicht die betroffene Unterposition.

  Warum sie ausgelöst wird

  Die Unterpositionen werden als reine Aufschlüsselung erzeugt — Bezeichnung, Menge, Betrag —, weil die Steuerangabe ja schon an der übergeordneten Position steht. Die Extension verlangt sie trotzdem an jeder einzelnen Unterposition. Ebenso scheitert ein Artikel, in den das Mapping zwei Kategorien schreibt, etwa die der übergeordneten Position und die eigene.

  Wie Sie es beheben

  Geben Sie jeder cac:SubInvoiceLine in cac:Item genau ein cac:ClassifiedTaxCategory mit Kategorie (cbc:ID), Steuersatz (cbc:Percent) und cac:TaxScheme/cbc:ID gleich VAT — hinter Bezeichnung, Kennungen und Klassifizierung, vor cac:AdditionalItemProperty. Jede Unterposition trägt dabei die Kategorie und den Satz, die für ihren Teil gelten. In CII gibt es keine Unterpositionen; auf einer CII-Datei mit ram:ParentLineID meldet sich stattdessen BR-DEX-15.

  Im XML

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

  <cac:SubInvoiceLine>
    <cbc:ID>1.1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">840.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Notebook</cbc:Name>
    </cac:Item>
  </cac:SubInvoiceLine>

  <cac:SubInvoiceLine>
    <cbc:ID>1.1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">840.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Notebook</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
  </cac:SubInvoiceLine>

  Was der Validator prüft

  UBLnot(exists(//cac:SubInvoiceLine/cac:Item[ count ( cac:ClassifiedTaxCategory) != 1]))

• BR-DEX-04

  Schema der Parteikennung (BT-29, BT-46, BT-60)

  Any scheme identifier in […] MUST be coded using one of the ISO 6523 ICD list.

  Was die Regel verlangt

  Trägt eine Parteikennung — die des Verkäufers (BT-29), des Käufers (BT-46) oder des Zahlungsempfängers (BT-60) — ein Schema-Attribut, muss dessen Wert auf einer Extension-Rechnung aus der ISO-6523-ICD-Liste stammen: derselben wie bei BR-CL-10, ergänzt um drei Codes, die nur die XRechnung kennt: XR01, XR02 und XR03. Damit diese drei durchgehen, stuft die KoSIT-Konfiguration BR-CL-10 für die Extension zum Hinweis herab; über die Annahme entscheidet dort BR-DEX-04. Kennungen ohne schemeID prüft die Regel nicht, und in UBL ist zusätzlich SEPA erlaubt — aber nur beim Verkäufer und beim Zahlungsempfänger, wo im selben Element auch die Gläubiger-ID (BT-90) steht.

  Warum sie ausgelöst wird

  Meist steht im Attribut ein Kürzel statt des Codes: „GLN“ statt 0088, „DUNS“ statt 0060, oder die Nummer ohne führende Nullen („88“). Ebenso scheitern sepa in Kleinschreibung und SEPA beim Käufer. Ein leeres schemeID="" lässt BR-DEX-04 dagegen durch: die Liste ist aus zwei Zeichenketten zusammengesetzt, an der Nahtstelle stehen zwei Leerzeichen, und genau die findet der Vergleich. BR-CL-10 bemängelt den leeren Wert zwar, entscheidet in der Extension aber nicht mit.

  Wie Sie es beheben

  Tragen Sie den Code aus der Liste ein, für eine GLN also 0088 — in UBL als schemeID an cac:PartyIdentification/cbc:ID, in CII an ram:GlobalID der jeweiligen Partei (ram:SellerTradeParty, ram:BuyerTradeParty, ram:PayeeTradeParty). Hat die Kennung kein Schema aus der Liste, lassen Sie das Attribut weg; in CII gehört sie dann nach ram:ID statt nach ram:GlobalID. Die SEPA-Ausnahme gibt es nur in UBL: in CII steht die Gläubiger-ID nicht in ram:GlobalID, sondern in ram:CreditorReferenceID.

  Im XML

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

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="GLN">4012345000009</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>Muster GmbH</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="0088">4012345000009</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>Muster GmbH</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:AccountingSupplierParty>

  Was der Validator prüft

  UBL((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' ')))) or ((not(contains(normalize-space(@schemeID), ' ')) and contains(' SEPA ', concat(' ', normalize-space(@schemeID), ' '))) and ((ancestor::cac:AccountingSupplierParty) or (ancestor::cac:PayeeParty)))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

  CII((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

• BR-DEX-05

  Schema der Registerkennung (BT-30, BT-47, BT-61)

  Any scheme identifier in […] MUST be coded using one of the ISO 6523 ICD list.

  Was die Regel verlangt

  Trägt eine Registerkennung — die des Verkäufers (BT-30), des Käufers (BT-47) oder des Zahlungsempfängers (BT-61) — ein Schema-Attribut, muss dessen Wert auf einer Extension-Rechnung aus der ISO-6523-ICD-Liste stammen: derselben wie bei BR-CL-11, ergänzt um drei Codes, die nur die XRechnung kennt: XR01, XR02 und XR03; BR-CL-11 selbst stuft die KoSIT-Konfiguration für die Extension zum Hinweis herab. Ohne schemeID wird nichts geprüft. In CII greift die Regel — wie BR-CL-11 — weiter, als ihr Feld vermuten lässt: sie prüft jedes ram:ID mit schemeID, ausgenommen die Steuerregistrierung (ram:SpecifiedTaxRegistration).

  Warum sie ausgelöst wird

  Typisch ist die Handelsregisternummer mit einem selbst gewählten Schema, etwa schemeID="HRB" — das ist kein Code der Liste. In CII kommt eine zweite Quelle hinzu: steht eine Partei- oder Lieferortkennung mit Schema in ram:ID statt in ram:GlobalID, wird ein falscher Code dort als BR-DEX-05 gemeldet und nicht als BR-DEX-04 oder BR-DEX-08. Ein leeres schemeID="" lässt die Regel dagegen durch, weil an der Nahtstelle der zusammengesetzten Liste zwei Leerzeichen stehen; BR-CL-11 bemängelt es, entscheidet in der Extension aber nicht mit.

  Wie Sie es beheben

  Übermitteln Sie die Handelsregisternummer ohne schemeID — in UBL als cac:PartyLegalEntity/cbc:CompanyID, in CII als ram:SpecifiedLegalOrganization/ram:ID; die Regel prüft nur Kennungen, die ein Schema tragen. Ein schemeID setzen Sie nur, wenn die Kennung tatsächlich zu einem Code der Liste gehört. In CII gehört eine Parteikennung mit Schema nach ram:GlobalID, eine ohne Schema nach ram:ID.

  Im XML

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

  <cac:PartyLegalEntity>
    <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
    <cbc:CompanyID schemeID="HRB">HRB 12345</cbc:CompanyID>
  </cac:PartyLegalEntity>

  <cac:PartyLegalEntity>
    <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName>
    <cbc:CompanyID>HRB 12345</cbc:CompanyID>
  </cac:PartyLegalEntity>

  Was der Validator prüft

  UBL((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

  CII((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

• BR-DEX-06

  Schema der Artikelkennung (BT-157)

  Any scheme identifier in […] MUST be coded using one of the ISO 6523 ICD list.

  Was die Regel verlangt

  Trägt die Artikelkennung nach Standard (BT-157) ein Schema-Attribut, muss dessen Wert auf einer Extension-Rechnung aus der ISO-6523-ICD-Liste stammen — derselben wie bei BR-CL-21, ergänzt um drei Codes, die nur die XRechnung kennt: XR01, XR02 und XR03. Ohne schemeID prüft die Regel nichts. Hier ist die Extension strenger als die CIUS: dort verhindert ein falsches Schema die Annahme nicht, weil die KoSIT-Konfiguration BR-CL-21 zur Warnung herabgestuft hat — in der Extension ist BR-CL-21 nur noch ein Hinweis, BR-DEX-06 aber ein Fehler, der zur Abweisung führt.

  Warum sie ausgelöst wird

  Meist steht der Name des Nummernsystems im Attribut statt seines Codes: „GTIN“ oder „EAN“ statt 0160. Wer von der CIUS auf die Extension umstellt, sieht den Fehler deshalb womöglich zum ersten Mal — dieselbe Kennung hat die Annahme dort nicht verhindert. Ein leeres schemeID="" lässt BR-DEX-06 dagegen durch, weil an der Nahtstelle der zusammengesetzten Liste zwei Leerzeichen stehen — und BR-CL-21, das den leeren Wert bemängelt, entscheidet in der Extension nicht mit.

  Wie Sie es beheben

  Setzen Sie den Code des Nummernsystems, für eine GTIN also 0160 — in UBL als schemeID an cac:Item/cac:StandardItemIdentification/cbc:ID, in CII an ram:SpecifiedTradeProduct/ram:GlobalID. Eine hausinterne Artikelnummer ist keine Standardkennung: sie gehört ohne Schema in die Artikelnummer des Verkäufers (BT-155), in UBL nach cac:SellersItemIdentification/cbc:ID, in CII nach ram:SellerAssignedID.

  Im XML

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

  <cac:Item>
    <cbc:Name>Laserdrucker</cbc:Name>
    <cac:StandardItemIdentification>
      <cbc:ID schemeID="GTIN">04012345678901</cbc:ID>
    </cac:StandardItemIdentification>
  </cac:Item>

  <cac:Item>
    <cbc:Name>Laserdrucker</cbc:Name>
    <cac:StandardItemIdentification>
      <cbc:ID schemeID="0160">04012345678901</cbc:ID>
    </cac:StandardItemIdentification>
  </cac:Item>

  Was der Validator prüft

  UBL((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

  CII((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

• BR-DEX-07

  Schema der elektronischen Adresse (BT-34, BT-49)

  Any scheme identifier for an Endpoint Identifier in […] MUST belong to the CEF EAS code list.

  Was die Regel verlangt

  Das Schema-Attribut der elektronischen Adresse — des Verkäufers (BT-34) oder des Käufers (BT-49) — muss auf einer Extension-Rechnung einen Code aus der CEF-EAS-Liste tragen: derselben wie bei BR-CL-25, ergänzt um drei Codes, die nur die XRechnung kennt: XR01, XR02 und XR03; BR-CL-25 selbst stuft die KoSIT-Konfiguration für die Extension zum Hinweis herab. Geprüft wird nur eine Adresse, die ein schemeID trägt; dass es dasteht, verlangen BR-62 und BR-63. Verglichen wird genau: EM besteht, „em“ und „EMAIL“ bestehen nicht.

  Warum sie ausgelöst wird

  Für die Leitweg-ID als Adresse kursiert das Schema 9958 — in der Liste dieses Regelwerks steht es nicht, dort steht 0204; auch in der CIUS scheitert 9958, dort an BR-CL-25. Bei E-Mail-Adressen scheitert es an der Schreibweise: „EMAIL“, „email“ oder „SMTP“ statt EM. Ein leeres schemeID="" lässt die Regel dagegen durch, weil an der Nahtstelle der zusammengesetzten Liste zwei Leerzeichen stehen; BR-CL-25 bemängelt es, entscheidet in der Extension aber nicht mit.

  Wie Sie es beheben

  Setzen Sie den Code aus der EAS-Liste — in UBL als schemeID an cbc:EndpointID unter cac:AccountingSupplierParty/cac:Party beziehungsweise cac:AccountingCustomerParty/cac:Party, in CII an ram:URIUniversalCommunication/ram:URIID unter ram:SellerTradeParty beziehungsweise ram:BuyerTradeParty. Für eine E-Mail-Adresse ist das EM, für die Leitweg-ID 0204. Groß- und Kleinschreibung zählt.

  Im XML

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

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="9958">04011000-12345-03</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Stadtverwaltung Musterstadt</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:AccountingCustomerParty>

  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0204">04011000-12345-03</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Stadtverwaltung Musterstadt</cbc:Name>
      </cac:PartyName>
    </cac:Party>
  </cac:AccountingCustomerParty>

  Was der Validator prüft

  UBL((not(contains(normalize-space(@schemeID), ' ')) and contains($CEF-EAS-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $CEF-EAS-EXT-CODES

  concat($DIGA-CODES, $CEF-EAS-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $CEF-EAS-CODES

  '0002 0007 0009 0037 0060 0088 0096 0097 0106 0130 …'104 Werte

  CII((not(contains(normalize-space(@schemeID), ' ')) and contains($CEF-EAS-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $CEF-EAS-EXT-CODES

  concat($DIGA-CODES, $CEF-EAS-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $CEF-EAS-CODES

  '0002 0007 0009 0037 0060 0088 0096 0097 0106 0130 …'104 Werte

• BR-DEX-08

  Schema der Lieferort-Kennung (BT-71)

  Any scheme identifier for a Delivery location identifier in […] MUST be coded using one of the ISO 6523 ICD list.

  Was die Regel verlangt

  Trägt die Kennung des Lieferorts (BT-71) ein Schema-Attribut, muss dessen Wert auf einer Extension-Rechnung aus der ISO-6523-ICD-Liste stammen — derselben wie bei BR-CL-26, ergänzt um drei Codes, die nur die XRechnung kennt: XR01, XR02 und XR03; BR-CL-26 selbst stuft die KoSIT-Konfiguration für die Extension zum Hinweis herab. Ohne schemeID prüft die Regel nichts. In CII greift sie nur an ram:GlobalID des Lieferorts auf Kopfebene, also unter ram:ApplicableHeaderTradeDelivery/ram:ShipToTradeParty.

  Warum sie ausgelöst wird

  Meist ist es die GLN eines Lagers oder einer Filiale, deren Schema als „GLN“ statt 0088 im Attribut steht: der Lieferort hat im Quellsystem oft kein eigenes Schemafeld, und das Mapping füllt das Attribut mit dem Namen der Nummer. Ein leeres schemeID="" lässt die Regel dagegen durch, weil an der Nahtstelle der zusammengesetzten Liste zwei Leerzeichen stehen; BR-CL-26 bemängelt es, entscheidet in der Extension aber nicht mit.

  Wie Sie es beheben

  Setzen Sie den Code aus der Liste, für eine GLN 0088 — in UBL als schemeID an cac:Delivery/cac:DeliveryLocation/cbc:ID, in CII an ram:ApplicableHeaderTradeDelivery/ram:ShipToTradeParty/ram:GlobalID. Ohne Schema gehört die Kennung in CII nach ram:ShipToTradeParty/ram:ID; trägt dieses Element dennoch ein schemeID, ist dafür BR-DEX-05 zuständig, nicht BR-DEX-08.

  Im XML

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

  <cac:Delivery>
    <cbc:ActualDeliveryDate>2026-08-24</cbc:ActualDeliveryDate>
    <cac:DeliveryLocation>
      <cbc:ID schemeID="GLN">4012345000016</cbc:ID>
    </cac:DeliveryLocation>
  </cac:Delivery>

  <cac:Delivery>
    <cbc:ActualDeliveryDate>2026-08-24</cbc:ActualDeliveryDate>
    <cac:DeliveryLocation>
      <cbc:ID schemeID="0088">4012345000016</cbc:ID>
    </cac:DeliveryLocation>
  </cac:Delivery>

  Was der Validator prüft

  UBL((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

  CII((not(contains(normalize-space(@schemeID), ' ')) and contains($ISO-6523-ICD-EXT-CODES, concat(' ', normalize-space(@schemeID), ' '))))

  Variablen darin

  $ISO-6523-ICD-EXT-CODES

  concat($DIGA-CODES, $ISO-6523-ICD-CODES)

  $DIGA-CODES

  ' XR01 XR02 XR03 '

  $ISO-6523-ICD-CODES

  '0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 …'243 Werte

• BR-DEX-09

  Zahlbetrag samt Zahlungen Dritter (BT-115)

  Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) - Paid amount (BT-113) + Rounding amount (BT-114) + Σ Third party payment amount (BT-DEX-002).

  Was die Regel verlangt

  Auf einer Extension-Rechnung muss der Zahlbetrag (BT-115) so aufgehen: Bruttobetrag (BT-112) minus bereits gezahlter Betrag (BT-113) plus Rundungsbetrag (BT-114) plus die Beträge aller Fremdforderungen (BG-DEX-09, je BT-DEX-002). Die Fremdforderungen erhöhen den Zahlbetrag — sie kommen hinzu, statt abgezogen zu werden. In die Summe geht jedes cac:PrepaidPayment der Rechnung ein.

  Warum sie ausgelöst wird

  Der UBL-Name cac:PrepaidPayment klingt nach Vorauszahlung. Wer die Gruppe so behandelt und den Betrag vom Zahlbetrag abzieht, statt ihn zu addieren, liegt um den doppelten Betrag daneben. Steht dort eine Anzahlung des Käufers, die zugleich als BT-113 abgezogen wird, heben sich beide Einträge auf, und BR-DEX-09 erwartet den Zahlbetrag, als wäre nichts gezahlt; wird die Fremdforderung zusätzlich als Rechnungsposition geführt, steckt sie schon in BT-112 und zählt doppelt. BR-CO-16 läuft auf der Extension weiter, kennt BT-DEX-002 nicht und schlägt an, sobald die Fremdforderungen in Summe nicht null sind — die KoSIT-Konfiguration stuft es dort zur Information herab. Ohne Fremdforderungen prüfen beide dieselbe Summe, und ein falscher Zahlbetrag erscheint unter beiden Codes.

  Wie Sie es beheben

  Leiten Sie BT-115 aus den übrigen Beträgen ab: BT-112 − BT-113 + BT-114 + Summe aller BT-DEX-002. Der Zahlbetrag steht in cac:LegalMonetaryTotal/cbc:PayableAmount, die Fremdforderungen in cac:PrepaidPayment/cbc:PaidAmount direkt unter dem Wurzelelement; eine Anzahlung des Käufers gehört allein in cbc:PrepaidAmount (BT-113), die Fremdforderung selbst nicht in die Positionen. BR-CO-16 lässt sich daneben nicht erfüllen, solange die Fremdforderungen in Summe nicht null sind — die beiden Formeln schließen sich dann aus. Die Regel gibt es nur in UBL: in CII sieht die Extension keine Fremdforderungen vor, und BR-CO-16 bleibt dort ein Fehler.

  Im XML

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

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>
  <cac:LegalMonetaryTotal>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1170.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>
  <cac:LegalMonetaryTotal>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1210.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>

  Was der Validator prüft

  UBL(round((xs:decimal(cbc:PayableAmount) - $payableroundingamount) * 10 * 10) div 100) = (round((xs:decimal(cbc:TaxInclusiveAmount) - $prepaidamount + $thirdpartyprepaidamount) * 10 * 10) div 100)

  Variablen darin

  $payableroundingamount

  if (exists(cbc:PayableRoundingAmount)) then (xs:decimal(cbc:PayableRoundingAmount)) else (0)

  $prepaidamount

  if (exists(cbc:PrepaidAmount)) then (xs:decimal(cbc:PrepaidAmount)) else (0)

  $thirdpartyprepaidamount

  if (exists(../cac:PrepaidPayment/cbc:PaidAmount[boolean(normalize-space(xs:string(.)))])) then (sum(../cac:PrepaidPayment/xs:decimal(cbc:PaidAmount))) else (0)

• BR-DEX-10

  Art der Zahlung durch Dritte (BT-DEX-001)

  Das Element "Third party payment type" BT-DEX-001 muss übermittelt werden, wenn die Gruppe "THIRD PARTY PAYMENT" (BG-DEX-09) übermittelt wird.

  Was die Regel verlangt

  Jede Fremdforderung (Gruppe BG-DEX-09, in UBL cac:PrepaidPayment) muss ihre Art nennen: BT-DEX-001, abgebildet auf cac:PrepaidPayment/cbc:ID. Geprüft wird nur, dass das Element vorhanden ist und mehr als Leerzeichen enthält; welche Art dort steht, prüft der Ausdruck nicht. Die Regel greift nur, wenn BT-24 die Extension ausweist.

  Warum sie ausgelöst wird

  Das UBL-Schema erlaubt, jedes Kind von cac:PrepaidPayment wegzulassen; erst die Extension macht aus der Gruppe eine Fremdforderung mit drei Pflichtfeldern. Ein Generator, der cac:PrepaidPayment als gewöhnliche Vorauszahlung behandelt — so klingt der Name —, schreibt darin nur den Betrag. Dass ausgerechnet cbc:ID die Art der Forderung trägt, verrät der Elementname nicht. Ein leeres cbc:ID meldet neben BR-DEX-10 auch PEPPOL-EN16931-R008, das leere Elemente grundsätzlich verbietet.

  Wie Sie es beheben

  Tragen Sie die Art der Fremdforderung in cac:PrepaidPayment/cbc:ID ein, als erstes Kind der Gruppe vor cbc:PaidAmount. Die Prüfung verlangt keinen bestimmten Wert, nur einen nicht leeren; welche Angabe Ihr Empfänger erwartet, klären Sie mit ihm. Ist der Betrag in Wahrheit eine Anzahlung des Käufers, gehört er nicht in cac:PrepaidPayment, sondern als BT-113 in cac:LegalMonetaryTotal/cbc:PrepaidAmount — dann entfallen BR-DEX-10 bis BR-DEX-14 ganz. Die Regel gibt es nur in UBL.

  Im XML

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

  <cac:PrepaidPayment>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  Was der Validator prüft

  UBLcbc:ID[boolean(normalize-space(xs:string(.)))]

• BR-DEX-11

  Betrag der Zahlung durch Dritte (BT-DEX-002)

  Das Element "Third party payment amount" BT-DEX-002 muss übermittelt werden, wenn die Gruppe "THIRD PARTY PAYMENT" (BG-DEX-09) übermittelt wird.

  Was die Regel verlangt

  Jede Fremdforderung (BG-DEX-09) muss ihren Betrag nennen: BT-DEX-002 in cac:PrepaidPayment/cbc:PaidAmount. Geprüft wird, dass das Element vorhanden und nicht leer ist — praktisch also, dass es vorhanden ist: ein leeres cbc:PaidAmount scheitert schon am Schema, das dort eine Dezimalzahl verlangt.

  Warum sie ausgelöst wird

  Die Gruppe wird angelegt, der Betrag aber anderswo geführt — etwa als eigene Rechnungsposition —, oder der Serialisierer lässt das Element weg, weil kein Wert vorliegt. Mit cbc:PaidAmount fehlt auch sein Attribut currencyID, und so meldet sich BR-DEX-14 gleich mit: der Währungsvergleich mit BT-5 findet nichts, was er vergleichen könnte. Ein Betrag von 0.00 besteht die Prüfung dagegen.

  Wie Sie es beheben

  Schreiben Sie den Bruttobetrag der Forderung in cac:PrepaidPayment/cbc:PaidAmount, zwischen cbc:ID und cbc:InstructionID, mit currencyID in der Rechnungswährung (BR-DEX-14) und höchstens zwei Nachkommastellen (BR-DEX-13). Rechnen Sie ihn in den Zahlbetrag BT-115 ein, wie BR-DEX-09 es verlangt. Gibt es keine Fremdforderung, lassen Sie die ganze Gruppe weg statt nur den Betrag. Die Regel gibt es nur in UBL.

  Im XML

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

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  Was der Validator prüft

  UBLcbc:PaidAmount[boolean(normalize-space(xs:string(.)))]

• BR-DEX-12

  Beschreibung der Zahlung durch Dritte (BT-DEX-003)

  Das Element "Third party payment description" BT-DEX-003 muss übermittelt werden, wenn die Gruppe "THIRD PARTY PAYMENT" (BG-DEX-09) übermittelt wird.

  Was die Regel verlangt

  Jede Fremdforderung (BG-DEX-09) braucht eine Beschreibung: BT-DEX-003, abgebildet auf cac:PrepaidPayment/cbc:InstructionID. Geprüft wird nur, dass das Element vorhanden ist und mehr als Leerzeichen enthält; ob zwei Gruppen dieselbe Beschreibung tragen, prüft der Ausdruck nicht.

  Warum sie ausgelöst wird

  Dass eine Beschreibung in ein Element namens InstructionID gehört, legt der Name nicht nahe, und cac:PrepaidPayment kennt kein Element namens Description oder Note, das den Weg wiese — so bleibt die Beschreibung beim Mapping liegen. Ein leeres cbc:InstructionID meldet neben BR-DEX-12 auch PEPPOL-EN16931-R008.

  Wie Sie es beheben

  Tragen Sie eine kurze Beschreibung in cac:PrepaidPayment/cbc:InstructionID ein — als letztes der drei Felder, hinter cbc:PaidAmount, sonst scheitert schon das Schema an der Reihenfolge. Geben Sie bei mehreren Fremdforderungen jeder eine eigene Beschreibung, auch wenn die Prüfung das nicht erzwingt. Die Regel gibt es nur in UBL.

  Im XML

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

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
  </cac:PrepaidPayment>

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  Was der Validator prüft

  UBLcbc:InstructionID[boolean(normalize-space(xs:string(.)))]

• BR-DEX-13

  Nachkommastellen dieses Betrags (BT-DEX-002)

  Die maximale Anzahl zulässiger Nachkommastellen für das Element "Third party payment amount" (BT-DEX-002) ist 2.

  Was die Regel verlangt

  Der Betrag einer Fremdforderung (BT-DEX-002, cac:PrepaidPayment/cbc:PaidAmount) darf höchstens zwei Nachkommastellen tragen. Gezählt wird wie bei den BR-DEC-Regeln: die Zeichen hinter dem Punkt, nicht der Wert — 100.000 fällt durch, obwohl es genau hundert sind.

  Warum sie ausgelöst wird

  BT-DEX-002 gehört nicht zu den einundzwanzig Beträgen der BR-DEC-Regeln, deshalb bringt die Extension eine eigene Regel mit. Überzählige Stellen entstehen beim Rechnen oder durch einen Formatierer, der Beträge mit drei oder vier Stellen schreibt. Auch Leerraum zählt mit: steht der Wert eingerückt auf einer eigenen Zeile, besteht er das Schema und fällt hier durch. In UBL meldet sich zugleich die CEN-Regel UBL-DT-01, die dieselbe Zählung für jedes Betragselement außer den Preisen vornimmt — drei Nachkommastellen erscheinen also unter zwei Codes.

  Wie Sie es beheben

  Runden Sie den Betrag beim Schreiben auf zwei Nachkommastellen — 19.96 statt 19.955 — und geben Sie ihn ohne umgebenden Leerraum aus. Leiten Sie den Zahlbetrag BT-115 aus dem gerundeten Wert ab: BR-DEX-09 rechnet mit dem Betrag, der im Dokument steht. Die Regel gibt es nur in UBL.

  Im XML

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

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">19.955</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">19.96</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  Was der Validator prüft

  UBLstring-length(substring-after(cbc:PaidAmount, '.')) <= 2

• BR-DEX-14

  Währung dieses Betrags (BT-DEX-002)

  Die Währungsangabe von "Third party payment amount" BT-DEX-002 muss BT-5 ("Invoice currency code") entsprechen.

  Was die Regel verlangt

  Der Betrag einer Fremdforderung (BT-DEX-002) muss in der Rechnungswährung angegeben sein: das Attribut currencyID an cac:PrepaidPayment/cbc:PaidAmount muss dem Code der Rechnungswährung gleichen (BT-5, cbc:DocumentCurrencyCode). Verglichen wird Zeichen für Zeichen — „eur“ ist nicht „EUR“.

  Warum sie ausgelöst wird

  Die Währung wird am Betrag fest eingetragen — etwa EUR —, während die Rechnung in einer anderen Währung läuft, oder sie wird mit dem Betrag aus den Daten des Dritten übernommen. Fehlt cbc:PaidAmount ganz, meldet sich BR-DEX-14 zusammen mit BR-DEX-11: ohne Element gibt es kein Attribut, und der Vergleich mit BT-5 scheitert.

  Wie Sie es beheben

  Setzen Sie currencyID an cac:PrepaidPayment/cbc:PaidAmount auf denselben Code wie cbc:DocumentCurrencyCode. Lautet die Forderung des Dritten auf eine andere Währung, rechnen Sie sie vorher in die Rechnungswährung um — eine zweite Währung lässt die Prüfung für BT-DEX-002 nicht zu. Die Regel gibt es nur in UBL.

  Im XML

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

  <cbc:DocumentCurrencyCode>CHF</cbc:DocumentCurrencyCode>
  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="EUR">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  <cbc:DocumentCurrencyCode>CHF</cbc:DocumentCurrencyCode>
  <cac:PrepaidPayment>
    <cbc:ID>Drittanbieterleistung</cbc:ID>
    <cbc:PaidAmount currencyID="CHF">20.00</cbc:PaidAmount>
    <cbc:InstructionID>Drittanbieter-Abo August 2026</cbc:InstructionID>
  </cac:PrepaidPayment>

  Was der Validator prüft

  UBLcbc:PaidAmount/@currencyID = parent::node()/cbc:DocumentCurrencyCode

• BR-DEX-15

  Unterpositionen in CII, die XRechnung nicht kennt

  This CII file might use the concept of Sub Invoice Lines. However XRechnung does not support this.Warnung

  Was die Regel verlangt

  Eine CII-Rechnung, die sich in BT-24 als Extension ausweist, soll kein ram:ParentLineID enthalten — das Element, mit dem eine Position auf eine übergeordnete verweist. Unterpositionen kennt die Extension nur in UBL — BR-DEX-02 und BR-DEX-03 gibt es nur dort. BR-DEX-15 ist eine Warnung, die Rechnung wird deswegen nicht abgewiesen.

  Warum sie ausgelöst wird

  Naheliegende Quelle ist ein Generator für ZUGFeRD/Factur-X EXTENDED, wo ram:ParentLineID zusammen mit ram:LineStatusReasonCode (GROUP, DETAIL, INFORMATION) Positionen zu einer Hierarchie verbindet, und der dieselbe Struktur in die XRechnung schreibt. Der Ausdruck prüft je Position, sucht aber mit //ram:ParentLineID im ganzen Dokument: ein einziger Verweis bringt die Warnung an jede Position der Rechnung, auch an die ohne. Auf einer gewöhnlichen XRechnung in CII meldet das Element dagegen gar keine Regel — die CEN-Regel CII-SR-036 sucht es direkt unter der Position, wo das Schema es nicht zulässt, und schlägt deshalb nie an.

  Wie Sie es beheben

  Brauchen Sie Unterpositionen, liefern Sie die Extension in UBL: dort trägt cac:InvoiceLine untergeordnete cac:SubInvoiceLine-Gruppen, für die BR-DEX-02 und BR-DEX-03 gelten. Bleiben Sie bei CII, entfernen Sie ram:ParentLineID aus ram:AssociatedDocumentLineDocument — für XRechnung sind die Positionen ohnehin gleichrangig, BR-CO-10 summiert jede einzelne. Eine Nummerierung wie 1.1 in der Positionskennung (BT-126) darf bleiben; nur der Verweis muss weg.

  Im XML

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

  <ram:IncludedSupplyChainTradeLineItem>
    <ram:AssociatedDocumentLineDocument>
      <ram:LineID>1</ram:LineID>
    </ram:AssociatedDocumentLineDocument>
  </ram:IncludedSupplyChainTradeLineItem>
  <ram:IncludedSupplyChainTradeLineItem>
    <ram:AssociatedDocumentLineDocument>
      <ram:LineID>1.1</ram:LineID>
      <ram:ParentLineID>1</ram:ParentLineID>
    </ram:AssociatedDocumentLineDocument>
  </ram:IncludedSupplyChainTradeLineItem>

  <ram:IncludedSupplyChainTradeLineItem>
    <ram:AssociatedDocumentLineDocument>
      <ram:LineID>1</ram:LineID>
    </ram:AssociatedDocumentLineDocument>
  </ram:IncludedSupplyChainTradeLineItem>
  <ram:IncludedSupplyChainTradeLineItem>
    <ram:AssociatedDocumentLineDocument>
      <ram:LineID>1.1</ram:LineID>
    </ram:AssociatedDocumentLineDocument>
  </ram:IncludedSupplyChainTradeLineItem>

  Was der Validator prüft

  CIInot(exists(//ram:ParentLineID))