If someone has told you that your business needs to be "Phase 2 compliant" and left it there, this article is the missing half of that sentence. It sets out what the Zakat, Tax and Customs Authority actually requires, in the order you will meet it, and where businesses most often get stuck.
Who this applies to
Every business resident in Saudi Arabia that is registered for VAT falls under the e-invoicing regulation, along with anyone issuing a tax invoice on their behalf. Phase 2 does not arrive for everyone at once: the Authority calls businesses in waves, each defined by taxable revenue in a reference year, and notifies each wave at least six months before its integration date. The thresholds have fallen steadily with every wave, which is the important thing to understand — if your business has not been called yet, it will be, and the direction of travel is towards smaller and smaller businesses.
Being in a wave does not change what an invoice is. It changes how it is produced, and who sees it before your customer does.
What a Phase 2 invoice is
Under Phase 1, an invoice had to come out of a system rather than a notepad. Under Phase 2 it has to be a specific kind of file:
- UBL 2.1 XML. The invoice is structured data, not a layout. The PDF your customer reads is a rendering of it; the XML is the invoice.
- A digital signature. Each document is signed using a cryptographic certificate issued to your business by the Authority, so a document can be traced to the establishment that issued it and cannot be altered afterwards.
- A hash chain. Every invoice carries the hash of the one before it — the previous invoice hash, or PIH — and an invoice counter value that only ever increases. Together they make the sequence tamper-evident: remove an invoice from the middle and the chain no longer joins up.
- A QR code. Eight fields, TLV-encoded and Base64 encoded, including the invoice hash, the signature and the public key.
Clearance and reporting
Two roads, decided by who the buyer is.
A standard tax invoice — business to business, or business to government — must be cleared. Your system sends the signed XML to the Authority, which validates it and returns it cleared. Only then may it be given to the buyer. In practice this is synchronous: the customer waits a second or two, and what they receive is a document the Authority has already seen.
A simplified tax invoice — the one handed to an individual at a point of sale — is reported. You give it to the buyer straight away and transmit it within 24 hours. This is why a shop's tills do not stop when the Authority's systems are slow, while a B2B invoice genuinely cannot be issued until clearance returns.
Getting this distinction wrong is the single most common design error we see. A system that reports everything will have B2B invoices rejected; a system that clears everything will hold up a queue of retail customers over a network call.
Connecting: the onboarding sequence
Connecting a business to the Authority follows a fixed sequence, and every compliant solution walks the same path:
- You sign in to the Fatoora portal with your ZATCA credentials and generate a one-time password (OTP) to onboard a new solution unit or device. The code is valid once, within the hour.
- Your solution generates a key pair and a certificate signing request (CSR) carrying your VAT number, business name and address.
- The OTP and the CSR are exchanged for a compliance certificate (CCSID).
- Using that certificate, the solution issues six compliance-check invoices — a standard invoice, a simplified one, and a credit and debit note for each — which the Authority validates one by one.
- Passing all six earns the production certificate (PCSID). Only now can real invoices be cleared or reported.
Two details catch people out. First, the certificate belongs to a device, not to a company: a business with three branches issuing invoices independently needs three onboarded devices, each with its own certificate and its own hash chain. Second, the production certificate expires, and renewing it needs a fresh OTP from the portal. Invoicing does not stop the moment it lapses, but clearance does.
What usually goes wrong
The rejections we see most often are not exotic. They are: a national address missing its district or building number, so the seller block fails validation; a customer's VAT number typed with fifteen digits that do not start and end with 3; a document-level discount that is not prorated across the lines, so the VAT column and the VAT total disagree; and a broken hash chain after an invoice was issued from two places at once.
None of these are judgement calls. They are field-level rules, and a solution that validates before it signs will catch every one of them before the Authority does.
What you actually have to do
If you already have a system that produces invoices, you do not need to replace it — you need to connect it, through an API that handles the signing, the chain and the transmission. Our API reference documents that integration end to end.
If you do not have such a system, you need a compliant one, and that can be as simple as a browser tab: enter your VAT number, paste an OTP, and issue. You can see what the finished document looks like on the ZATCA Tools home page, work out a figure with the VAT calculator, or check an invoice you have already been handed with the QR code reader.
Either way the obligation is the same, and it is worth saying plainly: the business issuing the invoice remains responsible to the Authority for what is on it. A good solution makes that responsibility easy to discharge. It does not remove it.
More articles are on the way — the English blog is where they will appear.