# BR-61: Add the payee account to a credit transfer

Payment means code `30` or `58` announces a credit transfer, so the invoice must say which account to pay: `cac:PayeeFinancialAccount/cbc:ID`.

- 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/BR-61/
- Explanation last updated: 2026-09-24

## The short answer

`BR-61` fails when a `cac:PaymentMeans` has code `30` (credit transfer) or `58` (SEPA credit transfer) and no `cac:PayeeFinancialAccount/cbc:ID` inside it. Add a `cac:PayeeFinancialAccount` to that payment means with the seller's account number, such as an IBAN, in `cbc:ID`.

If the account element is already there and only its `cbc:ID` is missing, `BR-50` is reported as well. If the code itself is wrong and the buyer will not pay by transfer, change the code instead of adding an account.

## What the rule checks

The rule runs on every `cac:PaymentMeans`. Once spaces around `cbc:PaymentMeansCode` are trimmed, a code of `30` or `58` requires the path `cac:PayeeFinancialAccount/cbc:ID` to exist; every other code passes.

Only existence is tested. An account `cbc:ID` that is empty or holds only spaces satisfied this rule when tried, and was then reported by `BR-50` and `PEPPOL-EN16931-R008`.

An account number placed anywhere else does not count. With the account removed and an IBAN-shaped value in `cbc:PaymentID`, the rule still failed when tried.

The codes in scope are exactly `30` and `58`. Code `42` (payment to bank account) and code `31` (debit transfer) both passed without any account when tried.

The two rules divide the cases like this: no account element gives `BR-61` alone, as in the recorded example; an account element without `cbc:ID` gives `BR-61` and `BR-50`; an empty `cbc:ID` gives `BR-50` and `PEPPOL-EN16931-R008`.

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BT-84 | Payment account identifier | `cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID` |

## How an integration ends up here

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

- Credit transfer is set as the payment means for every invoice, but bank details are only written when a setting is switched on for the seller entity.
- The seller holds accounts per currency and none is configured for the invoice currency, so the account block is left out.
- The account number is written only into the payment reference `cbc:PaymentID` or a free-text note.
- The invoice will be paid by card or direct debit, but the payment means code is hard-coded to `30`.

## How to fix it

1. Decide how the buyer will pay. For a transfer into the seller's account keep `30`, or `58` for a SEPA transfer; for any other method use that method's code and stop here.
2. Take the account number from the seller's bank details for this entity and currency, never from the buyer's data.
3. Add `cac:PayeeFinancialAccount` inside the `cac:PaymentMeans`, after `cbc:PaymentID` as in the corrected invoice, with the account number as its first child `cbc:ID`.
4. Add the account name in `cbc:Name` and the bank identifier, such as a BIC, in `cac:FinancialInstitutionBranch/cbc:ID` if you have them. When tried, an account holding only its `cbc:ID` passed every layer.

## 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 credit transfer with a payment reference and no payee account

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
</cac:PaymentMeans>
<cac:PaymentTerms>
  <cbc:Note>Payment within 30 days</cbc:Note>
</cac:PaymentTerms>
```

Fragment of the corrected invoice: the payee account follows the payment reference

```xml
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
    <cac:FinancialInstitutionBranch>
      <cbc:ID>EXAMPLE-BRANCH</cbc:ID>
    </cac:FinancialInstitutionBranch>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentTerms>
  <cbc:Note>Payment within 30 days</cbc:Note>
</cac:PaymentTerms>
```

The failing invoice has a code `30` payment means with a payment reference and nothing else; the corrected one adds the whole `cac:PayeeFinancialAccount` with identifier, name and branch. The failing document reports only `BR-61`. `BR-50` stays silent because there is no account element for it to inspect.

### What the validator reported

- The failing invoice reports **BR-61**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-61-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 code `30` and no account reported this rule when tried.
- This is an EN 16931 rule, and the Peppol layer passes in the recorded example.
- Each payment means is checked separately. A second `cac:PaymentMeans` with code `30` and no account was reported at `cac:PaymentMeans[2]` when tried. Had the second one used a different code, `UBL-SR-47` would also appear, because all payment means codes in a document must be equal.
- A payment means code outside the list, such as `BACS`, is reported by `BR-CL-16` and escapes this rule even with no account, so correcting that code to `30` can reveal this finding.

## Related rules

- [BR-50 checks the identifier inside an account element that is already present, and fires with this rule when it is missing](https://ironfang.uk/docs/finance/rules/BR-50.md)
- [BR-CL-16 checks that the payment means code comes from UNTDID 4461](https://ironfang.uk/docs/finance/rules/BR-CL-16.md)
- [PEPPOL-EN16931-R061 is the direct debit equivalent, requiring a mandate reference for codes 49 and 59](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R061.md)
- [NL-R-007 requires Dutch suppliers to include payment means whenever the buyer has something to pay](https://ironfang.uk/docs/finance/rules/NL-R-007.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-61](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-61/) 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-61)
- [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