What Is a CSID? Cryptographic Stamp Identifier Explained for ZATCA E-Invoicing

A Cryptographic Stamp Identifier (CSID) is a ZATCA-issued ECC P-256 X.509 digital certificate provisioned per Solution Unit through a CSR + OTP flow on the Fatoora portal. Its private key signs every Phase 2 e-invoice as XAdES-B over the canonicalised UBL 2.1 payload, binding the invoice hash, the previous invoice hash (the PIH chain), the seller's VAT number, and the invoice UUID into a tamper-evident cryptographic stamp.

Where the CSID sits in ZATCA's architecture

The CSID is the cryptographic identity at the heart of ZATCA Phase 2.

The CSID is the cryptographic identity at the heart of ZATCA Phase 2. ZATCA's design separates three concerns: identification (the VAT number), integrity (the XAdES signature with the CSID's private key), and tamper-evidence (the previous-invoice-hash chain). The CSID is the credential that ties identification and integrity together — without it, no signature; without a signature, no Phase 2 invoice.

Definition

A CSID is an X. 509 v3 digital certificate issued by ZATCA to a Saudi VAT-registered taxpayer, bound to a specific Solution Unit (an EGS — E-invoice Generation Solution instance), with an ECC P-256 key pair generated taxpayer-side.

A CSID is an X.509 v3 digital certificate issued by ZATCA to a Saudi VAT-registered taxpayer, bound to a specific Solution Unit (an EGS — E-invoice Generation Solution instance), with an ECC P-256 key pair generated taxpayer-side. The private key never leaves the taxpayer's environment. The certificate's public key, paired with the ZATCA-rooted trust chain, lets ZATCA and downstream consumers (auditors, buyers, third parties) verify every signed e-invoice.

How a CSID is provisioned

Step 1 — Generate the Certificate Signing Request

The EGS generates a CSR carrying the VAT number, common name, Commercial Registration Number (CRN), business category, country code (SA), and the ECC P-256 public key. The CSR also encodes a Solution Unit serial number; ZATCA matches that serial against every signed invoice at validation, so it must remain stable for the life of the Solution Unit.

Step 2 — Request the one-time password from Fatoora

The taxpayer authenticates to the ZATCA Fatoora portal, navigates to Onboard New Solution Unit / Device, and generates an OTP. The OTP is valid for one hour and binds to a single Solution Unit. Each device or tenant gets its own OTP — re-using an OTP across devices fails.

Step 3 — Exchange CSR + OTP for the Compliance CSID

POST CSR + OTP to the ZATCA compliance CSID endpoint. ZATCA returns a Compliance CSID — a sandbox-scoped certificate. It exists only to let the EGS pass the compliance checks; it cannot sign production invoices.

Step 4 — Pass the compliance checks and promote to Production CSID

Submit at least one of each invoice type (Standard, Simplified, plus credit and debit notes) to the compliance endpoint. Each is validated for UBL 2.1 conformance, XAdES signature correctness, TLV QR encoding, and PIH chain integrity. Once compliance passes, exchange the Compliance CSID for the Production CSID via the production CSID API. This is the certificate that signs live invoices.

What the CSID signs

For every e-invoice the EGS:

For every e-invoice the EGS:

1. Renders the UBL 2.1 XML with the ZATCA KSA extensions.
2. Canonicalises the payload (a strict, deterministic XML canonicalisation).
3. Computes the invoice hash (SHA-256 over the canonicalised payload).
4. Computes the Previous Invoice Hash (PIH) by reading the prior invoice's hash from the local chain.
5. Builds the XAdES ds:Signature block referencing the invoice hash, the PIH, the certificate, and the timestamp.
6. Signs the resulting digest with the CSID's ECC P-256 private key.

The signature binds together: the invoice hash, the previous invoice hash (chain integrity), the seller's VAT number, the invoice UUID, and the issue timestamp. Any post-issue edit to the payload changes the canonicalised hash, breaking the signature; ZATCA and downstream consumers detect the change immediately.

CSID vs TLV QR vs PIH

The three Phase 2 cryptographic primitives are easy to conflate:

The three Phase 2 cryptographic primitives are easy to conflate:

• CSID: the seller's signing certificate. Identity + private key.
• TLV QR: a Tag–Length–Value buyer-facing summary printed on the invoice. In Phase 2 it carries the seller name, VAT number, timestamp, total with VAT, VAT amount, plus tags 6–9 (XML hash, ECDSA signature, ECDSA public key, ZATCA stamp). It is the buyer's primary verification surface.
• PIH: the Previous Invoice Hash. Chains each invoice to the previous one so any insertion, deletion, or reordering is detectable. Not a credential — purely a tamper-evidence mechanism.

The CSID produces the signature that the QR's tags 6–9 reference. The PIH chain runs in parallel — every signed invoice carries the prior PIH, so an audit can replay the chain end to end.

Common CSID errors and how to fix them

Common CSID errors and how to fix them includes: Signing with the Compliance CSID in production — the single most common Phase 2 go-live error. Fix: promote to the Production CSID after compliance passes and update the EGS key store.

• Signing with the Compliance CSID in production — the single most common Phase 2 go-live error. Fix: promote to the Production CSID after compliance passes and update the EGS key store. The Compliance certificate is sandbox-only.
• CSR Solution Unit serial mismatch — ZATCA rejects signatures whose certificate's serial does not match the per-Solution-Unit serial issued at onboarding. Fix: keep the serial stable; never rotate it casually.
• OTP expired or re-used — OTPs are valid for one hour and bind to a single Solution Unit. Fix: re-issue the OTP per device.
• Wrong canonicalisation — the signature is over the canonicalised XML, not the source. Drift in whitespace, attribute order, or namespace prefixes invalidates the signature. Fix: run ZATCA's canonicalisation routine before computing the hash.
• CSID near expiry without renewal — production CSIDs have a validity period defined in the Security Features Standards; ZATCA hard-rejects signatures from expired certificates. Fix: schedule renewal well before expiry; the same VAT number may hold sequential CSIDs.
• Revoked CSID still in use — once revoked through Fatoora, no further signatures will validate. Fix: provision a replacement immediately; invoices already signed under the revoked CSID before the revocation timestamp remain valid.

Where this concept recurs in other regimes

The CSID is ZATCA-specific in name and shape, but the pattern — a regulator-issued signing credential bound to the seller's tax identity — recurs across clearance jurisdictions under different names and formats:

The CSID is ZATCA-specific in name and shape, but the pattern — a regulator-issued signing credential bound to the seller's tax identity — recurs across clearance jurisdictions under different names and formats:

• Nigeria NRS MBS — a NRS-onboarded credential bound to the Merchant TIN; see FIRS MBS Nigeria explained.
• Malaysia MyInvois — an LHDN-issued certificate per submitter; uses JWS signatures over JSON or XML payloads.
• India GST IRN — the IRP signs the issued IRN with its own JWS; the seller does not hold a regulator-issued certificate.
• Peppol — uses an AS4 transport certificate per Access Point, not per seller; the network is the trust boundary, not the regulator. See what is a Peppol Access Point.

The signing format itself — XAdES — is described in detail in XAdES digital signatures explained.

Key takeaways

Key takeaways includes: The CSID is ZATCA's per-Solution-Unit X. 509 + ECC P-256 signing certificate.

• The CSID is ZATCA's per-Solution-Unit X.509 + ECC P-256 signing certificate.
• Provisioned through a CSR + OTP exchange on Fatoora; private key stays taxpayer-side.
• Signs every Phase 2 invoice as XAdES-B over canonicalised UBL 2.1.
• Two flavours: Compliance (sandbox) and Production (live). Signing live with the Compliance CSID is the #1 go-live error.
• Different from the TLV QR (buyer-facing summary) and the PIH chain (tamper-evidence).

Related reading

To implement the regime end to end, read how to comply with ZATCA Phase 2. For the full Phase 2 explainer, see ZATCA Phase 2 explained.

To implement the regime end to end, read how to comply with ZATCA Phase 2. For the full Phase 2 explainer, see ZATCA Phase 2 explained. The signing format is unpacked in XAdES digital signatures, and the schema in UBL 2.1 explained. The pillar is global e-invoicing.

Authority sources

• ZATCA — Security Features Implementation Standards v1.2 (May 2023)
• ZATCA — E-Invoicing Detailed Technical Guideline v2
• ZATCA — Detailed Guidelines for E-Invoicing v2 (May 2023)
• ZATCA — Developer Portal User Manual
• ZATCA — Systems Developers Hub (CSID API references)
• ETSI EN 319 132-1 — XAdES Baseline Profile