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) followed by Base64, and the field order and tag numbers are fixed.

An error in any of these produces a code that looks correct to the eye and fails machine validation. That is a specification problem, and it stays invisible until the code is tested properly.

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 further fields such as the invoice hash, the cryptographic stamp and the public key. Each is a numbered tag in a fixed sequence. The timestamp format is a frequent source of failure, because systems often default to a local display format instead of the required standard.

Where implementations go wrong

The recurring errors are specific: encoding the values as plain text or JSON instead of TLV, using the wrong tag numbers, or altering the format of the VAT registration number. Others include formatting the timestamp in a local representation instead of ISO, and rounding the VAT amount differently in the code than on the invoice face so the two disagree. Testing uses ZATCA's validation tooling, since a phone will decode an invalidly structured code without complaint.

Print and display quality

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

A hypothetical example

Imagine a Riyadh restaurant group whose codes scan on staff phones and pass internal testing. A customer's accountant then reports that the code does not validate. The cause could be a timestamp encoded in a local digit format instead of the required ISO standard, which would be a small POS configuration change 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. Periodic validation belongs in the compliance routine and in wider e-invoice integration monitoring, so a regression is caught early and not at the next inspection.

Fixing historical exposure

When a QR defect is found, the question is not only how to fix it going forward but what to do about invoices already issued. The affected period and volume are quantified, and the next step is agreed with your tax adviser. The same questions arise in audit support, and they connect to e-invoicing compliance more broadly.

Documenting the configuration for whoever comes next

The details of QR encoding are not something anyone remembers a year later. The tag structure, timestamp format, rounding rules and validation test results are documented with dates, so whoever takes over the system can check that a change has not broken anything instead of rediscovering the details when the first problem appears.