Die Kernregeln der EN 16931 — welche Angaben eine Rechnung tragen muss
Die BR-Familie ist die Grundschicht der EN 16931: sie prüft nicht, ob Ihre Zahlen stimmen, sondern ob die Felder überhaupt da sind, die eine Rechnung nach europäischem Recht ausmachen.
59 Regeln · 59 erklärt · Regelwerk v2026-08-31
Warum fast jeder BR-Fehler dieselbe Ursache hat
Diese Regeln fallen praktisch nie einzeln aus. Wer eine bestehende PDF-Rechnungsvorlage in ein XML-Mapping überführt, hat für die Felder, die auf dem Papier nie sichtbar waren, auch keine Quelle im System — und bekommt dann fünf oder zehn BR-Meldungen auf einmal.
Der schnellste Weg ist deshalb nicht, sie der Reihe nach abzuarbeiten, sondern das Mapping einmal gegen die Pflichtfeldliste zu legen. Die Felder, die dabei auffallen, sind fast immer dieselben: BT-24 (Spezifikationskennung), BT-3 (Rechnungstyp), BT-5 (Währung) und die Steuerangaben des Verkäufers.
Was diese Regeln nicht prüfen
Eine Rechnung, die alle BR-Regeln besteht, ist formal vollständig und kann trotzdem inhaltlich falsch sein: der falsche Steuersatz, die falsche Leistungsbeschreibung, der falsche Empfänger. Das BMF-Schreiben vom 15. Oktober 2025 nennt das eine eigene Fehlerklasse, und keine technische Prüfung erkennt sie.
Umgekehrt gilt: BR-Verstöße sind umsatzsteuerlich nur relevant, soweit sie eine Pflichtangabe betreffen. Eine fehlende Spezifikationskennung macht das Dokument technisch unbrauchbar, sagt aber nichts über den Vorsteuerabzug.
Alle Kernregeln
Mit dem offiziellen Regeltext. Regeln mit ausgeschriebener Erklärung tragen Ursache und Behebung direkt darunter.
BR-01
Spezifikationskennung (BT-24) fehlt
An Invoice shall have a Specification identifier (BT-24).
- Was die Regel verlangt
- Die Rechnung muss eine Spezifikationskennung (BT-24) tragen. Sie sagt dem Empfänger, nach welchem Regelwerk die Rechnung aufgebaut ist.
- Warum sie ausgelöst wird
- Zwei Ursachen, und die zweite ist die unangenehmere. Entweder fehlt das Feld ganz — es war auf keiner Papierrechnung je sichtbar, also gibt es im Quellsystem nichts, was es füllen könnte. Oder es steht eine Kennung aus einer älteren Vorlage darin: dann wird die Rechnung gegen ein Regelwerk geprüft, das Sie nicht gemeint haben, und die Fundstellen passen zu nichts.
- Wie Sie es beheben
- Setzen Sie BT-24 auf die Kennung der Fassung, die Sie tatsächlich erzeugen. Für XRechnung 3.0 ist das urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 — der Namensraum lautet xeinkauf.de. Für eine reine EN-16931-Rechnung ohne nationale Ausprägung genügt urn:cen.eu:en16931:2017. Kennungen früherer Fassungen sehen fast gleich aus und unterscheiden sich nur in Namensraum und Versionsnummer, weshalb eine übernommene alte Kennung beim Lesen kaum auffällt: vergleichen Sie zeichenweise. In UBL steht der Wert in cbc:CustomizationID, in CII in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID.
- Was der Validator prüft
UBLnormalize-space(cbc:CustomizationID) != ''CIInormalize-space(rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate> <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>Korrigiert <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID> <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate> <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>BR-02
Rechnungsnummer (BT-1) fehlt
An Invoice shall have an Invoice number (BT-1).
- Was die Regel verlangt
- Die Rechnung muss eine Rechnungsnummer (BT-1) tragen — die Kennung, unter der der Empfänger sie bucht, bezahlt und referenziert. Mahnung, Gutschrift und Zahlungsavis zeigen später auf diese Nummer zurück.
- Warum sie ausgelöst wird
- In der Praxis fast immer ein Mapping-Fehler: Das Feld heißt intern anders und wird beim Export nicht befüllt, oder die Nummer wird erst nach dem Export vergeben.
- Wie Sie es beheben
- Befüllen Sie BT-1 mit Ihrer Rechnungsnummer, bevor Sie das Dokument erzeugen. In UBL ist das cbc:ID auf Dokumentebene, in CII ram:ID im ExchangedDocument. Achten Sie dabei auf den Datentyp: BT-1 ist Text, keine Zahl. Wer die Nummer unterwegs durch ein Zahlenfeld schickt, verliert führende Nullen — aus „RE-0042“ wird 42, und die Rechnung trägt eine Nummer, die in Ihrer Buchhaltung nicht existiert. Keine Regel prüft das: BR-02 ist die einzige Regel im Regelwerk, die BT-1 überhaupt erwähnt, und sie prüft nur, dass das Feld nicht leer ist. Auffallen wird es erst beim Abgleich.
- Was der Validator prüft
UBLnormalize-space(cbc:ID) != ''CIInormalize-space(rsm:ExchangedDocument/ram:ID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID> <cbc:IssueDate>2026-08-26</cbc:IssueDate>Korrigiert <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID> <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate>BR-03
Rechnungsdatum (BT-2) fehlt
An Invoice shall have an Invoice issue date (BT-2).
- Was die Regel verlangt
- Die Rechnung muss ein Rechnungsdatum (BT-2) tragen — das Datum der Ausstellung, nicht das der Leistung und nicht das der Übermittlung.
- Warum sie ausgelöst wird
- Meist ein Formatproblem statt eines fehlenden Werts, und es wirkt je Syntax verschieden. In UBL prüft BR-03 nur, dass das Feld nicht leer ist; einen Zeitstempel statt eines Datums weist das Schema zurück, nicht diese Regel. In CII greift BR-03 selbst.
- Wie Sie es beheben
- Übermitteln Sie BT-2 in UBL als JJJJ-MM-TT. In CII schreiben Sie den Wert achtstellig und setzen am udt:DateTimeString das Attribut format="102" — der Ausdruck von BR-03 sucht genau dieses Element, und steht dort etwa 610, findet er nichts und meldet ein fehlendes Rechnungsdatum. Es ist dann nicht nur die Warnung BR-TMP-7, die anschlägt: die Rechnung wird abgewiesen.
- Was der Validator prüft
UBLnormalize-space(cbc:IssueDate) != ''CIInormalize-space(rsm:ExchangedDocument/ram:IssueDateTime/udt:DateTimeString[@format='102']) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>26.08.2026</cbc:IssueDate>Korrigiert <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate>BR-04
An Invoice shall have an Invoice type code (BT-3).
- Was die Regel verlangt
- Die Rechnung muss einen Rechnungstyp (BT-3) tragen — den Code, der sagt, ob es sich um eine Rechnung, eine Gutschrift oder eine Abschlagsrechnung handelt.
- Warum sie ausgelöst wird
- Der Belegtyp ist im Quellsystem oft ein hausinternes Kürzel, für das es im Mapping keine Zuordnung gibt. Fehlt die Zuordnung, wird lieber nichts geschrieben als etwas Falsches.
- Wie Sie es beheben
- Setzen Sie BT-3 auf einen UNTDID-1001-Code — 380 für die Handelsrechnung, 384 für die Korrektur: cbc:InvoiceTypeCode in UBL, ram:TypeCode in CII. Die 381 für die Gutschrift ist der Sonderfall: in CII steht sie im selben ram:TypeCode, in UBL lässt BR-CL-01 sie nur in cbc:CreditNoteTypeCode zu — eine Gutschrift ist dort ein eigenes CreditNote-Dokument. Zur Auswahl der zulässigen Codes siehe BR-DE-17.
- Was der Validator prüft
UBLnormalize-space(cbc:InvoiceTypeCode) != '' or normalize-space(cbc:CreditNoteTypeCode) !=''CIInormalize-space(rsm:ExchangedDocument/ram:TypeCode) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate>Korrigiert <cbc:ID>RE-2026-0042</cbc:ID> <cbc:IssueDate>2026-08-26</cbc:IssueDate> <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>BR-05
An Invoice shall have an Invoice currency code (BT-5).
- Was die Regel verlangt
- Die Rechnung muss eine Rechnungswährung (BT-5) nennen. Jeder Betrag im Dokument wird in dieser Währung gelesen.
- Warum sie ausgelöst wird
- Ein Unternehmen, das nur in Euro fakturiert, führt die Währung nirgends als Feld — sie ist im Layout eingedruckt. Im strukturierten Datensatz fehlt sie dann vollständig.
- Wie Sie es beheben
- Setzen Sie BT-5 auf den ISO-4217-Code, für den deutschen Markt EUR: cbc:DocumentCurrencyCode in UBL, ram:InvoiceCurrencyCode in CII. Die Beträge tragen zusätzlich ihr eigenes currencyID-Attribut, das dazu passen muss.
- Was der Validator prüft
UBLnormalize-space(cbc:DocumentCurrencyCode) != ''CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>Korrigiert <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>BR-06
An Invoice shall contain the Seller name (BT-27).
- Was die Regel verlangt
- Die Rechnung muss den Namen des Verkäufers (BT-27) enthalten — den vollständigen eingetragenen Namen, unter dem das Unternehmen firmiert.
- Warum sie ausgelöst wird
- Der Absender steht im Briefkopf, nicht in den Rechnungsdaten: er ist für jede Rechnung gleich und wird deshalb im Layout gepflegt statt im Datensatz. Beim Erzeugen des XML fällt er heraus.
- Wie Sie es beheben
- Setzen Sie den eingetragenen Namen in BT-27: cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName in UBL, ram:SellerTradeParty/ram:Name in CII. Der Handelsname gehört, falls abweichend, zusätzlich in BT-28.
- Was der Validator prüft
UBLnormalize-space(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) != ''CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AccountingSupplierParty> <cac:Party> <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> </cac:PostalAddress> </cac:Party> </cac:AccountingSupplierParty>Korrigiert <cac:AccountingSupplierParty> <cac:Party> <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> </cac:PostalAddress> <cac:PartyLegalEntity> <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingSupplierParty>BR-07
Name des Käufers (BT-44) fehlt
An Invoice shall contain the Buyer name (BT-44).
- Was die Regel verlangt
- Die Rechnung muss den Namen des Käufers (BT-44) enthalten — den Namen, unter dem der Empfänger die Rechnung erwartet.
- Warum sie ausgelöst wird
- Im Debitorenstamm stehen oft mehrere Namensfelder: Anzeigename, Suchbegriff, Rechnungsempfänger. Das Mapping greift auf ein Feld zu, das bei manchen Kunden leer ist, weil es nur für die Suche gepflegt wird.
- Wie Sie es beheben
- Setzen Sie BT-44 auf den Namen des Rechnungsempfängers: cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName in UBL, ram:BuyerTradeParty/ram:Name in CII. Der Handelsname des Käufers gehört, falls abweichend, zusätzlich in BT-45 — cac:PartyName/cbc:Name. Nur dort gesetzt, bleibt BT-44 leer, und BR-07 meldet weiter einen fehlenden Namen, obwohl im XML einer steht.
- Was der Validator prüft
UBLnormalize-space(cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) != ''CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:Name) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AccountingCustomerParty> <cac:Party> <cac:PostalAddress> <cbc:CityName>Bonn</cbc:CityName> </cac:PostalAddress> </cac:Party> </cac:AccountingCustomerParty>Korrigiert <cac:AccountingCustomerParty> <cac:Party> <cac:PostalAddress> <cbc:CityName>Bonn</cbc:CityName> </cac:PostalAddress> <cac:PartyLegalEntity> <cbc:RegistrationName>Behörde Bonn</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingCustomerParty>BR-08
Anschrift des Verkäufers (BG-5) fehlt
An Invoice shall contain the Seller postal address.
Wortlaut in CII
An Invoice shall contain the Seller postal address (BG-5).
- Was die Regel verlangt
- Die Rechnung muss die Postanschrift des Verkäufers (BG-5) enthalten — die Gruppe, in der Straße, Ort, Postleitzahl und Land stehen.
- Warum sie ausgelöst wird
- Dieselbe Ursache wie beim Namen: die eigene Anschrift ist Teil des Layouts. Manchmal wird auch nur ein einzelnes Adressfeld gemappt, ohne die umgebende Gruppe anzulegen.
- Wie Sie es beheben
- Legen Sie cac:AccountingSupplierParty/cac:Party/cac:PostalAddress an (in CII ram:SellerTradeParty/ram:PostalTradeAddress). Ort und Postleitzahl verlangt zusätzlich BR-DE-3 und BR-DE-4, das Land BR-09. Die Straße selbst (BT-35) verlangt keine Regel des Regelwerks: eine Verkäuferadresse aus Ort, Postleitzahl und Land geht durch, auch wenn keine Straße darin steht.
- Was der Validator prüft
UBLexists(cac:AccountingSupplierParty/cac:Party/cac:PostalAddress)CIIrsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Party> <cac:PartyLegalEntity> <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party>Korrigiert <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:PartyLegalEntity> <cbc:RegistrationName>Muster GmbH</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party>BR-09
The Seller postal address (BG-5) shall contain a Seller country code (BT-40).
- Was die Regel verlangt
- Die Postanschrift des Verkäufers muss ein Länderkennzeichen (BT-40) enthalten — den zweistelligen ISO-3166-1-Code, nicht den ausgeschriebenen Ländernamen.
- Warum sie ausgelöst wird
- Adressen liegen in vielen Systemen als mehrzeiliger Freitext vor, in dem das Land die letzte Zeile ist. Beim Zerlegen in Einzelfelder bleibt genau diese Zeile übrig, weil sie keinen Code trägt.
- Wie Sie es beheben
- Übersetzen Sie das Land einmalig in den ISO-Code und setzen Sie ihn in BT-40: cac:PostalAddress/cac:Country/cbc:IdentificationCode in UBL, ram:PostalTradeAddress/ram:CountryID in CII. DE, nicht Deutschland.
- Was der Validator prüft
UBLnormalize-space(cac:Country/cbc:IdentificationCode) != ''CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> <cbc:PostalZone>10115</cbc:PostalZone> <cac:Country> <cbc:IdentificationCode>Deutschland</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress>Korrigiert <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> <cbc:PostalZone>10115</cbc:PostalZone> <cac:Country> <cbc:IdentificationCode>DE</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress>BR-10
An Invoice shall contain the Buyer postal address (BG-8).
- Was die Regel verlangt
- Die Rechnung muss die Postanschrift des Käufers (BG-8) enthalten — das Gegenstück zu BG-5 auf der Empfängerseite.
- Warum sie ausgelöst wird
- Bei Behördenrechnungen wird die Anschrift für verzichtbar gehalten, weil die Leitweg-ID die Zustellung ohnehin steuert. Die Norm verlangt die Anschrift dennoch: sie identifiziert den Leistungsempfänger, nicht den Zustellweg.
- Wie Sie es beheben
- Legen Sie cac:AccountingCustomerParty/cac:Party/cac:PostalAddress an (CII: ram:BuyerTradeParty/ram:PostalTradeAddress). Ort und Postleitzahl fordern zusätzlich BR-DE-8 und BR-DE-9, das Land BR-11.
- Was der Validator prüft
UBLexists(cac:AccountingCustomerParty/cac:Party/cac:PostalAddress)CIIrsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AccountingCustomerParty> <cac:Party> <cac:PartyLegalEntity> <cbc:RegistrationName>Behörde Bonn</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingCustomerParty>Korrigiert <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:PartyLegalEntity> <cbc:RegistrationName>Behörde Bonn</cbc:RegistrationName> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingCustomerParty>BR-11
The Buyer postal address shall contain a Buyer country code (BT-55).
- Was die Regel verlangt
- Die Postanschrift des Käufers muss ein Länderkennzeichen (BT-55) enthalten — dieselbe Anforderung wie BR-09, auf der Empfängerseite.
- Warum sie ausgelöst wird
- Bei rein inländischen Kunden wird das Land im Debitorenstamm häufig gar nicht gepflegt, weil es sich von selbst versteht. Was sich von selbst versteht, steht in keinem Feld.
- Wie Sie es beheben
- Setzen Sie den ISO-3166-1-Code in BT-55: cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode in UBL, ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID in CII. Ein Standardwert im Mapping ist hier vertretbar.
- Was der Validator prüft
UBLnormalize-space(cac:Country/cbc:IdentificationCode) != ''CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PostalAddress> <cbc:CityName>Bonn</cbc:CityName> <cbc:PostalZone>53113</cbc:PostalZone> </cac:PostalAddress>Korrigiert <cac:PostalAddress> <cbc:CityName>Bonn</cbc:CityName> <cbc:PostalZone>53113</cbc:PostalZone> <cac:Country> <cbc:IdentificationCode>DE</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress>BR-12
An Invoice shall have the Sum of Invoice line net amount (BT-106).
- Was die Regel verlangt
- Die Rechnung muss die Summe der Positionsnettobeträge (BT-106) enthalten. Die Norm verlangt jeden der Summenwerte ausdrücklich — keiner darf aus den übrigen erschlossen werden.
- Warum sie ausgelöst wird
- Der Wert ist im eigenen Rechnungsobjekt selten ein Feld: er ergibt sich aus den Positionen und wird beim Anzeigen berechnet. Im Dokument muss er aber ausgeschrieben stehen.
- Wie Sie es beheben
- Schreiben Sie BT-106 in cac:LegalMonetaryTotal/cbc:LineExtensionAmount (UBL) beziehungsweise ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:LineTotalAmount (CII). Wie der Wert zu den anderen Summen passen muss, steht in BR-CO-10 bis BR-CO-16.
- Was der Validator prüft
UBLexists(cbc:LineExtensionAmount)CII(ram:LineTotalAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:LegalMonetaryTotal> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>Korrigiert <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>BR-13
An Invoice shall have the Invoice total amount without VAT (BT-109).
- Was die Regel verlangt
- Die Rechnung muss den Gesamtbetrag ohne Umsatzsteuer (BT-109) enthalten. Die Norm verlangt jeden der Summenwerte ausdrücklich — keiner darf aus den übrigen erschlossen werden.
- Warum sie ausgelöst wird
- Wer keine Rabatte oder Zuschläge auf Dokumentebene kennt, hält den Betrag für identisch mit der Positionssumme und schreibt nur einen von beiden.
- Wie Sie es beheben
- Schreiben Sie BT-109 in cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount (UBL) beziehungsweise ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:TaxBasisTotalAmount (CII). Wie der Wert zu den anderen Summen passen muss, steht in BR-CO-10 bis BR-CO-16.
- Was der Validator prüft
UBLexists(cbc:TaxExclusiveAmount)CII(ram:TaxBasisTotalAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>Korrigiert <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>BR-14
An Invoice shall have the Invoice total amount with VAT (BT-112).
- Was die Regel verlangt
- Die Rechnung muss den Gesamtbetrag mit Umsatzsteuer (BT-112) enthalten. Die Norm verlangt jeden der Summenwerte ausdrücklich — keiner darf aus den übrigen erschlossen werden.
- Warum sie ausgelöst wird
- Der Bruttobetrag steht in der PDF-Darstellung ganz unten und wird dort formatiert erzeugt, nicht als Datenfeld geführt. Beim Mapping fehlt er deshalb.
- Wie Sie es beheben
- Schreiben Sie BT-112 in cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount (UBL) beziehungsweise ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:GrandTotalAmount (CII). Wie der Wert zu den anderen Summen passen muss, steht in BR-CO-10 bis BR-CO-16.
- Was der Validator prüft
UBLexists(cbc:TaxInclusiveAmount)CII(ram:GrandTotalAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>Korrigiert <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>BR-15
An Invoice shall have the Amount due for payment (BT-115).
- Was die Regel verlangt
- Die Rechnung muss den fälligen Zahlbetrag (BT-115) enthalten. Die Norm verlangt jeden der Summenwerte ausdrücklich — keiner darf aus den übrigen erschlossen werden.
- Warum sie ausgelöst wird
- Bei Rechnungen ohne Anzahlung ist der Zahlbetrag gleich dem Bruttobetrag, und ein gleicher Wert wirkt redundant. Die Norm verlangt ihn trotzdem eigenständig.
- Wie Sie es beheben
- Schreiben Sie BT-115 in cac:LegalMonetaryTotal/cbc:PayableAmount (UBL) beziehungsweise ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:DuePayableAmount (CII). Wie der Wert zu den anderen Summen passen muss, steht in BR-CO-10 bis BR-CO-16.
- Was der Validator prüft
UBLexists(cbc:PayableAmount)CII(ram:DuePayableAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> </cac:LegalMonetaryTotal>Korrigiert <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount> <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>BR-16
Rechnung ohne Position (BG-25)
An Invoice shall have at least one Invoice line (BG-25)
- Was die Regel verlangt
- Die Rechnung muss mindestens eine Rechnungsposition (BG-25) enthalten — Kopf- und Summendaten allein sind keine gültige Rechnung. Auch eine Pauschale braucht eine Position.
- Warum sie ausgelöst wird
- Tritt auf, wenn der Generator Positionen nur aus einer Artikelliste erzeugt und diese leer ist — etwa bei Pauschal- oder Abschlagsrechnungen, die intern ohne Einzelpositionen geführt werden.
- Wie Sie es beheben
- Erzeugen Sie auch für Pauschalbeträge genau eine Position: cac:InvoiceLine in UBL, ram:IncludedSupplyChainTradeLineItem in CII. Die eine Position muss dann selbst vollständig sein — Positionsnummer (BR-21), Menge 1 (BR-22), Maßeinheit C62 für „Stück“ (BR-23), Nettobetrag (BR-24), Bezeichnung (BR-25) und Einzelpreis (BR-26). Wer nur die Position anlegt und die sechs Felder ausläßt, tauscht einen Fehler gegen sechs.
- Was der Validator prüft
UBLexists(cac:InvoiceLine) or exists(cac:CreditNoteLine)CII//ram:IncludedSupplyChainTradeLineItem
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal>Korrigiert <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount> </cac:LegalMonetaryTotal> <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Pauschale</cbc:Name> <cac:ClassifiedTaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:ClassifiedTaxCategory> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">1000.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-17
The Payee name (BT-59) shall be provided in the Invoice, if the Payee (BG-10) is different from the Seller (BG-4)
- Was die Regel verlangt
- Weicht der Zahlungsempfänger (BG-10) vom Verkäufer ab, muss sein Name (BT-59) übermittelt werden. Wer das Geld bekommt, darf nicht offenbleiben.
- Warum sie ausgelöst wird
- Die Gruppe wird angelegt, weil eine abweichende Bankverbindung übermittelt werden soll — etwa bei Factoring oder einer Konzerntochter, die zentral kassiert. Der Name gilt dabei als Nebensache, weil die IBAN die Zahlung ohnehin lenkt.
- Wie Sie es beheben
- Setzen Sie BT-59 in cac:PayeeParty/cac:PartyName/cbc:Name (UBL) beziehungsweise ram:PayeeTradeParty/ram:Name (CII) — oder lassen Sie die Gruppe ganz weg, wenn Verkäufer und Zahlungsempfänger dieselbe Partei sind.
- Was der Validator prüft
UBLexists(cac:PartyName/cbc:Name) and (not(cac:PartyName/cbc:Name = ../cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name) and not(cac:PartyIdentification/cbc:ID = ../cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID) )CII(ram:Name) and (not(ram:Name = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name) and not(ram:ID = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:ID) and not(ram:SpecifiedLegalOrganization/ram:ID = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedLegalOrganization/ram:ID))
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PayeeParty> <cac:PartyIdentification> <cbc:ID>FACTOR-01</cbc:ID> </cac:PartyIdentification> </cac:PayeeParty>Korrigiert <cac:PayeeParty> <cac:PartyIdentification> <cbc:ID>FACTOR-01</cbc:ID> </cac:PartyIdentification> <cac:PartyName> <cbc:Name>Muster Factoring GmbH</cbc:Name> </cac:PartyName> </cac:PayeeParty>BR-18
The Seller tax representative name (BT-62) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11)
- Was die Regel verlangt
- Hat der Verkäufer einen steuerlichen Vertreter (BG-11), muss dessen Name (BT-62) übermittelt werden.
- Warum sie ausgelöst wird
- Die Gruppe wird meist nur angelegt, um die USt-IdNr. des Vertreters unterzubringen, weil das der steuerlich relevante Teil ist. Der Name folgt nicht mit.
- Wie Sie es beheben
- Setzen Sie BT-62 in cac:TaxRepresentativeParty/cac:PartyName/cbc:Name (UBL) beziehungsweise ram:SellerTaxRepresentativeTradeParty/ram:Name (CII). Anschrift und USt-IdNr. verlangen BR-19 und BR-56.
- Was der Validator prüft
UBLnormalize-space(cac:PartyName/cbc:Name) != ''CIInormalize-space(ram:Name) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxRepresentativeParty> <cac:PartyTaxScheme> <cbc:CompanyID>DE811234567</cbc:CompanyID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:PartyTaxScheme> </cac:TaxRepresentativeParty>Korrigiert <cac:TaxRepresentativeParty> <cac:PartyName> <cbc:Name>Steuerkanzlei Muster</cbc:Name> </cac:PartyName> <cac:PartyTaxScheme> <cbc:CompanyID>DE811234567</cbc:CompanyID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:PartyTaxScheme> </cac:TaxRepresentativeParty>BR-19
The Seller tax representative postal address (BG-12) shall be provided in the Invoice, if the Seller (BG-4) has a Seller tax representative party (BG-11).
- Was die Regel verlangt
- Hat der Verkäufer einen steuerlichen Vertreter, muss dessen Postanschrift (BG-12) übermittelt werden — dieselbe Anforderung wie BR-08, für eine dritte Partei.
- Warum sie ausgelöst wird
- Der Vertreter ist im Stammdatensatz oft nur ein Name und eine Steuernummer; eine vollständige Anschrift wird für ihn nicht gepflegt, weil an ihn nichts versendet wird.
- Wie Sie es beheben
- Legen Sie cac:TaxRepresentativeParty/cac:PostalAddress an (CII: ram:SellerTaxRepresentativeTradeParty/ram:PostalTradeAddress). Das Länderkennzeichen darin fordert BR-20.
- Was der Validator prüft
UBLexists(cac:PostalAddress)CII(ram:PostalTradeAddress)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxRepresentativeParty> <cac:PartyName> <cbc:Name>Steuerkanzlei Muster</cbc:Name> </cac:PartyName> </cac:TaxRepresentativeParty>Korrigiert <cac:TaxRepresentativeParty> <cac:PartyName> <cbc:Name>Steuerkanzlei Muster</cbc:Name> </cac:PartyName> <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> <cbc:PostalZone>10115</cbc:PostalZone> <cac:Country> <cbc:IdentificationCode>DE</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress> </cac:TaxRepresentativeParty>BR-20
Steuervertreter ohne Land (BT-69)
The Seller tax representative postal address (BG-12) shall contain a Tax representative country code (BT-69), if the Seller (BG-4) has a Seller tax representative party (BG-11).
- Was die Regel verlangt
- Hat der Verkäufer einen steuerlichen Vertreter, muss dessen Anschrift ein Länderkennzeichen (BT-69) tragen — dieselbe Anforderung wie BR-09 und BR-11, für die dritte Partei.
- Warum sie ausgelöst wird
- Wie bei den anderen beiden Adressen: das Land steht als Freitext in der letzten Adresszeile oder wird als selbstverständlich gar nicht geführt.
- Wie Sie es beheben
- Setzen Sie den ISO-3166-1-Code in cac:TaxRepresentativeParty/cac:PostalAddress/cac:Country/cbc:IdentificationCode (UBL) beziehungsweise ram:PostalTradeAddress/ram:CountryID des Vertreters (CII). Haben Sie gar keinen steuerlichen Vertreter, ist das Länderkennzeichen die falsche Antwort: löschen Sie die Gruppe BG-11, dann entfallen BR-18, BR-19 und BR-20 zusammen.
- Was der Validator prüft
UBLnormalize-space(cac:Country/cbc:IdentificationCode) != ''CIInormalize-space(ram:PostalTradeAddress/ram:CountryID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxRepresentativeParty> <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> <cbc:PostalZone>10115</cbc:PostalZone> </cac:PostalAddress> </cac:TaxRepresentativeParty>Korrigiert <cac:TaxRepresentativeParty> <cac:PostalAddress> <cbc:CityName>Berlin</cbc:CityName> <cbc:PostalZone>10115</cbc:PostalZone> <cac:Country> <cbc:IdentificationCode>DE</cbc:IdentificationCode> </cac:Country> </cac:PostalAddress> </cac:TaxRepresentativeParty>BR-21
Each Invoice line (BG-25) shall have an Invoice line identifier (BT-126).
- Was die Regel verlangt
- Jede Rechnungsposition (BG-25) muss eine Positionsnummer (BT-126) tragen. Sie ist der Anker, über den der Empfänger eine einzelne Zeile bespricht oder reklamiert.
- Warum sie ausgelöst wird
- Positionen entstehen als Liste, deren Reihenfolge implizit die Nummer ist. Beim Serialisieren wird der Index nicht mitgeschrieben, weil er im Quellobjekt kein Feld war.
- Wie Sie es beheben
- Vergeben Sie eine je Rechnung eindeutige Nummer in BT-126: cbc:ID in cac:InvoiceLine (UBL), ram:AssociatedDocumentLineDocument/ram:LineID (CII). Eine fortlaufende Zahl ab 1 genügt.
- Was der Validator prüft
UBLnormalize-space(cbc:ID) != ''CIInormalize-space(ram:AssociatedDocumentLineDocument/ram:LineID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-22
Each Invoice line (BG-25) shall have an Invoiced quantity (BT-129).
- Was die Regel verlangt
- Jede Rechnungsposition muss eine berechnete Menge (BT-129) tragen — auch dann, wenn es sich um eine Pauschale handelt.
- Warum sie ausgelöst wird
- Bei Dienstleistungen und Pauschalen gibt es im Quellsystem keine Menge, nur einen Betrag. Das Feld bleibt leer, weil es inhaltlich nichts zu sagen scheint.
- Wie Sie es beheben
- Schreiben Sie bei einer Pauschale die Menge 1 und den Betrag als Einzelpreis: cbc:InvoicedQuantity in UBL, ram:BilledQuantity in CII. Die Maßeinheit dazu fordert BR-23.
- Was der Validator prüft
UBLexists(cbc:InvoicedQuantity) or exists(cbc:CreditedQuantity)CII(ram:SpecifiedLineTradeDelivery/ram:BilledQuantity)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-23
An Invoice line (BG-25) shall have an Invoiced quantity unit of measure code (BT-130).
- Was die Regel verlangt
- Die berechnete Menge muss eine Maßeinheit (BT-130) tragen — einen Code aus UN/ECE Recommendation 20, nicht das eigene Kürzel aus dem Artikelstamm.
- Warum sie ausgelöst wird
- Systeme führen Einheiten als Text: Stk, Std, kg. Der Code dazu ist eine Übersetzung, die im Mapping erst angelegt werden muss, und ohne sie bleibt das Attribut leer.
- Wie Sie es beheben
- Setzen Sie das unitCode-Attribut an cbc:InvoicedQuantity (UBL) beziehungsweise ram:BilledQuantity (CII): C62 für Stück, HUR für Stunden, KGM für Kilogramm, MTR für Meter.
- Was der Validator prüft
UBLexists(cbc:InvoicedQuantity/@unitCode) or exists(cbc:CreditedQuantity/@unitCode)CII(ram:SpecifiedLineTradeDelivery/ram:BilledQuantity/@unitCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity>10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-24
Each Invoice line (BG-25) shall have an Invoice line net amount (BT-131).
- Was die Regel verlangt
- Jede Rechnungsposition muss einen Nettobetrag (BT-131) tragen — den Betrag der Zeile ohne Umsatzsteuer.
- Warum sie ausgelöst wird
- Der Betrag wird beim Anzeigen aus Menge und Preis berechnet und deshalb nicht als eigenes Feld geführt. Im Dokument muss er aber stehen, und zwar so, dass er zur Rechnung aufgeht.
- Wie Sie es beheben
- Schreiben Sie den Zeilenbetrag in cbc:LineExtensionAmount (UBL) beziehungsweise ram:LineTotalAmount (CII). Wie er sich aus Menge, Preis und Rabatten ergeben muss, prüft PEPPOL-EN16931-R120.
- Was der Validator prüft
UBLexists(cbc:LineExtensionAmount)CII(ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-25
Artikelname (BT-153) fehlt
Each Invoice line (BG-25) shall contain the Item name (BT-153).
- Was die Regel verlangt
- Jede Rechnungsposition muss einen Artikelnamen (BT-153) tragen. Ohne ihn steht in der Zeile ein Betrag für etwas Unbenanntes.
- Warum sie ausgelöst wird
- Die Bezeichnung kommt aus einem Langtext, der leer sein darf, während die interne Artikelnummer immer belegt ist. Das Mapping greift auf den Langtext zu und findet nichts.
- Wie Sie es beheben
- Setzen Sie eine kurze Bezeichnung in cac:Item/cbc:Name (UBL) beziehungsweise ram:SpecifiedTradeProduct/ram:Name (CII). Der ausführliche Text gehört daneben in BT-154, die Artikelnummer in BT-155.
- Was der Validator prüft
UBLnormalize-space(cac:Item/cbc:Name) != ''CIInormalize-space(ram:SpecifiedTradeProduct/ram:Name) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-26
Each Invoice line (BG-25) shall contain the Item net price (BT-146).
- Was die Regel verlangt
- Jede Rechnungsposition muss einen Nettopreis (BT-146) tragen — den Preis je Einheit nach Abzug eines Preisnachlasses.
- Warum sie ausgelöst wird
- Bei Pauschalen und bei Positionen, die nur einen Gesamtbetrag kennen, wird kein Einzelpreis geführt. Die Zeile trägt dann einen Betrag, aber nichts, woraus er entstünde.
- Wie Sie es beheben
- Schreiben Sie den Einzelpreis in cac:Price/cbc:PriceAmount (UBL) beziehungsweise ram:NetPriceProductTradePrice/ram:ChargeAmount (CII). Bei einer Pauschale ist der Einzelpreis der Gesamtbetrag bei Menge 1.
- Was der Validator prüft
UBLexists(cac:Price/cbc:PriceAmount)CII(ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:ChargeAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount> <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price> </cac:InvoiceLine>BR-27
Negativer Nettopreis (BT-146)
The Item net price (BT-146) shall NOT be negative.
- Was die Regel verlangt
- Der Nettopreis einer Position darf nicht negativ sein. Ein Minus gehört in die Menge oder in eine Gutschrift, nicht in den Preis.
- Warum sie ausgelöst wird
- Stornozeilen und Rückvergütungen werden gern als negativer Preis abgebildet, weil das in der eigenen Summenrechnung sofort funktioniert. Die Norm kennt dafür andere Mittel.
- Wie Sie es beheben
- Bilden Sie eine Rückvergütung als Abschlag auf der Position ab (BG-27), oder erzeugen Sie eine Gutschrift. In CII trägt die den Typ 381 in ram:TypeCode. In UBL nicht: BR-CL-01 lässt die 381 nur in cbc:CreditNoteTypeCode zu, also in einem CreditNote-Dokument — in cbc:InvoiceTypeCode gesetzt, meldet sie einen unzulässigen Code. Der Preis in cac:Price/cbc:PriceAmount bleibt in jedem Fall positiv.
- Was der Validator prüft
UBL(cac:Price/cbc:PriceAmount) >= 0CII(ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:ChargeAmount) >= 0
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Price> <cbc:PriceAmount currencyID="EUR">-100.00</cbc:PriceAmount> </cac:Price>Korrigiert <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> </cac:Price>BR-28
Negativer Bruttopreis (BT-148)
The Item gross price (BT-148) shall NOT be negative.
- Was die Regel verlangt
- Der Bruttopreis einer Position (BT-148) darf nicht negativ sein — der Listenpreis vor dem Rabatt, nicht der Nettopreis aus BR-27. Anders als dieser ist er freiwillig: wo kein Bruttopreis steht, kann BR-28 nicht auslösen.
- Warum sie ausgelöst wird
- Wer den Nettopreis negativ setzt, setzt meist auch den Bruttopreis negativ, weil beide aus derselben Quelle stammen. Die beiden Regeln melden sich deshalb fast immer gemeinsam.
- Wie Sie es beheben
- Halten Sie cac:Price/cac:AllowanceCharge/cbc:BaseAmount (UBL) beziehungsweise ram:GrossPriceProductTradePrice/ram:ChargeAmount (CII) positiv und drehen Sie das Vorzeichen dort, wo die Norm es vorsieht — siehe BR-27. Sobald ein Bruttopreis übermittelt wird, verlangt PEPPOL-EN16931-R046 außerdem, dass er aufgeht: Nettopreis = Bruttopreis − Rabatt.
- Was der Validator prüft
UBL(cac:Price/cac:AllowanceCharge/cbc:BaseAmount) >= 0 or not(exists(cac:Price/cac:AllowanceCharge/cbc:BaseAmount))CII(ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:ChargeAmount >= 0) or not(ram:SpecifiedLineTradeAgreement/ram:GrossPriceProductTradePrice/ram:ChargeAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">10.00</cbc:Amount> <cbc:BaseAmount currencyID="EUR">-110.00</cbc:BaseAmount> </cac:AllowanceCharge> </cac:Price>Korrigiert <cac:Price> <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">10.00</cbc:Amount> <cbc:BaseAmount currencyID="EUR">110.00</cbc:BaseAmount> </cac:AllowanceCharge> </cac:Price>BR-29
If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73).
- Was die Regel verlangt
- Sind Beginn und Ende des Abrechnungszeitraums angegeben, muss das Ende auf oder nach dem Beginn liegen.
- Warum sie ausgelöst wird
- Der Zeitraum wird aus zwei Feldern gefüllt, die getrennt gepflegt werden. Ein Tippfehler im Jahr, oder ein Ende, das aus dem Vormonat stehen blieb, dreht die Reihenfolge um.
- Wie Sie es beheben
- Prüfen Sie die Reihenfolge, bevor Sie cac:InvoicePeriod schreiben (CII: ram:BillingSpecifiedPeriod). Ein eintägiger Zeitraum mit identischem Beginn und Ende ist zulässig.
- Was der Validator prüft
UBL(exists(cbc:EndDate) and exists(cbc:StartDate) and xs:date(cbc:EndDate) >= xs:date(cbc:StartDate)) or not(exists(cbc:StartDate)) or not(exists(cbc:EndDate))CII(ram:EndDateTime/udt:DateTimeString[@format = '102']) >= (ram:StartDateTime/udt:DateTimeString[@format = '102']) or not (ram:EndDateTime) or not (ram:StartDateTime)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoicePeriod> <cbc:StartDate>2026-08-01</cbc:StartDate> <cbc:EndDate>2026-07-31</cbc:EndDate> </cac:InvoicePeriod>Korrigiert <cac:InvoicePeriod> <cbc:StartDate>2026-08-01</cbc:StartDate> <cbc:EndDate>2026-08-31</cbc:EndDate> </cac:InvoicePeriod>BR-30
If both Invoice line period start date (BT-134) and Invoice line period end date (BT-135) are given then the Invoice line period end date (BT-135) shall be later or equal to the Invoice line period start date (BT-134).
- Was die Regel verlangt
- Sind Beginn und Ende eines Positionszeitraums angegeben, muss das Ende auf oder nach dem Beginn liegen — dieselbe Prüfung wie BR-29, je Position.
- Warum sie ausgelöst wird
- Positionszeiträume entstehen in einer Schleife aus Vertragsdaten. Läuft ein Vertrag über den Jahreswechsel, wird das Jahr an einem der beiden Daten gern falsch berechnet.
- Wie Sie es beheben
- Prüfen Sie die Reihenfolge je Position, bevor Sie cac:InvoicePeriod innerhalb von cac:InvoiceLine schreiben. Dass der Zeitraum zusätzlich in den Rechnungszeitraum passen muss, fordern PEPPOL-EN16931-R110 und R111.
- Was der Validator prüft
UBL(exists(cbc:EndDate) and exists(cbc:StartDate) and xs:date(cbc:EndDate) >= xs:date(cbc:StartDate)) or not(exists(cbc:StartDate)) or not(exists(cbc:EndDate))CII(ram:EndDateTime/udt:DateTimeString[@format = '102']) >= (ram:StartDateTime/udt:DateTimeString[@format = '102']) or not (ram:EndDateTime) or not (ram:StartDateTime)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:InvoicePeriod> <cbc:StartDate>2026-12-01</cbc:StartDate> <cbc:EndDate>2026-01-31</cbc:EndDate> </cac:InvoicePeriod> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:InvoicePeriod> <cbc:StartDate>2026-12-01</cbc:StartDate> <cbc:EndDate>2027-01-31</cbc:EndDate> </cac:InvoicePeriod> </cac:InvoiceLine>BR-31
Each Document level allowance (BG-20) shall have a Document level allowance amount (BT-92).
- Was die Regel verlangt
- Jeder Abschlag auf Dokumentebene (BG-20) muss einen Betrag (BT-92) tragen. Ein Ab- oder Zuschlag ohne Betrag verändert nichts und gehört dann nicht ins Dokument.
- Warum sie ausgelöst wird
- Der Rabatt wird bereits in die Positionsbeträge eingerechnet und die Gruppe nur noch zur Erläuterung angelegt — mit Grund, aber ohne Betrag.
- Wie Sie es beheben
- Schreiben Sie den Betrag in cbc:Amount im cac:AllowanceCharge (UBL) beziehungsweise ram:ActualAmount im ram:SpecifiedTradeAllowanceCharge (CII). Zur Beziehung zwischen Betrag, Grundbetrag und Prozentsatz siehe PEPPOL-EN16931-R040.
- Was der Validator prüft
UBLexists(cbc:Amount)CII(../ram:ActualAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Rabatt</cbc:AllowanceChargeReason> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Rabatt</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>BR-32
Each Document level allowance (BG-20) shall have a Document level allowance VAT category code (BT-95).
- Was die Regel verlangt
- Jeder Abschlag auf Dokumentebene (BG-20) muss einen Umsatzsteuer-Kategoriecode (BT-95) tragen. Er entscheidet, in welchen Block der Steueraufschlüsselung der Betrag einfließt.
- Warum sie ausgelöst wird
- Der Ab- oder Zuschlag wird als reine Betragsposition gedacht, nicht als etwas Steuerbares. Erst die Aufschlüsselung braucht die Zuordnung — und findet sie dann nicht.
- Wie Sie es beheben
- Setzen Sie BT-95 in cac:AllowanceCharge/cac:TaxCategory/cbc:ID mit cbc:Percent und cac:TaxScheme (UBL) beziehungsweise ram:CategoryTradeTax in CII. Es ist derselbe Kategoriecode wie auf den Positionen — S, E, Z, AE.
- Was der Validator prüft
UBLexists(cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID)CII(../ram:CategoryTradeTax[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:AllowanceCharge>BR-33
Each Document level allowance (BG-20) shall have a Document level allowance reason (BT-97) or a Document level allowance reason code (BT-98).
- Was die Regel verlangt
- Jeder Abschlag auf Dokumentebene (BG-20) muss einen Grund tragen — im Klartext (BT-97), als Code (BT-98) oder beides. Ein Betrag ohne Begründung ist für den Empfänger nicht prüfbar.
- Warum sie ausgelöst wird
- Diese Regel und BR-CO-21 sind dieselbe Prüfung, in der Norm zweimal formuliert. Sie melden sich immer gemeinsam: ein fehlender Grund erzeugt zwei Fehlercodes, nicht zwei Fehler.
- Wie Sie es beheben
- Setzen Sie cbc:AllowanceChargeReason oder cbc:AllowanceChargeReasonCode im cac:AllowanceCharge (UBL) beziehungsweise ram:Reason oder ram:ReasonCode (CII). Damit verschwindet auch BR-CO-21. Zur Übereinstimmung von Code und Text siehe BR-CO-05 — eine Regel, die der Prüfer nie meldet.
- Was der Validator prüft
UBLexists(cbc:AllowanceChargeReason) or exists(cbc:AllowanceChargeReasonCode)CII(../ram:Reason) or (../ram:ReasonCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Mengenrabatt</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>BR-36
Each Document level charge (BG-21) shall have a Document level charge amount (BT-99).
- Was die Regel verlangt
- Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Betrag (BT-99) tragen. Ein Ab- oder Zuschlag ohne Betrag verändert nichts und gehört dann nicht ins Dokument.
- Warum sie ausgelöst wird
- Fracht- und Verpackungskosten werden als Text im Rechnungsfuß geführt. Die Gruppe entsteht aus diesem Text, und der Betrag steckt darin statt in einem eigenen Feld.
- Wie Sie es beheben
- Schreiben Sie den Betrag in cbc:Amount im cac:AllowanceCharge (UBL) beziehungsweise ram:ActualAmount im ram:SpecifiedTradeAllowanceCharge (CII). Zur Beziehung zwischen Betrag, Grundbetrag und Prozentsatz siehe PEPPOL-EN16931-R040.
- Was der Validator prüft
UBLexists(cbc:Amount)CII(../ram:ActualAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Versandkosten</cbc:AllowanceChargeReason> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Versandkosten</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>BR-37
Each Document level charge (BG-21) shall have a Document level charge VAT category code (BT-102).
- Was die Regel verlangt
- Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Umsatzsteuer-Kategoriecode (BT-102) tragen. Er entscheidet, in welchen Block der Steueraufschlüsselung der Betrag einfließt.
- Warum sie ausgelöst wird
- Der Ab- oder Zuschlag wird als reine Betragsposition gedacht, nicht als etwas Steuerbares. Erst die Aufschlüsselung braucht die Zuordnung — und findet sie dann nicht.
- Wie Sie es beheben
- Setzen Sie BT-102 in cac:AllowanceCharge/cac:TaxCategory/cbc:ID mit cbc:Percent und cac:TaxScheme (UBL) beziehungsweise ram:CategoryTradeTax in CII. Es ist derselbe Kategoriecode wie auf den Positionen — S, E, Z, AE.
- Was der Validator prüft
UBLexists(cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID)CII(../ram:CategoryTradeTax[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:AllowanceCharge>BR-38
Each Document level charge (BG-21) shall have a Document level charge reason (BT-104) or a Document level charge reason code (BT-105).
- Was die Regel verlangt
- Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Grund tragen — im Klartext (BT-104), als Code (BT-105) oder beides. Ein Betrag ohne Begründung ist für den Empfänger nicht prüfbar.
- Warum sie ausgelöst wird
- Diese Regel und BR-CO-22 sind dieselbe Prüfung, in der Norm zweimal formuliert. Sie melden sich immer gemeinsam: ein fehlender Grund erzeugt zwei Fehlercodes, nicht zwei Fehler.
- Wie Sie es beheben
- Setzen Sie cbc:AllowanceChargeReason oder cbc:AllowanceChargeReasonCode im cac:AllowanceCharge (UBL) beziehungsweise ram:Reason oder ram:ReasonCode (CII). Damit verschwindet auch BR-CO-22. Zur Übereinstimmung von Code und Text siehe BR-CO-06 — eine Regel, die der Prüfer nie meldet.
- Was der Validator prüft
UBLexists(cbc:AllowanceChargeReason) or exists(cbc:AllowanceChargeReasonCode)CII(../ram:Reason) or (../ram:ReasonCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>Korrigiert <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Versandkosten</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge>BR-41
Each Invoice line allowance (BG-27) shall have an Invoice line allowance amount (BT-136).
- Was die Regel verlangt
- Jeder Abschlag auf Positionsebene (BG-27) muss einen Betrag (BT-136) tragen. Ein Ab- oder Zuschlag ohne Betrag verändert nichts und gehört dann nicht ins Dokument.
- Warum sie ausgelöst wird
- Positionsrabatte kommen aus der Preisfindung als Prozentsatz. Der Prozentsatz wird übernommen, der daraus folgende Betrag nicht ausgerechnet.
- Wie Sie es beheben
- Schreiben Sie den Betrag in cbc:Amount im cac:AllowanceCharge (UBL) beziehungsweise ram:ActualAmount im ram:SpecifiedTradeAllowanceCharge (CII). Zur Beziehung zwischen Betrag, Grundbetrag und Prozentsatz siehe PEPPOL-EN16931-R040.
- Was der Validator prüft
UBLexists(cbc:Amount)CII(../ram:ActualAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Rabatt</cbc:AllowanceChargeReason> </cac:AllowanceCharge> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Rabatt</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>BR-42
Abschlag ohne Grund (BT-139)
Each Invoice line allowance (BG-27) shall have an Invoice line allowance reason (BT-139) or an Invoice line allowance reason code (BT-140).
- Was die Regel verlangt
- Jeder Abschlag auf Positionsebene (BG-27) muss einen Grund tragen — im Klartext (BT-139), als Code (BT-140) oder beides. Ein Betrag ohne Begründung ist für den Empfänger nicht prüfbar.
- Warum sie ausgelöst wird
- Diese Regel und BR-CO-23 sind dieselbe Prüfung, in der Norm zweimal formuliert. Sie melden sich immer gemeinsam: ein fehlender Grund erzeugt zwei Fehlercodes, nicht zwei Fehler.
- Wie Sie es beheben
- Setzen Sie cbc:AllowanceChargeReason oder cbc:AllowanceChargeReasonCode im cac:AllowanceCharge (UBL) beziehungsweise ram:Reason oder ram:ReasonCode (CII). Damit verschwindet auch BR-CO-23. Wählen Sie den Code, gilt zusätzlich BR-CL-19: dafür sind nur 19 Werte aus UNCL 5189 zulässig. Der Klartext ist an keine Liste gebunden — im Zweifel schreiben Sie ihn. Zur Übereinstimmung von Code und Text siehe BR-CO-07 — eine Regel, die der Prüfer nie meldet.
- Was der Validator prüft
UBLexists(cbc:AllowanceChargeReason) or exists(cbc:AllowanceChargeReasonCode)CII(../ram:Reason) or (../ram:ReasonCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>false</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Mengenrabatt</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>BR-43
Zuschlag ohne Betrag (BT-141)
Each Invoice line charge (BG-28) shall have an Invoice line charge amount (BT-141).
- Was die Regel verlangt
- Jeder Zuschlag auf Positionsebene (BG-28) muss einen Betrag (BT-141) tragen — ein Zuschlag ohne Betrag verändert nichts und gehört nicht ins Dokument.
- Warum sie ausgelöst wird
- Positionszuschläge sind selten und werden im Mapping oft nur halb angelegt: die Gruppe steht, der Betrag ist an ein Feld gebunden, das es im Quellsystem nicht gibt.
- Wie Sie es beheben
- Schreiben Sie den Betrag in cbc:Amount im cac:AllowanceCharge (UBL) beziehungsweise ram:ActualAmount im ram:SpecifiedTradeAllowanceCharge (CII). Zur Beziehung zwischen Betrag, Grundbetrag und Prozentsatz siehe PEPPOL-EN16931-R040.
- Was der Validator prüft
UBLexists(cbc:Amount)CII(../ram:ActualAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Expresszuschlag</cbc:AllowanceChargeReason> </cac:AllowanceCharge> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Expresszuschlag</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>BR-44
Each Invoice line charge shall have an Invoice line charge reason or an invoice line allowance reason code.
Wortlaut in CII
Each Invoice line charge (BG-28) shall have an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145).
- Was die Regel verlangt
- Jeder Zuschlag auf Positionsebene (BG-28) muss einen Grund tragen — im Klartext (BT-144), als Code (BT-145) oder beides. Ein Betrag ohne Begründung ist für den Empfänger nicht prüfbar.
- Warum sie ausgelöst wird
- Diese Regel und BR-CO-24 sind dieselbe Prüfung, in der Norm zweimal formuliert. Sie melden sich immer gemeinsam: ein fehlender Grund erzeugt zwei Fehlercodes, nicht zwei Fehler.
- Wie Sie es beheben
- Setzen Sie cbc:AllowanceChargeReason oder cbc:AllowanceChargeReasonCode im cac:AllowanceCharge (UBL) beziehungsweise ram:Reason oder ram:ReasonCode (CII). Damit verschwindet auch BR-CO-24. Zur Übereinstimmung von Code und Text siehe BR-CO-08 — eine Regel, die der Prüfer nie meldet.
- Was der Validator prüft
UBLexists(cbc:AllowanceChargeReason) or exists(cbc:AllowanceChargeReasonCode)CII(../ram:Reason) or (../ram:ReasonCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>Korrigiert <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cac:AllowanceCharge> <cbc:ChargeIndicator>true</cbc:ChargeIndicator> <cbc:AllowanceChargeReason>Expresszuschlag</cbc:AllowanceChargeReason> <cbc:Amount currencyID="EUR">50.00</cbc:Amount> </cac:AllowanceCharge> </cac:InvoiceLine>BR-45
Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116).
- Was die Regel verlangt
- Jeder Block der Steueraufschlüsselung (BG-23) muss den Nettobetrag der Kategorie (BT-116) enthalten. Die Aufschlüsselung ist die Stelle, an der die Steuer nachvollziehbar wird.
- Warum sie ausgelöst wird
- Die Aufschlüsselung wird aus den Steuerbeträgen gebaut, weil die auf der Rechnung sichtbar sind. Die zugehörige Bemessungsgrundlage ist ein Zwischenergebnis und wird nicht mitgeschrieben.
- Wie Sie es beheben
- Schreiben Sie BT-116 in cac:TaxTotal/cac:TaxSubtotal/cbc:TaxableAmount (UBL) beziehungsweise ram:BasisAmount im ram:ApplicableTradeTax (CII). Wie Bemessungsgrundlage, Satz und Steuerbetrag zusammenpassen müssen, prüft BR-CO-17.
- Was der Validator prüft
UBLexists(cbc:TaxableAmount)CII(ram:BasisAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxSubtotal> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>Korrigiert <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>BR-46
Each VAT breakdown (BG-23) shall have a VAT category tax amount (BT-117).
- Was die Regel verlangt
- Jeder Block der Steueraufschlüsselung (BG-23) muss den Steuerbetrag der Kategorie (BT-117) enthalten. Die Aufschlüsselung ist die Stelle, an der die Steuer nachvollziehbar wird.
- Warum sie ausgelöst wird
- Bei steuerfreien Kategorien wirkt ein Steuerbetrag von 0 wie eine Nichtangabe und wird weggelassen. Die Norm verlangt die Null ausdrücklich.
- Wie Sie es beheben
- Schreiben Sie BT-117 in cac:TaxTotal/cac:TaxSubtotal/cbc:TaxAmount (UBL) beziehungsweise ram:CalculatedAmount im ram:ApplicableTradeTax (CII). Wie Bemessungsgrundlage, Satz und Steuerbetrag zusammenpassen müssen, prüft BR-CO-17.
- Was der Validator prüft
UBLexists(cbc:TaxAmount)CII(ram:CalculatedAmount)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>Korrigiert <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>BR-47
Steueraufschlüsselung ohne Code (BT-118)
Each VAT breakdown (BG-23) shall be defined through a VAT category code (BT-118).
- Was die Regel verlangt
- Jeder Block der Steueraufschlüsselung muss über einen Umsatzsteuer-Kategoriecode (BT-118) definiert sein — einen der zehn, die BR-CL-17 zulässt. Das sind S, Z, E, AE, K, G, O, L, M und B.
- Warum sie ausgelöst wird
- Systeme unterscheiden Steuersätze über den Prozentsatz und brauchen dafür keine Kategorie. 0 % steht dann für steuerfrei, innergemeinschaftlich und Reverse Charge gleichermaßen, obwohl das drei verschiedene Kategorien sind.
- Wie Sie es beheben
- Setzen Sie BT-118 in cac:TaxSubtotal/cac:TaxCategory/cbc:ID (UBL) beziehungsweise ram:ApplicableTradeTax/ram:CategoryCode (CII). Es ist derselbe Code wie auf der Position, siehe BR-CO-04.
- Was der Validator prüft
UBLexists(cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:ID)CII(.[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>Korrigiert <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>BR-48
Each VAT breakdown (BG-23) shall have a VAT category rate (BT-119), except if the Invoice is not subject to VAT.
- Was die Regel verlangt
- Jeder Block der Steueraufschlüsselung muss einen Steuersatz (BT-119) tragen, außer die Rechnung unterliegt gar nicht der Umsatzsteuer.
- Warum sie ausgelöst wird
- Bei steuerfreien Kategorien wird der Satz weggelassen, weil es keinen gibt. Die Norm will dort ausdrücklich die 0 sehen — die Aussage „null Prozent“ unterscheidet sich von „kein Wert“.
- Wie Sie es beheben
- Setzen Sie BT-119 in cac:TaxSubtotal/cac:TaxCategory/cbc:Percent (UBL) beziehungsweise ram:RateApplicablePercent (CII), bei E, Z und AE ausdrücklich als 0. Für den deutschen Prüfweg gilt zusätzlich BR-DE-14.
- Was der Validator prüft
UBLexists(cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/cbc:Percent) or (cac:TaxCategory[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']/normalize-space(cbc:ID)='O')CII(.[upper-case(ram:TypeCode) = 'VAT']/ram:RateApplicablePercent) or (.[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode = 'O')
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>Korrigiert <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>19</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal>BR-49
A Payment instruction (BG-16) shall specify the Payment means type code (BT-81).
- Was die Regel verlangt
- Eine Zahlungsanweisung (BG-16) muss den Zahlungsmittel-Code (BT-81) nennen — die Angabe, auf welchem Weg gezahlt werden soll.
- Warum sie ausgelöst wird
- Die Gruppe wird angelegt, um die IBAN unterzubringen, und die IBAN scheint den Weg schon zu erklären. Für die automatische Verarbeitung ist der Code aber das entscheidende Feld, nicht die Kontonummer.
- Wie Sie es beheben
- Setzen Sie einen UNTDID-4461-Code in cbc:PaymentMeansCode (UBL) beziehungsweise ram:TypeCode (CII): 58 für SEPA-Überweisung, 59 für SEPA-Lastschrift, 30 für die allgemeine Überweisung, 48 für Kartenzahlung.
- Was der Validator prüft
UBLexists(cbc:PaymentMeansCode)CII(ram:TypeCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PaymentMeans> <cac:PayeeFinancialAccount> <cbc:ID>DE02120300000000202051</cbc:ID> </cac:PayeeFinancialAccount> </cac:PaymentMeans>Korrigiert <cac:PaymentMeans> <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode> <cac:PayeeFinancialAccount> <cbc:ID>DE02120300000000202051</cbc:ID> </cac:PayeeFinancialAccount> </cac:PaymentMeans>BR-50
A Payment account identifier (BT-84) shall be present if Credit transfer (BG-17) information is provided in the Invoice.
Wortlaut in CII
A Payment account identifier (BT-84) shall be present if Credit transfer (BG-16) information is provided in the Invoice.
- Was die Regel verlangt
- Wird eine Überweisung als Zahlungsweg angegeben, muss die Kontokennung des Zahlungsempfängers (BT-84) dabeistehen. Eine Aufforderung zu überweisen braucht ein Ziel.
- Warum sie ausgelöst wird
- Die Bankverbindung steht im Rechnungsfuß der PDF-Darstellung und wird im strukturierten Datensatz nicht wiederholt, weil sie dort für den Menschen bereits sichtbar ist.
- Wie Sie es beheben
- Schreiben Sie die IBAN in cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID (UBL) beziehungsweise ram:PayeePartyCreditorFinancialAccount/ram:IBANID (CII). Zur Richtigkeit der IBAN siehe BR-DE-19.
- Was der Validator prüft
UBLnormalize-space(cbc:ID) != ''CIInormalize-space(ram:IBANID) != '' or normalize-space(ram:ProprietaryID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PaymentMeans> <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode> </cac:PaymentMeans>Korrigiert <cac:PaymentMeans> <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode> <cac:PayeeFinancialAccount> <cbc:ID>DE02120300000000202051</cbc:ID> </cac:PayeeFinancialAccount> </cac:PaymentMeans>BR-51
Unmaskierte Kartennummer (BT-87)
In accordance with card payments security standards an invoice should never include a full card primary account number (BT-87). At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.
Wortlaut in CII
In accordance with card payments security standards an invoice should never include a full card primary account number (BT-97). At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.
- Was die Regel verlangt
- Die vollständige Kartennummer darf niemals in einer Rechnung stehen — umgesetzt ist das als schlichte Längengrenze: höchstens zehn Zeichen im Feld. Das entspricht den ersten sechs und letzten vier Ziffern, die PCI DSS als Maximum zulässt.
- Warum sie ausgelöst wird
- Die Kartennummer liegt im Zahlungssystem vollständig vor und wird beim Mapping unverändert übernommen, weil das Feld im Zielschema genau so heißt. Damit wandert ein Datum in ein Dokument, das per Mail verschickt und jahrelang archiviert wird. Der Regeltext oben nennt übrigens BT-97 — den Grund eines Abschlags auf Dokumentebene. Das ausgelieferte Regelwerk widerspricht sich hier: die UBL-Fassung von BR-51 schreibt BT-87, die CII-Fassung BT-97. Gemeint und geprüft ist in beiden die Kartennummer.
- Wie Sie es beheben
- Maskieren Sie vor dem Schreiben und übermitteln Sie höchstens die letzten Stellen in cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID (UBL) beziehungsweise ram:ApplicableTradeSettlementFinancialCard/ram:ID (CII). Die Maskierung gehört in die Erzeugung, nicht in eine spätere Bereinigung. Zählen Sie die Maskierungszeichen mit: „**** **** **** 1234“ hat neunzehn Zeichen und fällt durch, obwohl nichts Verwertbares darin steht. Die letzten vier Ziffern allein sind sicher.
- Was der Validator prüft
UBLstring-length(normalize-space(.))<=10CIIstring-length(normalize-space(ram:ID)) <= 10
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:CardAccount> <cbc:PrimaryAccountNumberID>4111111111111111</cbc:PrimaryAccountNumberID> <cbc:NetworkID>NA</cbc:NetworkID> </cac:CardAccount>Korrigiert <cac:CardAccount> <cbc:PrimaryAccountNumberID>******1111</cbc:PrimaryAccountNumberID> <cbc:NetworkID>NA</cbc:NetworkID> </cac:CardAccount>BR-52
Each Additional supporting document (BG-24) shall contain a Supporting document reference (BT-122).
- Was die Regel verlangt
- Jede zusätzliche Belegangabe (BG-24) muss eine Kennung (BT-122) tragen — die Nummer, unter der der Beleg beim Empfänger auffindbar ist.
- Warum sie ausgelöst wird
- Die Gruppe wird angelegt, um einen Anhang mitzuschicken, und der Anhang trägt einen Dateinamen. Eine Kennung für den Beleg selbst wird dabei nicht vergeben, weil der Dateiname als Bezeichnung genügt.
- Wie Sie es beheben
- Setzen Sie BT-122 in cac:AdditionalDocumentReference/cbc:ID (UBL) beziehungsweise ram:AdditionalReferencedDocument/ram:IssuerAssignedID (CII). Zur Eindeutigkeit der Dateinamen bei mehreren Anhängen siehe BR-DE-22.
- Was der Validator prüft
UBLnormalize-space(cbc:ID) != ''CIInormalize-space(ram:IssuerAssignedID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AdditionalDocumentReference> <cac:Attachment> <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="stundennachweis.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject> </cac:Attachment> </cac:AdditionalDocumentReference>Korrigiert <cac:AdditionalDocumentReference> <cbc:ID>SN-2026-0042</cbc:ID> <cac:Attachment> <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="stundennachweis.pdf">JVBERi0=</cbc:EmbeddedDocumentBinaryObject> </cac:Attachment> </cac:AdditionalDocumentReference>BR-53
If the VAT accounting currency code (BT-6) is present, then the Invoice total VAT amount in accounting currency (BT-111) shall be provided.
- Was die Regel verlangt
- Ist eine abweichende Steuerwährung (BT-6) angegeben, muss auch die Steuersumme in dieser Währung (BT-111) übermittelt werden. Die Währung allein sagt noch keinen Betrag.
- Warum sie ausgelöst wird
- BT-6 wird aus dem Mandanten oder einer Vorlage gesetzt, die Umrechnung des Steuerbetrags aber nicht ausgelöst — sie braucht einen Kurs, den das Rechnungsobjekt nicht kennt.
- Wie Sie es beheben
- Schreiben Sie den umgerechneten Steuerbetrag in ein zweites cac:TaxTotal ohne cac:TaxSubtotal, mit currencyID der Steuerwährung (UBL) — oder lassen Sie BT-6 weg. Wie viele solcher Blöcke zulässig sind, regelt PEPPOL-EN16931-R054, das Vorzeichen R055.
- Was der Validator prüft
UBLevery $taxcurrency in cbc:TaxCurrencyCode satisfies exists(//cac:TaxTotal/cbc:TaxAmount[@currencyID=$taxcurrency])CIInot(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode) or (/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode and (ram:TaxTotalAmount/@currencyID = /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode = /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode))
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cbc:TaxCurrencyCode>SEK</cbc:TaxCurrencyCode> <cac:TaxTotal> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> </cac:TaxSubtotal> </cac:TaxTotal>Korrigiert <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cbc:TaxCurrencyCode>SEK</cbc:TaxCurrencyCode> <cac:TaxTotal> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount> </cac:TaxSubtotal> </cac:TaxTotal> <cac:TaxTotal> <cbc:TaxAmount currencyID="SEK">2090.00</cbc:TaxAmount> </cac:TaxTotal>BR-54
Artikelmerkmal ohne Wert (BT-161)
Each Item attribute (BG-32) shall contain an Item attribute name (BT-160) and an Item attribute value (BT-161).
- Was die Regel verlangt
- Jedes Artikelmerkmal (BG-32) muss aus einem Namen (BT-160) und einem Wert (BT-161) bestehen — eines von beiden allein beschreibt nichts.
- Warum sie ausgelöst wird
- Merkmale werden aus einer Eigenschaftstabelle übernommen, in der Werte fehlen dürfen. Die Gruppe entsteht je Eigenschaft, auch wenn nur der Name belegt ist.
- Wie Sie es beheben
- Schreiben Sie cac:Item/cac:AdditionalItemProperty nur, wenn beide Felder belegt sind — cbc:Name und cbc:Value (UBL) beziehungsweise ram:ApplicableProductCharacteristic mit ram:Description und ram:Value (CII). Achtung bei CII: der Name steht dort in ram:Description, nicht in einem ram:Name — wer nach dem naheliegenden Element sucht, findet es nicht.
- Was der Validator prüft
UBLexists(cbc:Name) and exists(cbc:Value)CII(ram:Description) and (ram:Value)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:AdditionalItemProperty> <cbc:Name>Projektnummer</cbc:Name> </cac:AdditionalItemProperty> </cac:Item>Korrigiert <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:AdditionalItemProperty> <cbc:Name>Projektnummer</cbc:Name> <cbc:Value>P-2026-0815</cbc:Value> </cac:AdditionalItemProperty> </cac:Item>BR-55
Each Preceding Invoice reference (BG-3) shall contain a Preceding Invoice reference (BT-25).
- Was die Regel verlangt
- Jeder Verweis auf eine vorausgegangene Rechnung (BG-3) muss deren Nummer (BT-25) enthalten. Ohne sie verweist die Gruppe auf nichts Bestimmtes.
- Warum sie ausgelöst wird
- Die Gruppe wird angelegt, um das Datum der Ursprungsrechnung mitzugeben, oder sie entsteht leer aus einer Vorlage für Korrekturen. Die Nummer liegt in einem anderen Feld als erwartet.
- Wie Sie es beheben
- Setzen Sie BT-25 in cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID (UBL) beziehungsweise ram:InvoiceReferencedDocument/ram:IssuerAssignedID (CII). Wann der Verweis überhaupt verlangt wird, steht in BR-DE-26.
- Was der Validator prüft
UBLexists(cac:InvoiceDocumentReference/cbc:ID)CIInormalize-space(ram:IssuerAssignedID) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:BillingReference> <cac:InvoiceDocumentReference> <cbc:IssueDate>2026-07-15</cbc:IssueDate> </cac:InvoiceDocumentReference> </cac:BillingReference>Korrigiert <cac:BillingReference> <cac:InvoiceDocumentReference> <cbc:ID>RE-2026-0041</cbc:ID> <cbc:IssueDate>2026-07-15</cbc:IssueDate> </cac:InvoiceDocumentReference> </cac:BillingReference>BR-56
Each Seller tax representative party (BG-11) shall have a Seller tax representative VAT identifier (BT-63).
- Was die Regel verlangt
- Jeder steuerliche Vertreter (BG-11) muss seine Umsatzsteuer-Identifikationsnummer (BT-63) tragen. Ohne sie ist die Vertretung steuerlich nicht nachvollziehbar.
- Warum sie ausgelöst wird
- Der Vertreter wird als weitere Adresse behandelt und wie eine Adresse gemappt — Name, Ort, Land. Dass hier eine Steuerkennung zwingend ist und nicht nur nützlich, geht dabei unter.
- Wie Sie es beheben
- Setzen Sie BT-63 in cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID mit cac:TaxScheme/cbc:ID = VAT (UBL) beziehungsweise ram:SpecifiedTaxRegistration/ram:ID des Vertreters (CII). Das Länderpräfix fordert BR-CO-09.
- Was der Validator prüft
UBLexists(cac:PartyTaxScheme[cac:TaxScheme/(normalize-space(upper-case(cbc:ID)) = 'VAT')]/cbc:CompanyID)CIInormalize-space(ram:SpecifiedTaxRegistration/ram:ID[@schemeID='VA']) != ''
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:TaxRepresentativeParty> <cac:PartyName> <cbc:Name>Steuerkanzlei Muster</cbc:Name> </cac:PartyName> </cac:TaxRepresentativeParty>Korrigiert <cac:TaxRepresentativeParty> <cac:PartyName> <cbc:Name>Steuerkanzlei Muster</cbc:Name> </cac:PartyName> <cac:PartyTaxScheme> <cbc:CompanyID>DE811234567</cbc:CompanyID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:PartyTaxScheme> </cac:TaxRepresentativeParty>BR-57
Lieferanschrift ohne Land (BT-80)
Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80).
- Was die Regel verlangt
- Wird eine Lieferanschrift (BG-15) übermittelt, muss sie ein Länderkennzeichen (BT-80) enthalten — dieselbe Anforderung wie BR-09 und BR-11, für die Lieferadresse.
- Warum sie ausgelöst wird
- Die Lieferanschrift wird aus dem Auftrag übernommen und dort meist als Freitext geführt, weil sie nur auf den Lieferschein gedruckt wird. Ein Ländercode ist dafür nie nötig gewesen.
- Wie Sie es beheben
- Setzen Sie den ISO-3166-1-Code in cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode (UBL) beziehungsweise ram:ShipToTradeParty/ram:PostalTradeAddress/ram:CountryID (CII) — oder lassen Sie die Gruppe weg. Ort und Postleitzahl fordern BR-DE-10 und BR-DE-11.
- Was der Validator prüft
UBLexists(cac:Country/cbc:IdentificationCode)CII(ram:ShipToTradeParty/ram:PostalTradeAddress and normalize-space(ram:ShipToTradeParty/ram:PostalTradeAddress/ram:CountryID) != '') or not (ram:ShipToTradeParty/ram:PostalTradeAddress)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Delivery> <cac:DeliveryLocation> <cac:Address> <cbc:CityName>Bonn</cbc:CityName> <cbc:PostalZone>53113</cbc:PostalZone> </cac:Address> </cac:DeliveryLocation> </cac:Delivery>Korrigiert <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>BR-61
Überweisung ohne Kontokennung (BT-84)
If the Payment means type code (BT-81) means SEPA credit transfer, Local credit transfer or Non-SEPA international credit transfer, the Payment account identifier (BT-84) shall be present.
- Was die Regel verlangt
- Bedeutet der Zahlungsmittel-Code eine Überweisung — SEPA, inländisch oder international —, muss die Kontokennung des Empfängers (BT-84) übermittelt werden.
- Warum sie ausgelöst wird
- Nahe verwandt mit BR-50, aber anders ausgelöst: BR-50 greift, sobald Überweisungsdaten vorhanden sind, BR-61 über den Code. In UBL prüft BR-61 nur bei Code 30 oder 58 — wer 58 setzt und die Kontogruppe ganz weglässt, sieht deshalb nur diese Regel. In CII schauen beide auf dieselben zwei Elemente, prüfen aber Verschiedenes: BR-50 verlangt einen nicht leeren Wert, BR-61 nur, dass das Element überhaupt da ist. Ein leeres ram:IBANID meldet also BR-50 allein.
- Wie Sie es beheben
- Schreiben Sie die IBAN in cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID (UBL) beziehungsweise ram:PayeePartyCreditorFinancialAccount/ram:IBANID (CII) — oder setzen Sie den Code auf das Zahlungsmittel, das tatsächlich gemeint ist.
- Was der Validator prüft
UBL(exists(cac:PayeeFinancialAccount/cbc:ID) and ((normalize-space(cbc:PaymentMeansCode) = '30') or (normalize-space(cbc:PaymentMeansCode) = '58') )) or ((normalize-space(cbc:PaymentMeansCode) != '30') and (normalize-space(cbc:PaymentMeansCode) != '58'))CII(ram:IBANID) or (ram:ProprietaryID)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:PaymentMeans> <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode> <cbc:PaymentID>RE-2026-0042</cbc:PaymentID> </cac:PaymentMeans>Korrigiert <cac:PaymentMeans> <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode> <cbc:PaymentID>RE-2026-0042</cbc:PaymentID> <cac:PayeeFinancialAccount> <cbc:ID>DE02120300000000202051</cbc:ID> </cac:PayeeFinancialAccount> </cac:PaymentMeans>BR-62
The Seller electronic address (BT-34) shall have a Scheme identifier.
- Was die Regel verlangt
- Wird die elektronische Adresse des Verkäufers (BT-34) übermittelt, muss sie ein Schema-Attribut tragen. Das Attribut sagt, aus welchem Verzeichnis die Kennung stammt — ohne das ist sie nur eine Zeichenkette.
- Warum sie ausgelöst wird
- Die Adresse wird als einfache Zeichenkette gemappt, weil sie im Quellsystem eine ist. Das Schema-Attribut daneben hat dort kein Gegenstück und bleibt leer.
- Wie Sie es beheben
- Setzen Sie das Attribut schemeID an cac:AccountingSupplierParty/cac:Party/cbc:EndpointID (UBL). In CII heißt das Element anders: schemeID gehört an ram:SellerTradeParty/ram:URIUniversalCommunication/ram:URIID. PEPPOL-EN16931-R020 fordert die Adresse selbst.
- Was der Validator prüft
UBLexists(@schemeID)CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:URIUniversalCommunication[1]/ram:URIID/@schemeID) != '' or not (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:URIUniversalCommunication)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AccountingSupplierParty> <cac:Party> <cbc:EndpointID>rechnung@muster.de</cbc:EndpointID> <cac:PartyName> <cbc:Name>Muster GmbH</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingSupplierParty>Korrigiert <cac:AccountingSupplierParty> <cac:Party> <cbc:EndpointID schemeID="EM">rechnung@muster.de</cbc:EndpointID> <cac:PartyName> <cbc:Name>Muster GmbH</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingSupplierParty>BR-63
The Buyer electronic address (BT-49) shall have a Scheme identifier.
- Was die Regel verlangt
- Wird die elektronische Adresse des Käufers (BT-49) übermittelt, muss sie ein Schema-Attribut tragen. Das Attribut sagt, aus welchem Verzeichnis die Kennung stammt — ohne das ist sie nur eine Zeichenkette.
- Warum sie ausgelöst wird
- Dieselbe Ursache wie bei BR-62, mit einer Zuspitzung: bei Behörden wird die Leitweg-ID als Adresse eingetragen, und dann ist das Schema 0204 und nicht EM — die Wahl fällt nur auf, wenn es das Feld überhaupt gibt. Der früher übliche Code 9958 steht nicht mehr in der Liste, die BR-CL-25 prüft.
- Wie Sie es beheben
- Setzen Sie das Attribut schemeID an cac:AccountingCustomerParty/cac:Party/cbc:EndpointID (UBL). In CII heißt das Element anders: schemeID gehört an ram:BuyerTradeParty/ram:URIUniversalCommunication/ram:URIID. PEPPOL-EN16931-R010 fordert die Adresse selbst.
- Was der Validator prüft
UBLexists(@schemeID)CIInormalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:URIUniversalCommunication[1]/ram:URIID/@schemeID) != '' or not (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:URIUniversalCommunication)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:AccountingCustomerParty> <cac:Party> <cbc:EndpointID>rechnung@behoerde-bonn.de</cbc:EndpointID> <cac:PartyName> <cbc:Name>Behörde Bonn</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingCustomerParty>Korrigiert <cac:AccountingCustomerParty> <cac:Party> <cbc:EndpointID schemeID="EM">rechnung@behoerde-bonn.de</cbc:EndpointID> <cac:PartyName> <cbc:Name>Behörde Bonn</cbc:Name> </cac:PartyName> </cac:Party> </cac:AccountingCustomerParty>BR-64
The Item standard identifier (BT-157) shall have a Scheme identifier.
- Was die Regel verlangt
- Wird die Artikelkennung nach Standard (BT-157) übermittelt, muss sie ein Schema-Attribut tragen. Das Attribut sagt, aus welchem Verzeichnis die Kennung stammt — ohne das ist sie nur eine Zeichenkette.
- Warum sie ausgelöst wird
- Die GTIN steht im Artikelstamm als Zahl. Dass sie zusätzlich sagen muss, aus welchem Nummernkreis sie stammt, ergibt sich aus dem eigenen System nicht.
- Wie Sie es beheben
- Setzen Sie das Attribut schemeID an cac:Item/cac:StandardItemIdentification/cbc:ID (UBL). In CII heißt das Element anders: schemeID gehört an ram:SpecifiedTradeProduct/ram:GlobalID. 0160 steht für die GTIN.
- Was der Validator prüft
UBLexists(@schemeID)CIInormalize-space(ram:SpecifiedTradeProduct/ram:GlobalID/@schemeID) != '' or not (ram:SpecifiedTradeProduct/ram:GlobalID)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:StandardItemIdentification> <cbc:ID>04012345678901</cbc:ID> </cac:StandardItemIdentification> </cac:Item>Korrigiert <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:StandardItemIdentification> <cbc:ID schemeID="0160">04012345678901</cbc:ID> </cac:StandardItemIdentification> </cac:Item>BR-65
Artikelkennung ohne Schema (BT-158)
The Item classification identifier (BT-158) shall have a Scheme identifier.
- Was die Regel verlangt
- Wird die Klassifizierungskennung des Artikels (BT-158) übermittelt, muss sie ein Schema-Attribut tragen. Das Attribut sagt, aus welchem Verzeichnis die Kennung stammt — ohne das ist sie nur eine Zeichenkette.
- Warum sie ausgelöst wird
- Warengruppen werden hausintern vergeben und beim Mapping unverändert übernommen. Ohne Angabe des Klassifikationssystems ist die Nummer für den Empfänger bedeutungslos.
- Wie Sie es beheben
- Setzen Sie das Attribut listID an cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode (UBL). In CII heißt weder das Element noch der Weg dorthin gleich: das Attribut listID gehört an ram:ClassCode in ram:DesignatedProductClassification. TST steht im Beispiel stellvertretend; üblich sind etwa eCl@ss oder UNSPSC.
- Was der Validator prüft
UBLexists(@listID)CIInormalize-space(ram:ClassCode/@listID) != '' or not (ram:ClassCode)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:CommodityClassification> <cbc:ItemClassificationCode>12345678</cbc:ItemClassificationCode> </cac:CommodityClassification> </cac:Item>Korrigiert <cac:Item> <cbc:Name>Beratungsleistung</cbc:Name> <cac:CommodityClassification> <cbc:ItemClassificationCode listID="TST">12345678</cbc:ItemClassificationCode> </cac:CommodityClassification> </cac:Item>BR-DE-TMP-32
Liefer- oder Leistungsdatum fehlt
Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums entweder BT-72 "Actual delivery date", BG-14 "Invoicing period" oder in jeder Rechnungsposition BG-26 "Invoice line period" enthalten.Hinweis
- Was die Regel verlangt
- Ein Hinweis, kein Fehler: Die Rechnung sollte das Liefer- oder Leistungsdatum strukturiert angeben — als Lieferdatum (BT-72), als Abrechnungszeitraum (BG-14) oder als Zeitraum auf jeder einzelnen Rechnungsposition (BG-26). Fehlen alle drei Angaben, bleibt die Rechnung gültig, und der Validator empfiehlt sie weiterhin zur Annahme. Geprüft wird nur, ob eines der Elemente vorhanden ist; in UBL genügt deshalb schon ein cac:InvoicePeriod, das allein den Code für das Steuerdatum (BT-8) enthält, obwohl darin kein Datum steht.
- Warum sie ausgelöst wird
- Alle drei Angaben sind in der EN 16931 optional, und viele Rechnungen nennen den Zeitpunkt der Lieferung oder Leistung — eine Pflichtangabe nach § 14 Abs. 4 Satz 1 Nr. 6 UStG — nur im Freitext („Leistungsdatum entspricht Rechnungsdatum“) oder als Steuerdatum (BT-7), der hier nicht zählt. Der Positionszeitraum wiederum hilft nur, wenn ihn jede Zeile trägt: Selbst die Testrechnung 01.01a aus der XRechnung-Testsuite der KoSIT erhält den Hinweis, weil ihre Zeile „Porto + Versandkosten“ keinen Zeitraum hat.
- Wie Sie es beheben
- Für eine einzelne Lieferung setzen Sie BT-72: in UBL cac:Delivery/cbc:ActualDeliveryDate, in CII ram:ApplicableHeaderTradeDelivery/ram:ActualDeliverySupplyChainEvent/ram:OccurrenceDateTime mit udt:DateTimeString format="102". Für eine Leistung über einen Zeitraum nehmen Sie BG-14 mit Beginn und Ende — cac:InvoicePeriod mit cbc:StartDate und cbc:EndDate in UBL, ram:ApplicableHeaderTradeSettlement/ram:BillingSpecifiedPeriod mit ram:StartDateTime und ram:EndDateTime in CII. Tragen Positionen bereits eigene Zeiträume, müssen diese innerhalb von BG-14 liegen, sonst weisen PEPPOL-EN16931-R110 und PEPPOL-EN16931-R111 die Rechnung ab; eine leere Gruppe beseitigt den Hinweis zwar, scheitert aber an BR-CO-19.
- Was der Validator prüft
UBLcac:Delivery/cbc:ActualDeliveryDate or cac:InvoicePeriod or (every $line in (cac:InvoiceLine | cac:CreditNoteLine) satisfies $line/cac:InvoicePeriod)CIIram:ApplicableHeaderTradeDelivery/ram:ActualDeliverySupplyChainEvent/ram:OccurrenceDateTime or ram:ApplicableHeaderTradeSettlement/ram:BillingSpecifiedPeriod or (every $line in ram:IncludedSupplyChainTradeLineItem satisfies $line/ram:SpecifiedLineTradeSettlement/ram:BillingSpecifiedPeriod)
Im XML
Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.
Fehlerhaft <cbc:Note>Leistungszeitraum: September 2026</cbc:Note> <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>Korrigiert <cbc:Note>Leistungszeitraum: September 2026</cbc:Note> <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference> <cac:InvoicePeriod> <cbc:StartDate>2026-09-01</cbc:StartDate> <cbc:EndDate>2026-09-30</cbc:EndDate> </cac:InvoicePeriod>
NormAPI liefert technische Validierung, keine Steuer- oder Rechtsberatung.