Blog Overview
ZATCA cut the threshold to SAR 187,500 and added 2025 to the qualifying years. Here is who is in scope, what your system must do, and a 12-week plan before the deadline.
On 24 July 2026, ZATCA announced the criteria for Wave 25 of the e-invoicing integration phase. The news is not the wave number. It is the threshold cut to SAR 187,500 and the addition of 2025 to the qualifying years. That makes this the broadest wave so far, and it brings the deadline close to businesses that assumed the programme was not for them.
The date is 1 February 2027. A targeted business has roughly three months from today, not a year. That is enough time if you start now, and not enough if you wait for a notification that may arrive only six months before the deadline.
What ZATCA actually announced
The criterion is published on ZATCA’s site: Wave 25 covers every taxpayer whose VAT-subject revenue exceeded SAR 187,500 in any of 2022, 2023, 2024, or 2025. Integration starts on 1 February 2027. ZATCA notifies targeted taxpayers at least six months before the date.
| Item | Wave 24 | Wave 25 |
|---|---|---|
| Threshold | Above SAR 375,000 | Above SAR 187,500 |
| Qualifying years | 2022, 2023, 2024 | 2022, 2023, 2024, 2025 |
| Deadline | 30 June 2026 | 1 February 2027 |
| Impact | Mid-sized businesses | Small and mid-sized businesses, including 2025 startups |
Who is in scope for Wave 25
Three cases are worth checking. Do not rely on current turnover alone; the test looks at any of the four years.
You exceeded the threshold in any year from 2022 to 2025. Even if revenue fell afterwards, you remain in scope.
You were established in 2025 and exceeded the threshold. This is the first wave to count 2025, and it is the case many new businesses miss.
You did not exceed the threshold in 2022–2024 but did in 2025. Do not assume the earlier waves passed you by; check 2025 specifically.
The difference between phase one and phase two
Many businesses believe they are “ready” because they issue an e-invoice with a QR code. That covers phase one only. Phase two adds integration and real-time clearance, and the engineering impact is different.
| Area | Phase one: generation and storage | Phase two: integration |
|---|---|---|
| Format | An e-invoice with the required fields | UBL 2.1 XML, or PDF/A-3 with embedded XML |
| Connection | Not required | Direct API connection to Fatoora |
| Standard invoice | Generated and stored | Cleared in real time before sharing with the buyer |
| Simplified invoice | Generated and stored | Reported within 24 hours |
| Stamp | QR code | Cryptographic stamp and a hash chain that resists tampering |
What your system must actually do
It is not enough to have an “e-invoicing solution”. The solution must perform six functions, or manual work stays inside the process.
Generate valid XML with the additional phase-two fields, not just a visual template.
Sign the invoice with a cryptographic stamp and a hash sequence that links each invoice to the next.
Submit standard invoices for clearance before sharing them with the buyer, and handle rejections and warnings.
Report simplified invoices within 24 hours and keep the acknowledgement.
Retry after an outage without duplicating an invoice or breaking the sequence.
Log every attempt with the response, time, and user, because the log is what proves compliance in a review.
A 12-week plan before 1 February 2027
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
The plan below assumes you have not started and that an ERP or accounting system is already in place. If the process is fully manual, add two weeks to select and connect an e-invoicing solution.
| Weeks | Work | Output |
|---|---|---|
| 1–2 | Assess eligibility, list invoice types, review customer and tax data | A scope list and a data-gap list |
| 3–4 | Select a solution or assess the current one, register in the test environment | A solution decision and credentials |
| 5–7 | Configure fields, signing, QR, and the API connection | The first invoice passing in test |
| 8–9 | Test standard, simplified, credit, and debit documents | Documented test results |
| 10–11 | Pilot with one branch or one team | Real invoices under monitoring |
| 12 | Full cutover, error monitoring, rollback plan | Stable operation before the deadline |
Where integration projects fail
Failure is rarely in the connection itself. It shows up in the data and the exceptions nobody considered before testing.
Customer data is incomplete. A name, address, tax number, or document type is wrong. The invoice is rejected because the field was never required in the old system.
Only one document type is handled. The team tests a standard invoice, then simplified invoices, credit notes, and debit notes appear in week one.
No retry logic. A network drop means a lost or duplicated invoice, and both have a cost.
Testing only with clean data. Production carries mixed Arabic names, incomplete addresses, and duplicate numbers.
Nobody watches rejections. An invoice is rejected silently, and it surfaces in an audit or a client complaint.
Finance and engineering do not sit together. One knows tax, the other knows the API, and nobody owns the end-to-end process.
A checklist for evaluating an e-invoicing solution
Use this list in the demo. If the vendor cannot answer with evidence, the question is still open.
- Does it support UBL 2.1 XML and PDF/A-3 with embedded XML?
- Does it clear standard invoices in real time and report simplified invoices within 24 hours?
- Does it generate the cryptographic stamp and hash sequence, or depend on an external service?
- Does it handle credit and debit notes as separate document types?
- Does it retry without duplicating an invoice?
- Does it keep a full log of attempts and responses?
- Does it connect to the current ERP, and who owns data synchronisation?
- Is the interface Arabic and usable on a phone?
- What is the support agreement when invoices are rejected at month end?
- What is the exit cost, and who owns the data on termination?
What happens if you are late
E-invoicing is not an optional initiative. Missing the integration date, or issuing invoices in a format that is not accepted, exposes the business to penalties and delays collection. The operational impact can exceed the fine: an invoice that is not cleared is a receivable that is not paid.
Read the e-invoicing implementation resolution for the legal detail, and do not rely on an article summary. If you were in an earlier wave and have not integrated, the same remediation starts now.
The bottom line
Wave 25 is not a technical notice for accountants alone. It is a deadline that forces the business to know where the invoice is created, who signs it, how it reaches Fatoora, and what happens when it is rejected. Whoever answers those questions before November will be ready in February.
Sources
- ZATCA: Wave 25 criteria — 24 July 2026.
- E-Invoicing Implementation Resolution — format, stamp, clearance, and reporting.
- ZATCA Detailed Guideline — real-time clearance and 24-hour reporting.
- EY: Wave 25 analysis — Wave 24 vs Wave 25 comparison.
