Skip to content

BR-54: Give every item attribute both a name and a value

Each cac:AdditionalItemProperty must have a cbc:Name and a cbc:Value. If the item has no value for an attribute, leave the attribute out.

EN 16931Fatal: the document is invalidLines and pricesCore fields

The short answer

BR-54 fails when a cac:AdditionalItemProperty in a line item lacks its cbc:Value or its cbc:Name. In the recorded example the attribute is called Service level and has no value. Add the value from the item data, or remove the whole cac:AdditionalItemProperty if the item has none for that attribute.

A missing name does not reach this rule in practice. cbc:Name is mandatory in this UBL element, so a property without one is refused at the XSD layer before any business rule runs.

What the rule checks

The rule runs on every cac:AdditionalItemProperty in the document and passes when it has both a cbc:Name child and a cbc:Value child. Each property is judged on its own: when tried, an item with two properties lacking values reported the rule twice, once for each.

Only the presence of the two elements is tested. An empty cbc:Value satisfies this rule and is reported by PEPPOL-EN16931-R008 instead; an empty cbc:Name behaved the same way when tried.

Only cbc:Value counts as the value. When tried, a property with cbc:ValueQuantity in its place reported this rule and the warning UBL-CR-611, which flags cbc:ValueQuantity as an element outside the EN 16931 model.

Element order matters to the schema, not to this rule. When tried, a property with cbc:Value written before cbc:Name failed at the XSD layer.

TermMeaningUBL element
BG-32Item attributescac:InvoiceLine/cac:Item/cac:AdditionalItemProperty (cac:CreditNoteLine/cac:Item/cac:AdditionalItemProperty in a credit note)
BT-160Item attribute namecac:InvoiceLine/cac:Item/cac:AdditionalItemProperty/cbc:Name
BT-161Item attribute valuecac:InvoiceLine/cac:Item/cac:AdditionalItemProperty/cbc:Value

How an integration ends up here

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

  • Attributes are generated from a product template with fixed attribute names, and the value is blank for this product.
  • The serialiser drops null values but still writes the enclosing cac:AdditionalItemProperty and its name.
  • A numeric attribute such as a weight is written as cbc:ValueQuantity because UBL offers it, and no cbc:Value is sent.
  • Attribute names and values come from different sources, such as a catalogue and an order, and the join finds no value for this line.

How to fix it

  1. Use the finding location, for example cac:InvoiceLine[1]/cac:Item[1]/cac:AdditionalItemProperty[1], to find the property.
  2. If the item has a value for the attribute, write it as text in cbc:Value, directly after cbc:Name. For a measurement, put the number and its unit in that text, since cbc:Value is the only value element the EN 16931 model uses.
  3. If there is no value, leave the whole cac:AdditionalItemProperty out. An empty cbc:Value only swaps this finding for PEPPOL-EN16931-R008.
  4. Stop the serialiser from writing a property whose value is null, so a name is never sent on its own.

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 item attribute has a name and no value

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <!-- standard identifier, classification and tax category omitted from this fragment -->
  <cac:AdditionalItemProperty>
    <cbc:Name>Service level</cbc:Name>
  </cac:AdditionalItemProperty>
</cac:Item>

Fragment of the corrected invoice: the attribute Service level has the value Standard

<cac:Item>
  <cbc:Name>Example service</cbc:Name>
  <!-- standard identifier, classification and tax category omitted from this fragment -->
  <cac:AdditionalItemProperty>
    <cbc:Name>Service level</cbc:Name>
    <cbc:Value>Standard</cbc:Value>
  </cac:AdditionalItemProperty>
</cac:Item>

Only cbc:Value differs: absent from the item attribute in the failing invoice, Standard in the corrected one. The failing document reports only BR-54. Its Peppol layer passes, because the value element is missing rather than empty, so PEPPOL-EN16931-R008 has no element to report.

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/cac:Item in a UBL Invoice and cac:CreditNoteLine/cac:Item in a CreditNote. When tried, a credit note with the value removed reported the same single finding at cac:CreditNoteLine[1].
  • Item attributes are optional. A line with no cac:AdditionalItemProperty at all passes, which is why removing an attribute you cannot fill is a valid fix.
  • The rule reads the attribute only. The item name, standard identifier and classification on the same item have their own rules.

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