Auf dieser Seite
Die kurze Antwort
BR-04 schlägt fehl, wenn das Wurzelelement keinen Typcode mit Wert hat: kein cbc:InvoiceTypeCode in einer Invoice, kein cbc:CreditNoteTypeCode in einer CreditNote, oder ein leeres Element. Fügen Sie das Element mit dem Code für die Art des Dokuments ein, das Sie senden: 380 für eine Handelsrechnung oder 381 für eine Gutschrift.
Das UBL-Schema behandelt den Typcode als optional, daher besteht der XSD-Prüfschritt ohne ihn, und diese Regel aus EN 16931 beanstandet ihn als erste.
Was die Regel prüft
Die Regel läuft einmal pro Dokument, am Wurzelelement. Sie ist erfüllt, wenn eines der beiden Typcode-Elemente direkt unter dem Wurzelelement anderen Text als Leerraum enthält.
Ein fehlendes Element ergibt nur BR-04, wie im aufgezeichneten Beispiel, weil die Codelisten-Regeln kein Element zum Prüfen haben. Ein leeres oder nur aus Leerraum bestehendes Element ergab im Versuch vier Befunde: BR-04, BR-CL-01, die Peppol-Regel für den Typcode dieses Wurzelelements (PEPPOL-EN16931-P0100 oder PEPPOL-EN16931-P0101) und PEPPOL-EN16931-R008.
Die Regel beurteilt den Wert nicht. Jeder nicht leere Text erfüllt sie; ob der Code zulässig ist, entscheiden BR-CL-01 und die Peppol-Profilregeln.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-3 | Code für den Rechnungstyp | cbc:InvoiceTypeCode (cbc:CreditNoteTypeCode 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:
- Das Mapping wurde für ein Format gebaut, in dem der Nachrichtentyp den Dokumenttyp vorgibt, und nichts setzt das UBL-Element.
- Der Typcode wird aus einem Konfigurationswert gefüllt, der in dieser Umgebung fehlt, und der Serialisierer lässt das Element weg.
- Eine Gutschriftvorlage wurde aus der Rechnungsvorlage abgeleitet, und die Zeile mit dem Rechnungstypcode wurde gelöscht, ohne an ihrer Stelle
cbc:CreditNoteTypeCodeeinzufügen.
So korrigieren Sie das Dokument
- Legen Sie fest, was das Dokument geschäftlich ist, und wählen Sie den Code aus der Peppol-Liste für dieses Wurzelelement:
380für eine gewöhnliche Rechnung,381für eine gewöhnliche Gutschrift. - Geben Sie
cbc:InvoiceTypeCodean seiner Schemaposition aus: nachcbc:IssueDateundcbc:DueDate, vorcbc:Note,cbc:TaxPointDateundcbc:DocumentCurrencyCode, soweit vorhanden. Nachcbc:DocumentCurrencyCodeplatziert, scheiterte es im Versuch am XSD-Prüfschritt. - Geben Sie in einer
CreditNotestattdessencbc:CreditNoteTypeCodeaus; der Elementname der Rechnung ist dort nicht gültig. - Machen Sie den Code zu einer Pflichtausgabe des Mappings, damit ein fehlender Wert den Export stoppt, statt das Element stillschweigend wegzulassen.
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: Der Kopf geht vom Fälligkeitsdatum direkt zur Währung über
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<!-- no cbc:InvoiceTypeCode in the failing document -->
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>Ausschnitt der korrigierten Rechnung: 380, Handelsrechnung, zwischen Fälligkeitsdatum und Währung
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>Die korrigierte Rechnung enthält <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> zwischen Fälligkeitsdatum und Währungscode; die fehlerhafte Rechnung hat überhaupt kein Typcode-Element. Das fehlerhafte Dokument meldet nur BR-04. Ohne vorhandenes Element haben weder BR-CL-01 noch PEPPOL-EN16931-P0100 einen Wert zu prüfen, daher besteht der Peppol-Prüfschritt.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-04. 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. Eine Gutschrift ohnecbc:CreditNoteTypeCodemeldete im Versuch diese Regel und bestand ebenfalls den XSD-Prüfschritt. - Der Befund stammt aus dem Prüfschritt EN 16931. Peppol hat keine eigene Vorhandenseinsregel für den Typcode.
- Sobald das Element vorhanden ist, wird sein Wert von
BR-CL-01gegen die Liste aus EN 16931 geprüft und vonPEPPOL-EN16931-P0100oderPEPPOL-EN16931-P0101gegen die engere Peppol-Liste.
Verwandte Regeln
- BR-CL-01 prüft den Wert des Typcodes gegen die Listen aus EN 16931, sobald er vorhanden ist
- PEPPOL-EN16931-P0100 beschränkt die Typcodes von Rechnungen auf die Peppol-Liste
- PEPPOL-EN16931-P0101 beschränkt die Typcodes von Gutschriften auf die Peppol-Liste
- PEPPOL-EN16931-R008 kommt zu dieser Regel hinzu, wenn das Typcode-Element vorhanden, aber leer 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-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-24.
Die offizielle Definition von BR-04 (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.

