Solutions — Saudi Arabia
We have built and delivered an ERP-integrated ZATCA e-invoicing solution: EGS onboarding, integration with the Fatoora platform, and automated compliance and validation around the finance systems you already run. This page explains how the programme actually works, what we build, and what it will need from your side.
ZATCA is the Zakat, Tax and Customs Authority, Saudi Arabia's tax authority. Fatoora is the name of its e-invoicing programme, and it has arrived in two distinct stages that are frequently confused with one another.
Phase 1, Generation, has applied since 4 December 2021. It requires invoices to be issued and stored electronically in a structured format, to carry the mandatory VAT fields, and — for simplified invoices — to display a QR code. Most businesses cleared this bar with a modest change to their existing billing system.
Phase 2, Integration, started on 1 January 2023 and has been introduced in waves defined by revenue thresholds. This is a different order of problem. Invoices must be produced as UBL 2.1 XML, or as PDF/A-3 with the XML embedded. Each one carries a UUID, a cryptographic stamp, a hash of itself, and the hash of the invoice before it — the PIH, or previous invoice hash — so that your invoices form a chain that cannot be quietly reordered or edited after the fact. The system generating them must be onboarded with ZATCA and must talk to the Fatoora platform directly.
On waves and thresholds: we do not name a "current" wave anywhere on this site. The thresholds have advanced repeatedly since the programme began and anything published here would date badly. We confirm which requirements and dates apply to you against ZATCA's published guidance at the start of every engagement.
The product is a compliance layer, not a finance system. It wraps what you already run.
Every unit that generates invoices — a POS terminal, an ERP instance, a billing service — is an E-invoicing Generation Solution and must be registered with ZATCA before it can issue anything compliant. We handle key generation, the certificate signing request, the one-time-code authentication against the Fatoora portal, and CSID issuance — automated, so onboarding a new till is a routine operation rather than a ticket.
We map your invoice data onto the UBL 2.1 structure ZATCA expects, including fields your ERP has probably never been asked for. This is where most projects get stuck: the XML is unforgiving about VAT category codes, buyer identification and rounding — and those are data problems in your master records, not bugs in the connector.
Each invoice is stamped with the certificate tied to its EGS, hashed, and linked to its predecessor through the PIH. We keep the chain intact across restarts, parallel submissions and the messy cases — an offline till, a document voided mid-sequence — because a broken chain is found late and is painful to repair.
Standard tax invoices are cleared with ZATCA before they reach the buyer. Simplified invoices reach the buyer immediately and are reported within 24 hours. These are genuinely different engineering problems — one sits on your critical path, the other does not — and we build them as such rather than forcing both through one pipe.
Compliant QR generation for simplified invoices, plus the practical work of getting it onto a receipt a thermal printer can render and a customer can scan. We also handle Arabic and English presentment, and PDF/A-3 output with the XML embedded where you want one document to archive.
We validate before submission rather than learning of problems from a rejection. Invoices are checked against the schema and business rules locally, so a malformed document is caught where it is cheap to fix — and the ones that do fail at ZATCA come back with a readable message rather than an error code.
In practice this means an integration layer, not a rip-and-replace. We have designed the solution to sit around SAP, Microsoft Dynamics, Odoo, custom in-house ERPs and POS systems, taking invoices through whichever door a given system offers — an API, a database view, a file drop, a message queue. Your finance team keeps its ERP and its habits.
Every submission, response, stamp and hash is stored, so an auditor's question years from now has an answer that does not rely on someone's memory. Retention is aligned to Saudi record-keeping obligations, with data residency decided deliberately rather than by accident of hosting.
Rejections, warnings, timeouts and offline terminals are normal operating conditions. Failed submissions queue and retry where retrying is safe; anything needing a human lands in a work queue with the validation message. Finance sees what has cleared, what has not, and what is about to breach a 24-hour reporting window.
Plenty of vendors sell e-invoicing middleware. What tends to be underestimated in Saudi Arabia and the UAE is that the compliance code is the small part. The hard parts are organisational.
Estates are fragmented. A group in Riyadh or Jeddah rarely runs one ERP. It runs a main ERP, an inherited system in a subsidiary, a POS estate a franchise partner controls, and a spreadsheet nobody admits to. ZATCA does not care: each generating unit still needs onboarding and still needs to produce valid documents. Scoping the estate honestly is the first real deliverable.
The specification moves. ZATCA has updated its rules and validation behaviour more than once, and it would be naive to assume it is finished. This is the strongest argument for isolating the compliance layer behind a clear boundary: when the specification changes, we change one component, retest it in the sandbox and redeploy — without touching your general ledger or reopening a POS integration you had finished with. Teams that embedded ZATCA logic in ERP customisations have paid for that decision repeatedly.
Sandbox first, always. ZATCA provides developer and simulation environments, and we use them properly: real invoice shapes from your history, not three happy-path samples. Simulation is where you discover that a legacy customer record has no valid buyer identifier, or that credit notes reference invoices predating the programme. Finding that in production, with clearance blocking your B2B billing, is what the sandbox is there to prevent.
Regional context. We work across the UAE, Saudi Arabia and India, and we have real clients in the Kingdom — RiyadhPharma among the logos on our site. The UAE is moving on its own e-invoicing track, and groups operating both sides of the border sensibly want a compliance layer that can serve more than one regime rather than two disconnected projects.
Almost every design decision in a Phase 2 project traces back to this table. It is worth being precise about it before anyone writes code.
| Clearance | Reporting | |
|---|---|---|
| Invoice type | Standard tax invoice — typically B2B and B2G | Simplified tax invoice — typically B2C |
| When it goes to ZATCA | Before the buyer receives it | Within 24 hours of issue |
| Who sees it first | ZATCA. The invoice may only be shared once cleared. | The buyer, at the point of sale. |
| On failure | Not cleared, so it cannot be issued. Data must be corrected and resubmitted. | The customer already has it. The rejection is a compliance gap to close and evidence. |
| Engineering consequence | Synchronous and on the critical path. Latency and downtime are billing problems. | Asynchronous and queued. Tills must keep selling when the link is down. |
| QR code | Applied per ZATCA's rules for the cleared document. | Mandatory on the invoice given to the customer. |
The row that costs money is the last but one. If clearance is on the critical path, then an outage in your integration is an outage in your ability to invoice B2B customers. That argues for careful queueing, idempotent submission and honest monitoring — not for optimism.
We inventory every system that issues an invoice, confirm the applicable ZATCA requirements against current published guidance, and look at your real invoice data — including the awkward ones. Deliverable: a scoped estate and an honest view of your data quality.
We agree where the compliance boundary sits, how each ERP or POS hands over invoices, how CSIDs are managed across branches, where data resides, and what happens when a submission fails. Decisions get written down — including the ones we would revisit if the specification changes.
Mapping, stamping, hashing and PIH chaining are built and exercised in ZATCA's sandbox and simulation environments against your invoice history — standard and simplified, credit and debit notes, the lot. We would rather find the failures here.
Production onboarding, a phased cutover where the estate allows it, and monitoring your finance team can read. Afterwards we track ZATCA's updates and keep the compliance layer current — which is the whole reason it is a separate layer.
We would rather be direct about this than discover it in week three. A ZATCA project moves at the speed of the answers to these questions.
The ERP-integrated ZATCA E-Invoice solution is a real product of ours, covering EGS onboarding and integration, broad ERP compatibility and automated compliance and validation. We are not learning the programme on your budget. You can see the rest of what we have built on our work.
We serve clients across Saudi Arabia, the UAE and India — RiyadhPharma is among the Saudi client logos on our site. Our Saudi Arabia team understands that a tax deadline is a business deadline and does not move.
ZATCA compliance is an integration problem wearing a tax hat. We build custom applications, ERP platforms and SaaS products that have to talk to systems their owners cannot change — which is exactly this shape of problem.
Phase 1, called Generation, has applied since 4 December 2021. It requires you to issue and store invoices electronically in a structured format, to include the mandatory VAT fields, and to print a QR code on simplified invoices. Phase 2, called Integration, began on 1 January 2023 and has been rolled out in waves. It is a much bigger change: your invoices must be produced as UBL 2.1 XML, carry a cryptographic stamp, a UUID, an invoice hash and the hash of the previous invoice, and your generating solution must be onboarded to and talk directly to ZATCA's Fatoora platform. Phase 1 is a formatting exercise. Phase 2 is a systems integration project.
In our experience, almost never. Your ERP already knows how to price, tax and post an invoice, and replacing it is expensive and risky for reasons that have nothing to do with tax. What we build instead is a compliance layer that sits alongside it: it takes the invoice your ERP already produces, turns it into compliant UBL 2.1 XML, stamps and hashes it, exchanges it with Fatoora, and writes the outcome back. Your finance team keeps working in the system they know.
An EGS, or E-invoicing Generation Solution, is the unit that generates your invoices — a POS terminal, an ERP instance, a billing service. Each must be registered with ZATCA before it can issue compliant documents. Onboarding means generating a key pair and a certificate signing request, authenticating against ZATCA with a one-time code from the Fatoora portal, and receiving a CSID — a cryptographic stamp identifier. That certificate proves an invoice came from a registered device. Managing these identities across many branches and terminals, including renewal, is usually more operational work than the integration itself.
Standard tax invoices — typically B2B and B2G — must be cleared. You send the invoice to ZATCA first and you may only share it with the buyer once it has been cleared. Simplified tax invoices — typically B2C — work the other way round: the buyer gets the invoice immediately at the point of sale, and you report it to ZATCA within 24 hours. The practical consequence is that clearance sits on your critical path and reporting does not, which is why the two flows need different engineering.
It depends on the flow. A rejected standard invoice has not been cleared, so it cannot be issued: someone must correct the data and resubmit. A rejected simplified invoice has already reached the customer, so the problem is a compliance gap to close and evidence. There is also a middle category — warnings — where the document is accepted but flagged, and those often precede a rejection after a specification update. We treat rejections as an operational reality, not an edge case: every submission and response is stored, failures are queued and retried where safe, and anything needing human judgement lands in a work queue with the validation message attached.
We will not answer that from a web page, and you should be sceptical of any vendor who does. ZATCA has announced Phase 2 in successive waves defined by revenue thresholds, and those thresholds have advanced repeatedly since the programme began. Any figure written down here would eventually be wrong and could cause you to plan around the wrong date. We confirm the applicable requirements and timing against ZATCA's published guidance at the start of each engagement, and we would rather tell you the deadline is nearer than you hoped than reassure you with a stale number.
It depends far more on your invoice data than on the integration code. A single ERP with clean master data and one invoice type is a comparatively short piece of work. Several ERPs, a POS estate across many branches, credit and debit notes, and mixed standard and simplified flows take considerably longer, and most of that time goes on data quality and testing in the sandbox rather than on writing the connector. In our experience the honest answer only appears after discovery, so we scope the sandbox work first and commit to production dates once we have seen your real invoices.
Tell us which systems issue your invoices and roughly how many you raise. We will tell you what the work looks like, where we think the risk sits, and if the honest answer is that a smaller change gets you compliant, we will say so.