ZATCA e-invoicing: what your software needs to support

In general terms, software that issues invoices in Saudi Arabia needs to produce structured electronic invoices in a standard XML format, include a QR code, and, depending on the phase your business falls into, connect to the ZATCA platform to report or clear invoices. This is a general overview, not legal or tax advice. Requirements and timelines change, so confirm the current rules with ZATCA or a qualified adviser before you build.

What Fatoora e-invoicing is

ZATCA is the Zakat, Tax and Customs Authority, and Fatoora is its e-invoicing programme. The idea is that invoices are no longer just PDFs or paper. They are structured data that can be checked, stored and exchanged in a consistent way.

The programme has been rolled out in phases and in waves. One phase is generally about generating and storing compliant invoices. A later phase is about integration with the ZATCA platform. Which obligations apply to a given business, and from when, is something to confirm directly with ZATCA, because we do not want you relying on a date or threshold from a blog post.

What your software generally needs to support

Structured invoices. Invoices need to be produced as XML in the format ZATCA specifies, not only as a printable document. The human-readable version and the structured data should always agree.

QR codes. Invoices are generally expected to carry a QR code containing key invoice details. The exact content and encoding follow ZATCA's technical specification.

Platform integration. At the integration phase, systems generally communicate with the ZATCA platform through its APIs to report or clear invoices, depending on the invoice type. That means handling onboarding, credentials, retries when the service is unavailable and clear error handling when an invoice is rejected.

Invoice integrity. Compliant systems typically need to prevent silent edits to issued invoices. Corrections are handled through credit and debit notes rather than overwriting history, and an audit trail records what happened.

Arabic and English. Many Saudi businesses issue bilingual invoices, so layouts, fonts and right-to-left text need to be handled properly.

Design decisions that matter early

Treat invoicing as a core module, not a report. If your ERP, point-of-sale and ordering tools each produce invoices in their own way, compliance becomes several projects instead of one. A single invoicing service that everything else calls is easier to keep correct.

Store the raw structured invoice, the response from the platform and the status of each submission. When something is rejected, your finance team needs to see why without asking an engineer. Build a queue for submissions so a temporary outage does not stop billing.

Keep your tax rules configurable. VAT treatment and invoice fields can change, and hard-coding them turns a small update into a release.

Where we fit

We build ERP and billing software in Laravel, with integrations, queues, role systems and audit logs as standard parts of the stack. We already issue formal, FBR-compliant invoices for our own business, so invoicing logic is familiar territory for us.

Plan for testing before go-live. Use ZATCA's sandbox and test environments where available, run realistic invoice types including credit notes and bilingual content, and agree with your adviser how you will verify the output.

We do not certify compliance and we are not tax advisers. We build to the specification your adviser or ZATCA gives you, and we can run a scoping call to map your current invoicing flow and the systems it touches. Typical focused builds are an 8-14 week fixed-scope project, with the real number coming from that written scope.