Skip to main content
Make sure you have completed the registration guide before clearing or reporting invoices.
Saudi Arabia runs two e-invoicing flows, and both are driven by the same GOBL invoice with the ZATCA add-on. A single send workflow converts the document to UBL 2.1, chains it, signs it, and submits it to the corresponding ZATCA endpoint:

​
Sending

The send workflow claims the next ICV, builds and hashes the UBL document, signs it and generates the QR (for simplified invoices), submits to ZATCA and then stores the final XML and QR back on the silo entry.

​
How it works

1

Set State → Processing

Sets the state of the silo entry as “Processing”.
2

Send invoice to ZATCA

Converts the GOBL invoice to UBL 2.1, adds the ICV and PIH chain values, hashes the document, and submits it to the clearance or reporting flows.
3

Set state → Sent

Marks the silo entry as “Sent”

Saudi Arabia send invoice workflow

Clears standard invoices and reports simplified invoices to ZATCA.
An invoice that is already signed is skipped as “already sent”.

​
Credit and debit notes

Issued invoices can’t be cancelled or edited once cleared or reported. Corrections are made with credit notes (reduction) or debit notes (increase) that reference the original invoice. A note flows through the same clearance or reporting model as the document it corrects, using the same send workflow.

​
Example invoices

Every example pairs the minimal hand-authored GOBL input with the built version produced by gobl build. All carry the sa-zatca-v1 add-on. Standard invoices are cleared; simplified invoices are reported. Standard tax invoices (clearance)
A standard tax invoice between two VAT-registered parties, billed at the 15% standard rate. This is the baseline document cleared with ZATCA before it is shared with the buyer.
A credit note that reduces a previously cleared standard invoice. The preceding block links it to the original document.
A debit note that increases the value of a previously cleared standard invoice, referencing the original in preceding.
An export to a customer outside the GCC, taxed at the zero rate. Exports carry an exemption reason and are reported with the export tag.
A nominal (deemed) supply — goods or services provided without a monetary charge but still subject to VAT.
A self-billed invoice, where the customer issues the document on the supplier’s behalf under a self-billing agreement.
An invoice issued by an authorised third party on behalf of the supplier.
An invoice issued in USD. The VAT amount must also be expressed in SAR, converted at the SAMA rate on the supply date.
A summary credit note that corrects one or more preceding invoices in a single document, tagged summary.
Simplified tax invoices (reporting)
A simplified tax invoice for a consumer sale. It is signed and stamped locally with the Production CSID, delivered immediately, and reported to ZATCA within 24 hours.
A credit note reducing a previously reported simplified invoice.
A debit note increasing the value of a previously reported simplified invoice.
A simplified invoice on zero-rated supplies, carrying explanatory tax notes for the applied rate.

​
FAQ

From the GOBL invoice type. Simplified invoices (B2C) are reported to ZATCA; all standard invoices (B2B and B2G) are cleared.
Before you share it with the buyer. Standard invoices follow the clearance model: Invopop submits the invoice to ZATCA in real time, ZATCA validates it and applies its cryptographic stamp, and the cleared document is returned. Only that cleared version is legally valid and shareable — so the invoice must go through Invopop before you send it on to the buyer.
Within 24 hours of issuing it. Simplified invoices follow the reporting model, so you can give the invoice to the customer straight away at the point of sale — it does not need ZATCA validation first, and you can share it before it ever reaches Invopop. You then have up to 24 hours from issuance to submit it to Invopop, which forwards it to ZATCA immediately when the workflow runs.
No. Invopop calculates the Invoice Counter Value (ICV) and Previous Invoice Hash (PIH) internally on every submission. You only see them reflected in the generated invoice XML.
ZATCA requires every document a party issues to form a single, unbroken cryptographic chain. Invopop maintains one chain per party and environment (sandbox simulation/developer vs. production are separate sequences), so each registered CSID has its own continuous counter. Two values link it together:
  • ICV starts at 1 for the first document and increments by exactly 1 for every document that follows.
  • PIH of the first document is the hash of the value 0 — the base case defined in ZATCA’s data dictionary. Every document after that sets its PIH to the hash of the immediately preceding document.
Each new document takes the hash of the immediately preceding document and increments ICV by 1, irrespective of type and status:
  • Document type does not split the chain. Standard invoices, simplified invoices, credit notes, and debit notes all share one sequence.
  • Rejected documents still occupy their slot. A document that ZATCA rejects keeps its ICV and hash; the next document chains off it, not off the last accepted one.
For example, if invoice 2 is rejected, invoice 3 still uses hash(invoice 2) as its PIH and ICV = 3:
In the Files section of the silo entry. After a successful submission the final XML is attached as invoice.xml — for standard invoices this is the ZATCA-cleared, stamped document. The QR code is also stamped onto the document.
More available in our Saudi Arabia FAQ section.

Participate in our community

Ask and answer questions about invoicing in Saudi Arabia →