The Cryptographic Stamp in the E-Invoice: A Practical ZATCA Phase 2 Guide

When any Saudi business begins issuing invoices under Phase 2 of e-invoicing, one term keeps appearing on every invoice the system produces: the “cryptographic stamp.” This stamp is what separates an ordinary digital invoice from one that is legally approved by the Zakat, Tax and Customs Authority (ZATCA). Without it, the invoice remains just a file with no regulatory value, because the Authority does not recognize any document that lacks a valid cryptographic stamp.

In this guide we explain the cryptographic stamp exactly as the Authority requires it in Phase 2. We will see what this stamp is precisely, what it is made of, how your accounting system generates it using a CSID certificate, where it lives inside the invoice structure and in the QR code, and how the Authority verifies its validity. The goal is to leave you with a clear practical picture, not a general theoretical overview, because understanding the stamp helps you read any error message that appears while integrating with the Fatoora platform.

An important note before we begin. The cryptographic stamp is a different concept from the general notion of a digital signature in cryptography. The latter is a broad theory explaining how keys and certificates work in any system. The cryptographic stamp, by contrast, is the specific application of that theory inside a Phase 2 invoice, in a particular format mandated by the Authority. For the theoretical foundation of digital signatures and PKI keys, see our separate guide on the digital signature in the e-invoice. Here we focus on the stamp in its practical form inside the Saudi invoice.

What is the cryptographic stamp in the e-invoice?

The cryptographic stamp (Cryptographic Stamp) is a unique digital signature attached to every e-invoice in Phase 2. Its job is to prove two things at once: that the invoice was genuinely issued by the registered business and is not impersonated, and that its content has not changed by a single character since the moment it was issued. Any later change to the amount, the tax number, or the date breaks the stamp and makes it invalid.

The Authority requires this stamp for a fundamental reason: to move trust in the invoice away from paper and manual stamps toward cryptography. In the old paper system, a company stamp could be forged. The cryptographic stamp solves this problem because it is mathematically bound to the invoice content itself and to the business identity, so a valid stamp can only be produced by the system that holds the correct private key.

It is essential to distinguish between two terms that many accountants confuse. The “cryptographic stamp” is the signature itself that appears on the invoice, meaning the final result. The “cryptographic stamp identifier,” which we know as the CSID certificate, is the digital certificate from which this stamp is generated. The first is the fruit, the second is the tool that produces the fruit. This guide concerns the fruit, meaning the stamp itself, while the CSID guide explains the tool and how it is issued and renewed.

The cryptographic stamp is not just an ordinary signature

The cryptographic stamp may look identical to any digital signature you see in a signed PDF document. The difference is that the Authority imposes on this stamp a precise structure, specific fields, and particular algorithms. It is not enough to sign the invoice in any way; the stamp must be produced according to the UBL 2.1 specification adopted by the Authority, and it must be computed over specific parts of the invoice in a specific order.

This strict definition is what makes every business’s invoices automatically verifiable by the Authority. If each system were left to sign as it pleased, it would be impossible for the Fatoora platform to read and verify signatures in a uniform way. That is why the cryptographic stamp in the Saudi invoice is a standard, not merely a general idea of a signature.

Why did the Authority mandate the cryptographic stamp specifically?

A business owner might ask: why all this complexity? And why is a simple electronic stamp on the invoice not enough? The answer lies in the problems the Authority wanted to solve by moving to Phase 2.

The first problem is fictitious invoices. In the paper and early electronic systems, it was possible to create an invoice in the name of a business that had nothing to do with it, or to fabricate an invoice with no real transaction behind it. The cryptographic stamp blocks this, because producing a valid stamp requires holding the private key linked to the CSID certificate registered with the Authority. Whoever does not hold the certificate cannot produce an approved invoice.

The second problem is manipulating figures after issuance. Some parties could issue an invoice for one amount, then later amend it to reduce the tax due. The SHA-256 hash bound to the stamp makes any change immediately detectable, because the new hash will not match the signature.

The third problem is deleting invoices from the record to hide sales. The hash chain that links each invoice to the one before it means that deleting a single invoice breaks the entire chain sequence, so the gap shows up at the first audit. Through these three mechanisms, the cryptographic stamp turns from a technical procedure into a regulatory tool that protects public revenue and ensures fair competition among compliant businesses.

Components of the cryptographic stamp

The cryptographic stamp is not a single value, but a set of interconnected elements that combine to prove the invoice’s validity. Understanding these components helps you read the invoice content and understand why the Authority sometimes rejects it.

The invoice hash (Invoice Hash)

Before signing the invoice, the system computes a digital “fingerprint” of its content called the Hash. This fingerprint is a short string of characters produced by running the entire invoice through the SHA-256 algorithm. Any change in the invoice, even a single comma, produces a completely different fingerprint. That is why the fingerprint acts as a guardian of content integrity.

The digital signature on the hash

After computing the hash, the system signs it using the private key linked to the CSID certificate. This signature is the core of the stamp. Any party holding the public key can verify that the signature matches the hash, and that the hash matches the invoice content, completing the chain of trust.

The public key and the certificate

The public key and the CSID certificate are embedded inside the invoice so the recipient can verify it without needing to request the certificate from an external party. This way the invoice carries with it everything needed to verify it independently.

The signature timestamp

The stamp carries a timestamp that pinpoints the moment of signing precisely. This timestamp matters because it ties the invoice to the moment it was issued, and prevents reusing an old stamp on a new invoice.

The previous invoice hash (Previous Invoice Hash)

Here lies one of the Authority’s smartest mechanisms. Every invoice carries the hash of the invoice that preceded it, forming an interconnected chain like the links of a single chain. If someone tried to delete an invoice from the middle or alter it, the chain would break and the flaw would appear immediately at audit. This chain is known as the hash chain, and it ensures the invoice record is complete and sequential with no gaps.

How is the cryptographic stamp generated using the CSID?

Generating the stamp is a process that happens in fractions of a second inside your accounting system, but it goes through clear, logical steps. Understanding these steps makes any integration error understandable instead of a closed black box.

The process begins by issuing the invoice and preparing its structure in XML format according to the UBL 2.1 specification. The system then computes the SHA-256 hash of the invoice content. Next it calls the securely stored private key linked to the CSID certificate and uses it to sign the hash, producing the digital signature. Finally, the system gathers the signature, the public key, the timestamp, and the previous invoice hash into the stamp structure, and embeds it inside the invoice and in the QR code.

The core idea is that the CSID certificate is the source of trust, but it is not the stamp. The certificate is issued once and stays valid for a period, while a new and different stamp is generated with every invoice. If you issued a thousand invoices in a single day, you would get a thousand different stamps, all signed with the same private key linked to a single CSID certificate.

This distinction explains the cause of common integration errors. When the CSID certificate expires or is invalid, all subsequent signing operations fail, because the tool that produces the stamp is no longer valid. That is why you must track the certificate’s life cycle carefully, as explained in detail by the CSID guide .

Where does the cryptographic stamp live inside the invoice and in the QR code?

The cryptographic stamp does not appear to the ordinary reader as an image; instead it lives in two technical places inside the invoice. Knowing its location helps the accountant verify that the invoice is complete before sending it.

Inside the invoice structure in UBL format

The stamp’s primary location is inside the invoice file in XML format built on the UBL 2.1 specification. There are dedicated fields that carry the digital signature, the certificate data, the timestamp, and the previous invoice hash. This file is what is sent to the Fatoora platform, and it is the complete legal document that the Authority relies on. What the customer sees in PDF/A-3 format carries this file embedded within it.

Inside the QR code

Part of the stamp data is embedded inside the QR (Quick Response) code printed on the invoice. This code carries a signed summary that includes the seller’s name, tax number, the invoice total, and the tax amount, in addition to a digital signature proving the validity of this data. Anyone with the Authority’s verification app can scan the code and confirm that the invoice is sound. For full detail on this code’s structure and fields, see our guide on the QR (Quick Response) code in the e-invoice.

The difference between the two locations matters. The UBL file carries the complete stamp intended for automated verification by the Authority. The QR code, by contrast, carries a signed summary intended for quick field verification, such as a buyer verifying an invoice in a store. The stamp exists in both cases, but at a different level of detail suited to each purpose.

The life cycle of the stamp within a single invoice

Let us follow the journey of a single invoice from the moment “Save” is pressed until it is approved, so the picture of the stamp becomes clear in practice.

In the first moment, the system gathers the invoice data: the seller’s name, tax number, invoice line items, tax amount, total, and timestamp. It arranges this data in an XML structure according to the UBL 2.1 specification, which precisely defines the order and names of the fields. Any flaw in this order makes the invoice unreadable by the Fatoora platform.

After that, the system computes the invoice hash, then extracts the previous invoice hash from the record and includes it so the hash chain is complete. At this point it calls the private key and signs the hash, generating the digital signature that is the heart of the stamp. The system adds the public key, the CSID certificate, and the timestamp, so the stamp is complete with all its components.

Finally, the system generates the QR code containing the signed summary, and embeds the complete stamp inside the UBL file. The invoice is now ready. If it is a business invoice (B2B), it is sent to the Fatoora platform for approval before being delivered to the buyer. If it is an individual invoice (B2C), it is delivered to the buyer immediately and reported to the Authority afterward. In both cases, the stamp is the invoice’s passport through the system.

What distinguishes this cycle is that it repeats in full with every invoice. There is no saved stamp that is reused; instead there is a complete generation process each time, tied to that invoice’s content and to its position in the chain. This is what makes forging a single invoice practically impossible without being detected.

The difference between the cryptographic stamp and an ordinary signature

Many businesses assume that any digital signature is enough for compliance. This is a mistake that leads to rejected invoices. The following table clarifies the fundamental differences.

The bottom line is that the cryptographic stamp is a digital signature, but a signature governed by the Authority’s rules in terms of its source, format, fields, and verification mechanism. The general signature is a broad theoretical concept, and the stamp is a specific application of that concept in the context of the Saudi invoice. This is exactly what distinguishes this guide from the digital signature guide, which explains the general theory.

How does the Authority verify the validity of the cryptographic stamp?

When the invoice arrives at the Fatoora platform, it goes through a series of automated checks before being approved. Understanding these checks explains why one invoice is accepted and another rejected.

The first check confirms that the stamp was produced with a valid CSID certificate genuinely issued by the Authority. The second check recomputes the invoice hash and compares it to the signed hash; if they match, it proves the content has not changed. The third check confirms the validity of the signature itself using the public key. The fourth check verifies the integrity of the hash chain, meaning that the previous invoice hash is correct and sequential.

Here the difference between the two invoice types appears. The full tax invoice between businesses (B2B) is subject to what is called “clearance,” meaning it must pass through the Fatoora platform and be approved before being sent to the buyer. The simplified tax invoice for individuals (B2C), by contrast, is issued and delivered to the buyer immediately, then reported to the Authority within twenty-four hours. In both cases the stamp must be valid, but the timing of the verification differs.

For more detail on these two types, see the definition of the tax invoice and the definition of the simplified tax invoice in the glossary. And if you want the complete picture of integration requirements, the Phase 2 of e-invoicing guide explains the entire system.

How do you make sure your invoices are stamped correctly?

You do not need to read the XML file yourself to be confident your stamp is sound, but it is useful to know the practical signs that indicate a valid invoice before relying on it at scale.

The first sign is that the invoice carries a scannable QR code. Scan the code with the Authority’s verification app; if the seller data, the amount, and the tax appear correctly, this is an initial indicator that the stamp is sound. The second sign is that the Fatoora platform approves business invoices without rejection, since approval means all four checks succeeded.

The third sign is that your system does not display alerts about CSID certificate expiry or signing failure. Such alerts are an early signal of a problem in the tool producing the stamp. The fourth sign is that your invoice numbering sequence is continuous with no gaps, because any gap may point to a break in the hash chain.

When any flaw appears, start by checking the CSID certificate status first, because it is the most common source of problems. Then verify that the system date and time are correct, because a wrong timestamp may invalidate the stamp. A compliant accounting system usually guides you to the cause of the problem with a clear message, so you do not need to guess.

Common mistakes about the cryptographic stamp

Misunderstanding the stamp costs businesses time and rejected invoices. These are the most prominent mistakes we see.

Confusing the stamp with the certificate

Some assume that the “cryptographic stamp” and the “CSID certificate” are the same thing. The certificate is a tool that produces, and the stamp is a result that is generated. Confusing them leads to a wrong diagnosis of any integration problem. If signing fails, the problem is usually in the certificate or the key, not in the stamp itself.

Trying to amend the invoice after stamping it

Some accountants try to change an amount or a line item after issuing and stamping the invoice. Any change breaks the hash and invalidates the stamp. The correct solution is to issue a credit or debit note, not to amend the original invoice. See the definition of the Zakat, Tax and Customs Authority to understand the Authority’s rationale for not accepting direct amendment.

Neglecting to renew the CSID certificate

The stamp depends entirely on the validity of the certificate. Neglecting to renew it suddenly halts the issuance of all invoices. That is why tracking the certificate’s life cycle is part of compliance management, not a secondary technical detail.

Choosing a non-approved invoicing provider

Not every invoicing program is capable of producing a valid stamp in the Authority’s format. Choosing an unqualified solution produces invoices that the Fatoora platform rejects. Learn the selection criteria in the guide on approved companies for e-invoicing.

How does Qoyod handle the cryptographic stamp?

The idea that matters to a business owner is that everything above happens automatically behind the scenes. Qoyod accounting software generates the cryptographic stamp for every invoice with no manual intervention, so you do not need to understand the details of keys and hashes in order to issue a valid invoice.

When issuing the invoice, Qoyod prepares its structure in UBL 2.1 format, computes the hash, signs it with the private key linked to the CSID certificate, and attaches the stamp inside the invoice and in the QR code. It also stores the chain of invoice hashes to guarantee their sequence. All of this happens the moment you save.

Qoyod is compliant with Phase 2 of e-invoicing, and it handles the instant clearance of business invoices and reporting within twenty-four hours for individual invoices. You can review the compliance details on the Phase 2 compliance page and the integration with the Fatoora platform.

Qoyod’s role does not remove your responsibility to issue and register the CSID certificate with the Authority, but it guides you through the steps and handles the technical side afterward. This division of roles is what makes compliance practical for any business, small or large. All of this is backed by a support team available 24 hours a day, all week.

Frequently asked questions about the cryptographic stamp

What is the difference between the cryptographic stamp and the CSID certificate?

The cryptographic stamp is the digital signature attached to every invoice, meaning the result. The CSID certificate is the digital certificate from which this signature is generated, meaning the tool. Every invoice has a different stamp, while a single certificate serves thousands of invoices.

Does the cryptographic stamp appear to the customer on the invoice?

The stamp does not appear as a visible image. It lives inside the invoice file in UBL format, and part of it appears within the QR code data, which can be scanned to verify the invoice’s validity.

Does amending the invoice break the cryptographic stamp?

Yes. Any change to the invoice content after stamping it alters its hash and invalidates the stamp. The correct solution is to issue a credit or debit note instead of amending the original invoice.

What algorithm is used to compute the invoice hash?

Phase 2 relies on the SHA-256 algorithm to compute the invoice hash, and this hash is then signed using the private key linked to the CSID certificate.

Do I need to understand the details of the stamp to issue a valid invoice?

No. A compliant accounting system handles generating the stamp automatically. Understanding it is useful for reading integration errors, but daily issuance requires no technical intervention from you.

What happens if the CSID certificate expires?

The stamp generation process stops for all new invoices, because the tool that produces it is no longer valid. That is why you must track the certificate’s life cycle and renew it before it expires to avoid halting issuance.