ZATCA Wave 24 E-Invoicing Deadline: June 2026 Integration Guide

Wave 24 is not a future problem — if your client's or employer's annual revenues crossed the ZATCA-specified threshold for this wave, you have roughly weeks, not months, to achieve full FATOORA clearance before the 30 June 2026 (4 Muharram 1448H) hard deadline. Most articles stop at announcing the date. This one takes you through the field-level ERP mapping, UUID/QR reconciliation logic, and cutover testing steps that determine whether your go-live actually holds up under ZATCA's API validation.

Who Is Caught by Wave 24

ZATCA publishes phase-rollout thresholds through its official portal at zatca.gov.sa. Wave 24 targets taxpayers whose revenues subject to VAT exceeded the threshold announced in the corresponding integration notification — consistent with the phased approach ZATCA has followed since Wave 1 (which covered taxpayers above SAR 3 billion) through successive waves targeting smaller and smaller revenue bands.

Before anything else, confirm eligibility:

• Pull your VAT returns for the 12-month base period ZATCA references in the Wave 24 announcement.
• If taxable supplies (standard-rated plus zero-rated, per Article 33 of the VAT Implementing Regulations) exceed the threshold, integration is mandatory — there is no grace-period opt-out.
• Voluntary early integration is permitted and tactically smart: ZATCA's API testing environment (Sandbox) is open now.

If you are unsure of the exact revenue threshold for Wave 24, verify directly at zatca.gov.sa/en/E-Invoicing rather than relying on secondary sources, as ZATCA has updated threshold figures mid-wave in prior rounds.

What Phase 2 Clearance Actually Requires

Phase 2 (Integration Phase) differs from Phase 1 (Generation Phase) in one critical way: every standard-rated and zero-rated B2B/B2G tax invoice must be sent to FATOORA for clearance before it is issued to the buyer. Simplified invoices (B2C) require reporting within 24 hours of generation, per ZATCA's E-Invoicing Implementing Regulation Article 53.

The cleared invoice comes back with:

• A cryptographic stamp from ZATCA
• A UUID (Universally Unique Identifier) assigned by your system and echoed back confirmed
• An updated QR code carrying the clearance hash

None of these are cosmetic. A tax invoice without a confirmed UUID and ZATCA cryptographic stamp is legally invalid under Article 53 of the E-Invoicing Implementing Regulation, exposing you to penalties under Article 40 of the VAT Law.

ERP Field Mapping: Where Most Integrations Break

This is where small finance teams lose weeks. The FATOORA API expects XML in UBL 2.1 format following ZATCA's KSA e-invoicing standard (KSAEINV-UBL). The mapping errors that cause the most clearance rejections in practice:

Invoice Field	Common ERP Label	ZATCA XML Element	Frequent Error
Seller VAT Number	Tax Registration No.	cbc:CompanyID (schemeID="VAT")	Missing schemeID attribute
Invoice Type Code	Document Type	cbc:InvoiceTypeCode	Wrong code (e.g. 388 vs 381 for credit notes)
Line Item VAT Category	Tax Code	cac:TaxCategory/cbc:ID	Using "S" where "Z" or "E" is correct
Invoice Total (incl. VAT)	Grand Total	cbc:TaxInclusiveAmount	Rounding — must be SAR to 2 decimal places, using half-up rule
Supply Date	Posting Date	cbc:IssueDate	ERP posting date ≠ actual supply date
UUID	Auto-generated	cbc:UUID	Duplicate UUIDs across test and production environments

Practical example: A contractor issues a progress invoice for SAR 118,000 (SAR 100,000 + SAR 18,000 VAT at 15%). If your ERP rounds the tax-inclusive total to SAR 117,999.99 due to floating-point handling, ZATCA's API returns a validation error on TaxInclusiveAmount. Fix this at the ERP configuration layer before cutover, not invoice by invoice.

For Mu'tamad-certified ERPs (the list is published on the ZATCA portal), your vendor should provide a pre-validated UBL template — but still test it against your specific chart-of-accounts setup, because multi-company or multi-branch configurations frequently produce schema errors in production that did not appear in the vendor's generic demo.

UUID and QR Reconciliation: The Audit Trail That Matters

Every cleared invoice now has a UUID that ZATCA holds on its side. Your accounts receivable sub-ledger must store and reconcile this UUID against:

1. The invoice number in your ERP
2. The UUID echoed in the FATOORA clearance response
3. The UUID embedded in the QR code on the printed/PDF invoice

If these three do not match, you have a document integrity problem that will surface in a ZATCA field audit. Here is the minimum reconciliation control to build:

• After each clearance API call, store the full ZATCA response payload (including clearedInvoice XML and clearanceStatus) in an immutable log table — do not just store the UUID string.
• Run a nightly reconciliation query: count of invoices posted in ERP for the day versus count of successful clearance responses in your log. Any gap triggers an alert before the 24-hour reporting window for simplified invoices closes.
• For credit notes (Invoice Type Code 381), confirm the UUID of the original invoice is referenced in cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID. ZATCA validates this linkage; a credit note without a valid original-invoice UUID reference will be rejected.

Cutover Testing Checklist for Small Finance Teams

ZATCA's Sandbox environment mirrors Production. Use it properly — running through a truncated test plan because "we tested with the vendor" is one of the most common reasons Wave integrations fail on day one.

Pre-cutover (6–8 weeks before 30 June 2026):

• Complete ZATCA Onboarding in Sandbox: obtain Cryptographic Stamp Identifier (CSID) for each ERP system/branch
• Submit at least 50 diverse invoice scenarios through Sandbox (standard-rated, zero-rated, exempt, credit notes, debit notes)
• Validate all five ZATCA compliance checks per invoice: structural, semantic, Arabic business rules, cryptographic, and QR
• Confirm dual-leg posting: ERP posts successfully AND clearance response is received within API timeout (ZATCA targets sub-5-second response; your ERP timeout should be set to at least 30 seconds to handle peak load)

Pre-cutover (2–4 weeks before 30 June 2026):

• Run parallel: issue real invoices through existing process AND simultaneously push XML to Sandbox — compare outputs daily
• Test failure-mode handling: what does your ERP do when FATOORA returns HTTP 500 or a timeout? Invoice must not be issued to buyer without a cleared status
• Train AR team on the new workflow: cleared invoice PDFs now carry the ZATCA QR — buyers will scan them; your team needs to know what "pending clearance" means operationally

Go-live (by 30 June 2026):

• Switch CSID from Sandbox to Production (separate credentials — do not reuse Sandbox keys)
• Monitor first 48 hours: API error rate, clearance response times, UUID reconciliation counts
• Keep the legacy PDF invoicing process on standby for the first week as a documented contingency — but any invoice issued outside FATOORA after the deadline is non-compliant

Sharpening your technical knowledge before sitting in implementation meetings pays off fast — test your current ZATCA Phase 2 knowledge here and identify exactly where your gaps are.

Penalties and What ZATCA Has Actually Done

Under Article 40 of the VAT Law and the E-Invoicing Regulations, ZATCA can issue fines for:

• Failure to integrate by the mandated deadline
• Issuing invoices without clearance or reporting
• Generating invoices that fail the five compliance checks

ZATCA has applied a proportionate enforcement approach in earlier waves — initial warnings followed by escalating fines — but that approach is not guaranteed to continue, and the burden of proof for compliance sits entirely with the taxpayer. There is no official ZATCA public dataset on Wave 24 penalty issuances to cite yet; monitor zatca.gov.sa for enforcement bulletins.

The practical risk for an accountant: if a client gets fined post-deadline and it emerges that integration was technically feasible but deprioritised, the professional exposure is significant. Document every milestone — vendor sign-off, Sandbox test results, go-live date — with timestamps.

What To Do in the Next Two Weeks

The June 2026 deadline is close enough that "we are still assessing" is no longer a defensible position. Here is the immediate action list:

1. Confirm threshold eligibility against ZATCA's Wave 24 notice — do this today.
2. Engage your Mu'tamad-certified ERP vendor or middleware provider and get a written integration timeline with milestone dates.
3. Register on ZATCA's Fatoora portal and begin the onboarding steps to obtain your Sandbox CSID.
4. Assign a named person in your finance team as the integration owner — ZATCA correspondence and API credentials need a single accountable contact.
5. Map your invoice types against the UBL 2.1 field table above and identify any non-standard scenarios (multi-currency, self-billed invoices, third-party billing) that need custom handling.

Phase 2 integration is not a one-day IT task — the finance team owns the business logic, the tax codes, and the reconciliation controls. Push back if your ERP vendor treats this as purely a technical deployment.

---

Sharpen your edge with SuperAccountant's next live cohort — small batches, real client workpapers, taught by partners. Details and seats at https://app.superaccountant.in/en/cohort.