BR-DE-26 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)
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.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BG-3 / BT-25- Severity
warning
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"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 locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"invoiceTypeCode": "384", "precedingInvoices": [{ "invoiceNumber": "2026-000141", "issueDate": "2026-07-31" }]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.