ZATCA Phase 2 requirements for Saudi businesses

When an invoice is rejected after being issued from the ERP or the point of sale, the problem is not just a technical file. A collection can stall, a shipment can be delayed, or finance can end up handling a manual exception under the pressure of close. So ZATCA Phase 2 requirements begin with regulatory compliance but end, in practice, with the organisation's ability to issue correct, auditable documents however high the volume or however many legal entities are involved.

Phase 2, known as the integration phase, does not necessarily mean replacing the invoicing system you already run. It means the invoice-issuing system must integrate with the Zakat, Tax and Customs Authority's system according to the mandate wave notified to the business, and must enforce specific controls over data, signing, submission and response. The date that matters to any business is its own wave date as given in the Authority's notice, not a general date assumed to apply to everyone — the Phase 2 waves and their published criteria are explained in a separate article.

What does Phase 2 actually change?

Phase 1 focused on issuing an e-invoice containing the right elements and code. In Phase 2, the invoice's path becomes connected to the Authority. Standard tax invoices, used mostly in business-to-business transactions, go through clearance before being shared with the buyer. Simplified tax invoices, common in consumer sales, are reported to the Authority within the statutory window, which extends to 24 hours from the time of issue.

That difference is not cosmetic. Clearance makes the Authority's response part of the invoice's sales journey, while reporting makes queue reliability, retries and deadline monitoring essential. A business handling both needs clear rules for classifying the invoice before submission starts, not after a rejection appears. The full difference between the two types deserves a separate read.

Producing a readable file or a paper copy is not enough either. The invoice must be created in a structured format conforming to the Authority's specifications, built on the e-invoice standard, with the mandatory fields and local rules. It is then signed and stamped technically using certificates and stamps bound to the solution unit doing the issuing.

The core ZATCA Phase 2 requirements

The requirements divide between the identity of the unit issuing the invoice, the correctness of the document's content, and how it communicates with the Authority. Each layer has a different operational consequence.

Onboarding the solution unit and its certificates

Every system, device or logical unit that issues invoices needs proper onboarding. The process starts with registering the unit and obtaining the required credentials and certificates, then using the correct certificate in the test and production environments. This data should not be treated as configuration set once and forgotten: certificate validity, key rotation, and changes of device or application are all events that belong in operating procedures — and the detail of the electronic seal certificate has its own article.

The private key used for signing is a highly sensitive security asset. Keeping it in exposed files on an application server, or passing it between development and operations teams, creates a risk that a successful submission to the Authority does not address. The more disciplined approach keeps it in secure custody, using a hardware security module or a governed key service, with a clear separation of duties and an audit record of every use.

Invoice structure and data correctness

The invoice should carry supplier and buyer details where applicable, the VAT number, the issue date, invoice numbers, line descriptions, and quantities, prices, VAT and totals that are arithmetically consistent. But the common mistake is treating field completeness as sufficient. Real validation covers the relationships between fields: does the tax rate match the supply type? Do the lines, discounts and tax sum to the total? Are the currency, the codes and the permitted values correct?

The invoice also needs a unique identifier, a technical link to the chain of previous invoices where the specifications require it, and a hash, a signature and an electronic stamp. These elements make the document verifiable and reduce the scope for tampering, but they oblige the business to manage ordering, counters and retry cases precisely. Resubmitting the same transaction after a network drop, for instance, must not turn into two separate invoices. The invoice structure and its elements are explained in detail separately.

Sequential numbering deserves particular attention. The system has to guarantee that documents are not duplicated and the sequence is not lost through retries, loss of connectivity, or the existence of more than one issuing channel. In an environment with stores, points of sale, branches and e-commerce platforms, this is not solved by making the invoice number longer, but by managing a trusted issuing source, unique identifiers, and a clear state for every document from creation to acceptance or rejection.

The QR code and the visual representation

The QR code is mandatory according to the invoice rules and its type. In Phase 2 it is no longer just a code showing the seller's name and the total; it carries additional data tied to the signature, the stamp and verification. And the visual copy the customer sees must match the structured data submitted to the Authority. If the point of sale prints data from one source while the integration engine submits data from another, discrepancies appear that are hard to find at review time.

Clearance, reporting and managing the response

Once the document is built, validated and signed, it is submitted to the Authority through the approved interface. For a standard invoice, it should not be made available to the buyer as final before the required clearance result is received. For a simplified invoice, the system must be able to prove that reporting happened within the window, even if the business hit a temporary outage or network pressure.

The response is not always a simple acceptance or rejection. There may be warnings, errors in the document structure, certificate-related errors, or a transient connectivity problem. Good operational design distinguishes the error that needs a data correction, the error that calls for an automatic retry, and the error that must escalate to a specialist team. Rejection is part of the workflow, not a crisis handed to a finance clerk without explanation.

Validating before submission reduces costly rejection

Pre-submission validation is the most efficient line of defence. The system can detect conflicting amounts, missing mandatory fields, registration-number errors, or tax mismatches before the document reaches the Authority. It does not remove the need for the official validation, nor does it justify copying old rules without managing regular specification updates.

That matters more in businesses running complex tax rules, discounts, multi-currency sales, or invoices tied to long contracts. Edge cases need testing: partial notes, line-level and document-level discounts, zero-rated or exempt tax where it applies, and linking a note to the original document. Every case should have an expected result and a named owner for signing it off across tax, finance and technology.

Where large organisations stumble

The problem is usually not the first invoice that succeeds in the sandbox. The challenge starts when the group issues thousands of invoices across branches, sales channels, e-commerce platforms and several legal entities. Each entity has its own VAT number, compliance context, certificates and master data that may differ, while management expects central visibility and control.

Relying on direct customisation inside every ERP or point of sale raises the cost of change with every regulatory amendment. Turning each system into an expert on the Authority's specifications, certificates, retries and audit records duplicates the same burden in several places. The practical alternative is one integration layer that receives a single data shape from internal systems, then applies the validation, mapping, signing and submission rules according to the entity and the invoice type.

But unification does not mean ignoring differences. The legal entity must stay isolated in permissions, data, certificates and operating records, even when the group administers all of it from a central account. Where data is stored, the retention policy, and the ability to export the audit record should also be explicit engineering and commercial decisions rather than details deferred until after launch.

An implementation plan that reduces risk

Start by inventorying invoice sources, not just applications. Determine where the invoice is actually created: the ERP, the point of sale, the subscription platform, the e-commerce gateway, or an external service. Then classify the flows into standard and simplified, and identify the legal entities, branches and issuing units in each flow.

Next, test data quality before connecting production. Review VAT numbers, unit codes, discount rules, exemption cases, currencies and VAT totals. That stage saves more time than any later API improvement, because most early rejections come from master data or inconsistent pricing logic rather than a connectivity problem.

Testing should include the failure scenarios, not just the acceptance path. Test an expiring certificate, a temporary service outage, a repeated submission request, a returned invoice, a backed-up queue, and a change of tax rate or supply type. Then agree the owner of every decision: who corrects the data? Who reviews warnings? Who may reprocess? And who watches that simplified invoices were reported within the window? The readiness checklist gathers these points into a trackable form.

What should appear in the audit record?

Compliance responsibility does not end at acceptance. The business needs a tamper-proof record tying the source document, the submitted payload, the Authority's result, the time of each event, and the identity of the system or user that acted. Rejection reasons, attempt copies, transaction identifiers and resubmission events should all be retained.

These records serve more than an external audit. They help finance explain the difference between sales and accepted invoices, let technology diagnose faults, and give tax management practical evidence of compliance. The more legal entities there are, the more necessary logical separation of data, permissions and approvals becomes — even when operational administration is central.

How this looks in alFatora - الفاتورة

alFatora Connect carries this whole layer while your systems stay as they are: one integration on a stable JSON shape, then validation before submission, signing and stamping under secure key custody, QR generation, clearance or reporting by document type, each document's status by webhook, and an immutable audit trail tying request to result.

The sandbox is free and unlimited, so you can test rejections, an expiring certificate and a backed-up queue before any of it touches production. And credits burn on documents the Authority actually accepts, not on failed attempts or experiments.

Real Phase 2 readiness shows when the organisation can answer three questions immediately: where is every invoice now? Why was it rejected, if it was? And who owns the next action? When those answers are documented and actionable, ZATCA's requirements turn from a burdensome compliance project into an operation you can trust.