Error Code 1018: Invoice Outside the 24-Hour Reporting Window

If your system tries to report a simplified B2C invoice to the Fatoora platform and it returns error code 1018, the message is telling you that the invoice arrived after the reporting window closed — the window fixed at twenty-four hours from the moment it was issued. A simplified invoice does not go through instant clearance the way a standard B2B invoice does; instead it is handed to the buyer at the moment of sale and then reported to the Authority within a window no longer than twenty-four hours. When reporting is delayed past this window, the platform rejects the submission and returns code 1018. This page explains the error at its root: what exactly the reporting window is, from where it is counted, why late reporting is rejected, which automated causes delay it — such as batching, queue waits, and clock drift — and how to diagnose the delay, fix it, and prevent it from recurring.

This guide is part of the ZATCA e-invoicing error reference, within the Reporting Errors section that gathers all errors on the B2C reporting path, and within the concept of Reporting in e-invoicing, all part of the e-invoicing system by Qoyod. The target audience is the developer, integration analyst, or accountant who runs the technical issuance and wants a precise understanding of the cause, not just a surface-level step.

What error code 1018 means exactly

Error code 1018 is a rejection at the level of reporting timing — not at the level of the invoice structure, its calculation, or its signature. The invoice itself may be perfectly sound: its header complete, its numbers correct, its signature valid. The only problem is that it arrived late. The platform receives the report, reads the issue date and time stamped inside the invoice, compares it to the moment of receipt, and if the difference exceeds twenty-four hours it returns code 1018.

What matters is understanding the difference between two entirely distinct paths in the second phase of e-invoicing. The standard B2B invoice goes through instant clearance: it is sent to the Authority first, cleared, then handed to the buyer. The simplified B2C invoice, on the other hand, is handed to the buyer at the moment of sale, then reported to the Authority afterward within the twenty-four-hour window. Code 1018 belongs to the second path alone. You will not see it in the clearance of a B2B invoice, because that path has no deferred reporting window in the first place.

This distinction is practical. When you see code 1018 you immediately know the invoice is a simplified B2C type, and that the fault is in the time of arrival, not in its content. Do not go audit the fields or the signature; go straight to a single question: why did sending this invoice take more than twenty-four hours after it was issued?

How the twenty-four-hour window is counted

The reporting window is counted from the moment the invoice is issued — stamped in the IssueDateTime field inside the invoice itself, not from the moment of the send attempt. This is a fundamental point that many overlook. The clock starts at issuance, so if you issue the invoice at one o’clock in the afternoon today, you must report it before one o’clock in the afternoon tomorrow. Every minute of delay in the pipeline after issuance eats into the window’s balance.

The following table shows how the time difference between issuance and reporting moves, and when rejection occurs.

The third case in the table is the heart of the problem. The invoice did not change, but it was sent an hour and a half after the deadline expired, so it was rejected. Notice that the difference that pushed it into rejection was only an hour and a half over the limit — and that is enough. The platform grants no grace period after twenty-four hours.

Why late reporting is rejected and exposes you to a violation

Late reporting may look like a formality, but it is not. The Authority builds the e-invoicing system on the premise that every transaction appears in its records within a narrow time window, so that the tax record stays synchronized with actual activity. Late reporting breaks this synchronization, which is why the platform handles it with rejection rather than conditional acceptance.

The consequences of delay go beyond the rejection message on the screen:

• The invoice remains unreported. Rejection with code 1018 means the platform did not receive the invoice into its records. As far as the Authority is concerned, the invoice is as if it was never reported — even though you actually handed it to the buyer.
• You are exposed to non-compliance fines. A simplified invoice that was not reported on time falls within the scope of violations for which the Authority may impose fines, especially if the delay recurs and becomes a pattern rather than an isolated incident.
• A gap opens between your records and the Authority’s. Every late invoice widens the gap between what appears in your system and what the Authority sees, which makes reconciliation harder during an audit and raises questions about the integrity of the sequence.
• A resend queue accumulates. Rejected invoices pile up in a queue that needs manual handling, so you get busy processing the past instead of controlling the present.

The bottom line is that code 1018 is not an alert you can postpone. It is a hard rejection that leaves an actual invoice outside the Authority’s records, and every day that passes without fixing the source adds new invoices to the gap.

There is an additional dimension many overlook. A recurring code 1018 is not just a technical problem but an operational signal of a flaw in the send design. The Authority looks at the compliance pattern over time, not at a single invoice. An establishment that reports its invoices on time consistently builds a clean compliance record, while an establishment where delay recurs paints a different picture during an audit. That is why treating code 1018 at its root protects the establishment’s tax record, not just one invoice. And the faster you shift sending to real time instead of batching, the less likely the delay turns from an isolated incident into a pattern that draws attention.

The automated causes that delay reporting

A developer rarely delays reporting on purpose. The delay arises from three recurring automated patterns, and knowing them points your diagnosis straight to the source.

Batching

Many systems do not send each invoice the moment it is issued; instead they collect the day’s invoices and send them in a single batch at a set time, often at the end of the day or at night. This design is reasonable from a performance standpoint, but it is dangerous for the reporting window. An invoice issued at ten in the morning waits until the midnight batch, so it starts its journey having already consumed fourteen hours of its balance. And if that batch itself is delayed or fails and is retried the next day, its oldest invoices fall outside the window and come back with code 1018.

The greater danger is that a single day’s error in the batch hits dozens of invoices at once, not a single invoice. This is what makes code 1018 appear suddenly in large numbers instead of appearing one at a time.

Queue delay (Queue)

Systems that send invoices through an asynchronous processing queue face a different risk. The invoice enters the queue at the moment of issuance, but the send worker may stop, slow down under pressure, or get stuck on a failed invoice and hold up the queue behind it. The result is that sound invoices wait for hours before their turn arrives, and some cross the window before being sent.

The sign of this pattern is that code 1018 appears in the invoices that hit a pressure peak or a temporary worker outage, not in every invoice. Monitor the queue length and the wait time in it, as these are the early indicator before rejection occurs.

Clock drift and time-zone drift (Clock Drift)

This pattern is the most hidden of the three, because it does not actually delay sending — it makes it appear late. If the server clock is drifting off the correct time, or the issuance moment was recorded in the wrong time zone, then the difference the platform computes will differ from the real difference. For example, if the issuance time is stamped in a time other than official Saudi time, it may appear to the platform that the invoice was issued hours before its actual issuance, so it falls outside the window even though sending was fast.

The issuance time must be stamped in official Saudi time, and the server clock must be synchronized via a reliable synchronization protocol. A drift of minutes may let through invoices on the edge of the window, but it blows up on invoices close to the limit.

How to read the rejection message

When reporting is rejected, the platform returns a response carrying the reporting status and a list of validation errors. Each error carries a code, a category, and a message. The following block is an illustrative example of a rejection response due to exceeding the twenty-four-hour window. Copy it and compare it to the response structure your system returns.

{
  "validationResults": {
    "infoMessages": [
      {
        "type": "INFO",
        "code": "XSD_ZATCA_VALID",
        "category": "XSD validation",
        "message": "Complied with UBL 2.1 standards"
      }
    ],
    "warningMessages": [],
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1018",
        "category": "Reporting window validation",
        "message": "Simplified invoice reported after the 24-hour window."
      }
    ],
    "status": "ERROR"
  },
  "reportingStatus": "NOT_REPORTED",
  "issueDateTime": "2026-06-24T13:00:00",
  "receivedDateTime": "2026-06-25T14:30:00"
}

The keys that matter to you when reading:

• code with the value 1018 is what you rely on to classify the error. Tie your system’s logic to the code, not to the descriptive text, because the code is fixed while the text may be phrased in different ways.
• category with the value Reporting window validation confirms that the fault is in the reporting timing, not in the invoice structure or its calculation.
• reportingStatus with the value NOT_REPORTED means the invoice did not enter the Authority’s records, so it is unreported until you resend it successfully.
• Compare issueDateTime andreceivedDateTime. The difference between them is the difference the platform rejected. In the example above the difference is twenty-five and a half hours — that is, an hour and a half over the limit.

This time comparison is the most important step in diagnosis. When you see the difference between issuance and receipt, you know by how much you exceeded the window, and you know whether the delay is small — pointing to clock drift — or large — pointing to a stalled batch.

How to diagnose the source of the delay in your system

Diagnosis starts from the size of the delay you read in the response, because the size points to the causing pattern:

• A delay of minutes over the limit. Most likely clock drift or a wrong time zone. The invoice was sent on time, but the issuance moment was recorded in a way that makes the difference appear larger. Check the server clock synchronization and the timing of stamping IssueDateTime.
• A delay of hours on scattered invoices. Most likely a stuck or slow queue. Check the send worker logs and the wait time in the queue around the time of the affected invoices.
• A delay on dozens of invoices at once. Most likely a late or failed batch. Check the batching schedule and when the last successful batch was sent — most likely a whole batch fell late.

After identifying the pattern, go straight to its source. Code 1018 does not ask you to edit the invoice; it asks you to fix the pipeline that delayed it. This is what distinguishes it from structure errors that are corrected inside the invoice.

How to correct the invoice and re-report it

The correction goes through two steps; neither one alone is enough. The first treats the current rejected invoice, and the second treats the source so it does not recur. The most important point is that re-reporting is not a repeat of the same file: any invoice that exceeded its window cannot be reported retroactively as if nothing happened.

The correct procedure for a simplified invoice that exceeded its window is to handle it per the Authority’s guidelines for late invoices — not to resend it with its old issuance date hoping for acceptance, because the platform will reject it with code 1018 again as long as the difference between issuance and receipt exceeds the limit. Handle the case per your system’s policy approved by the Authority, then direct your greater effort at the source.

As for treating the source, it depends on the pattern you diagnosed:

• If batching is the cause, shrink the gap between issuance and sending. Switch from a single daily batch to closely spaced batches, or to immediate sending at issuance, so that no invoice waits for hours before starting its journey.
• If the queue is the cause, add monitoring for the queue length and the wait time, and make failed invoices get isolated into a separate queue instead of holding up the main queue behind them.
• If clock drift is the cause, synchronize the server clock via a reliable protocol, always stamp the issuance time in official Saudi time, and test the behavior on edge cases such as midnight and the change of day.

The governing rule is that fixing a single invoice is worthless unless you treat the source that delayed it, because the same pattern will produce a new 1018 invoice tomorrow.

How to tell code 1018 apart from other reporting errors

The Reporting Errors section includes more than one code, and many confuse them because they all fall on the simplified B2C invoice path. But each code has a different meaning and a different source, and telling them apart shortens the diagnosis. Code 1018 alone concerns timing: the invoice is sound but arrived late. The other errors on the path concern the content, the signature, or the identity, and they occur even if the invoice arrives on time.

This difference is fundamental to the way you treat it. A content error is corrected inside the invoice: you edit the wrong field and regenerate. Code 1018, on the other hand, is never corrected inside the invoice, because the invoice is not wrong. What gets corrected is the pipeline that delayed it. If you tried to treat 1018 by editing a field in the invoice, the result would not change, because the platform looks at the time difference between issuance and receipt, not at any internal field.

So the practical rule is: when you see a code on the reporting path, first ask whether it is a timing code or a content code. If it is 1018, the treatment is in the send infrastructure. If it is anything else, the treatment is usually inside the invoice. This first classification saves long minutes of diagnosing in the wrong direction. And to review the rest of the reporting-path codes and their meanings, see Reporting Errors.

Where code 1018 sits in the simplified invoice path

Understanding where code 1018 sits in the path clarifies why it has nothing to do with the invoice structure. The simplified invoice path starts at the point of sale: the invoice is issued and handed to the buyer immediately, and at that moment the window clock starts. During the next twenty-four hours, its report must reach the Fatoora platform. As long as reporting is within the window, it is accepted. When the limit is exceeded, the door of acceptance closes and code 1018 appears.

This differs fundamentally from the standard B2B invoice, which goes through instant clearance before being handed to the buyer, so it has no deferred reporting window. That is why code 1018 is specific to the B2C path alone. For a deeper understanding of the difference between the two paths, see Reporting Errors and the concept of Reporting in e-invoicing.

A practical scenario: a restaurant in Riyadh that batches the day’s invoices

A restaurant in Riyadh issues hundreds of simplified invoices a day through its points of sale. Its team designed the integration to collect the day’s invoices and send them in a single batch at midnight, to save on platform calls. The arrangement worked for months without a visible problem.

One night, the batch server failed and that day’s batch was not sent. The failure was discovered at noon the next day, and the batch was restarted. But yesterday’s early-morning invoices had been issued more than thirty hours earlier, so they all came back with code 1018. The problem looked sudden and huge, because dozens of invoices fell together, not a single invoice.

The diagnosis revealed that the problem was not in the invoices but in the send design. An invoice issued at seven in the morning that waits for the midnight batch consumes seventeen hours of its window before it moves, leaving only seven reserve hours. Any failure in the batch devours this reserve instantly. The fix was not to repair yesterday’s invoices only, but to switch sending from a single daily batch to immediate sending at issuance — and code 1018 disappeared at its root.

How to prevent the error from recurring for good

Preventing code 1018 is easier than treating it, because it is a timing error, not a content error. The golden rule is to shrink the gap between issuing the invoice and reporting it to the smallest possible degree, because the closer reporting is to the moment of issuance, the further you are from the twenty-four-hour limit:

• Report immediately at issuance, not by batching. Send every simplified invoice the moment it is issued instead of collecting it into a batch. Immediate sending turns the window into a huge reserve rather than a tight constraint.
• Monitor the window balance, not the occurrence of rejection. Create an alert for any invoice not reported within a few hours of its issuance, so you handle it before it approaches the limit rather than after exceeding it.
• Synchronize the clocks and fix the time zone. Make sure the clock of every server in the pipeline is synchronized, and that the issuance time is always stamped in official Saudi time.
• Isolate failed invoices from the main queue. Prevent a stuck invoice from holding up the queue behind it, so that sound invoices are not delayed because of a single stalled invoice.
• Test the edge cases. Test the behavior at midnight, at the change of day, and at peak pressure, as these are the moments when code 1018 is usually born.

When these controls come together, code 1018 becomes a rare incident rather than a recurring pattern, and your simplified invoices stay inside the Authority’s records on time.

How Qoyod takes care of reporting your invoices on time

Qoyod sends every simplified B2C invoice to the Fatoora platform the moment it is issued, not by daily batching that consumes the window. This design keeps the difference between issuance and reporting within minutes, so you stay far from the twenty-four-hour limit with a wide margin. Qoyod also stamps the issuance time in a unified time and manages the signature with the CSID compliance identifier certificate automatically, so reporting does not fall into clock drift or a wrong time zone.

It remains for you to register the CSID compliance identifier with the Authority once at the start, and Qoyod guides you through the step. For an understanding of the rest of the reporting-path errors, see Reporting Errors, and for a comprehensive look at e-invoicing errors, see ZATCA e-invoicing error reference.

Frequently asked questions

From where is the twenty-four-hour window counted?
From the moment the invoice is issued, stamped in the IssueDateTime field inside the invoice, not from the moment of the send attempt. The clock starts at issuance, so every delay in the pipeline after it eats into the window’s balance.

Does code 1018 concern all invoice types?
No. It concerns the simplified B2C invoice alone, because it is the only one reported after delivery within a deferred window. The standard B2B invoice goes through instant clearance before delivery, so it has no reporting window to exceed.

Do I resend the rejected invoice as is after exceeding the window?
No. As long as the difference between issuance and receipt exceeds twenty-four hours, the platform will reject it with code 1018 again. Handle the late invoice per the Authority’s guidelines for late invoices, then fix the source that delayed it so it does not recur.

Why does code 1018 appear suddenly on a large number of invoices?
Usually because of batching. When a daily batch fails or is delayed, all its old invoices fall outside the window together, so the code appears in large numbers all at once rather than one at a time.

How do I tell a real delay apart from clock drift?
Compare issueDateTime and receivedDateTime in the rejection response. A delay of a few minutes over the limit on invoices that were sent quickly points to clock drift or a time zone. A delay of hours points to a stuck queue or a late batch.

Does Qoyod spare me from dealing with code 1018?
Qoyod sends every simplified invoice the moment it is issued in a unified time, so the difference stays within minutes and stays far from the twenty-four-hour limit. It remains for you to register the CSID compliance identifier with the Authority once at the start, and Qoyod guides you through it.