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

> Match the invoice QR to the customer's payment rail: an EPC code for SEPA invoices, PIX for Brazil, UPI for India, a Swiss QR-bill in Switzerland, and a payment-link URL elsewhere. Prefill the exact amount and the invoice number as the reference, and place the code beside the total.

Source: https://useqr.app/docs/payments/qr-code-for-invoices · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## 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](/docs/payments/qr-payment-standards-compared), 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](/docs/payments/epc-qr-on-an-invoice) |
| Switzerland / Liechtenstein | Swiss QR-bill | 27-char QR reference | [Swiss QR-bill](/docs/payments/swiss-qr-bill) |
| Brazil | PIX (static, with amount) | `txid`, 1–25 alphanumeric | [PIX format](/docs/payments/pix-qr-code-format) |
| India | UPI (with amount) | `tr`, 1–35 chars | [UPI format](/docs/payments/upi-qr-code-format) |
| Singapore (B2B) | PayNow via UEN | Reference field | [PayNow](/docs/payments/paynow-qr-singapore) |
| Card-first / international | Payment-link URL | In the link's metadata | [Stripe Payment Links](/docs/payments/stripe-payment-link-qr) |

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](/docs/developers/free-qr-code-api-no-key)).

## 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](/docs/payments/pix-qr-for-small-business), 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](/docs/payments/pix-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](/docs/print/why-you-should-print-qr-codes-from-svg), screenshots do
  not. See [adding a QR to a PDF](/docs/how-to/how-to-add-a-qr-code-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](/docs/payments/girocode-explained).

## 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](/docs/security/how-to-check-a-qr-code-before-opening), 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](/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.

## Try it

- https://useqr.app/epc
- https://useqr.app/pix
- https://useqr.app/upi
- https://useqr.app/url