Everything You Need to Know About
ZATCA QR Codes

Yesterday, June 30, 2026, was a deadline that quietly reshaped Saudi commerce. Wave 24 of ZATCA’s Phase 2 e-invoicing rollout came into force — the first wave to reach all the way down to businesses with as little as SAR 375,000 in annual taxable revenue, which is also the mandatory VAT registration threshold itself. In practical terms, that means almost every VAT-registered business in the Kingdom is now required to be integrated with the Fatoora platform. The penalty-waiver window that let businesses fix onboarding mistakes without financial consequence closed on the same date. As of today, ZATCA’s e-invoicing enforcement is effectively universal.

If you build or maintain a POS, ERP, or billing system for the Saudi market, that little black-and-white square on every receipt is no longer optional homework — it’s the single most visible proof of compliance your software produces. This guide covers what the QR code actually contains, why ZATCA built the program this way, the real differences between Phase 1 and Phase 2, how B2B and B2C invoices diverge, how a buyer actually claims VAT back, and the mistakes that most often make a QR code fail validation. At the bottom, there’s a free client-side generator so you can build and inspect a compliant QR code yourself, tag by tag.

What Is ZATCA E-Invoicing, and Why Does It Exist?

ZATCA — the Zakat, Tax and Customs Authority — is the Saudi government body responsible for collecting VAT, Zakat, customs duties, and enforcing e-invoicing compliance. It was formed in 2021 from the merger of the General Authority of Zakat and Tax (GAZT) and the General Authority of Customs, consolidating tax administration under one roof.

Saudi Arabia introduced VAT on January 1, 2018, at 5%, as part of a coordinated GCC-wide rollout. On July 1, 2020, facing collapsing oil revenue and the fiscal shock of COVID-19, the government tripled the rate to 15%, where it remains today. A tax that large, applied across an entire economy, is only as good as the government’s ability to verify it’s actually being collected and remitted — and paper invoices, handwritten receipts, and spreadsheet-generated bills are trivially easy to under-report or simply never issue. That gap between VAT collected from customers and VAT actually declared to the state is what the e-invoicing program, branded Fatoora, was built to close.

The QR code is the visible tip of that system. It turns every receipt into a machine-readable, independently verifiable record, so a customer, an auditor, or ZATCA’s own systems can confirm an invoice is genuine without trusting the paper it’s printed on. The program rolled out in two officially defined phases:

• December 4, 2021 — Phase 1 (Generation Phase): every VAT-registered business had to stop issuing handwritten or spreadsheet-generated invoices and switch to a compliant electronic system that could produce and store e-invoices with a TLV QR code.
• January 1, 2023 onward — Phase 2 (Integration Phase): businesses connect their e-invoicing system directly to ZATCA’s Fatoora platform for real-time clearance or reporting. Because connecting every business simultaneously isn’t operationally realistic, ZATCA rolled this out in successive “waves,” grouped by annual taxable revenue, each announced at least six months ahead of its deadline. Wave 1 (turnover above SAR 3 billion) went live January 1, 2023; Wave 24 (turnover above SAR 375,000) went live yesterday.

There is no separately announced “Phase 3” as of this writing — the program is officially two phases, with Phase 2 itself still expanding through further waves as ZATCA works down toward smaller taxpayers and, eventually, an even wider net including e-invoicing for VAT return pre-filling. Treat any content that references a distinct “Phase 3” as informal shorthand for a future wave, not an official designation.

How a ZATCA QR Code Actually Works

A ZATCA QR code is not a link. Scan one with a generic QR app and you won’t land on a website — you’ll get a block of Base64 text. That text is the output of a specific three-stage pipeline defined in ZATCA’s own Electronic Invoice Security Features Implementation Standards:

1. Build the TLV structure. Every field — seller name, VAT number, timestamp, and so on — is encoded as Tag + Length + Value: a 1-byte tag number, a 1-byte length (the byte-length of the value, not its character count), and the value itself as UTF-8 bytes. Every field is concatenated, tag after tag, into one continuous byte array.
2. Base64-encode the byte array. The entire TLV structure, as raw bytes, is converted into a single Base64 string. ZATCA caps this string at 700 characters.
3. Render the Base64 string as a QR code. Only at this final step does the text actually become the black-and-white square printed on the receipt.

Here’s the core of that logic in JavaScript — the same function powering the generator further down this page:

That one comment — never value.length — is worth dwelling on. A JavaScript string’s .length counts UTF-16 code units, not bytes. “Bobs Records” happens to have the same character count and byte count in plain ASCII, so a lazy implementation works fine in testing and then silently corrupts every invoice with an Arabic seller name in production, since Arabic characters take 2 bytes each in UTF-8. We’ll come back to this in the common-errors section, because it’s one of the most frequent real-world causes of QR rejection.

Phase 1 vs Phase 2: What Actually Changed

It’s easy to think of Phase 2 as “Phase 1 plus a few extra fields.” In reality, it’s a different architecture. Phase 1 asked you to generate a correct document. Phase 2 asks you to generate a correct document and prove it to ZATCA in real time, tied to a hardware- or software-bound cryptographic identity.

B2B vs B2C: Which Rules Apply to You

ZATCA regulation recognizes two invoice types, and confusing them is one of the fastest ways to end up out of compliance or, for a buyer, unable to reclaim VAT they thought they could.

Standard Tax Invoice (B2B / B2G): used between two VAT-registered parties. It must show both the seller’s and the buyer’s name and VAT number, a line-item breakdown, and per-line VAT amounts. Under Phase 2, it follows the Clearance model: your system submits the invoice to ZATCA’s Fatoora platform and must receive approval — including a cryptographic stamp — before the invoice is legally allowed to reach the buyer. A QR code on a standard invoice is optional in most cases, though many ERPs include one anyway, and Fatoora’s clearance response typically carries the cryptographic material needed to build one.

Simplified Tax Invoice (B2C): used at the point of sale, typically where the buyer isn’t VAT-registered or isn’t known at the time of sale — a retail receipt being the classic example. It follows the Reporting model: the invoice is issued to the customer immediately, and your system reports it to ZATCA within 24 hours afterward. A QR code is mandatory on every simplified invoice, and it’s the version most people mean when they say “ZATCA QR code.”

Two thresholds worth knowing: a standard tax invoice is legally required whenever a B2B supply exceeds SAR 1,000 (below that, a simplified invoice is acceptable even between two businesses), and the seller’s VAT number can be omitted from a simplified invoice entirely if the total invoice value is under SAR 1,000.

The distinction matters well beyond formatting. As covered in the VAT-claiming section below, only a standard tax invoice supports an input VAT deduction claim — a simplified invoice, however perfectly formatted its QR code, generally will not.

All 9 TLV Tags, Explained

Every field ZATCA can require in a QR code has a fixed tag number. Tags 1–5 have been mandatory since Phase 1; tags 6–9 were added for Phase 2.

Generation order matters. Build and cryptographically sign the XML invoice first. Only then compute the hash, extract the signature, and assemble the QR. Generating the QR before signing produces tags 6–9 that are empty or stale — a surprisingly common bug, and an instant rejection.

What Business Owners Actually Need to Do

Strip away the acronyms and compliance comes down to five stages. Here’s the path from “not registered” to “live on Fatoora.”

1. Register for VAT

Mandatory once your annual taxable supplies exceed SAR 375,000. Between SAR 187,500 and that threshold, registration is voluntary — and often worthwhile, since it lets you reclaim input VAT on your own purchases. Non-resident businesses making taxable supplies in the Kingdom must register regardless of turnover.

2. Get a Phase 1-compliant system, then check your wave

Every VAT-registered business already needs Phase 1 generation capability today. Phase 2 arrives on a schedule: ZATCA groups taxpayers into waves by annual taxable revenue and notifies each group at least six months before its deadline. The thresholds have compressed fast — Wave 1 covered turnover above SAR 3 billion; Wave 24, live as of yesterday, covers turnover above SAR 375,000. If you haven’t been notified yet, it’s worth checking directly with ZATCA rather than assuming you’re outside scope.

3. Complete CSID onboarding on the Fatoora portal

This is the technical core of Phase 2, and it follows a fixed five-step sequence:

1. Log into the Fatoora portal using Single Sign-On through your ZATCA taxpayer account.
2. Generate a One-Time Password (OTP) for each device or solution unit you want to onboard.
3. Submit a Certificate Signing Request (CSR) along with the OTP, and receive a Compliance CSID — a sandbox certificate.
4. Pass compliance checks by submitting sample standard and simplified invoices through the sandbox for ZATCA to validate.
5. Receive your Production CSID — valid for roughly a year and renewable before expiry — and go live against the real Fatoora endpoint.

4. Test end-to-end before your deadline

ZATCA provides a Fatoora Simulation Portal specifically so you can rehearse onboarding, clearance, and reporting without touching production data. Industry practice is to finish this at least a month before your wave deadline, since certificate issues and rejected sample invoices are far cheaper to fix before enforcement starts than after.

5. Keep records — longer than you’d think

Invoices, notes, and supporting records must be retained for a minimum of 6 years from the end of the relevant tax period — extended to 11 years for anything connected to real property. Records must be kept in Arabic (bilingual is fine) and stored within Saudi Arabia.

What non-compliance actually costs

ZATCA’s penalty framework scales with the violation, and fines increase for repeated offenses. Published figures include:

Figures above are drawn from ZATCA’s published penalty structure and third-party compliance summaries as of mid-2026; always confirm current amounts directly on zatca.gov.sa, as penalty schedules are revised periodically.

Verifying a QR Code & How VAT Actually Gets Claimed

Verifying a QR code

Because the QR payload is plain Base64 text, any generic QR scanner can technically read it — but reading isn’t the same as validating. To actually confirm an invoice is genuine, decode the TLV structure, and check its cryptographic stamp against ZATCA’s certificate chain, use ZATCA’s own VAT app (available for iOS and Android) or the e-invoice validation service on zatca.gov.sa. That distinction is exactly why a QR code that merely “looks right” on screen can still fail a real scan — something worth remembering when you test your own output.

How a business actually claims VAT back

This is the part general explainers usually skip, and it’s the answer to the question we get asked most: does having a QR code on an invoice mean I can claim the VAT back? Not by itself, and not always.

Saudi VAT runs on a credit-invoice system: a VAT-registered business collects output VAT on what it sells and can offset that against input VAT it paid on its own purchases, remitting only the difference to ZATCA. To exercise that right of deduction, the Implementing Regulations (Article 53(5)) require the business to hold a valid Tax Invoice — specifically a standard tax invoice showing both parties’ VAT numbers, the date, a description of the supply, and the VAT amount. A simplified (B2C-style) invoice, QR code and all, generally does not support an input VAT claim, because it isn’t required to identify the buyer at all.

Under Phase 2, there’s an additional gate: per ZATCA’s E-Invoicing Implementation Resolution, an electronic invoice must actually have been Cleared by or Reported to ZATCA to be usable as evidence for an input VAT deduction — an invoice your supplier generated but never submitted to Fatoora doesn’t count, regardless of how correct it looks.

A few practical rules for the buyer’s side:

• Timing: the right to deduct arises in the tax period the supply is received and the tax invoice is issued — not when payment is made or the goods are consumed.
• Filing cadence: businesses with annual turnover above SAR 40 million file VAT returns monthly; everyone else files quarterly.
• Retention: keep the invoice for 6 years (11 for real-estate-related supplies) — ZATCA can request it during an audit long after the fact.
• Language: the invoice must carry the required details in Arabic. ZATCA can, at its discretion, accept alternative evidence if a supplier’s invoice is incomplete, but the supplier remains obligated to issue a proper Arabic tax invoice.

In short: the QR code proves the receipt is genuine. Whether the VAT on it is reclaimable is a separate question, answered by the invoice type, not by whether it has a QR code at all.

Common QR Code Errors & How to Fix Them

Most “invalid QR code” reports trace back to a small, repeatable set of implementation mistakes. In rough order of frequency:

• Using character length instead of byte length. The Length tag must be the UTF-8 byte length of the value. Arabic, and any non-ASCII text, takes more bytes than characters — get this wrong and every Arabic seller name silently corrupts the invoice after it.
• Generating the QR before signing the XML. Tags 6–9 depend on the final, signed document. Build the QR first and those tags end up empty, stale, or built from a hash that no longer matches the invoice ZATCA actually receives.
• ASCII-only encoding. Some legacy libraries default to Latin-1 or Windows-1252. ZATCA requires strict UTF-8 throughout — anything else breaks as soon as a value contains an Arabic character, a curly quote, or certain symbols.
• Omitting the Arabic seller name. An English-only trade name is a common shortcut for international brands, but the printed invoice — and by extension the data behind it — needs an Arabic name present.
• Values that exceed 255 bytes. The Length byte can only represent 0–255. An unusually long legal entity name or an unexpectedly verbose field can overflow it — validate field lengths before encoding, not after a QR fails to scan.
• Mixing up invoice types. Tag 9 (ZATCA’s own cryptographic stamp) applies to simplified invoices reported after the fact; standard invoices are cleared through a different flow. Copying one invoice type’s tag structure onto the other produces a QR that looks plausible and fails validation.
• Trusting that it “looks like a QR code” means it’s valid. A malformed TLV structure can still render as a scannable, visually normal QR code — the only way to know it’s correct is to decode it and check the fields, or scan it with ZATCA’s own validation app.

Try It: Free ZATCA QR Code Generator

Fill in the fields below and watch the TLV structure, Base64 payload, and QR code update live. Everything runs as JavaScript in your browser — nothing you type is sent anywhere. It’s pre-loaded with example data (including an Arabic seller name, to show the UTF-8 byte-length handling from earlier in action) so you can see a working code immediately.

Frequently Asked Questions (FAQs)