ZATCA Phase 2 e-invoicing: what integration actually requires

Phase 1 and Phase 2 are different problems

Phase 1 (Generation) asked for a structured electronic invoice with a QR code and a fixed set of fields. Any billing system that could produce a compliant document satisfied it, and nothing left your building. Phase 2 (Integration) is a different category of work: your system now talks to ZATCA's platform for every invoice you raise, and the tax authority answers.

That single change is what catches teams out. A Phase 1 implementation is a document format. A Phase 2 implementation is an availability-critical integration, with cryptographic keys, certificates that expire, and an outbound dependency that sits between your cashier and a printed invoice.

Clearance and reporting are not the same flow

Standard tax invoices — business-to-business documents — go through clearance. You submit the invoice to ZATCA before you give it to the buyer, and it is only a legally valid tax invoice once ZATCA has cleared it and returned a signed copy. If clearance fails, you do not have an invoice yet.

Simplified tax invoices — typical business-to-consumer point-of-sale receipts — go through reporting. You issue and hand over the receipt immediately, then report it to ZATCA afterwards, within the published window. The customer never waits on the network.

The practical consequence is that your point of sale and your B2B invoicing need different failure behaviour. A shop till must keep selling when the connection drops and reconcile later. A B2B invoice must not be treated as issued until it clears.

The cryptographic pieces, in order

Integration is mostly a sequence of credentials. Each step depends on the one before it, and each is a place a deployment stalls:

• A key pair and a certificate signing request (CSR) generated per device or per billing unit, carrying your VAT registration details in the exact fields ZATCA expects.
• A compliance certificate obtained by submitting that CSR with a one-time password from the ZATCA portal — this is the step that fails most often, because the OTP is short-lived.
• Compliance checks: sample invoices, credit notes and debit notes of each type you intend to issue, all accepted before you are allowed to go further.
• A production certificate, which is what actually signs live documents — and which has an expiry date somebody must own long before it arrives.

What the invoice itself has to carry

The document you submit is UBL 2.1 XML, not a PDF. Inside it sit the pieces that make the invoice verifiable: a cryptographic hash of the previous invoice, which chains your documents together so a deleted or inserted invoice is detectable; a digital signature; and a QR code carrying the seller name, VAT number, timestamp, total, VAT amount and the signature data in a defined binary encoding.

Human-readable output still matters — buyers want a document they can file — so most implementations produce a PDF/A-3 with the signed XML embedded, giving one file that is both readable and machine-verifiable.

The failure modes worth designing for

Any system that has run this in production has met the same short list, and each one is a design decision rather than a bug to fix later:

• ZATCA is unreachable or slow. Simplified invoices should queue and report later; standard invoices cannot simply be issued anyway. Decide, in advance, what the cashier sees.
• A certificate expires. Renewal is a scheduled operational task, not an incident — an expired production certificate stops invoicing entirely.
• An invoice is rejected on a field your ERP allows but ZATCA does not — unusual units of measure, discounts or shipping lines modelled in a way the XML mapping does not express.
• The hash chain breaks after a restore from backup or a manual database edit, and every subsequent invoice inherits the problem.

What to ask a vendor

Compliance claims are cheap. Useful questions are specific: which document types have you had cleared and reported in production, not in the sandbox? What happens to a sale when ZATCA times out? Who renews the certificate, and what warns them? Can I export my signed XML and the hash chain if I leave? A vendor who has genuinely run Phase 2 will have concrete answers, because each of these has cost them a day at some point.