Attestwire › Rule reference › BR-DE-26

BR-DE-26 A corrected invoice must say what it corrects

noun · XRechnung · warning · BG-3 / BT-25

Your invoice carries a warning because it is marked as a corrected invoice but does not say which invoice it corrects. Give the number of the original invoice. KoSIT rates this a warning, so the invoice is accepted. In the standard this is group BG-3 with field BT-25, when the invoice type code in BT-3 is 384; BR-DE-26 is the rule that asks for the reference.

Diese Regel auf Deutsch: BR-DE-26 — auf Deutsch erklärt.

Business term

BG-3 / BT-25 — Preceding invoice reference

Severity

warning

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Name the corrected invoice in precedingInvoices, for example [{ "invoiceNumber": "2026-000141", "issueDate": "2026-07-31" }].

What the rule requires

With invoice type code 384 (corrected invoice), group BG-3 (preceding invoice reference) belongs in the document at least once, with the invoice number (BT-25) of the corrected invoice.

The issue date (BT-26) is optional; give it anyway. It is what lets your customer find the original when your numbering has been reset in the meantime.

If no correction was meant, 380 (commercial invoice) is the right code.

In this library the group is precedingInvoices.

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.

A passing value

"invoiceTypeCode": "384", "precedingInvoices": [{ "invoiceNumber": "2026-000141", "issueDate": "2026-07-31" }]

Why it exists

A correction without a reference leaves your customer with two documents for one supply and no way to net them, and your own VAT return cannot show which period the correction belongs to. KoSIT rates the rule a warning, so the document is accepted; the reconciliation problem arises anyway.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "BR-DE-26",
  "field": [
    "BG-3",
    "BT-25"
  ],
  "severity": "warning",
  "message": "The invoice type code (BT-3) is \"384\" (corrected invoice), so the PRECEDING INVOICE REFERENCE group (BG-3) should be present at least once, carrying the number of the invoice being corrected (BT-25). A correction that does not say what it corrects leaves the buyer holding two documents for one supply with no way to net them — and leaves your own VAT return unable to show which period the adjustment belongs to. KoSIT flags this `warning` rather than `fatal`, so the document is accepted; the reconciliation problem it creates is not.",
  "fix": "Set precedingInvoices to the invoice you are correcting — [{ \"invoiceNumber\": \"2026-000141\", \"issueDate\": \"2026-07-31\" }]. The issue date (BT-26) is optional and worth supplying: it is what lets the buyer find the original when your numbering has been reset. If no correction is intended, use \"380\" (commercial invoice) instead.",
  "example": "\"invoiceTypeCode\": \"384\", \"precedingInvoices\": [{ \"invoiceNumber\": \"2026-000141\", \"issueDate\": \"2026-07-31\" }]",
  "xpath": "/ubl:Invoice/cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID",
  "docsUrl": "https://attestwire.com/rules/BR-DE-26"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-55 — the invoice number inside each reference; BR-DE-17 — the invoice type codes XRechnung accepts.