The cost of ZATCA Phase 2 integration depends far less on the FATOORA API itself than on the scope around it: how many systems, branches and point-of-sale (POS) terminals issue invoices, whether your ERP has a supported Phase 2 module or needs middleware or a custom build, how clean your customer master data is, which document types you issue, how much testing and onboarding is involved, and who runs the solution after go-live. Two companies with similar revenue can face very different budgets because of these factors.
This guide does not quote prices. Rates vary by vendor, ERP and scope, and any figure published without seeing your systems would mislead you. Instead, it explains each cost driver so you can scope the work properly, ask vendors the right questions and compare quotes on equal terms. If you need the technical background first, read our ZATCA Phase 2 integration guide.
Invoicing sources, branches and EGS units
Under Phase 2, every system that issues tax invoices, simplified tax invoices, credit notes or debit notes must be onboarded with ZATCA as an E-invoice Generation Solution (EGS) unit and receive a Cryptographic Stamp Identifier (CSID). The number and spread of these units is often the single biggest scope factor.
What multiplies the effort
- Number of source systems. An ERP, a separate billing platform, an e-commerce store and a POS system are four integrations, not one, unless a middleware layer consolidates them.
- Branches and POS terminals. Each EGS unit keeps its own invoice counter (ICV) and previous-invoice hash (PIH) chain. Many tills or branches mean more units to onboard, more keys to protect and more chains to keep intact.
- Offline or intermittent sites. Locations with unreliable connectivity need careful design so simplified invoices are still reported to FATOORA within 24 hours of issue.
- Manual or spreadsheet invoicing. Any invoices produced outside a system must move into a compliant solution, which can mean new process design as well as technology.
Questions to answer before you ask for quotes
- How many systems issue invoices or notes today, and which of them will still exist after any planned ERP change?
- How many branches, POS terminals and other devices issue invoices?
- Will you onboard one unit per device, per branch or per system, and why?
- Which sites have connectivity constraints?
A clear inventory lets vendors price the same scope. Without it, each quote rests on different assumptions.
Native ERP module, middleware or custom build
The integration route moves cost between licences, implementation effort and long-term maintenance. None is cheapest in every case.
| Cost factor | Native ERP module | Middleware / connector | Custom build |
|---|---|---|---|
| Upfront licence or subscription | Often an add-on or localization package | Subscription or per-unit fees are common | Usually none, but development effort is highest |
| Implementation effort | Lower if your version is supported | Moderate: mapping and connection per source | Highest: XML, signing, hash chain, APIs |
| ERP upgrade dependency | High: older versions may need upgrading first | Low | Low |
| Multiple source systems | Weak | Strong | Strong, with more effort |
| Maintenance when ZATCA updates specifications | Vendor-led, usually tied to your support plan | Shared with the provider | Fully in-house |
| Hidden cost to watch | A forced ERP upgrade | Per-unit or volume-based fees as you grow | Specialist skills you must retain |
When a native module costs more than it looks
A native module is usually simplest when your ERP version is current and lightly customized. It becomes expensive when the module requires an ERP upgrade, when heavy customizations break during that upgrade, or when the module does not cover all your document types.
When middleware or custom work is justified
Middleware suits businesses with several invoicing systems or an ERP that cannot be upgraded soon. A custom build suits teams that already maintain their own billing software and have the skills to manage cryptographic keys, certificates and specification changes. Either way, ask who absorbs the cost when ZATCA updates its technical specifications.
Master data, credit notes and special invoice types
Much of the effort in a Phase 2 project sits in data and documents rather than in the connection itself.
Customer master data
Standard tax invoices are validated by FATOORA before they reach the buyer, so data errors become rejected invoices. Typical cleanup work includes:
- Verifying customer VAT registration numbers.
- Completing national addresses and commercial registration details for business customers.
- Checking product and service VAT categories and exemption reasons.
- Removing duplicate customers and closing obsolete accounts.
The cost here depends on the number of customers and items and the state of the data. It is usually finance and sales effort as much as IT effort, and it is often underestimated because nobody has measured the data quality beforehand.
Credit notes, debit notes and special cases
Credit and debit notes follow the same clearance or reporting rules as the invoices they relate to, must reference the original invoice and must state a reason. Many ERPs handle returns, discounts and corrections in several different ways, and each path needs mapping and testing.
ZATCA’s XML implementation standard also flags special transaction types, such as third-party, nominal supply, export, summary and self-billed invoices. If you issue any of these, or deal with advance payments, multiple currencies or complex discounts, expect extra mapping and test cases. A vendor quote that does not list your document types has not priced them.
Onboarding and testing in ZATCA’s environments
Testing effort is a real cost driver, and ZATCA provides several environments to support it:
- Developer Portal sandbox. ZATCA’s E-Invoicing Developer Portal gives solution developers a sandbox and tools to validate XML invoices, credit notes and debit notes against the specifications.
- Simulation environment. Accessed through the FATOORA portal, it replicates production so taxpayers can test onboarding, clearance and reporting end to end. Responses there are not official clearance or reporting.
- Compliance checks. Each unit obtains a compliance CSID using a one-time password (OTP) generated in the FATOORA portal, then submits sample documents for every type it will issue.
- Production onboarding. Once compliance checks pass, the unit requests a production CSID and goes live.
The effort grows with the number of units, document types and source systems. It also grows when test data is unrealistic: partial credit notes, rounding, discounts and API outages should all be rehearsed before go-live. Ask every vendor which of these environments they will use, how many test scenarios they will run and who prepares the test data.
Running costs after go-live
Phase 2 is not a one-off project. Budget for the costs that continue once invoices are flowing.
- Certificate renewal. CSIDs expire. ZATCA’s detailed e-invoicing guideline describes the FATOORA portal as the place to generate, renew or revoke a unit’s CSID. Renewal needs a new OTP and certificate request, so someone must own it and get alerts well before expiry.
- Rejection and reporting monitoring. Someone has to watch for rejected standard invoices and failed simplified-invoice reports, fix the cause and resubmit quickly, because a rejected standard invoice has not been legally issued.
- Specification updates. When ZATCA updates its technical requirements, your module, middleware or custom code must follow. Check whether that is covered by a support contract or billed as change requests.
- System changes. New branches, POS terminals, ERP upgrades or new document types all mean onboarding or retesting.
- Key management and audit support. Private keys must stay protected, and you may need to show auditors how invoices were generated and stamped.
Our Support & Optimization service is one way to cover this work after go-live.
How to compare vendor quotes: a checklist
Headline prices are rarely comparable, because each vendor assumes a different scope. Before choosing, check that every quote answers these questions:
- Scope. Which source systems, branches, POS terminals and EGS units are included?
- Document types. Are tax invoices, simplified invoices, credit notes, debit notes and your special cases all listed?
- Integration route. Native module, middleware or custom, and does it require an ERP upgrade?
- Pricing model. One-off, subscription, per unit, per invoice or per branch, and what happens to cost as volumes grow?
- Master data. Is data assessment or cleanup included, or assumed to be done by you?
- Testing. Which ZATCA environments, how many scenarios, and who provides test data?
- Onboarding. Who generates OTPs, submits certificate requests and completes compliance checks for each unit?
- Key storage. Where will private keys live, and who can access them?
- Exceptions. How are rejections surfaced to finance users, and what is the agreed fix-and-resubmit process?
- After go-live. Are certificate renewal, specification updates, monitoring and response times covered, and for how long?
- Exit. If you change vendor later, can you keep your invoice archive, keys and hash chain continuity?
Put the answers side by side in one table. Gaps in a quote are not savings; they are costs that will appear later as change requests.
When to start
ZATCA states in its detailed guideline that notifications to target groups are issued at least six months in advance. That window is the practical planning horizon, and it is not long once vendor selection, master data cleanup, development, testing and onboarding are added together.
Start scoping as soon as you receive your notification, or earlier if you expect to be included in an upcoming wave. Starting early also gives you more negotiating room with vendors and avoids paying a premium for compressed timelines. Your go-live date and current requirements are in your ZATCA notification and on zatca.gov.sa.
If an ERP upgrade or replacement is already planned, align the two projects so you do not build Phase 2 twice. Our ERP Implementation service often covers that sequencing.
Common mistakes that inflate the cost
- Requesting quotes before inventorying invoicing sources. Vendors price different assumptions and the cheapest quote often excludes the hardest parts.
- Ignoring the upgrade hidden in a native module. The module may be inexpensive while the required ERP upgrade is not.
- Leaving master data until testing. Cleanup discovered during compliance checks delays onboarding and adds rework.
- Testing only standard invoices. Credit notes, debit notes and special transaction types often fail after go-live when they were never tested.
- Treating go-live as the finish line. Certificate renewal, monitoring and specification updates need an owner and a budget.
- No exception process. Without a clear owner for rejections, billing and collections slow down.
Frequently asked questions
How much does ZATCA Phase 2 integration cost?
There is no standard price. Cost depends on your number of invoicing sources and EGS units, the integration route, master data quality, document types, testing scope and post-go-live support. Use the checklist above to get comparable quotes for your own scope.
Is a native ERP module always cheaper than middleware?
No. A native module is often simplest for a current, lightly customized ERP. If it requires an ERP upgrade, or you have several invoicing systems, middleware or a custom build can be more economical overall.
Do we need a separate EGS unit for every POS terminal?
Each unit keeps its own counter and hash chain, so the structure of your units is a design decision with security, operational and cost consequences. Decide it with your vendor based on how your branches and terminals issue invoices, and confirm it against current ZATCA guidance.
Are there ongoing costs after go-live?
Yes. Plan for certificate renewal, monitoring of rejections and reporting failures, updates when ZATCA changes its specifications, and retesting when you add branches, devices or systems.
Can we test before committing to a vendor?
ZATCA’s Developer Portal sandbox and the simulation environment in the FATOORA portal allow testing without issuing legal invoices. A short proof of concept with a shortlisted vendor in these environments is a sensible way to validate their approach.
Getting a clear scope before you buy
AIMLTS is based in Jeddah and builds ZATCA Phase 1 and Phase 2 e-invoicing into existing ERP and billing systems, including FATOORA API integration, EGS onboarding and testing against ZATCA’s sandbox and simulation environments. See our ZATCA & E-Invoicing service for details, or book a discovery call to review your invoicing flow against Phase 2 rules and define a scope that vendors can quote on equal terms.