← Back to blog

Is the QR Code on Your Receipt Actually Valid?

Saudi retailers: check if your till receipt QR code is ZATCA compliant. The five TLV fields it must carry, and how to test yours in two minutes.

A QR code printed on a receipt is not automatically a compliant QR code. Plenty of tills in Saudi Arabia print a square black-and-white pattern that scans perfectly well and still fails a ZATCA check, because what is inside it is the wrong thing entirely.

You can test yours in about two minutes with the phone in your pocket. This article explains what has to be inside the code, how to look, and what to do if the answer is bad.

Why the receipt needs a code in the first place

Under ZATCA's e-invoicing rules, a simplified tax invoice is what you hand a walk-in customer — the till receipt in a shop, restaurant or pharmacy. It is the B2C document, as opposed to the standard tax invoice you issue to another registered business.

Phase 1, the generation phase, came into effect on 4 December 2021. From that date every simplified tax invoice has had to carry a QR code. This was not a recommendation. It applies to any VAT-registered business making retail sales, whatever the size of the shop.

The point of the code is that an inspector, or the customer, can scan the receipt and read back the core tax facts without trusting the paper. That only works if the data is encoded the way ZATCA specified.

The five fields, in this order

ZATCA's Electronic Invoice Security Features Implementation Standard defines nine possible tags. For a Phase 1 simplified tax invoice, five are required:

Tag Field Type
1 Seller's name Text (UTF-8)
2 VAT registration number of the seller Text (UTF-8)
3 Time stamp of the invoice (date and time), ISO 8601 Text (UTF-8)
4 Invoice total (with VAT) Text (UTF-8)
5 VAT total Text (UTF-8)

Tags 6 to 9 — the hash of the XML invoice, the ECDSA signature, the public key, and ZATCA's cryptographic stamp — belong to Phase 2, the integration phase. If you are only obliged to meet Phase 1, tags 1 to 5 are what matters.

Two details in that table cause most of the trouble. The VAT registration number in tag 2 is the 15-digit number ZATCA issued to you, not your commercial registration number and not your national ID. And the timestamp in tag 3 must be ISO 8601 — ZATCA's own example in the standard is 2022-02-21T12:13:57Z. That is date, the letter T, time, then Z. Not 21/02/2022 12:13 PM.

What TLV and Base64 mean here

The five fields are not simply written out one after another. They are encoded in Tag-Length-Value format, then the whole thing is Base64 encoded, and that Base64 string is what goes into the QR image.

TLV works like this. For each field you write one byte for the tag number, one byte for the length of the value, then the value itself in UTF-8. So a seller name of "Niazi Store" becomes tag 01, length 0B (eleven bytes), then the eleven bytes of the name. All five fields run together with no separators or commas between them.

The length byte counts bytes, not characters. This matters for Arabic. An Arabic letter takes two bytes in UTF-8, so a four-letter Arabic shop name needs a length of 8, not 4. Getting this wrong is one of the more common bugs in home-grown till software, and it produces a code that looks fine and decodes to nonsense.

Once the TLV bytes are assembled, they are Base64 encoded into an ASCII string. That string is the QR payload.

Check your own receipt in two minutes

You do not need special software.

  1. Take a recent receipt from your till. A real one, not a test print.
  2. Open any QR scanner on your phone. The built-in camera app on most phones will do it.
  3. Point it at the code and look at what the phone offers you.

What you are looking for is a long string of jumbled letters, numbers and possibly +, / or = characters. Something in the shape of AQtOaWF6aSBTdG9yZQIPMzAwMTIzNDU2NzAwMDAzAxQyMDI2LTA4LTE5VDE0OjMwOjAwWgQGMTE1LjAwBQUxNS4wMA==. That example is a real, correctly formed payload: it decodes to the seller name Niazi Store, VAT number 300123456700003, timestamp 2026-08-19T14:30:00Z, total 115.00 and VAT 15.00. Your phone will not know what to do with it, and may offer to search the web for it. That is the correct outcome. Base64 is meant to be unreadable to a human.

If instead your phone opens a website, or shows you a tidy line of readable text like Shop Name | Total: 115.00, the code is wrong.

To confirm the contents rather than just the shape, ZATCA publishes a free official app for iOS and Android that verifies an e-invoice by scanning its QR code. Scanning your own receipt with it is the closest thing to a definitive answer, and it costs nothing.

The four failures worth checking for

A QR code containing a URL. This is the most frequent one. The till prints a code that opens a link to a receipt page, a loyalty programme, or the vendor's website. It may be genuinely useful to customers. It is not a ZATCA QR code and does not satisfy the requirement.

Plain text instead of TLV. The code decodes into something readable, such as the shop name and total separated by dashes or line breaks. The right data is present, but it is not TLV-encoded and not Base64 encoded, so it cannot be validated.

A missing or wrong VAT number. Tag 2 is either absent, empty, or filled with the commercial registration number. Check the number on your receipt against the 15-digit VAT number on your ZATCA certificate, digit by digit. They are easy to confuse and the till was often configured years ago by someone who has left.

A wrong timestamp format. Local formats like 19-08-2026 14:30 will not do. It has to be ISO 8601 with the T separator, and ZATCA's example carries the trailing Z. Some systems also print the date only and omit the time, which fails for the same reason.

What happens at an inspection

ZATCA runs field visits to retail premises, and inspectors scan receipts on the spot.

The authority has stated that violations for not including the QR code on a simplified tax invoice begin with a warning to the facility rather than an immediate fine, and that fines are then applied according to the type of violation and how many times it is repeated. Other e-invoicing breaches are treated more sharply — failing to issue electronic invoices at all carries a fine of SAR 5,000, and deleting or amending an invoice after issuance carries SAR 10,000.

The practical reading is that a first warning is a chance to fix things, not a verdict, but it starts a clock. Repeat findings on later visits are where it becomes expensive. We cover the wider penalty structure in ZATCA penalties for non-compliance.

If your till is producing invalid codes

Start with your software vendor. Send them a photo of the receipt and the decoded string, and ask directly whether their QR output is TLV-encoded per ZATCA's Security Features Implementation Standard. A vendor who cannot answer that question clearly is telling you something.

If the till is old, unsupported, or the vendor has gone quiet, you have two realistic options. Replace the point-of-sale software with something that generates the code correctly, or issue compliant documents alongside it while you sort out the till.

For the second, you can create a ZATCA-compliant invoice free as a stopgap. For the first, our POS software for Saudi Arabia prints simplified tax invoices with a proper TLV Base64 QR code on every receipt.

Both are worth doing before an inspector scans a receipt for you. The invoice generator is free to use. The POS software has a 7-day free trial and is paid after that — it produces Phase 1 simplified tax invoices with a compliant QR code, and does not connect to FATOORA for Phase 2 clearance.

Is your till producing a valid code?

SwiftPOS encodes the five TLV fields correctly on every receipt. 7 days free, no card.