Review business identity, document requirements and the separate stages of ZATCA integration before statutory use.
Start with the actual Saudi business#
Complete shared Business setup for the Saudi corporate profile before installing its apps. Review the actual legal name, registration, address, tax status, record currency and time zone. Configure Accounting and its legal compliance profile for that same entity.
The business owner must establish the applicable ZATCA requirements and integration notification for their own registration. Selecting Saudi Arabia, VAT registration or an invoice design does not activate a government connection.
Official references: ZATCA electronic invoice specifications ↗
Clearance and reporting are separate workflows#
Standard and simplified documents have different authority workflows. Review the applicable invoice type, buyer identification, tax treatment and correction process against the official specifications. A quotation is a commercial proposal, not an electronic tax invoice.
Production implementation must preserve document identity, exact tax calculations, the required XML and security features, and the original authority response. A failed or uncertain request needs reconciliation against the same source document rather than a newly invented invoice or duplicate submission.
Official references: ZATCA security requirements ↗
Read each readiness stage correctly#
The released customer workspace provides source exports and a limited local XML preflight. Preflight checks selected fields only. It does not run the full official validation rules, verify a cryptographic stamp or submit a document to ZATCA.
Developer validation and non-production gateway checks are engineering evidence. Even a developer response labelled CLEARED cannot issue a customer tax invoice, activate production credentials or establish statutory acceptance.
The production source-document workflow, secure taxpayer EGS onboarding, clearance/reporting and verified live recovery are not released. Do not replace a working Saudi fiscal solution with this preparation workflow. A production launch requires those capabilities and genuine taxpayer activation to be completed and verified.
| Choice | When it fits | What it changes |
|---|---|---|
| Local preflight | Check selected XML fields without a network request. | No authority receipt or permission to issue. |
| Developer sandbox | Exercise a separate synthetic developer workflow. | Non-production evidence; no customer financial state changes. |
| Production acceptance | Verify the actual taxpayer, source document and live authority outcome. | Unavailable until the complete production integration is released and activated. |
Keep authority credentials with their legal entity#
An EGS private key, certificate, security token and onboarding code belong to a specific integration environment and business. Never paste them into a support message, demo extension reason or customer spreadsheet. Demo and developer credentials must remain separate from production.
Record credentials, validation evidence and production activation through the released secure integration workflow when it becomes available. Current integration requests collect the business requirement only and do not enable live filing.
Keep the active workspace, actual business requirements and current setup summary in view. A guide explains a choice; it does not make that choice for you.