What "invoice QR code" actually means in 2026
You searched for invoice QR because a customer asked why your invoice does not have one, a finance lead pushed back on manual reconciliation costs, or an accounting system flagged a Swiss QR-Bill it could not parse. Here is the framing most posts skip.
An invoice QR is not a marketing flourish. It is a structured-data envelope, defined by a banking standard, that lets the payer's bank app pre-fill a payment without transcription. The QR itself is an ordinary ISO/IEC 18004 symbol; the standard lives in the data convention inside it.
Three real standards dominate. The EPC QR Code, published by the European Payments Council, encodes a SEPA Credit Transfer for any euro-zone payment. The Swiss QR-Bill, governed by SIX Group and the Swiss Payments Standard, is the mandatory format for Swiss franc invoicing since September 30, 2022. UPI QR, regulated by India's National Payments Corporation, encodes a payment intent that resolves through the UPI rails.
Outside those three zones — the United States, most of Latin America, most of Asia outside India, Australia — there is no analogous standard, and "invoice QR" almost always means a QR pointing at a hosted payment page. A Stripe Invoice link. A PayPal payment URL. A QuickBooks Pay invoice. Useful for one-tap pay, but structurally different from the EPC and Swiss formats. The customer's bank app cannot pre-fill anything; it just opens a browser.
The distinction matters because accounting reconciliation depends on it. The EPC and Swiss formats carry a structured creditor reference that flows through the bank rails to your bank feed, where DATEV, Sage, Xero, or QuickBooks match it back to the open invoice automatically. The Stripe payment link reconciles through Stripe's webhook into your accounting tool, separately. Both work. They are not the same thing.
This post is the engineering reference for what an invoice QR really encodes, when each standard wins, and what the published reconciliation savings actually are. For the sibling structured-data pillar, see the GS1 QR breakdown.
The three real standards — and the one common workaround
Four patterns cover essentially every invoice QR in the wild. The first three are real banking standards. The fourth is a payment link with a QR around it.
EPC QR Code — SEPA Credit Transfer (Europe). Defined by the European Payments Council in document EPC069-12. Encodes a SEPA Credit Transfer: beneficiary name, IBAN, amount in euros, structured creditor reference (ISO 11649 RF or free-text remittance), optional purpose. The payer scans with their bank app — Sparkasse, ING, BBVA, ABN AMRO, Bunq, N26 all support it — and the transfer is pre-filled. No manual IBAN entry, no transcription errors.
Swiss QR-Bill. Defined by SIX Group's Swiss Payments Standard. Mandatory since September 30, 2022, replacing the red ESR and orange ES slips that had circulated since the 1970s. Carries IBAN or QR-IBAN, creditor and debtor address, amount in CHF or EUR, structured reference (QRR 27-digit or SCOR ISO 11649), unstructured additional info. Printed on a perforated payment slip at the bottom of the invoice in a defined A4 layout. DACH accounting software reads it natively.
UPI QR — India. Defined by NPCI. A URI scheme: upi://pay?pa=<vpa>&pn=<name>&am=<amount>&tn=<invoice ref>&cu=INR. The payer scans with any UPI app (GPay, PhonePe, Paytm, BHIM) and the payment is pre-filled. Reconciliation runs through the NPCI rails; the merchant's bank statement carries the UPI transaction reference and the tn field that typically holds the invoice number.
B2B payment-link QR — the workaround. A QR pointing at a hosted payment URL: Stripe Invoice (https://invoice.stripe.com/...), PayPal (https://www.paypal.com/invoice/p/...), QuickBooks Pay, Square. Customer scans, opens the payment page in a browser, pays by card or ACH. Reconciliation happens through the payment processor's webhook, not the QR itself. Common in the US, UK for non-SEPA invoices, Canada, Australia, and most of Asia outside India.
A single business invoicing across regions ends up running multiple of these in parallel. A German SaaS company billing a Swiss customer prints a Swiss QR-Bill, a French customer gets an EPC QR, an Indian reseller gets UPI, a US enterprise gets a Stripe link with a QR. The QR generator does not unify them; the accounting system does. See the payment use case page for the broader payment-channel framing.
| Standard | Region | Defined by | Key fields | Auto-reconciles in accounting |
|---|---|---|---|---|
| EPC QR Code | SEPA (EU, EEA, Switzerland for euro) | European Payments Council (EPC069-12) | BIC, Beneficiary, IBAN, Amount, Reference, Purpose | Yes via bank feed + structured reference |
| Swiss QR-Bill | Switzerland (CHF and EUR) | SIX Group / Swiss Payments Standard | IBAN or QR-IBAN, Creditor address, Debtor, Amount, QRR or SCOR reference | Yes — DATEV, Abacus, Sage, Bexio read it natively |
| UPI QR (invoice) | India | NPCI | `pa` (VPA), `pn`, `am`, `tn` (note), `cu` | Partially — via UPI transaction reference on bank statement |
| Payment-link QR (Stripe / PayPal / QuickBooks) | Global fallback | No banking standard — vendor URL | URL only; data lives at the hosted page | Via processor webhook, not via the QR |
EPC QR Code — field-by-field structure
The EPC QR Code is the most underappreciated banking standard in Europe. It encodes a complete SEPA Credit Transfer instruction in a known line-delimited format. The customer's bank app reads it, pre-fills the payment, and the customer confirms. No IBAN copy-paste, no reference number transcription, no fat-finger errors landing the payment in the wrong account.
The format is line-delimited. Each field is one line, ended by a line feed. The order is fixed. Missing fields are blank lines, not omitted. A bank app reading an EPC QR with a missing field for an earlier line cannot recover.
A concrete example for a 1,234.56 EUR invoice to a Berlin agency:
```
BCD
002
1
SCT
DEUTDEDB110
Musterfirma GmbH
DE89370400440532013000
EUR1234.56
GDSV
RF18539007547034
Rechnung 2026-0417
```
The fields in order:
1. Service Tag — always BCD. Identifies the payload as an EPC QR.
2. Version — 001 or 002. Version 002 is current.
3. Character Set — 1 for UTF-8 (the practical default).
4. Identification — SCT for SEPA Credit Transfer.
5. BIC of the beneficiary bank — 8 or 11 characters. Optional under version 002 for EEA payments where IBAN alone suffices.
6. Beneficiary name — up to 70 characters.
7. Beneficiary IBAN — up to 34 characters, no spaces.
8. Amount — currency code followed by the value with a dot decimal separator, e.g. EUR1234.56. Range 0.01 to 999999999.99.
9. Purpose — optional 4-character ISO 20022 purpose code (e.g. GDSV for goods and services).
10. Structured creditor reference — ISO 11649 RF reference, or blank if using unstructured remittance.
11. Unstructured remittance information — up to 140 characters. Use field 10 or 11, not both.
12. Beneficiary-to-beneficiary information — optional, up to 70 characters. Rarely used.
The payload is capped at 331 bytes including line feeds. Error correction level M is the EPC recommendation; level Q for invoices that may be photocopied. See the QR best practices guide for ECC tradeoffs.
The field that drives reconciliation is the structured reference. The ISO 11649 RF reference (RF + two check digits + up to 21 alphanumeric characters derived from the invoice number) passes through the creditor's bank statement intact, and DATEV, Sage, Xero, or QuickBooks match it to the open invoice automatically. Without a structured reference, the bank feed shows free-text remittance that requires fuzzy matching at best.
Swiss QR-Bill — what changed on September 30, 2022
The Swiss QR-Bill is the most consequential Swiss payment-standard change in 50 years. On September 30, 2022, the legacy red ESR (Einzahlungsschein mit Referenznummer) and orange ES (Einzahlungsschein) payment slips became invalid. Banks stopped processing them. Every business invoicing in Swiss francs had to switch.
What a QR-Bill is. A standardized perforated payment slip at the bottom of an A4 invoice, with a QR code in a defined position. The QR carries the structured payment data; the perforated slip carries the human-readable version. The customer can pay by scanning with a banking app (UBS, PostFinance, ZKB, Raiffeisen, Migros Bank all support it), entering the IBAN and reference manually, or mailing the perforated slip to PostFinance.
What the QR encodes. Header (SPC service tag, version 0200, coding 1), creditor IBAN or QR-IBAN (the QR-IBAN is a special IID-range IBAN reserved for structured-reference payments), creditor address, amount and currency (CHF or EUR), debtor address (optional but recommended), reference type (QRR, SCOR, or NON), the reference value, unstructured additional info, the trailer (EPD), and optional structured bill information (SwicoString) for VAT and discount terms.
The reconciliation payoff. SIX Group's published estimate is that the QR-Bill cuts manual data entry by 60-80% in Swiss accounting workflows. The QRR reference flows through the bank rails into the camt.054 ISO 20022 credit notification, where DATEV, Abacus, Bexio, Sage, Topal, and Pebe read it and match the payment to the open invoice without human intervention.
The print spec is strict. The payment part lives in a fixed 105 × 148 mm area at the bottom of the A4 page. The QR sits in a 46 × 46 mm box with the Swiss cross overlaid. Perforation between receipt and payment parts is recommended. PDF generation has to match the spec or the slip is non-compliant. Most Swiss accounting tools (Bexio, Abacus, Sage 50, Topal) generate compliant QR-Bills as a built-in feature; standalone QR generators do not.
The practical takeaway: the QR is one element of a layout-regulated slip. EZQR and every URL-QR generator can emit a QR pattern, but the surrounding slip — perforation, Swiss cross, fixed-position fields, human-readable backup — belongs in the accounting tool. For PDF QR codes embedded in non-Swiss invoices, EZQR works fine.
UPI QR for invoices — India
UPI (Unified Payments Interface) is India's instant payment rail, operated by NPCI. UPI QR for invoicing is widespread because every adult Indian with a smartphone has a UPI app (GPay, PhonePe, Paytm, BHIM, or the bank's own).
The URI format. A UPI invoice QR encodes a string like upi://pay?pa=acme@hdfcbank&pn=Acme%20Pvt%20Ltd&am=15000.00&tn=INV-2026-0417&cu=INR. Fields:
pa— Payee Address (Virtual Payment Address), e.g.acme@hdfcbank. Required.pn— Payee Name, URL-encoded. Required.am— Amount in INR, decimal. Optional; blank means the payer enters it.tn— Transaction Note, up to 80 characters. The conventional carrier for the invoice reference.cu— Currency. AlwaysINRfor domestic UPI.mc— Merchant Category Code (optional, ISO 18245).tr— Transaction Reference (optional, used by merchant aggregators).
The payer scans, the payment screen pre-fills, the payer confirms, and the funds settle in seconds through the NPCI switch.
Where the reconciliation lives. UPI does not carry a structured creditor reference the way EPC and Swiss formats do. The merchant's bank statement (or aggregator dashboard — Razorpay, Cashfree, PayU, BillDesk) shows the UPI transaction reference (UTR) and the tn note. Tally, Zoho Books, and QuickBooks India reconcile on tn (the invoice number) plus the amount. The match is more brittle than EPC because tn is free-text — payers can edit it before submitting — but in practice it works for 90%+ of B2B UPI invoice payments.
Static vs dynamic UPI QR. Static QRs encode the VPA only; the payer enters amount and note. Dynamic QRs (per-invoice) encode the full payload including amount and tn. For invoicing, dynamic is correct — the payer cannot fat-finger the amount, and tn carries the invoice reference. Tally, Zoho Books, and most Indian invoicing tools generate dynamic UPI QRs per invoice as a built-in feature.
International invoicing into India. UPI International rolled out from 2023 (Singapore, UAE, Bhutan, Nepal, France for merchant payments, with Mauritius and Sri Lanka added through 2024-2025). For cross-border B2B invoicing above the consumer-merchant threshold, SWIFT or a payment processor (Wise Business, Razorpay International) remains the practical channel.
B2B PDF invoice QR — the Stripe, PayPal, and QuickBooks pattern
Outside the EPC, Swiss, and UPI zones, the practical invoice QR is a payment-link QR — a QR on the PDF pointing at a hosted payment page. This is the dominant pattern in the United States, the United Kingdom for non-SEPA invoices, Canada, Australia, and most of Latin America and Asia outside India.
The flavors. Stripe Invoice links (https://invoice.stripe.com/...) lead in SaaS billing. PayPal invoice links work for legacy ecommerce and freelancer billing. QuickBooks Pay links integrate with QuickBooks Online. Square serves small-business retail and services. Wave, Zoho Invoice, and FreshBooks have analogous flows. Each emits a unique URL per invoice; a QR pointing at that URL is the path of least resistance.
Why this is not the same as EPC or Swiss QR-Bill. The QR carries a URL, nothing else. The customer's banking app cannot pre-fill anything — it just opens a browser. There is no structured creditor reference flowing through bank rails. Reconciliation happens through the payment processor's webhook (Stripe's invoice.paid, PayPal's IPN, QuickBooks' webhook) into your accounting tool. Both EPC/Swiss and payment-link QRs reconcile, through different channels.
When the payment-link QR is right. US B2B invoicing. UK invoicing for customers paying by card or USD ACH. Australian and New Zealand domestic invoicing. Cross-border B2B where the payer is unlikely to use a SEPA bank app. Any case where you already run Stripe Billing, PayPal, or QuickBooks and just need a scannable surface on the PDF.
When it is not. A German customer paying a euro invoice. A Swiss customer paying CHF. An Indian B2B customer paying via UPI. In all three, the bank-native standard is structurally better — the customer's bank app pre-fills the payment, no browser detour, and bank-rail reconciliation is automatic.
The generator workflow is simple: the accounting tool generates the payment URL, EZQR wraps it in a QR. For high-volume invoice runs, template the QR generation into the PDF emission pipeline. For PDF QR codes at scale, the PDF type page covers the workflow. The honest framing: payment-link QR on a US B2B invoice is a usability upgrade, not a structured-data envelope.
Accounting software integration — what auto-reconciles
The QR on the invoice is half the story. The other half is the accounting integration that closes the loop from payment to paid-invoice status. Region matters a lot.
DATEV (DACH region). DATEV reads camt.054 ISO 20022 credit notifications from German, Austrian, and Swiss banks. EPC QR payments carrying an ISO 11649 RF reference flow through to DATEV automatically and match against open receivables (Offene Posten). Swiss QR-Bill payments using the QRR reference do the same in DATEV's Swiss module. The reconciliation is genuinely hands-off for invoices where the payer scans the QR — no fuzzy matching, no manual posting.
Sage (UK, DACH, France). Sage 50 and Sage 200 in the UK read CSV bank feeds and bank-API integrations from Lloyds, HSBC, Barclays, Natwest. EPC QR payments with structured references match against open invoices. Sage's Swiss QR-Bill support is built into Sage 50 Switzerland.
Xero (global). Xero auto-reconciles bank feeds via the Plaid, Yodlee, or direct-bank-API channels. EPC QR payments with structured references match against open Xero invoices. For Stripe and PayPal payment-link QRs, Xero's native Stripe and PayPal connectors fire on the webhook and mark the invoice paid in Xero automatically. Xero is the cleanest cross-region story because both standards (EPC + payment-link) reconcile to the same Xero invoice record.
QuickBooks Online (US + global). QuickBooks Online auto-reconciles Stripe, PayPal, QuickBooks Pay, and Square payment-link QRs via the native payment processor connectors. For EPC QR (rare in QuickBooks territory), the bank feed match has to be set up manually — QuickBooks does not parse structured references natively the way DATEV does. For US B2B, the QuickBooks Pay link QR is the cleanest pattern.
Bexio, Abacus, Topal (Swiss-native). All three read Swiss QR-Bill payments via the camt.054 feed and reconcile automatically. They are also the cleanest generators of compliant QR-Bills for invoicing. For a Swiss business, the QR-Bill stack is end-to-end inside one tool.
Tally, Zoho Books, QuickBooks India. All three support UPI QR generation per invoice and bank-feed reconciliation against the UPI tn reference. The match is on amount + invoice number; reliability is high but not as bulletproof as EPC structured-reference matching.
For more on the broader small-business accounting use case, see the use-case page.
Tips
- Confirm your accounting tool reads the camt.054 ISO 20022 credit notification from your bank — this is the channel that carries structured creditor references back to your books.
- For EPC QR, always use the ISO 11649 RF reference, not free-text remittance. Free text gets fuzzy-matched at best and unmatched at worst.
- For Swiss QR-Bill, use a QR-IBAN with QRR references for the cleanest reconciliation, or a regular IBAN with SCOR references if QR-IBAN is not available from your bank.
- For US/UK/AU B2B, plug Stripe, PayPal, or QuickBooks Pay into your accounting tool first, then add the QR. The webhook is what closes the reconciliation loop.
- Test the full loop on one invoice before rolling out: issue invoice, scan QR, pay, watch for the auto-match in your accounting tool. Surprises at scale are expensive.
- For multi-region businesses, accept that you will run two or three QR patterns in parallel. The accounting system unifies them; the QR generator does not.
Printing and PDF embedding — what actually works
Invoice QRs print on three surfaces: paper invoices mailed to customers, PDF invoices emailed and possibly printed, and online invoice views in a customer portal.
Paper A4 invoices. The QR should be at least 20 × 20 mm for reliable smartphone decode at reading distance (30 cm). The Swiss QR-Bill spec mandates exactly 46 × 46 mm on the perforated slip, with the Swiss cross overlaid. For EPC QR on a generic invoice, 25 × 25 mm with a 4-module quiet zone is the practical minimum. Print at 600 dpi on coated stock; thermal desk-printer output survives one scan but degrades.
PDF invoices. Embed the QR as vector (SVG) or high-resolution PNG (300+ dpi at print size). A QR that looks fine on screen at 100% may be unscannable when the recipient prints — verify by printing and scanning. Generate the QR at the final print dimensions plus a safety multiplier.
Online invoice views. The QR on a Stripe Invoice or QuickBooks customer portal page is mostly redundant — the customer can click Pay. The QR matters when the customer prints the PDF and scans from another device, or finance teams forward printed invoices between offices. Include it; it costs nothing.
Error correction. Level M (15%) is the EPC default. Level Q (25%) for invoices likely to be photocopied. Level H (30%) only when a logo is embedded — necessary for the Swiss cross on the QR-Bill, otherwise it sacrifices data density.
Contrast and color. Dark-on-light at 4.5:1 minimum. Black-on-white is the safe default. Pastel and pale-blue invoice QRs fail in field testing. The Swiss QR-Bill spec requires black-on-white.
Quiet zone. Four modules of clear space on all sides. Invoice templates that crowd the QR with adjacent text break decode reliability. The Swiss QR-Bill's defined position eliminates this problem; EPC QR on a generic template needs layout discipline.
For print-vs-screen tradeoffs, see the QR best practices guide, and the permanent QR code generator breakdown for the vendor-survival side.
Common mistakes — when "invoice QR" is not actually an invoice QR
Five patterns turn the invoice QR project into a sunk cost.
A URL-shortened PayPal link on a German invoice, called an invoice QR. The Sparkasse banking app does not recognize the URL. It opens a browser. The customer abandons. Reconciliation happens through PayPal's webhook, not the bank rails, which the finance team did not plan for. The right answer for a euro invoice to a German customer is an EPC QR. The PayPal QR is fine for a US customer paying the same invoice.
An EPC QR with no structured reference. The customer scans, the bank pre-fills the payment, the payment lands. The bank statement shows free-text remittance saying "Rechnung Acme 2026-0417" or whatever the payer typed. DATEV cannot auto-match it. The accountant matches by hand. The reconciliation savings the standard exists to provide were thrown away. Always emit the ISO 11649 RF reference.
Swiss QR-Bills with a non-compliant layout. The QR pattern is correct, but the surrounding slip is missing perforation, the Swiss cross is mispositioned, or the receipt section is mis-sized. Swiss banks accept the payment because the QR data is valid, but the invoice is non-compliant under the Swiss Payments Standard. Use a Swiss-native accounting tool (Bexio, Abacus, Sage 50 Switzerland) for QR-Bills, not a standalone generator with a custom template.
UPI QR for B2B invoices above the per-transaction limit. UPI has a per-transaction cap (currently 5 lakh INR for most categories, higher for specific ones like education and capital markets). A B2B invoice above the cap will not clear via UPI; the customer pays by NEFT or RTGS instead. Confirm category limits before defaulting to UPI for high-value B2B.
Confusing payment-link QR with auto-reconciliation. A Stripe Invoice QR is one-tap pay. It is not auto-reconciliation unless your accounting tool has the Stripe connector firing on the webhook. Most do; some legacy systems do not. The QR alone does nothing — the connector closes the loop. Plan for both.
The sibling structured-data pillar is documented in the GS1 QR breakdown. For ecommerce invoicing flows, see the ecommerce playbook. For freight and delivery-note QRs, the logistics guide covers parallel patterns.
Where EZQR fits — honest positioning
We built EZQR for the URL-QR consumer side. For invoice QR, the lane we serve well is the payment-link QR — Stripe Invoice URLs, PayPal invoice links, QuickBooks Pay URLs, Square invoices, Wave and Zoho links. Generate the URL in your billing tool, paste it into EZQR, get a QR that prints cleanly on PDF invoices and survives the photocopier. Free static QRs cover one-off invoicing; the Lite plan at $5/mo covers monthly billing runs with dynamic codes you can redirect if a payment URL ever needs to change. Pro at $10/mo adds bulk CSV for SaaS companies emitting hundreds of invoices a month; Max at $20/mo handles enterprise-scale invoice runs with API access.
What we do not do: emit EPC QR with structured reference syntax, or generate compliant Swiss QR-Bills with the perforated payment slip layout. Those belong in your accounting system. DATEV, Sage, Bexio, Abacus, Sage 50 Switzerland, and Topal generate them as a built-in feature; cobbling them together from a standalone QR generator is the wrong tool for the job.
For in-between cases — a US-based SaaS billing European customers in euros and wanting to add structured-reference EPC support — the right move is to enable EPC QR output in your invoicing platform (Stripe Billing has added EPC support for SEPA invoices in select regions, Chargebee and Recurly are catching up) or to use a DACH-region invoicing tool that emits both EPC and payment-link QRs from one template.
If the use case is non-EPC, non-Swiss, non-UPI — US B2B with Stripe, UK B2B with Wave, Australian small-business with Xero — EZQR works as the QR generator around the payment URL. Codes survive cancellation indefinitely, which matters because an invoice QR printed on archival paper records should not silently die when the marketing team changes QR vendors. See the permanent QR code generator breakdown for the cancellation-policy comparison.
For the broader payment context, see the payment use case page and the small business use case page. For PDF embedding, the PDF QR type page covers the workflow.
