Fehler BR-DE-21 beheben: Ungültiger Rechnungsartcode in BT-3
Nach dem deutschen Standard XRechnung (BR-DE-21) sind für BT-3 nur bestimmte UNTDID 1001 Codes zulässig: 326 (Teilrechnung), 380 (Handelsrechnung), 381 (Gutschrift), 384 (Korrekturrechnung) oder 389 (Eigenrechnung).
Eigene Rechnung hier hineinziehen
oder Datei vom Computer auswählen (.pdf oder .xml bis 10 MB)
Vorausgefüllter, normkonformer JSON-Payload gegen unser InvoiceRequest-Modell. Du kannst die Werte direkt editieren:
zg_test_ouroboros_001 (sofortige PDF/A-3 Generierung).
Code-Vergleich: Falsches vs. Korrektes CII-XML
<!-- FEHLER: Code 388 oder Text 'Invoice' ist nach BR-DE-21 nicht zulässig -->
<rsm:ExchangedDocument>
<ram:ID>RE-2026-001</ram:ID>
<ram:TypeCode>388</ram:TypeCode> <!-- UNGÜLTIG: Wird von XRechnung Prüftool abgewiesen -->
<ram:IssueDateTime>
<udt:DateTimeString format="102">20261023</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<!-- KORREKT: Typcode 380 (Commercial Invoice) nach UNTDID 1001 -->
<rsm:ExchangedDocument>
<ram:ID>RE-2026-001</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20261023</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
Technische Ursache & Lösung
Während die europäische Kernnorm EN 16931 eine breite Palette an Dokumententypen erlaubt, schränkt die deutsche CIUS XRechnung die Liste über die Prüfregel BR-DE-21 streng ein.
Zulässig sind ausschließlich: - 380: Handelsrechnung (Commercial Invoice) - 381: Gutschrift (Credit Note) - 384: Korrekturrechnung (Corrected Invoice) - 326: Teilrechnung (Partial Invoice) - 389: Eigenrechnung (Self-billed Invoice)
Wird beispielsweise der generische Code 388 (Tax Invoice) oder ein Freitext verwendet, verweigert der Validator die Zertifizierung. Unsere API setzt standardmäßig immer den passenden, normierten Code 380.
Keine Lust auf XML-Schematron-Fehler und Rundungsdifferenzen?
Unsere E-Rechnung Cloud API übernimmt alle mathematischen Berechnungen, Steuerregeln, XSD-Schemata und die PDF/A-3 Konvertierung vollautomatisch im Hintergrund.
Häufig gestellte Fragen (FAQ)
Welcher Code muss für eine normale B2B-Rechnung verwendet werden?
Für reguläre Handelsrechnungen ist der UNTDID-Code 380 vorgeschrieben.
Welchen Code nutze ich für eine Rechnungskorrektur oder Storno?
Für Korrekturen wird Code 384 verwendet; für kaufmännische Gutschriften Code 381.
Muss ich den TypeCode in der API manuell übergeben?
Nein, unsere API wählt automatisch den normgerechten Code 380 nach UNTDID 1001, sodass BR-DE-21 stets erfüllt ist.
Passende Themen & Normen
Alle 12 Themen ansehen →BT-3 Rechnungsarten: Rechnung (380), Gutschrift (381) & Korrektur (384)
Die UNTDID 1001 Rechnungsart-Codes in BT-3 verstehen: Wann nutzt man Code 380, 381 oder 384 in ZUGFeRD & XRechnung? Mit Praxis-Beispielen und XML-Tags.
BR-DE-01Fehler BR-DE-01 beheben: Zahlungsbedingungen in XRechnung & ZUGFeRD
Löse den Schematron-Fehler BR-DE-01 in deiner E-Rechnung. Ursachen, XML-Codebeispiele (CII) und Vorlage zur normgerechten Angabe von Zahlungsbedingungen.
BR-DE-15Fehler BR-DE-15 beheben: Käuferreferenz / Leitweg-ID (BT-10) in XRechnung
So behebst du den Fehler BR-DE-15 in XRechnung & ZUGFeRD. Erfahre, wo die Leitweg-ID (BT-10) im CII-XML eingetragen werden muss inkl. XML-Vergleich & API-Payload.
PDF-OVERLAY (/EMBED)Bestehende PDF-Rechnung in ZUGFeRD umwandeln: Factur-X XML einbetten
Verwandle fertige Rechnungs-PDFs mit POST /v1/invoice/embed in gültige PDF/A-3 E-Rechnungen mit eingebettetem XML. Ohne dein bestehendes Layout zu verändern.