Account
English

BR-DE-26: Corrected invoice (384) without preceding invoice reference

XRechnung rule · Warning · UBL / CII

StandardXRechnung 3.0.2 (KoSIT, German CIUS of EN 16931)SeverityWarning: the invoice is accepted but should be correctedSyntaxUBL, CIIBusiness terms
  • BG-3 Preceding invoice reference
  • BT-3 Invoice type code
Applies toXRechnung 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.

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:CreditNote

Test (XPath):

((not(normalize-space(cbc:InvoiceTypeCode) = '384' or normalize-space(cbc:CreditNoteTypeCode) = '384') or                     (cac:BillingReference/cac:InvoiceDocumentReference)))

CII

/rsm:CrossIndustryInvoice

Test (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.

Check your invoice →

Same check via API:

curl -F file=@invoice.xml https://einvoicechecker.com/v1/validate

Related rules

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.