When any Saudi business moves to the second phase of e-invoicing, one phrase recurs in every technical guide and at every integration step: “CSID certificate.” This certificate is what turns your invoice from an ordinary digital file into a digitally signed document recognized by the Zakat, Tax and Customs Authority (ZATCA). Without it, your invoice cannot be stamped, cannot be sent to the Fatoora platform, and cannot be legally accepted.
In this guide we explain the Cryptographic Stamp Identifier (CSID) from the ground up: what it is, why the Authority requires it, how it signs your invoices, what its lifecycle looks like, and why it comes in two distinct types. The goal is to give you the full picture before you dive into the technical details of each type, because understanding the identifier itself saves you many integration errors later.
What is the Cryptographic Stamp Identifier (CSID)?
The Cryptographic Stamp Identifier, is a digital certificate issued by the Zakat, Tax and Customs Authority for every device or invoicing solution that issues electronic invoices. This certificate acts as a unique cryptographic identity, linking every invoice your business issues to its true source in a way that cannot be forged.
The core idea is simple. Every invoice in the second phase must carry a cryptographic stamp, a digital signature that proves two things: that the invoice was genuinely issued by the registered business, and that its content has not changed since issuance. The certificate is the tool that produces this stamp and proves its validity. In other words, the CSID is the digital ID card your accounting system uses to sign every invoice in your business’s name.
Technically, the certificate is of the X.509 type, and it includes a Public Key linked to a Private Key that the invoicing system keeps securely. When an invoice is issued, the system uses the private key to create a digital signature, and the public key and signature are embedded within the invoice structure and in the QR (Quick Response) code. Any party wanting to verify the invoice can use the public key to confirm the signature is valid.
It is important to distinguish between two terms that many people confuse. The “cryptographic stamp” is the digital signature itself that is attached to each invoice. The “Cryptographic Stamp Identifier” (CSID), meanwhile, is the certificate that makes it possible to create that stamp. The first is a result; the second is the tool that produces the result.
A digital certificate in X.509 format
A key pair: a public key and a private key
The private key generates the invoice’s cryptographic stamp
Links the invoice to the identity of the business registered with the Authority
Embeds the stamp within the QR (Quick Response) code
Why does the Authority require the Cryptographic Stamp Identifier?
The Authority’s requirement for this certificate is not a mere formality. It is a fundamental pillar in the design of the second phase of e-invoicing, and it serves clear objectives in protecting the tax system from manipulation.
The first objective is proving the source. When an invoice reaches the Fatoora platform, the Authority needs to be sure it was genuinely issued by the business that claims to have issued it, and not by an impersonating party. The cryptographic stamp produced by the certificate proves the source’s identity conclusively, because the private key is held only by the approved system for that business.
The second objective is preventing content tampering. Any modification to the invoice after signing, even changing a single digit in the amount, renders the signature invalid. This turns every invoice into a tamper-proof document that cannot be forged without being detected immediately upon verification.
The third objective is building a trusted chain of invoices. Every invoice in the second phase is linked to the invoice before it through a hash value, and is digitally stamped. This creates a sequential record from which it is difficult to delete an invoice or insert a fake invoice without breaking the chain.
The fourth objective is enabling real-time verification. Because the invoice carries the proof of its source and integrity within itself, the Authority and any concerned party can verify it instantly at clearance or reporting, without waiting or manual review. This speeds up the approval cycle and reduces disputes over invoice validity.
With these four objectives, invoicing shifts from a paper-based process open to manipulation into a trusted digital system. And because the certificate is the cornerstone of this system, the Authority made it an indispensable requirement for entering the second phase. You can review the broader picture of integration requirements on the page E-invoicing with Qoyod.
How does the identifier sign your invoices step by step?
To understand the certificate’s role in practice, follow the journey of a single invoice from the moment it is created until it reaches the buyer. This journey reveals exactly where the identifier steps in.
The process begins with creating the invoice inside your accounting system in an XML format compliant with the UBL 2.1 standard. The invoice includes the seller and buyer data, invoice line items, tax amounts, and the total. Up to this point, the invoice is merely a data file with no signature.
Next, the system computes a hash value for the invoice using the SHA-256 algorithm. This value is a unique digital fingerprint representing the entire content of the invoice, and any change to the content changes it. The system then links this invoice to the previous invoice by embedding its fingerprint, forming a connected chain.
Here the certificate’s role comes in. The system uses the private key associated with the identifier to digitally sign the hash value using the ECDSA algorithm. This produces the cryptographic stamp, the signature that proves the source and the integrity of the content. This stamp, along with the public key, is embedded within the invoice structure and within the QR (Quick Response) code.
The final step differs depending on the invoice type. The business-to-business (B2B) tax invoice is first sent to the Fatoora platform for clearance, and it cannot be delivered to the buyer until the Authority returns it cleared. The simplified consumer-facing (B2C) tax invoice, meanwhile, is delivered to the buyer immediately and then reported to the Authority within 24 hours (Reporting). In both cases, the stamp produced by the certificate is a condition for accepting the invoice. For more detail on this mechanism, see the e-invoicing learning section.
Create the UBL 2.1 file
Compute the SHA-256 hash
Link it to the previous invoice’s hash
Sign with the private key
Embed the stamp in the QR code
Clearance or reporting via the Fatoora platform
Lifecycle of the Cryptographic Stamp Identifier
The certificate is not something you obtain once and forget. It has a clear lifecycle that begins with an issuance request and passes through stages up to actual use and renewal. Understanding this cycle helps you avoid an issuance outage in the middle of your work.
The cycle begins by creating a Certificate Signing Request inside the invoicing system. This request generates the key pair: the private key, which remains securely stored in your system, and the public key, which is sent within the request.
The request is then submitted to the Fatoora platform along with an OTP (one-time password) you obtain from the Authority’s portal. This code proves that the business owner is the one authorizing the issuance of the certificate for that device or solution. Upon successful verification, the Authority issues the certificate.
The next stage is the compliance stage. The Authority first issues a compliance certificate used in the testing environment to confirm that your system produces fully valid invoices. After passing the compliance checks, the Authority issues the production certificate you use to sign your actual invoices. This split into two types is what we explain in the next section.
The certificate has a defined validity period, and it needs to be renewed before it expires so that invoice issuance is not interrupted. You may also need to reissue the certificate upon certain changes to the business data or devices. That is why your system should manage this cycle automatically as much as possible to avoid any sudden interruption to daily operations.
An important practical point: every device, branch, or issuing unit needs its own identifier. A business operating from multiple branches or multiple points of sale manages several certificates at once, which is what makes automating this management a necessity rather than a luxury.
How is the certificate issued through the Fatoora platform?
Obtaining the certificate is not a single step, but an organized sequence carried out through the Fatoora platform. Understanding its order reassures you that every step has a purpose, and that a good accounting system handles it for you without any technical involvement on your part.
The process begins inside the invoicing system by generating the key pair and creating the certificate signing request. This request carries the public key and the basic business data, while the private key remains stored in the system and never leaves it. The confidentiality of the private key is the foundation of the security of the entire system.
You then obtain a one-time password from the Authority’s portal and enter it into your system when submitting the request. This code proves that the authorized business owner is the one permitting a certificate to be issued for this specific device, preventing any unauthorized party from registering devices in your business’s name.
Upon successful verification, the Authority first issues the compliance certificate, with which you enter the testing stage, then, after passing it, you obtain the production certificate. This organized sequence is what ensures that any system reaching the stage of signing real invoices has genuinely proven its readiness.
Issue your invoices signed and compliant with the second phase
Qoyod manages the issuance and renewal of the Cryptographic Stamp Identifier certificate for every branch, signs your invoices automatically, and connects them to the Fatoora platform with no technical complexity on you.
The two types: the compliance certificate (CCSID) and the production certificate (PCSID)
What most confuses businesses during integration is that the Cryptographic Stamp Identifier is not a single certificate, but comes in two successive types, each with a different purpose and role in the integration journey. Understanding the difference between them saves you hours of confusion in the face of error messages.
The first type is the Compliance CSID, abbreviated as CCSID. This certificate is transitional; its purpose is to test your system in the trial environment before the actual launch. You use it to send test invoices and confirm that your system produces a correct invoice structure, a valid QR code, and an accepted cryptographic stamp. You do not sign real invoices with a tax effect using it.
The second type is the Production CSID, abbreviated as PCSID. This is the actual certificate you use to sign your real invoices after passing the compliance checks. Every invoice you actually issue to your customers is stamped with this certificate, and it is the one the Authority recognizes in the production environment.
The relationship between the two types is sequential. You obtain the compliance certificate first, test with it, then request the production certificate based on the success of the test. You cannot jump straight to production without passing through the compliance stage. This progression ensures that any system entering the production environment has proven its ability to produce valid invoices.
To go deeper into each type on its own, we have dedicated a separate guide to each. See the guide Compliance CSID certificate to understand the testing stage and its checks in detail, and the guide PCSID production certificate to understand the actual signing mechanism and certificate renewal in production.
| Criterion | CCSID compliance certificate | PCSID production certificate |
|---|---|---|
| Environment | Simulation | Production |
| Invoices | Test invoices for trials | Real, approved invoices |
| Tax effect | No effect | Recognized by the Authority |
| Role | Compliance testing | Actual signing of invoices |
A technical breakdown of the certificate in simple terms
You do not need a cryptography background to understand how the certificate works, but knowing its basic components makes you better able to read error messages and handle them. At its core, the certificate is three interconnected elements.
The first element is the key pair. The private key stays secret inside the invoicing system and is used to create the signature. The public key is published with every invoice and is used to verify the signature. What the private key signs can only be verified by its corresponding public key, and this mathematical relationship is the basis of all the trust.
The second element is the digital certificate itself in X.509 format. This certificate links the public key to the identity of your business registered with the Authority. In other words, the certificate tells everyone: this public key belongs to this specific business, and the Authority attests to that.
The third element is the signing algorithm. The second phase relies on the ECDSA algorithm, based on elliptic curve cryptography. This algorithm is characterized by being strong in security and compact in size, producing a relatively small signature that is easy to embed in the QR (Quick Response) code without inflating it.
When these three elements come together, every invoice becomes a signed document that carries the proof of its source within itself. There is no need for a central database to verify a particular invoice, because the proof is embedded in the invoice and its code.
The QR code and the role of the identifier in it
Many people see the QR (Quick Response) code on the invoice and think it is just a link or a number. In reality, it is an organized container that carries the invoice’s basic data in TLV (tag, length, value) format, including information directly linked to the certificate.
The simplified tax invoice code in the second phase includes nine fields: the seller’s name, their tax registration number, the timestamp, the invoice total including tax, the total tax, the invoice hash value, the cryptographic stamp, the public key, and the public key signature. The last four fields are all a direct product of the certificate.
This means the identifier does not merely sign the invoice, but makes the signature verifiable by any party simply by scanning the code. The buyer or auditor can confirm the integrity of the invoice and its source without going back to the seller. This transparency is what turns the code from decoration on paper into a real verification tool.
Managing the identifier in multi-branch businesses
The biggest challenge in managing certificates does not appear in a single-branch business, but in businesses that operate from multiple locations or run multiple points of sale. Here, management shifts from a simple task into a process that needs organization.
The rule is that every independent issuing unit needs its own identifier. The branch in Riyadh has its certificate, the branch in Jeddah has its certificate, and each point of sale within the branch may need its own certificate depending on the issuance method. This means a business with ten branches may manage dozens of certificates at once.
Each of these certificates has its own lifecycle: issuance, compliance check, production, then renewal as the validity approaches expiry. Tracking this number manually is a real burden, and any certificate that expires unnoticed means issuance stops in that branch and its sales operations are disrupted.
This is where the value of an accounting system that manages these certificates centrally lies. When all certificates are managed from a single dashboard, expanding by opening a new branch becomes a matter of adding an issuing unit, not a separate technical project each time.
What does the identifier mean for your business in practical terms?
Talk of keys and signatures may seem far from a business owner’s daily concerns, but the certificate’s impact on your business is direct and tangible.
At the compliance level, having a valid and effective certificate is a condition for your invoices to be accepted by the Authority. An invoice without a valid stamp is a rejected invoice, and this exposes you to regulatory risks and potential fines. The certificate is therefore your first line of defense for the soundness of your tax position.
At the business-continuity level, any fault in the certificate, whether an expiry or an issuance error, halts your ability to issue approved invoices. In sectors such as retail or restaurants, a halt in issuance means a halt in sales. That is why managing the certificate reliably is not a purely technical matter, but a matter of revenue continuity.
At the trust level, a signed invoice gives your customer and partners assurance that dealing with you is official and documented. This strengthens your business’s reputation and eases its dealings with entities that require compliant invoices. In short, the certificate is an investment in your business’s reliability, not just a technical requirement you fulfill reluctantly.
Common mistakes when dealing with the identifier
Many integration problems with the Fatoora platform stem from a simple misunderstanding about the certificate. Being aware of these mistakes shortens the path considerably.
The first mistake is confusing the two types. Some businesses try to sign real invoices with the compliance certificate, and they are rejected. The compliance certificate is for testing only, and production has its own separate certificate.
The second mistake is neglecting renewal. The certificate has a validity period, and if it expires without renewal, the issuance of signed invoices stops. Track the expiry dates, or use a system that manages renewal automatically.
The third mistake is assuming a single certificate is enough for all branches. Every issuing unit needs its own identifier. A multi-branch business manages several certificates, and ignoring this causes failures in branches whose devices have not been registered.
The fourth mistake is poor safekeeping of the private key. The private key is the foundation of signing security, and losing it or leaking it means losing the ability to sign or putting your business’s identity at risk. Reliable systems keep the key in a secure environment away from direct access.
How Qoyod helps you
The technical complexity surrounding the Cryptographic Stamp Identifier is exactly what Qoyod handles on your behalf. You run your business and issue your invoices, and the system takes care of the entire cryptographic layer.
Qoyod manages creating the certificate signing request, issuing the compliance certificate, passing the test checks, then issuing the production certificate for every branch or issuing unit in your business. You do not need to deal directly with the complexities of keys and signing.
When each invoice is issued, Qoyod signs it automatically with the cryptographic stamp, generates the compliant QR (Quick Response) code, links the invoice to the previous invoice within the chain, then sends it to the Fatoora platform for clearance or reporting depending on its type. All of this runs in the background with no manual steps on you.
Qoyod is a solution compliant with the second phase of e-invoicing, generating invoices in UBL 2.1 format with the cryptographic stamp, the QR code, and the invoice chain. It lets you focus on your business instead of being preoccupied with technical details. And for any help, Qoyod support is available 24 hours a day, seven days a week. Learn more about Qoyod’s compliance with the second phase and about integration with the Authority.
Frequently asked questions
What is the difference between the cryptographic stamp and the Cryptographic Stamp Identifier?
The cryptographic stamp is the digital signature attached to each invoice to prove its source and integrity. The Cryptographic Stamp Identifier (CSID), meanwhile, is the digital certificate that makes it possible to create that stamp. The first is a result; the second is the tool that produces it.
Do I need one identifier or several identifiers?
It depends on the number of issuing units you have. Every device, branch, or point of sale that issues invoices needs its own identifier. A multi-branch business manages several certificates at once.
What is the difference between the compliance certificate and the production certificate?
The compliance certificate (CCSID) is transitional, for testing in the trial environment before launch, and you do not sign real invoices with it. The production certificate (PCSID) is the one you use to sign your actual invoices after passing the test.
What happens if the identifier expires?
The issuance of signed invoices stops until renewal. That is why you must track the expiry dates, and it is best to use a system that manages renewal automatically to avoid any interruption to your work.
Does Qoyod manage the issuance of the identifier on my behalf?
Yes. Qoyod handles creating the certificate request, issuing the compliance certificate, passing the checks, then issuing the production certificate for every branch, and it signs your invoices automatically without any technical involvement on your part.
Is the identifier a substitute for registering on the Fatoora platform?
No. The identifier is part of the integration process with the Fatoora platform, not a substitute for it. The Fatoora platform is mandatory, and the identifier is the tool with which invoices are signed within this system.
What signing algorithm is used in the cryptographic stamp?
The second phase relies on the ECDSA algorithm, based on elliptic curve cryptography. This algorithm produces a signature that is strong in security and relatively small in size, making it easy to embed in the invoice structure and in the QR (Quick Response) code without inflating the data.
