In brief
A compliant solution must support its actual document and unit architecture. ZATCA’s technical scenarios, QR definitions and response rules distinguish production onboarding, stamping, reporting, chain integrity and ongoing evidence.
A compliant Saudi e-invoicing solution must support the document type, taxpayer identity, issuance architecture and integration process actually used by the business. A supplier’s statement that software “supports Fatoora” is a starting point for verification, rather than a complete assessment of the deployed version and configuration.
The implementation controls, their annexes and ZATCA’s detailed and technical guidelines distinguish generation, signing, clearance, reporting and retention. Those functions should be mapped before the business decides how many units to onboard or accepts the system as ready.
Define the document flows before selecting capabilities
Implementation controls Clause Two(3) distinguish standard Tax Invoices and their associated notes from Simplified Tax Invoices and their notes. Standard documents require ZATCA clearance before they are shared with the customer. Simplified documents are generated with the required stamp and reported within no more than 24 hours of generation.
The solution must therefore handle the correct route for each document, including credit and debit notes. A system that sends every document through a single delayed reporting queue does not establish compliant clearance of standard invoices.
ZATCA’s Detailed Technical Guideline, section 4.3, explains submitting documents to the Authority in the required structured XML form, validation outcomes and the distinct clearance and reporting processes. A printable invoice alone does not demonstrate that the required structured document was generated and shared correctly.
Map the real issuing and signing architecture
A physical screen or checkout is not necessarily the unit that generates, signs and transmits the document. Technical Guideline sections 3.5.1–3.5.4 describe central servers, smart point-of-sale devices, branch servers and terminals that cannot sign invoices.
In the section 3.5.1 central-server scenario, the certificate structure follows the taxpayer and unique document sequence on the server. In the section 3.5.4 terminal scenario, a terminal that relies on the server for the relevant signing and QR functions need not have its own CSID merely because it is a separate checkout. The server’s actual role and the standard/simplified route still matter.
These are ZATCA’s architectural scenarios, not a licence to share credentials indiscriminately. Prepare a diagram identifying the legal taxpayer, VAT number, actual generating/signing unit, document sequence and transmission path. Confirm the intended design against the applicable scenario before counting certificates or onboarding devices.
Distinguish compliance credentials from production credentials
The technical guideline’s section 3 separates the initial onboarding process, compliance checks, production CSID, renewal and revocation. A successful test submission or compliance credential should not be treated as evidence that the actual production unit is fully onboarded for its required document types.
Section 4.2 explains that the associated production credential must remain valid, unrevoked and associated with the correct functionality. Monitor the actual certificate record and renewal process. Dariba recommends an internal renewal lead time that allows testing and correction; a chosen thirty-day reminder is an operating control, not a universal statutory renewal deadline.
Changes in VAT registration or group status can affect existing credentials and require the applicable re-onboarding process. Preserve the taxpayer and unit mapping when reorganising branches or migrating systems instead of copying an old credential into a new design without review.
Apply signing and QR requirements by document type
Under implementation controls Clause Two(3)(a), ZATCA applies the clearance stamp to compliant standard documents through the clearance process. Simplified documents require the applicable solution-generated stamp before reporting. Saying that the supplier’s device applies the same final stamp to every invoice obscures that distinction.
The Technical Guideline, section 6, QR field-definition table, specifies the QR contents:
| Tag | Specified content |
|---|---|
| 1–5 | Seller name, seller VAT number, invoice timestamp, total including VAT and VAT total |
| 6 | Hash of the invoice XML |
| 7 | ECDSA signature |
| 8 | ECDSA public key |
| 9 | For simplified invoices and associated notes, ZATCA technical certification authority’s signature of the cryptographic stamp public key |
The CSID certificate, previous-document hash and invoice counter have their own roles. They are not substitute descriptions for QR tags 8 and 9. A QR that displays seller and total information is also not, by itself, proof that the complete Phase Two security content and processing are correct.
Request validation of actual production-like samples for each document type, including notes and special transaction cases. Technical Guideline sections 5–6 explain signing and encoding; the exact current standards and applicable annex fields must be implemented, rather than recreated from a marketing checklist.
Keep counters, document chains and response handling distinct
Implementation controls Clause Three and Annex One require the relevant counter, tamper protection and linked document history. The counter, document identifier, previous-document hash and QR data should be reconciled as separate controls.
Technical Guideline section 4.3 explains that the sequence covers generated standard and simplified documents for the onboarded unit. It also distinguishes generation order from transmission order and discusses preserving the document chain when a submission is rejected. A rejected submission should not lead the business to erase the original record or restart the counter.
The same section distinguishes a valid document, an accepted document with warnings and a rejected document. An acceptance response carrying warnings is not evidence that every requirement was satisfied. Assign responsibility for correcting the cause and retain the returned messages with the affected document.
The clearance and reporting guide explains the business workflow. System status, customer delivery and the VAT accounting record should remain traceable to one another.
Remove prohibited functions and secure the signing key
Implementation controls Annex One, Prohibited Functionalities, distinguishes the applicable phase requirements. It addresses uncontrolled access, alteration or deletion of generated invoices, notes or logs, inaccurate timestamps, counter reset, multiple sequences from a unit, export of stamping keys and software time changes as specified in the table.
These are capability requirements. A prohibited editing or key-export option should not be accepted merely because staff promise not to use it. Test the deployed configuration, user permissions and administrative tools, including the software version actually in use.
The stamping key must be protected against the prohibited export functionality. This should be distinguished from exporting invoice records for lawful archival purposes, which the controls also address. A requirement to secure a private key does not prohibit maintaining the required invoice archive.
Retain records and operate an incident process
Controls Clauses Five and Seven(4)–(5) address retention, incidents, notification of recovery and resuming required generation and integration. Fatoora acceptance does not transfer the taxpayer’s record-keeping obligations to ZATCA.
Maintain recoverable invoice and note records, associated data and the relevant processing evidence for the actual statutory retention period. Test restoration and access after a vendor change. A dashboard that only displays totals is not a substitute for the underlying records needed to support a return or examination.
For an outage, establish whether the failure concerns the business, its provider, connectivity or ZATCA’s platform. Follow the applicable Authority notification and recovery procedure, preserve timestamps and responses, and reconcile the backlog. Do not turn a temporary technical exception into indefinite permission to stop generating the required documents.
Accept the deployed solution on evidence
ZATCA’s Solution Providers Directory is expressly indicative and does not constitute Authority approval of the listed solutions. Taxpayers may use a compliant solution from a provider outside the list. An in-house or unlisted design therefore requires the same substantive verification; a listed supplier does not eliminate it.
Dariba recommends acceptance evidence covering actual document types, taxpayer/unit mapping, production onboarding, signatures and QR fields, counters and chain integrity, rejected and warning responses, outage recovery and archive restoration. The technical guideline sections 2.1.4–2.1.5 describes optional validation and sandbox tools; these are useful testing resources, not a promise of production approval or a mandatory project duration.
Link the written acceptance to the deployed version and known remaining defects. The penalties guide explains the current category-specific consequences, while the Wave 25 guide addresses the particular revenue threshold and integration date.
Key takeaways
- Map generating, signing and transmission roles before counting units or CSIDs.
- ZATCA technical scenarios distinguish central servers from signing POS devices.
- Standard clearance and simplified signing/reporting have different stamp responsibilities.
- QR tags 8 and 9 concern the public key and specified CA signature, not the previous hash.
- Accepted-with-warning and rejected documents require different follow-up.
- Provider-directory inclusion does not constitute ZATCA approval of the solution.
Sources
- ZATCA e-invoicing implementation controls, current Arabic publicationClauses Two, Three, Five and Seven and Annex One: document routes, security, retention, integration and incidents; controlling Arabic text.
- ZATCA English publication of e-invoicing implementation controlsReading aid for the controlling Arabic controls and annexes; standard clearance and simplified reporting distinguished.
- ZATCA Detailed Guidelines for E-Invoicing, version 2, May 2023Sections 4–7 and 10 explain document routes, technical controls, taxpayer duties, records and failure scenarios.
- ZATCA E-Invoicing Detailed Technical GuidelineSections 2.1, 3.5, 4.2–4.3 and 5–6: optional testing, unit/CSID scenarios, response handling, signing and actual QR tags.
- ZATCA Solution Providers Directory and express disclaimerIndicative directory does not constitute approval of the listed solutions; compliant unlisted solutions are permitted.
General information only. Actual supplies, facts, applicable periods and controlling Arabic legislation determine the result. Official examples are distinguished from Dariba analysis and original illustrations. Seek advice or clarification where the arrangement or source material leaves a specific issue unresolved.
