# BR-CL-16: Use a UNTDID 4461 payment means code

`cbc:PaymentMeansCode` must be a UNTDID 4461 code, such as `30` for credit transfer or `49` for direct debit, not a bank scheme or product name.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Code lists
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-16/
- Explanation last updated: 2026-09-24

## The short answer

`BR-CL-16` fails when `cac:PaymentMeans/cbc:PaymentMeansCode` holds something that is not a UNTDID 4461 code. Replace it with the code for how the buyer will pay: `30` for a credit transfer into the seller's account, `58` for a SEPA credit transfer, `49` for a direct debit, `48` for a bank card, and so on.

A scheme or product name such as `BACS` is not a code. If you want the name on the invoice, put it in the `name` attribute of the same element, which carries the payment means text.

## What the rule checks

The value is trimmed of leading and trailing spaces and must then match a single code exactly. The pinned list holds the numbers 1 to 70, 74 to 78 and 91 to 98, plus `ZZZ` for a mutually defined method.

Form and case matter. When tried, `zzz`, `030`, `71`, `99`, the words `Credit transfer` and the pair `30 58` were all rejected, while `30` with spaces around it passed.

The `name` attribute is not checked by this rule. A code of `30` with `name="BACS"` passed every layer when tried.

An empty `cbc:PaymentMeansCode` fails this rule and `PEPPOL-EN16931-R008`. Leaving the element out altogether fails the XSD layer instead, because UBL requires it in every payment means.

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BT-82 | Payment means text | `cac:PaymentMeans/cbc:PaymentMeansCode/@name` |

## How an integration ends up here

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

- An internal payment method name or code, such as `BACS`, `BANK` or `CARD`, is written straight into the element with no translation table.
- The code is stored as a number and formatted with a leading zero or padding.
- The code was taken from another list, for example a bank's own transaction type codes.
- The descriptive text and the code were swapped, putting the text in the element and the code in the `name` attribute.

## How to fix it

1. List the payment methods your system offers and map each to a UNTDID 4461 code in an explicit table. A payment the buyer sends to the seller's bank account through Bacs or Faster Payments is a credit transfer, `30`; a collection under a Bacs Direct Debit instruction is a direct debit, `49`.
2. Write the code as plain text with no padding. Put any human-readable label in the `name` attribute.
3. Check what the new code brings with it. `30` and `58` need a payee account identifier (`BR-61`), and `49` and `59` need a mandate reference (`PEPPOL-EN16931-R061`).

## Before and after

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

Fragment of the failing invoice: the payment means code is the name of a UK clearing scheme

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>BACS</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
```

Fragment of the corrected invoice: code 30, credit transfer

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
```

Only `cbc:PaymentMeansCode` differs: `BACS` in the failing invoice, `30` in the corrected one. The failing document reports only `BR-CL-16`. The payee account and its identifier are present in both documents, so once the code is `30` the credit transfer rules find nothing missing.

### What the validator reported

- The failing invoice reports **BR-CL-16**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-CL-16-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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 `BACS` reported the same rule when tried.
- The rule is checked for every `cbc:PaymentMeansCode` in the document, one finding per unlisted code.
- A code outside the list hides the checks that depend on the code. `BR-61` and `PEPPOL-EN16931-R061` look for specific codes, so a payment means coded `BACS` with no account at all reported only this rule when tried.
- Some Peppol national rules narrow the list for domestic invoices, such as `NL-R-008` between Dutch parties and `DK-R-005` between Danish ones. Those are separate findings on top of this one.

## Related rules

- [BR-61 requires a payee account once the code is 30 or 58](https://ironfang.uk/docs/finance/rules/BR-61.md)
- [PEPPOL-EN16931-R061 requires a mandate reference once the code is 49 or 59](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R061.md)
- [BR-CL-01 is the same kind of code list check for the document type code](https://ironfang.uk/docs/finance/rules/BR-CL-01.md)
- [BR-51 warns when a card payment, coded 48, 54 or 55, carries the full card number](https://ironfang.uk/docs/finance/rules/BR-51.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 BR-CL-16](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-CL-16/) 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/BR-CL-16)
- [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