ZATCA E-Invoicing Wave 25 (2027): The Complete Guide

Saudi Arabia's electronic invoicing programme is entering another significant stage with the announcement of Wave 25 of the Integration Phase (Phase 2) by the Zakat, Tax and Customs Authority (ZATCA) on 24 July 2026.

This latest wave brings a substantial reduction in the revenue threshold for businesses required to integrate their electronic invoicing systems with ZATCA's Fatoora platform.

The new threshold is SAR 187,500 in VAT-subject revenues during any one of the calendar years 2022, 2023, 2024 or 2025. Businesses meeting this criterion will be required to integrate their electronic invoicing solutions with Fatoora by no later than 1 February 2027, subject to ZATCA's notification and applicable requirements.

This is particularly important for small and medium-sized enterprises (SMEs), as the threshold has been reduced to half the SAR 375,000 threshold used for Wave 24.

However, Phase 2 is not simply about connecting an invoicing application to a government portal. It introduces technical requirements involving structured XML invoices, digital signatures, cryptographic hashing, QR codes, API communication, document sequencing and invoice validation.

For businesses operating ERP systems, POS applications or custom accounting software, understanding these requirements is essential.

This guide explains the regulatory scope of Wave 25, the invoice information required by ZATCA, the technical specifications of the XML format, the Fatoora integration process and the practical considerations involved in preparing an ERP system for compliance.

1. Understanding ZATCA E-Invoicing: Phase 1 vs Phase 2

Saudi Arabia introduced its electronic invoicing programme, commonly known as Fatoora, to replace traditional paper-based invoicing with a structured electronic invoicing framework.

The programme is being implemented in two phases.

Phase 1 – Generation Phase

Phase 1 became mandatory on 4 December 2021.

It requires VAT-registered taxpayers subject to the E-Invoicing Regulation to generate and store electronic invoices and associated credit and debit notes through compliant electronic invoicing solutions.

Key requirements include:

Electronic generation of tax invoices and notes.

Prohibition of handwritten invoices and invoices generated through ordinary text-editing or spreadsheet applications.

Generation of invoices containing the required information.

QR code generation for applicable invoices.

Retention of electronic invoice records.

Protection against unauthorized invoice modification and deletion.

Under Phase 1, businesses did not have to integrate their invoicing systems directly with ZATCA's Fatoora platform.

Phase 2 – Integration Phase

Phase 2 commenced on 1 January 2023 and is being introduced progressively through implementation waves.

Unlike Phase 1, the Integration Phase requires the taxpayer's electronic invoicing solution to communicate directly with ZATCA's Fatoora platform.

Additional requirements include:

Integration through ZATCA's APIs.

Generation of invoices in the prescribed UBL 2.1 XML format.

Cryptographic invoice hashing.

Digital signatures and cryptographic stamps.

Invoice counter management.

Previous Invoice Hash (PIH) management.

QR code generation according to Phase 2 specifications.

Electronic clearance or reporting.

Compliance with ZATCA's XML validation rules.

The objective is to establish a more transparent, secure and standardized invoicing environment in which invoice information can be validated electronically.

Official reference: ZATCA – E-Invoicing Regulations and Technical Requirements.

2. ZATCA Wave 25: Who Is Required to Comply?

On 24 July 2026, ZATCA announced the criteria for selecting taxpayers in the twenty-fifth implementation wave.

The announcement specifies that Wave 25 covers taxpayers whose VAT-subject revenues exceeded SAR 187,500 during any one of the following years:

2022

2023

2024

2025

The applicable integration deadline is 1 February 2027.

This is significant because 2025 is included for the first time as a reference year in the wave's revenue criteria.

Consequently, a business that did not cross the previous thresholds in 2022, 2023 or 2024 may still fall within Wave 25 if its VAT-subject revenue exceeded SAR 187,500 during 2025.

Wave 25 at a glance

Does the threshold mean every business must integrate automatically?

Businesses should distinguish between meeting the revenue criterion and receiving an integration notification.

ZATCA has stated that it will notify the targeted taxpayers directly.

Therefore, businesses should:

Review their VAT-subject revenues for all four reference years.

Monitor their ZATCA communication channels.

Confirm whether they have received an integration notification.

Contact their invoicing software provider to assess Phase 2 readiness.

The integration requirement should be assessed against the applicable ZATCA notification and regulatory requirements, rather than relying solely on an internal revenue calculation.

Official source: ZATCA – Announcement of Wave 25.

3. What Does Phase 2 Actually Require?

One of the most common misconceptions is that Phase 2 simply involves adding a QR code to an existing invoice.

That is not sufficient.

Phase 2 introduces a structured electronic document exchange process between the taxpayer's Electronic Generation Solution (EGS) and ZATCA's Fatoora platform.

An EGS can be an ERP system, POS application, invoicing solution or another electronic system used to generate invoices.

The solution must support the following core capabilities.

These requirements must be implemented as an integrated invoicing process, not as disconnected invoice-printing features.

4. ZATCA Invoice Types: Standard vs Simplified Tax Invoices

ZATCA distinguishes between two primary categories of tax invoices.

Understanding this distinction is important because the clearance and reporting workflows are different.

4.1 Standard Tax Invoice (B2B)

Standard tax invoices are generally used for business-to-business transactions.

These invoices are subject to ZATCA's clearance process.

The invoice must be submitted to Fatoora and successfully cleared before being issued to the customer.

The general process is:

Create the sales invoice in the ERP.

Generate the UBL XML document.

Perform local validation.

Generate the required invoice security information.

Submit the invoice to the Clearance API.

Receive the response from ZATCA.

Process the cleared invoice.

Deliver the cleared invoice to the buyer.

The ERP should retain the cleared XML and the associated response information.

4.2 Simplified Tax Invoice (B2C)

Simplified tax invoices are generally used for business-to-consumer transactions.

Unlike standard invoices, these are not subject to pre-issuance clearance.

The EGS generates the invoice, applies the required cryptographic stamp, generates the QR code and issues the invoice to the customer.

The invoice must then be reported to ZATCA within 24 hours.

The general process is:

Complete the customer transaction.

Generate the simplified invoice.

Generate the required XML.

Apply the cryptographic stamp.

Generate the QR code.

Issue the invoice to the customer.

Submit the XML through the Reporting API.

Process the ZATCA response.

Comparison

The classification should follow the applicable VAT invoicing rules and transaction characteristics. It should not be determined simply by whether the customer is an individual or a company.

5. Exact Information Required on a ZATCA-Compliant Invoice

This is one of the most important areas for finance teams and ERP developers.

A compliant invoice must contain the applicable information defined in ZATCA's Electronic Invoice XML Implementation Standard and Electronic Invoice Data Dictionary.

The requirements differ depending on invoice type and transaction circumstances.

The following sections summarize the principal data groups that need to be supported.

5.1 Invoice Identification Information

Every invoice must have the appropriate identification and control information.

The invoice number and UUID are different identifiers and must be managed separately.

The ICV and PIH are also important security-related elements and must not be treated as ordinary invoice references.

5.2 Seller Information

The supplier's legal and tax identification information must be represented in the invoice.

The ERP should maintain a centralized company master record containing the correct registered information.

5.3 Buyer Information

For standard tax invoices, buyer information is particularly important.

Simplified invoices generally have fewer buyer identification requirements.

ERP systems should therefore support different buyer-information requirements depending on the invoice classification.

5.4 Invoice Line Information

Each invoice line must contain the applicable item and tax information.

The system must support multiple VAT treatments within a single invoice.

For example, a business may sell:

Standard-rated products.

Zero-rated products.

VAT-exempt services.

Transactions outside the scope of VAT.

The relevant categories include:

The ERP must also support the applicable exemption and zero-rating reason codes.

A common implementation mistake is to apply the standard 15% VAT rate to every invoice line. VAT classification should instead be maintained at the appropriate item, tax-template and transaction level.

5.5 Invoice Totals and VAT Breakdown

The invoice must contain the applicable financial totals.

VAT must be broken down according to the applicable tax categories and rates.

For example:

The total invoice value including VAT would be SAR 14,500, assuming no other discounts, charges or adjustments.

5.6 Discounts, Charges and Advance Payments

The XML implementation standard also accommodates more complex invoicing scenarios.

A compliant solution should support:

Item-level discounts.

Document-level discounts.

Item-level additional charges.

Document-level additional charges.

Allowance reason codes.

Charge reason codes.

VAT treatment of discounts and charges.

Advance payments.

Allocation of advance payments.

Outstanding payable amounts.

This is particularly important for businesses operating in retail, distribution, contracting and project-based industries.

5.7 Payment Information

The system should also support the relevant payment information, including:

Payment means code.

Payment method.

Payment terms.

Prepaid amount.

Outstanding payable amount.

These details help maintain consistency between invoicing, accounts receivable and customer settlement records.

Official technical reference: ZATCA Electronic Invoice XML Implementation Standard.

6. XML Invoice Format: Understanding UBL 2.1

ZATCA requires electronic invoices to follow the Universal Business Language (UBL) 2.1 XML format, subject to Saudi-specific implementation requirements.

UBL is an international XML-based standard used to represent business documents such as invoices, purchase orders and credit notes.

ZATCA has adopted the UBL 2.1 structure and enhanced it with additional Saudi-specific business rules.

The XML implementation is aligned with the EN 16931 electronic invoicing semantic model.

6.1 Main XML Components

The following table identifies some of the important XML elements.

6.2 Illustrative XML Example

The following example demonstrates the basic structure of a UBL invoice.

It is intentionally abbreviated to explain the XML architecture. It is not a production-ready ZATCA invoice and must not be submitted to Fatoora without the mandatory elements, Saudi-specific extensions, correct element ordering and validation rules.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice
xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
<cbc:UBLVersionID>2.1</cbc:UBLVersionID>
<cbc:ID>INV-2026-00001</cbc:ID>
<cbc:UUID>
123e4567-e89b-12d3-a456-426614174000
</cbc:UUID>
<cbc:IssueDate>2026-11-04</cbc:IssueDate>
<cbc:IssueTime>14:30:00</cbc:IssueTime>
<cbc:InvoiceTypeCode name="0100000">
388
</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
<cac:AccountingSupplierParty>
<cac:Party>
<cac:PartyLegalEntity>
<cbc:RegistrationName>
Example Trading Company
</cbc:RegistrationName>
</cac:PartyLegalEntity>
<cac:PartyTaxScheme>
<cbc:CompanyID>300000000000003</cbc:CompanyID>
</cac:PartyTaxScheme>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<!-- Buyer information -->
</cac:AccountingCustomerParty>
<cac:TaxTotal>
<!-- VAT breakdown -->
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<!-- Invoice totals -->
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<!-- Invoice line items -->
</cac:InvoiceLine>
</Invoice>

The example illustrates the XML namespace and the main invoice elements.

The invoice type code and its seven-character transaction indicator must be populated according to the actual transaction.

For example, standard and simplified tax invoices use different transaction indicators. The values must be taken from the applicable ZATCA specifications rather than copied indiscriminately.

6.3 Why the Data Dictionary Matters

The XML implementation standard explains the structure and validation requirements.

However, developers also need the Electronic Invoice Data Dictionary.

This document provides the detailed mapping of business information to the relevant XML elements, including:

Business term identifiers.

Field definitions.

XML locations.

Mandatory and conditional requirements.

Data types.

Formats.

Validation conditions.

For ERP developers, the Data Dictionary should be used as the primary field-mapping reference when designing the invoice-generation engine.

Official resources:

Electronic Invoice XML Implementation Standard

Electronic Invoice Specifications and Data Dictionary

7. QR Code Requirements and TLV Encoding

QR codes are an important component of Saudi electronic invoicing.

However, Phase 2 introduces additional cryptographic information compared with the basic QR requirements of Phase 1.

ZATCA specifies a Tag-Length-Value (TLV) structure encoded using Base64.

7.1 The Nine QR Code Tags

The Phase 2 QR code specification defines the following information.

Tags 1–5 contain the basic invoice information.

Tags 6–9 provide the additional cryptographic information.

7.2 How TLV Encoding Works

TLV stands for:

Tag: Identifies the information.

Length: Specifies the length of the value.

Value: Contains the actual information.

The process involves:

Assigning the appropriate tag number.

Converting the value into its required byte representation.

Calculating the length.

Combining the tag, length and value.

Repeating the process for the required fields.

Encoding the resulting byte array using Base64.

Generating the QR image from the encoded string.

7.3 An Important Development Consideration

The length must be calculated using the number of bytes in the UTF-8 encoded value, not simply the number of characters.

This is particularly important when seller names contain Arabic characters.

For example, an Arabic company name may occupy a different number of UTF-8 bytes than its character count suggests.

A QR generator that calculates lengths incorrectly may produce an invalid result.

Developers should implement the TLV process according to ZATCA's security implementation standard rather than using a generic QR-generation library without the required encoding logic.

Official reference: ZATCA Electronic Invoice Security Features Implementation Standards, version 1.2.

8. Cryptographic Hashing and Digital Signatures

Cryptographic security is one of the most important technical aspects of Phase 2.

ZATCA requires electronic invoicing systems to implement mechanisms that protect the integrity and authenticity of generated documents.

These mechanisms include hashing, digital signatures, cryptographic certificates and invoice sequencing.

8.1 SHA-256 Invoice Hashing

SHA-256 is used to generate a cryptographic fingerprint of the invoice.

The resulting hash is used to identify the document and detect changes to its underlying content.

ZATCA's implementation specifies the transformation and canonicalization steps used before hashing.

The general process includes:

Generate the invoice XML.

Remove the specified elements and extensions according to the hashing rules.

Remove the XML declaration.

Canonicalize the XML using the specified C14N11 method.

Generate the SHA-256 hash.

Encode the resulting hash in Base64.

The exact transformation rules must be followed. Simply hashing the original XML file as-is will not produce the required result.

8.2 ECDSA Digital Signatures

ZATCA uses Elliptic Curve Digital Signature Algorithm (ECDSA) for the cryptographic signing process.

The implementation involves:

Private key.

Public key.

Cryptographic certificate.

Invoice hash.

Signed properties and certificate information.

The private key is particularly sensitive.

It must be securely protected and should never be exposed through ordinary ERP user permissions, application logs or publicly accessible files.

8.3 Previous Invoice Hash (PIH)

ZATCA requires the electronic invoicing system to maintain a continuous document hash sequence.

Each new invoice references the hash of the preceding document generated by the same EGS unit.

For illustration:

This establishes a relationship between consecutive documents.

If an invoice is modified or the sequence is improperly manipulated, the integrity of the chain may be compromised.

An important consideration is that rejected submissions do not simply disappear from the document sequence. The system must preserve the required sequencing and hash-chain integrity.

8.4 Invoice Counter Value (ICV)

The Invoice Counter Value is another important control.

It maintains a sequential count of documents generated by an EGS unit.

The ICV is not the same as the ERP's normal sales invoice number.

For example:

An ERP may generate invoice numbers such as:

SI-2026-0001

SI-2026-0002

SI-2026-0003

The EGS must independently maintain its ICV according to the applicable ZATCA requirements.

8.5 Cryptographic Stamp Identifier (CSID)

The onboarding process involves obtaining cryptographic credentials from ZATCA.

The general process is:

Generate an OTP through the Fatoora portal.

Generate a Certificate Signing Request (CSR).

Submit the CSR to ZATCA.

Obtain the Compliance CSID.

Perform the required compliance checks.

Obtain the Production CSID following successful compliance testing.

The Production CSID is used for production communication with Fatoora.

Businesses must also manage certificate security, renewal and revocation requirements.

Official reference: ZATCA Security Features Implementation Standards.

9. Integrating an ERP System with ZATCA Fatoora APIs

Phase 2 requires communication between the taxpayer's EGS and the Fatoora platform.

This communication is handled through ZATCA's published APIs.

There are two primary workflows: Clearance and Reporting.

9.1 Standard Tax Invoice – Clearance API

For standard tax invoices, the invoice must be cleared before it is issued to the buyer.

The process is:

The user creates a sales invoice in the ERP.

The ERP generates the UBL XML.

The XML is validated locally.

The EGS prepares the required security information.

The invoice is submitted through the Clearance API.

ZATCA validates the document.

ZATCA returns the relevant response.

Following successful clearance, the cleared invoice is stored.

The cleared invoice is delivered to the customer.

The system must process the actual response and distinguish between successful clearance, warnings and rejection.

A successful API connection does not automatically mean that an invoice has been cleared.

9.2 Simplified Tax Invoice – Reporting API

Simplified invoices follow a different workflow.

The process is:

The customer transaction is completed.

The ERP generates the simplified invoice.

The EGS generates the XML.

The EGS applies the cryptographic stamp.

The QR code is generated.

The invoice is issued to the customer.

The XML is submitted through the Reporting API.

ZATCA validates the submission.

The ERP records the response.

Simplified invoices must be reported within 24 hours.

9.3 Integration Architecture

A typical integration architecture can be represented as follows:

USER / CUSTOMER
|
v
ERP / POS SYSTEM
|
v
INVOICE GENERATION
|
v
UBL XML
|
v
XML VALIDATION
|
v
CRYPTOGRAPHIC ENGINE
|
v
QR GENERATOR
|
v
API CLIENT
|
+------+------+
|             |
v             v
CLEARANCE      REPORTING
B2B           B2C
|             |
+------+------+
|
v
FATOORA PLATFORM
|
v
VALIDATION RESPONSE
|
v
ERP STATUS UPDATE
|
+------+------+
|             |
v             v
ACCEPTED       REJECTED
|             |
v             v
STORE XML       ERROR HANDLING
& RESPONSE      & CORRECTION

The ERP should maintain a complete record of the API communication, including request identifiers, response codes, submission timestamps and validation results.

Official technical reference: ZATCA Detailed Technical Guideline and Developer Portal documentation.

10. Technical Considerations for ERP and Software Developers

Implementing ZATCA Phase 2 requires more than adding an API endpoint to an existing invoicing application.

The solution must address invoice generation, validation, security, communication, sequencing and auditability.

The following are the key areas developers should consider.

10.1 Dedicated Integration Architecture

A recommended architecture separates ZATCA compliance functionality from the core accounting and invoicing modules.

This architecture makes the integration easier to maintain and allows multiple business modules to use the same compliance engine.

10.2 Multiple Branches and POS Systems

Businesses with multiple branches need to consider how their invoicing infrastructure is organized.

For example, a retail company operating 20 outlets may have:

One central ERP.

Multiple POS terminals.

Separate branch servers.

A centralized integration service.

The architecture must account for the applicable EGS units, onboarding and cryptographic credentials.

Document counters and hash chains must be maintained correctly for each EGS unit.

A centralized architecture can simplify management, but the deployment must follow ZATCA's EGS identification and security requirements.

10.3 Internet Connectivity and Failure Handling

What happens if a business loses internet connectivity?

This is an important consideration for retailers, restaurants and businesses operating multiple locations.

The integration should account for:

Temporary connectivity failures.

API timeouts.

Authentication failures.

Invalid XML submissions.

Rejected invoices.

Delayed reporting.

Recovery and resubmission.

Document sequence preservation.

A robust system should implement submission queues and clear status management.

For example:

A network failure should not be confused with a regulatory rejection.

The retry mechanism must also prevent duplicate processing and preserve invoice sequencing.

10.4 Data Security and Certificate Management

The cryptographic architecture makes security a critical requirement.

Developers should consider:

Secure private-key storage.

Restricted certificate access.

Encryption of sensitive configuration.

Secure API authentication.

Role-based access control.

Certificate renewal monitoring.

Certificate revocation procedures.

Protection of XML documents.

Audit logging.

Monitoring unauthorized changes.

Private keys should never be exposed through ordinary application interfaces or publicly accessible files.

10.5 XML Validation and Testing

ZATCA provides a Compliance and Enablement Toolbox (SDK) to help developers validate electronic invoices.

The SDK supports verification of invoice and note compliance with the applicable technical requirements.

Testing should include:

XML schema validation.

UBL structure.

Business rules.

VAT calculations.

QR code generation.

Cryptographic signatures.

Credit and debit notes.

Invoice sequencing.

API communication.

The SDK is an essential development resource.

However, passing SDK validation does not mean that ZATCA has formally approved the entire production integration. It also does not remove the taxpayer's responsibility to comply with the applicable regulations.

Official resource: ZATCA Compliance and Enablement Toolbox SDK.

11. Implementing ZATCA Phase 2 in ERPNext

For businesses operating ERPNext, the existing accounting and sales modules provide much of the foundation needed for a compliant invoicing solution.

However, Phase 2 requires a dedicated integration layer.

Simply adding a QR code to an existing Sales Invoice print format is not sufficient.

A proper implementation should cover the entire invoicing lifecycle.

11.1 ERPNext Modules Requiring Enhancement

11.2 Recommended Custom Application

A practical approach would be to create a dedicated Frappe application named:

zatca_integration

Suggested DocTypes include:

ZATCA Settings

ZATCA EGS Unit

ZATCA Certificate

ZATCA Invoice Log

ZATCA Submission Queue

ZATCA Error Log

ZATCA Document Sequence

ZATCA API Transaction Log

The application should provide separate services for:

XML generation.

Invoice validation.

Hash generation.

Digital signing.

QR generation.

API communication.

Response processing.

This approach keeps the integration modular and makes it easier to maintain across multiple ERPNext deployments.

11.3 Important ERPNext Design Considerations

Invoice submission should be asynchronous where appropriate.

For simplified invoices, background jobs can handle reporting without unnecessarily delaying customer-facing operations.

For standard invoices, the system must enforce successful clearance before the invoice is issued to the buyer.

Document sequencing must be independent of ordinary invoice numbering.

The ICV and PIH should be maintained in a dedicated sequence-management component.

Submitted XML should be retained.

The system should preserve the generated XML, relevant cryptographic information, API response and cleared document where applicable.

Invoice corrections should follow the proper credit/debit note process.

The system must not simply edit or overwrite an already issued electronic invoice.

These design considerations are particularly important when extending ERPNext into a multi-company or multi-branch environment.

12. Arabic Language, Invoice Presentation and Record Retention

Technical integration is only one part of compliance.

Businesses must also consider the human-readable invoice and electronic record-keeping requirements.

12.1 Arabic Invoice Requirements

ZATCA's FAQ confirms that the information visible on the human-readable invoice must be in Arabic.

Bilingual Arabic-English invoices are permitted.

ERP systems should therefore support:

Arabic company information.

Arabic customer information where applicable.

Arabic product and service descriptions.

Arabic invoice labels.

Arabic tax information.

Proper right-to-left formatting.

This should be considered during ERP implementation rather than treated as a final print-format adjustment.

12.2 Invoice Storage

Businesses should retain the relevant electronic records, including:

Original invoice information.

Generated XML.

Cleared XML for standard invoices.

Cryptographic information.

QR code information.

ZATCA API responses.

Rejection and warning details.

Credit and debit note references.

Relevant audit records.

The storage architecture should protect document integrity and support the applicable record-retention requirements.

12.3 PDF and Printed Invoices

A customer-facing invoice may be presented as a PDF or printed document.

However, the PDF is not a substitute for the required structured XML document.

The XML must be generated, submitted and retained according to the applicable Phase 2 requirements.

13. ZATCA Wave 25: Business Readiness Checklist

Businesses approaching the February 2027 deadline should not wait until the final weeks to assess their systems.

A structured readiness assessment should cover regulatory applicability, master data, invoicing processes, software capabilities and technical integration.

14. What Should Businesses Do Before 1 February 2027?

The most practical approach is to divide implementation into manageable stages.

Stage 1 – Regulatory Assessment

Review VAT-subject revenue for the relevant years.

Confirm whether the business has received a Wave 25 notification.

Identify the applicable integration date.

Assess existing invoicing processes.

Stage 2 – Software Assessment

Identify the current ERP or invoicing solution.

Confirm whether it supports ZATCA Phase 2.

Identify any gaps in XML generation, security and API integration.

Determine whether the existing provider offers an upgrade.

Stage 3 – Master Data Preparation

Validate company registration details.

Review customer VAT information.

Review item tax classifications.

Correct missing or inconsistent addresses.

Review invoice numbering and document sequencing.

Stage 4 – Technical Implementation

Configure the EGS.

Complete onboarding.

Generate the required cryptographic credentials.

Implement XML generation and validation.

Implement the required API workflows.

Configure QR code generation.

Stage 5 – Testing and Go-Live

Test standard invoices.

Test simplified invoices.

Test credit and debit notes.

Validate XML and QR codes using ZATCA's SDK.

Test API communication.

Test rejection and recovery scenarios.

Complete production integration within the applicable deadline.

Businesses should also train their finance and operational teams to understand the new invoicing workflows.

15. Official ZATCA Documentation and Developer Resources

For businesses, ERP consultants and software developers, the following official resources are particularly important.

These documents should be treated as the primary technical references when implementing ZATCA Phase 2.

Official documentation links

1. ZATCA E-Invoicing Portal

https://www.zatca.gov.sa/en/E-Invoicing/Pages/default.aspx

2. Electronic Invoice XML Implementation Standard

https://www.zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20220624_ZATCA_Electronic_Invoice_XML_Implementation_Standard_vF.pdf

3. Electronic Invoice Data Dictionary and Specifications

https://zatca.gov.sa/en/e-invoicing/systemsdevelopers/pages/e-invoice-specifications.aspx

4. Security Features Implementation Standards

https://www.zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_Security_Features_Implementation_Standards_vF.pdf

5. Detailed Technical Guideline

https://www.zatca.gov.sa/en/E-Invoicing/Introduction/Guidelines/Documents/E-invoicing-Detailed-Technical-Guideline.pdf

6. Compliance and Enablement Toolbox SDK

https://www.zatca.gov.sa/en/E-Invoicing/SystemsDevelopers/ComplianceEnablementToolbox/Pages/DownloadSDK.aspx

7. Developer Portal Manual

https://zatca.gov.sa/en/E-Invoicing/Introduction/Guidelines/Documents/DEVELOPER-PORTAL-MANUAL.pdf

8. E-Invoicing Laws and Regulations

https://zatca.gov.sa/en/E-Invoicing/Introduction/LawsAndRegulations/Pages/default.aspx

9. ZATCA Frequently Asked Questions

https://www.zatca.gov.sa/en/E-Invoicing/Introduction/FAQ/Pages/default.aspx

10. Official Wave 25 Announcement

https://zatca.gov.sa/en/MediaCenter/News/Pages/Wave25-E-invoicing.aspx

16. Conclusion: E-Invoicing Is Becoming an Integral Part of Business Digitalization

Wave 25 represents another important step in Saudi Arabia's transition towards a fully integrated electronic invoicing environment.

With the revenue threshold reduced to SAR 187,500, the Integration Phase is becoming relevant to a much broader group of VAT-registered businesses, including smaller enterprises.

For business owners and finance leaders, the immediate priority should be to establish whether their organization falls within the targeted group, verify the applicable integration date and assess the readiness of their existing invoicing solution.

For ERP providers and software developers, the challenge is more substantial.

Phase 2 requires a complete technical framework covering structured invoice generation, VAT calculations, cryptographic security, document sequencing, XML validation and API communication.

These requirements must be integrated into the underlying accounting and invoicing architecture rather than implemented as superficial changes to invoice templates.

Businesses that approach this transition as part of their broader digital transformation strategy will be better positioned to achieve regulatory compliance while improving financial controls, invoice traceability and operational efficiency.

The February 2027 deadline should therefore be treated not simply as an invoicing compliance milestone, but as an opportunity to strengthen the organization's financial and technology infrastructure.

Need Help Preparing Your ERP for ZATCA Phase 2?

Whether your organization operates ERPNext, SAP, Oracle Fusion, Microsoft Dynamics or a custom-built accounting solution, preparing for ZATCA integration requires careful consideration of both regulatory and technical requirements.

A proper readiness assessment can identify gaps in invoice generation, VAT configuration, XML compliance, cryptographic security and Fatoora API integration before they become operational problems.

If your business is preparing for Wave 25, consider reviewing your existing ERP architecture and initiating the necessary integration work well ahead of the applicable deadline.