ZATCA e-invoicing, Phase 2, explained by what your system has to do

Which wave you are in

Wave 24 caught taxpayers whose VAT-subject revenue exceeded SAR 375,000 in 2022, 2023 or 2024, with an integration deadline of 30 June 2026. That date has passed and enforcement has been live since 1 July 2026.

Wave 25 halves the threshold to SAR 187,500, tested across 2022 to 2025, with an integration deadline of 1 February 2027. At that level the great majority of trading companies in the Kingdom are in scope. The Cancellation of Fines initiative, extended a second time, closes on 31 December 2026, and ZATCA's published fines start at SAR 5,000 for not issuing e-invoices and SAR 10,000 for deleting or amending them, with some violations starting at a warning and fines rising with repeats.

Those are the published criteria. Your binding wave is the one in the notification ZATCA sends you, and it is worth checking that letter rather than working from a threshold alone.

• Wave 24: over SAR 375,000, integrate by 30 June 2026, deadline passed
• Wave 25: over SAR 187,500, integrate by 1 February 2027
• Fine relief closes 31 December 2026
• Fines start at SAR 5,000, or SAR 10,000 for altered invoices

Standard and simplified are two different flows

A standard invoice, the business to business case, is cleared: it goes to ZATCA before you share it with the buyer, and what you send the buyer is the cleared document. A simplified invoice, the consumer case, is reported within twenty four hours of issue and carries a QR code the customer can scan at the counter.

The practical consequence for a retailer is that clearance sits in the critical path of a B2B sale and reporting does not sit in the critical path of a B2C one. Systems that treat both the same tend to fail in the direction of holding up a sale.

The hash chain, and why it matters more than the XML

Each invoice carries the hash of the previous invoice in its chain. The first invoice uses ZATCA's documented genesis value. Change any figure on an invoice and its hash changes, which changes the hash of every invoice issued after it. Delete one and the chain has a gap.

That single mechanism is what turns e-invoicing from a reporting obligation into an audit control. It is also the part that catches companies out, because it means invoice issuance has to be sequential and durable rather than something a point of sale can retry casually.

The QR code is five tags, not a picture

The QR on a simplified invoice encodes a TLV payload: seller name, VAT registration number, invoice timestamp, total including VAT, and the VAT amount. Five tags, each with its byte length, base64 encoded. An Arabic seller name is measured in bytes rather than characters, which is where naive implementations truncate and stop being readable.

There is an interactive version of this on the ProCul home page. Type three fields and watch the XML, the hash chain and the QR assemble in the browser.

There is no pull API, and that shapes everything

Fatoora is push only. There is no public endpoint that returns a company's own invoices. Any service claiming to reconcile your books from ZATCA is describing something that does not exist. Invoice data has to come from the system that issued the invoice, which is why ProCul reads your accounting ledger and issues through your own credentials rather than trying to read back from the platform.