# BR-50: Add the account identifier to the payee financial account

A credit transfer with code `30` or `58` has a `cac:PayeeFinancialAccount` but no account number in its `cbc:ID`. Add the real account identifier.

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

## The short answer

`BR-50` fails when a `cac:PaymentMeans` with code `30` (credit transfer) or `58` (SEPA credit transfer) contains a `cac:PayeeFinancialAccount` whose `cbc:ID` is absent or blank. Put the number of the account the buyer should pay into, such as an IBAN or a national account number, in `cbc:ID` as the first child of that account element.

A missing `cbc:ID` also fails `BR-61`, so the two arrive together. An element that is present but empty fails this rule and `PEPPOL-EN16931-R008` instead, without `BR-61`.

## What the rule checks

The rule looks only inside payment means whose `cbc:PaymentMeansCode` is `30` or `58`, and only when that payment means has a `cac:PayeeFinancialAccount`. It passes when the account holds a `cbc:ID` with some text other than whitespace.

The account name in `cbc:Name` and the bank identifier in `cac:FinancialInstitutionBranch` do not count. The recorded failing invoice keeps both and still fails.

Missing and empty are reported differently. With no `cbc:ID` at all, `BR-50` and `BR-61` are both reported. With an empty `cbc:ID`, or one holding only spaces, `BR-61` is satisfied because the element exists, and this rule is reported together with `PEPPOL-EN16931-R008`; both cases were tried.

With no `cac:PayeeFinancialAccount` at all this rule has nothing to inspect, and `BR-61` reports the missing account on its own.

The code match in this rule is exact. When tried with a space either side of `30`, this rule stayed silent and only `BR-61`, which trims the code before comparing, reported the missing identifier.

Other payment means codes are out of scope. An account without an identifier under code `42` (payment to bank account) passed every layer when tried.

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BG-17 | Credit transfer | `cac:PaymentMeans/cac:PayeeFinancialAccount` |
| 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:

- The account number lives in a bank details table and the lookup fails for this seller entity or currency, while the account name comes from the company record and is still written.
- The serialiser drops a null account number but keeps the parent element because its other children have values.
- The account number was put in `cac:FinancialInstitutionBranch/cbc:ID`, which is where the bank identifier, such as a BIC, belongs.
- The account number was written to `cbc:PaymentID` or to a note, and the account element was built from the remaining fields.

## How to fix it

1. Find the account the seller wants this invoice paid into: the IBAN or national account number from the seller's own bank details for the entity and currency of the invoice.
2. Write it as `cbc:ID`, the first child of `cac:PayeeFinancialAccount`, before `cbc:Name` and `cac:FinancialInstitutionBranch`.
3. Keep the bank identifier in `cac:FinancialInstitutionBranch/cbc:ID`. It sits beside the account identifier and does not replace it.
4. If the buyer will not pay by transfer, change `cbc:PaymentMeansCode` to the code for the real method and remove the account element, instead of sending a credit transfer without an account.

## 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 payee account has a name and a branch but no account identifier

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

Fragment of the corrected invoice: the account identifier is the first child of the payee account

```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>
```

The corrected invoice has `<cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>` at the start of `cac:PayeeFinancialAccount` and the failing one lacks it; nothing else differs. The failing document also reports `BR-61`, the companion rule that requires an account identifier for codes `30` and `58` whether or not an account element exists. `BR-50` is located at the account element and `BR-61` at the payment means, but one missing element causes both. `EXAMPLE-ACCOUNT-001` is a placeholder, not an account number format.

### What the validator reported

- The failing invoice reports **BR-50** and [BR-61](https://ironfang.uk/docs/finance/rules/BR-61.md). The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/BR-50-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 a credit transfer account and no identifier reported `BR-50` and `BR-61` when tried.
- Both findings come from the EN 16931 layer; the Peppol layer passes in the recorded example.
- Each `cac:PaymentMeans` is checked on its own, and the finding location names the one without an identifier.
- A code outside the UNTDID 4461 list, such as `BACS`, fails `BR-CL-16` and takes the payment means out of scope here, so correcting the code to `30` can bring this finding up next.

## Related rules

- [BR-61 requires the account identifier for the same two codes and fires with this rule when the ID is missing](https://ironfang.uk/docs/finance/rules/BR-61.md)
- [PEPPOL-EN16931-R008 is reported instead of BR-61 when the account ID element is present but empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [BR-CL-16 checks the payment means code that decides whether this rule applies](https://ironfang.uk/docs/finance/rules/BR-CL-16.md)
- [PEPPOL-EN16931-R061 is the direct debit counterpart, requiring a mandate reference](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R061.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-50](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-50/) 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-50)
- [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