Reachware Fatoora in Saudi Arabia: implementation and integration, assessed on the evidence. Reachware Fatoora is a Reachware product and we build, implement and support it, and we make no compliance guarantee on anyone's behalf — including our own.
E-invoicing in the Kingdom is not optional. The Zakat, Tax and Customs Authority has launched the E-Invoicing (Fatoorah) requirements in two phases — Phase 1 from 4 December 2021 and Phase 2 from 1 January 2023 — so the question was never whether to comply but which route gets you there with the least breakage. Reachware describes Fatoora as a fully automated e-invoicing solution for ZATCA compliance in Saudi Arabia. That is the vendor's description, and it is a reasonable starting point; it is not a finding of ours.
Your billing systems are several, not one, and each would otherwise need its own path to ZATCA. You are already running other Reachware components, so the integration surface is short. Or your ERP's own e-invoicing module exists but does not cover the invoice types you actually issue, and you need a layer that does without replacing the ledger.
We do not recommend a separate e-invoicing platform when your ERP already clears every invoice type you issue: you would be adding a hop, a licence and a failure mode to a chain that works. We also advise against it when the real problem is upstream data quality — missing tax numbers, wrong item classifications, addresses that will not validate — because no clearance layer fixes a bad invoice, it only rejects it faster. In both cases start with a fit assessment of the invoice chain you already have.
Attributed, because that is the only honest way to write it: Reachware publishes that Fatoora is a fully automated e-invoicing solution ensuring seamless ZATCA compliance in Saudi Arabia, and it sits inside Reachware's integration suite alongside Connect, Studio and the rest. What that resolves to for your invoices — which document types, which clearance and reporting flows, which fields your systems must supply — is a scope question, and we put it to the vendor in writing rather than answering it here.
First and most important: no product makes you compliant. ZATCA publishes the specifications, the data dictionary and the XML implementation standard, and compliance is a property of what your systems actually emit against them. A solution helps; it does not absolve. Second, we make no statement about any certification, approval or listing held by this product or by us — we hold none relevant here and we assert none on the vendor's behalf; check ZATCA's own published materials for anything of that kind. Third, an e-invoicing layer is only as good as the master data feeding it, which is where most Phase 2 programmes actually spend their time.
ZATCA describes electronic invoicing as converting the issuing of paper invoices and notes into an electronic process that allows invoices, credit notes and debit notes to be exchanged and processed in a structured electronic format between buyer and seller. Two things follow for a Saudi finance function. Every invoice-issuing system in the estate is in scope, not just the main one — the point-of-sale estate, the billing engine, the service desk that raises ad-hoc charges. And VAT at 15% has to be represented correctly in each of them, because a clearance failure is a tax problem before it is an IT problem. That is why we scope from the invoice population outward rather than from the platform inward. See the payments and e-invoicing category for the wider picture, and retail for the multi-till case.
We publish no price; Reachware publishes none, and an invented figure is worse than silence. The model we build has four lines: the licence or subscription as quoted to you; the connector work per invoice-issuing system, which is where the cost actually lives; the master-data remediation that Phase 2 exposes and nobody budgets for; and the ongoing cost of keeping the integration current as specifications are updated. We model all four with your numbers.
Three honest routes exist. Your ERP's own e-invoicing capability, if it covers your document types — usually cheapest when it fits. A dedicated e-invoicing platform such as this one, when the estate is fragmented. Or a direct integration built against ZATCA's published specifications and developer portal, which is the most control and the most maintenance. We score all three against your invoice population and publish the method, not a ranking; our software comparisons show that shape of work.
We inventory every system that issues a document ZATCA cares about, and the invoice types each produces. That inventory decides the answer. We take no margin on any licence and we do not bid on implementations we scope, which is what makes "your ERP already does this" a possible outcome.
The chain runs from the system that raises the document, through the tax logic, through whatever clears or reports it, back into the ledger and the archive. We prove the return path first — rejections and their handling — because a programme that only tests the happy path discovers its real workload in production.
Finance needs to work rejections, not just watch a dashboard, so training is built around the exception queue and the audit trail. Branch and billing staff learn what makes a document fail before it fails. The first full billing cycle after go-live runs with us on call.
We publish no counters here. The outcome that matters is agreed with you before the work starts — typically the rejection rate and the time to resolve a rejected document — and it is measured against your own baseline. A figure from someone else's estate tells you nothing about yours.
It tracks the number of invoice-issuing systems and the state of their master data, not the platform. We size it once the document inventory exists and put the assumptions in writing beside the estimate.
Licence, per-system connector build, master-data remediation, and keeping the integration current as specifications change. We do not publish a benchmark: invoice estates differ too much for one to mean anything.
We do not answer that with a claim, and you should be wary of anyone who does. Compliance is a property of your deployment measured against ZATCA's published specifications, data dictionary and XML implementation standard. What we do is test your actual documents against those published requirements, establish where the data is hosted, and obtain the vendor's own written statements for your tax and compliance functions to assess. Any certification or listing question is referred to ZATCA's own materials.
Your existing ERP's capability first, then the dedicated-platform route, then direct integration against ZATCA's developer portal. Each is recorded in the assessment report with the reason it was kept or dropped.
Not replacing the billing systems is the point of a clearance layer. Whether it integrates with yours is an evidence question answered by a per-system interface inventory and a written vendor confirmation for each, which the assessment collects.
We publish no facts of that kind here, because the honest ones are not numbers. What we will state: we take no licence margin, we do not bid on implementations we scope, and every engagement ends in a written recommendation you keep whether or not you hire us again.
We name organizations only with their consent and in direct conversation, never on a product page. Ask for references in your sector and we will arrange the calls.
No composite case study appears here. Relevant work is walked through attributably in a first conversation — the standard we suggest you hold every bidder to, ourselves included.
We publish no testimonial quotes on this page. Speak to our references directly; it carries more weight than a curated pull-quote.
Certifications and partnerships are listed in proposals, where they are current and checkable, and we assert no certification, approval or listing for this product or for ourselves — not with ZATCA, not with anyone. On an e-invoicing page, where badges are used as a substitute for evidence, that matters. The material fact for this page is stated plainly instead: Reachware Fatoora is a Reachware product and we build, implement and support it, so this is the position of the team that would do the work, not an arm's-length comparison. What qualifies the advice is method: a documented invoice inventory and a written scope.
Continue with the payments and e-invoicing category, our software comparisons, the retail sector page, or a fit assessment.
A word about "neutral", because we would rather say it than have you wonder: we build and support this platform, so we cannot offer you neutrality between vendors on this page. What we can offer, and do, is neutrality about whether a separate e-invoicing layer is the right route at all — the section above on when we don't recommend it is on this page for that reason. Bring us your list of invoice-issuing systems, or let us build it. You will leave with a written position on the route that fits and what it would cost. Request a demo or book a fit assessment.
Unlimited support included.
One-on-one onboarding sessions.
Training videos, webinars, & demos.