UBL-SR-45: Give the payment due date in no more than one PaymentMeans

The short answer

UBL-SR-45 fails when more than one cac:PaymentMeans in the document holds a cbc:PaymentDueDate. In the recorded credit note both payment means give 2026-10-08. Keep the date in one payment means and remove it from the others.

A credit note has no cbc:DueDate of its own, so its due date does belong in cac:PaymentMeans/cbc:PaymentDueDate, once. An invoice states its due date as cbc:DueDate near the top of the document and should not repeat it in the payment means at all.

What the rule checks

The rule runs once on the document root and counts the cbc:PaymentDueDate elements directly inside cac:PaymentMeans. It fails above one, and the finding points at the root, whichever payment means carry them.

Elements are counted, not distinct values, so the same date twice fails as surely as two different dates. The payment reference and the payment means code may repeat as long as they agree; the due date may not. When tried, 2026-10-08 in one payment means and 2026-10-15 in the other gave the same finding as two equal dates.

Nothing compares a payment means date with an invoice due date. When tried on an invoice, a single cbc:PaymentDueDate of 2026-10-15 beside a cbc:DueDate of 2026-10-08 drew only the warning UBL-CR-412, and dates in both payment means reported this rule whether or not cbc:DueDate was present.

Only payment means are counted. When tried, a credit note with its due date in one payment means and again in cac:PaymentTerms/cbc:PaymentDueDate passed this rule, with just the warning UBL-CR-463 for the payment terms element. Two due dates inside one payment means never reach the rule: the schema allows one there, and the XSD layer rejected the document when tried.

How an integration ends up here

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

• The due date is written into every cac:PaymentMeans by the same template, so a second account brings a second copy.
• A mapping built for credit notes, where the due date belongs in the payment means, is reused for invoices that list several accounts.
• Instalments with different due dates are modelled as separate payment means, each with its own date.

How to fix it

1. In a credit note, keep cbc:PaymentDueDate in the first cac:PaymentMeans only and leave it out of the others.
2. In an invoice, write the due date once as cbc:DueDate, after cbc:IssueDate, and remove cbc:PaymentDueDate from every cac:PaymentMeans; the warning UBL-CR-412 goes with it.
3. If there really are several due dates, as with instalments, the model has room for one. Give the date of the first payment and describe the schedule in cac:PaymentTerms/cbc:Note.
4. Write the date as a plain YYYY-MM-DD: PEPPOL-EN16931-F001 checks that format on cbc:DueDate but does not select cbc:PaymentDueDate.

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 credit note: both payment means give the due date of 8 October

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment of the corrected credit note: the due date is given once, in the first payment means

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

The failing credit note gives cbc:PaymentDueDate 2026-10-08 in both cac:PaymentMeans; the corrected credit note keeps it in the first and leaves it out of the second. Only UBL-SR-45 is reported, at the document root: a credit note may carry a payment means due date, so nothing else objects, and the XSD and Peppol layers pass.

Where it applies

• Applies to Invoice and CreditNote, with a difference. When tried on an invoice, due dates in both payment means reported this rule together with the warning UBL-CR-412, which advises against any payment means due date in an invoice; with the date in one payment means, the invoice was valid and kept the warning.
• Reported by the EN 16931 layer as part of the UBL syntax binding.
• A credit note cannot move the date to the document level instead. When tried, adding cbc:DueDate to the credit note failed the XSD layer.
• The payment reference and the payment means code have single-value rules of their own, UBL-SR-44 and UBL-SR-47, which the same repeated payment means can break.

Related rules

• UBL-SR-44 lets payment means repeat one payment reference but not give different ones
• UBL-SR-47 requires every payment means to use the same code
• PEPPOL-EN16931-F001 checks the format of the invoice due date in cbc:DueDate
• 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-45 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.