ZATCA Wave 25 E-Invoicing: What Saudi Businesses Must Integrate Before February 2027

Saudi Arabia's Zakat, Tax and Customs Authority has expanded Phase 2 of e-invoicing to Wave 25, covering targeted taxpayers whose revenues subject to VAT exceeded SAR 187,500 in 2022, 2023, 2024 or 2025. ZATCA says those taxpayers must integrate their e-invoicing solutions with the Fatoora Platform by no later than February 1, 2027.

For businesses newly entering Phase 2, this is not a cosmetic invoice-template update. The invoicing system must generate compliant structured XML, support ZATCA onboarding and cryptographic credentials, apply the correct B2B clearance or B2C reporting flow, preserve invoice sequencing and hashes, handle rejected submissions, and remain operable when networks or external services fail.

The useful implementation model is:

Confirm Wave 25 scope and notification
        ↓
Map every invoice-producing system
        ↓
Generate compliant XML and security fields
        ↓
Onboard each EGS unit and obtain credentials
        ↓
Integrate Clearance and Reporting APIs
        ↓
Test in ZATCA tools and sandbox
        ↓
Rehearse failure/retry scenarios
        ↓
Cut over before 1 February 2027

This guide focuses on what business owners, ERP teams and software developers need to get right before the deadline.

Who is included in ZATCA Wave 25?

ZATCA announced Wave 25 on July 24, 2026. The official Wave 25 notice says the wave includes taxpayers whose revenues subject to VAT exceeded SAR 187,500 during any of 2022, 2023, 2024 or 2025.

ZATCA says targeted taxpayers will be notified and must integrate their e-invoicing solutions with Fatoora by no later than February 1, 2027.

That threshold matters because Phase 2 has now moved far beyond the very largest Saudi companies. A business that previously treated Fatoora integration as an enterprise-only project may now fall inside the rollout.

Use this as a screening rule:

VAT-subject revenue > SAR 187,500
in 2022 OR 2023 OR 2024 OR 2025
        ↓
Potential Wave 25 scope
        ↓
Confirm ZATCA notification and taxpayer obligations

Do not rely only on an old revenue-band article or a software vendor's wave table. ZATCA's roll-out page states that Phase 2 is implemented by targeted taxpayer groups and that ZATCA notifies taxpayers in advance.

What changes from Phase 1 to Phase 2?

Phase 1 was primarily about generating and storing compliant electronic invoices. Phase 2 adds integration with ZATCA's systems and additional technical, data and security requirements.

ZATCA's current e-invoicing overview describes the model as:

Phase 1
→ Generate and store compliant electronic invoices

Phase 2
→ Generate in required structured format
→ Add required fields/security features
→ Integrate invoicing solution with Fatoora

A business can therefore be compliant with the generation phase and still have meaningful engineering work before Phase 2.

The main workstreams usually become:

• XML generation and validation;
• invoice data completeness;
• cryptographic/security requirements;
• onboarding each invoicing solution unit;
• API integration;
• clearance/reporting logic;
• resilient retry and rejection handling;
• audit-friendly storage;
• production monitoring.

The migration should be treated as an application-integration project, not a PDF redesign.

Standard tax invoices and simplified invoices follow different flows

This is the most important architectural distinction in Phase 2.

Standard tax invoices: clearance

Standard tax invoices are generally associated with B2B transactions.

Under ZATCA's clearance model:

Business generates standard tax invoice
        ↓
Send invoice to Fatoora
        ↓
ZATCA validates it
        ↓
Invoice is cleared
        ↓
Cleared invoice is shared with customer

ZATCA's Detailed Guidelines define Clearance as the process in which the authority validates tax invoices and associated notes against the required controls and details. The authority inserts the relevant cryptographic stamp on compliant documents before they are shared with customers.

That means the ZATCA call is part of the issuance path.

Your application must therefore answer practical questions such as:

• What does the user see while clearance is pending?
• What happens when ZATCA rejects the XML?
• Can another invoice be created while one invoice is awaiting a response?
• How is the response stored?
• What is shown on the final customer document?
• Who is alerted when clearance fails?

Simplified tax invoices: reporting

Simplified tax invoices are generally associated with B2C transactions.

ZATCA's Detailed Guidelines state that simplified invoices are reported to Fatoora within 24 hours of issuance.

The flow is therefore different:

Business generates simplified tax invoice
        ↓
Issue invoice to customer
        ↓
Report invoice to Fatoora
within the required window

This difference should exist explicitly in code.

Do not create one vague function such as:

sendInvoiceToZatca()

and hide two different regulatory workflows inside it without modelling their states separately.

A better invoice state machine

A Phase 2 system benefits from explicit lifecycle states.

For a standard tax invoice:

DRAFT
→ GENERATED
→ VALIDATED_LOCALLY
→ SENT_FOR_CLEARANCE
→ CLEARED
→ DELIVERED

Failure states might include:

CLEARANCE_REJECTED
CLEARANCE_TRANSPORT_ERROR
MANUAL_REVIEW_REQUIRED

For a simplified tax invoice:

DRAFT
→ GENERATED
→ ISSUED
→ REPORTING_PENDING
→ REPORTED

with failure states such as:

REPORTING_REJECTED
REPORTING_RETRY_PENDING
REPORTING_MANUAL_REVIEW

The exact names are yours. The important point is that regulatory state should be stored as business data, not inferred from an HTTP log.

That gives finance and operations teams a reliable answer to:

Which invoices still require action?

Phase 2 invoices need structured XML, not merely a PDF

ZATCA defines an electronic invoice as a document generated in a structured electronic format through electronic means. Scanning a paper invoice, exporting an image, or generating only a visual PDF is not the same thing.

For developers, the source of truth is the structured invoice payload.

ZATCA's E-Invoice Specifications publishes:

• the Electronic Invoice Data Dictionary; and
• the Electronic Invoice XML Implementation Standard.

The XML Implementation Standard contains the syntax and business-content rules that generated invoices must satisfy.

A sensible architecture is:

Transaction / ERP data
        ↓
Canonical invoice model
        ↓
ZATCA mapping + business rules
        ↓
Structured XML
        ↓
security / hash / QR requirements
        ↓
validation
        ↓
clearance or reporting API
        ↓
human-readable invoice output

Do not build the XML by scraping values back out of a PDF template. Generate both machine-readable and human-readable outputs from a common validated invoice model.

What should your invoice data model contain?

The exact mandatory fields depend on invoice type and transaction context, so implementation should be driven by ZATCA's current Data Dictionary and XML rules rather than a blog checklist.

But the application model usually needs clear ownership of categories such as:

• seller identity and VAT details;
• buyer details where required;
• invoice type;
• invoice number / counter;
• issue date and time;
• supply dates where applicable;
• currency;
• line items;
• quantities and prices;
• discounts and charges;
• tax categories and VAT amounts;
• totals;
• references to previous invoices or notes;
• payment means where required;
• UUID;
• invoice hash / chain-related values;
• QR/security fields;
• clearance/reporting response data.

The engineering mistake to avoid is bolting Phase 2 onto a weak existing invoice table that stores only:

invoice_number
customer
total
pdf_url

If the source system cannot represent the required tax semantics reliably, API integration will not fix the data problem.

What is an EGS unit and why does onboarding matter?

ZATCA's Detailed Guidelines describe the Fatoora Portal as the system used to receive invoice data and to onboard an E-Invoice Generation Solution (EGS) Unit.

The onboarding process is tied to cryptographic identity.

ZATCA defines the Cryptographic Stamp Identifier (CSID) as a unique identifier connecting the e-invoice solution unit with trusted identity information.

In practical terms, implementation needs an inventory of the invoice-producing units that will operate under the taxpayer.

Depending on your architecture, these may represent:

• a central ERP instance;
• branch POS units;
• store-level invoicing devices;
• separate legal/system environments;
• production invoicing applications.

Do not wait until final deployment to decide what constitutes an EGS unit in your system. That affects credential storage, onboarding, revocation, monitoring and disaster recovery.

Keep ZATCA credentials out of business logic

The integration should have an explicit credential boundary.

Conceptually:

Invoice service
        ↓
ZATCA integration adapter
        ↓
secure credential provider
        ↓
Fatoora APIs

Do not scatter production onboarding credentials through:

• frontend JavaScript;
• Flutter/mobile applications;
• POS configuration files readable by ordinary users;
• source repositories;
• database rows without appropriate protection;
• CI logs;
• support tickets.

Credential lifecycle should include:

provision
→ secure storage
→ use
→ renewal/rotation where applicable
→ revocation
→ replacement

If the business operates many units or branches, credential management becomes an operational subsystem of its own.

Use ZATCA's SDK and sandbox before production

ZATCA provides developer tooling specifically for this transition.

The Compliance and Enablement Toolbox SDK is intended to help taxpayers and solution developers verify generated invoices, credit notes and debit notes against the e-invoicing requirements.

ZATCA's developer documentation also provides sandbox/testing support for integration work.

Use the layers separately:

1. Schema/business-rule validation
        ↓
2. Security feature validation
        ↓
3. Sandbox API integration
        ↓
4. onboarding test
        ↓
5. clearance/reporting test
        ↓
6. production cutover

Passing a local validator is not the same thing as proving the complete integration works.

ZATCA explicitly notes that SDK verification does not itself mean an invoice has been approved by the authority and does not remove the taxpayer's compliance responsibility.

Do not test only the happy path

A demo that successfully clears one invoice is not production readiness.

Test at least these cases:

An integration is ready when failure behaviour is designed, not when the success response is green.

Invoice counters and retries need special care

Retries are dangerous when developers treat invoice submission like an ordinary idempotent REST call.

ZATCA's Detailed Technical guidance says an Invoice Counter Value (ICV) must not be reused for another document once a document has been generated with it.

That means a rejected invoice should not trigger careless behaviour such as:

delete rejected record
→ reset counter
→ reuse the same counter for another invoice

Instead, the invoice domain should preserve immutable identity and sequencing rules.

A safer model separates:

Business invoice identity
Invoice counter
UUID
submission attempt
ZATCA response

Submission retries should not silently create a new commercial transaction unless the business process genuinely requires a new document.

This is one reason invoice integration belongs in a proper state machine rather than a controller that calls an API and immediately forgets the response.

What happens if simplified-invoice reporting fails?

The B2C flow needs a durable retry queue.

ZATCA's technical guidance distinguishes a reporting failure from the underlying taxable transaction. When a simplified invoice has already been issued and reporting fails, the software needs to correct the technical problem and resubmit appropriately rather than pretending the sale never happened.

Build for:

Invoice issued
        ↓
report attempt fails
        ↓
persist failure and payload
        ↓
classify retryable vs validation error
        ↓
retry / correct
        ↓
report successfully
        ↓
close operational alert

Do not store failed submissions only in application logs.

Finance or support staff need a dashboard or report showing unresolved invoices before the reporting window becomes a compliance problem.

Network failure is a business requirement, not an edge case

Retail, hospitality, field operations and multi-branch businesses should assume connectivity will sometimes be unavailable.

A robust architecture separates invoice generation from network delivery where the applicable invoice type permits it.

For simplified invoices:

POS generates compliant invoice locally
→ customer transaction completes
→ reporting job persists
→ background integration reports to ZATCA
→ retries are monitored

For standard invoices subject to clearance, the workflow must respect the requirement that clearance occurs before the cleared document is provided to the customer.

That may mean the UI needs a clear "awaiting clearance" experience rather than assuming every API request returns instantly.

Do not let a network timeout turn into an unknown financial state.

Multi-branch businesses need central visibility

A branch may generate invoices locally, but the company still needs one operational picture.

For a multi-branch design, consider:

Branch/POS
├── local invoice generation
├── local queue where appropriate
└── EGS identity / unit context
        ↓
Central integration/observability layer
        ↓
Fatoora
        ↓
Central compliance dashboard

The central system should be able to answer:

• Which branch generated the invoice?
• Which EGS unit/credential was used?
• Was it cleared or reported?
• How many submissions are pending?
• Which failures are older than the internal SLA?
• Are invoice sequences healthy?
• Which credentials are nearing an operational renewal event?
• Can support reproduce the original XML and response?

For a growing Saudi operation, this observability can be more valuable than the API connector itself.

Should you modify the ERP or build a separate integration layer?

There are three common approaches.

1. Native ERP support

Use the ERP's maintained ZATCA module when it genuinely supports your Saudi business requirements.

Best when:

• the ERP is the clear invoice system of record;
• the module is actively maintained;
• custom workflows are limited.

2. Custom integration adapter

Keep the ERP/POS as the transaction system and add a service responsible for:

mapping
XML generation
validation
security
API communication
retry
monitoring

Best when multiple systems need a common ZATCA integration or the ERP's extension model is weak.

3. Replace the invoicing subsystem

Appropriate only when the current system cannot reliably represent required invoice data or operational workflows.

Do not rebuild the entire ERP merely because one integration is difficult.

For many businesses, an adapter is the cleanest boundary:

ERP / POS / booking system
        ↓
canonical invoice event
        ↓
ZATCA adapter
        ↓
Fatoora

That isolates regulatory integration from the rest of the application.

What should the ZATCA adapter own?

A maintainable integration service can own:

• mapping internal invoice data to ZATCA fields;
• XML generation;
• schema/business-rule validation;
• QR/security construction where required;
• credential access;
• clearance/reporting API clients;
• response parsing;
• retry policy;
• submission audit records;
• operational alerts;
• sandbox/production configuration separation.

It should not invent tax/business facts that the ERP failed to capture.

If the source transaction has no correct tax category, buyer VAT information or line-level value, the adapter should reject the transaction for correction rather than guess.

Avoid hard-coding regulatory rules throughout the application

A poor implementation distributes ZATCA-specific conditions across:

POS frontend
ERP plugin
backend controller
PDF template
mobile app
database trigger

Then a rule change becomes a scavenger hunt.

Prefer:

business transaction model
        ↓
versioned e-invoicing rules/mapping
        ↓
one compliance/integration boundary

Where configuration can safely be data-driven, version it.

Where a rule affects tax meaning, cover it with automated tests.

The goal is not to make regulation "dynamic" at any cost. It is to know exactly where compliant behaviour lives.

Security requirements are part of Phase 2

ZATCA maintains a dedicated Security Requirements section and Security Features Implementation Standard.

That should influence architecture from the beginning.

A production review should include:

• protection of private/credential material;
• secure transport;
• controlled administrative access;
• auditability;
• tamper resistance appropriate to the invoicing solution;
• protection against unauthorised invoice modification;
• secure backup/restore;
• separation of sandbox and production secrets;
• secret rotation/revocation procedures.

Do not let tax credentials share the same casual storage pattern as a low-risk application API key.

Separate sandbox and production completely

Use different:

• credentials;
• environment variables;
• API endpoints/configuration;
• monitoring labels;
• storage/audit records;
• deployment permissions.

A production system should make it difficult to accidentally send:

test invoice → production

or:

production invoice → sandbox

An environment field in each submission audit record can make incidents much easier to diagnose.

Build an audit record for every submission

For each clearance/reporting action, store enough information to explain what happened later.

A useful record can include:

internal invoice ID
invoice UUID
invoice counter
invoice type
EGS unit
payload hash
submission timestamp
environment
endpoint/action
attempt number
HTTP status
ZATCA result/status
error/warning codes
response reference
final resolution

Do not log private keys or other sensitive credentials.

Retain the original invoice data and relevant responses according to your tax, accounting, security and retention obligations.

The audit trail is what turns "the API returned an error once" into an operationally manageable process.

What should an operations dashboard show?

At minimum:

• pending B2B clearances;
• rejected B2B clearances;
• B2C invoices awaiting reporting;
• B2C reporting failures;
• oldest unresolved item;
• errors by branch/EGS unit;
• errors by validation rule;
• daily invoice counts;
• credential/integration health;
• queue backlog.

A traffic-light KPI such as "99.8% success" can be misleading if the remaining 0.2% contains old unresolved tax invoices.

Show age and actionability, not only percentages.

Use alerts based on business deadlines

Infrastructure alerts such as CPU and memory are not enough.

Useful e-invoicing alerts include:

B2C report pending > internal threshold
B2B clearance rejection detected
submission queue not draining
credential/authentication failures spike
one branch stops submitting
validation errors exceed baseline

Set the internal threshold comfortably inside any regulatory deadline.

If the external requirement permits 24 hours, an alert at hour 23 is not resilience.

A practical implementation timeline for Wave 25

Businesses have time before February 1, 2027, but integration work has several dependency layers.

September-October 2026: discovery and gap analysis

• confirm Wave 25 status/notification;
• identify every invoice-generating system;
• classify standard vs simplified invoices;
• review current data quality;
• choose ERP-native, adapter or replacement approach;
• map EGS units;
• assign finance and technical owners.

October-November: build compliance core

• implement canonical invoice model;
• generate required XML;
• implement security requirements;
• integrate validation tools;
• build audit/submission state model.

November-December: integrate APIs and sandbox

• complete onboarding flow;
• implement clearance;
• implement reporting;
• implement retry/rejection handling;
• test credit/debit notes;
• validate branch/POS behaviour.

December-January: production rehearsal

• load and failure testing;
• finance/UAT sign-off;
• reconciliation reports;
• operational dashboard;
• support runbooks;
• credential and backup review;
• staged rollout where possible.

Before February 1, 2027

• finish production onboarding;
• move all in-scope invoice flows to the compliant path;
• verify queues are empty/healthy;
• confirm monitoring and ownership.

Do not reserve onboarding and sandbox work for the final week.

A Wave 25 readiness checklist

• □We have confirmed whether ZATCA has targeted/notified the taxpayer for Wave 25.
• □Revenue criteria were checked against 2022, 2023, 2024 and 2025.
• □Every system that can issue an invoice or note is inventoried.
• □Standard and simplified invoice flows are explicitly separated.
• □Required invoice data can be represented at line and document level.
• □XML generation follows ZATCA's current specification.
• □Invoice UUID/counter/security requirements are implemented correctly.
• □EGS units are defined and onboarded appropriately.
• □Credentials are stored outside client applications and source code.
• □Standard tax invoice clearance is implemented.
• □Simplified tax invoice reporting is implemented.
• □B2C pending reporting is durably queued and monitored.
• □Rejected submissions remain visible until resolved.
• □Retries cannot create duplicate business transactions or reuse invalid sequencing.
• □Credit and debit notes are tested.
• □SDK/local validation passes for representative invoice types.
• □Sandbox clearance/reporting tests pass.
• □Network/API timeout behaviour is tested.
• □Multi-branch/EGS visibility exists where relevant.
• □Sandbox and production credentials are separated.
• □Finance can reconcile invoice records against submission state.
• □Support has a runbook for ZATCA failures.
• □Production monitoring alerts before regulatory windows become urgent.
• □The cutover is planned before February 1, 2027 rather than on the deadline.

Common implementation mistakes

Mistake 1: treating Phase 2 as a QR-code project

Phase 2 is a system integration, data, security and lifecycle project.

Mistake 2: using one flow for B2B and B2C

Standard invoices use clearance; simplified invoices use reporting. Their timing and failure behaviour differ.

Mistake 3: generating a PDF first and XML second

Generate from a canonical structured invoice model.

Mistake 4: storing failed submissions only in logs

Failures need durable operational state and ownership.

Mistake 5: putting ZATCA credentials in a POS/mobile client

Use a secure integration boundary and appropriate credential storage.

Mistake 6: testing one perfect invoice

Test rejection, timeout, duplicate, restart and offline scenarios.

Mistake 7: assuming the ERP vendor "supports ZATCA" without testing your customisations

Custom fields, tax logic, branches and integrations can create gaps outside the vendor demo.

Mistake 8: waiting until January to model invoice data

Data-model gaps are often slower to fix than the API client.

How should a business choose a ZATCA solution provider?

ZATCA states on its e-invoicing portal that taxpayers may use any solution provider as long as the solution complies with the e-invoicing requirements; use of a provider from an indicative directory is not itself the definition of compliance.

Evaluate a provider or development partner on:

• current ZATCA specifications;
• ERP/POS integration depth;
• ability to model your real invoice types;
• multi-branch architecture;
• failure/retry handling;
• observability and reconciliation;
• security/credential design;
• data migration;
• support after go-live;
• ownership of source code/configuration;
• ability to reproduce compliance tests.

Ask to see failure handling, not only a successful sandbox invoice.

FAQs

What is the ZATCA Wave 25 revenue threshold?

ZATCA says Wave 25 includes targeted taxpayers whose revenues subject to VAT exceeded SAR 187,500 during 2022, 2023, 2024 or 2025.

What is the Wave 25 integration deadline?

ZATCA's July 24, 2026 announcement says targeted Wave 25 taxpayers must integrate their e-invoicing solutions with the Fatoora Platform by no later than February 1, 2027.

Does Phase 2 require all invoices to be approved before the customer receives them?

No. The flow depends on invoice type. Standard tax invoices use ZATCA clearance before the cleared invoice is shared with the customer. Simplified tax invoices use reporting and must be transmitted to Fatoora within the required reporting window, which ZATCA's Detailed Guidelines state is 24 hours from issuance.

Can we keep our existing ERP for ZATCA Phase 2?

Often yes. ZATCA's guidance allows an existing e-invoicing solution to be updated for Phase 2 if it meets the integration requirements. The practical decision is whether the current ERP can represent the required data and integrate reliably, either natively or through a custom adapter.

Is a PDF invoice enough for ZATCA Phase 2?

No. ZATCA requires structured electronic invoices in the required format. The XML and business/security rules are core implementation requirements; a visual PDF alone is not a compliant structured e-invoice.

Does using a listed solution provider guarantee compliance?

No. ZATCA says taxpayers may choose any provider as long as the solution complies with the requirements. Compliance depends on the implemented solution and invoice behaviour, not merely appearing in a provider directory.

Conclusion

Wave 25 changes the audience for Saudi e-invoicing integration. With the threshold now at SAR 187,500 of VAT-subject revenue, Phase 2 can affect businesses that do not think of themselves as large-enterprise ERP programmes.

The safest implementation sequence is:

Confirm scope
→ map invoice sources
→ fix the data model
→ generate/validate XML
→ implement security and EGS onboarding
→ separate B2B clearance from B2C reporting
→ design durable retries and audit state
→ test sandbox failures
→ monitor production

The February 1, 2027 deadline is far enough away to implement this deliberately, but close enough that businesses with custom POS, ERP, booking, ecommerce or multi-branch systems should already be in discovery and integration work.

If your current ERP or operational platform cannot reach Fatoora cleanly, Softotic's custom software development service can build the integration layer around the existing system rather than forcing a full replacement. For browser-based ERP, portals or internal operations software, web application development can cover the surrounding workflow, reconciliation dashboard and support tooling.

Sources and references

• ZATCA: Wave 25 e-invoicing selection criteria and February 1, 2027 deadline
• ZATCA: E-Invoicing rollout phases
• ZATCA: E-Invoicing overview and Developer Portal
• ZATCA: E-Invoice specifications and XML Implementation Standard
• ZATCA: Compliance and Enablement Toolbox SDK
• ZATCA: Security Requirements
• ZATCA: Detailed Guidelines for E-Invoicing