attestwireAttestwire › XRechnung-Regeln › BR-DE-17
BR-DE-17 XRechnung schränkt die Rechnungsarten auf acht Codes ein
Ihre Rechnung wurde nicht abgelehnt, aber mit einem Hinweis versehen: Der Code für den Rechnungstyp gehört nicht zu den acht, die XRechnung vorsieht (326, 380, 381, 384, 389, 875, 876, 877). KoSIT, die Stelle, die den offiziellen Prüfer veröffentlicht, stuft das als „warning“ (Hinweis) ein; die Rechnung wird angenommen. Wir empfehlen trotzdem, bei den acht Codes zu bleiben. Im Standard ist das Feld BT-3; BR-DE-17 ist die Regel, die die Liste einschränkt.
Die Regelnummer bezeichnet die fehlgeschlagene Prüfung. BT steht für ein Rechnungsfeld, BG für eine Gruppe von Feldern. XRechnung ergänzt die europäische Norm EN 16931 um deutsche Anforderungen (CIUS).
- Informationselement
BT-3- Schweregrad
warning— Warnung: weitere Prüfung erforderlich- Gilt für
xrechnung-ubl, xrechnung-cii- Regelwerk
- XRechnung-CIUS (KoSIT) — nationale Verschärfung der EN 16931
Die Lösung
Nehmen Sie "380" für die normale Handelsrechnung, "384" für eine Rechnungskorrektur (dann zusätzlich precedingInvoices setzen, siehe BR-DE-26), "326" für eine Teilrechnung, "389" für die Selbstabrechnung, "381" für eine Gutschrift. Das Feld heißt invoiceTypeCode.
Ein Wert, der die Prüfung besteht
"invoiceTypeCode": "380"Was die Regel verlangt
Verwenden Sie für den Rechnungstyp (BT-3) einen der acht Codes aus UNTDID 1001, die XRechnung nennt: 326 Teilrechnung, 380 Handelsrechnung, 381 Gutschrift, 384 Rechnungskorrektur, 389 Selbstabrechnung (Gutschriftverfahren), sowie 875, 876 und 877 für Abschlagsrechnungen im Bauwesen.
Es ist eine Regel für beide Dokumentarten. Das KoSIT-Schematron prüft cbc:InvoiceTypeCode und cbc:CreditNoteTypeCode gegen dieselbe Achterliste — eine Gutschrift wird also an genau denselben acht Codes gemessen.
Der deutsche Wortlaut sagt „sollen“, und KoSIT vergibt entsprechend die Stufe warning (Hinweis) statt fatal (Ablehnung). Die weitere UNTDID-Liste bleibt unter der EN 16931 zulässig. Lesen Sie den Befund als Kompatibilitätshinweis, nicht als Ablehnung.
Der offizielle Regeltext
Die Regel BR-DE-17 stammt aus der XRechnung-CIUS und
wird im Schematron der KoSIT geführt, den offiziellen Prüfregeln.
Ein wörtliches Zitat des Regeltextes liegt uns für diese Regel nicht
vor; was Sie oben lesen, ist unsere Erklärung. Maßgeblich ist die
Veröffentlichung der KoSIT.
Warum es die Regel gibt
Ein Empfängersystem verzweigt nach dem Typcode: Rechnung buchen, Korrektur verrechnen, Gutschrift erstatten. Die acht Codes sind die, die XRechnung für Rechnungen an die öffentliche Hand nennt. KoSIT warnt bei einem anderen Code nur, und das Portal nimmt die Rechnung an; wir empfehlen dennoch, bei den acht zu bleiben, damit der Empfänger einen Code vorfindet, den er erwartet.
So sieht der Befund aus
Genau dieses Objekt liefert die Bibliothek in
result.warnings,
wenn die Regel anschlägt. Es wird beim Bauen dieser Seite durch
Ausführen von @attestwire/en16931 erzeugt und entspricht
dem Text, den Sie in Ihrem eigenen Log sehen. Die Meldung selbst ist
englisch, weil die Bibliothek englisch meldet.
{
"rule": "BR-DE-17",
"field": "BT-3",
"severity": "warning",
"message": "XRechnung asks that the invoice type code (BT-3) be one of 326, 380, 381, 384, 389, 875, 876 and 877 from UNTDID 1001, but \"999\" was supplied. The rule is one rule across both document types: KoSIT's schematron tests `cbc:InvoiceTypeCode = $supportedInvAndCNTypeCodes or cbc:CreditNoteTypeCode = $supportedInvAndCNTypeCodes`, against one eight-code list, so a credit note is held to exactly the same eight. The German text says \"sollen\", and KoSIT flags the rule \"warning\" rather than \"fatal\": the document is accepted, and the wider UNTDID list stays legal under core EN 16931. Treat it as a portal-compatibility finding rather than a rejection — a receiving system that only branches on the eight listed codes will not know what to do with yours, which is a slower and more expensive failure than a bounce.",
"fix": "Use \"380\" for a commercial invoice, \"384\" for a corrected invoice (and then also supply precedingInvoices with the number of the invoice you are correcting, BR-DE-26), \"326\" for a partial invoice, \"389\" for self-billing, \"381\" for a credit note. All eight generate: \"381\" and the rest of the UNTDID 1001 credit-note list emit a ubl:CreditNote in the UBL syntax and a CrossIndustryInvoice with ram:TypeCode 381 in CII.",
"example": "\"invoiceTypeCode\": \"380\"",
"xpath": "/ubl:Invoice/cbc:InvoiceTypeCode",
"docsUrl": "https://attestwire.com/rules/BR-DE-17"
}
xpath zeigt auf das Element in einem
UBL-Dokument — dort meldet auch ein KoSIT-Validator
denselben Mangel. Bei einer CII-Rechnung
(xrechnung-cii, ZUGFeRD, Factur-X) erhalten Sie dieselbe
Zeichenkette und müssen sie selbst auf das CII-Element übertragen.
Häufige Fragen
- Was bedeutet BR-DE-17?
- Ihre Rechnung wurde nicht abgelehnt, aber mit einem Hinweis versehen: Der Code für den Rechnungstyp gehört nicht zu den acht, die XRechnung vorsieht (326, 380, 381, 384, 389, 875, 876, 877). KoSIT, die Stelle, die den offiziellen Prüfer veröffentlicht, stuft das als „warning“ (Hinweis) ein; die Rechnung wird angenommen. Wir empfehlen trotzdem, bei den acht Codes zu bleiben. Im Standard ist das Feld BT-3; BR-DE-17 ist die Regel, die die Liste einschränkt.
- Wie behebe ich BR-DE-17?
- Nehmen Sie "380" für die normale Handelsrechnung, "384" für eine Rechnungskorrektur (dann zusätzlich precedingInvoices setzen, siehe BR-DE-26), "326" für eine Teilrechnung, "389" für die Selbstabrechnung, "381" für eine Gutschrift. Das Feld heißt invoiceTypeCode.
- Ist BR-DE-17 Pflicht für XRechnung?
- Teil des Standards, aber als „warning“ (Hinweis) eingestuft: Die Rechnung wird angenommen. Wir empfehlen trotzdem einen der acht Codes.