# PEPPOL-EN16931-R061: Add the mandate reference to a direct debit

Payment means `49` or `59` is a direct debit and needs `cac:PaymentMandate/cbc:ID`, the reference of the mandate the buyer signed.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R061/
- Explanation last updated: 2026-09-24

## The short answer

`PEPPOL-EN16931-R061` fails when a `cac:PaymentMeans` with code `49` (direct debit) or `59` (SEPA direct debit) has no `cac:PaymentMandate/cbc:ID`. Add the reference of the direct debit mandate the buyer gave the seller as `cbc:ID`, the first child of `cac:PaymentMandate`.

The debited account alone is not enough. The recorded failing invoice names the buyer's account in `cac:PayerFinancialAccount` and still fails, because the mandate reference is what identifies the authority to collect.

## What the rule checks

The rule selects payment means whose code, once surrounding spaces are trimmed, is `49` or `59`, and asks only whether a `cbc:ID` element exists directly inside `cac:PaymentMandate`. Other codes are not examined; code `31` (debit transfer) passed without a mandate when tried.

It is a presence test. An empty or blank mandate `cbc:ID` satisfied this rule when tried and was reported by `PEPPOL-EN16931-R008` instead, so a placeholder element gains nothing.

The debited account is not required by this rule: a mandate with a `cbc:ID` and no `cac:PayerFinancialAccount` passed every layer when tried.

A payment means with no `cac:PaymentMandate` at all and one whose mandate lacks `cbc:ID` produce the same single finding, located at the payment means.

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BT-89 | Mandate reference identifier | `cac:PaymentMeans/cac:PaymentMandate/cbc:ID` |
| BT-91 | Debited account identifier | `cac:PaymentMeans/cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID` |

## How an integration ends up here

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

- The mandate reference is held on the customer record or by the collection provider and is not joined into the invoice export.
- The mandate block is built from the buyer's bank details only, so `cac:PayerFinancialAccount` is written and the reference is not.
- Direct debit is the default payment means for a customer group that includes customers who never signed a mandate.
- The mandate reference was put in `cbc:PaymentID`, which carries the remittance reference for the payment, not the mandate.

## How to fix it

1. Look up the mandate this buyer signed, in the direct debit records the seller or its collection provider keeps, and take its reference.
2. Write it as `cbc:ID` inside `cac:PaymentMandate`, before `cac:PayerFinancialAccount`.
3. If the buyer has no mandate, the invoice cannot be collected by direct debit. Change `cbc:PaymentMeansCode` to the method the buyer will actually use, and meet that method's own requirements, such as a payee account for `30`.
4. Keep the payment reference in `cbc:PaymentID` separate from the mandate reference; they identify different things.

## Before and after

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

Fragment of the failing invoice: a direct debit mandate that names the debited account but has no reference

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>49</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cac:PayerFinancialAccount>
      <cbc:ID>GB00EXAMPLE00000000001</cbc:ID>
    </cac:PayerFinancialAccount>
  </cac:PaymentMandate>
</cac:PaymentMeans>
```

Fragment of the corrected invoice: the mandate reference comes first in the mandate

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>49</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-001</cbc:ID>
    <cac:PayerFinancialAccount>
      <cbc:ID>GB00EXAMPLE00000000001</cbc:ID>
    </cac:PayerFinancialAccount>
  </cac:PaymentMandate>
</cac:PaymentMeans>
```

The corrected invoice has `<cbc:ID>MANDATE-001</cbc:ID>` as the first child of `cac:PaymentMandate`; the failing one goes straight to the debited account. The failing document reports only `PEPPOL-EN16931-R061`, and its EN 16931 layer passes, because the core standard leaves the mandate reference optional even for a direct debit. `MANDATE-001` stands in for a real mandate reference.

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R061**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R061-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/direct-debit-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 UBL `Invoice` and `CreditNote` alike; a credit note with code `49` and no mandate reported this rule when tried.
- This is a Peppol rule. A document checked against EN 16931 alone would not report it.
- A direct debit needs no payee account, since the seller collects. Coding a direct debit as `30` instead brings `BR-61`, which the mandate does not satisfy; that was reported when tried.

## Related rules

- [BR-CL-16 checks the payment means code that puts a payment in scope of this rule](https://ironfang.uk/docs/finance/rules/BR-CL-16.md)
- [BR-61 is the credit transfer counterpart, requiring a payee account for codes 30 and 58](https://ironfang.uk/docs/finance/rules/BR-61.md)
- [PEPPOL-EN16931-R008 is what an empty mandate reference element reports](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.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-24.

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