BG-3Preceding invoice referenceBT-3Invoice type code
Official rule text
[BR-DE-26] If the code 384 (Corrected invoice) is transmitted in the element "Invoice type code" (BT-3), PRECEDING INVOICE REFERENCE BG-3 shall be present at least once.
Official text (German): Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.
Why this error occurs
When the invoice type code (BT-3) is 384 (corrected invoice), XRechnung expects at least one preceding invoice reference (BG-3) so the receiver can link the correction to the original. The rule looks for cac:BillingReference/cac:InvoiceDocumentReference (UBL) or ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument (CII) whenever the type code is 384. It fails when the original invoice number is only mentioned in a note or in the line text.
How to fix it
In UBL add cac:BillingReference/cac:InvoiceDocumentReference with cbc:ID (number of the corrected invoice, BT-25) and cbc:IssueDate (BT-26), placed after cac:OrderReference. In CII add ram:InvoiceReferencedDocument with ram:IssuerAssignedID and ram:FormattedIssueDateTime/qdt:DateTimeString format="102" inside ram:ApplicableHeaderTradeSettlement. One reference per corrected invoice; if the correction only partially reverses, consider a credit note (381) with the same reference instead. This is a warning, but authorities usually insist on it.
Example (valid)
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
...
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>RE-2026-00100</cbc:ID>
<cbc:IssueDate>2026-09-30</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
What the validator checks
Checked element (context):
UBL
/ubl:Invoice | /cn:CreditNoteTest (XPath):
((not(normalize-space(cbc:InvoiceTypeCode) = '384' or normalize-space(cbc:CreditNoteTypeCode) = '384') or (cac:BillingReference/cac:InvoiceDocumentReference)))CII
/rsm:CrossIndustryInvoiceTest (XPath):
not(normalize-space(rsm:ExchangedDocument/ram:TypeCode) = '384') or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument)
Check your invoice
Drop your XML or PDF on the validator and every failed rule is linked to its page here. Free, no account, the file is not stored.
Same check via API:
curl -F file=@invoice.xml https://einvoicechecker.com/v1/validateRelated rules
BR-DE-17Invoice type code is not in the XRechnung subsetBR-DE-1Payment instructions (BG-16) are missingBR-DE-2Seller contact (BG-6) is missingBR-DE-3Seller city (BT-37) is missingBR-DE-4The element "Seller post code" must be transmittedBR-DE-5Seller contact point (BT-41) is missingBR-DE-6Seller contact telephone number (BT-42) is missingBR-DE-7Seller contact email address (BT-43) is missing
Frequently asked questions
What does BR-DE-26 mean?
BR-DE-26 is a xrechnung rule: If the code 384 (Corrected invoice) is transmitted in the element "Invoice type code" (BT-3), PRECEDING INVOICE REFERENCE BG-3 shall be present at least once.
Will my invoice be rejected because of BR-DE-26?
No. BR-DE-26 is a warning: the invoice is accepted but the recipient sees the notice. Fix it anyway, warnings often become errors in later rule versions.
Which formats does BR-DE-26 apply to?
XRechnung in UBL or CII syntax, including ZUGFeRD / Factur-X PDFs with the XRECHNUNG profile. Invoices to German public authorities (federal, state and municipal) must pass it. Syntax: UBL and CII.
Source: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Catalogue generated from the official schematron on 2026-10-14.