XML Invoicing for ZATCA: A Technical Overview
Once you get past QR codes and into ZATCA's Phase 2 requirements, the conversation shifts to XML — a term that means something specific and technical, not just "the file format under the hood." Here's what it actually involves.
Why XML Instead of a PDF
A PDF invoice is built to be read by a person — it looks right, but a computer can't reliably extract structured data from it without extra processing. XML invoicing structures every piece of data — line items, tax amounts, party details, totals — into clearly defined fields a system can read directly, validate automatically, and process without human interpretation. That structure is what makes real-time clearance and reporting possible at ZATCA's scale.
UBL 2.1: The Standard Behind It
ZATCA's e-invoicing XML format is based on UBL 2.1 (Universal Business Language), a widely used international standard for structured business documents, adapted with ZATCA-specific fields and validation rules. Using an established standard rather than a fully custom format means the underlying structure follows patterns already used in electronic invoicing internationally, with Saudi-specific requirements layered on top.
What's Inside a ZATCA XML Invoice
- Invoice header details — invoice number, date, type (simplified or full), and currency.
- Seller and buyer information — including VAT registration numbers, with more detail required for full tax invoices than simplified ones.
- Line items — each product or service, quantity, unit price, and applicable VAT treatment.
- Tax totals — VAT amounts broken out clearly, supporting the calculations ZATCA validates.
- Cryptographic stamp — a digital signature verifying the invoice came from a specific, ZATCA-registered system.
From XML to Compliance
Generating correctly structured XML is only part of Phase 2 compliance — the invoice also needs the cryptographic stamp applied, and then submission to ZATCA for clearance (B2B) or reporting (B2C) through ZATCA API integration. Each piece depends on the others working correctly; a well-formed XML document with an invalid stamp, or a valid stamp on incorrectly structured data, both fail compliance for different reasons.
Why This Matters Even If You're Not Technical
You don't need to read XML yourself to be affected by whether your invoicing software generates it correctly. What matters practically is whether your provider's Phase 2 implementation is built against ZATCA's actual specification, tested against real validation, and honestly represented in terms of what's ready versus what's still in progress.
Frequently Asked Questions
Why does ZATCA require XML instead of PDF invoices for Phase 2?
XML structures invoice data into fields a system can read and validate automatically, which is necessary for real-time clearance and reporting at scale, unlike a PDF built primarily for human reading.
What XML standard does ZATCA use?
ZATCA's e-invoicing format is based on UBL 2.1, an international standard for structured business documents, adapted with ZATCA-specific fields and rules.
What data is included in a ZATCA XML invoice?
Invoice header details, seller and buyer information, line items, tax totals, and a cryptographic stamp verifying the invoice's origin.
Is a cryptographic stamp the same as a QR code?
No. The cryptographic stamp verifies the invoice's origin at a technical level, while the QR code is a scannable summary of key invoice details for humans and simple verification tools.
Do I need to understand XML to use ZATCA-compliant invoicing software?
No. The software generates and submits the correctly structured XML for you; what matters is whether your provider's implementation is built correctly and honestly represented.
The technical details matter, even if you never see them directly. Start free with Booksara for full Phase 1 compliance today, and honest updates as our Phase 2 integration progresses.