BR-DE-17: what it means and how to fix it
The invoice type code should be one of 326, 380, 384, 389, 381, 875, 876 or 877.
| Rule | BR-DE-17 |
|---|---|
| Standard | XRechnung 3.0 (the German CIUS of EN 16931, published by KoSIT) |
| Severity | Warning |
| Concerns | BT-3: Invoice type code |
How to fix it
Use 380 for an invoice, 381 for a credit note or 384 for a corrected invoice.
Where the field is in the XML
| Term | CII (XRechnung-CII, ZUGFeRD, Factur-X) | UBL (XRechnung-UBL, Peppol) |
|---|---|---|
| BT-3 Invoice type code | rsm:ExchangedDocument/ram:TypeCode | cbc:InvoiceTypeCode |
From your code
curl -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/xml" \
--data-binary @invoice.xml "https://agent-data-tools.revmesh2074.workers.dev/einvoice/validate"The answer lists every broken rule with its number, the field, a message with the figures from your file and the fix. E-invoice API: validate, convert to JSON, and create XRechnung or ZUGFeRD XML from JSON.
Questions
What does BR-DE-17 mean?
The invoice type code should be one of 326, 380, 384, 389, 381, 875, 876 or 877. It is a rule of XRechnung 3.0 (the German CIUS of EN 16931, published by KoSIT).
How do I fix BR-DE-17?
Use 380 for an invoice, 381 for a credit note or 384 for a corrected invoice.
Is BR-DE-17 an error or a warning?
A warning: the invoice is still conformant, but the value should be corrected.
Does BR-DE-17 apply to ZUGFeRD and Factur-X too?
Only when the file declares the XRechnung specification identifier (the ZUGFeRD profile "XRECHNUNG" does). Files in the plain EN 16931 profile are checked against the European rules, not the German additions.
Related rules
- BR-04: An invoice must have an invoice type code.
Rule numbers are those of XRechnung 3.0 (KoSIT); the explanation is ours. Not tax or legal advice.