Cryptographic Stamp and Hash Chain: Why an Invoice Can't Be Edited After It's Issued
The cryptographic stamp and hash chain make an invoice impossible to edit after issue. A plain explanation of how they work, why the chain breaks, and how to avoid it.
سامي الحيدري
The cryptographic stamp and hash chain turned the invoice from a document anyone could edit into a record that cannot be tampered with. Understanding them is not a technical luxury: most rejection errors in Phase 2 e-invoicing trace back to them, and most wrong fixes make those errors worse.
The idea in one sentence: every invoice carries a fingerprint of its own content, the fingerprint of the invoice before it, and a digital signature from a device registered in your name.
What is hashing, and why are invoices linked to each other?
A hash is a mathematical fingerprint calculated from the invoice's content. Any change, even a single halala, produces a completely different fingerprint, and there is no way to work back from the fingerprint to the content.
The clever part of the design is that each invoice also carries the fingerprint of the previous invoice. This forms a chain: invoice 100 carries the fingerprint of 99, 99 carries the fingerprint of 98, and so on back to the start.
The practical result: you cannot delete an invoice from the middle, insert one retroactively, or change an old amount. Any attempt breaks the chain from the point of change to the end, and it shows up immediately.
What is the cryptographic stamp?
The hash proves the content has not changed, but it does not prove who issued it. That is where the stamp comes in.
Inside your issuing unit (the device or system registered to issue your invoices) sits a private key that never leaves it. The system uses this key to sign the invoice's fingerprint, producing a signature that anyone can verify using the public key published in the QR code.
So the hash answers "Has the content changed?" and the stamp answers "Who issued this invoice?". Together, they make the invoice verifiable without going back to your system.
The cryptographic stamp and hash chain plus the counter: the third link
Alongside the fingerprint and the stamp, every issuing unit has an incrementing counter that is never reset or renumbered. Its job is to prevent another kind of tampering: deleting whole invoices from the end.
| Element | Answers | What it prevents |
|---|---|---|
| Hash | Has the content changed? | Editing amounts or line items |
| Previous invoice hash | Is the chain unbroken? | Deleting from the middle and backdated insertion |
| Counter | Is the numbering unbroken? | Deleting invoices from the end |
| Stamp | Who issued it? | Impersonating another issuing unit |
These four together are what make electronic books auditable without having to trust the seller.
Why does the chain break? Five causes
- Copying one device's settings to another. Both devices carry the same identity and increment the same counter, so the two chains collide.
- Restoring an old database backup. The system goes back to an old invoice and continues from there, so numbers are duplicated.
- Running test and production environments in parallel on the same data.
- Deleting an invoice row directly from the database to fix an apparent problem. This is the worst thing you can do.
- Reinstalling the system without restoring the key and certificate, so the issuing unit's identity is lost.
What they all have in common: manual intervention in something designed to be automatic.
What should you do if the chain breaks?
Do not try to "repair" it by editing the database. That doubles the problem and leaves a trace that is hard to explain later.
The right procedure:
- Stop issuing from that unit immediately so damaged invoices don't pile up.
- Document what happened: when it happened, which was the last valid invoice, and what took place just before it.
- Go back to your provider with information, not a request. Tell them "The chain broke after invoice X because of Y", not "Fix it".
- Correct the affected invoices with credit or debit notes, not by deleting them, and reissue them properly.
- Address the cause so it doesn't happen again: who has access to the database, and who restores backups?
A worked example: what does the auditor see?
Imagine a business deletes a large invoice from the database to hide it. What happens?
The next invoice still carries the fingerprint of the deleted invoice, but that invoice no longer exists. The unit's counter skips a number. And every later invoice is linked to a chain that starts from a missing link.
The auditor doesn't need to prove an invoice was deleted; it is enough that the chain doesn't connect. This is the fundamental difference between a paper ledger, where a page can be torn out without a trace, and an electronic record that carries the trace of every change made to it.
Likewise, if an invoice amount is edited in the database, the fingerprint calculated today will not match the fingerprint stored in the next invoice, nor the stamp sent to the platform at the time of issue.
How do you protect the chain from the start?
- Make each device an independent issuing unit with its own certificate, and copy nothing between devices.
- Block direct access to the invoice database for everyone, including your provider, except through a documented procedure.
- Take backups that include the certificate and the key, not just the data.
- Separate the test environment from production completely.
The technical specifications for the hash, the stamp and the counter, and how they are calculated, are published in the official guides from the Zakat, Tax and Customs Authority (ZATCA), which is the reference in case of any discrepancy.
Read also
- CSID compliance certificate: issuing and renewal
- The QR code on an invoice: what it contains
- Phase 2 e-invoicing: what integration means
Key takeaway: The hash, the previous-invoice hash, the counter and the stamp together make every issued invoice verifiable and tamper-evident. Never fix a broken chain by editing the database; stop, document, and correct with notes.
To see how SmartPro handles ZATCA (Fatoora) Phase 2 e-invoicing for your business, start a free trial or book a demo.
Frequently asked questions
What is the difference between the cryptographic stamp and the hash chain?
A hash is a mathematical fingerprint calculated from the invoice's content and proves it has not changed. The cryptographic stamp is a digital signature made with a private key inside the issuing unit, and it proves who issued the invoice. The hash answers "Has the content changed?" and the stamp answers "Who issued it?".
Why does every invoice carry the fingerprint of the previous invoice?
So that a linked chain is formed, preventing anyone from deleting an invoice from the middle, inserting one retroactively or changing an old amount. Any change breaks the chain from that point to the end and shows up immediately during an audit.
What breaks the hash chain?
Copying one device's settings to another, restoring an old database backup, running test and production environments on the same data, deleting an invoice row directly from the database, and reinstalling the system without restoring the key and certificate. All of them involve manual intervention in a process designed to be automatic.
What should I do if the chain breaks?
Stop issuing from that unit immediately, document the last valid invoice and what happened just before it, then go back to your provider with that information. Correct the affected invoices with credit or debit notes rather than deleting them. Do not try to repair the chain by editing the database, because that doubles the problem.