BR-KSA-04 Rejects the invoice

Invoice date is in the future

The issue date of an invoice must not be later than the current date at the Authority. A past date is accepted and a future date is rejected — and what most often causes it is a system that computes today in a time zone other than Riyadh.

The message text as the Authority sends it in English, unedited

The document issue date (BT-2) must be less or equal to the current date.

What does this mean?

The comparison is on the date (BT-2), not on the time: an invoice dated today passes at any hour of it, and an invoice dated tomorrow is rejected even one minute before midnight.

It works in one direction only: a past date never trips this rule — the code catches the future and nothing else.

The verdict is given by the clock at the Authority, not the clock on your machine. A drift of minutes does not show up here because the comparison is by day, but a time-zone difference moves the whole day.

Why does it happen?

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

  • The server runs on UTC and the system builds the date from it: after 9pm Riyadh time your machine is still on the same day while you counted it as the next one — or the reverse for zones east of Saudi Arabia.
  • Generating tomorrow invoices in advance (subscriptions and scheduled payments) and sending them as soon as they are generated instead of waiting for their day.
  • A device or server clock set manually to the wrong date.
  • A manual date field on the form where tomorrow was typed by mistake.

How to fix it

3 steps, then send the invoice again.

  1. 1
    Standardise on Riyadh time

    Build the issue date from Riyadh time (Asia/Riyadh) on the server that generates the invoice, not from UTC and not from the user device. This closes the first and most common cause for good.

  2. 2
    Send the invoice on its own day

    If your system generates scheduled invoices ahead of time, hold the send until the date written on them. Generating in advance is fine; sending in advance is what is rejected.

  3. 3
    Correct the date and resend

    A rejected invoice was never recorded at the Authority, so it needs no credit note: correct the date to the actual day of issue and send the same invoice again.

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.

Does ZATCA Tools prevent it?

Yes on the automatic path: the date and time are stamped in Riyadh time on the server at the moment of issue, so the time-zone shift that causes this code does not happen.

Related codes

Frequently asked questions

Can I issue an invoice dated yesterday? +
This rule does not prevent it — it rejects the future only. But remember that a simplified tax invoice must be reported within 24 hours of the actual issue, so putting an earlier date on it does not push the deadline back.
I issued an invoice near midnight and it was rejected — why? +
Most likely your system computed the date in a time zone other than Riyadh and wrote tomorrow, or a day off in the other direction. Set the date to be built on Asia/Riyadh and the midnight cases disappear.
You fixed this one — now avoid the next

ZATCA Tools builds the signature, the PIH, the counter and the encoding for you, and validates your data before it is sent. Completely free for now, and no credit card.

Start for free

← All ZATCA error codes