What it is
A QR code on an electronic invoice is a quick-response 2D barcode that encodes a tax-relevant subset of the invoice's data, plus — in most regimes that mandate it — a cryptographic signature or hash that the tax authority can verify offline. The point is to make the invoice independently verifiable: a buyer, an inspector, or a downstream system can scan the code with any phone and confirm what the seller actually issued, without having to retrieve the full XML.
QR codes are not part of EN 16931 and are not required by Peppol BIS Billing 3.0. They sit on top of structured e-invoicing where regulators want a tamper-evident link between the printable representation and the reported data.
How the encoding usually works
Most regulators specify a deterministic encoding so that any compliant device can produce the same code from the same invoice. The dominant pattern is TLV (Tag-Length-Value) byte-encoding plus Base64. Saudi Arabia's ZATCA, the most-cited reference implementation, defines nine TLV tags:
1. Seller name
2. Seller VAT registration number
3. Invoice timestamp (ISO 8601, UTC)
4. Invoice total (with VAT)
5. VAT total
6. Hash of the XML invoice (SHA-256, base64)
7. ECDSA signature
8. Public key of the cryptographic stamp
9. Signature of the cryptographic stamp's public key by ZATCA
The nine fields are concatenated as TLV bytes, the whole payload is Base64-encoded, and the resulting string is rendered as a QR code (typically version 5 or 6, error correction level M). Phase 2 (Integration) of ZATCA's mandate requires fields 6–9 — the cryptographic stamp — which makes the QR code self-verifying: anyone can validate the seller's signature against ZATCA's published trust chain.
Other regimes use simpler payloads. India's IRP (Invoice Registration Portal) embeds the IRN (Invoice Reference Number) plus a JWT-signed JSON in the QR; the reader posts the JWT to the GST portal for verification. Spain's TicketBAI (Basque Country) uses a TBAI URL containing the invoice ID and a hash. Portugal's QR is a simple A:[NIF];B:[NIF];C:[country];... ATCUD-anchored payload signed with the certified billing software's private key.
In the EU specifically
The EU has no horizontal QR code requirement. ViDA's Digital Reporting Requirements focus on per-transaction structured data sent to a national platform, not on print-format barcodes. Country-level pictures:
QrCode element exists in the FatturaPA schema and is used by some retailers for e-receipts (corrispettivi telematici) but not by typical B2B invoicing.Outside Europe, ZATCA (Saudi Arabia), India, the UAE, Egypt, and most of Latin America (CFDI in Mexico, DTE in Chile, CFE in Uruguay) require QR codes — usually on the human-readable representation of an otherwise structured XML invoice.
Why ERP vendors care
If an ERP serves customers in any of the QR-mandatory countries, the billing module needs to: (1) compute the country-specific payload at invoice creation time; (2) sign it with the correct cryptographic primitive (ECDSA-P256 for Saudi Arabia, RSA for some others); (3) render the QR onto the printable PDF in the right position and size (Saudi Arabia: minimum 2 cm x 2 cm); and (4) keep the signing key in a regulator-approved keystore (HSM, secure enclave, or the regulator's own SDK).
A frequent integration mistake is encoding the QR from data that diverges from the XML actually submitted to the tax authority — a refund, a discount, or a rounding rule applied late causes the QR's hash to mismatch the submitted document. Tax authorities verify both, so the rule is: produce the XML first, hash it, then build the QR from that hash, never the other way around.
Relation to digital signatures
The QR code and the document-level digital signature solve overlapping but distinct problems. The signature proves the issuer signed the full structured document; the QR provides a portable, human-scannable verification of a small canonical subset. In Saudi Arabia, India, and Portugal, the QR's payload is itself signed — it is, in effect, a tiny detached signature optimised for offline scanning.