Search for "ZATCA approved invoicing software" and you will find dozens of vendors claiming to be certified. That framing is misleading, and it is the single most expensive misunderstanding a Saudi business can carry into a procurement decision. The Zakat, Tax and Customs Authority (ZATCA) does not hand out a permanent seal of approval to invoicing products. What it publishes is a technical specification, a set of prohibited functions, and a compliance process that your installation has to pass — through the Fatoora portal, under your VAT registration number.

That distinction changes how you should evaluate software. You are not shopping for a badge. You are shopping for a solution that can generate the exact XML ZATCA expects, stamp it cryptographically, chain it to the previous invoice, produce a valid QR code, and talk to ZATCA's APIs without you touching a line of code — and a vendor who will still be doing all of that after the next specification update. This guide walks through the technical criteria that separate a genuinely compliant solution from a marketing promise, the questions to put to a vendor before you sign, and a five-step migration plan.

Why "ZATCA-certified software" is not a real category

Saudi e-invoicing rolled out in two stages. Phase 1 (the Generation phase) started in December 2021 and required every resident VAT-registered taxpayer to stop issuing handwritten or scanned invoices and start producing structured electronic invoices with the mandated fields. Phase 2 (the Integration phase) started in January 2023 and is being rolled out in waves, with ZATCA notifying each group of taxpayers in advance of their integration date. Our complete ZATCA e-invoicing (Fatoora) Phase 2 guide covers that structure in full — read it first if you are new to the mandate, and treat it as the hub this article hangs off.

Compliance in Phase 2 is established at the level of the taxpayer's onboarded solution unit, not at the level of the product name. The practical sequence is: your solution generates a certificate signing request, you authorise it in the Fatoora portal with a one-time password tied to your VAT account, ZATCA issues a cryptographic stamp identifier, and your invoices are then validated against ZATCA's rules on every submission. A vendor can build software that makes all of this effortless — but the compliance itself attaches to your onboarded unit, and it can be broken by a bad update, an expired certificate, or an unpatched schema change.

So the right question is never "is this product certified?" It is "can this product pass ZATCA's validation today, keep passing it after the next specification release, and prove it to me before I commit?"

The technical criteria that actually decide compliance

Use the list below as a scorecard. A solution that cannot clearly demonstrate all of these is not ready for Phase 2, regardless of how it markets itself.

1. UBL 2.1 XML generation, not PDF with an XML attachment bolted on

A Phase 2 invoice is an XML document that conforms to ZATCA's implementation of UBL 2.1. The human-readable copy your customer sees is a rendering of that XML, not the source of truth. If a vendor's architecture starts from a PDF template and generates XML as an afterthought, you will hit field-mapping failures the first time an edge case appears — a discount line, a reverse-charge supply, an export sale. We break down how these documents are assembled in ZATCA QR code and XML (UBL 2.1): how Phase 2 invoices are built.

2. Cryptographic stamping, UUID and invoice hash chaining

Every Phase 2 invoice carries a universally unique identifier, a cryptographic stamp produced with the certificate issued during onboarding, and a hash of the previous invoice. That last element is what makes the sequence tamper-evident: change one historical invoice and every subsequent hash breaks. Ask the vendor how the chain is maintained across multiple branches, devices or point-of-sale terminals, because each onboarded unit maintains its own chain and a naive implementation will corrupt it the moment you open a second location.

3. Correct handling of both invoice types

Standard tax invoices (typically B2B and B2G) and simplified tax invoices (typically B2C) follow different paths. Standard invoices go to ZATCA for clearance before you share them with the buyer; simplified invoices are reported to ZATCA after issuance, within the window set by the regulations. A solution that treats every document identically will either block your retail counter waiting for a clearance response it does not need, or fail to clear a B2B invoice that legally requires it. The distinction, and the different mandatory fields each type carries, is covered in simplified vs standard tax invoice in Saudi Arabia.

4. A QR code that encodes the right data in the right format

The QR code on a Saudi e-invoice is not a link to a web page. It is a TLV-encoded, Base64-represented payload carrying specified fields such as the seller name, VAT registration number, timestamp, invoice total and VAT amount, plus stamping data in Phase 2. Scan a sample invoice from the vendor with any ZATCA-compatible reader during your evaluation. If the code resolves to a URL or returns garbled values, the implementation is wrong.

5. Arabic as a first-class language

Arabic is mandatory on the invoice. Additional languages are permitted alongside it, but Arabic cannot be the afterthought. Check the rendering of a real invoice: right-to-left layout, correct Arabic numerals and date handling, seller and buyer names in Arabic, and no truncation where a template was designed for English and later translated. A vendor that only shows you an English demo is showing you an untested path.

6. Security controls and the prohibited-functions list

ZATCA's technical resolution explicitly prohibits certain capabilities in an e-invoicing solution — among them anonymous or uncontrolled user access, the ability to export the cryptographic stamping key, the ability to delete or modify audit logs, and the ability to tamper with the system clock. Ask for documentation showing how the vendor blocks each of these. A product that lets an administrator quietly delete an issued invoice is not a compliance product.

7. Record retention and where your data lives

Saudi VAT rules require invoices and related records to be retained for a defined minimum period and to remain available to ZATCA on request. Establish in writing where invoice data and audit logs are stored, how you export the full archive if you leave the vendor, and in what format. "You can download a CSV" is not an archive of signed XML documents. Confirm the current retention period and hosting requirements against ZATCA's published regulations before signing, as these are the details most often stated loosely in sales material.

8. API integration, not manual upload

Phase 2 is machine-to-machine. If any part of your day involves exporting a file and uploading it somewhere by hand, the integration is not finished. The requirements and the wave structure that determines your own deadline are laid out in ZATCA Phase 2: integration requirements and rollout waves.

9. Sandbox access and demonstrable test results

ZATCA provides a simulation environment so that solutions can be validated before going live. A credible vendor will show you their own validation results and will let you run your real invoice scenarios — credit notes, debit notes, foreign-currency sales, zero-rated exports — through a sandbox before your go-live date. Treat reluctance here as a red flag.

10. A maintenance commitment

The specification has been revised repeatedly since 2021 and will be revised again. What matters is the vendor's track record on shipping those updates before the enforcement date, and whether updates are included in your subscription or billed as a project. Ask for the dates of the last three specification changes and what the vendor shipped in response.

What to ask a vendor before you sign

Take these questions into the demo. The answers are more revealing than any feature list.

  • "Walk me through onboarding for my VAT number." You want to see the certificate request and OTP flow, not a screenshot.
  • "Show me the raw XML of a cleared standard invoice." If nobody on the call can produce one, the team you would depend on does not work at that level.
  • "How do you handle a rejected submission?" There must be a visible queue, the ZATCA error message in readable form, and a retry path — not a silent failure.
  • "How many onboarded units do I get, and what happens when I add a branch?" Pricing that punishes a second location will shape your operations badly.
  • "What is my exit?" Full export of signed XML plus human-readable copies, on demand, without a fee.
  • "Who is liable if your software causes a non-compliant submission?" Read the contract's limitation-of-liability clause rather than accepting the verbal answer.

Matching the solution to the size of your business

The right answer differs sharply by scale, and overbuying is as damaging as underbuying.

Freelancers and small establishments issuing a modest number of invoices a month need a cloud solution that handles onboarding, clearance and reporting invisibly. The deciding factors are Arabic invoice quality, a usable mobile experience, and predictable pricing. An on-premise deployment or a middleware licence is wasted money at this scale.

Growing SMEs with several users, branches or a retail counter should focus on the multi-unit questions: separate onboarded units per device or branch, correct chaining per unit, role-based access, and a clear view of which invoices are cleared, reported, pending or rejected.

Larger enterprises already running an ERP usually need middleware that sits between the ERP and ZATCA rather than a replacement billing system. Here the evaluation centres on connector maturity for your specific ERP version, throughput, and how failures are surfaced to a finance team that will not be reading API logs.

Across all three, confirm that your VAT treatment is handled correctly for your actual sales mix. The standard rate, zero-rated exports and exempt supplies each behave differently on a compliant invoice — see VAT in Saudi Arabia: rates, registration and returns for how those categories map onto your invoicing.

A five-step migration plan

  1. Confirm your integration date. ZATCA notifies taxpayers of their wave in advance. Work backwards from that date and give yourself a buffer of at least one full month for testing.
  2. Inventory what you issue today. List every document type you produce — standard invoices, simplified invoices, credit notes, debit notes, advance payments, foreign-currency sales — because every one of them has to survive the migration, and the awkward ones are where implementations fail.
  3. Clean your master data. VAT registration numbers, commercial registration details, Arabic legal names and national addresses must be correct before onboarding. Bad master data is the most common cause of rejected submissions and it is entirely preventable.
  4. Onboard and test in the sandbox. Push your real scenarios through the simulation environment, fix what fails, and keep the validation output as evidence.
  5. Run a short parallel period, then cut over. Issue through the new solution while keeping the old process available for reconciliation, verify that clearance and reporting responses are arriving as expected, then retire the old system and archive its records.

Common mistakes worth avoiding

Three patterns cause most of the pain we see. The first is believing a certification claim instead of testing the solution against your own invoice scenarios. The second is leaving migration until the notification deadline is weeks away, which removes any room to discover that a document type does not validate. The third is treating e-invoicing as an IT project rather than a finance one — the people who know why an invoice is structured the way it is sit in accounting, and a technically perfect integration that produces the wrong VAT treatment is still a compliance failure.

Getting compliant without rebuilding your billing

Facturi issues structured e-invoices with Arabic as a native language, keeps the human-readable and machine-readable copies in sync, and stores a complete, exportable archive of everything you issue — so your records are ready when ZATCA asks for them. If you are choosing a solution for the Saudi market, or moving off a tool that has not kept pace with the specification, start with Facturi and put your real invoice scenarios through it before you commit.

One closing caution: the details in this article reflect the structure of the ZATCA e-invoicing framework, but specification versions, wave thresholds and retention rules are updated periodically. Always verify the current requirements and your own integration date against ZATCA's official publications and the notification sent to your VAT account before making a purchasing decision.