AttestwireRule referenceATW-CREDIT-NOTE-PROJECT-REFERENCE-UNBOUND

ATW-CREDIT-NOTE-PROJECT-REFERENCE-UNBOUND This credit note states a project reference (BT-11 = "PRJ-ERECHNUNG-2026"), and a UBL CreditNote cannot carry one

This credit note states a project reference (BT-11 = "PRJ-ERECHNUNG-2026"), and a UBL CreditNote cannot carry one. cac:ProjectReference is not in UBL-CreditNote-2.1.xsd at all — it exists on Invoice and on nothing else — so the reference will be **absent from the generated UBL document**. This is a hole in the syntax rather than in this library or in EN 16931: the CII binding has ram:SpecifiedProcuringProject and keeps it, so generateCii on this same input loses nothing.

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-11
Severity
warning

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "ATW-CREDIT-NOTE-PROJECT-REFERENCE-UNBOUND",
  "field": "BT-11",
  "severity": "warning",
  "message": "This credit note states a project reference (BT-11 = \"PRJ-ERECHNUNG-2026\"), and a UBL CreditNote cannot carry one. cac:ProjectReference is not in UBL-CreditNote-2.1.xsd at all — it exists on Invoice and on nothing else — so the reference will be **absent from the generated UBL document**. This is a hole in the syntax rather than in this library or in EN 16931: the CII binding has ram:SpecifiedProcuringProject and keeps it, so generateCii on this same input loses nothing.",
  "fix": "Drop projectReference, or move the project identifier somewhere the document can hold it: buyerAccountingReference (BT-19, the buyer's cost centre) is the usual home, and contractReference (BT-12) or invoicedObjectIdentifier (BT-18) fit some processes better. If the project reference is load-bearing for your buyer, emit the credit note as CII instead — profile \"xrechnung-cii\" keeps it.",
  "example": "\"buyerAccountingReference\": \"PRJ-ERECHNUNG-2026\"",
  "xpath": "/ubl:CreditNote",
  "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

the shape this field expects
"buyerAccountingReference": "PRJ-ERECHNUNG-2026"

The fix

Drop projectReference, or move the project identifier somewhere the document can hold it: buyerAccountingReference (BT-19, the buyer's cost centre) is the usual home, and contractReference (BT-12) or invoicedObjectIdentifier (BT-18) fit some processes better. If the project reference is load-bearing for your buyer, emit the credit note as CII instead — profile "xrechnung-cii" keeps it.

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.