UBL-CR-665: Remove the schemeID attribute from the identifier of a document reference other than the invoiced object

The short answer

UBL-CR-665 is a warning raised when the identifier of a document reference other than the invoiced object (cac:AdditionalDocumentReference/cbc:ID) carries a schemeID attribute. EN 16931 does not use the attribute there, so remove it and keep the element with its value. On a supporting document the identifier stands alone (BT-122); a scheme belongs only on the invoiced object reference (BT-18-1).

The warning on its own does not make the document invalid, though other rules still check what is there.

What the rule checks

The rule looks at every cac:AdditionalDocumentReference whose cbc:DocumentTypeCode is not 130, or that has none, and checks whether its cbc:ID carries a schemeID attribute. The invoiced object reference, with code 130, may carry one (BT-18-1).

It runs once against the whole document, so it is reported once however many times the document has the attribute, and the finding points at the document root rather than at the element: look for cac:AdditionalDocumentReference/cbc:ID/@schemeID in the XML.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• Scheme and list attributes (schemeID, listID and the like) are written on every identifier or code by default, including those where EN 16931 does not carry them.
• A general UBL 2.1 library writes every element and attribute it has a value for, whether or not EN 16931 uses it.
• A mapping built for another UBL-based document, such as an order, a despatch advice or a national profile, is reused for Peppol BIS Billing.

How to fix it

1. Stop writing schemeID on the cbc:ID of a document reference whose cbc:DocumentTypeCode is not 130; keep it on the invoiced object reference.
2. On a supporting document the identifier stands alone (BT-122); a scheme belongs only on the invoiced object reference (BT-18-1).
3. Validate again: the warning goes.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the credit note with the warning: the schemeID attribute on the identifier of a document reference other than the invoiced object

<cac:AdditionalDocumentReference>
  <cbc:ID schemeID="ABT">PROJECT-001</cbc:ID>
  <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>

Fragment of the corrected credit note: the same lines without it

<cac:AdditionalDocumentReference>
  <cbc:ID>PROJECT-001</cbc:ID>
  <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>

The credit note with the warning has <cbc:ID schemeID="ABT">PROJECT-001</cbc:ID>, and the corrected credit note is the same document without it. It reports only this warning and is valid on every layer, so it would be accepted as it stands.

Where it applies

• Applies to UBL Invoice and CreditNote alike; the recorded example is a credit note.
• The warning comes from the EN 16931 layer's rules for the UBL syntax. In the recorded example the schema layer passes: the attribute is valid UBL 2.1 and is only outside the EN 16931 model.
• A document reference with a schemeID also fails UBL-SR-43 (fatal) on either document type: that rule allows a scheme only on the invoiced object and, on a credit note, on the project reference (code 50). So this warning shows on its own only there, as in the recorded example, a credit note project reference.

Related rules

• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-29.1: source checked 2026-09-29, explanation last updated 2026-09-29.

The official definition of UBL-CR-665 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.