Error Code 1010: Date and Time Format Incorrect

«Error code 1010: date and time format incorrect» is one of the most confusing rejection errors for business owners in e-invoicing. The invoice looks fine on screen, the numbers are correct, both parties are identified, and then the Fatoora platform rejects it for a reason unrelated to the amounts: the date or time field is written in a format the standard does not accept. This guide explains the error from its root: what the Zakat, Tax and Customs Authority (ZATCA) requires in the IssueDate andIssueTimefields, why validation fails, how to find the real cause, and how to prevent it for good.

This reference is part of a series on ZATCA e-invoicing errors, and it focuses exclusively on one error: date and time format. If you are looking for a broader list of field-format errors, start from the guide on Validation Errors. And to understand where these two fields sit inside the file structure, refer to the Invoice Header in XML.

What does error code 1010 mean?

Code 1010 is a rejection message the Fatoora platform issues when it finds that the value of a date or time field in the invoice file does not match the format the standard imposes. Rejection here does not only mean the date is logically wrong; it may mean the way the date itself is written is unacceptable. The Fatoora platform reads the XML file literally and compares every value against a strict rule. Any deviation from the expected format stops processing immediately.

The rejection message usually appears in this form in the platform’s response:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "code": "1010",
        "category": "FORMAT",
        "message": "Invalid date/time format",
        "field": "cbc:IssueDate"
      }
    ]
  }
}

Notice that the message pinpoints the offending field precisely. In this example the problem is in cbc:IssueDate. Sometimes the field mentioned is cbc:IssueTime, and sometimes another date field such as the supply date. Reading the rejection message first is the fastest way to locate the source of the error.

Why is the platform so strict about the date and time format?

Rejecting an entire invoice because of a slash instead of a hyphen may look like excessive strictness. But there is clear logic behind it. The Fatoora platform processes millions of invoices from thousands of different systems. If it let every system write the date its own way, the readings would blur together. The date 06/07/2026 means the sixth of July in one country and the seventh of June in another. This ambiguity is unacceptable in an official tax document.

That is why e-invoicing in Saudi Arabia adopted the global UBL 2.1 standard, which in turn relies on the date and time format defined in the international ISO 8601 standard. This format leaves no room for interpretation: the year first, then the month, then the day, ordered from largest to smallest. The benefit is that any system in the world reads the value with the same meaning, without confusion. In this, the Kingdom also aligns with the European standard EN 16931, which forms the semantic basis of e-invoicing in many countries.

The practical result is that the Fatoora platform does not try to guess what you mean. It validates the value against a single strict rule: if it matches, it is accepted; if it deviates, it is rejected with code 1010. There is no grey area. This strictness is in fact a protection for you: an accepted invoice allows no more than one interpretation of its date, and that protects you in any later review or audit.

The format the Authority requires for the date field

The cbc:IssueDate field carries the invoice issue date. The only accepted format is the international one known as ISO 8601, that is YYYY-MM-DD. That means four digits for the year, then a hyphen, then two digits for the month, then a hyphen, then two digits for the day. The date is Gregorian, not Hijri.

This example shows the correct format as it appears inside the file:

<cbc:IssueDate>2026-06-24</cbc:IssueDate>

The value 2026-06-24 means the twenty-fourth of June in the year 2026. Notice that the month comes before the day, the opposite of the order common in everyday Arabic writing. This order is part of the standard and may not be changed. The following table summarizes what is accepted and what is rejected.

The takeaway from the table: the date itself may be correct, but the way it is written drops the invoice. The separator between the parts must be a hyphen, the order must start with the year, and each part must carry its full number of digits.

The format the Authority requires for the time field

The cbc:IssueTime field carries the invoice issue time. Its accepted format is HH:MM:SS on a twenty-four-hour system. That means two digits for the hour, then a colon, then two digits for the minute, then a colon, then two digits for the second. The hour ranges from 00 to 23, and the minutes and seconds from 00 to 59.

The following example shows the correct format:

<cbc:IssueTime>14:42:18</cbc:IssueTime>

The value 14:42:18 means eighteen seconds past forty-two minutes past two in the afternoon. Do not use the 12-hour format with AM or PM, and do not write the hour as a single digit. The seconds part is required, and omitting it is a common cause of rejection.

The question that confuses many: do I write the Kingdom’s local time or Coordinated Universal Time? The answer is that an invoice issued by an establishment inside the Kingdom is recorded in local time, which is Saudi standard time, three hours ahead of Coordinated Universal Time (UTC). What matters is that the time is consistent with the issue date in the other field. A conflict between two different time zones within a single file is a hidden cause of many rejection cases, especially when the date is generated on a server in one time zone and the time is generated on a machine in another.

Edge cases in time worth watching

Midnight specifically is a common source of confusion. The first moment of the day is written 00:00:00, not 24:00:00. The hour never reaches 24 in the twenty-four-hour system; it returns to zero as the day advances. Any system that writes the hour as 24 causes rejection, and worse, it may push the date forward a full day if the transition is not handled correctly.

Another matter concerns some systems that add time-zone information to the time value, such as a suffix indicating the offset from Coordinated Universal Time. What matters is that your system sticks to the format the platform expects, and does not mix writing the time locally with writing it in standard form with a time-zone suffix in the invoice itself. Consistency is the rule: one format across all invoices, not one format here and another there.

Finally, pay attention to the invoice issued near midnight. If the date is generated in the last second of the day and the time is generated in the first second of the next day, the two moments become conflicting even though each is valid on its own. Generating both fields from the same time source at the same moment prevents this conflict entirely.

Common causes of error 1010

One code, but many causes. Understanding the exact cause shortens the time to a fix. These are the most recurring causes in the invoices of Saudi establishments.

The wrong separator between the date parts

The most common cause. The system that generates the invoice writes the date in a local format such as 24/06/2026 instead of the standard format. The slash is not accepted; a hyphen is required. This often happens when the system relies on the date settings of the user’s machine instead of a fixed format.

A Hijri year instead of a Gregorian one

Some systems write the Hijri date because it is the official calendar in many local transactions. The standard in e-invoicing requires the Gregorian date exclusively. Writing 1447-12-09 is rejected by the platform even if the date is correct in Hijri.

Omitting the seconds from the time

The time must carry the seconds. Writing 14:42 without the seconds breaks the format. The full format is 14:42:18.

A single digit instead of a double one

Each part must take its full number of digits. The sixth month is written 06 not 6, and the ninth hour is written 09 not 9. Dropping the leading zero breaks the format.

A date in the future

The issue date may not precede the current moment. An invoice dated to a day that has not yet come is rejected, because the Fatoora platform in the clearance model receives the invoice near the moment of its issuance. This error often appears when the server’s time is ahead of the actual time due to a wrong time-zone setting, so the issue time appears to the platform as a time that has not yet arrived.

A time-zone conflict between the fields

When the date is generated on a server in Coordinated Universal Time and the time is generated in local time, the two values may conflict when the actual moment is computed. The result is an invoice whose time appears to precede its date, or to follow it by hours. Consistency between the two fields is a condition for acceptance.

How to find the real cause step by step

Diagnosis matters more than guessing. Follow this order to reach the source of the error by the shortest route.

First, read the full rejection message and identify the field it mentions. The message names the offending field explicitly, whether it is cbc:IssueDate or cbc:IssueTime or another date field. This is the first piece of information, and it covers half the distance.

Second, open the rejected XML file and look at the actual value in that field. Compare it against the standard format: is the separator a hyphen? Is the date Gregorian? Does each part carry its full number of digits? Does the time carry the seconds?

Third, check the consistency of the date with the time. Compute the full moment and make sure it is not in the future, and that it does not conflict between two time zones. Review the time-zone setting on the server that generates the invoice.

Fourth, if the value is formally correct but is still rejected, the problem is usually in the time-zone setting or in the system clock itself. Correct the setting, then regenerate. The following table links each symptom to its likely cause.

How to fix the rejected invoice

After identifying the cause, the fix is straightforward. If the format is wrong, the fix is not in the single invoice only, but in the setting that generated it. Correcting one invoice manually solves the current case, but it leaves the door open for the error to recur in every later invoice.

The practical step: set the source of dates in your system to a fixed format unaffected by the machine’s settings. Then make sure the system server runs on the correct time zone for the Kingdom, and that its clock is synchronized with a trusted time source. After that, regenerate the invoice and send it again. The rejected invoice was not recorded by the platform, so resending it in a valid format is enough, with no need for any additional step.

If you use a certified accounting system, you most likely will not face this error at all, because the system generates the date and time in the standard format automatically. Error 1010 usually appears in systems that build the XML file manually or through a custom integration that did not follow the standard to the letter.

A full practical example: from rejection to acceptance

Let us follow a full real case to make the idea stick. An establishment sent an invoice and it was rejected with code 1010, and the field mentioned was cbc:IssueDate. On opening the file, this section of the header appeared:

<cbc:ID>INV-2026-000128</cbc:ID>
<cbc:IssueDate>24/6/2026</cbc:IssueDate>
<cbc:IssueTime>14:42</cbc:IssueTime>

A first reading reveals two errors together in the two fields. In the date field, the separator is a slash not a hyphen, the order starts with the day, and the month is a single digit. Each one of these three alone is enough for rejection. And in the time field, the seconds part is omitted. The correction rewrites both fields in the standard format:

<cbc:ID>INV-2026-000128</cbc:ID>
<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>14:42:18</cbc:IssueTime>

After the correction, the year comes first in four digits, the month in two digits 06, the day in two digits, and the separator is a hyphen. And the time was completed with the seconds part. It was resent and the invoice was accepted on the first attempt. Notice that the invoice number did not change, because the rejected invoice was never recorded, so there is no need for a new number or a credit note.

The lesson learned is that the real fix was not merely editing these two lines. Had the setting that produced them stayed as it was, the error would have recurred in the next invoice. The root fix was setting the system to generate the correct format automatically for every upcoming invoice.

The relation of the date and time to the rest of the invoice fields

The two issuance fields are not the only ones carrying a time value in the invoice. Some invoices contain additional dates, such as the actual supply date of the good or service, and dates within references to earlier documents in the case of credit and debit notes. All these dates are subject to the same format rule, YYYY-MM-DD. So when code 1010 appears, read the field mentioned carefully, as it may not be the issue date but another date in the file.

Likewise, the date logic is tied to the model of sending to the platform. Tax invoices between businesses go through the clearance path, where the invoice is sent to the Fatoora platform for clearance before being handed to the buyer, and here it is near the moment of its issuance. Simplified invoices directed to the consumer are reported within a defined window after their issuance. In both cases, the issue date and time must reflect the actual moment of issuance, not the moment of sending nor a later moment, and any large unjustified gap between the two moments may raise a flag.

How to prevent error 1010 from recurring

Prevention is cheaper than treatment. Error 1010 is not an error that happens once and disappears; it is a symptom of an unsound setting in the invoice-generation layer. Fixing the setting once closes the door on every recurrence. These are four practices that spare you rejection from the start.

Adopt a fixed format unaffected by the machine

The root problem in most cases is that the system writes the date in the local format of the user’s machine or browser. The solution is for the system to generate the standard format directly, independent of any machine’s settings. Do not leave the date format a decision made by the browser or the operating system; impose it explicitly in the file-generation layer.

Unify the time zone across all components

The invoice usually passes through several layers: the database that stores the creation time, the server that builds the file, and the user interface that displays the value. If the time zone differs between these layers, the conflict that causes rejection arises. The rule is simple: one unified time zone across all components, which is the Kingdom’s time, or a single time reference from which local time is derived at display only.

Synchronize server clocks continuously

A server clock drifts slowly over time if it is not synchronized with a trusted source. A drift of a few minutes is enough to make the issue time appear in the future, so the platform rejects it. Enable automatic time synchronization on every server that generates invoices, and check it periodically, as this step prevents a whole class of mysterious rejection cases where the value appears formally correct.

Test before the actual launch

Before relying on a new integration, issue a test invoice in the test environment the platform provides, and verify that the date and time fields are accepted. Testing one case near midnight, and another at the start of the month, reveals most format problems before they reach a real invoice. These few minutes of testing save hours of handling rejections later.

The practical difference between an establishment that suffers from this error and one that never sees it is in the file-generation layer. When a certified platform builds all the fields according to the standard, this class of errors disappears entirely, and the business owner is freed to run the establishment instead of tracking the details of the XML file.

What if the rejection recurs after the correction?

Sometimes you correct the format, resend, then the rejection returns with code 1010 again. This recurrence is frustrating, but it carries a clear signal: the error is not in the value you see, but in a deeper layer that generates it.

First, review that you corrected the setting, not the single invoice only. If you edited one line in one file while the system still generates the wrong format, the problem will return with every new generation. Make sure the correction happened in the generation source itself.

Second, inspect the server clock and its time zone once more. The value may look valid in the file, but the actual moment of sending differs from what you think because of clock drift. Correct the synchronization, then regenerate and send at the same moment.

Third, make sure the field mentioned in the rejection message is the field you actually edited. You may have fixed the issue date while the problem is in another date within the file. The rejection message names the field precisely, so read it literally before any edit.

If the rejection persists despite the soundness of everything above, the problem is most likely in the custom integration that builds the file. Here, moving to a certified platform that generates the fields according to the standard automatically is cheaper and safer than fixing the manual integration field by field.

How Qoyod helps you avoid error 1010

generates Qoyod’s e-invoicing software the date and time fields in the standard format automatically, so you do not write any value manually and are not exposed to the format error from the start. These are the most notable things the system offers in this respect:

• Generating the issue-date field in the Gregorian YYYY-MM-DD format automatically, without relying on the user’s machine settings.
• Writing the time field in the full HH:MM:SS format with the seconds, in Saudi standard time, and consistent with the issue date.
• A direct connection with the Fatoora platform in Phase Two, generating all header fields in the order the standard imposes.
• Managing the cryptographic stamp certificate (CSID) automatically, so the business owner is freed to run the establishment instead of following the details of the XML file.

The result is an invoice accepted on the first send, with no rejection code 1010 nor any other format error, because the generation layer follows the standard to the letter in every field.