Saudi Arabia ZATCA E-Invoicing Compliance

The problem

Saudi e-invoicing is not a reporting nicety you can bolt on at year end. Under the Fatoora programme, a taxpayer in scope must produce every invoice in a prescribed XML format, cryptographically stamped and carrying a QR code, and must either submit it for clearance before it is valid or report it within a fixed window. Get the format wrong and the invoice is rejected. Get the sequencing wrong — a gap in the invoice counter, a broken previous-invoice hash chain — and the whole batch behind it is in question.

Dynamics 365 Finance & Operations posts customer invoices, credit notes, debit notes, project invoices and free text invoices from several different places in the application. Each one has its own document journal, its own printing route, and its own tax posting. A compliant solution has to intercept all of them, not just the sales order flow, and it has to do it inside the transaction so that a posted invoice and its cleared document never diverge.

Waves have rolled outward from the largest taxpayers to progressively smaller ones. If your revenue puts you in an upcoming wave, the work is not optional and the date is not negotiable.

What ECOSIRE builds

This is a build-to-order engagement. There is no shrink-wrapped download. After a scoping call and a fixed quote, ECOSIRE builds the extension against your F&O environment, your legal entity structure and your device registration, then delivers it through your LCS pipeline.

Document generation

The extension hooks the posting of customer invoices, credit notes, debit notes, free text invoices and project invoices through event handlers and chain of command, and produces the required XML document from the posted record — not from a report layout. Header and line values come from the actual posted tables (CustInvoiceJour, CustInvoiceTrans, the tax transaction tables and the ledger dimension framework), so what is submitted is what is in your ledger. Seller and buyer identification, tax registration numbers, national address elements, supply dates, line-level tax categories and reasons for exemption are mapped from configurable sources on the legal entity, the customer and the tax setup.

Cryptography and QR

Certificate and key material live in a secured configuration area with a device registration workflow, so an administrator can onboard a device per legal entity and per branch without a developer. Each document is hashed, stamped, and chained to its predecessor so the sequence is verifiable. The QR code is generated in the required encoded structure and embedded in the printed and PDF output, so a customer scanning it sees the values that were submitted.

Clearance and reporting

Standard tax invoices follow the clearance route: the document goes to the authority before it is given to the buyer, and the cleared response with its stamp is written back onto the invoice record. Simplified invoices follow the reporting route, submitted within the required window, with the submission status tracked per document. Both routes run through the batch framework so a queue of documents drains reliably across AOS instances, with configurable retry, backoff and alerting when the authority endpoint is unavailable. Nothing is silently dropped: every document sits in exactly one state — pending, submitted, cleared, reported, warning or rejected — and every state change is logged with the authority's response payload.

Operational surface

A compliance workspace gives the tax team a live view: documents awaiting submission, documents that came back with warnings, documents rejected and why, and the current counter and hash chain position per device. Rejections can be inspected against the exact XML that was sent. A resubmission action is available with full audit trail rather than a quiet retry.

Integration and archiving

All compliance tables are exposed as data entities for Data management framework export and OData access, so your archive obligations and any external tax reporting tool are served from the same data. Generated XML and authority responses are retained against the invoice through the Document management framework for the retention period you specify.

Build discipline

Extension-based X++ in a dedicated model — chain of command, event handlers, table and form extensions. No overlayering, so your existing customisations and your platform update path are untouched.

Who this is for

Organisations running Dynamics 365 Finance & Operations with one or more Saudi legal entities that fall into a Fatoora wave: manufacturers, distributors, contractors, retail groups and services businesses. It is equally relevant to a multinational group where one Saudi entity sits inside a shared F&O instance and must comply without disturbing the other entities' posting behaviour.

If your Saudi operations are still on a separate system and you are mid-migration to F&O, the scoping call should happen early — compliance sequencing and cutover interact.

How delivery works

Scoping call. We establish which document types you issue, which are standard versus simplified, your branch and device structure, your legal entity setup, your F&O version and how your tax codes and exemption reasons are configured. We confirm your wave timing and work backwards from it.

Fixed quote. A written scope lists every document type covered, the compliance workspace, the device onboarding flow, the entities and the batch jobs, with a fixed price. Work starts only after you approve it.

Build. Development happens in a dedicated model, with check-ins that show real generated documents rather than progress text.

Install in test. The deployable package goes into your sandbox through LCS. We onboard a test device, configure the legal entity data, and run your real invoice types end to end against the authority's non-production environment until the output is accepted cleanly.

Production. After sandbox sign-off, the same package is applied to production through your release process, production devices are onboarded, and we are on the call for the first live submissions.

Support. A defined support window follows go-live for defect fixes and configuration questions, with the source code in your hands throughout.

Typical lead time from approved quote to sandbox install is two to four weeks depending on how many document types and entities are in scope. If your wave date is close, say so on the scoping call — sequencing the work around a deadline is part of the conversation.