# PEPPOL-EN16931-R003: Add a buyer reference or a purchase order reference

The document has neither cbc:BuyerReference nor cac:OrderReference/cbc:ID. Peppol needs at least one so the buyer can route the invoice.

- 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-R003/
- Explanation last updated: 2026-09-20

## The short answer

`PEPPOL-EN16931-R003` fails when the document carries neither a buyer reference nor a purchase order reference. Add `cbc:BuyerReference`, or `cac:OrderReference` with a `cbc:ID`, using whichever reference the buyer actually gave you. Either one satisfies the rule; both may be sent.

The value has to come from the buyer. It is what their system uses to route the document to the right person or match it to an order, so a made-up placeholder passes validation and then stalls on their side.

## What the rule checks

The rule looks at the document root for two things: a `cbc:BuyerReference` element, and a `cbc:ID` inside `cac:OrderReference`. It passes when at least one exists. An invoice with only a purchase order reference passes, and so does one with only a buyer reference.

Only document-level references count. An order line reference on an invoice line (`cac:OrderLineReference`) does not satisfy the rule.

The check is on presence, not content. An empty `cbc:BuyerReference` does not report this rule, but it reports `PEPPOL-EN16931-R008` for the empty element, so it is no way round the requirement.

| Term | Meaning | UBL element |
|---|---|---|
| BT-10 | Buyer reference | `cbc:BuyerReference` |
| BT-13 | Purchase order reference | `cac:OrderReference/cbc:ID` |

## How an integration ends up here

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

- The buyer reference is an optional field on the customer or order record and was left blank for this customer.
- The source invoice has a purchase order number, but it is mapped to a note or a line-level field and not to `cac:OrderReference/cbc:ID`.
- The serialiser drops elements whose source value is null, so a missing reference disappears silently and nothing upstream blocks the invoice.
- A sales order number is available but no purchase order number, and `cac:OrderReference` was left out because its `cbc:ID` could not be filled.

## How to fix it

1. Find out which reference the buyer expects: a routing reference they issue to suppliers, or the number of the purchase order being invoiced.
2. If it is a buyer reference, write it to `cbc:BuyerReference`. In the UBL sequence it follows `cbc:DocumentCurrencyCode` and `cbc:AccountingCost`, and comes before `cac:OrderReference`.
3. If it is a purchase order number, write it to `cac:OrderReference/cbc:ID`. The UBL schema requires `cbc:ID` whenever `cac:OrderReference` is present, so a `cac:OrderReference` holding only `cbc:SalesOrderID` fails at the XSD layer before this rule runs.
4. Make the reference mandatory at order entry or invoice approval for customers invoiced over Peppol, so the gap is caught before the XML is built.

## Before and after

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

Fragment of the failing invoice: no buyer reference, and the document has no order reference either

```xml
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cac:AccountingSupplierParty>
  <!-- seller party omitted from this fragment -->
</cac:AccountingSupplierParty>
```

Fragment of the corrected invoice: the buyer reference is present

```xml
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:AccountingSupplierParty>
  <!-- seller party omitted from this fragment -->
</cac:AccountingSupplierParty>
```

The only difference is the `cbc:BuyerReference` line. The failing document reports only `PEPPOL-EN16931-R003`; the EN 16931 layer passes because the core standard treats both references as optional.

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R003**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R003-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-minimal.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 UBL `Invoice` and `CreditNote` alike. A credit note with neither reference reports the same rule, and a credit note with only `cac:OrderReference/cbc:ID` passes.
- This is a Peppol requirement on top of EN 16931, so it appears only in the Peppol layer.
- The rule does not check that the reference is one the buyer recognises. That can only be settled with the buyer.

## Related rules

- [PEPPOL-EN16931-R008 is what an empty buyer reference element reports](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [PEPPOL-EN16931-R001 is another Peppol-only header requirement: the business process identifier](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R001.md)
- [PEPPOL-EN16931-R010 requires the buyer electronic address, the other piece of buyer routing data](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R010.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-24.1: source checked 2026-09-24, explanation last updated 2026-09-20.

[The official definition of PEPPOL-EN16931-R003](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R003/) 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.uk/docs/finance/rules/PEPPOL-EN16931-R003)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp