Error Code 1004: Invalid ICV Invoice Counter Sequence

When you send your electronic invoice to the Fatoora platform of the Zakat, Tax and Customs Authority, the system may respond with a rejection message carrying the code 1004 with a description indicating that the invoice counter (ICV) sequence is invalid. This code does not mean your accounting system has broken down; it means the sequential number that accompanied your invoice did not arrive in its expected position. The invoice counter must increase by exactly one with every invoice on the same device. Any jump in the number, any repeat of a previous number, or any return to a smaller number breaks the sequence and the platform rejects the invoice.

In this guide we focus on this single error. We will explain what the ICV invoice counter is and why it must be sequenced precisely, why the Authority rejects the invoice when the sequence is disrupted, how to identify the exact cause in minutes, how to fix it step by step, and how to prevent it from recurring. The goal is for you to leave this page with your invoice accepted and your counter sequence intact, not to collect general information.

What does “invalid ICV invoice counter sequence” mean?

The invoice counter, known by the abbreviation ICV from the English phrase Invoice Counter Value, is a sequential number that starts at 1 and increases by one with every new invoice issued by the device or issuing unit. The first invoice carries counter 1, the second 2, the third 3, and so on without interruption. This number is embedded inside the invoice file and enters into the digital signature calculation, so the Fatoora platform verifies its sequence before approving the invoice.

When the platform finds that the counter did not arrive in its expected position — that is, it did not equal the previous invoice value plus one — it responds with code 1004 and rejects the invoice. The rejection here occurs at the sequence-integrity validation level, meaning the invoice reached the Authority but did not pass the counter-sequence check. This is why this error is classified among the validation errors that the platform checks before approval, and it is part of the broader set of Zakat, Tax and Customs Authority e-invoicing errors you may encounter during integration.

An important distinction here: the ICV counter differs from the unique identifier UUID. The counter is a consecutive sequential number set locally by the issuing unit, whereas the unique identifier is a non-repeating unique string for each invoice. Both are mandatory fields, but the counter alone is the one subject to the increase-by-one rule. Our focus on this page is on the ICV invoice counter only.

Why the Authority tied the counter to the invoice series

The sequencing rule is not a pointless technical complication. Its purpose is to ensure there are no deleted, hidden, or later-inserted invoices outside the sequence. When the counter always increases by one, it becomes easy to confirm that the invoice series is complete and no invoice was deleted from the middle. If the counter jumped from 50 to 52, it raises a legitimate question: where is invoice number 51?

This is why the counter is linked to another mechanism, the Previous Invoice Hash (PIH), where each signature carries the fingerprint of the invoice before it. The counter and the hash together create an interlinked chain whose order cannot be tampered with. For a deeper look at the interlinking between fields, see the guide on hash errors.

How the counter sequences correctly

The core rule is simple and settled. Each invoice’s counter equals the previous invoice’s counter plus one, at the level of the same device or issuing unit. Elements of the rule:

• The counter starts at 1 for the first invoice on the device.
• Each subsequent invoice takes the previous counter + 1.
• The counter is never repeated for two invoices on the same device.
• The counter never jumps over a number and never returns to a smaller number.
• Each device or issuing unit keeps its own counter independent of the other devices.

The last point is essential. If you have three branches, each with an issuing device, then each device has its own counter that starts at 1 and runs independently of the other two. Mixing counters across devices, or trying to make them sequential across the whole establishment, is one of the most common causes of code 1004.

The sequencing rule applies to both invoice types together. The tax invoice in B2B invoicing, which is subject to immediate clearance, and the simplified tax invoice aimed at the consumer, which is reported within 24 hours — both consume a number from the same counter on a single device. That is, the counter does not distinguish between the two types; it counts every invoice issued by the device in order, regardless of type. This means issuing a simplified invoice between two B2B invoices takes up a number in the sequence, so do not expect the counter to skip one type over another.

It is also useful to know that the counter is a local value managed by the issuing unit on your device, not a value the platform grants you. In other words, responsibility for its correct sequencing lies with the system that issues the invoice, while the platform merely verifies it and rejects anything that breaks the rule. This is why choosing a system that sets the counter automatically is the first line of defense against this error.

Counter progression, visualized

Common errors in counter progression

Most cases of code 1004 do not arise from a system failure, but from an action that disrupted the counter progression. The most prominent of these errors:

• Running the system on a second device with the same setup: copying the issuing environment to another device creates two separate counters issuing conflicting numbers for the same entity.
• Restoring an old backup: reverting to an earlier copy resets the counter to a number smaller than the invoices have actually reached.
• Deleting an invoice from the series: removing an invoice from the middle of the sequence leaves a gap in the counter progression.
• Issuing invoices in parallel from two sessions: opening the system in two windows or on two devices at the same time can produce two identical counters.
• Manually resetting the counter: zeroing or manually editing the counter at the start of a new accounting period breaks the progression the platform expects.

Why does the Authority reject the invoice with this code?

Rejection with code 1004 happens for one of three main reasons. Identifying the reason that applies to your case is essential, because the fix differs between them:

First reason: a jump in the counter

The counter skipped a number, so its value came out greater than the previous invoice value plus one. Example: the previous invoice carried counter 50, and the new invoice carried 52 instead of 51. The platform expects 51, so it rejects 52. This often happens when an invoice that would have taken the missing number was deleted, or when there is a fault in number generation.

Second reason: a repeated counter

The counter equaled the value of an earlier invoice on the same device. Example: two invoices carrying counter 30. This happens when the system runs in two parallel environments, or when two invoices are issued at the same instant from two separate sessions. The platform sees a number already used, so it rejects the second invoice.

Third reason: the counter going backward

The counter returned to a number smaller than the series had actually reached. Example: the series reached 80, then an invoice was issued with counter 60. The most common cause is restoring an old backup, or manually resetting the counter. The platform has already recorded higher numbers, so it rejects the smaller number because it breaks the direction of the progression.

Sequence-break paths

How to identify the exact cause

Before you correct anything, identify the path you fell into so you do not treat the symptom without the root cause. Follow these steps in order:

1. Read the full rejection message: code 1004 comes with a text description stating the expected value and the value that arrived. Compare them to know whether the counter jumped, repeated, or went back.
2. Review the counter of the last approved invoice: find the number the series actually reached on this device, as it is the reference on which the next invoice must build.
3. Check the number of issuing devices: if you have more than one device or branch, make sure each device keeps its own independent counter and the counters have not been mixed.
4. Review the last operation on the system: did you restore a backup? did you delete an invoice? did you copy the issuing environment to a new device? the last change is often the cause of the break.
5. Make sure there are no parallel sessions: close any issuing window or session open on another device that issues invoices at the same time.

Reading the text description of the message is the fastest route to a diagnosis. A description stating “expected value 51 and received value 52” points you to a jump, while a description referring to a previously used counter points you to a repeat, and a description stating a value smaller than the recorded one points you to a step back.

If you want a diagnosis in under two minutes, start with one question: did anything unusual happen before the error appeared? A restored backup, a new device, or a deleted invoice. These three events explain most cases of code 1004. But if none of them happened and the error appeared suddenly, examine the possibility of two parallel sessions issuing at the same time.

The step-by-step fix

After identifying the path, apply the appropriate fix. Here we present the three paths.

If the counter jumped

1. Check whether an invoice that would have taken the missing number was deleted. Approved invoices are not deleted from the series.
2. Do not try to insert the missing number manually, because the platform expects the sequence to continue from the last number you actually recorded.
3. Issue the next invoice so that its counter equals the counter of the last approved invoice plus one, and send it to the Fatoora platform.

If the counter repeated

1. Stop issuing from any parallel device or session, and keep a single active issuing source per device.
2. Make sure each device keeps its own independent counter, and do not copy the issuing environment from one device to another.
3. Issue the next invoice with a counter not previously used on this device, which is the last approved counter plus one.

If the counter went backward

1. If you have restored an old backup, reset the counter to the number the series actually reached before the restore, not to the number in the old copy.
2. Do not manually reset the counter to a smaller number, even at the start of a new accounting period; the sequence is not zeroed when the year changes.
3. Continue issuing from the last approved number plus one, and send the invoice to the platform.

In the vast majority of cases the matter is resolved by continuing to issue from the last approved number plus one, without any manual intervention in the counter itself.

A practical example from a real case

Let us take a common case. An establishment was issuing its invoices from a main device, and its counter had reached 240. The device suffered a malfunction, so it restored a backup from the previous day, in which the counter had only reached 228. It continued issuing, so the first new invoice carried counter 229. The platform responded with code 1004 because the counter had gone back to a number smaller than the 240 it had actually recorded.

On diagnosis, the accountant reviewed the last approved invoice on the platform and found it at counter 240. He realized the backup had set the counter backward. He adjusted the issuing start to be from 241, that is, the last approved number plus one, then issued the invoice and sent it, and it was approved immediately. The lesson here: after any backup restore, match the counter to the last invoice actually approved, not to the number in the old copy.

Another, less common case: an establishment with two branches copied the issuing setup from its first branch to the second to speed up configuration. The two branches ended up with a counter of the same value, so when an invoice was issued from the second branch with counter 15, code 1004 appeared because the same number had been used in the first branch. The fix was to separate the issuing environment for each branch so that each device keeps its own independent counter, after which the invoices went through without rejection.

An example error message

When the invoice is rejected, the Fatoora platform returns a structured response containing the error code, its description, and the location of the problem. Below is an illustrative example of the response shape for code 1004, showing the expected value and the value that arrived:

{
  "validationResults": {
    "status": "ERROR",
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1004",
        "category": "INVOICE_COUNTER_VALUE",
        "message": "Invalid ICV sequence: expected 51 but received 52.",
        "field": "Invoice/AdditionalDocumentReference[ID='ICV']/UUID"
      }
    ]
  }
}

Read the following fields for a quick diagnosis: the value of code equals 1004, andcategory refers to the invoice counter, andmessage states the expected value 51 versus the received value 52, confirming that the path was a jump in the counter. The field field specifies the counter’s location inside the invoice file.

A sound counter versus a rejected counter

How to prevent the error from recurring

Correcting a single invoice is easy, but permanent prevention saves you from repeating the problem with every batch of invoices. Follow these practices:

• Leave counter management to the system: never edit the counter manually, and let the issuing unit handle increasing it by one automatically.
• Separate each device’s counter: give each branch or device an independent issuing environment with its own counter, and do not copy the setup between devices.
• Handle backups with care: after any restore, match the counter to the last invoice actually approved before issuing a new invoice.
• Do not delete approved invoices: a wrong invoice is handled with a credit note, not by deletion, because deletion breaks the progression.
• Avoid parallel sessions: do not issue invoices from two devices or two windows at the same time on the same issuing unit.

Establishments that rely on an accounting system that manages the counter and its sequence automatically rarely face this error, because the system sets the number before sending it to the platform and leaves no room for manual intervention.

Extra precautions when migrating or upgrading the system

If you are moving from one system to another or transferring the issuing environment to a new device, this moment is the most exposed to code 1004. Any error in transferring the counter value results in a jump or a step back on the very first invoice. To avoid this, record the counter value on the old device before the transfer, and make sure the new device continues from the same value plus one.

Likewise, issue a single test invoice after any transfer or upgrade, and confirm it is approved before issuing a real batch of invoices. A single test invoice reveals a counter-sequence error immediately, and saves you from having dozens of invoices rejected all at once. This is a simple step, but it prevents the most troublesome cases of code 1004.

The difference between the ICV counter and the UUID unique identifier

Some users confuse the invoice counter with the unique identifier because both are mandatory fields that identify the invoice, but the difference between them is fundamental:

• The ICV counter: a consecutive sequential number that starts at 1 and increases by one at the device level, whose purpose is to prove the completeness of the invoice series. Its disruption produces code 1004.
• The UUID unique identifier: a non-repeating unique string generated for each invoice, whose purpose is to distinguish the invoice from others with no relation to the sequence. Its disruption produces a different code.

The simplified rule: the counter answers the question “what is the order of this invoice?”, while the unique identifier answers the question “what is its individual identity?”. For details on the unique identifier, see the guide on UUID unique identifier errors.

Where this error sits among e-invoicing errors

Code 1004 is not the only error you may face. It is classified among the data validation errors, a group in which the platform checks the integrity of the invoice content before approval. To understand the full picture, see the guide on Zakat, Tax and Customs Authority e-invoicing errors, and the guide on the ICV invoice counter which explains the counter mechanism in detail, in addition to the guide on validation errors.

To learn how to issue compliant invoices from the start, visit the Qoyod electronic invoicing.

Why you should not ignore this error

Code 1004 may seem like a minor technical problem, but its practical impact is greater than some think. A rejected invoice is not an approved invoice, and this means you have not issued a formal document to the customer. More seriously, a counter disruption is not an error in a single invoice, but in the progression of the whole series. Unless you fix the progression, the rejection will repeat with every subsequent invoice.

In the longer term, the accumulation of invoices rejected because of the counter confuses your records and makes it harder to reconcile sales with tax returns. Every stuck invoice is revenue not yet formally documented. And because the counter is a consecutive mechanism, ignoring its break today means the gap widens tomorrow. That is why it is best to address it as soon as it appears; resetting the progression takes minutes, while delay accumulates a problem that grows with every invoice.

The practical takeaway: identify the last number actually approved, continue from it plus one, and leave counter management to the system without manual intervention. With these three steps you close the door on code 1004 for good.

Frequently asked questions

What does code 1004 mean in e-invoicing?

It means the invoice counter (ICV) sequence is invalid. The counter is a sequential number that must increase by one with every invoice on the same device. If it jumps over a number, repeats, or goes back to a smaller number, the platform responds with code 1004 and rejects the invoice before approving it.

How should the invoice counter be sequenced?

The counter starts at 1 for the first invoice on the device, then each subsequent invoice takes the previous counter value plus one, with no repeat, jump, or step back. Each issuing device keeps its own counter independent of the other devices.

Code 1004 appeared after restoring a backup — what do I do?

The restore most likely reset the counter to a number smaller than the series had actually reached. Review the last approved invoice on the platform, set the issuing start from its number plus one — not from the number in the old copy — then reissue the invoice.

I have more than one branch, how do I avoid a repeated counter?

Give each branch or issuing device an independent environment with its own counter, and do not copy the issuing setup from one device to another. A repeated counter between two branches is one of the most common causes of code 1004 in multi-branch establishments.

Is the ICV counter the same as the UUID unique identifier?

No. The counter is a consecutive sequential number that proves the invoice’s order within the series, while the unique identifier is a non-repeating unique string that distinguishes the invoice from others. The counter alone is subject to the increase-by-one rule.

Does it resolve the records of this error automatically?

It manages the invoice counter records and their sequence automatically for each issuing device, and signs every invoice with a Compliance Stamp Identifier (CSID) certificate approved by the Authority, which reduces the likelihood of this error occurring in the first place. Even so, avoiding manual intervention in the counter, and not deleting approved invoices, remains the user’s responsibility.