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

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

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

| Term | Meaning | UBL element |
|---|---|---|
| BG-32 | Item attributes | `cac:InvoiceLine/cac:Item/cac:AdditionalItemProperty (cac:CreditNoteLine/cac:Item/cac:AdditionalItemProperty in a credit note)` |
| BT-160 | Item attribute name | `cac:InvoiceLine/cac:Item/cac:AdditionalItemProperty/cbc:Name` |
| BT-161 | Item attribute value | `cac: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.

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

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

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

- The failing invoice reports **BR-54**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-54-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/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.

## Related rules

- [PEPPOL-EN16931-R008 reports an attribute name or value that is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [BR-25 requires the item name on the same line item](https://ironfang.uk/docs/finance/rules/BR-25.md)
- [BR-64 checks the scheme of the item standard identifier in the same item](https://ironfang.uk/docs/finance/rules/BR-64.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-54](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-54)
- [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