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:StandardItemIdentificationinstead ofcac: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
schemeAgencyIDinstead ofschemeID.
How to fix it
- Establish what the number in
cbc:IDis. A GTIN, which includes EAN-13 and UPC barcode numbers, takes0160. An identifier from another registered item numbering scheme takes that scheme code from the ICD list. - Write the code to the
schemeIDattribute ofcac:StandardItemIdentification/cbc:ID, spelt exactly that way, as the four-digit code and not the scheme name. - If the identifier is internal to the seller or the buyer, move it to
cac:SellersItemIdentificationorcac:BuyersItemIdentificationand dropcac:StandardItemIdentificationfor that line. Send those identifiers without a scheme: when tried, aschemeIDon the seller item identifier drew the warningUBL-CR-668. - 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
- The failing invoice reports BR-64. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected 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:InvoiceLinein anInvoiceandcac:CreditNoteLinein aCreditNote, 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:StandardItemIdentificationpasses, 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
- BR-65 is the matching attribute check for the item classification code
- BR-62 requires a scheme on the seller electronic address in the same way
- BR-54 checks the item attributes that can accompany the standard identifier on the same item
- 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-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.
