The most common misconception we run into is that ZATCA Phase 2 is about what appears on the invoice. It is not. Phase 1 was largely about invoice content โ a QR code, the right fields, no handwritten invoices. Phase 2 is about the invoice being a structured document that your systems and ZATCA's systems exchange directly.
If your finance team still generates a PDF and emails it, that flow does not become compliant by adding a QR code to the template.
The four technical requirements
1. A structured XML invoice
Invoices must be produced as XML conforming to UBL 2.1, following ZATCA's specific implementation rules. The PDF becomes a human-readable rendering of the XML, not the invoice itself. In practice this means your ERP needs a mapping layer between its internal invoice model and the required schema โ including fields most systems do not track natively, such as the buyer's VAT registration handled distinctly from other identifiers.
2. Cryptographic stamping
Each invoice carries a cryptographic stamp generated with a certificate issued by ZATCA, obtained through an onboarding process (a CSR is submitted, a compliance certificate is issued, then a production certificate). Your ERP โ or the middleware sitting beside it โ has to store those credentials securely and renew them. This is the part most often underestimated: it is key management, and it needs an owner.
3. The QR code, properly encoded
The QR code is TLV-encoded (tag-length-value), base64 encoded, and contains defined fields including the seller name, VAT number, timestamp, total with VAT, VAT amount, and for standard invoices the hash and signature. Rendering a QR code containing a URL or plain text will pass a visual inspection and fail a real one.
4. Transmission to ZATCA
This is the requirement that changes system architecture, because it splits by invoice type:
- Standard tax invoices (B2B) go through clearance. The invoice is sent to ZATCA and must be cleared before it is issued to the buyer. ZATCA returns a cleared XML, and that is the legal invoice.
- Simplified tax invoices (B2C) go through reporting. The invoice is issued to the customer immediately, then reported to ZATCA within 24 hours.
Clearance means a synchronous external dependency now sits in the middle of your invoicing process. That has consequences worth designing for deliberately.
The design questions people miss
What happens when ZATCA is unreachable? For B2B clearance you cannot simply issue the invoice anyway. You need a queue, a retry policy, and a clear operational answer for the finance team about what an invoice stuck in that queue means commercially. Build it before you need it.
Where does the counter live? Invoices in a device's sequence are chained โ each carries the hash of the previous one. That counter and chain must be maintained per device or per invoicing unit. If you have multiple branches, multiple POS terminals, or you are planning a migration between systems, decide early how these units map, because it is painful to restructure later.
Who owns credential renewal? Certificates expire. If nobody is accountable for renewing them, you will discover the expiry the way everyone else does: invoicing stops.
What to actually check
If you are assessing whether a system is Phase 2 ready, these questions get you to the truth faster than a vendor datasheet:
- Show me the XML produced for a standard invoice โ not the PDF.
- Show me a cleared invoice with ZATCA's response stored against it.
- What happens to invoice number 501 if invoice 500 failed to clear?
- Where are the certificates stored, and who is notified before expiry?
- Can we reproduce the hash chain for an audit covering last quarter?
A system that answers all five confidently is compliant in the way that matters. One that answers the first and gestures at the rest usually means the integration was built for the demo.
This article describes technical requirements as we implement them and is not tax advice. Confirm your specific obligations, wave assignment and deadlines with ZATCA or your tax advisor.