Skip to content

Ironfang Finance - Rule reference

UBL-CR-372: Remove PlotIdentification from the deliver-to address

Warning: EN 16931 has no place for cbc:PlotIdentification in the deliver-to address. The document stays valid; remove it.

EN 16931Warning: the document stays validParties and addresses

On this page

The short answer

UBL-CR-372 is a warning raised when cbc:PlotIdentification appears in the deliver-to address (cac:Delivery/cac:DeliveryLocation/cac:Address). EN 16931 has no business term for it, so remove the element. Write details such as the building, floor or department into the address lines: cbc:StreetName, cbc:AdditionalStreetName and one cac:AddressLine/cbc:Line (BT-75, BT-76, BT-165; an address has one such line, UBL-SR-51).

The warning on its own does not make the document invalid, though other rules still check what is there. Removing the element keeps the XML inside the EN 16931 model, which is what a receiver maps the invoice from.

What the rule checks

The rule checks one thing: whether cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PlotIdentification exists. Its value is not read.

It runs once against the whole document, so it is reported once however many times the document has the element, and the finding points at the document root rather than at the element: look for cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PlotIdentification in the XML.

TermMeaningUBL element
-PlotIdentification (UBL only, no business term)cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PlotIdentification
BG-15Deliver-to addresscac:Delivery/cac:DeliveryLocation/cac:Address

How an integration ends up here

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

  • The source system holds the value, and the mapping writes it because UBL 2.1 has a place for it.
  • A general UBL 2.1 library writes every element and attribute it has a value for, whether or not EN 16931 uses it.
  • A mapping built for another UBL-based document, such as an order, a despatch advice or a national profile, is reused for Peppol BIS Billing.

How to fix it

  1. Stop writing cac:Delivery/cac:DeliveryLocation/cac:Address/cbc:PlotIdentification.
  2. Write details such as the building, floor or department into the address lines: cbc:StreetName, cbc:AdditionalStreetName and one cac:AddressLine/cbc:Line (BT-75, BT-76, BT-165; an address has one such line, UBL-SR-51).
  3. Validate again: the warning goes. If the element was the only thing in its parent, remove the parent too: Peppol refuses empty elements (PEPPOL-EN16931-R008).

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 invoice with the warning: PlotIdentification in the deliver-to address

<cac:Address>
  <cbc:StreetName>3 Delivery Street</cbc:StreetName>
  <cbc:PlotIdentification>Example</cbc:PlotIdentification>
  <cac:Country>
    <cbc:IdentificationCode>GB</cbc:IdentificationCode>
  </cac:Country>
</cac:Address>

Fragment of the corrected invoice: the same lines without it

<cac:Address>
  <cbc:StreetName>3 Delivery Street</cbc:StreetName>
  <cac:Country>
    <cbc:IdentificationCode>GB</cbc:IdentificationCode>
  </cac:Country>
</cac:Address>

The invoice with the warning has <cbc:PlotIdentification>Example</cbc:PlotIdentification> in the deliver-to address, and the corrected invoice is the same document without it. It reports only this warning and is valid on every layer, so it would be accepted as it stands.

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 UBL Invoice and CreditNote alike; the recorded example is an invoice.
  • The warning comes from the EN 16931 layer's rules for the UBL syntax. In the recorded example the schema layer passes: the element is valid UBL 2.1 and is only outside the EN 16931 model.

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-29.1: source checked 2026-09-29, explanation last updated 2026-09-29.

The official definition of UBL-CR-372 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.