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:AdditionalItemPropertyand its name. - A numeric attribute such as a weight is written as
cbc:ValueQuantitybecause UBL offers it, and nocbc:Valueis 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
- Use the finding location, for example
cac:InvoiceLine[1]/cac:Item[1]/cac:AdditionalItemProperty[1], to find the property. - If the item has a value for the attribute, write it as text in
cbc:Value, directly aftercbc:Name. For a measurement, put the number and its unit in that text, sincecbc:Valueis the only value element the EN 16931 model uses. - If there is no value, leave the whole
cac:AdditionalItemPropertyout. An emptycbc:Valueonly swaps this finding forPEPPOL-EN16931-R008. - 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
- The failing invoice reports BR-54. 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:InvoiceLine/cac:Itemin a UBLInvoiceandcac:CreditNoteLine/cac:Itemin aCreditNote. When tried, a credit note with the value removed reported the same single finding atcac:CreditNoteLine[1]. - Item attributes are optional. A line with no
cac:AdditionalItemPropertyat 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
- BR-25 requires the item name on the same line item
- BR-64 checks the scheme of the item standard identifier in 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-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.
