ZATCA Phase 2 integration (Fatoora)
The Fatoora integration phase — connecting your real systems to ZATCA for clearance and reporting, returning the cryptographic stamp and UUID on every invoice, built and owned by you.
What the integration phase actually demands
Phase 1 of Fatoora (generation) only asked for structured electronic invoices with a QR code, produced and stored locally. Phase 2 — the integration phase, rolled out to taxpayers in waves by turnover — changes the model entirely. Your billing system, an EGS unit in ZATCA's terms, must onboard with the platform, obtain a Cryptographic Stamp Identifier (CSID), and then call ZATCA on every invoice.
For B2B standard invoices that means real-time clearance: ZATCA validates the UBL 2.1 XML, applies its cryptographic stamp, returns a UUID and a cleared status, and only then is the invoice legally valid. For B2C simplified invoices it means reporting within twenty-four hours, with the stamp generated locally and the document submitted afterward. Every invoice also carries an incrementing counter (ICV) and the hash of the previous invoice (PIH), forming a tamper-evident chain.
- Onboarding — generate a CSR, exchange it for a compliance CSID, pass ZATCA's compliance checks, then promote to a production CSID.
- Clearance (B2B) — submit each standard tax invoice synchronously; the invoice is not valid until ZATCA returns it cleared.
- Reporting (B2C) — stamp simplified invoices locally and report them to ZATCA within the required window.
- Cryptographic chain — ICV counter and previous-invoice hash on every document, plus the QR code carrying the ZATCA stamp.
Integration wired into the system you invoice from
We do not hand you another portal to re-key into. We build the Phase 2 handshake into the system that already produces your invoices — your ERP, your store, your accounting software, or your AIMOCS operator — so clearance happens inline, automatically, from real data.
- EGS onboarding and CSID lifecycle — initial onboarding plus automated renewal before the certificate expires, so clearance never silently stops.
- Clearance and reporting flows — the correct path per invoice type, with the returned stamp, UUID, and status written back to your records.
- Resilient queue — retries, dead-letter handling, and clear surfacing of rejections so a failed invoice is visible, not lost.
- In-region hosting — documents, keys, and audit logs in Riyadh or Jeddah, aligned to data-residency expectations.
- Audit trail — every submission, clearance, rejection, and renewal recorded immutably for a future tax review.
Why integrate rather than buy a clearance middleman
A market of intermediaries will happily sit between you and ZATCA, taking your invoice, clearing it, and charging per document forever. That works until you need to reconcile a rejection, prove a number in an audit, or change how you invoice — at which point the middleman is a black box you cannot inspect. Building the integration into your own stack keeps the cryptographic chain, the audit trail, and the API logic under your control.
It also matters because ZATCA's specification evolves — new validation rules, new fields, new waves. We keep the clearance and onboarding logic in a tested, versioned utility that is re-checked against ZATCA's sandbox on every spec change, so an update is a controlled release, not a production fire drill.
What is the difference between clearance and reporting?
Clearance applies to B2B standard tax invoices: ZATCA validates and stamps the invoice in real time and it is not valid until returned cleared. Reporting applies to B2C simplified invoices: the invoice is stamped locally and submitted to ZATCA within the required window. We build the correct path per invoice type.
Do you handle CSID onboarding and renewal?
Yes. We run the full lifecycle — generate the CSR, obtain the compliance CSID, pass ZATCA's checks, promote to a production CSID, and automate renewal before expiry so clearance never silently stops.
Can this connect to our existing ERP or store?
Yes — that is the point. The Phase 2 handshake is built into the system that already produces your invoices, so clearance happens inline from real data with no separate portal to re-key into.
What happens when an invoice is rejected by ZATCA?
Rejections are surfaced clearly, not swallowed. A resilient queue with retries and dead-letter handling means a failed invoice is visible and actionable, with the reason logged in your audit trail.
Do we own the integration?
Yes — you receive the source, the keys, the schema, and the deploy pipeline. No per-document clearance fee, no intermediary black box.
We don't advise on AI. We run it for you.
Proven on your data before you commit.