Auf dieser Seite
Die kurze Antwort
BR-O-03 schlägt fehl, wenn ein cac:AllowanceCharge auf Wurzelebene mit cbc:ChargeIndicator false eine cac:TaxCategory O hat und das Dokument zugleich eine Umsatzsteuer-Identifikationsnummer trägt: eine cbc:CompanyID in einem cac:PartyTaxScheme mit VAT bei Verkäufer, Käufer oder Steuervertreter. Im aufgezeichneten Beispiel ist es die Nummer GB987654321 des Käufers neben einem Loyalty discount über 5.00. Entfernen Sie das cac:PartyTaxScheme mit VAT bei jeder Partei.
Der Befund kommt in der Regel zusammen mit BR-O-02, weil ein Dokument mit einem Nachlass in O auch Positionen in O hat; beide Regeln prüfen dieselben Nummern von verschiedenen Ausgangspunkten aus, und das Entfernen der Nummern beseitigt beide.
Was die Regel prüft
Der Auslöser ist auf Nachlässe direkt unter der Dokumentwurzel beschränkt, deren cac:TaxCategory im Schema VAT O ist. Nachlässe und Zuschläge auf Positionsebene fallen nicht darunter, ebenso wenig die Positionen selbst, die BR-O-02 abdeckt.
Gesucht wird an drei Stellen, jeweils nur unter einem cac:PartyTaxScheme, dessen Schema VAT ist: beim Verkäufer, beim Käufer und in cac:TaxRepresentativeParty. Im Versuch an der korrigierten Rechnung meldeten die Nummer GB123456789 des Verkäufers und ein Steuervertreter mit GB987654321 jeweils diese Regel zusammen mit BR-O-02.
Ohne Position in O steht die Regel für sich. Im Versuch meldete derselbe Nachlass über 5.00 in der Kategorie O auf einer Rechnung zum Normalsatz, deren Verkäufer GB123456789 hat, diese Regel und BR-O-01, aber nicht BR-O-02, da keine Position in O stand.
Eine Registrierung des Verkäufers im Schema TAX ist für diese Regel keine Umsatzsteuer-Identifikationsnummer: Als 1234567890 zur korrigierten Rechnung hinzugefügt, ließ sie das Dokument mit dem Nachlass im Versuch gültig.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-95 | Code der Umsatzsteuerkategorie des Nachlasses auf Dokumentenebene | cac:AllowanceCharge[cbc:ChargeIndicator = false]/cac:TaxCategory/cbc:ID |
| BT-31 | Umsatzsteuer-Identifikationsnummer des Verkäufers | cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID |
| BT-48 | Umsatzsteuer-Identifikationsnummer des Käufers | cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID |
| BT-63 | Umsatzsteuer-Identifikationsnummer des Steuervertreters des Verkäufers | cac:TaxRepresentativeParty/cac:PartyTaxScheme/cbc:CompanyID |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Der Kundenstamm liefert die Umsatzsteuer-Identifikationsnummer des Käufers für jedes Dokument, auch für eines, bei dem Positionen und Rabatt vollständig nicht steuerbar sind.
- Ein Rabatt wird mit
Ogekennzeichnet, weil er selbst keine Steuer trägt, auf der Rechnung eines umsatzsteuerlich registrierten Verkäufers, dessen Nummern wie üblich geschrieben werden. - Der Nachlass übernimmt
Ovom Dokument, während der Parteienblock getrennt aus Firmen- und Kundeneinstellungen aufgebaut wird, und niemand gleicht beides ab.
So korrigieren Sie das Dokument
- Prüfen Sie, ob der Nachlass wirklich nicht steuerbar ist. Ein Rabatt folgt normalerweise der umsatzsteuerlichen Behandlung dessen, was er mindert; sind die Positionen steuerpflichtig, sollte der Nachlass ihre Kategorie tragen, nicht
O. - Ist das Dokument tatsächlich nicht steuerbar, löschen Sie jedes
cac:PartyTaxScheme, dessencac:TaxScheme/cbc:IDVATist, bei Käufer, Verkäufer undcac:TaxRepresentativeParty. Im aufgezeichneten Beispiel ist das der Block des Käufers mitGB987654321. - Lassen Sie beide Parteien auf anderem Weg identifiziert, etwa über
cac:PartyLegalEntity/cbc:CompanyID, die sie im aufgezeichneten Beispiel bereits haben (12345678und87654321). - Lassen Sie die Abbildung Umsatzsteuer-Identifikationsnummern unterdrücken, sobald eine Position, ein Nachlass oder ein Zuschlag in
Oist, statt nur die Positionen zu prüfen.
Vorher und nachher
Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.
Ausschnitt der fehlerhaften Rechnung: eine Umsatzsteuer-Identifikationsnummer des Käufers auf einem Dokument, dessen Treuerabatt in der Kategorie O steht
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<!-- postal address omitted from this fragment -->
<cac:PartyTaxScheme>
<cbc:CompanyID>GB987654321</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>95</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Loyalty discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="GBP">5.00</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>O</cbc:ID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>Ausschnitt der korrigierten Rechnung: Der Käufer behält nur seine Kennung der rechtlichen Registrierung
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
<!-- postal address omitted from this fragment -->
<cac:PartyLegalEntity>
<cbc:RegistrationName>Example Buyer Ltd</cbc:RegistrationName>
<cbc:CompanyID>87654321</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
<!-- the loyalty discount of 5.00 in category O, unchanged, omitted from this fragment -->Die fehlerhafte Rechnung ergänzt beim Käufer ein cac:PartyTaxScheme mit VAT und GB987654321; die korrigierte Rechnung hat für keine Partei eine Umsatzsteuer-Identifikationsnummer, und beide behalten den Nachlass über 5.00 und die Position in der Kategorie O. Das fehlerhafte Dokument meldet neben BR-O-03 auch BR-O-02, weil seine Position ebenfalls in O steht und diese Regel dieselbe Nummer des Käufers wegen der Position verbietet.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-O-02 und BR-O-03. Das korrigierte Dokument besteht jeden Prüfschritt ohne Befunde.Fehlerhaftes XML herunterladenKorrigiertes XML herunterladen
Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.
Wo die Regel gilt
- Gilt für UBL
InvoiceundCreditNote. Als Gutschrift umgeschrieben meldete die fehlerhafte Rechnung im Versuch dieselben zwei Befunde. - Zuschläge haben eine eigene Regel,
BR-O-04, und Positionen habenBR-O-02; die drei teilen die Liste der verbotenen Nummern und unterscheiden sich nur darin, was sie auslöst. - Derselbe Nachlass darf keinen Satz angeben (
BR-O-06), und sein Betrag wird im Steuerbasisbetrag fürOabgezogen, denBR-O-08prüft.
Verwandte Regeln
- BR-O-02 verbietet dieselben Nummern, wenn eine Position nicht steuerbar ist, und wird im Beispiel zusammen mit dieser Regel gemeldet
- BR-O-04 wendet dasselbe Verbot an, wenn ein Zuschlag auf Dokumentenebene nicht steuerbar ist
- BR-O-06 hält einen Umsatzsteuersatz von demselben nicht steuerbaren Nachlass fern
- BR-CO-26 verlangt eine andere Kennung des Verkäufers, sobald dessen Umsatzsteuer-Identifikationsnummer entfernt ist
- Alle Regeln der Referenz ansehen
- Hintergrund (auf Englisch): Understanding EN 16931 validation errors
Umfang und Quelle
Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.
Die offizielle Definition von BR-O-03 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.
Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.

