Invoice issue time (KSA-25) missing or in the wrong format

What does this mean?

The document states when it was issued in two fields, not one: the issue date (BT-2) and the issue time (KSA-25). BR-KSA-04 checks that the date is not in the future; this rule checks that the time is there at all, and that it is written in one of two shapes.

The shapes the message names are hh:mm:ss for a local time and hh:mm:ssZ when the value is UTC. Two digits for each part, a 24-hour clock, seconds always present. A 12-hour clock with AM or PM, minutes with the seconds dropped, or a whole date and time in the field are all outside what the rule describes.

The date and the time have to describe the same instant. A sale at 01:30 in Riyadh is 22:30 the previous day in UTC: put a Riyadh date next to a UTC time and the document claims a moment that never happened. Take both from one reading of one clock.

It is also what goes into the QR code. The timestamp a customer scanning the invoice sees is built from this date and this time, so a wrong time is not only an XML field — it is printed on the document.

Why does it happen?

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

• A source system that stores invoices with a date column and no time, so the time has to be produced at export and gets left out instead.
• A time formatted for a human: 7:20 PM, or 19:20 with the seconds dropped as noise.
• A UTC timestamp emitted without its Z, so it reads as local time and the document is three hours out — and across midnight, a day out from its own date.
• A whole ISO timestamp dropped into the field: 2026-09-10T19:20:30Z where only 19:20:30Z belongs.
• An offset in place of the suffix, 19:20:30+03:00. The message names local time and UTC and mentions no offset form, so it is not a shape to reach for.

How to fix it

3 steps, then send the invoice again.

1. 1
   Build both fields from one instant

   Take a single timestamp in Asia/Riyadh, put its date part in BT-2 and its time part in KSA-25. Two separate clock reads can straddle a second, and two different zones can straddle a day.

2. 2
   Format it explicitly, not by locale

   Spell the pattern out — zero-padded, 24-hour, HH:mm:ss — instead of calling a locale-aware short-time helper, which is what produces AM and PM and drops the seconds. Append Z only if the value really is UTC, and if it is, make BT-2 the UTC date too.

3. 3
   If your source has no time

   Use the moment the document is actually issued, not 00:00:00. Midnight passes the format check and states something untrue on a tax document, and for a simplified invoice the reporting window runs from the real moment of issue — see standard versus simplified tax invoices. The row almost always has a created timestamp somewhere, even when the invoice date column does not carry one.

Once corrected, send the invoice again. A rejected invoice was never recorded with the Authority, so it needs no credit note — send the corrected invoice itself.

Frequently asked questions