ZATCA Phase 2: the integration checklist for Saudi businesses

If your business issues invoices in Saudi Arabia, you have already dealt with Phase 1 of e-invoicing. Phase 2 is a different kind of problem: it does not change what the document looks like, it changes where the document goes.

The two phases are two different problems

Phase 1 ("Generation"), live since 4 December 2021, is about the invoice itself: it must come out of a compliant electronic system, carry the mandatory fields, and — on simplified invoices — a QR code. No handwritten books, no scanned Word file.

Phase 2 ("Integration") is about the connection: your billing system talks to ZATCA's Fatoora platform on every single invoice — not at month end.

Phase 2 is rolled out in waves ordered by prior-year revenue, and ZATCA notifies each wave at least six months before its go-live date. If that letter has arrived, the clock is already running; if it has not, the work below is still the work — you just get to do it calmly. Confirm your own wave and its revenue threshold with the authority, not with an article.

Clearance or reporting: which one applies to you

This is the single distinction that decides your architecture, and it is decided by the invoice type — not by how big the customer is.

Most businesses issue both, which means both paths have to work — not just whichever one was easier to build.

What the invoice itself has to carry

• A structured XML document — UBL 2.1 as profiled by ZATCA — and, for a standard invoice, a human-readable PDF/A-3 with that same XML embedded inside it.
• A UUID for the document and an invoice counter value (ICV) that increments by exactly one, with no gaps, for the whole life of the issuing device or system.
• The previous invoice hash (PIH), which chains each invoice to the one before it. Break the chain and every invoice after the break is rejected.
• A cryptographic stamp produced with the certificate ZATCA issues to your system — not a certificate bought anywhere else.
• A QR code carrying the seller name, VAT registration number, timestamp, total including VAT and the VAT amount — plus the stamp and public key on simplified invoices.

Onboarding: how your system gets its certificate

1. 1Generate a key pair and a certificate signing request (CSR) on the system that will issue invoices, with the fields ZATCA specifies for your environment.
2. 2Get a one-time password from the Fatoora portal for the device or solution you are onboarding.
3. 3Exchange the CSR and OTP for a Compliance CSID — a temporary certificate that only works against the compliance checks.
4. 4Run the compliance checks: sample standard and simplified invoices plus their credit and debit notes, until every case passes.
5. 5Exchange the Compliance CSID for a Production CSID. That is the certificate that stamps real invoices.
6. 6Renew it before it expires, and re-onboard any system you rebuild or clone.

Prove the integration on the simulation environment first. A cleared simulation invoice is not a real filing — which is exactly why the environment exists.

The integration checklist

1. 1Confirm your wave. Read the notification and the revenue threshold it cites, and put the go-live date in the close calendar.
2. 2Inventory every system that issues an invoice — the ERP, the POS tills, the booking site, the spreadsheet someone still uses. Each one is either integrated or retired.
3. 3Clean the master data first: VAT registration numbers, seller address fields, item descriptions, unit codes. Clearance rejects on data quality far more often than on cryptography.
4. 4Fix the sequence owner: one system, one counter, one certificate per issuing device.
5. 5Map credit and debit notes. They carry the same requirements plus a reference to the original invoice and a reason for the adjustment.
6. 6Handle the failure paths deliberately: a rejection queue somebody actually watches, a retry policy, and a rule for what a cashier does when clearance is slow.
7. 7Test with your real catalogue, not the sample file — zero-rated lines, exempt lines, exports, rounding on three-decimal currencies, discounts at both line and document level.
8. 8Archive everything: six years of invoices with their XML, their stamps and the platform's responses — retrievable, not merely backed up.
9. 9Train the people who will read the rejection messages. They are precise, and they were not written for accountants.

Where teams actually get stuck

• Rounding. VAT calculated per line and then summed does not always equal VAT calculated on the total, and the tolerance is small. Pick one method, apply it everywhere, and reconcile the result.
• Timestamps. Issue times are checked; a device with a drifting clock or the wrong timezone produces invoices that fail validation for no visible reason.
• The 24-hour window for simplified invoices is a hard operational commitment, not a nightly batch that can slip over a long weekend.
• Arabic fields. The invoice is issued in Arabic; an English-only item description is a compliance gap, not a formatting preference.
• Copies. A reprinted invoice is the same invoice — reprinting must never mint a new UUID or a new counter value.

How Fatouraty handles it

Fatouraty produces the ZATCA-profiled UBL document, signs it with the business's own key and certificate, keeps the counter and the hash chain in a single owned sequence, and routes standard invoices to clearance and simplified ones to reporting without asking the user which is which — the invoice type decides. Without a key it refuses to transmit rather than sending an unstamped document the gateway would reject anyway.

Rejections land in a queue carrying the authority's own message alongside the entry that caused it — because a rejection message without the invoice line behind it is not actionable information.

Where to start

Start with the inventory and the master data. The cryptography is a solved problem you can buy; nineteen spreadsheets issuing invoices is not. Every hour spent cleaning VAT numbers and unit codes before you integrate saves a day of reading rejection messages afterwards.