ATW-DATE-NOT-A-CALENDAR-DATE The invoice issue date (BT-2) is "09.08.2026", which is not a calendar date
The invoice issue date (BT-2) is "09.08.2026", which is not a calendar date. UBL types this element as xs:date, so the only accepted form is a zero-padded YYYY-MM-DD naming a day that actually exists: "31.07.2026" and "07/31/2026" fail on syntax, and "2026-02-30", "2026-13-01" and "2025-02-29" fail because no such day is on the calendar. Core EN 16931 has no BR-* rule for it because the XML schema already forbids it — which is exactly why it is worth catching here. Left alone, this value passes every business rule, is written into the document verbatim, and the document is then rejected by schema validation before any validator reaches the business rules at all.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BT-2- Severity
fatal
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "ATW-DATE-NOT-A-CALENDAR-DATE",
"field": "BT-2",
"severity": "fatal",
"message": "The invoice issue date (BT-2) is \"09.08.2026\", which is not a calendar date. UBL types this element as xs:date, so the only accepted form is a zero-padded YYYY-MM-DD naming a day that actually exists: \"31.07.2026\" and \"07/31/2026\" fail on syntax, and \"2026-02-30\", \"2026-13-01\" and \"2025-02-29\" fail because no such day is on the calendar. Core EN 16931 has no BR-* rule for it because the XML schema already forbids it — which is exactly why it is worth catching here. Left alone, this value passes every business rule, is written into the document verbatim, and the document is then rejected by schema validation before any validator reaches the business rules at all.",
"fix": "Set issueDate to an ISO 8601 calendar date — four-digit year, two-digit month, two-digit day, separated by hyphens, with no time part and no timezone. If you are formatting a JavaScript Date, note that toISOString() appends a time part that must be trimmed, and that it converts to UTC first, which can move the date by a day.",
"example": "\"issueDate\": \"2026-07-31\"",
"xpath": "/ubl:Invoice/cbc:IssueDate",
"docsUrl": "https://github.com/attestwire/en16931#not-implemented-yet"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"issueDate": "2026-07-31"The fix
Set issueDate to an ISO 8601 calendar date — four-digit year, two-digit month, two-digit day, separated by hyphens, with no time part and no timezone. If you are formatting a JavaScript Date, note that toISOString() appends a time part that must be trimmed, and that it converts to UTC first, which can move the date by a day.