If your VAT-subject revenue exceeded SAR 187,500 in 2022, 2023, 2024 or 2025, you are in Wave 25 of ZATCA's e-invoicing Integration Phase, and your invoicing system has to be integrated with the Fatoora platform by 1 February 2027. One qualifying year out of the four is enough. You do not fall out of scope because last year was quieter.
That is the whole eligibility test. The rest of this article is about what the deadline actually asks of your engineering team, because "integrate with Fatoora" is doing a lot of work in that sentence.
This is engineering context, not tax advice. Whether your entity is in scope, and on what basis, is a question for Saudi-qualified tax counsel. What follows is what the obligation does to your systems once counsel says yes.
What changed, and why this wave is different
ZATCA announced the Wave 25 criteria on 24 July 2026. The threshold is SAR 187,500 — half of Wave 24's SAR 375,000, which itself was the lowest to date. Wave 24's own deadline, 30 June 2026, has already passed.
Halving the threshold is not a routine increment. It is the point at which the Integration Phase stops being an enterprise-ERP problem and becomes a small-business software problem. SAR 187,500 of annual VAT-subject revenue is a single-branch retailer, a design studio, a two-van logistics operation. These are businesses whose "invoicing system" is frequently a spreadsheet, a point-of-sale terminal from a vendor who may or may not still be trading, or a WordPress plugin.
The engineering consequence: the population now entering Phase 2 is the one least likely to have an integration path already, and most likely to discover in December 2026 that their POS vendor has no answer. If you build or sell software that issues invoices in Saudi Arabia, your customers are about to ask you this question all at once.
Phase 1 compliance does not carry over
The most expensive misunderstanding we see is a business that went through Phase 1 — the Generation Phase — concluding it has already done this.
Phase 1 asked you to stop writing invoices by hand and produce them electronically, with a QR code on simplified invoices. Many businesses satisfied it by turning on a feature their existing software already had.
Phase 2, the Integration Phase, is a different category of work:
- Invoices must be XML (or PDF/A-3 with the XML embedded), in ZATCA's implementation standard — not your own format, not a PDF that looks right.
- Your solution must be onboarded with ZATCA and hold a Cryptographic Stamp Identifier (CSID).
- Every invoice carries a cryptographic stamp, a UUID, a tamper-resistant counter, and the hash of the previous invoice.
- Invoices must reach Fatoora over an API — B2B invoices before they go to the buyer, B2C invoices within 24 hours.
None of that is a setting. It is an integration, and the part that surprises teams is that it changes the invoice lifecycle, not just the invoice document. We cover the full mechanics in our ZATCA Phase 2 integration guide.
The two flows, and which one you are building
Your architecture depends on which invoices you issue, and most businesses issue both.
Standard tax invoices (mostly B2B) go through Clearance. You submit the XML to Fatoora and wait. Fatoora validates it against the implementation standard, runs referential checks, and — if it passes — adds the cryptographic stamp and the QR code itself, returning a "cleared" XML. That cleared document is what you give the buyer. Clearance sits in front of invoice delivery, which means Fatoora is now a synchronous dependency in your sales flow.
Simplified tax invoices (mostly B2C) go through Reporting. Your own solution stamps the XML with its CSID and applies the QR code, you hand the customer their invoice immediately, and you report the XML to Fatoora within 24 hours. The customer never waits on ZATCA.
One rule worth knowing because it is easy to get backwards: you may issue a simplified invoice for a B2B transaction only when taxable supplies are under SAR 1,000. B2C simplified invoices have no such ceiling.
The design implication is that a retail business with a trade counter needs both paths, and needs to decide which one a given sale takes at the moment of sale. We go through the architectural consequences in clearance versus reporting.
What "by 1 February 2027" really means
Read the deadline as a date by which you must be live and stable, then work backwards. A realistic ordering:
1. Confirm scope with your tax adviser. Four candidate years, any one of which can catch you.
2. Decide build or buy. A ZATCA-certified solution provider is a legitimate answer, especially for a single, simple billing flow. Building is the right call when invoices originate in a system you control and care about.
3. Onboard in ZATCA's sandbox and get through compliance checks. This is where you discover which of your invoice shapes ZATCA dislikes.
4. Fix your data before you fix your code. Most first-attempt rejections are not integration bugs. They are missing seller address fields, VAT numbers of the wrong length, item lines with no name, tax rates stored as 15% rather than 15.00.
5. Run in production alongside your existing process long enough to see a month-end, a credit note, and a refund.
Steps 3 and 4 are the ones that consume the calendar. Teams routinely budget for the API call and are surprised by the data cleanup, which touches the customer master, the item catalogue and the company's own registration details.
The failure that costs the most to unwind
Worth stating on its own, because it is the one that is expensive to fix after go-live: a rejected invoice still consumes its counter value and its place in the hash chain.
ZATCA's guideline is explicit that every document has its own hash and counter value, and that a rejected document's hash and counter value must not be changed or updated. If a clearance call returns a 400, you correct the data and submit a new document with the next counter value. You do not reuse, roll back, or renumber.
Systems that treat a rejection as "nothing happened" and retry with the same counter produce a chain with duplicates. Systems that skip the failed number produce gaps. Both are discoverable at audit, and neither can be repaired retroactively, because the chain is cryptographic — every later invoice commits to the one before it. We go through this and the other structural traps in the invoice counter and hash chain.
If you sell software into Saudi Arabia
Wave 25 is a commercial event for you, not just a compliance one. Your customers below the old threshold are now in scope, they have until 1 February 2027, and a meaningful share of them will change vendor rather than wait for you.
The work is a bounded, well-specified integration — ZATCA publishes the standard, the sandbox and the validation rules. What is not bounded is the long tail of invoice shapes your product allows that ZATCA will not accept: zero-rated lines, exports, advance payments, credit notes without a parent, discounts expressed as percentages. Find those now, against the sandbox, rather than in January.
Frequently asked questions
Does one qualifying year put me in scope, or do I need all four?
One. The criteria cover taxpayers whose VAT-subject revenue exceeded SAR 187,500 during 2022, 2023, 2024 or 2025.
I was not in any earlier wave. Am I automatically in Wave 25?
Not automatically — it depends on your revenue against this threshold. ZATCA notifies targeted taxpayers directly, but do not treat "no letter yet" as confirmation you are out of scope. Check with your tax adviser.
Is Wave 26 announced?
No wave beyond 25 had been announced as of 22 September 2026. Given the trajectory of the thresholds, expect the remaining population to be brought in rather than exempted.
We already comply with Phase 1. Is there anything to do?
Yes — effectively all of it. Phase 1 is about generating electronic invoices. Phase 2 adds XML in ZATCA's standard, onboarding, a cryptographic stamp, the hash chain, the counter and live API submission.
Can we keep issuing PDFs to customers?
You can share PDF/A-3 with the XML embedded, and buyers who can process XML may take the XML directly. What you submit to Fatoora is always XML, never PDF/A-3.
What happens if we miss 1 February 2027?
Penalties are a matter for ZATCA and your tax adviser, not for us to quantify. The engineering point is that the remediation work does not shrink after the deadline — it is the same integration, done under pressure.
Do we need a Saudi entity to integrate?
Onboarding is done by the taxpayer, so the VAT-registered entity is the one that onboards. A development partner can build and operate the integration; it is the taxpayer's solution that is onboarded and stamped.
Sources
- ZATCA — Criteria for the Twenty-Fifth Wave, Integration Phase (announced 24 July 2026)
- ZATCA — Detailed Guidelines for E-Invoicing (PDF)
- ZATCA — E-invoicing roll-out phases
- ZATCA — Criteria for the Twenty-Fourth Wave
Again: engineering context, not tax advice. Confirm your own scope and obligations with Saudi-qualified counsel.