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

An invoice or credit note line may hold one `cac:DocumentReference` at most, the invoiced object identifier. Split a line that covers several objects.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Process and references, Lines and prices
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R100/
- Explanation last updated: 2026-09-28

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-128 | Invoice line object identifier | `cac:InvoiceLine/cac:DocumentReference/cbc:ID (cac:CreditNoteLine/cac:DocumentReference/cbc:ID in a credit note)` |

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

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

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

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

### What the validator reported

- The failing invoice reports `UBL-SR-52` and **PEPPOL-EN16931-R100**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/PEPPOL-EN16931-R100-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/core-line-object-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 `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](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R101.md)
- [BR-CL-07 checks the scheme of an invoiced object identifier against UNTDID 1153](https://ironfang.com/docs/finance/rules/BR-CL-07.md)
- [PEPPOL-EN16931-R080 is the one-only limit for project references on a credit note](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R080.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-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

[The official definition of PEPPOL-EN16931-R100](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.

## Links

- [This rule as a web page](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R100)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp