Before your business issues its first electronically signed invoice in the production environment, you pass through an indispensable technical checkpoint: obtaining the Compliance CSID certificate (Compliance CSID). This certificate is the gateway to Phase Two of e-invoicing, and through it your system proves its ability to issue valid invoices in the simulation environment before it is allowed to operate for real. Understanding this step saves you weeks of stalled attempts when integrating your e-invoicing software with the Zakat, Tax and Customs Authority platform.
In this guide we detail exactly what the Compliance CSID certificate is, when and how it is issued through the Certificate Signing Request (CSR) and the One-Time Password (OTP), its role in passing the compliance checks, and how you move from it to the production certificate. We also pinpoint where it sits among the other types of Cryptographic Stamp Identifier so the concepts never get mixed up.
What is the Compliance CSID certificate?
The Compliance CSID certificate is a temporary digital certificate issued by the Zakat, Tax and Customs Authority (ZATCA) to your invoicing system during the onboarding process. Its function is clear and limited: it lets your system connect to the Authority’s compliance APIs in the simulation environment (Sandbox), not in the real production environment.
In other words, the Compliance CSID certificate is a “trial licence.” With it, your system proves that it can generate signed e-invoices that conform to the technical specification, before the Authority allows it to handle real invoices. The invoices signed by this certificate stay inside the test environment and carry no tax value, and that is the essential difference that sets it apart from the production certificate.
Remember that “CSID” stands for Cryptographic Stamp Identifier. It is the key that ties every invoice to the business’s identity through a digital signature based on Public Key Infrastructure (PKI). The Compliance CSID is the first, temporary version of this identifier, and it precedes the permanent version dedicated to production.
Many people make the mistake of treating the Compliance CSID as a mere formality to be rushed through. The truth is that it is the most important diagnostic checkpoint in your journey through Phase Two. It is the moment you discover whether your system truly understands the technical specification or whether it produces documents that look valid on the surface but are rejected upon inspection. Discovering this in a safe environment is far better than discovering it on a real invoice in front of a waiting customer.
Add to this an important regulatory dimension: by succeeding in the compliance checks, you prove to the Authority that your business is serious about compliance and technically capable of it. This puts you in the position of a prepared business rather than a lagging one, and gives you a margin of reassurance before the date of your actual obligation to issue in the production environment arrives.
Generate the CSR and request the OTP
Compliance CSID for testing in the simulation
Production certificate PCSID for real invoices
Why did the Authority create a temporary certificate before the production certificate?
Because issuing an e-invoice in Phase Two is not simply printing a sheet of paper. The invoice here is a structured digital document in XML format that follows the UBL 2.1 standard, carrying a cryptographic stamp, a unique identifier (UUID), a Quick Response (QR) code, and a hash chain that links it to the previous invoice. Any error in building this document means it is rejected upon submission.
Instead of discovering these errors on real invoices in front of your customers, the Authority provided a safe simulation environment. The Compliance CSID certificate is the entry ticket to this environment. In it, your system sends invoice samples, the Authority verifies their validity, and moving to production is not permitted until these checks are passed successfully.
When and how is the Compliance CSID certificate issued?
The Compliance CSID certificate is issued at the start of the onboarding journey, that is, after your business joins the scope of Phase Two and connects your invoicing system to the Fatoora platform. The process passes through sequential technical steps, each one building on the one before it.
Step one: generate the Certificate Signing Request (CSR)
Everything begins with generating a Certificate Signing Request (CSR). This is a file created automatically by the invoicing system, containing the identifying data of the business and the device, along with a public key linked to a private key kept securely inside the system. The signing request is, at its core, an “initial identity” you present to the Authority, asking it to endorse it and grant you a certificate.
The signing request data usually includes the business’s tax number, its name, the commercial registration number, the target environment type (simulation or production), and the device identifier. The accuracy of this data is a fundamental condition; any conflict between it and the business’s record at the Authority leads to the request being rejected.
Step two: the One-Time Password (OTP)
After generating the signing request, you need a One-Time Password (OTP) issued from the Fatoora platform. The business owner or the authorised person signs in to the platform and requests the code for the device to be onboarded. This code is what proves to the Authority that the party requesting the certificate is genuinely the one authorised to represent the business.
The OTP is entered into the invoicing system together with the signing request, and the two are then sent together to the Authority’s API. The code has a limited validity period, so the step must be completed as soon as it is issued. If it expires before submission, request a new code and try again.
Generate the CSR inside the system
Request the OTP from the Fatoora platform
Send the request and the code to the Authority
Receive the Compliance CSID certificate
Step three: receive the Compliance CSID certificate
If the Authority accepts the signing request and the code, it responds with the Compliance CSID certificate. The invoicing system stores it securely and links it to the private key generated in step one. From this moment, your system becomes able to sign test invoices and send them to the compliance APIs in the simulation environment.
It is important to understand that this certificate is tied to a specific “device.” Every issuing unit (point of sale, branch, separate environment) needs its own signing request, OTP, and dedicated certificate. A business with three branches and four points of sale may need several certificates, and this is normal in the Phase Two architecture.
The role of the Compliance CSID in the compliance checks
The essence of the Compliance CSID certificate is enabling you to pass the compliance checks (Compliance Checks). These checks are a series of mandatory tests through which the Authority confirms that your system generates every type of required document in the correct format before allowing it into production.
During this phase, your system sends samples of documents to the simulation environment using the Compliance CSID certificate. The samples usually include:
- The standard tax invoice (B2B): an invoice addressed to another business, subject to Clearance before being delivered to the buyer.
- The simplified tax invoice (B2C): an invoice addressed to the final consumer, subject to Reporting within 24 hours.
- The credit note: an adjustment document that reduces the value of a previous invoice or partially cancels it.
- The debit note: an adjustment document that adds value to a previous invoice.
The Authority verifies each sample: is the XML file structure valid? Is the cryptographic stamp correct? Does the QR code carry the nine required fields? Is the hash chain correctly connected? Your system does not pass the check unless all samples go through without errors.
| Document type | Processing |
|---|---|
| Standard tax invoice | Clearance |
| Simplified tax invoice | Reporting |
| Credit note | Depends on the type of the original invoice |
| Debit note | Depends on the type of the original invoice |
What happens when one of the checks fails?
When the Authority rejects a sample, it returns an error message explaining the reason for rejection: a missing field, an identifier in the wrong format, or a non-matching stamp. Your job here is to correct the issue in the settings or the data, then resend the sample. This cycle repeats until every document type passes successfully.
Among the most common causes of rejection: identifiers in a non-standard format, such as the commercial registration number or the tax number written with the wrong number of digits. For this reason, it helps a great deal for your system to validate the format of these identifiers at the moment of entry, before they even reach the checking phase.
Moving from the Compliance CSID to the production certificate
Once you pass all the compliance checks, you move to the final step: requesting the Production certificate PCSID (Production CSID). This is the certificate with which you will sign your real invoices, and it is the decisive difference between a “system that tests” and a “system that operates.”
In practice, your system uses the Compliance CSID certificate itself to request the production certificate from the Authority. That is, the Compliance CSID is not merely an entry ticket for testing; it is also the key that is later exchanged for a permanent certificate. After receiving the production certificate, your system redirects the connection from the simulation environment to the production environment, and begins sending invoices that carry actual tax value.
To dive deeper into the stage that follows this one, see our dedicated guide on the Production certificate PCSID, and for the broader picture of the Cryptographic Stamp Identifier and its types, see the general CSID certificate guide. The two guides show how the three concepts integrate into a single connected journey.
Comparison table: the Compliance CSID versus the production certificate
| Aspect | Compliance CSID certificate | Production certificate PCSID |
|---|---|---|
| Environment | Simulation (Sandbox) | Real production |
| Invoice value | Test invoices with no tax effect | Real and tax-binding |
| Purpose | Passing the compliance checks | Signing daily invoices |
| Timing | Start of onboarding | After passing the checks |
Where does the Compliance CSID certificate sit among the other concepts?
Many people confuse three closely related terms: the general Cryptographic Stamp Identifier (CSID), the Compliance CSID (Compliance CSID), and the production certificate (Production CSID). The picture is simpler than it seems.
“CSID” is the umbrella term describing the idea of the digital certificate with which invoices are signed in general. The Compliance CSID and the production certificate are two successive versions of this identifier: the first temporary for testing, the second permanent for operation. You do not choose between them; rather, you pass through them in order: compliance first, then production.
This order explains why understanding the Compliance CSID well is so important. Any stumble in it halts the whole journey at its very first door. On the other hand, succeeding in passing the checks quickly means a smooth transition to production and an early start on regulatory compliance.
Terms that recur in this journey
- Certificate Signing Request (CSR): the initial identity file that is sent to request the certificate.
- One-Time Password (OTP): a code from the Fatoora platform that proves the authorisation of the party making the request.
- Simulation environment (Sandbox): an isolated test environment where nothing that takes place has any tax effect.
- Clearance: the Authority’s approval of the standard invoice before it is delivered to the buyer.
- Reporting: sending the simplified invoice to the Authority within 24 hours of its issuance.
If you want to anchor these concepts in a broader context, the Fatoora platform guide explains the official portal through which these processes take place, while the guide to integrating with the Authority clarifies the technical side of the integration.
How Qoyod helps you on the Compliance CSID certificate journey
Qoyod is a ready-made solution for Phase Two of e-invoicing, designed to take on the complex technical side on your behalf. With regard to the Compliance CSID certificate specifically, Qoyod offers the following:
- Onboarding devices on the Fatoora platform: Qoyod manages the Cryptographic Stamp Identifier path for every branch and device, generating the signing request, receiving the certificate, and storing it securely without any manual intervention from you.
- Generating the XML file according to the UBL 2.1 standard: Qoyod creates the structured document with all the required fields complete, so the check samples pass in a valid format on the first attempt.
- Instant validation of identifier formats: Qoyod checks the format of the commercial registration, the tax number, and the rest of the identifiers at the moment of entry (released on 2026-05-20), preventing one of the most common causes of check rejection before it happens.
- Managing the clearance and reporting paths: Qoyod handles standard invoices (B2B) through clearance, and simplified invoices (B2C) through reporting within 24 hours, which are the two paths tested in the compliance checks.
- Embedding XML inside a PDF/A-3 file: Qoyod merges the tax XML document inside a single PDF file for the invoice (released on 2026-05-24 for Phase Two customers), meeting the presentation requirement in the technical specification.
Your role stays clear: entering your business data accurately, and requesting the OTP from the Fatoora platform. As for the technical building of the invoice, signing it, and sending it to the simulation environment and then production, the system takes care of that. Note that Qoyod does not register your business with the Authority on your behalf; rather, it guides you through the steps, and the initial registration in the Phase Two scope is done directly by you.
Prepare your business for Phase Two with Qoyod
Let Qoyod handle the Cryptographic Stamp Identifier path and the generation of signed invoices, and focus on your business. Onboarding ready for the Fatoora platform and invoices that conform to the technical specification.
What happens technically during the Compliance CSID request?
Understanding the internal mechanism helps you diagnose any stumble quickly. When generating the signing request, the invoicing system creates a pair of keys: a private key that stays kept inside the system and never leaves it, and a public key that is embedded inside the signing request and sent to the Authority. This cryptographic foundation is what makes the signature on the invoice verifiable later without exposing the private key.
When the Authority receives the signing request accompanied by the OTP, it confirms that the business data matches its record, then signs the public key with its own private key and returns it in the form of a certificate. This certificate ties your business’s identity to the public key in a documented way. From that moment, every invoice your system signs with the private key can be verified by any party using the public key embedded in the certificate.
In the simulation environment, this cycle repeats on a smaller scale: you send a signed sample invoice, and the Authority decrypts the signature and verifies the integrity of the content, the XML file structure, and the hash chain. Success means your system has mastered the technical specification, and failure returns to you the details of what must be corrected. This secure exchange is what protects you from launching a broken system into production.
The QR code deserves special attention. In the standard invoice, this code carries nine encrypted fields, including the seller’s name, its tax number, the timestamp, the invoice total, the tax amount, the hash of the XML file, the cryptographic stamp, the public key, and the signature. Any deficiency in one of these fields makes the code incomplete, so the sample is rejected. That is why a good invoicing system checks the completeness of these fields before submission, not after rejection.
The hash chain deserves similar attention. Every invoice carries a digital fingerprint of the invoice that preceded it, forming an interlinked chain in which it is impossible to tamper with one link without that being detected. This linkage is what guarantees to the Authority the integrity of your invoice sequence, and any break in it appears immediately in the compliance checks.
Readiness checklist before starting the compliance checks
Before you request the Compliance CSID certificate and start the checks, make sure these elements are complete. Advance readiness shortens the rejection cycles and speeds your arrival at production:
- Confirm the scope of obligation: verify that your business falls within the Phase Two wave announced by the Authority, and review your specific obligation date.
- Accuracy of business data: match the business name, the tax number, and the commercial registration number literally with what is registered at the Authority.
- Inventory of issuing units: know the number of branches and points of sale that each need an independent certificate, and plan to onboard them one after another.
- Access permission to the Fatoora platform: ensure that you or your authorised person have the permission to sign in and request the OTP.
- A compliant invoicing system: make sure your system generates the XML file in the UBL 2.1 standard and manages the clearance and reporting paths.
When these elements are complete, the compliance checks turn from a recurring obstacle into a step you pass through. Many delay cases are caused by overlooking a single element from this list, not by the complexity of the process itself.
The Compliance CSID and multiple branches
Businesses with multiple branches face a recurring question: do we repeat the whole process for every branch? The answer is yes in principle, but good management eases the burden considerably. Every issuing unit needs a signing request, an OTP, and a dedicated certificate, but an organised invoicing system manages these certificates in a single dashboard, so you track the status of every device without chaos.
The practical benefit is that a check failure in one branch does not disrupt the rest of the branches. The issue is handled in the unit concerned alone, while the branches that passed continue on their way to production. This separation between units is part of the Phase Two design, and it is what makes it applicable to large and medium businesses alike.
And as your business grows and you add new branches later, the same journey repeats for the new units only: a signing request, an OTP, a Compliance CSID, checks, then a production certificate. The framework is fixed, and the addition builds on it without redoing everything from scratch.
Common mistakes when dealing with the Compliance CSID
Despite the clarity of the steps, some mistakes recur that delay passing the checks. Knowing them in advance saves you precious time:
- Using the Compliance CSID in production: some think that passing the checks is enough to start operating with the certificate itself. This is a mistake; you must request the production certificate first.
- Neglecting the validity of the OTP: the code is time-limited, and delaying its entry invalidates it. Request it as soon as you are ready to submit.
- Conflict between the signing request data and the Authority’s record: if the business name or its tax number differs from what is registered at the Authority, the request is rejected.
- Mixing up devices: using one device’s certificate to sign another device’s invoices fails, because every issuing unit needs its own certificate.
Avoiding these mistakes makes your journey from the signing request to production smooth. Whenever you want a broader reference on regulatory compliance, you will find useful the guide to Phase Two readiness andthe basics of Value Added Tax which place the Compliance CSID in its full tax context, in addition to the integrated accounting platform that manages all of this from one place.
Frequently Asked Questions
Is the Compliance CSID certificate free?
Issuing the certificate through the Fatoora platform is part of the regulatory onboarding process for Phase Two, and the Authority does not impose direct fees for issuing it. What you need is a compliant invoicing system that takes on the technical side.
How long do the compliance checks take?
The duration depends on the readiness of your system. If the system generates documents in a valid format from the start, you may pass the checks in a short time. But if rejection recurs due to errors in the data, the cycle may lengthen until all the samples are corrected.
Do I need a compliance certificate for every branch?
Yes. Every issuing unit, whether a branch, a point of sale, or a separate environment, needs its own signing request, OTP, and dedicated certificate. This is normal in the Phase Two architecture.
What happens to the invoices signed by the Compliance CSID?
They stay inside the simulation environment and carry no tax value. Their purpose is only to test the system, and they are not counted within your business’s tax record.
Can I skip the Compliance CSID and move directly to production?
No. The Compliance CSID is a mandatory step that precedes the production certificate. The Authority does not issue a production certificate until the compliance checks are passed successfully in the simulation environment.
Who is responsible for issuing the certificate, me or the invoicing system?
The responsibility is shared. You enter the business data and request the OTP from the Fatoora platform, while the invoicing system takes care of generating the signing request, sending it, and receiving and storing the certificate.
