Reporting Errors in E-Invoicing: Causes and Fixes

“Reporting Errors” are the problems that appear on the simplified tax invoice (B2C) path after it is issued, when your system sends its copy to the Fatoora platform within the mandatory 24-hour window. This practical guide breaks down every common error on this path: the symptom you see, its root cause, and the step-by-step fix. This guide sits within the E-Invoicing Errors Center, and it is the sibling of the Clearance errors guide for business invoices (B2B) within the same Errors Center .

If you first need to understand the reporting mechanism itself before diving into its errors, start with theReporting guide which explains the flow from its roots, or review the Reporting API reference if you are looking into the technical side of direct integration with the Fatoora platform.

Why do reporting errors differ from clearance errors?

Before we tackle the errors, you need to know where you stand on the map. The simplified tax invoice (B2C) follows the “Reporting” path: you issue it and hand it to the customer immediately, then your system sends it to the Zakat, Tax and Customs Authority (ZATCA) later, within 24 hours. The full tax invoice (B2B) follows the “Clearance” path: it waits for the Authority’s prior approval before it reaches the buyer.

This difference changes the nature of the error and when it appears. In clearance, the error stops the invoice before it reaches the buyer, so you know about the problem instantly. In reporting, the invoice has already been handed to the customer and entered your books, then the error appears at the later submission. That is why reporting errors are more dangerous in one respect: you may discover them late, after the 24-hour window has passed.

The following table places the two paths side by side so you can be sure you are reading the right guide:

How does reporting work technically, so you understand where it breaks?

Every error on this path is, at its core, a fault at one station of a fixed flow. Once you understand the flow, diagnosing the error becomes a matter of pinpointing the station that stopped. The flow moves through the following steps:

1. You issue the invoice from your system and hand it to the customer at the moment of sale.
2. The system generates the technical elements: the cryptographic stamp, the unique identifier (UUID), the hash value linked to the previous invoice, and the Quick Response (QR) code.
3. The system builds the XML file per the UBL 2.1 specification and sets the Clearance Status field to 0 because it is a reported, not cleared, invoice.
4. The system sends the invoice to the Fatoora platform through the Reporting API within the 24-hour window.
5. The Authority responds with one of three states: Accepted, Accepted with notes (Warning), or Rejected (Error).

Any error you see falls in the second, third, fourth, or fifth step. The following sections address each symptom on its own, in order of how common it is in practice.

Symptoms table: from the symptom to the right section

Before you read each section, use this table to jump straight to the error that matches what you see. Each symptom has a likely cause and a section that addresses it:

We address each error with three fixed points: the symptom as it appears to you, the root cause behind it, and the step-by-step fix. This structure makes the guide a reference you return to at every problem, not a one-time read you forget.

Error One: Reporting after the 24-hour window (late reporting)

This is the most common reporting error and the least obvious, because it does not block the sale at the moment it happens.

Symptom: The invoice was issued and handed to the customer successfully, but its submission to the Fatoora platform did not happen within 24 hours of the issuance time. On late submission, the Authority may accept it while recording a violation, and you may see a note that the invoice arrived outside the mandatory window. The real risk is not in a single invoice, but in the accumulation of unsent invoices when the connection drops or automatic submission fails.

Root cause: Three main causes. The first is a loss of connection to the internet or to the Fatoora platform for a prolonged period without anyone noticing. The second is the business relying on scheduled manual submission instead of instant automatic submission after each invoice. The third is invoices stuck in the submission queue due to an earlier technical error that kept them from leaving, so they accumulated until they exceeded the window.

Fix:

1. Enable instant automatic submission so that every invoice leaves the moment it is issued, not in a scheduled batch at the end of the day.
2. Monitor the submission queue daily. Any invoice pending for more than two hours is an early warning before it approaches the 24-hour limit.
3. On a long outage, be sure to re-submit the accumulated invoices as soon as the connection returns, and review their sequence.
4. Send the late invoice immediately, even after the window has passed. Late submission is better than no submission, because the data reaches the Authority and reduces the impact of the violation.

The Qoyod e-invoicing software handles this submission automatically the moment each invoice is issued, and retries automatically when the connection returns, so the risk of occasional delay disappears at its root.

Error Two: Reporting rejection (ERROR state)

Here the Authority responds with an outright rejection, so the invoice remains unreported even though it was handed to the customer.

Symptom: The system sends the invoice and it comes back with the status code ERROR accompanied by a message explaining the reason for rejection. The invoice in this case is not in the Authority’s records, and it needs correction and re-submission. Rejection differs from “Accepted with notes” (Warning), where the Authority accepts the invoice but alerts you to a minor shortcoming.

Root cause: Usually an error in the XML file structure or in a mandatory field. The most prominent causes: an incorrect or missing tax registration number, a discrepancy in VAT calculation between the invoice line items and the total, a hash value that does not match the previous invoice in the chain, or an expired cryptographic stamp linked to a cryptographic stamp identifier (CSID) that was not renewed.

Fix:

1. Read the error message received from the Authority carefully. It identifies the field or rule that was broken, and it is always the correct starting point.
2. Check the mandatory fields: the tax registration number, the seller name, the date and time, the invoice line items, the tax amount, and the total.
3. Review the consistency of the tax calculation. Make sure the sum of the line items’ tax exactly equals the tax amount in the total.
4. Make sure the cryptographic stamp is valid, and that the cryptographic stamp identifier (CSID) is registered and not expired.
5. Correct the cause, then re-submit. Do not issue a new replacement invoice unless the situation requires a credit note to cancel the original.

The most frequent rejection messages deserve a pause, because knowing them in advance saves you a full diagnostic cycle. The most prominent are four. The first is rejection due to a tax registration number that does not match the Authority’s format of fifteen digits starting and ending with a specific digit. The second is rejection due to the sum of the line items’ tax not matching the tax amount in the total, which is the most common and arises from inconsistent decimal rounding. The third is rejection due to a hash value that does not connect to the previous invoice, which breaks the invoice chain. The fourth is rejection due to a Quick Response (QR) code that is missing or does not carry the five mandatory fields.

Each of these four has a direct remedy. Correcting the tax number format, unifying the decimal rounding rule across line items, fixing the hash sequence by re-linking the invoice to its correct predecessor, and completing the Quick Response code fields. An approved accounting system generates these elements correctly from the start, so you rarely reach the rejection stage.

The difference between the status value in the Authority’s response determines the type of intervention you need. The table clarifies the three states:

Error Three: Duplicate reporting of the same invoice

A single invoice may appear twice in the reporting log, an error that confuses reconciliation later.

Symptom: The same invoice was reported more than once, or the system tried to send it again and it came back with a message indicating that the unique identifier (UUID) already exists. In some cases the invoice appears twice in your internal reports while the Authority keeps a single copy.

Root cause: Usually a manual re-submission attempt after an outage, so the system sent the invoice a first time before the outage and then sent it manually after it returned. Another cause is a duplicate import of invoices from a point of sale or an external file, or a wrong automatic-retry setting that fires the submission twice.

Fix:

1. Do not re-submit manually before confirming the status of the first submission. Search for the unique identifier (UUID) in the reporting log first.
2. Rely on the unique identifier for each invoice as the single key that prevents duplication. A single invoice carries one UUID that does not change no matter how many times you retry.
3. Review the point-of-sale import integration so the invoice file is not loaded twice.
4. Configure the automatic-retry policy so that it verifies the success of the previous submission before firing a new attempt.

The invoice’s unique identifier is the first line of defense against duplication. When your system respects this identifier, re-submission becomes safe because it does not create a second record.

Error Four: Wrong Clearance Status value (1 instead of 0)

This is a classification error that puts the invoice on the wrong path from the outset.

Symptom: Submission is rejected or comes back with an inconsistency message, because the simplified invoice (B2C) had its Clearance Status field set to the value 1 (cleared) instead of the correct value 0 (reported). The simplified invoice does not pass through clearance, so it is not valid to mark it as cleared.

Root cause: An error in setting the invoice type inside the system, or an invoice template inherited from a B2B setup applied to a B2C transaction. Sometimes it happens when the settings of a branch that issues full invoices are copied to a branch that sells to individuals without adjusting the invoice type.

Fix:

1. Make sure the invoice type in the system is set to “simplified tax invoice” for transactions directed at the final consumer.
2. Verify that the Clearance Status field carries the value 0 for every simplified invoice, and the value 1 for full invoices only.
3. Review the invoice templates copied between branches, and make sure each template carries the correct invoice type for the branch’s activity.
4. After correction, re-issue the invoice with the correct type if needed, then report it on the reporting path.

Error Five: Reporting a B2B invoice by mistake

This is the mirror of the previous error: a full invoice took the reporting path instead of clearance.

Symptom: A full tax invoice directed at a business (B2B) was sent on the reporting path instead of clearance. The result is that the invoice reached the buyer without prior clearance, which is a violation because the full invoice requires the Authority’s approval before delivery. The system may respond with an inconsistency message, or you may discover the error later when reviewing invoices.

Root cause: A wrong classification of the customer in the system, so the business customer was treated as if it were an individual consumer. Another cause is the absence of the buyer’s tax registration number in the invoice data, so the system did not recognize it as a B2B invoice that requires clearance.

Fix:

1. Classify the customer accurately. A customer that has a tax registration number and requests a full invoice is a B2B transaction that follows clearance.
2. Make the buyer’s tax registration number a pivotal field. Its presence routes the invoice to clearance, and its absence routes it to reporting.
3. When you discover a full invoice reported by mistake, address the situation per the Authority’s guidance, usually by issuing a credit note and re-issuing on the correct path.
4. Review the E-Invoicing Errors Center to understand the correct clearance path for these invoices in detail.

How is the 24-hour window calculated precisely?

Most late-submission errors arise from a misunderstanding of when the count begins. The window does not start from the end of the day, nor from the time the invoice is recorded in your books, but from the moment the invoice is issued and handed to the customer. This moment is the timestamp fixed inside the invoice itself, and the Authority measures the delay from it, not from any other time.

This detail matters in practice. A business that issues an invoice at 11 p.m. thinks it has a full day ahead, while the deadline ends at 11 p.m. the following day. If it relies on a scheduled submission that runs at noon, it may send yesterday’s late invoice after its window has passed. That is why instant submission after each issuance is the only guarantee against falling into delay.

There is another common confusion. Some businesses think that late reporting cancels or voids the invoice. This is not true. The simplified invoice is valid as soon as it is issued and handed to the customer, and reporting is a separate later obligation. A delay records a violation against the business, but it does not touch the validity of the sale itself. Nevertheless, the accumulation of violations exposes the business to the Authority’s penalties, so the goal is zero delay, not merely reducing it.

The practical rule: every simplified invoice must leave your system within minutes of its issuance, not hours. When you rely on instant automatic submission, the 24-hour window becomes a wide safety margin, not a limit you race against daily.

Correcting a simplified invoice after reporting: the credit note

A frequently recurring question: what if you discover an error in a simplified invoice after it has been reported and accepted? The answer is that you do not edit the reported invoice and do not delete it; instead, you issue a corrective document linked to it.

If the correction reduces the amount (a discount, a return, a quantity reduction), you issue a credit note that references the original invoice by its unique identifier. And if it increases the amount, you issue a debit note. Both notes are subject to the same reporting path, and are sent to the Authority within a 24-hour window from their issuance.

The common error here is that some businesses try to re-issue the original invoice with a modified value, creating a conflict with the previously reported copy. The correct route is always the credit or debit note linked to the original, because it keeps the hash chain intact and documents the correction before the Authority.

When issuing the note, make sure of two things: that it carries a correct reference to the original invoice’s identifier, and that it carries the reason for the correction. The absence of the reference to the original is one of the most common causes of note-reporting rejection, because the Authority cannot link the correction to its invoice.

Best practices to prevent reporting errors at their root

Dealing with an error after it occurs is costly. It is better to build your processes so that the error does not occur at all. The following practices cover most of what we discussed:

1. Adopt instant automatic submission. Every invoice leaves the moment it is issued, so it does not accumulate and does not approach the window limit.
2. Monitor the submission queue daily. A dashboard showing pending invoices reveals any outage before it turns into a mass delay.
3. Set the type of each invoice at issuance. Simplified for individuals with a Clearance Status of zero, full for businesses on the clearance path.
4. Link the customer classification to their tax registration number. Its presence routes the invoice to clearance, and its absence routes it to reporting, so the two paths do not mix.
5. Renew the cryptographic stamp identifier (CSID) before it expires. An expired stamp stops all reporting, not a single invoice.
6. Review tax consistency automatically. A system that matches the sum of the line items’ tax with the total before submission prevents the most common cause of rejection.

These practices turn from an exhausting manual checklist into default behavior when an approved accounting system manages them. A good system does not wait for you to remember the rule; it applies it automatically and blocks the incomplete invoice before it leaves.

What does an actual reporting error message look like?

When reporting is rejected, the Fatoora platform responds with a structured response that identifies the reason for rejection. Understanding the structure of this response shortens the diagnosis time. The following example shows the shape of a typical rejection response for an error in tax calculation:

{
  "validationResults": {
    "status": "ERROR",
    "reportingStatus": "NOT_REPORTED",
    "clearanceStatus": 0,
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "BR-KSA-EN16931-08",
        "category": "EN_16931",
        "message": "Invoice total VAT amount does not equal the sum of line VAT amounts"
      }
    ],
    "warningMessages": []
  },
  "invoiceHash": "NWZlY2ViNjZmZmM4NmYz...",
  "uuid": "3cf5ee18-ee25-44ea-a444-2c37ba7f28be"
}

Read this response from three angles. First, the field status and its value ERROR confirms that the invoice was rejected and not reported (reportingStatus: NOT_REPORTEDand its value 0 confirms that it is a simplified invoice on the correct reporting path, so the problem is not in the classification. Third, the block clearanceStatus ). Second, the field errorMessages identifies the cause precisely: the sum of the line items’ tax does not equal the tax amount in the total. This directs you straight to reviewing the tax calculation before re-submission.

Note the presence of uuid andinvoiceHash in the response. These two elements link the invoice to its chain, and prove that the unique identifier is correct, so the error is confined to the tax calculation, not to the chain structure.

A quick checklist before every reporting

Most reporting errors are prevented by a careful review before submission. Review the following points on every simplified invoice:

• The invoice type is set to “simplified tax” and the Clearance Status field carries the value 0.
• The seller’s tax registration number is correct and complete.
• The sum of the line items’ tax exactly equals the tax amount in the total.
• The cryptographic stamp is valid and the cryptographic stamp identifier (CSID) is not expired.
• The hash value matches the previous invoice in the chain.
• Submission takes place within the 24-hour window from the moment of issuance, automatically not manually.

When your accounting system handles this checklist automatically, reporting turns from a daily source of worry into a silent process running in the background. This is where the difference of relying on an approved software that manages the full cycle on your behalf appears.

Frequently asked questions about reporting errors

Is the invoice canceled if its reporting is delayed? No. The simplified invoice is valid as soon as it is issued and handed to the customer. The delay records a violation against the business, but it does not void the sale. Send the late invoice immediately, even after the window has passed, to reduce the impact.

What if the Authority accepts the invoice with a Warning state? The invoice was reported and entered the Authority’s record. The note is an alert to a minor shortcoming that does not prevent acceptance. Address the cause of the note in upcoming invoices so it does not turn into a rejection later.

Should I issue a new invoice when reporting is rejected? Usually no. Correct the cause of the rejection in the invoice itself and re-submit it with the same unique identifier. A new invoice is required only when the situation calls for a credit note to cancel the original.

How do I quickly distinguish a reporting invoice from a clearance invoice? Look at the Clearance Status field. The value 0 means a simplified invoice on the reporting path, and the value 1 means a full invoice on the clearance path. The presence of a tax registration number for the buyer is another indicator that it is a B2B transaction.

When should you turn to support?

Some reporting cases go beyond self-correction. Turn to support in the following cases: repeated rejection of the invoice despite correcting all fields, or a cryptographic stamp identifier (CSID) error that is not resolved by re-linking, or the accumulation of a large number of unsent invoices after a long outage that need organized re-submission.

Qoyod provides technical support around the clock, seven days a week, helping you diagnose the error message and reset submission. Do not leave a rejected invoice pending, because every day that passes brings it closer to exceeding the mandatory window.