BR-DE-26
The invoice is marked as a correction but does not say what it corrects.
Why it happens
Type code 384 used without a reference to the original invoice.
How to fix it
Add cac:BillingReference/cac:InvoiceDocumentReference with the original invoice number, or change the type code if this is not actually a correction.
The official rule
XRechnung, official German wordingWenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.
Our English rendering: If "Invoice type code" (BT-3) is 384 (corrected invoice), PRECEDING INVOICE REFERENCE (BG-3) should be present at least once.
Technical detail — where the rule is evaluated and the exact test
| Syntax | Context and assertion |
|---|---|
| UBL | /ubl:Invoice | /cn:CreditNote |
((not(normalize-space(cbc:InvoiceTypeCode) = '384' or normalize-space(cbc:CreditNoteTypeCode) = '384') or (cac:BillingReference/cac:InvoiceDocumentReference))) | |
| CII | /rsm:CrossIndustryInvoice |
not(normalize-space(rsm:ExchangedDocument/ram:TypeCode) = '384') or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument) |
Check your own invoice
Paste or drop your UBL or CII file into the free validator. It runs the official EN 16931 ruleset plus the German XRechnung layer and lists every rule that fires, BR-DE-26 included — no signup, no limit.
Validate an e-invoice freeFixing the data at source instead? The CSV converter builds a compliant invoice from a spreadsheet export.