# PEPPOL-EN16931-R080: Send only one project reference on a credit note

A Peppol credit note may carry one `cac:AdditionalDocumentReference` with `cbc:DocumentTypeCode` `50` at most: that is how it holds its project reference.

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

## The short answer

`PEPPOL-EN16931-R080` fails when a `CreditNote` contains more than one `cac:AdditionalDocumentReference` whose `cbc:DocumentTypeCode` is `50`. Keep a single project reference per credit note: the project the credit relates to.

The UBL 2.1 credit note has no `cac:ProjectReference` element, so Peppol carries the project there as an additional document reference with type code `50`. That is why the limit is counted over those references, and why it applies to credit notes only.

## What the rule checks

The rule runs once on the credit note root and counts the additional document references with type code `50`. One is allowed; any number above that fails, and the finding is still reported once: when tried, three such references gave a single finding at the root.

The identifiers are not compared with each other. When tried, two references that both held `PROJECT-001` failed exactly as two different ones did.

References with any other type code, or none, are not counted. When tried, a second reference to `PROJECT-002` without a type code passed every layer, but it is then an ordinary supporting document, not a project reference.

Invoices are outside the rule. When tried, an `Invoice` with two type `50` references did not report it; the EN 16931 layer rejected each reference as `UBL-SR-43`, because an invoice holds its project in `cac:ProjectReference`, and two of those reported `UBL-SR-39`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-11 | Project reference | `cac:AdditionalDocumentReference[cbc:DocumentTypeCode = 50]/cbc:ID (cac:ProjectReference/cbc:ID in an invoice)` |

## How an integration ends up here

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

- A credit note built from an invoice that referenced several projects turns every one of them into a type `50` reference.
- The credit covers work on more than one project, and the export lists them all.
- Other references, such as a work order or a contract, are written with type code `50` because the mapping uses one code for every additional reference.
- The same project is written twice, once from the header and once from a cost allocation.

## How to fix it

1. Decide which single project the credit note belongs to, normally the project of the invoice it corrects.
2. Keep one `cac:AdditionalDocumentReference` with that project in `cbc:ID` and `cbc:DocumentTypeCode` `50`, and remove the others.
3. If the credit genuinely spans several projects, issue one credit note per project.
4. Send references that are not projects in their own elements: a contract goes in `cac:ContractDocumentReference`, and a supporting document is an additional document reference with no type code.

## Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing credit note: two additional document references of type 50

```xml
<cac:BillingReference>
  <!-- invoice reference omitted from this fragment -->
</cac:BillingReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>PROJECT-001</cbc:ID>
  <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>PROJECT-002</cbc:ID>
  <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>
<cac:AccountingSupplierParty>
  <!-- seller omitted from this fragment -->
</cac:AccountingSupplierParty>
```

Fragment of the corrected credit note: one project reference, PROJECT-001

```xml
<cac:BillingReference>
  <!-- invoice reference omitted from this fragment -->
</cac:BillingReference>
<cac:AdditionalDocumentReference>
  <cbc:ID>PROJECT-001</cbc:ID>
  <cbc:DocumentTypeCode>50</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>
<cac:AccountingSupplierParty>
  <!-- seller omitted from this fragment -->
</cac:AccountingSupplierParty>
```

The failing credit note has a second `cac:AdditionalDocumentReference` for `PROJECT-002` with type code `50`; the corrected one keeps only `PROJECT-001`, and nothing else differs. `PEPPOL-EN16931-R080` is the only finding, at the `CreditNote` root. The EN 16931 layer passes, because its own limit on project references counts `cac:ProjectReference`, which a credit note does not have.

### What the validator reported

- The failing credit note reports **PEPPOL-EN16931-R080**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/PEPPOL-EN16931-R080-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/core-credit-note-project-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

- A `CreditNote` rule only. An `Invoice` puts its single project reference in `cac:ProjectReference`, and the EN 16931 layer enforces the limit there as `UBL-SR-39`.
- A Peppol BIS rule, reported in the Peppol layer alone.
- The reference is still an additional document reference, so the rules for those apply to it too: when tried, an empty `cbc:ID` on the type `50` reference reported `BR-52` and `PEPPOL-EN16931-R008`.
- Moving the project to `cac:ProjectReference` is not an option in a credit note. When tried, that element failed the XSD layer, since the UBL 2.1 credit note schema does not define it.

## Related rules

- [PEPPOL-EN16931-R100 sets the matching limit of one invoiced object per line](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R100.md)
- [BR-52 requires an identifier in every additional document reference, the project reference included](https://ironfang.com/docs/finance/rules/BR-52.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-R080](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R080/) 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-R080)
- [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