A retailer on King Fahd Road with a QR code that scans fine on a phone but fails ZATCA's validation has a specification problem invisible until it's actually tested.

ZATCA requires a QR code on simplified invoices under Phase 1 and an extended version under Phase 2 that includes the cryptographic stamp. The encoding is TLV, tag-length-value, then Base64, and the field order and tag numbers are fixed. Getting any of this wrong produces a code that looks correct to the eye and fails machine validation.

What the code must contain

Phase 1 requires five fields: seller name, seller VAT registration number, invoice timestamp in the specified format, invoice total including VAT, and VAT amount. Phase 2 adds the invoice hash, the cryptographic stamp and the public key. Each is a numbered tag in a fixed sequence, and the timestamp format in particular is a frequent source of failure because systems often default to a local display format rather than the required standard.

Where implementations go wrong

The recurring errors are specific: encoding the values as plain text or JSON rather than TLV, using the wrong tag numbers, omitting leading zeros in the VAT number, formatting the timestamp with a local rather than ISO representation, and rounding the VAT amount differently in the code than on the invoice face so the two disagree. We test against ZATCA's validation tooling rather than by scanning with a phone, because a phone will happily decode an invalidly structured code.

Print and display quality

A technically correct code that cannot be scanned is equally useless. Thermal receipt printers with low resolution or worn print heads produce codes that fail at the point of scanning, and codes printed below the minimum size or without adequate quiet zone margin fail too. For high-volume retail we test on the actual printers in the actual branches rather than on an office laser printer.

A common Saudi scenario

A Riyadh restaurant group passes its own testing because the codes scan on staff phones. A customer's accountant reports that the code will not validate. Investigation finds the timestamp is encoded in local Arabic-numeral format rather than the required ISO standard. Every simplified invoice issued for fourteen months is technically non-compliant, and the fix is a one-line change in the POS configuration that nobody knew was needed.

Verification as an ongoing control

QR correctness is not a one-time check. A POS software update, a printer replacement or a change in invoice template can each break it silently. We build periodic validation into the compliance routine, and it forms part of broader e-invoice integration monitoring so a regression is caught in days rather than at the next inspection.

Fixing historical exposure

When a QR defect is found, the question is not only how to fix it forward but what to do about invoices already issued. We quantify the affected period and volume, assess whether the defect renders those invoices non-compliant or merely imperfect, and where disclosure is warranted, prepare it deliberately rather than waiting for an inspection to raise it. This is the same discipline applied in audit support and it connects to e-invoicing compliance more broadly.

Local context

High-volume retail and food service operators in Riyadh face the greatest print-quality risk given thermal printer use across many branches, while B2B businesses more often need attention to the Phase 2 cryptographic elements of the code.