A date is not written YYYY-MM-DD

What does this mean?

The rule is about the shape, not the value: the issue date (BT-2) in cbc:IssueDate, the supply date (KSA-5) in cac:Delivery/cbc:ActualDeliveryDate and the latest supply date (KSA-24) in cbc:LatestDeliveryDate are all written in the ISO 8601 «calendar date complete representation»: 2026-09-22. Four digits for the year, a hyphen, two digits for the month, a hyphen, two digits for the day. Nothing before it and nothing after it.

Three things look like dates and are not in that shape: a date with its time (2026-09-22T10:15:00Z), because the time has its own field, KSA-25, and its own rule, BR-KSA-70; a date without zero padding (2026-9-2), because month and day are always two digits; and a date with a time zone (2026-09-22+03:00), because a calendar date is bare. And the plainer cases: 22/09/2026, 09/22/2026, 22-09-2026 and Sep 22, 2026 are all outside the rule even when the day is right.

The calendar is Gregorian. A Hijri date in the same shape — 1448-04-10 — passes the format check, being four digits, two and two, and is then read as the year 1448 of the common era: a document dated six centuries ago. No rule in the list we index catches that; BR-KSA-04 rejects the future only and the past goes through. This code guards the shape; what lies between the shape and the truth is yours.

It is a warning: the invoice is accepted and the warning recorded with it. The cost is that the date is a field with consequences: it places the invoice in its tax period, it starts the reporting deadline on a simplified invoice, and the QR code's stamp is built from it. A date that is not read the same way by every party is a date that will be disputed.

Why does it happen?

Ordered from the most common to the least — your cause is most likely the first or the second.

• JavaScript's default formatting: new Date().toString() gives Tue Sep 22 2026 10:15:00 GMT+0300, and toLocaleDateString() gives 9/22/2026 on an English machine — and on one set to ar-SA, a Hijri date in Arabic-Indic digits with invisible direction marks between its parts. By far the most common cause in web integrations.
• toISOString() and then the first ten characters: it looks like the right trick and is two traps. Uncut, it carries the time and a Z; cut, it gives the UTC date rather than the Riyadh one, so from midnight to three in the morning it produces yesterday — and yesterday passes BR-KSA-04 silently, and on the first of the month lands in the wrong VAT return.
• The Hijri calendar: an accounting system running on the Umm al-Qura calendar, or a user who typed a Hijri date into the date field, comes out in ISO shape and is read as Gregorian.
• Regional settings in Windows or Excel: 22/09/2026 from a worksheet, or the date's serial number (46287) when a CSV is read without formatting.
• Other languages' defaults: date('d/m/Y') in PHP, DateTime.Now.ToString() in .NET under the machine's culture, and Python's str(date.today()), which happens to be right while str(datetime.now()) carries the time.
• A free-text field on the form with no check, or an invisible character in the value: a trailing space, or a direction mark U+200E that locale formatting plants between the digits where the eye cannot see it.

How to fix it

4 steps, then send the invoice again.

1. 1
   Build the date from its parts, not from the default formatter

   In JavaScript: `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}` from a local date object. In PHP: $date->format('Y-m-d'). In .NET: ToString("yyyy-MM-dd", CultureInfo.InvariantCulture). In Python: strftime('%Y-%m-%d'). The general rule: an explicit format spelled out in letters, never one that depends on the machine's locale.

2. 2
   Compute the day in Riyadh time, then format it

   Time zone first, formatting second: move the instant to Asia/Riyadh and take the year, month and day from there. The reverse order — format in UTC, then send — gives a correct shape for the wrong day. The time that goes with the date is taken from the same instant; see BR-KSA-70.

3. 3
   Gregorian in the XML, Hijri for the reader if you wish

   If your system runs on the Hijri calendar, convert at the source with the Umm al-Qura tables to Gregorian before the document is built, and never send a Hijri triple dressed as ISO. A Hijri date has its place printed on the PDF beside the Gregorian one if your customers want it; the XML is Gregorian only.

4. 4
   Check the shape before signing

   Before the invoice is signed, test every date with an expression that matches the shape letter by letter — ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ — then confirm it is a real calendar day (no 31 February) and that its year is a year of this era. A check on your side prevents the warning on every invoice instead of reading it in the response after signing.

This code does not block acceptance, so the invoice you have is compliant. Correct the data so the warnings disappear from future invoices.

Frequently asked questions