BR-DE-16 Payment Due Date
What this rule checks
BR-DE-16 verifies that the payment due date (BT-9) is present in the invoice whenever payment means or payment terms are specified. The field cbc:DueDate (or cbc:PaymentDueDate in some UBL contexts) must exist and contain a valid date in YYYY-MM-DD format.
Within XRechnung, BT-9 (Payment due date) is a document-level field. This rule fires whenever the invoice contains payment information via the cac:PaymentMeans group.
Why this rule exists
German commercial law (section 286 BGB) stipulates that a debtor only enters default when a specific calendar date for payment has been agreed upon or is determinable. Without an explicit due date on the invoice:
- The issuer cannot claim automatic default (Verzug)
- Automated processing in ERP systems (SAP, DATEV, etc.) is hindered
- There is no basis for automated dunning workflows
- Cash flow management on the receiver’s side suffers
The EN 16931 standard and the German CIUS (XRechnung) tighten this requirement: once payment means are specified, BT-9 must be provided.
What triggers a failure
The error is triggered when:
- Payment means present but no due date — The invoice contains a
cac:PaymentMeansblock butcbc:DueDateis completely missing - Empty due date — The element exists but is empty:
<cbc:DueDate/> - Invalid date format — The value does not conform to ISO 8601, e.g.
15.02.2024instead of2024-02-15
Failing XML example
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:module:...">
<!-- Invoice header -->
<cbc:ID>INV-2024-001</cbc:ID>
<cbc:IssueDate>2024-01-15</cbc:IssueDate>
<!-- ERROR: PaymentDueDate is missing here -->
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE89370400440532013000</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<!-- More invoice data... -->
</ubl:Invoice>
The validator reports: BR-DE-16: The element “Payment due date” (BT-9) must be provided.
The fix
Add cbc:DueDate at the document level:
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:module:...">
<cbc:ID>INV-2024-001</cbc:ID>
<cbc:IssueDate>2024-01-15</cbc:IssueDate>
<cbc:DueDate>2024-02-15</cbc:DueDate> <!-- BT-9: Payment due date -->
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE89370400440532013000</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
</ubl:Invoice>
Note: In UBL 2.1, the element is called cbc:DueDate at document level (not cbc:PaymentDueDate). In CII, the path is ram:DueDateDateTime.
Edge cases and common mistakes
Date format
The date must use YYYY-MM-DD (ISO 8601) format. Common mistakes:
15.02.2024— German date format, but invalid in XML02/15/2024— US date format, invalid2024-2-15— missing leading zero, invalid
Payment terms as text
Even when cbc:PaymentTerms/cbc:Note contains text such as “Net 30 days”, BT-9 must still be calculated and provided as a concrete date. The validator does not accept a textual description as a substitute.
Due date in the past
The rule does not check whether the date is in the future. A past date is technically valid — however, receiving systems may issue warnings or reject the invoice, especially Peppol access points.
Partial payments
For invoices with multiple due dates (installment payments), BT-9 is set to the first or next payment date. Individual installments are specified via the BG-22 (PAYMENT INSTRUCTIONS) group.
Credit notes
For credit notes (TypeCode 381), BT-9 is optional since no payment is expected from the recipient. BR-DE-16 typically does not apply.