BR-DE-26 — E-Invoice Validation Rule & Fix

Fixture ID: correctedInvoice · XPath: /ubl:Invoice/cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID

1. Why This Rule Triggers (Diagnostic 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.

2. How to Fix BR-DE-26

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.

3. Valid Code / Payload Example

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