Every e-invoice carries a set of technical identifiers with one job: to make each document uniquely identifiable, so that it can never be confused with another. Yet repeated identifiers are among the common mistakes the Zakat, Tax and Customs Authority has pointed to, asking taxpayers to make sure invoice reference numbers and unique identifiers are never repeated. Repetition is rarely an employee's mistake; it is usually the result of how systems are run.
The identifiers that must never repeat
| Identifier | What it is | Where it must be unique |
|---|---|---|
| Invoice number | The readable number the customer sees | Within the seller's invoice series |
| Universally unique identifier (UUID) | A random alphanumeric string | Globally: no other document anywhere has it |
| Invoice counter (ICV) | An incrementing counter | Within one invoicing unit: every document consumes a value |
| Invoice hash | The document's fingerprint | Derived from its content, carried into the next invoice |
| Previous invoice hash (PIH) | The fingerprint of the document before it | Links the documents into one chain |
The e-invoice's XML structure explains how these work together. What matters here is that the counter and the hash form a chain: if a value repeats or the chain forks, it shows immediately to anyone who checks it.
How does repetition happen?
Restoring a device from a backup
A point-of-sale device fails and is restored from last week's backup. The counter and the invoice number go back to their values in that backup, so the next invoices are issued with numbers and counter values already used, and a previous hash that does not match the last real document.
Copying an invoicing unit onto more than one device
A new device is set up from a copy of an existing one, with its certificate and counter. You now have two devices issuing under the same identity from the same counter, so values repeat and the chain forks. Every device or program that issues invoices needs its own registration and certificate.
Several tills on one counter without a lock
Two tills read the counter at the same moment, each adds one and issues. The result is two invoices with the same value. Allocation has to happen in one protected operation that two parties cannot enter at once.
A retry that creates a new document
The connection drops after sending, and the system creates the invoice again instead of resending the same document. Two documents come out of one sale, or a new document with a number already used. A safe retry sends the same document, with a key that prevents a second copy — see handling invoices when ZATCA is down.
Renumbering on a new provider or a new year
A new system starts the series at 1, or yearly numbering restarts without a prefix that tells the years apart. Old numbers reappear. A provider migration plan has to settle where the series continues from.
What if an identifier has already repeated?
A sealed document is not edited or deleted — cancelling by deletion is not an option. First establish the scope: which device, since when, how many documents. Then stop issuing from the repeating source until it is fixed, correct the tax effect with the lawful tools — credit and debit notes — and document what happened in your records. An invoice the Authority rejected is corrected by a new document with a new counter value, as in correcting a rejected invoice.
A prevention checklist
- Every device or program that issues invoices has its own registration, certificate and counter.
- The invoice number and counter value are allocated together, in one protected operation, as the document is saved.
- A uniqueness constraint on the number in the database, not application logic alone.
- No device restored from a backup before matching the last counter value and hash submitted.
- A retry resends the same document with an idempotency key, never a new document.
- The numbering series continues across years and system changes.
How this looks in alFatora
In the alFatora app and alFatora Connect, repetition is prevented by construction, not by a warning:
- The invoice number, counter value and previous invoice hash are allocated together under a lock, in the same transaction that saves the document, so no two documents get the same value.
- A fresh unique identifier for every document, created when it is created and never reused.
- An invoicing unit with its own certificate, and the API unit separate from the app's, so they never share a counter.
- A mandatory idempotency key on the API: resending with the same key returns the first result and never creates a second document.
Frequently asked questions
Which identifiers must never repeat on an e-invoice?
The invoice number within the seller’s series, the universally unique identifier (UUID), the invoice counter value (ICV) within the invoicing unit, and the invoice hash that links each document to the one before it.
Why do invoice numbers repeat after a point-of-sale device is restored?
Because the backup takes the counter and the invoice number back to their values at backup time, so the next invoices reuse values. Match the last value submitted before issuing again.
Can two devices share one certificate and counter?
No. Every device or program that issues invoices needs its own registration, certificate and counter, or values repeat and the hash chain forks.
Was this useful? Review alFatora on Google.
