This guide extends the short ZATCA overview. It is general information to help you evaluate systems and ask good questions. It is not tax or legal advice and does not replace ZATCA's own guidance or a tax adviser's review of your case.
1. Background
ZATCA (the Zakat, Tax and Customs Authority) administers Saudi Arabia's electronic invoicing system, publicly branded as FATOORA. The program requires VAT-registered businesses to issue invoices in a structured electronic format, with additional integration requirements phased in over time for applicable businesses and invoice types.
The rollout has proceeded in two broad phases:
- Phase 1 — Generation. Invoices must be generated electronically in a structured format with mandatory fields, rather than as unstructured PDFs, images or paper.
- Phase 2 — Integration. Applicable invoices must be integrated with ZATCA's platform — involving clearance or reporting workflows depending on invoice type — with technical and timing requirements ZATCA communicates to businesses directly, typically in waves based on revenue thresholds.
Because thresholds, waves and specific technical requirements are set and updated by ZATCA, always confirm current obligations against ZATCA's own published materials or a tax adviser. This guide describes the shape of the system, not your own compliance deadline.
2. Document types
A system built seriously for Saudi e-invoicing needs to model these as genuinely distinct document types, not variants of one generic invoice:
Tax Invoice. Used for B2B (and generally B2G) transactions. Carries the full set of mandatory fields, including buyer and seller VAT registration details.
Simplified Tax Invoice. Used for B2C transactions, typically point-of-sale style. Carries a reduced but still specific field set and mandatory QR code content.
Credit Note. Issued to reduce the value of a previously issued invoice — must reference the original invoice.
Debit Note. Issued to increase the value of a previously issued invoice — must reference the original invoice.
Prepayment Invoice. Issued for payment received ahead of full goods or service delivery — structurally distinct from a standard tax invoice.
3. Core data requirements
Regardless of invoice type, the underlying business records need to support specific fields that many generic (non-Saudi-first) systems treat as optional:
Company (seller) record:
- Legal name and Arabic legal name
- VAT registration number (VATIN)
- Commercial Registration Number (CRN)
- Full address, including building number, street, district, city, postal code — in both Arabic and English
- Default VAT rate and currency (SAR)
Customer (buyer) record, where applicable:
- Legal name and Arabic legal name
- VAT registration number, where the customer is VAT-registered
- Full bilingual address
- Tax status classification
If these are free-text notes instead of structured fields, producing a correct invoice is unreliable, and errors are hard to catch afterwards.
4. QR codes on simplified invoices
Simplified tax invoices carry a mandatory QR code encoding a defined minimum set of invoice information, intended to let the code be scanned and verified. A system issuing simplified invoices has to produce the QR as part of the invoice, from the invoice data, not as a value someone types.
5. Credit and debit note integrity
Credit and debit notes must reference the original invoice, so the data model needs an explicit link, not a matching amount or a typed reference. Ask the vendor: if I issue a credit note, is it linked to the original tax invoice in the data, or is that a text field?
6. Phase 2 integration considerations
For applicable invoices under Phase 2, integration with ZATCA's platform involves technical requirements — including invoice signing, specific XML/UBL-based formatting, and clearance or reporting workflows — that go well beyond generating a correctly formatted document. If a vendor claims Phase 2 integration, it's reasonable to ask specifically how invoices are transmitted, what happens on a clearance failure, and how that's surfaced to your team.
7. Demo and sandbox modes
A system can generate invoices in the correct structure without transmitting them to ZATCA's live platform, particularly during evaluation or early deployment. What matters is that the difference is never ambiguous. A demo or sandbox invoice should be clearly labelled as such on the document itself (for example, "Demo — Not Submitted to ZATCA"), so nobody downstream mistakes it for a live, compliant invoice.
This guide describes the general shape of Saudi e-invoicing requirements as a reference for evaluating software. It is not a substitute for ZATCA's own current published guidance, and nothing here should be read as confirming compliance certification for any specific product.
8. A checklist for evaluating any Saudi-market invoicing system
| Requirement | What to check |
|---|---|
| Document types | Tax Invoice, Simplified Tax Invoice, Credit Note, Debit Note and Prepayment Invoice modeled as distinct types |
| Company/customer fields | VATIN, CRN, bilingual address as structured fields, not free text |
| Credit/debit note linkage | Structural reference to the original invoice, not just a manual note |
| QR codes | Generated automatically for simplified tax invoices |
| Phase 2 integration | Specific description of signing, formatting and clearance/reporting workflow, if claimed |
| Demo/sandbox labelling | Unambiguous on the invoice document itself |
9. How Circumz handles each point
| Topic | Circumz today |
|---|---|
| Document types | Tax, simplified, credit note, debit note and prepayment, as distinct types |
| Seller and buyer data | VAT number, CR number and bilingual address as structured company and customer fields |
| Issued invoices | Immutable, with a sequence and a hash chain linking each to the previous |
| Output | UBL XML and a QR code generated from the invoice data |
| Credit and debit notes | Linked to the original invoice |
| Submission | Demo mode, labelled on the document. It never reaches ZATCA's live platform |
| Currency | SAR only for Saudi sellers. A foreign-currency invoice from a Saudi seller is refused |
| Point of sale | Retail receipts are sales receipts, not simplified tax invoices |
| Other countries | Plain numbered tax invoices with a per-rate breakdown, never described as filed |
Circumz does not claim ZATCA certification.
10. Where to go for authoritative information
Requirements, thresholds and technical specifications change as ZATCA updates the program. For anything you intend to rely on — a compliance deadline, a specific field requirement, an integration specification — use ZATCA's own published documentation or a qualified Saudi tax adviser, not a third-party summary, including this one.