Circumz
If you're running a business in Saudi Arabia, you've likely already run into the term "ZATCA e-invoicing," or its program name, FATOORA. This post is a plain-language overview of what it actually requires — and, just as importantly, what it doesn't automatically mean for whatever software you're using.
This is general information, not tax or legal advice. For anything binding — filing decisions, integration deadlines that apply to your business, or interpretation of a specific transaction — consult a qualified tax advisor and ZATCA's own published guidance directly.
What ZATCA e-invoicing is
ZATCA (the Zakat, Tax and Customs Authority) runs Saudi Arabia's electronic invoicing system, known as FATOORA. At a high level, it requires VAT-registered businesses to generate invoices in a structured electronic format rather than as free-form PDFs or paper documents, and — depending on phase and invoice type — to transmit or clear those invoices through ZATCA's platform.
The program has been rolled out in phases:
- Phase 1 (Generation) requires invoices to be generated electronically, in a structured format, with specific mandatory fields.
- Phase 2 (Integration) requires integration with ZATCA's platform for applicable invoice types — including real-time or near-real-time clearance or reporting, depending on invoice type.
Which phase and which specific requirements apply to a given business depend on factors like revenue threshold and rollout wave, which ZATCA determines and communicates directly. If you're unsure which applies to you, that's a question for your tax advisor or ZATCA directly — not something to assume from a blog post.
The document types that matter
ZATCA's e-invoicing framework distinguishes between several invoice types, and a system built for Saudi Arabia needs to model these as distinct concepts, not variations of one generic invoice:
| Type | Typical use |
|---|---|
| Tax Invoice | B2B transactions |
| Simplified Tax Invoice | B2C transactions |
| Credit Note | Adjustments that reference an original invoice |
| Debit Note | Adjustments that reference an original invoice |
| Prepayment Invoice | Invoices issued ahead of full delivery |
The distinction between Tax Invoice and Simplified Tax Invoice matters beyond terminology — they carry different mandatory fields and, for simplified invoices, specific QR code requirements.
What good software architecture looks like here
The most common mistake in Saudi-market software isn't inaccuracy — it's treating Saudi e-invoicing as a feature added on top of a generic international invoice, rather than as the primary design. In practice that shows up as:
- VATIN, Commercial Registration Number and bilingual (Arabic/English) address fields treated as optional extras instead of first-class fields on the company and customer record
- No real distinction between Tax Invoice and Simplified Tax Invoice document types
- Credit and debit notes that don't properly reference the original invoice
- No QR code generation for simplified invoices
If Saudi requirements are bolted on rather than designed in, they tend to stay incomplete — because every new invoice type or edge case requires reworking a data model that wasn't built for it.
Demo, sandbox, and "not yet live" — know the difference
Many systems, including early-stage or demo deployments, generate invoices in the correct structural format without actually submitting them to ZATCA's live platform. That's a completely normal stage of building or evaluating a system — but it should never be ambiguous. Any invoicing system that isn't actually connected to ZATCA's live platform should say so, clearly, on the document itself — something like "Demo — Not Submitted to ZATCA" — rather than looking indistinguishable from a fully compliant invoice.
If you're evaluating software and a vendor's invoices don't make this distinction obvious, that's worth asking about directly.
Nothing here should be read as a compliance certification for any specific product, including Vertex. Requirements, thresholds and rollout waves are set and updated by ZATCA directly — always confirm current requirements against ZATCA's own published materials.
The practical checklist
If you're assessing whether a system is built seriously for Saudi e-invoicing, a few concrete questions cut through the marketing:
- Does the data model distinguish Tax Invoice, Simplified Tax Invoice, Credit Note, Debit Note and Prepayment Invoice as separate types, or is it one generic invoice with a label?
- Are VATIN, CRN and bilingual address fields part of the core company and customer record?
- Are credit and debit notes required to reference the original invoice?
- Is it unambiguous, on the invoice itself, whether it was actually submitted to ZATCA or generated in a demo/sandbox mode?
Those four questions will tell you more about whether a system takes Saudi compliance seriously than any feature list.