ZATCA Phase 2: the checklist before you integrate

Phase 1 asked you to change how an invoice looks. Phase 2 asks your system to hand every invoice to ZATCA and wait for an answer. That difference matters operationally: in Phase 1 a badly formatted invoice was an embarrassment; in Phase 2 a rejected invoice is a document you cannot legally give the customer, while they are standing at your counter.

We have onboarded enough companies now to notice the pattern: the integration itself takes a couple of days. What takes three weeks is fixing the master data underneath it. Here is the list we run before we touch a single certificate.

Your own company record

• The VAT registration number on the company record matches the certificate exactly — not a copy with a space in it, not the CR number by mistake.
• The commercial registration number, national address and building number are filled and current. An outdated address is a rejection, not a warning.
• The company name in Arabic is present, correct and matches your registration. Many databases carry only an English trading name.
• Every branch or device that will issue invoices is registered separately, with its own onboarding. One certificate for the whole group is a common and expensive assumption.

Your customers

• Every B2B customer has a VAT number stored in a field the invoice template actually reads. Storing it in an internal note does not count.
• Customer addresses are complete for standard tax invoices. Half-filled addresses that were fine for years become blocking on the day you switch.
• Duplicate customer records are merged first. Two records for one entity means two VAT profiles and eventually one wrong invoice.

Your products and tax setup

• Every product carries the right tax treatment: standard 15%, zero-rated, exempt or out of scope. Products defaulted to standard because nobody checked will misreport exports.
• Unit of measure codes are the ones the schema expects. "Piece", "PC" and "each" are three different answers to the same field.
• Discounts are modelled as discounts, not as negative lines. Negative line items are the single most common structural rejection we see.
• Invoice numbering is sequential, gapless and never reused after a cancellation. If your sequence resets per branch, prove it is still unique.

If you can produce a clean VAT return from your current system without manual adjustment, Phase 2 will be an integration project. If you cannot, it is a data project wearing an integration costume.

What the integration itself involves

Once the data is clean, the technical work is well defined: generate the compliance request and obtain the certificates, produce the XML document in the required structure, apply the cryptographic stamp and hash chain, encode the QR, and send the document for clearance or reporting depending on whether it is a standard or simplified invoice.

Two operational details decide whether go-live is calm. First, what happens when ZATCA is unreachable — your system needs a queue and a retry policy, not an error dialogue in front of a customer. Second, who watches that queue. A failed clearance nobody notices for a week is a compliance problem, not an IT one.

Test in the sandbox, twice

Run the full document set through ZATCA's sandbox before production: standard invoice, simplified invoice, credit note, debit note, and an invoice with a discount and mixed tax rates. Then run it again after the production certificates are installed, because the credentials and endpoints differ and a configuration that passed in sandbox can still fail on the first real document.

Regulations change. Verify the current requirements against ZATCA's official publications before acting on anything here — this article is written from delivery experience, not as legal or tax advice.