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

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.

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.

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

<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

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

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
• BR-CL-16 checks that each payment means code is in the permitted list
• BR-61 requires the payee account on each payment means coded as a credit transfer
• UBL-SR-48 is another UBL syntax rule that narrows a repeatable element to what the model allows: one tax category per line
• 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-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.