QR codes for invoices — match the code to the customer's rail

One decision: which rail does your customer pay on

An invoice QR exists to collapse "find the bank details, type them, type the amount, type the reference" into one scan. That only works if the code speaks the payment system your customer's app understands — there is no universal payment QR, so the choice is per customer region:

Customer pays via	Use	Reference field	Details
SEPA (eurozone)	EPC QR	Remittance line (≤ 140 chars)	EPC on an invoice
Switzerland / Liechtenstein	Swiss QR-bill	27-char QR reference	Swiss QR-bill
Brazil	PIX (static, with amount)	txid, 1–25 alphanumeric	PIX format
India	UPI (with amount)	tr, 1–35 chars	UPI format
Singapore (B2B)	PayNow via UEN	Reference field	PayNow
Card-first / international	Payment-link URL	In the link's metadata	Stripe Payment Links

If your customer base spans regions, generate per invoice by customer country — the invoice template knows the billing address, so this is one conditional in your invoicing code, conveniently scriptable against typed API endpoints (/api/v1/epc, /api/v1/upi, and friends — see the keyless API).

The reference discipline

Automatic reconciliation is the actual prize, and it lives or dies on one rule: one invoice, one reference, in the scheme's reference field — not in a free-text note, not appended to the payee name.

• EPC: the invoice number in the unstructured remittance line, or a structured ISO 11649 reference — never both, they are mutually exclusive.
• PIX: the invoice number as txid (letters and digits only, max 25).
• UPI: as tr (max 35 characters of A–Z a–z 0–9 . -).

Generate the code at invoice-creation time with that invoice's amount and reference baked in. A shared "pay us" code without per-invoice references puts you back to guessing which payment was which — fine for a counter, wrong for invoicing.

Placement and print

• Beside the total. The payment block, top-right area or directly next to "Amount due" — where the reader's eye is at the moment of deciding to pay.
• Size: at least 2 × 2 cm for desk-distance scanning; more if the payload is long.
• Always print the identifier as text — IBAN for EPC, VPA for UPI, copia e cola for PIX. Not every app reads every code, and the text line keeps every invoice payable.
• Embed as vector. Invoices are PDFs that get re-printed at unknown quality; SVG survives that, screenshots do not. See adding a QR to a PDF.
• Label it. One line — "Scan with your banking app to pay" — sets expectations, especially for EPC codes that do nothing in a camera app.

What not to put on an invoice

Not a homepage link, not a "please find our bank details" page, and never a shortened or redirecting URL in place of a payment payload — an invoice asks for money, which is exactly the context where a reader should distrust opaque links, and where your accounts-payable recipient's fraud team may reject the whole document. The code should contain the payment itself, verifiable by decoding: run your own invoice code through /validate and check name, amount and reference before the template ships.

FAQ

Which QR code should go on an invoice?

The one your customer's banking app can pay — EPC for SEPA customers, a QR-bill for Swiss ones, PIX in Brazil, UPI in India, PayNow-by-UEN in Singapore, or a hosted payment link for card-first and international customers.

Should the invoice QR include the amount?

Yes, the exact total, plus the invoice number in the scheme's reference field. Prefilled amount and reference are the entire point — they eliminate typing errors and make payments reconcile automatically.

Where should the QR code go on the invoice?

In the payment block beside the total, at least 2 x 2 cm, with the IBAN, VPA or equivalent printed as text next to it and a one-line instruction to scan from a banking app.

Can one QR code work for all my international customers?

No — payment schemes are regional and mutually incompatible. Generate per invoice based on the customer's country, and fall back to a hosted payment link where no shared bank rail exists.