PEPPOL-EN16931-R100: Reference only one invoiced object on each line

The short answer

PEPPOL-EN16931-R100 fails when a cac:InvoiceLine or cac:CreditNoteLine contains more than one cac:DocumentReference. A line can name one invoiced object, such as a meter, a vehicle or a subscription, so give each object a line of its own.

The same line is reported as UBL-SR-52 on the EN 16931 layer too, which makes the identical count. Both clear once the line has a single reference.

What the rule checks

The rule counts the cac:DocumentReference children of each line and fails from the second one on. It does not look inside them: when tried, a second reference with type code 50 instead of 130 reported the same two rules as the recorded example.

That variant did not bring PEPPOL-EN16931-R101, the rule that restricts a line reference to type 130, because it is satisfied as soon as one reference on the line carries 130. With a single reference and no type code, PEPPOL-EN16931-R101 was reported on its own.

The limit applies per line, so different lines may each name a different object.

The invoiced object identifier for the whole document is a different element with its own limit. When tried, two root-level cac:AdditionalDocumentReference elements of type 130 reported UBL-SR-04, not this rule.

How an integration ends up here

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

• A line bills several meters, devices or contracts together, and the export writes one reference per object.
• The mapping uses the line document reference for other documents as well, such as a delivery note or a timesheet, next to the object identifier.
• A repeated source record, such as the same meter read twice, produces a duplicate reference.

How to fix it

1. Find the line from the finding, for example cac:InvoiceLine[1], and list the references it carries.
2. Keep the one that identifies the invoiced object, with cbc:DocumentTypeCode 130.
3. If the line covers several objects, split it into one line per object, each with its own quantity, net amount and cac:DocumentReference, and recalculate the totals from the new lines.
4. Move references that are not invoiced objects off the line: a supporting document belongs in a cac:AdditionalDocumentReference at document level.
5. Remove plain duplicates.

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: line 1 names two meters

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cac:DocumentReference>
    <cbc:ID>METER-001</cbc:ID>
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>
  </cac:DocumentReference>
  <cac:DocumentReference>
    <cbc:ID>METER-002</cbc:ID>
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>
  </cac:DocumentReference>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Fragment of the corrected invoice: line 1 names one meter, METER-001

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cac:DocumentReference>
    <cbc:ID>METER-001</cbc:ID>
    <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode>
  </cac:DocumentReference>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

The failing invoice lists two meters, METER-001 and METER-002, as document references on line 1; the corrected invoice keeps METER-001 alone and is otherwise identical. Two findings sit on that line: PEPPOL-EN16931-R100 in the Peppol layer and UBL-SR-52 in the EN 16931 layer, which counts the references the same way. Removing the second reference clears both; had both meters really been billed, each would need a line of its own.

Where it applies

• Applies to Invoice and CreditNote. When tried, a cac:CreditNoteLine with two references reported PEPPOL-EN16931-R100 and UBL-SR-52 at that line.
• A Peppol BIS rule, reported in the Peppol layer. Its EN 16931 twin, UBL-SR-52, has no page of its own in this reference.
• The contents of the one reference are checked elsewhere: PEPPOL-EN16931-R101 requires type code 130, and BR-CL-07 checks a scheme on the identifier against UNTDID 1153.

Related rules

• PEPPOL-EN16931-R101 requires the one line reference to be an invoiced object, type 130
• BR-CL-07 checks the scheme of an invoiced object identifier against UNTDID 1153
• PEPPOL-EN16931-R080 is the one-only limit for project references on a credit note
• Browse every rule in the reference
• Background: How Peppol invoice validation actually works

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

The official definition of PEPPOL-EN16931-R100 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.