If you run a business in Saudi Arabia you will have met the term ZATCA e-invoicing, or its programme name, FATOORA. This post explains what it asks of an invoice and what to check in the system that produces yours.
This is general information, not tax or legal advice. Which requirements apply to you, and from when, is set by ZATCA. Confirm it with a tax adviser or ZATCA's own published material.
What the programme requires
ZATCA, the Zakat, Tax and Customs Authority, requires VAT-registered businesses to issue invoices in a structured electronic format instead of free-form PDFs or paper. It came in two phases:
- Phase 1, generation. Invoices are produced electronically with a defined set of mandatory fields.
- Phase 2, integration. Applicable invoices are connected to ZATCA's platform, with clearance or reporting depending on the invoice type, in waves set by ZATCA.
Document types are separate things
A Saudi system should treat these as distinct documents, not one invoice with a label:
| Type | Typical use |
|---|---|
| Tax invoice | Business-to-business sales |
| Simplified tax invoice | Business-to-consumer, point-of-sale style |
| Credit note | Reduces a previous invoice, must reference it |
| Debit note | Increases a previous invoice, must reference it |
| Prepayment invoice | Billed ahead of delivery |
The first two are not just differently named. They carry different mandatory fields, and simplified invoices need a QR code.
Where systems usually go wrong
The common mistake is building a generic international invoice and adding Saudi fields later. It shows up as:
- VAT number, commercial registration number and Arabic and English addresses held as optional notes.
- No real difference between tax and simplified invoices.
- Credit notes that have a matching amount but no structural link to the original.
- No QR code, or a QR typed in by hand.
Be clear about what has been filed
A system can produce a correctly structured invoice without sending it to ZATCA. That is normal during evaluation or early rollout. What matters is that the document says so. A demo invoice should read something like "Demo, not submitted to ZATCA" on its face, so nobody mistakes it for a filed one.
Nothing here certifies any product, including Circumz. Requirements and rollout waves change, so confirm against ZATCA's current published guidance.
How Circumz handles it today
For a Saudi seller invoicing in SAR, Circumz issues tax invoices, simplified tax invoices, credit notes, debit notes and prepayment invoices. Each is immutable once issued, chained to the previous one by hash, has UBL XML and a QR code generated from the invoice data, and credit and debit notes are linked to the invoice they adjust. Submission runs in a labelled demo mode and never reaches ZATCA's live platform.
Two limits matter. Saudi sellers cannot issue foreign-currency invoices, because ZATCA's currency rules are not implemented. And receipts from Retail are sales receipts, not simplified tax invoices.
Outside Saudi Arabia, Circumz issues plain numbered tax invoices with a per-rate breakdown. They are never presented as filed with a tax authority.
Four questions to put to any vendor
- Are tax, simplified, credit, debit and prepayment documents separate types?
- Are VAT number, CR number and bilingual addresses structured fields on the company and the customer?
- Does a credit note reference the original invoice in the data, not in a text box?
- Is it obvious, on the invoice itself, whether it was submitted or generated in demo mode?
For a longer treatment see the ZATCA compliance guide.