# UBL-CR-412: Move the due date from the payment instructions to the invoice header Warning: an invoice states its due date in `cbc:DueDate`, not in the payment instructions. The document stays valid; move the date. - Layer: EN 16931 - Severity: warning (the document stays valid) - Topics: Core fields - Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-412/ - Explanation last updated: 2026-09-29 ## The short answer `UBL-CR-412` is a warning raised when an invoice has `cbc:PaymentDueDate` in its payment instructions (`cac:PaymentMeans`). An invoice states its due date (BT-9) in the header, in `cbc:DueDate`: move the date there. The warning on its own does not make the document invalid, though other rules still check what is there. ## What the rule checks The rule checks whether an invoice has `cac:PaymentMeans/cbc:PaymentDueDate`. Its value is not read, and a credit note is not checked. It runs once against the whole document, so it is reported once however many times the document has the element, and the finding points at the document root rather than at the element: look for `cac:PaymentMeans/cbc:PaymentDueDate` in the XML. | Term | Meaning | UBL element | |---|---|---| | - | PaymentDueDate (BT-9 on a credit note only) | `cac:PaymentMeans/cbc:PaymentDueDate` | | 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 source system holds the value, and the mapping writes it because UBL 2.1 has a place for it. - A general UBL 2.1 library writes every element and attribute it has a value for, whether or not EN 16931 uses it. - A mapping built for another UBL-based document, such as an order, a despatch advice or a national profile, is reused for Peppol BIS Billing. ## How to fix it 1. Move the date from `cac:PaymentMeans/cbc:PaymentDueDate` to `cbc:DueDate` in the header. 2. The due date (BT-9) is `cbc:DueDate` in a UBL invoice; only a credit note, which has no `cbc:DueDate`, states it in the payment means. 3. Validate again: the warning goes. ## Before and after These are fragments, not complete documents. The complete synthetic documents they come from are linked below. Fragment of the invoice with the warning: PaymentDueDate in the payment instructions ```xml 30 2026-10-08 PAYMENT-001 ``` Fragment of the corrected invoice: the same date in cbc:DueDate in the header ```xml urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 EXAMPLE-INV-002 2026-09-08 2026-10-08 380 Example only. Terms & references <must> be preserved. Café 🐺 2026-09-07 ``` The invoice with the warning has `2026-10-08` in the payment instructions and no `cbc:DueDate`; the corrected invoice has the same date in `cbc:DueDate` in the header instead. It reports only this warning and is valid on every layer, so it would be accepted as it stands. ### What the validator reported - The invoice with the warning is valid, and reports the warning **UBL-CR-412**. The corrected document passes every layer with no findings. - [Download the XML with the warning](https://ironfang.com/finance/rule-examples/UBL-CR-412-warning.xml) - [Download the corrected XML](https://ironfang.com/finance/rule-examples/syntax-invoice-complete.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 only to a UBL `Invoice`: the rule skips credit notes, because the UBL 2.1 credit note has no `cbc:DueDate` and states its due date (BT-9) in `cac:PaymentMeans/cbc:PaymentDueDate`. - The warning comes from the EN 16931 layer's rules for the UBL syntax. In the recorded example the schema layer passes: the element is valid UBL 2.1 and is only outside the EN 16931 model. ## Related rules - [UBL-CR-411: ID in the payment instructions](https://ironfang.com/docs/finance/rules/UBL-CR-411.md) - [UBL-CR-413: PaymentChannelCode in the payment instructions](https://ironfang.com/docs/finance/rules/UBL-CR-413.md) - [UBL-CR-414: InstructionID in the payment instructions](https://ironfang.com/docs/finance/rules/UBL-CR-414.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-29.1: source checked 2026-09-29, explanation last updated 2026-09-29. [The official definition of UBL-CR-412](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-412/) 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-CR-412) - [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