attestwireAttestwire › Rule reference › BR-DE-26
BR-DE-26 A corrected invoice should reference the invoice it corrects
noun · XRechnung · warning · BG-3 / BT-25
For a sample invoice, the library reports: 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).
Diese Regel auf Deutsch: BR-DE-26 — auf Deutsch erklärt.
- Business term
BG-3 / BT-25- Severity
warning
The 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.
A passing value
"invoiceTypeCode": "384", "precedingInvoices": [{ "invoiceNumber": "2026-000141", "issueDate": "2026-07-31" }]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.