QR Codes on Tax Invoices: TLV, Signed JWT, and Verification URL Formats Compared

Every clearance-model e-invoicing mandate requires a QR on the buyer-facing invoice, but the QR format is set by the regulator and varies sharply: ZATCA Phase 2 uses a Base64-encoded TLV (Tag-Length-Value) structure that includes the seller, totals, signature hash, and public key for offline verification; India's GST IRN uses a signed JSON Web Token (JWT) with the IRN, GSTINs, and totals; FIRS MBS, GRA e-VAT, and KRA eTIMS use a verification URL that resolves to the regulator's public lookup endpoint; and MyInvois uses a hybrid UUID + URL format. A multi-jurisdiction platform must emit the correct format per destination regulator on every cleared invoice.

Why regulators mandate a QR

The QR is the buyer's primary verification surface — the artefact a clerk in accounts payable scans to confirm the invoice was actually cleared by the tax authority. Without a verifiable QR, the regulator's clearance is invisible at the buyer's end and the whole clearance chain breaks.

The QR is the buyer's primary verification surface — the artefact a clerk in accounts payable scans to confirm the invoice was actually cleared by the tax authority. Without a verifiable QR, the regulator's clearance is invisible at the buyer's end and the whole clearance chain breaks. Three design forces shape the QR format choice:

• Offline verifiability — can the buyer confirm authenticity without hitting the regulator's server? (Yes for TLV and JWT; no for URL.)
• Payload size — how much data must fit in the QR symbol before scan reliability degrades? (URLs are smallest; signed JWTs are largest.)
• Data freshness — does the verifier see the regulator's current view, or a snapshot? (URLs are always fresh; TLV/JWT are issuance-time snapshots.)

Format 1 — TLV (Tag-Length-Value), Base64-encoded

Used by ZATCA Phase 1 and Phase 2 in Saudi Arabia. The QR encodes a binary structure where each field has a numeric tag, a length byte, and a UTF-8 value.

Used by ZATCA Phase 1 and Phase 2 in Saudi Arabia. The QR encodes a binary structure where each field has a numeric tag, a length byte, and a UTF-8 value. The whole TLV byte string is then Base64-encoded for QR rendering.

Phase 1 TLV — five mandatory fields

1. Tag 1: Seller name (UTF-8 string).
2. Tag 2: Seller VAT registration number (15-digit, starts and ends with 3).
3. Tag 3: Timestamp in ISO 8601 UTC.
4. Tag 4: Invoice total including VAT.
5. Tag 5: VAT total.

Phase 2 TLV — extended with signature

Phase 2 adds four cryptographic fields that make the QR verifiable offline:

6. Tag 6: XML invoice hash (SHA-256, Base64).
7. Tag 7: ECDSA signature over the canonicalised invoice.
8. Tag 8: EGS public key (DER-encoded, Base64).
9. Tag 9: ZATCA-issued certificate signature for the public key.

A buyer with a Phase 2-capable viewer can decode the TLV, hash the invoice locally, and verify the signature chains back to a trusted ZATCA root — no portal lookup required. See what is a CSID for the cryptographic credential at the heart of this scheme.

Format 2 — Signed JWT

Used by GST IRN in India. The QR encodes a JSON Web Token (RFC 7519) signed by the NIC IRP using RSA-SHA256.

Used by GST IRN in India. The QR encodes a JSON Web Token (RFC 7519) signed by the NIC IRP using RSA-SHA256. The JWT payload contains:

• The 64-character IRN.
• Seller and buyer GSTINs.
• Document type, document number, document date.
• Total invoice value and total GST.
• Main HSN code.
• Signing certificate identifier and algorithm.

Any compliant viewer can decode the JWT, fetch the published IRP signing certificate, and verify the signature offline. This is the basis on which the Indian buyer claims input tax credit.

Trade-off: JWT payloads are larger than TLV or URL, which requires higher QR density (version 10+ symbols) and good print quality. A smudged JWT QR is a denied ITC claim.

Format 3 — Verification URL

Used by FIRS / NRS MBS in Nigeria, GRA e-VAT in Ghana, KRA eTIMS in Kenya, and several Latin American mandates.

Used by FIRS / NRS MBS in Nigeria, GRA e-VAT in Ghana, KRA eTIMS in Kenya, and several Latin American mandates. The QR encodes a URL to the regulator's public verification endpoint with the IRN or invoice ID as a parameter:

https://einvoice.firs.gov.ng/verify?irn={IRN}&tin={SELLER_TIN}

The buyer scans the QR, follows the URL on a phone or AP system, and the regulator's page confirms the seller, buyer, totals, and timestamp.

Trade-off: small payload, always-fresh data — but requires the regulator's portal to be online for verification. During regulator downtime the buyer cannot confirm clearance.

Format 4 — Hybrid (UUID + verification URL)

Used by MyInvois in Malaysia and by ZATCA Phase 2 B2C invoices. The QR carries both an identifier (UUID for MyInvois; cleared invoice reference for ZATCA B2C) and a verification URL to the regulator's portal.

Used by MyInvois in Malaysia and by ZATCA Phase 2 B2C invoices. The QR carries both an identifier (UUID for MyInvois; cleared invoice reference for ZATCA B2C) and a verification URL to the regulator's portal. This gives offline identifier capture plus optional online deep-verification.

Side-by-side comparison

Side-by-side comparison — Offline verification: Yes (Phase 2) — Yes (with cert).

Implementation patterns for multi-jurisdiction platforms

Implementation patterns for multi-jurisdiction platforms includes: Centralise QR generation in a single service that takes a canonical input (regulator, IRN/UUID, signature material, verification URL template) and emits the correct format. Do not duplicate QR logic per integration.

• Centralise QR generation in a single service that takes a canonical input (regulator, IRN/UUID, signature material, verification URL template) and emits the correct format. Do not duplicate QR logic per integration.
• Pre-test print quality — JWT QRs that look fine on screen smudge into illegibility on thermal paper. Pick error correction Q and minimum module size 4 for printed invoices.
• Validate the regulator round-trip for every QR you generate in sandbox before go-live. Decode your own QR, hit the regulator's verification endpoint (or verify the signature for TLV/JWT), confirm the data matches.
• Surface the QR to the buyer in two formats — the visual QR on the PDF, and a copyable text link for accessibility and AP automation.
• Re-issue QRs on credit/debit notes — every cleared document gets its own QR; do not reuse the original invoice's QR on the credit note.

Key takeaways

Key takeaways includes: You don't choose the QR format — the regulator does. Build the per-jurisdiction emitter, don't argue.

• You don't choose the QR format — the regulator does. Build the per-jurisdiction emitter, don't argue.
• TLV is compact and offline-verifiable; JWT is offline-verifiable but large; URLs are tiny but online-only; hybrid bridges both.
• For printed invoices, prefer error correction Q and pre-test on actual paper.
• Multi-jurisdiction platforms must centralise QR generation in one service and emit the correct format per destination.
• The QR is the buyer's verification surface — not generating it correctly costs the buyer their input tax claim and costs you working capital.

Related reading

For the mandate context, read clearance vs reporting models in e-invoicing and real-time invoice reporting. For the cryptographic primitives, see what is a CSID and what is an IRN.

For the mandate context, read clearance vs reporting models in e-invoicing and real-time invoice reporting. For the cryptographic primitives, see what is a CSID and what is an IRN. For platform selection, the 12-point platform checklist includes QR-generation requirements. For the pillar, see the Invoicemonk global e-invoicing platform.

Authority sources

• ZATCA — Guide to FATOORA-compliant QR code (TLV specification)
• ZATCA — E-invoicing Detailed Technical Guidelines (Phase 2 cryptographic fields)
• GSTN — e-Invoice portal (signed JWT QR specification)
• FIRS / NRS MBS — verification URL endpoint
• IETF RFC 7519 — JSON Web Token specification