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

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.

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.

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 credit note: two additional document references of type 50

<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

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

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
• BR-52 requires an identifier in every additional document reference, the project reference included
• 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-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.