Attestwire › Rule reference › ATW-CREDIT-NOTE-DUE-DATE-UNBOUND
ATW-CREDIT-NOTE-DUE-DATE-UNBOUND This credit note states a payment due date (BT-9 = "2026-09-08") and no payment instructions (BG-16)
This credit note states a payment due date (BT-9 = "2026-09-08") and no payment instructions (BG-16). A UBL CreditNote has no cbc:DueDate element: EN 16931 binds BT-9 to cac:PaymentMeans/cbc:PaymentDueDate on that document, and UBL's PaymentMeans requires a payment means code (BT-81), so without BG-16 there is no lawful element to carry the date. It will be **absent from the generated UBL document**. In CII the same input is unaffected — BT-9 has its own element there — so this finding is about the UBL binding, not about your data.
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
BT-9 / BG-16- Severity
warning
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-DUE-DATE-UNBOUND",
"field": [
"BT-9",
"BG-16"
],
"severity": "warning",
"message": "This credit note states a payment due date (BT-9 = \"2026-09-08\") and no payment instructions (BG-16). A UBL CreditNote has no cbc:DueDate element: EN 16931 binds BT-9 to cac:PaymentMeans/cbc:PaymentDueDate on that document, and UBL's PaymentMeans requires a payment means code (BT-81), so without BG-16 there is no lawful element to carry the date. It will be **absent from the generated UBL document**. In CII the same input is unaffected — BT-9 has its own element there — so this finding is about the UBL binding, not about your data.",
"fix": "Supply payment instructions: `payment: { meansCode: \"58\", iban: \"…\" }` for a SEPA credit transfer, or \"1\" if the code is genuinely unknown. XRechnung requires BG-16 anyway under BR-DE-1, so a document that hits this finding is usually one field short of two rules at once. If the credit note is settled by netting rather than by payment, drop dueDate — a date nobody will pay on is worse than no date.",
"example": "\"dueDate\": \"2026-09-08\", \"payment\": { \"meansCode\": \"58\", \"iban\": \"DE02120300000000202051\" }",
"xpath": "/ubl:CreditNote/cac:PaymentMeans/cbc:PaymentDueDate",
"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
"dueDate": "2026-09-08", "payment": { "meansCode": "58", "iban": "DE02120300000000202051" }The fix
Supply payment instructions: `payment: { meansCode: "58", iban: "…" }` for a SEPA credit transfer, or "1" if the code is genuinely unknown. XRechnung requires BG-16 anyway under BR-DE-1, so a document that hits this finding is usually one field short of two rules at once. If the credit note is settled by netting rather than by payment, drop dueDate — a date nobody will pay on is worse than no date.