Attestwire › Rule reference › ATW-CREDIT-NOTE-NO-PRECEDING-INVOICE
ATW-CREDIT-NOTE-NO-PRECEDING-INVOICE This credit note names no preceding invoice (BG-3 / BT-25)
This credit note names no preceding invoice (BG-3 / BT-25). No rule requires one: BR-DE-26 is often read as demanding it, and it does not — its test fires on the corrected-invoice code 384, on either document type, and never on 381. KoSIT accepts a credit note with no reference, and so does the EN 16931 schematron. What it leaves is a reconciliation problem: the buyer holds a credit with nothing to net it against, and your own VAT return cannot show which supply the adjustment belongs to. A credit note that says what it credits is the ordinary case, which is why this is worth one line of advice at the level the regulator uses for advice.
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
information
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "ATW-CREDIT-NOTE-NO-PRECEDING-INVOICE",
"field": [
"BG-3",
"BT-25"
],
"severity": "information",
"message": "This credit note names no preceding invoice (BG-3 / BT-25). No rule requires one: BR-DE-26 is often read as demanding it, and it does not — its test fires on the corrected-invoice code 384, on either document type, and never on 381. KoSIT accepts a credit note with no reference, and so does the EN 16931 schematron. What it leaves is a reconciliation problem: the buyer holds a credit with nothing to net it against, and your own VAT return cannot show which supply the adjustment belongs to. A credit note that says what it credits is the ordinary case, which is why this is worth one line of advice at the level the regulator uses for advice.",
"fix": "Set precedingInvoices to the invoice being credited — [{ \"invoiceNumber\": \"2026-000142\", \"issueDate\": \"2026-08-09\" }]. BT-26, the issue date, is optional and worth supplying: it is what lets the buyer find the original after a numbering reset. If the credit note is genuinely standalone (a goodwill credit, a volume rebate over many invoices), leave it out — that is a real case and this finding is advisory for exactly that reason.",
"example": "\"precedingInvoices\": [{ \"invoiceNumber\": \"2026-000142\", \"issueDate\": \"2026-08-09\" }]",
"xpath": "/ubl:CreditNote/cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID",
"docsUrl": "https://github.com/attestwire/en16931#not-implemented-yet"
}
xpath locates the element in a UBL
document, which is where a KoSIT or Peppol validator will report the
same problem. It is a UBL path on every profile. A
xrechnung-cii or facturx-en16931 invoice
gets the same string, so map it to the CII element yourself.
A passing value
"precedingInvoices": [{ "invoiceNumber": "2026-000142", "issueDate": "2026-08-09" }]The fix
Set precedingInvoices to the invoice being credited — [{ "invoiceNumber": "2026-000142", "issueDate": "2026-08-09" }]. BT-26, the issue date, is optional and worth supplying: it is what lets the buyer find the original after a numbering reset. If the credit note is genuinely standalone (a goodwill credit, a volume rebate over many invoices), leave it out — that is a real case and this finding is advisory for exactly that reason.