QR codes for invoicing — SEPA, UPI, and bank payment QRs

QR codes for invoicing are a different animal from QR codes for marketing. A payment QR doesn't encode a URL — it encodes a structured string that the customer's bank app parses into a pre-filled transfer. The IBAN, the amount, the reference number, the payee's name. The customer scans, confirms, and the money lands in your account with the right reference for reconciliation. No copy-paste, no typo on the IBAN, no "wait, what's the reference again?" email three days later.

That last bit is the value. Invoice payments fail at the data-entry step more often than people admit. A payment QR removes the entry step. The customer's bank app fills every field from the QR and asks them to confirm. In Europe this runs through the SEPA EPC069-12 specification. In India it runs through UPI's upi://pay scheme. In Brazil it's PIX. In the US there is no universal answer — and that's a problem worth being honest about. This post covers the three standards in detail, the exact strings each one expects, the encoding gotchas (decimal separators, character limits, error correction), and the UX trap that kills more payment QRs than any encoding bug: most customers scan with their camera app, which doesn't open the bank app at all.

What a payment QR code actually contains#

A payment QR encodes structured plain text. Not a URL, not a redirect. The customer's bank app recognises the format, reads the fields, and pre-fills a transfer screen with them. There's no server in the loop — the QR's pixels carry the entire payment instruction.

Three working standards cover most of the world:

• SEPA EPC069-12 — the European one. Published by the European Payments Council, supported by most eurozone bank apps. Encodes a SEPA Credit Transfer.
• UPI (Unified Payments Interface) — the Indian one. The upi://pay URI scheme. NPCI processed over 100 billion UPI transactions in 2023, making it the most-scanned payment QR standard on earth.
• PIX — the Brazilian one. Modelled on UPI, ascendant since 2020, run by the Brazilian central bank.

The common shape: a fixed identifier that tells the bank app what kind of payment this is, then a series of key-value fields for the recipient, amount, currency, and reference. Different alphabets, same idea. The differences are in the syntax. Another sector that lives or dies on structured-payload QR strings is healthcare, where prescription leaflets and equipment-tag QR codes face the same key-value-field discipline minus the bank. Paste a sample SEPA or UPI string into the drop-in QR builder and the syntax differences turn into something you can scan and compare side by side rather than read about.

SEPA EPC069-12 — the European format#

The European Payments Council published EPC069-12 ("Quick Response Code: Guidelines to Enable Data Capture for the Initiation of a SEPA Credit Transfer") in 2013. The format is the de-facto standard for invoice QR codes across the eurozone. Most major bank apps in Germany, Austria, Belgium, the Netherlands, France, Italy, Spain, Finland, and elsewhere parse it. Some — like ING and Revolut — handle it better than others, but coverage is broad.

The encoded string is plain text, UTF-8, separated by line feed (\n) characters. Every field has a fixed position. The complete structure for a version-002 SCT (SEPA Credit Transfer) payment looks like this:

BCD
002
1
SCT
BANKDEFFXXX
Acme Ltd
DE89370400440532013000
EUR125.00
CHAR
INV-2026-04-117
Invoice 117 for May

Line by line:

1. BCD — the service tag. Always literal "BCD" (acronym from the German reference implementation).
2. 002 — the version. 001 requires a BIC, 002 makes BIC optional. Use 002.
3. 1 — the character set. 1 means UTF-8.
4. SCT — the identification code. Always "SCT" for a credit transfer.
5. BIC (optional in v002) — the bank's BIC code. Empty line if you don't include it.
6. Beneficiary name — up to 70 characters. The payee.
7. IBAN — the recipient account, no spaces.
8. Amount — currency code (3 letters) followed by the amount, with . as the decimal separator. Example: EUR125.00. Must be between 0.01 and 999999999.99.
9. Purpose (optional) — a SEPA purpose code (4 characters). Most QRs leave it blank.
10. Reference — either a structured remittance reference (RF-prefixed, ISO 11649) or unstructured text. 35 chars structured, 140 chars unstructured. Use one or the other, not both.
11. Beneficiary-to-beneficiary information (optional) — free-text up to 70 chars.

The whole string must fit within 331 bytes. The QR encoding should be at error correction level M per the spec — banks are okay with M, and bumping to H increases QR density without much real-world benefit since invoice QRs are scanned indoors at close range.

Two encoding gotchas worth knowing:

• Decimal separator is always . even in eurozone countries that use , in their normal numeric formatting. EUR125,00 will silently fail to parse on most bank apps.
• Character set 1 (UTF-8) supports German umlauts and accented characters but some older bank apps in Germany still expect set 2 (ISO 8859-1 Latin-1). If you have a payee name with ä/ö/ü and you're seeing reports of failed scans on legacy apps, downgrade to set 2 and avoid characters outside Latin-1.

UPI — the Indian model#

UPI is the most-scanned payment QR standard in the world. NPCI (National Payments Corporation of India) reports over 100 billion UPI transactions in 2023 — roughly 11 million per hour, every hour. The upi:// URI scheme is what every UPI QR encodes.

The format is a URI query string. Minimum required parameters:

• pa — payee address. The recipient's VPA (Virtual Payment Address), like acme@okhdfcbank or 9876543210@paytm.
• pn — payee name. URL-encoded.

Optional but commonly included:

• am — amount. Decimal, e.g. 125.00. UPI accepts decimal precision down to two places.
• cu — currency. Always INR for UPI domestic. Foreign currency UPI exists but is a separate flow.
• tn — transaction note. Free-text reference. URL-encoded, 50-character limit on most apps.
• tr — transaction reference ID. Used by merchants for reconciliation; up to 35 characters.
• mc — merchant category code. ISO 18245 four-digit code.

A complete merchant-style UPI QR for an invoice:

upi://pay?pa=acme@okhdfcbank&pn=Acme%20Ltd&am=125.00&cu=INR&tn=INV-2026-04-117&tr=20260413117

Spaces in pn and tn must be percent-encoded as %20. Ampersands inside the values must be %26. Most generators get this right; hand-rolled strings often don't.

A working scaffold for that string — VPA, payee name, amount, INR currency, and transaction note in the right places — is what the UPI QR code generator emits, with the percent-encoding handled so the spaces and ampersands don't silently break the parse. Drop it into the QR builder lower down to see the encoded length before you commit to print.

UPI has one operational advantage SEPA doesn't: NPCI runs settlement in real-time, 24/7. The customer scans, confirms, and the seller's bank balance reflects it within seconds. SEPA Instant Credit Transfer offers similar speed in Europe but isn't yet universal across all banks — about 99% of SEPA Instant transactions settle in under 10 seconds per ECB data, but coverage varies and the customer's app needs to be using the Instant rail rather than the slower standard SEPA path.

The United States — the gap nobody mentions#

There is no universal bank-payment QR standard in the United States. Not one that works across banks, not one published by a regulator, not one that's likely soon. ACH (the closest US analogue to SEPA Credit Transfer) has no QR specification. Wire transfers don't either. The Clearing House's RTP (Real-Time Payments) network has no published QR format. Zelle has no public QR spec.

What exists is a patchwork of proprietary formats from peer-to-peer apps:

• Venmo — encodes https://venmo.com/code?user_id=... URLs in QR form. Only works inside the Venmo app or a phone camera that recognises the venmo.com domain. Useless to a customer who pays via Chase or Bank of America directly.
• Cash App — encodes https://cash.app/$cashtag URLs. Same constraint — only useful for Cash App users.
• PayPal — encodes paypal.me/username/amount short links. Slightly better cross-platform because it's a normal web URL, but the customer is taken to PayPal's site, not their bank app. The shape of that URL is exactly what the PayPal QR code generator writes — handle, amount and currency pre-filled into a paypal.me link the camera app opens without complaint.

For a US small business invoicing in dollars, the practical options are: pay with PayPal QR (fees), pay with Venmo/Cash App QR (only works for users of that app), or print the ACH details on the invoice and accept that the customer will type them. There is no QR equivalent of "scan this from inside Chase Mobile and the IBAN auto-fills" because Chase Mobile doesn't support a generalised QR ACH scheme.

EMV's QRCPS (QR Code Payment Specification) does exist and could in theory fill this gap, but US banks have not adopted it for domestic payments. EMV QR is more visible in parts of Asia and Africa than in the US. The path forward is unclear; for now, US small businesses ship invoices with bank details typed in plain text.

A handful of US-based sellers — particularly anyone invoicing internationally or in tech-adjacent industries — skip the bank-rail problem entirely by adding a Bitcoin payment option as a parallel line on the invoice. The BIP-21 URI scheme behind it (bitcoin:<address>?amount=...&label=...) is what every native wallet app reads, and the Bitcoin QR code generator writes that string with address, amount, label, and chain selection — Bitcoin mainnet, Lightning, or one of the L2s — so the customer's wallet pre-fills the same way a bank app would on a SEPA scan. The BIP-21 anatomy walkthrough on Bitcoin QR codes covers what wallets parse and which error-correction level a printed Bitcoin QR actually needs (spoiler: not the marketing default). It's not a replacement for ACH; it's a useful second rail when the customer base spans countries and timezones the US banks can't reach overnight.

PIX in Brazil — the UPI clone that works#

PIX launched in November 2020, run by the Banco Central do Brasil. It copied UPI's pattern almost exactly: instant settlement, structured QR codes, ubiquity inside bank apps, no fees on personal use. Within two years it became the dominant retail payment method in Brazil. Static PIX QRs encode an EMV-format string starting with 00020126... carrying the recipient's PIX key, amount, merchant name, and reference.

If you're building a payment-QR feature for Latin American customers, PIX is the format to support. If you're invoicing across SEPA + UPI + PIX, you're covering a meaningful share of the global retail-payments QR landscape. Add EMV QRCPS for the rest of Asia (Singapore, Thailand, Indonesia all have national QR schemes built on EMV). In these same markets, invoice PDFs often pair a PIX or UPI payment QR with a second QR code that opens a WhatsApp chat — the payment QR for the transfer, the WhatsApp QR for questions and receipts, both scanned from inside the same invoice without an email exchange.

Build a payment QR string#

Pick the standard, fill in the fields, and copy the encoded string into your QR generator. The widget below produces the exact text per spec. Static analysis only — nothing leaves your browser.

The output is the literal string the QR encodes. Drop it into any standard QR generator — set error correction to M for SEPA invoices and L or M for UPI (the payload is short, density isn't a concern, and small invoice QRs scan fine indoors). Don't bump to H unless the QR is going to be exposed to wear or partial occlusion. We covered this trade-off in QR error correction levels — what changes when you go from L to H — for invoice QRs specifically, M is the sweet spot.

The UX gotcha that kills payment QRs#

Most customers scan QR codes with their phone's camera app. The camera app handles a URL by offering to open it in the browser. It handles a vCard by prompting "add to contacts." It handles a SEPA EPC string by — doing nothing useful. The camera doesn't know what to do with structured payment data. iOS Camera shows the raw text in a notification banner; Android Camera does similar.

To actually pay from a SEPA EPC QR, the customer has to scan it from inside their bank's app, using the bank app's "scan to pay" or "scan QR" feature. Same for UPI — scan from Google Pay, PhonePe, Paytm, or the bank's own UPI integration. PIX requires the same in-app scan flow.

The real-world consequence: a payment QR printed on an invoice without a clear instruction is going to fail half the time because the customer scans it with their camera, sees nothing actionable, and gives up. The fix is verbal:

Pay this invoice — open your banking app and scan the QR code from inside it.
SEPA-compatible. Pre-fills payee, amount, and reference automatically.

That sentence printed below the QR, in normal text size, doubles the success rate. Small businesses skip it because it feels obvious; it isn't. We've seen the same UX failure on outdoor codes — the post on QR codes outdoors covers a related case where scan instructions decide whether the code gets used.

Static or dynamic for payment QRs#

Static is the right call for invoice QRs. The IBAN doesn't change. The payee name doesn't change. The only fields that change between invoices are the amount and the reference — which are baked into the printed QR per invoice anyway, because each invoice is a separate document with its own QR. Static is fine because the static-vs-dynamic question doesn't really apply: each invoice's QR is a one-shot artefact for that one payment. The post on static vs dynamic QR codes covers when each kind earns its keep — payment QRs sit firmly on the static side because they encode structured data, not URLs.

The only case for dynamic on payment QRs is if you're printing the QR before knowing the amount (for example, on a saved-payee card that the customer can use repeatedly to pay arbitrary amounts). In that scenario, leave the amount field blank and let the customer enter it on confirmation. Both SEPA and UPI accept QRs without amounts — the customer just types it after scanning.

Including the amount and reference#

Both choices: yes, include both. Here's why.

Including the amount removes a class of customer mistake — typing 12.50 instead of 125.00, or forgetting the cents. Bank apps confirm the amount before sending the transfer, so the customer still has a chance to catch a printed-QR error. UPI accepts decimal precision down to two places; SEPA EPC requires . as the decimal separator regardless of the country's local formatting (eurozone displays often use ,, but the encoded string is always .).

Including the reference number is critical for the seller's reconciliation. Without a reference, you receive a payment from an unfamiliar IBAN with no obvious link to which invoice it's settling. With a reference (INV-2026-04-117 or similar), your accounting software can match it automatically. SEPA supports either:

• Structured remittance reference (ISO 11649 RF-prefixed). Format: RF + two check digits + up to 21 alphanumeric characters. The bank validates the check digits.
• Unstructured reference (free text). Up to 140 characters. Most small-business invoices use this.

UPI's tn (transaction note) is unstructured free text, 50 characters on most apps. PIX has both options too.

Don't omit the reference. The five seconds it adds to the QR-builder workflow saves an hour of "did anyone pay invoice 117?" later.

What not to do#

A handful of common mistakes that show up on small-business invoice QRs:

• Don't encode a generic shortened URL thinking the customer's bank app will handle it. A QR that encodes bit.ly/payme123 is not a payment QR — it's a marketing redirect. The customer's bank app won't recognise it; the camera app will open the link in the browser; the customer will see your domain's landing page and never complete a transfer. Use the structured payment string per the relevant standard.
• Don't mix standards. A QR encoded as a UPI URI won't parse in a SEPA bank app, and vice versa. Pick the standard the customer uses; if you serve customers across regions, generate region-specific QRs and label them.
• Don't forget the decimal. EUR125,00 fails on most parsers because SEPA EPC requires .. Eurozone numeric conventions don't apply here.
• Don't print payment QRs at error correction L on cheap inkjet. Even though the payload is short, light scuffing or fold-line damage can drop modules. Use M as a default; H is overkill for an invoice QR scanned from arm's length.
• Don't skip the verbal instruction. "Scan from inside your bank app" printed below the QR turns a 50% success rate into a 90% one. Most invoices don't include this and quietly suffer.

Security — should I worry about a printed payment QR?#

The honest answer: less than you'd worry about a printed IBAN. The QR encodes the same payment instruction the customer would type by hand, and the bank app shows the parsed values for confirmation before sending. The customer can verify the IBAN, amount, and reference on their phone before the money moves. A scammer would have to substitute the QR with a malicious one (sticker overlay) to misroute payments — and that's the quishing attack covered in the QR security post. For invoice QRs printed on a PDF the customer downloads from your trusted email or portal, the attack surface is essentially the same as IBAN typo — except the QR removes the typo risk.

For QRs printed in physical public locations (display windows, market stalls), tamper-evident lamination is worth the cost. For an emailed invoice, the security model is your email's authenticity.

What we'd ship by default#

For a small business invoicing in the eurozone: SEPA EPC069-12 QR on every invoice PDF, error correction M, structured reference if your accounting software prefers ISO 11649, otherwise unstructured. Print the verbal "scan from inside your bank app" instruction next to it. Test the QR on at least three eurozone bank apps before going live (Revolut, N26, and one local-bank app cover most of the variation). The Linked.Codes QR docs cover the platform-level options that matter for invoice batches — bulk generation, error-correction defaults, and how to host structured payloads without writing your own server.

For India: UPI QR with VPA, payee name, amount, currency INR, and transaction note. Universal coverage across UPI-enabled apps. The business question shifts from "will it scan" to "which app will the customer prefer" — most use Google Pay, PhonePe, or Paytm regardless of which bank issued their account.

For Brazil: PIX EMV QR with a static PIX key. Same pattern as UPI, slightly different syntax.

For the US: print bank details in plain text and accept that the customer will type. There is no working alternative as of 2026. If you specifically serve customers who pay via Venmo / Cash App / PayPal, generate a per-customer link from the relevant app and include it as a clickable URL on the invoice — but not as a "payment QR" in the SEPA/UPI sense, because that infrastructure doesn't exist for US ACH.

The shape of payment QRs around the world is more useful than confusing once you know which standard maps to which region. There's no single global format — and there probably won't be soon, because the underlying payment rails (SEPA / UPI / PIX / ACH) don't share architecture. But within each region, the QR formats are stable, well-documented, and widely supported. Pick the right one for your customer base and the rest is data entry.