ZATCA E-Invoicing Wave 25: What Product and Engineering Teams Must Ship Before 1 February 2027 (Fatoora Phase 2 Checklist)

The short answer

ZATCA e-invoicing Wave 25 is the Saudi Zakat, Tax and Customs Authority's 24 July 2026 decision to pull every taxpayer whose VAT-subject revenue exceeded SAR 187,500 in any year from 2022 to 2025 into Phase 2, the "Integration Phase", with the Fatoora platform. ZATCA says it will notify each business directly and that integration is due by 1 February 2027. For product and engineering teams, that is a build with hard edges: B2B invoices must be cleared by ZATCA before the buyer receives them, B2C invoices must be reported within 24 hours, every device or server that issues invoices needs its own certificate, and every document is locked into a hash chain that cannot be edited, deleted or restarted. Treat it as a product, not a tax setting.

Key facts, with dates and primary sources

• 4 December 2021: Phase 1, the "Generation Phase", starts. Taxpayers stop issuing handwritten or spreadsheet invoices and must generate and store e-invoices with required fields, including a QR code. (ZATCA, Wave 25 announcement)
• 26 September 2025: ZATCA announces Wave 24: VAT-subject revenue above SAR 375,000 in 2022, 2023 or 2024, integration no later than 30 June 2026. (ZATCA, Wave 24 announcement)
• 24 July 2026: ZATCA announces Wave 25: all taxpayers with VAT-subject revenue above SAR 187,500 during 2022, 2023, 2024 or 2025. One qualifying year is enough. (ZATCA, Wave 25 announcement)
• 1 February 2027: the integration date ZATCA gives for Wave 25. Later waves will be notified at least six months before their date. From 24 July 2026 to 1 February 2027 is a little over six months. (ZATCA, Wave 25 announcement, English; Arabic)
• What Phase 2 adds: integrate the invoicing solution with Fatoora, issue e-invoices in a specific format, and include additional fields. (ZATCA, Wave 25 announcement)
• Clearance and reporting: tax invoices (B2B) follow the clearance model, simplified tax invoices (B2C) follow the reporting model, within 24 hours. (ZATCA, E-invoicing Detailed Technical Guidelines v2, Nov 2022)
• Format and security: UBL 2.1 XML under the XML Implementation Standard and Data Dictionary (19 May 2023); XAdES cryptographic stamp, TLV-encoded Base64 QR code and OAuth 2 basic authentication under the Security Features Implementation Standards (v1.2, 19 May 2023). (XML standard; Security standards)

A reading note: "no later than" or "starting from"?

Read the two language versions of ZATCA's Wave 25 announcement side by side. The English text says ZATCA will notify taxpayers to integrate "by no later than February 1, 2027". The Arabic text says the notified businesses will connect their systems to Fatoora with the phrase "ibtida’an min 1 February 2027", which reads as "starting from 1 February 2027". Both are ZATCA's own wording of the same day. The first sounds like a deadline you can beat; the second sounds like a start date you must be ready for. The safe product decision is the same either way: be live and tested before 1 February, because a deadline and a start date both punish a team that is still onboarding on the day. Then keep the notice ZATCA sends you, because that notice, not a news article, is your reference date.

Are you in Wave 25? A five-minute test

1. List your VAT-subject revenue for 2022, 2023, 2024 and 2025 as four separate numbers.
2. If any one of them is above SAR 187,500, you are in scope, even if revenue has since fallen.
3. Check your ZATCA account and registered email for the notice, because ZATCA says it will notify each targeted taxpayer.
4. If you were above SAR 375,000 in 2022, 2023 or 2024, you were already in Wave 24 or earlier, so this article is not about your first deadline.
5. If you sell software or run a platform for merchants, ask each merchant for their notice date, because your customers' dates become your support calendar.

Law-firm and adviser summaries add that SAR 187,500 is the voluntary VAT registration threshold, so Wave 25 reaches small and voluntarily registered businesses. Treat that as context, not as a rule, and confirm your own position with your tax adviser.

Phase 1 versus Phase 2: what actually changes in the product

• Phase 1 is local. Your system generates, stores and shows a compliant invoice with a QR code. ZATCA does not receive it in real time.
• Phase 2 is a live conversation with a government API. Your system must onboard with ZATCA, hold a certificate, sign every invoice, send XML to Fatoora and handle three answers: valid, accepted with warnings, or rejected.
• The invoice becomes a chain. Each invoice carries a counter and the hash of the previous invoice, so one missing or edited document breaks every document after it.
• Time matters. B2B invoices wait for ZATCA before they can be handed over. B2C invoices have a 24-hour clock.
• PDF is not the submission. ZATCA's guidance says documents go to Fatoora as XML, not as PDF/A-3. The human-readable PDF is a presentation layer.

Clearance and reporting are two different product promises

Clearance (standard tax invoices, B2B). The seller sends the XML to the Clearance API before giving the invoice to the buyer. ZATCA validates it, applies its own cryptographic stamp and updates the QR code, and sends the document back. In ZATCA's words, a standard document is only considered valid if it has been cleared. Your checkout, ERP or billing screen therefore has a waiting state with a real network dependency in it. Self-billing, where the buyer submits, needs an agreement approved by ZATCA.

Reporting (simplified tax invoices, B2C). The seller generates, stamps and prints or shares the invoice immediately, with the QR code, then reports the XML within 24 hours. ZATCA does not stamp simplified documents; your system must. That is the only reason a till can keep working through a short outage, and it is also why the 24-hour queue is a design object you need to see, alert on and drain.

The two models share one hash chain. ZATCA's guideline says each onboarded unit generates documents in a single sequence that covers both B2B and B2C, and that the previous-document hash must equal the hash of the last document generated, in generation order, not submission order.

Eight product and engineering decisions to take now

1. Model the invoice as a state machine, not a record. Suggested states: drafted, issued and stamped, queued, submitted, cleared or reported, accepted with warnings, rejected, superseded by credit note. Keep every transition with a timestamp. Support, finance and auditors will all ask "where is invoice 4821 right now?"

2. Treat the hash chain as a concurrency constraint. ZATCA's security guidance says a unit must not generate more than one sequence, must not allow the counter to be reset, and must link each invoice to the previous invoice's hash. In the XML standard, the previous hash is a Base64 SHA-256 computed after removing the UBL extensions block, the QR reference and the signature block, then canonicalising with C14N 1.1; the very first invoice uses a fixed seed value defined in the standard. Practical consequence: two servers cannot stamp invoices in parallel against one certificate. Decide early whether each branch, till or worker gets its own onboarded unit, or whether one signing service serialises everything.

3. Never build an edit or delete button for issued invoices. ZATCA's guideline says users must not be able to alter or delete issued invoices; a "cancel" is a credit note plus a new invoice. Its FAQ goes further for rejections: a rejected invoice is not cancelled; the taxpayer fixes the errors and submits the XML as a new invoice with its own counter value and hash. The previous-document hash must be maintained even for rejected documents, because Fatoora records the hash of rejected submissions. Your "fix and resend" screen should create a new document, link it to the failed one and explain why in plain Arabic.

4. Design the three answers, not just success. Valid is easy. "Accepted with warnings" is the one teams ignore: ZATCA treats it as accepted but not fully compliant, and tells the taxpayer to resolve warnings in a timely manner. Rejected means ZATCA does not treat it as a valid document. Show all three states with different colours, counts and next steps, and let finance export the warning text.

5. Make the 24-hour reporting queue visible. For B2C, show how many invoices are waiting, the age of the oldest one and the last successful submission. Alert well before 24 hours, not at hour 23. Make retries idempotent, and never let a retry change the invoice contents, because the content is already stamped and chained.

6. Get the certificate topology right per environment. ZATCA's technical guideline describes the cases. A central server, in the cloud or on premises, needs one certificate (CSID) per taxpayer and per unique sequence of documents. Smart POS devices that sign and send need a CSID each. If dumb terminals hand off to a server that stamps, the server holds the CSID and applies the QR code before the printout. Onboarding runs through the Fatoora portal with a one-time password, a certificate signing request, a compliance CSID, compliance checks, then a production CSID. Certificates expire and are renewed, and ZATCA revokes them automatically when a taxpayer is deregistered or suspended, for example after joining a VAT group. Your product needs a certificate dashboard with expiry dates before it needs a pretty invoice template.

7. Build the Arabic invoice as a first-class template. ZATCA's FAQ says invoices must be in Arabic, with other languages allowed in addition, and Arabic or Hindi numerals both count as Arabic. The XML technicalities are in English, but the human-readable data must be Arabic. That makes this an Arabic-first rendering problem: right-to-left tables, long Arabic company names inside narrow thermal-printer widths, a QR code that scans reliably on cheap paper. Our guide to writing the onboarding in Arabic first applies directly: write the invoice labels in Arabic, then translate.

8. Clean the customer master data before go-live. ZATCA's FAQ notes that a missing additional buyer ID may produce a warning rather than a rejection, and recommends updating customer master data to meet all requirements. Most warnings in a new integration come from data you let customers skip years ago: tax numbers, addresses, buyer identifiers. Make those fields required at creation, not at invoicing time.

What goes into the QR code

For a tax invoice, ZATCA's security standard requires a QR code that is a Base64 string of up to 700 characters, built from tag-length-value records. Tags 1 to 5 carry the seller's name, the seller's VAT number, the ISO 8601 timestamp, the invoice total with VAT and the VAT total. Tag 6 is the hash of the XML invoice, tag 7 the ECDSA signature, tag 8 the public key, and tag 9, for simplified invoices, the signature of the cryptographic stamp issued by ZATCA's technical certificate authority. Validate the string with ZATCA's offline SDK rather than trusting your own decoder, and test the printed code on the cheapest scanner your customers use.

The toolchain ZATCA gives you

• Compliance and Enablement Toolbox (SDK): an offline tool, with a command-line interface, to validate XML invoices, credit and debit notes and their QR codes.
• Integration Sandbox: a test ZATCA backend where your unit can onboard and submit test documents for reporting and clearance.
• Core endpoints (portal user manual, v3, May 2023): compliance (pre-compliance CSID), compliance/invoices (compliance checks), production/csids (request or renew a production CSID), invoices/reporting/single and invoices/clearance/single, all under the Fatoora gateway at /e-invoicing/core/, with a parallel /e-invoicing/simulation/ path for the simulation environment.
• Fatoora portal statistics: a view of documents submitted in the past 12 months, split into accepted, accepted with warnings and rejected, with detailed CSV error and warning files available on request.

Our limits: we read these documents closely, we did not run an onboarding against the sandbox for this article, and the technical documents we cite carry dates between November 2022 and May 2023. Check the Developer Portal for newer versions before you freeze your build.

A sixteen-week plan from 11 October to 1 February

This is our suggested schedule, not ZATCA's.

1. Weeks 1 to 2 (October): confirm scope and your notice; list every place an invoice is born (web checkout, POS, ERP, billing, manual); decide which are B2B and which B2C; pick buy, build or integrate with an e-invoicing solution provider. ZATCA's directory of providers is indicative only; a compliant provider outside the list is still acceptable.
2. Weeks 3 to 6 (late October to mid-November): design the document state machine, the certificate topology and the sequencing model; clean customer master data; draft Arabic invoice templates.
3. Weeks 7 to 10 (mid-November to mid-December): onboard in the sandbox, run compliance checks for every invoice type you will issue, including credit and debit notes, and test rejection and warning paths on purpose.
4. Weeks 11 to 13 (mid-December to early January): production onboarding when ZATCA opens it for you, load tests on the signing path, failure drills for the 24-hour queue, train finance and support.
5. Weeks 14 to 16 (January): go live early, not on the day; watch the Fatoora statistics and your own rejection rate daily; freeze risky releases.

Metrics that tell you whether the integration is healthy

• Cleared or accepted rate by invoice type (B2B and B2C), with accepted-with-warnings counted separately.
• Age of the oldest unreported B2C invoice, with an alert threshold well under 24 hours.
• Median clearance latency for B2B and the share of checkouts that wait longer than your timeout.
• Rejection reasons, grouped by cause: data, signing, hash chain, schema.
• Certificate days to expiry for every unit.
• Reconciliation gap: invoices in your ledger versus documents Fatoora shows as accepted, checked monthly against the VAT return.

Risks and trade-offs

• Serialising for the hash chain slows throughput. One signing path is simple and safe but is a bottleneck at peak; many units scale better but multiply certificates and onboarding work. Measure your peak invoices per minute before choosing.
• Waiting for B2B clearance can stall a sale. Decide what your sales or accounting teams do when Fatoora is slow, and write it into the runbook before it happens.
• Buying a provider does not remove your responsibility. ZATCA tells taxpayers to resolve errors with their solution provider, but warnings and rejections are still your invoices. Ask providers how fast they ship fixes after a ZATCA specification update.
• Dates can move. Wave 24's window was announced in September 2025 and ran to 30 June 2026. Wave 25's date is set by ZATCA's announcement of 24 July 2026; keep checking ZATCA's own news page.
• Penalties are real but we do not quote amounts. ZATCA's guideline says the Authority can levy penalties for non-compliance. Ask your adviser for current figures.

What this means for SaaS, POS, marketplace and payments teams

If you sell invoicing, POS or billing software to Saudi merchants, Wave 25 is your demand spike and your support spike in the same quarter. The merchants most affected are exactly the ones with the thinnest in-house IT. Ship an onboarding wizard that explains the notice, the certificate and the Arabic template in one place. If you run a payment product, your merchants will ask whether their acquirer's receipt counts as a tax invoice; our notes on Tap to Pay and SoftPOS in Saudi Arabia and on SME and merchant payment rails in MENA cover the payment side; the invoice is a separate legal document with its own chain. If you serve small businesses with digital banking, see how STC Bank and Monsha'at frame SME digital banking and think about where invoice status could surface next to cash-flow views. And if you are building agent-driven checkout, remember that an AI agent buying on a merchant's behalf still produces a tax invoice that must be stamped, chained and reported.

iFynx designs and builds bilingual Arabic-English products for regulated MENA markets, including this kind of compliance-driven build. Browse the full iFynx articles hub for more regional product and engineering analysis.

Related reading on iFynx

• SAMA Tap to Pay on iPhone: SoftPOS UX Must Match mada Trust Rituals
• SME & Merchant Payment Rails UX in MENA
• STC Bank × Monsha'at's SAR 5B SME Push: Digital Business Banking UX Must Scale Trust
• Write the Onboarding in Arabic First. Then Translate.
• More: iFynx articles hub

Frequently asked questions

What is ZATCA e-invoicing Wave 25 and who is in it?

Wave 25 is ZATCA's group of taxpayers required to start Phase 2 of Saudi e-invoicing, the integration phase with the Fatoora platform. ZATCA announced on 24 July 2026 that it covers every taxpayer whose revenue subject to VAT exceeded SAR 187,500 in 2022, 2023, 2024 or 2025. One qualifying year is enough, and ZATCA says it will notify each targeted taxpayer directly.

What is the ZATCA Wave 25 deadline?

ZATCA's announcement dated 24 July 2026 gives 1 February 2027 as the integration date for Wave 25. The English text says "by no later than" that date, while the Arabic text says "starting from" it, so plan to be live and tested before 1 February and keep the notice ZATCA sends you as your reference.

What is the difference between clearance and reporting in ZATCA Phase 2?

Clearance applies to standard tax invoices and their notes (B2B): the seller submits the XML to Fatoora before giving the document to the buyer, and ZATCA validates it, stamps it and updates the QR code. Reporting applies to simplified tax invoices and their notes (B2C): the seller stamps and issues the invoice immediately, then submits the XML to Fatoora within 24 hours. Both models use one hash chain per onboarded unit.

What happens if Fatoora rejects an invoice, and can I cancel it?

You cannot edit, delete or cancel an issued invoice. ZATCA's guideline says a cancellation is done with a credit note and a new invoice, and a rejected invoice is fixed by submitting corrected XML as a new invoice with its own counter value and hash. The hash of the rejected document still counts in the chain, so the next invoice must reference it.

Do invoices have to be in Arabic, and what goes in the QR code?

ZATCA's FAQ says invoices must be in Arabic, with other languages allowed in addition, and both Arabic and Hindi numerals are accepted. The QR code is a TLV-encoded Base64 string of up to 700 characters holding the seller name, VAT number, timestamp, invoice total, VAT total, the XML hash, the ECDSA signature, the public key and, for simplified invoices, the signature of ZATCA's technical certificate authority.

Sources

• ZATCA — Criteria for selecting taxpayers in Wave 25 (24 July 2026), English and Arabic (primary)
• ZATCA — Criteria for taxpayers in Wave 24 (26 September 2025) (primary)
• ZATCA — E-invoicing Detailed Technical Guidelines, version 2 (Nov 2022) (primary)
• ZATCA — Detailed Guidelines for E-Invoicing, version 2 (May 2023) (primary)
• ZATCA — Electronic Invoice XML Implementation Standard (19 May 2023) (primary)
• ZATCA — Security Features Implementation Standards, v1.2 (19 May 2023) (primary)
• ZATCA — FATOORA Portal User Manual, version 3 (May 2023) (primary)
• ZATCA — E-Invoicing overview and solution providers directory (primary)
• Adamant Code — ZATCA Phase 2 waves, deadlines and thresholds and SJB — ZATCA Wave 25 (secondary, context on thresholds)
• Hero photo: "Riyadh Skyline showing the King Abdullah Financial District (KAFD) and the famous Kingdom Tower" by B.alotaby, Wikimedia Commons, licensed CC BY-SA 4.0, cropped to 16:9

Closing craft note

The easy way to read Wave 25 is as a deadline. The better way is as a new kind of invoice: one that has a state, a position in a chain, a certificate behind it and a clock running on it. Teams that give that invoice a visible lifecycle, an Arabic face and an honest failure screen will spend January watching dashboards. Teams that treat it as a PDF with a QR code will spend January finding out what a broken hash chain feels like.

---

Originally published on iFynx.