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

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.

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.

Validate your corrected invoice

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

<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

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

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
• BR-61 requires an account identifier in each credit transfer payment means
• PEPPOL-EN16931-R008 reports a payment reference element left empty
• UBL-SR-45 allows a due date in only one payment means, even when the dates agree
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

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