Circumz
This guide expands on Saudi Arabia e-invoicing and ZATCA: what businesses need to know into a fuller reference. It is general information intended to help you evaluate systems and ask informed questions — it is not tax or legal advice, and it does not substitute for ZATCA's own published guidance or a qualified tax advisor's review of your specific situation.
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 advisor — this guide describes the shape of the system, not your specific 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 a system treats these as free-text notes rather than structured fields, generating a compliant invoice reliably becomes difficult — and worse, error-prone in ways that are hard to catch after the fact.
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 generating simplified invoices needs to produce this QR code correctly as part of the invoice, not as an optional add-on.
5. Credit and debit note integrity
Because credit and debit notes must reference the original invoice, the data model needs an explicit link between them — not just a matching amount or a manually typed reference number. Ask any vendor directly: if I issue a credit note, is it structurally linked to the original tax invoice, or is that connection just a text field someone fills in?
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
It's common, and reasonable, for a system to support generating invoices in the correct structural format without actually transmitting them to ZATCA's live platform — particularly during evaluation or early deployment. What matters is that this distinction 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. 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 — go to ZATCA's own published documentation, or a qualified Saudi tax advisor, rather than any third-party summary, including this one.