# UBL-SR-47: Use the same payment means code in every PaymentMeans

The `cac:PaymentMeans` elements carry more than one distinct `cbc:PaymentMeansCode`. An invoice has one payment means type: use the same code in each.

- Layer: EN 16931
- Severity: fatal (the document is invalid)
- Topics: Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-SR-47/
- Explanation last updated: 2026-09-28

## The short answer

`UBL-SR-47` fails when the `cbc:PaymentMeansCode` values in a document are not all the same. The recorded example offers one account under `30`, credit transfer, and a second under `58`, SEPA credit transfer. Choose the one code that describes how the invoice is to be paid and use it in every `cac:PaymentMeans`.

Repeating `cac:PaymentMeans` is how UBL lists several accounts for the same kind of payment. It is not a way to offer different kinds of payment, because the model has one payment means type code per invoice.

## What the rule checks

The rule runs once on the document root, gathers every `cbc:PaymentMeansCode`, and fails when more than one distinct value is found. Any number of payment means sharing one code pass, as the corrected invoice shows with two under `30`.

Codes are compared as written, with no trimming. When tried, ` 30` with a leading space beside `30` failed this rule, although `BR-CL-16` accepted both as the code 30.

Any mix of methods fails the same way. When tried, a card payment under `48`, giving the last four digits of the card, next to a credit transfer under `30` reported this rule and nothing else.

The optional `name` attribute on the code is not compared. When tried, giving the first code `name="Credit transfer"` and the second none passed every layer.

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BG-16 | Payment instructions | `cac:PaymentMeans` |

## How an integration ends up here

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

- The invoice lists every way the supplier accepts payment, such as a bank transfer and a card, as separate payment means.
- Domestic and euro accounts are exported with the code of their own scheme, `30` for one and `58` for the SEPA account.
- Payment means are copied from a supplier profile in which each account has its own code, and every account goes into every invoice.
- A code is padded, or read from a fixed-width field, in one place only, so one copy carries a space.

## How to fix it

1. Decide on the one payment means type for this invoice. If the buyer may use either of two accounts for a bank transfer, one credit transfer code covers both; `30` is the general credit transfer code.
2. Write that code in every `cac:PaymentMeans`, trimmed and identical.
3. Leave payment means for other methods, such as a card, out of the invoice. If the buyer needs to know about them, describe them in the payment terms note.
4. Keep one `cac:PayeeFinancialAccount` in each payment means, with its identifier, as `BR-61` requires for credit transfers.

## 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 second account is offered as a SEPA credit transfer, code 58

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
```

Fragment of the corrected invoice: both accounts are offered under code 30

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
```

In the failing invoice the second `cac:PaymentMeans` uses code `58`; in the corrected one it uses `30`, like the first. Account and payment reference are the same in both. Only `UBL-SR-47` is reported, at the document root: `58` is a permitted code, and each payment means meets the credit transfer requirements on its own.

### What the validator reported

- The failing invoice reports **UBL-SR-47**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/UBL-SR-47-invalid.xml)
  - [Download the corrected XML](https://ironfang.com/finance/rule-examples/two-payment-accounts-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 `Invoice` and `CreditNote`. When tried, a credit note with payment means under `30` and `58` reported this rule too.
- Reported by the EN 16931 layer as part of the UBL syntax binding.
- A single payment means under `58` is fine. When tried, the one-account example invoice with its code changed from `30` to `58` passed every layer.
- The payment reference is held to one value in the same way, by `UBL-SR-44`.

## Related rules

- [UBL-SR-44 allows only one distinct payment reference across the payment means](https://ironfang.com/docs/finance/rules/UBL-SR-44.md)
- [BR-CL-16 checks that each payment means code is in the permitted list](https://ironfang.com/docs/finance/rules/BR-CL-16.md)
- [BR-61 requires the payee account on each payment means coded as a credit transfer](https://ironfang.com/docs/finance/rules/BR-61.md)
- [UBL-SR-48 is another UBL syntax rule that narrows a repeatable element to what the model allows: one tax category per line](https://ironfang.com/docs/finance/rules/UBL-SR-48.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 UBL-SR-47](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-SR-47/) 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/UBL-SR-47)
- [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