Onboarding wizard
Certificate request, OTP exchange with Fatoora and device registration, walked through in minutes rather than read out of a specification.
Your system already knows how to raise an invoice. It should not also have to learn certificate onboarding, XML signing, hashing chains and clearance. Post the invoice to us and get back the signed document the authority accepts.
Phase 2 is a cryptography project wearing an accounting hat: a CSR and an OTP exchange with Fatoora, a per-device certificate, a hash chain that must never break, canonical XML that must sign byte-for-byte, then clearance for standard invoices and reporting for simplified ones. Every company that sells anything now has to solve it, and none of them wanted a cryptography project.
A compliance layer for a system that already exists — not a system to replace it.
Certificate request, OTP exchange with Fatoora and device registration, walked through in minutes rather than read out of a specification.
POST an invoice and receive the signed XML, the QR and a PDF. Standard invoices are cleared, simplified ones reported — the service knows which is which.
Told when the status changes rather than polled for it, with retries and a delivery log you can inspect.
Separate keys for sandbox and production, rotatable, with per-key usage so an integration gone wrong is visible before the bill is.
Every invoice, its status, the authority's response, and what you have used this month — for the finance team, not just the developer.
B2B buyer records, credit and debit notes, and the archive the regulation requires you to keep.
The wizard takes your commercial details, requests the certificate and completes the OTP exchange with Fatoora.
Integrate against the sandbox with your real invoice shapes until the responses are what you expect.
Swap the key for the production one. Nothing else in your integration changes.
Webhooks into your system, the dashboard for your finance team, and us on the other end when the authority behaves oddly.
By volume, with a sandbox that costs nothing. Quoted after a short call about how many invoices you issue and how many entities you issue them from.
For a business making its own system compliant.
For a high-volume issuer, or a group of entities under one account.
For a software vendor making their own customers compliant.
It is designed to sit behind something that already invoices.
No, and that is the point. This sits behind whatever raises your invoices today — your own software, an ERP, a POS — and makes what it produces compliant. If you wanted to replace the accounting system we would be selling you a different product.
Yours. The onboarding wizard requests it in your name and it is encrypted at rest, per tenant. Nothing is shared between customers, which is what makes an audit answerable.
The implementation is byte-equivalent to the official ZATCA SDK and proven against the live validator. That is a testable claim, not a reassurance — and the sandbox is where you test it with your own invoices.
The invoice is queued and retried, the status stays visible, and your webhook fires when it resolves. Your system is never left holding a request that silently failed.
The sandbox will tell you in an afternoon whether this removes the problem. That is usually the whole evaluation.