Electronic invoice in Saudi Arabia

The Complete Guide to FATOORA and ZATCA Compliance: Ensuring seamless integration, mastering clearance rules, and avoiding penalties under the new Wave 25 thresholds.

Select a country

Overview

Saudi Arabia runs its own e-invoicing system, FATOORA, administered by the Zakat, Tax and Customs Authority (ZATCA). It is a centralised continuous transaction control model with a direct API between the taxpayer's system and the tax administration — not a Peppol four- or five-corner arrangement and not a decentralised network of accredited access points.

The distinctive feature is that the country runs two regimes at once. Standard tax invoices — used mainly in B2B and B2G — must be cleared by ZATCA before they reach the buyer. Simplified invoices, used mainly in B2C, are stamped by the seller's own system, handed over immediately, and reported to ZATCA within 24 hours. Delivery of the invoice to the buyer happens outside FATOORA entirely: it is a tax platform, not a delivery network.

SAR 187,500

the Wave 25 revenue threshold — half the level that applied under Wave 24

24 hours

the reporting window for simplified invoices, after they reach the customer

6 years

the retention period for the structured XML and its audit trail

Timeline

Two phases, then a long sequence of waves that keeps pulling the threshold down. The most recent announcement halved it again.

Already in force

4 December 2021

Phase 1 — the Generation Phase

Taxpayers must generate invoices and adjustment documents electronically in a compliant system, retain them with their associated data, and avoid prohibited functions that would allow deletion, alteration or backdating. It applies to persons within the Saudi VAT and e-invoicing regulations — excluding non-residents registered for Saudi VAT — and to third parties invoicing on a Saudi supplier's behalf.

1 January 2023

Phase 2 — the Integration Phase begins

Rolled out group by group. It adds mandatory integration of the invoicing system with FATOORA, API interaction, mandatory XML, UUIDs, an invoice counter and previous-invoice hash, CSID cryptographic certificates, clearance of standard invoices and reporting of simplified ones. ZATCA notifies each target group at least six months before its integration date.

30 June 2026

Wave 24 integration deadline

Announced on 26 September 2025 for taxpayers with VAT-subject revenue above SAR 375,000 in 2022, 2023 or 2024 — the ordinary VAT registration threshold, meaning Phase 2 had by then reached the bulk of registered Saudi VAT payers.

Still ahead

1 February 2027

Wave 25 — the threshold is halved

Announced on 24 July 2026. Taxpayers whose VAT-subject revenues exceeded SAR 187,500 in any of 2022, 2023, 2024 or 2025 must integrate with FATOORA by this date — half the Wave 24 level, and now testing a fourth year. See The waves and who is in.

There is no separate B2G start date in the FATOORA legislation. The tax invoice for most B2G transactions is classified exactly like a standard B2B invoice, so a supplier's obligation follows its own wave — not the identity of its customer.

The waves and who is in

Phase 1 applies to essentially everyone in scope of the Saudi VAT and e-invoicing regulations. Phase 2 arrives by wave, and each wave is defined by a revenue test over specified years.

Wave 24VAT-subject revenue above SAR 375,000 in 2022, 2023 or 2024 — integrate by 30 June 2026

Wave 25VAT-subject revenue above SAR 187,500 in 2022, 2023, 2024 or 2025 — integrate by 1 February 2027

Two things follow from the shape of these tests. First, the revenue test looks at any of the listed years, so a business whose turnover has since fallen can still be pulled in by an earlier year. Second, with Wave 25 the threshold has dropped to half the VAT registration threshold — Phase 2 is now reaching well below the level of business that Wave 24 captured.

For newly registered businesses, late registrations and special cases, the governing document is ZATCA's individual notification rather than a published wave criterion. Since notification comes at least six months ahead, an unexpected letter is a project trigger, not an emergency.

Clearance and reporting

After onboarding, the taxpayer's e-invoicing generation solution (EGS) talks directly to FATOORA over the API. The platform receives the XML, runs technical and business validations, returns a processing status, adds ZATCA's data on clearance, and stores the accepted document. Delivery to the buyer sits outside this exchange and is not controlled by FATOORA.

Standard invoice — clearance

Used mainly for B2B and B2G. The supplier builds the UBL XML, sends it through the Clearance API, ZATCA validates it, and on success applies a clearance stamp and generates or updates the QR code. The cleared document returns to the supplier — and only then may it go to the buyer.

A standard B2B or B2G document is valid only after ZATCA clearance. In substance this is real-time clearance, though the regulations use the word clearance rather than real-time reporting.

Simplified invoice — reporting

Used for most B2C sales. The seller's EGS applies the cryptographic stamp and QR code itself, the document can be handed to the customer immediately, and the XML goes to ZATCA through the Reporting API within 24 hours of issue.

ZATCA applies no stamp of its own on reporting, because the seller's system has already signed it. This is near-real-time reporting with a 24-hour ceiling — not prior clearance.

The technical controls

—A UUID, a sequential invoice counter and a hash of the previous invoice — a chain that makes gaps detectable

—A cryptographic stamp and a QR code

—CSID and Production CSID certificates for each registered invoicing unit

—A prohibition on altering or deleting an issued invoice — corrections go through a credit or debit note

—XML validation against the XSD, the EN 16931 business rules and the KSA rules

Each EGS unit — or a centralised server, depending on the architecture — is onboarded separately and receives its own CSID. For a multi-entity or multi-site client this is the design decision that shapes the whole integration.

B2G and Etimad

A supplier to the Saudi government issues the same Standard Tax Invoice as for any B2B sale, cleared through ZATCA in the same way. The obligation follows the supplier's own wave.

Etimad, the government's procurement and financial platform, handles the financial verification and payment side. It does not replace ZATCA's tax clearance, and submitting an invoice into Etimad discharges nothing under the e-invoicing regulations. Both steps happen, in that order.

Formats and EN 16931

The mandatory Phase 2 syntax is OASIS UBL 2.1 XML in ZATCA's invoice and credit note structure, following ZATCA's XML implementation standard. Saudi Arabia is one of the few non-European countries whose model is genuinely built on EN 16931 — which makes the differences more important, not less.

ZATCA's rule hierarchy

01 Saudi rules and business requirements

02 EN 16931 rules

03 Base UBL requirements

Where they conflict, Saudi rules override EN 16931, and EN 16931 overrides general UBL. ZATCA applies a customised subset of the EN 16931 rules and its own Saudi CIUS.

The correct characterisation is therefore: FATOORA leans on EN 16931 semantically and technically, but is a separate national specification with additional fields, security rules and tax requirements. An ordinary Peppol BIS Billing XML should never be assumed FATOORA-compliant without conversion and validation against the KSA rules.

On PDF: an ordinary PDF without embedded structured XML is not a compliant electronic invoice. A human-readable rendering may be given to the buyer — and Arabic rendering is part of the requirements — but the tax system must retain the structured XML.

Peppol in Saudi Arabia

Peppol is not a mandatory or principal channel. FATOORA is a centralised tax API, not a network of accredited access points, and no Saudi Peppol Authority or national electronic address scheme governs the mandate.

Peppol can be used as an additional channel for international delivery or format conversion — sending a European counterparty a document it can process. It is not official tax transport and it is no substitute for FATOORA clearance.

Export, import and GCC

Exporting from Saudi Arabia

Exports of goods and services are inside the e-invoicing regulations, including zero-rated exports. Where the supplier is in Phase 2, the export invoice is built in ZATCA UBL, cleared as a Standard Tax Invoice, and only then sent to the foreign buyer. The buyer's VAT or tax registration number may be absent — it is not mandatory on an export invoice — while customs and commercial evidence of export is retained to support zero rating. A PDF/A-3, a bilingual rendering or a converted copy in the buyer's national format may be provided; the Saudi XML and the clearance must be retained.

Importing goods

Imports are excluded from the transactions for which a supplier must generate a Saudi FATOORA invoice. The foreign supplier issues an ordinary commercial invoice; Saudi import VAT is evidenced primarily by the customs import declaration, the customs system data and the import VAT payment documents. A foreign supplier must not send its commercial invoice to FATOORA.

Reverse-charge services

Transactions taxed in Saudi Arabia under the reverse-charge mechanism are outside the e-invoicing scope. The foreign supplier issues an ordinary commercial invoice, and the Saudi buyer accounts for VAT under reverse charge, reflects it in its VAT return and keeps the contract, invoice and evidence of receipt. Sending such a foreign invoice into the Clearance API as an outgoing Saudi standard invoice is a mistake worth designing against.

Intra-GCC and the EU

Supplies between GCC states fall within FATOORA's scope to the extent the GCC Unified VAT Agreement and Saudi VAT legislation apply — for a Saudi supplier that means generating and clearing an export or cross-border Standard Tax Invoice, with the rate and required evidence depending on the actual VAT treatment and the state of GCC mechanism implementation.

ViDA

Intra-EU does not describe a Saudi–EU supply: for the Saudi supplier it is an export, for the EU buyer an import of goods or an acquisition of services from a third-country supplier. From 1 July 2030 ViDA governs EU VAT reporting, not FATOORA. Two parallel obligations can coexist — Saudi clearance for the supplier, and EU-side accounting or reporting for the buyer or for the supplier's own EU VAT registration — but neither replaces the other.

Requirements for providers

Entering Saudi Arabia is not an extension of existing Peppol connectivity. It requires a dedicated ZATCA/FATOORA connector, and the list below is the realistic minimum rather than a wish list.

—ZATCA UBL 2.1 mapping and the KSA CIUS business rules

—The Clearance API for standard invoices and the Reporting API for simplified ones

—CSID onboarding and certificate management

—Cryptographic stamping and QR code generation

—The invoice counter and the previous-invoice hash chain

—Arabic human-readable rendering

—The credit and debit note lifecycle, since issued invoices cannot be altered

—XML archiving with an audit trail

—Export invoice support, and correct exclusion of reverse-charge and import transactions

—A separate tenant and certificate model per Saudi VAT taxpayer

ZATCA supports this work properly, which is unusual and worth exploiting. It publishes an XML implementation standard, an electronic invoice data dictionary, security features implementation standards, a Java-based SDK and a web-based validator that lets non-technical users check an XML invoice, credit or debit note independently and share the result with developers. Build the validator into the delivery process rather than treating it as a one-off check.

Archiving

Electronic invoices and their associated data must be retained for six years, in an audit-ready form. Phase 1 already required retention in a compliant system with no prohibited functions permitting deletion, alteration or backdating — so in Saudi Arabia the archive is not a passive store but part of the control regime itself.

What is retained is the structured XML, together with the clearance response for standard invoices — a PDF rendering is not the record

The hash chain and invoice counter must remain intact and verifiable — a gap in the sequence is itself evidence

Credit and debit notes belong with the invoices they correct, since correction by amendment is prohibited

Note that failing to retain in the prescribed format is itself an e-invoicing violation, listed alongside failing to issue electronically — see Penalties.

Penalties

The e-invoicing violations include failing to issue or retain invoices electronically, not observing the prescribed retention format, a missing mandatory QR code, failing to notify ZATCA of an invoicing system malfunction, using prohibited functions, and deleting or altering an invoice after issue.

The escalating scale

First detectionA warning

First repetitionSAR 1,000

Second repetitionSAR 5,000

Third repetitionSAR 10,000

Fourth repetitionSAR 40,000

Repetition is assessed over a twelve-month period: if more than twelve months have passed since the last detection, a new violation can be treated as a first offence again. ZATCA may also allow a period to remedy the breach.

The general VAT penalties still apply

—Issuing a tax invoice by an unregistered person — up to SAR 100,000

—Failing to retain tax invoices, books and accounting documents — up to SAR 50,000

—Breach of the VAT Law or Regulations — up to SAR 50,000

—An incorrect VAT return reducing the tax due — up to 50% of the difference

—Tax evasion — from the unpaid VAT up to three times the value of the goods or services concerned

A repeat violation within three years of a final ZATCA decision can double the general penalty.

Do not rely on the amnesty. ZATCA extended its Cancellation of Fines and Exemption of Financial Penalties Initiative to 31 December 2026, but the current guidance covers mainly late registration, late payment, late filing and VAT return correction penalties. It contains no general automatic waiver of technical e-invoicing field violations, and penalties under Article 45 of the VAT Law are excluded from the initiative.

Input VAT

For transactions within the e-invoicing regulations, it is the electronic invoices generated in the prescribed formats, timings and integration phases that count as tax invoices for the purpose of deducting input VAT.

What that means once your supplier is in Phase 2

—A manual invoice is not a valid outcome

—A standard invoice that has not been cleared creates a serious risk of the deduction being refused

—The buyer must obtain and retain the cleared invoice

—A PDF without embedded XML should not be treated as sufficient standalone evidence

For an ordinary transaction covered by FATOORA and Phase 2, a compliant and — where required — cleared electronic invoice is the principal and regulatorily required evidence of the right to deduct. The general VAT Regulations do allow certain alternative evidence, such as a correctly issued Simplified Tax Invoice or other commercial documents in special cases. Those are limited exceptions, not a routine substitute for the mandatory e-invoice.

How we help

Saudi Arabia needs a dedicated connector, but its EN 16931 foundation means a European semantic model is a genuine starting point rather than a dead end:

Mapping into ZATCA UBL 2.1 with the KSA CIUS and the Saudi-over-EN-16931 rule hierarchy applied correctly

Clearance API for standard invoices, Reporting API for simplified ones, with the 24-hour window enforced

CSID onboarding, certificate lifecycle and a per-taxpayer tenant model

Cryptographic stamping, QR codes, the invoice counter and the previous-invoice hash chain

Arabic rendering, and PDF/A-3 or converted copies for the foreign buyer alongside the Saudi original

Correct exclusion of imports and reverse-charge services from the clearance flow

Connection by API, SFTP and CSV, with ERP and IDoc source data

Frequently asked questions

Is e-invoicing mandatory in Saudi Arabia?

Yes. Phase 1, requiring electronic generation and retention, has applied since 4 December 2021 to persons within the Saudi VAT and e-invoicing regulations — excluding non-residents registered for Saudi VAT — and to third parties invoicing on a Saudi supplier's behalf. Phase 2, the integration with FATOORA, has been rolling out by wave since 1 January 2023. Wave 24 required integration by 30 June 2026 at SAR 375,000, and Wave 25 brings the threshold down to SAR 187,500 with a deadline of 1 February 2027.

Must the invoice be cleared before I send it to the buyer?

For a standard invoice, yes. Used mainly in B2B and B2G, it goes through the Clearance API, ZATCA validates it and applies a clearance stamp and QR code, the cleared document returns to you, and only then may it go to the buyer — it is valid only after clearance. A simplified invoice, used for most B2C sales, works the other way round: your own system stamps it, the customer gets it immediately, and the XML is reported to ZATCA within 24 hours.

Am I in Wave 25?

If your VAT-subject revenues exceeded SAR 187,500 in any of 2022, 2023, 2024 or 2025, you must integrate with FATOORA by 1 February 2027. Announced on 24 July 2026, this halves the Wave 24 threshold and adds a fourth test year — so a business whose turnover has since fallen can still be caught by an earlier year. For new registrations and special cases, ZATCA's individual notification governs, and it arrives at least six months before the deadline.

Does a Peppol BIS invoice comply with FATOORA?

No — not without conversion and validation against the KSA rules. FATOORA is built on EN 16931 but is a separate national specification with additional fields, security rules and tax requirements. ZATCA applies an explicit hierarchy: Saudi rules override EN 16931, which overrides base UBL, and it uses a customised subset of the EN 16931 rules plus its own Saudi CIUS. Peppol itself is not a mandatory or principal channel and no Saudi Peppol Authority exists.

Do I invoice imports and reverse-charge services through FATOORA?

No, and doing so is a design error worth guarding against. Imports of goods are excluded from the transactions requiring a Saudi FATOORA invoice — the foreign supplier issues an ordinary commercial invoice and Saudi import VAT is evidenced by the customs import declaration, customs system data and import VAT payment documents. Reverse-charge services are likewise outside scope: the Saudi buyer accounts for the VAT and keeps the contract, invoice and evidence of receipt. Neither foreign invoice should be sent to the Clearance API.

Can I still give the buyer a PDF?

As a rendering, yes. An ordinary PDF without embedded structured XML is not a compliant electronic invoice, but a human-readable representation may be provided to the buyer — with Arabic rendering part of the requirements — while the tax system retains the structured XML. On exports you may additionally supply a PDF/A-3, a bilingual rendering or a copy converted into the buyer's national format, provided the Saudi XML and its clearance are retained.

How long must invoices be kept, and in what form?

Six years, audit-ready, and as the structured XML together with the clearance response for standard invoices — not as a PDF rendering. The hash chain and invoice counter must remain intact and verifiable, and credit and debit notes belong with the invoices they correct, since amending an issued invoice is prohibited. Note that failing to retain in the prescribed format is itself a listed e-invoicing violation, not merely a bookkeeping lapse.

What are the penalties, and does the amnesty cover them?

E-invoicing violations escalate: a warning on first detection, then SAR 1,000, SAR 5,000, SAR 10,000 and SAR 40,000 on successive repetitions, assessed over a rolling twelve months — after more than twelve months a new violation can count as a first offence again, and ZATCA may allow a remedy period. General VAT penalties run alongside, up to SAR 100,000 for invoicing while unregistered and up to three times the value of goods or services for evasion. ZATCA's fines cancellation initiative runs to 31 December 2026, but it covers mainly late registration, payment and filing — not a general waiver of technical e-invoicing violations.

Summary

Saudi Arabia is a centralised clearance country running two regimes side by side: prior clearance for standard B2B and B2G invoices, 24-hour reporting for simplified B2C ones. FATOORA is a tax API rather than a delivery network, so getting the invoice to the buyer remains entirely the supplier's job — after clearance, in the standard case.

The scope keeps widening. Wave 24 reached the ordinary VAT registration threshold by 30 June 2026, and Wave 25 — announced in July 2026 — halves it to SAR 187,500 with a deadline of 1 February 2027. Since the revenue test looks at any of four years, businesses well below today's turnover are being drawn in.

For a European provider this is the most transferable of the non-European clearance markets — FATOORA is genuinely built on EN 16931 — but it is still a separate connector, not a Peppol extension. What has to be built is CSID onboarding, cryptographic stamping, the hash chain, Arabic rendering, and both APIs. ZATCA's own SDK and web validator make that materially easier than in most clearance countries; use them from the start.

Resources

ZATCA — E-Invoicing (FATOORA) The official hub for the two phases, the wave announcements and the taxpayer guidance ZATCA — Systems Developers The XML implementation standard, the data dictionary, the security features standard, the SDK and the web validator ZATCA Developer Portal and sandbox Where an EGS is built and tested against the compliance requirements before touching production E-Invoicing Detailed Technical Guideline (PDF) The technical reference behind clearance, reporting, CSID onboarding and the cryptographic requirements ZATCA — e-invoicing guidelines library The FATOORA portal manual, the detailed guidelines and the official FAQ Zakat, Tax and Customs Authority The authority itself — wave announcements, VAT rules, penalties and the fines cancellation initiative

Need support with e-invoicing compliance?

As a certified Peppol Access Point we provide solutions for sending and receiving electronic invoices securely across Europe — including format conversion, validation and integration with national systems.

Start your free trial