# UBL-SR-44: Use one payment reference for every payment means in the invoice

Two `cbc:PaymentID` values differ. An invoice has one remittance reference: repeat the same value in each `cac:PaymentMeans`, or give it once.

- 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-44/
- Explanation last updated: 2026-09-28

## The short answer

`UBL-SR-44` fails when the document holds `cbc:PaymentID` elements with more than one distinct value. In the recorded example the second `cac:PaymentMeans` asks for `PAYMENT-002` where the first asks for `PAYMENT-001`. Choose the one reference the buyer should quote and write that same value in each payment means.

Several payment means are allowed, for instance one for each bank account the buyer may pay into, and each may repeat the reference. What the model cannot express is a second, different reference: it has a single remittance information field for the whole invoice.

## What the rule checks

The rule runs once per document and collects every `cbc:PaymentID`, wherever it is. It counts the distinct values and fails when there are two or more; the finding points at the document root, and when tried with three payment means asking for three different references there was still only one finding.

Repeats and gaps are allowed. When tried, dropping `cbc:PaymentID` from the second payment means passed, and the corrected invoice gives `PAYMENT-001` in both.

Values are compared exactly as written. When tried, `PAYMENT-001 ` with a trailing space and `payment-001` in lower case each counted as a second reference and failed the rule.

Two different references inside one payment means fail twice over. When tried, a single `cac:PaymentMeans` holding `PAYMENT-001` and `PAYMENT-002` reported this rule and `UBL-SR-26`, which allows one `cbc:PaymentID` per payment means; the same value written twice there reported `UBL-SR-26` alone.

| Term | Meaning | UBL element |
|---|---|---|
| BT-83 | Remittance information | `cac:PaymentMeans/cbc:PaymentID` |
| 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 payment reference is generated per bank account or per payment channel, so each `cac:PaymentMeans` gets its own.
- Instalments are modelled as separate payment means, each with the reference of its instalment.
- A reference is normalised in one place and not in another, leaving a trailing space or a different letter case in one copy.

## How to fix it

1. Decide which reference the buyer must quote when paying, such as the invoice number or a structured creditor reference.
2. Write exactly that value, character for character, in the `cbc:PaymentID` of every `cac:PaymentMeans` that carries one, or leave it out of all but one.
3. If you need different references for different accounts or instalments, the model has no place for them. Keep one reference and describe the arrangement in the payment terms, `cac:PaymentTerms/cbc:Note`.
4. Trim and normalise the reference once, before it is copied into each payment means.

## Before and after

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

Fragment of the failing invoice: two accounts, each with its own 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>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-002</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 ask for PAYMENT-001

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

The second `cac:PaymentMeans` carries `PAYMENT-002` in the failing invoice and `PAYMENT-001` in the corrected one; both documents offer the same two accounts under code `30`. The failing document reports `UBL-SR-44` alone, at the document root, since each payment means on its own is complete and valid.

### What the validator reported

- The failing invoice reports **UBL-SR-44**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.com/finance/rule-examples/UBL-SR-44-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 two payment means asking for different references reported this rule.
- Part of the UBL syntax binding, reported in the EN 16931 layer; the Peppol layer passed the recorded failing invoice.
- The payment means code has the same single-value restriction, enforced by `UBL-SR-47`. When tried, changing both the code and the reference of the second payment means reported both rules.
- An empty `cbc:PaymentID` counts as a value too. When tried, emptying the second one reported this rule and `PEPPOL-EN16931-R008`.

## Related rules

- [UBL-SR-47 requires the payment means code to be the same in every payment means](https://ironfang.com/docs/finance/rules/UBL-SR-47.md)
- [BR-61 requires an account identifier in each credit transfer payment means](https://ironfang.com/docs/finance/rules/BR-61.md)
- [PEPPOL-EN16931-R008 reports a payment reference element left empty](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [UBL-SR-45 allows a due date in only one payment means, even when the dates agree](https://ironfang.com/docs/finance/rules/UBL-SR-45.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-44](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-SR-44/) 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-44)
- [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