The problem
ZATCA Phase 2 does not let you keep printing invoices out of NetSuite the way you always have. Standard tax invoices must be cleared with the authority before they reach the buyer, and simplified invoices must be reported within 24 hours of issuance. Each document has to be a UBL 2.1 XML file carrying a cryptographic stamp, an invoice hash chained to the previous document, a UUID, and a TLV-encoded QR code. Your device has to be onboarded to the Fatoora portal, hold a valid compliance certificate (CSID), and renew it before it expires.
Native NetSuite gives you the invoice record, the tax engine, the subsidiary structure and the print templates — but it does not generate ZATCA UBL, it does not sign anything, it does not talk to the Fatoora APIs, and it has no concept of an invoice counter value or a previous-invoice hash. Finance teams end up re-keying cleared documents into a portal, or exporting to spreadsheets and losing the audit trail entirely. Once a document fails clearance, nothing in stock NetSuite tells you which invoice broke the chain or how to resubmit it.
What ECOSIRE builds
We build a NetSuite customization — SuiteScript 2.1, SuiteFlow, custom records and saved searches — that lives inside your NetSuite account and turns invoice posting into a compliant e-invoicing lifecycle. This is not a shrink-wrapped product you download. We scope it against your chart of accounts, subsidiaries and item setup, quote a fixed price, then build and deploy it.
Document generation
A User Event script on Invoice, Cash Sale and Credit Memo records assembles the ZATCA UBL 2.1 payload at approval. It maps NetSuite fields to the required XML: seller VAT registration and CR number from the subsidiary, buyer identification from the customer record and its address subrecord, line-level item, quantity, unit price, discount and tax category from the transaction lines, and the tax breakdown from the NetSuite tax detail sublist. Zero-rated, exempt and out-of-scope treatments are driven by a mapping table on a custom record, so tax code changes are configuration, not code.
Cryptographic stamping and hashing
A supporting module produces the invoice hash, chains it to the previous document's hash per counter, generates the UUID, builds the TLV/base64 QR payload and applies the digital signature using the certificate issued to your device. The counter value and the hash chain are stored on a custom record so the sequence is reconstructable and auditable, not held in memory.
Clearance and reporting transmission
RESTlet and Scheduled/Map-Reduce scripts handle the outbound calls. Standard invoices go through the clearance flow synchronously at approval; simplified invoices are queued and reported within the 24-hour window by a Map/Reduce job that batches, retries with backoff, and records every request and response. HTTP failures, validation rejections and warnings are all captured — a warning-cleared document is still cleared, and the solution treats it that way rather than blocking your billing.
Onboarding, certificates and renewal
We build the onboarding utility that submits the CSR, stores the compliance and production credentials in a restricted custom record, and a scheduled reminder that flags certificate expiry before it stops your invoicing.
Operational visibility
A custom Suitelet dashboard plus saved searches show cleared, reported, rejected and pending documents with their ZATCA response codes. Rejected documents can be corrected and resubmitted from the record itself. The cleared XML and the QR-bearing PDF/A-3 output are stored on the transaction as file cabinet attachments, so the statutory copy is the one the customer received.
Who this is for
Businesses running NetSuite that are in scope for a ZATCA Phase 2 wave — whether that is a single Saudi entity or a OneWorld account where the KSA subsidiary needs compliance while other subsidiaries are untouched. It suits companies with real transaction volume, mixed B2B and B2C flows, or multiple NetSuite roles issuing invoices, where a manual portal workaround is not sustainable.
It is a poor fit if you issue a handful of invoices a month and are content keying them into the Fatoora portal by hand.
How delivery works
1. Scoping call. We walk your NetSuite account: subsidiaries, tax codes, item types, transaction forms, the roles that approve invoices, and your current Fatoora onboarding status. We confirm which document types are in scope. 2. Fixed quote. You get a written scope and a fixed price before any code is written. Changes after that are quoted separately, not billed silently. 3. Build. We develop against your sandbox as an SDF project. You see progress on real records, not slideware. Typical lead time is one working week depending on scope and how fast sandbox access and test data arrive. 4. Install in sandbox, then production. We deploy the unmanaged bundle/SDF project to your sandbox, run clearance and reporting against the ZATCA simulation environment with your own data, and only then promote to production and switch to the production endpoint. 5. Support. A defined support window after go-live covers defects, ZATCA response-code questions and configuration adjustments.
You own the resulting SuiteScript and customizations outright. There is no runtime lock, no per-invoice fee to us, and no obligation to keep us engaged after the support window.
What we do not claim
We do not issue your certificates — ZATCA does. We do not guarantee an authority will never reject a document; we build the validation, error surfacing and resubmission path so that when it happens you can see why and fix it. Regulatory specifications change, and we tell you plainly when a change is inside your support window and when it is a new scope.