Skip to content

BR-64: Add the schemeID attribute to the item standard identifier

An item standard identifier in cac:StandardItemIdentification/cbc:ID must say which scheme it belongs to, in schemeID: 0160 for a GTIN.

EN 16931Fatal: the document is invalidLines and pricesCode lists

The short answer

BR-64 fails when cac:Item/cac:StandardItemIdentification/cbc:ID on a line has no schemeID attribute. Add schemeID with the ISO 6523 ICD code of the numbering system the identifier belongs to. For a GS1 GTIN, as in the recorded example, that is 0160.

If the number is your own article number and not from a registered scheme, it belongs in cac:SellersItemIdentification/cbc:ID, which takes no scheme. When tried, the same number moved there with no attribute passed every layer.

What the rule checks

The rule runs on each cbc:ID inside cac:StandardItemIdentification on an invoice or credit note line and tests one thing: whether a schemeID attribute is there.

The value of the attribute is left to BR-CL-21. When tried, schemeID="" passed this rule and was reported by that one.

The identifier is not tested against its scheme. With schemeID="0160", both a 13-digit number with a wrong GS1 check digit and the text ABC passed every layer when tried, so a correct GTIN is your responsibility.

Other attributes do not stand in for schemeID. When the code was written to schemeAgencyID instead, this rule was reported together with the warning UBL-DT-27.

An empty cbc:ID that does carry schemeID passes this rule; when tried it was reported by PEPPOL-EN16931-R008 alone.

TermMeaningUBL element
BT-157Item standard identifiercac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID (cac:CreditNoteLine/cac:Item/cac:StandardItemIdentification/cbc:ID in a credit note)
BT-157Item standard identifier: its scheme identifier attributecac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID/@schemeID

How an integration ends up here

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

  • The product master stores the barcode number without recording which scheme it belongs to, and the mapping writes the number alone.
  • The seller article number is mapped to cac:StandardItemIdentification instead of cac:SellersItemIdentification, so there is no scheme to give.
  • The serialiser drops attributes whose source column is null, and the scheme column is empty for some products.
  • The scheme is written to schemeAgencyID instead of schemeID.

How to fix it

  1. Establish what the number in cbc:ID is. A GTIN, which includes EAN-13 and UPC barcode numbers, takes 0160. An identifier from another registered item numbering scheme takes that scheme code from the ICD list.
  2. Write the code to the schemeID attribute of cac:StandardItemIdentification/cbc:ID, spelt exactly that way, as the four-digit code and not the scheme name.
  3. If the identifier is internal to the seller or the buyer, move it to cac:SellersItemIdentification or cac:BuyersItemIdentification and drop cac:StandardItemIdentification for that line. Send those identifiers without a scheme: when tried, a schemeID on the seller item identifier drew the warning UBL-CR-668.
  4. Hold the scheme next to the identifier in the product data, so every standard identifier is exported with one.

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 failing invoice: the GTIN has no scheme attribute

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <cac:StandardItemIdentification>
    <cbc:ID>5012345678900</cbc:ID>
  </cac:StandardItemIdentification>
  <!-- classification, tax category and item attribute omitted from this fragment -->
</cac:Item>

Fragment of the corrected invoice: schemeID 0160 marks the identifier as a GTIN

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID="0160">5012345678900</cbc:ID>
  </cac:StandardItemIdentification>
  <!-- classification, tax category and item attribute omitted from this fragment -->
</cac:Item>

The only difference is schemeID="0160" on the item standard identifier, missing in the failing invoice. The failing document reports only BR-64. BR-CL-21 is not reported with it, because that rule checks the value of the attribute and there is no attribute to check.

What the validator reported

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

Where it applies

  • Applies to cac:InvoiceLine in an Invoice and cac:CreditNoteLine in a CreditNote, where the item structure is identical. When tried, a credit note with the attribute removed from its GTIN reported this rule alone.
  • The standard identifier is optional. A line without cac:StandardItemIdentification passes, so there is no reason to add one without a real identifier.
  • Seller and buyer item identifiers are outside this rule, and so are identifiers on parties, which have their own scheme rules such as BR-62.

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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of BR-64 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.