# 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.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Lines and prices, Code lists
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-64/
- Explanation last updated: 2026-09-24

## 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.

| Term | Meaning | UBL element |
|---|---|---|
| BT-157 | Item standard identifier | `cac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID (cac:CreditNoteLine/cac:Item/cac:StandardItemIdentification/cbc:ID in a credit note)` |
| BT-157 | Item standard identifier: its scheme identifier attribute | `cac: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.

## 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

```xml
<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

```xml
<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

- The failing invoice reports **BR-64**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-64-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/item-details-valid.xml)

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`.

## Related rules

- [BR-CL-21 checks that the schemeID value is an ISO 6523 ICD code](https://ironfang.uk/docs/finance/rules/BR-CL-21.md)
- [BR-65 is the matching attribute check for the item classification code](https://ironfang.uk/docs/finance/rules/BR-65.md)
- [BR-62 requires a scheme on the seller electronic address in the same way](https://ironfang.uk/docs/finance/rules/BR-62.md)
- [BR-54 checks the item attributes that can accompany the standard identifier on the same item](https://ironfang.uk/docs/finance/rules/BR-54.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-64)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp