Auf dieser Seite
Die kurze Antwort
BR-O-11 schlägt fehl, wenn cac:TaxTotal ein cac:TaxSubtotal in der Kategorie O und zugleich eines in einer anderen Kategorie im Schema VAT enthält; das aufgezeichnete Beispiel fügt neben der Aufschlüsselung für O eine Aufschlüsselung zum Normalsatz mit 20 % hinzu. Nehmen Sie die Positionen der anderen Kategorie aus dem Dokument und stellen Sie sie gesondert in Rechnung, sodass jedes Dokument entweder vollständig nicht steuerbar ist oder gar kein O enthält.
Keine Anordnung des XML macht die Mischung gültig. Die Regeln von EN 16931 reservieren O für ein Dokument, das vollständig außerhalb der Umsatzsteuer liegt; ein Dokument, das nur teilweise außerhalb des Anwendungsbereichs der Umsatzsteuer liegt, lässt sich mit O nicht ausdrücken.
Was die Regel prüft
Die Regel liest nur die Aufschlüsselung auf Dokumentenebene. Sobald eine cac:TaxSubtotal/cac:TaxCategory im Schema VAT die cbc:ID O hat, muss die Zahl der Aufschlüsselungen in diesem Schema mit einer anderen cbc:ID null sein. Ein einziger Befund wird an der Wurzel gemeldet.
Positionen deckt BR-O-12 ab, die eine Position in einer anderen Kategorie in einem Dokument mit einer Aufschlüsselung für O abweist. Mit entfernter Aufschlüsselung zum Normalsatz, aber beibehaltener Position bestand diese Regel im Versuch, und BR-O-12 schlug zusammen mit BR-S-01 und BR-S-02 fehl.
Es gilt auch umgekehrt: Eine Aufschlüsselung zum Normalsatz neben Positionen in O, ohne Position zum Normalsatz dahinter, meldete im Versuch weiterhin BR-O-11, neben Befunden zur nicht gedeckten Aufschlüsselung.
Jede zweite Kategorie zählt, nicht nur S. Eine steuerbefreite Position und Aufschlüsselung anstelle derjenigen zum Normalsatz meldeten diese Regel, BR-O-12 und BR-E-02 für die fehlende Umsatzsteuer-Identifikationsnummer des Verkäufers.
Zwei Aufschlüsselungen für O werden dieser Regel nicht angerechnet, aber dieses Dokument wurde im Versuch von BR-O-01 und BR-O-08 abgewiesen.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BG-23 | Umsatzsteueraufschlüsselung | cac:TaxTotal/cac:TaxSubtotal |
| BT-118 | Code der Umsatzsteuerkategorie | cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID |
| BT-151 | Code der Umsatzsteuerkategorie des in Rechnung gestellten Artikels | cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (cac:CreditNoteLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID in a credit note) |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Eine einzige Rechnung verbindet einen steuerpflichtigen Verkauf mit einem Artikel, den das Quellsystem als nicht steuerbar kennzeichnet, und der Export schreibt eine Aufschlüsselung pro gefundener Kategorie.
- Artikel ohne Steuercode fallen standardmäßig auf
O, sodass eine gewöhnliche Rechnung zum Normalsatz versehentlich eine Position und Aufschlüsselung inOerhält. - Ein nicht umsatzsteuerlich registrierter Verkäufer verwendet durchgehend
O, aber ein Produkt oder Zuschlag trägt aus einer Vorlage oder Preisliste noch einen Steuercode zum Normalsatz.
So korrigieren Sie das Dokument
- Klären Sie, warum jede Position ihre Kategorie hat. Stammt die Position in
Oaus einem Standardwert für einen fehlenden Steuercode, korrigieren Sie den Steuercode an der Quelle; das Dokument braucht dann womöglich gar keinO. - Sind beide Arten von Leistungen echt, stellen Sie zwei Dokumente aus: eines nur mit den Positionen in
Ound der Aufschlüsselung fürO, ohne Umsatzsteuer-Identifikationsnummern, und eines mit den übrigen Positionen, ihren Aufschlüsselungen und den Umsatzsteuer-Identifikationsnummern, die diese Kategorien verlangen. - Berechnen Sie jede Summe auf jedem Dokument neu. Im aufgezeichneten Beispiel senkt das Entfernen der Position zum Normalsatz die Positionssumme von 35.00 auf 25.00, die Umsatzsteuersumme von 2.00 auf 0.00 und den fälligen Betrag von 37.00 auf 25.00.
- Stufen Sie die steuerpflichtige Position nicht in
Oum, um an der Regel vorbeizukommen. Die Kategorie gibt die umsatzsteuerliche Behandlung an, und sie zu ändern stellt die Leistung falsch dar.
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 Aufschlüsselung für O und eine zum Normalsatz in derselben Umsatzsteuersumme
<cac:TaxTotal>
<cbc:TaxAmount currencyID="GBP">2.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="GBP">25.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>O</cbc:ID>
<!-- reason code and text omitted from this fragment -->
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="GBP">10.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="GBP">2.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<!-- line 1 in category O at 25.00 and line 2 in category S at 20 for 10.00 omitted from this fragment -->Ausschnitt der korrigierten Rechnung: Nur die Aufschlüsselung für O bleibt, ohne Umsatzsteuer
<cac:TaxTotal>
<cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="GBP">25.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="GBP">0.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>O</cbc:ID>
<!-- reason code and text omitted from this fragment -->
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>Die fehlerhafte Rechnung fügt eine zweite Position hinzu, Example standard rated item zu 10.00 in der Kategorie S mit 20 %, mit passender Aufschlüsselung zum Normalsatz und auf 35.00 netto, 2.00 Umsatzsteuer und 37.00 fällig erhöhten Summen; die korrigierte Rechnung hat nur die Position und Aufschlüsselung in O. Das fehlerhafte Dokument meldet drei Befunde. BR-O-11 ist der Konflikt zwischen den Aufschlüsselungen. BR-O-12 ist derselbe Konflikt auf Positionsebene, da eine Position in S in einem Dokument mit einer Aufschlüsselung für O steht. BR-S-02 erscheint, weil eine Position zum Normalsatz eine Umsatzsteuer-Identifikationsnummer oder Steuernummer des Verkäufers braucht und dieser Verkäufer keine hat; das Hinzufügen einer Umsatzsteuer-Identifikationsnummer des Verkäufers beseitigte im Versuch BR-S-02 und brachte BR-O-02, das diese Nummer verbietet. Der Widerspruch ist die Lehre: Das gemischte Dokument lässt sich nicht gültig machen.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-O-11,
BR-O-12und BR-S-02. 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 ergab die fehlerhafte Rechnung im Versuch dieselben drei Befunde. - Kennungen können ein gemischtes Dokument nicht retten. Im Versuch beseitigte eine Steuernummer des Verkäufers im Schema
TAXden BefundBR-S-02, ohneBR-O-02auszulösen, undBR-O-11undBR-O-12schlugen weiterhin fehl. - Nach einer Aufteilung muss jedes Dokument für sich aufgehen:
BR-CO-10,BR-CO-13,BR-CO-14undBR-CO-15prüfen seine Summen.
Verwandte Regeln
- BR-O-02 verbietet die Umsatzsteuer-Identifikationsnummern, die die anderen Kategorien eines gemischten Dokuments bräuchten
- BR-S-02 wird neben dieser Regel gemeldet, wenn die hinzugefügte Position zum Normalsatz steht und der Verkäufer keine Umsatzsteuer-Identifikationsnummer hat
- BR-S-01 verlangt eine Aufschlüsselung zum Normalsatz für Positionen zum Normalsatz; nur die Aufschlüsselung zu entfernen hilft daher nicht
- BR-CO-14 prüft die Umsatzsteuersumme gegen die Aufschlüsselungen, sobald die Dokumente getrennt sind
- 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-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-24.
Die offizielle Definition von BR-O-11 (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.

