E-Invoices (ZATCA)

ZATCA's e-invoicing regulation (Fatoora) requires every tax invoice to be generated electronically as a standard XML document, to carry a QR code, to be signed with a certificate ZATCA issues to your organization's e-invoicing unit, and to be sent to ZATCA: a standard (B2B) invoice is cleared before it reaches the buyer, a simplified (B2C) invoice is reported within 24 hours. The Invoices page (Sales section) does all of it: you write a draft, click issue, and the invoice gets its number, its stamp and its QR code and goes to ZATCA in the same step.

The scope here is the document itself: the platform issues the compliant invoice and stops there. Recording payments, tracking receivables and the accounting entries all stay in your accounting software, which takes the issued invoice from here (as PDF or XML).

Drafting

The quickest way is the Create invoice button on a sales order or a quotation: the form opens filled with the customer and the lines at their prices and VAT categories. You can also start from scratch. Pick the document (tax invoice, credit note, debit note) and its kind (standard B2B or simplified B2C), pick the customer from the customer directory so the buyer block (legal name, VAT number or other identifier, national address) is filled from its profile, or enter the buyer's details by hand, then the supply date, the payment means and the lines. Every line carries its VAT category: the standard 15% rate, zero-rated with an exemption reason (medicines and medical equipment are VATEX-SA-35), exempt, or out of scope. Picking a product from the catalog fills the description, the price and the VAT category from the product record.

What an invoice needs before issue

The draft page lists what is still missing under ZATCA's rules, and the issue button stays disabled until the list is empty. The seller side is set once in organization settings: the legal name, the VAT number (15 digits starting and ending with 3), the CR number and the national address (street, 4-digit building number, district, city, 5-digit postal code). The buyer side depends on the kind: a standard invoice needs the buyer's VAT number or another identifier (CR number, national ID…), their address and the supply date; a simplified invoice needs only the customer name. A credit or debit note needs the issued invoice it corrects and the reason.

Issuing

1. The invoice gets its sequential number and the issue date and time in Riyadh.
2. The XML is built in ZATCA's format and hashed (SHA-256), chained to the previous invoice's hash (the PIH chain) with the invoice counter (ICV).
3. The invoice is signed with the e-invoicing unit's key and certificate, and the QR code is built with the hash, the signature and the public key.
4. The invoice is frozen: it can no longer be edited or deleted; a correction is a credit or debit note that references it.
5. It goes to ZATCA: clearance for a standard invoice, reporting for a simplified one. The outcome shows on the invoice (cleared, reported, rejected with ZATCA's messages, or awaiting ZATCA when the gateway could not be reached, in which case Send to ZATCA again re-sends the same file).

From the invoice page you download the printed PDF (Arabic with English, with the QR code and the VAT table), the signed XML ZATCA received, and, for cleared standard invoices, the XML copy ZATCA stamped.

Setting up the e-invoicing unit

The unit is what signs invoices in your organization's name. The owner sets it up under Settings → ZATCA e-invoicing in four steps: generate the keys and the certificate request, request the compliance certificate with a one-time password from the Fatoora portal (Onboard new solution unit), run the six compliance checks (a standard and a simplified invoice, credit note and debit note), then request the production certificate. The sandbox accepts the OTP 123345 and issues test certificates, which is how to try the whole cycle before production; a unit is bound to its environment, so moving to production means resetting it and starting over.

Activity log, archive and verification

ZATCA requires a compliant solution to log every activity of the invoicing process without any way to modify or delete it, to let you export invoices to an external archive, and to detect tampering with the stored documents. The Activity card under every invoice shows everything that happened to it: the draft created and edited, the issue, the submission to ZATCA with its answer, and every PDF or XML download, with the member, the time and the channel (the app, or the API an assistant used). The log is write-only: nobody can edit or delete a row, the platform included, and every row is chained to the previous one by hash, so a changed order or content shows up when verified.

The Download archive button above the invoices list (admin and owner) gives you a ZIP with every issued document's signed XML, each file named with the VAT number, the issue time and the invoice number (300000000000003_20260922T104500_INV-000001.xml) the way ZATCA requires for archiving, ZATCA's cleared copy beside it as .cleared.xml, and a manifest.json listing numbers, UUIDs and hashes. Narrow it by issue date when there are many documents.

The Records integrity card under Settings → ZATCA e-invoicing (owner) re-hashes every issued document from its stored XML and compares it with the record, checks the stamp against the certificate in the file, each invoice's link to the previous one and the counter sequence, the file against the record, the unit's counter and last hash, and the activity log's own chain. The result names the invoice and the problem if there is one. Run it before any audit.

Roles

• View: everyone who sees sale-side prices (owner, admin, sales, purchasing, viewer); viewer without pricing and technical do not see invoices.
• Drafts: sales, purchasing and up create, edit and delete drafts.
• Issue and re-send: admin and owner only.
• The e-invoicing unit and records verification: the owner only, like the rest of the organization settings.
• The XML archive: admin and owner, like every export. The activity log is readable by everyone who sees invoices.

API and MCP

Everything above is available over the REST API and the MCP server: invoices_list, invoices_get, invoices_create, invoices_update, invoices_delete, invoices_issue, invoices_submit, invoice_pdf and invoice_xml under the invoices.read and invoices.write scopes, invoice_events_list for the activity log and invoice_archive_zip for the archive, and the zatca_egs_* tools for the unit plus zatca_chain_verify for the verification under the settings scopes. invoices_get returns readiness_issues, what a draft still lacks before issue, which is what an assistant should show before asking to issue.