The QR code on a Saudi e-invoice — what it carries and why it exists

The code encodes five data items in a structured format (TLV — each item tagged and length-marked): the seller's registered name, their VAT registration number, the invoice date and time, the invoice total including VAT, and the VAT amount itself. A phone reads the five fields and displays them, so the code can be matched against the paper carrying it — if a number or amount differs, the invoice is not what it claims to be.

The code began in Phase 1 (the generation phase), when invoices were produced electronically without live connection. Its presence on a printed invoice from a connected system is what separates it from an ordinary receipt — and its absence from a consumer invoice is a sign the issuing system is not where it should be.

In the integration phase the code is no longer built from invoice data alone: it is derived from the cryptographic stamp the invoice receives on clearance (for business tax invoices) or reporting (for simplified ones). The code thereby ties the invoice to its record at ZATCA — the code on a cleared invoice carries the trace of that clearance itself, not merely a summary the seller typed.

That is why a non-integrated system cannot produce a valid Phase 2 code however similar the paper looks. The CSID explainer shows how the stamp is built, and the invoice-fields guide shows the two templates the code sits on.

The causes are more practical than technical: a code printed too small or faded after the invoice was photocopied twice; a code generated by a Phase 1 system on an invoice claiming Phase 2; or missing fields in the encoded data because the firm's base data — registered name or VAT number — is wrong in the system at source.

The simplest test is in your hand: scan your own issued invoices with your phone before a customer does. If the phone reads it and shows the right figures, the code is sound; if not, the problem is in your system today, cheaper than a customer or an inspector finding it tomorrow.