Overview
The Zakat, Tax and Customs Authority (ZATCA) requires VAT-registered businesses in Saudi Arabia to issue invoices electronically and integrate with the Fatoora platform. Nama ERP supports Phase 2, the Integration Phase: the system generates each invoice as UBL 2.1 XML, signs it digitally, and submits it directly to the Authority.
This is built into the ERP itself, not bolted on through a middleware product. The invoice your team raises is the invoice that gets signed, submitted and stamped — there is no export step, no second system to reconcile against, and no separate compliance database that can drift out of step with your ledger.
Features
Both invoice types, routed automatically
Fatoora treats business and consumer sales differently, and Nama ERP handles both:
| Standard / Tax Invoice (B2B) | Simplified Invoice (B2C) | |
|---|---|---|
| Submission model | Clearance | Reporting |
| When it is valid | Only once ZATCA returns it stamped with the official QR code | Immediately at point of sale |
| Deadline | Before it is shared with the buyer | Reported within 24 hours |
You enable whichever applies to your business — or both, if you sell to businesses and to individuals. The system then routes each invoice down the correct path by its type, so nobody has to remember which queue an invoice belongs in.
Onboarding handled from inside the system
No system may submit invoices until it has onboarded with the Authority. Nama ERP performs all three stages behind a single Approve System action:
- Generate the CSR — builds a Certificate Signing Request from your tax data.
- Compliance CSID — submits the request with an OTP from the Fatoora portal and sends sample invoices to prove compliance.
- Production CSID — obtains the final production certificate and stores it in the configuration, making the business ready to submit live invoices.
Submission, status tracking and correction
Invoices are gathered into a Tax Authority Submission Document, where you collect by date or document range, optionally validate the data and preview the generated XML before anything is sent, then submit.
Every line carries a status — Not Sent, Sent, or Not Valid Sent with the Authority’s error message attached — and a single action re-queries ZATCA to refresh it. You can open any invoice on the Authority’s own portal directly from the record.
An audit trail that proves what was submitted
The submission document can export the exact XML the Authority received — the cleared, ZATCA-stamped version for standard invoices — as well as regenerate the XML from the document’s current data.
Comparing the two answers a question auditors actually ask: was this invoice edited after it was submitted? If the current XML no longer matches the cleared one, it was.
Supported documents and controls
Invoices, credit notes and debit notes are all supported. The window allowed for sending an invoice after its value date — and for cancelling one — defaults to three days and is configurable.
Tax codes and VAT categories are configured per taxpayer, including exemption reason codes for zero-rated, exempt and out-of-scope lines, so the common causes of ZATCA rejection are prevented at the point of data entry rather than discovered at submission.
What you need before you start
Onboarding requires access to the Fatoora Portal to generate an OTP, the business’s 15-digit VAT registration number, its Commercial Registration Number, its complete National Address, and the EGS serial number of the invoicing unit. The Authority’s signing toolkit is deployed on your server as part of the setup.
Our implementation team handles this configuration as part of a Saudi deployment — the full technical procedure is published in our documentation.
If you are still working out what the mandate obliges you to do, rather than which system will do it, start with what ZATCA Phase 2 requires — the same ground from the compliance side, including the four data problems behind most rejections.
Good question — already answered
Do we need middleware or a separate compliance product as well?
No. Generation, signing, submission and status tracking all happen inside Nama ERP against the same invoice your team raised. The alternative most vendors offer — an ERP plus a compliance bridge plus the bridge's own database — gives you two records of every invoice and a reconciliation job at month end to prove they still agree.
Can we test before going live?
Yes, and you should. Three environments are supported and selected on the taxpayer configuration: the developer sandbox, the simulation portal used during the trial period, and live production. The normal rollout runs your real scenarios end to end through simulation first, so the surprises happen where they cost nothing.
How do we know an invoice was rejected?
Every line on the submission document carries its own state — not sent, sent, or rejected with the Authority's error message attached to the line. One action re-queries ZATCA and refreshes them, and any invoice can be opened on the Authority's own portal from the record. Nothing depends on somebody noticing a missing acknowledgement.
Does this cover point-of-sale as well as invoices raised in accounts?
Yes. Simplified invoices issued at the till travel the reporting path and standard invoices travel the clearance path, and the system routes each by its type rather than asking the cashier to know the difference.
We run several Saudi companies. Is that one configuration or several?
Several configurations on one system. Each legal entity onboards with its own certificate and its own taxpayer record, drawing the seller data and national address from its own branch — but they share a database, so group reporting is a report rather than a consolidation exercise.
