ZATCA e-invoicing software, built and integrated for your business
Fatoora Phase-2-ready e-invoicing — generated correctly, cleared with ZATCA, and wired into the systems you already run, owned by you.
What ZATCA Phase 2 actually demands
Saudi Arabia's e-invoicing programme, Fatoora, runs in two phases. Phase 1 required structured electronic invoices with a QR code. Phase 2 — the integration phase, rolled out in waves by taxpayer size — requires your system to connect to ZATCA's platform, submit each invoice for clearance or reporting, and embed the cryptographic stamp and UUID ZATCA returns. The invoice must be valid UBL 2.1 XML carrying the seller's VAT registration number, the timestamp, the totals, and the VAT amount.
Getting this subtly wrong is the most common production failure we see in MENA finance systems: invoices that look fine to a human but fail ZATCA validation, or clear in test and break in production. The fix is to treat clearance as a tested, versioned part of the system — not a feature bolted onto a generic invoicing tool.
E-invoicing wired into how you actually work
- Compliant generation — valid UBL 2.1 XML with the QR code, seller TRN, timestamps, and VAT, produced from your real invoice data.
- Phase-2 integration — connection to ZATCA for clearance (B2B) or reporting (B2C), handling the returned stamp, UUID, and any rejection cleanly.
- System integration — the e-invoicing layer sits inside your ERP, accounting system, e-commerce store, or AIMOCS operator, not as a separate island you re-key into.
- In-region hosting — documents and audit logs hosted in Riyadh or Jeddah, aligned to data-residency expectations.
- Audit trail — every generated, cleared, and rejected document recorded immutably, so a tax review is a query, not an investigation.
Why integrate rather than buy another invoicing app
Plenty of Saudi vendors sell standalone e-invoicing apps. They work if invoicing is a separate activity. But for most businesses invoicing is the output of something else — an order in the store, a milestone in the ERP, a job closed by an operator — and a separate app means re-keying, reconciliation, and a second source of truth. Building the clearance layer into your existing flow removes that. And because ZATCA's rules evolve, we keep the validation in a tested, versioned utility that is updated and re-checked on every rule change — the same governance discipline we apply to model versions.
Does this make us compliant with ZATCA Phase 2?
It produces ZATCA-valid UBL 2.1 invoices with the QR code and integrates with the Fatoora platform for clearance or reporting, handling the returned cryptographic stamp and UUID. Compliance also depends on your VAT registration and processes, which we map during setup.
Can it integrate with our existing ERP or e-commerce store?
Yes — that is the point. The e-invoicing layer is built into your ERP, accounting system, or store so invoices clear automatically from your real data, with no separate app to re-key into.
Is the data hosted in Saudi Arabia?
Yes. In-region hosting (Riyadh/Jeddah) is the default, with an immutable audit trail of every cleared and rejected document.
What happens when ZATCA changes the rules?
The validation and clearance logic lives in a tested, versioned utility, not buried in application code. When ZATCA updates the spec we update that utility, run the regression checks, and roll it out — without breaking your live invoicing.
Do we own the software?
Yes — you receive the source, schema, and deploy pipeline. No per-document SaaS fee, no lock-in.
We don't advise on AI. We run it for you.
Proven on your data before you commit.