Swiss QR-bill changes in November 2025
explained

QR-bill 2025 changes explained: what actually changes in November 2025 (and what doesn’t)

If you issue invoices in Switzerland—whether as a freelancer, sole proprietor, or SME—late November 2025 brings an important QR-bill update that can affect whether your customers’ payments go through smoothly.

The biggest change is not “everyone must switch to QR‑IBAN.”
The real change is simpler and more operational:

• QR-bill standard v2.3 requires structured addresses (type S) in the QR code
• Unstructured/combined addresses (type K) are no longer allowed
• The QR-bill also supports an extended character set (useful for umlauts, accents, and more)

This guide breaks down the changes, who’s impacted, and what you should do now to avoid rejected or manual payments later—using official guidance from SIX (the standard owner) and Swiss bank guidance (e.g., UBS).
Sources: SIX QR-bill standard page, UBS structured address guidance, PostFinance address changes context.

• https://www.six-group.com/en/products-services/banking-services/payment-standardization/standards/qr-bill.html
• https://www.ubs.com/ch/en/services/payments/connection-ubs/iso-20022/structured-addresses.html
• https://www.postfinance.ch/de/unternehmen/wissen/news/adressen-anpassungen.html

At a glance: the QR-bill v2.3 change you must care about

Effective date: around 21–22 November 2025
You’ll see both dates referenced across the ecosystem. In practice, treat it as: be compliant by 21 November 2025 to be safe (many banks communicate 21 Nov; SIX often references 22 Nov as the “since” date for the standard update).
Sources: SIX + UBS pages linked above.

What changes (QR-bill only):

• Only structured addresses (type S) are permitted in the Swiss QR code
• Combined/unstructured addresses (type K) are removed
• Extended character set support is introduced

What does not change:

• You generally do not need to switch to QR‑IBAN
• “Normal” IBAN remains valid for QR-bills (depending on reference type)
• The QR-bill layout your customers see still looks familiar; the key change is inside the QR code data

Why it matters:

• If your invoices or templates still generate type K addresses, payments may be rejected or require manual correction, which slows down cash collection.

What changed in the Swiss QR-bill standard in November 2025 (v2.3)

SIX introduced QR-bill standard v2.3 as the operative version in late November 2025. The two practical deltas most businesses notice are:

1) Structured addresses become mandatory (type S only)

Before v2.3, QR-bills could include either:

• Structured address (type S), or
• Combined/unstructured address (type K)

From late November 2025 onward, the QR-bill standard requires structured addresses only (type S).
Source: SIX QR-bill standard page.

This applies to the QR code payload (the machine-readable data). Even if the printed invoice looks fine, the underlying address fields must be structured correctly.

2) The QR-bill supports an extended character set

The standard also introduces an extended character set. Practically, this is relevant if you invoice customers with names/addresses containing:

• umlauts (ä, ö, ü)
• accents (é, è, à, ç)
• other special characters used in CH multilingual contexts

Source: SIX QR-bill standard page.

Important nuance: extended character set support doesn’t mean “anything goes.” Your invoicing tool still needs to generate QR data exactly to spec. If you’re unsure, validation (see checklist below) is the safest approach.

What did NOT change: IBAN vs QR‑IBAN (and the myth that everyone must switch)

A common rumor is: “After November 2025, only QR‑IBANs will work.” That’s not accurate.

IBAN vs QR‑IBAN in one minute

• IBAN (standard IBAN): the normal Swiss/European account identifier used for payments.
• QR‑IBAN: a special IBAN used specifically with a QR reference (QRR). It exists to support the QR reference logic.

Whether you need a QR‑IBAN depends on the reference type you use on your QR-bill:

• QRR (QR reference): typically requires QR‑IBAN
• SCOR (Creditor Reference / ISO 11649): uses a standard IBAN
• NON (no reference): uses a standard IBAN

So for many freelancers and small service businesses issuing straightforward invoices, a standard IBAN remains perfectly fine—especially if you use SCOR or NON.

If you’re not sure what you use today, check your QR-bill settings in your invoicing tool or ask your bank/accountant.

Structured vs unstructured address (type S vs type K): the difference that matters now

This is the core operational change.

Definitions (simple and practical)

Structured address (type S) means the address is split into distinct fields, typically:

• Name
• Street name
• House number
• Postal code
• City
• Country

Combined/unstructured address (type K) means the address is stored in fewer lines, often like:

• “Example GmbH”
• “Musterstrasse 12”
• “8000 Zürich”

Historically, type K was tolerated for convenience. From v2.3 onward, it’s no longer allowed in the QR-bill QR code.

“Before vs After” example table

Below is a practical illustration of how you should store and output addresses now.

Common pitfall: Having “Street + house number” in a single field inside the QR code data is exactly what v2.3 aims to prevent.

Why the change?

Structured addresses improve automation and reduce payment friction across banks, QR scanners, and downstream processing (including broader ISO 20022 alignment). Swiss banks are also pushing address structuring across payment types, not only QR-bills.
Context source: UBS + PostFinance pages linked above.

Who is impacted (and what you need to change) by tool type

The required change is small conceptually—but the work varies a lot depending on how you generate QR-bills.

If you use a modern Swiss invoicing app (best case)

Most cloud invoicing apps and up-to-date accounting tools will:

• update their QR-bill generator to v2.3
• map your address book into structured fields
• validate output automatically

What you should still do:

• Confirm your app explicitly supports QR-bill standard 2.3
• Audit your saved customer addresses for clean separation (street vs number)
• Re-check recurring invoices (see below)

If you use Word/Excel templates or “manual QR code generators” (higher risk)

If you create invoices in Word/Excel and paste in:

• a QR code generated by a website, or
• a QR-bill PDF generated via a basic tool, or
• an old template that stores addresses in a couple of free-text lines

…you’re at higher risk of producing a type K address in the QR code.

What you need to change:

• Switch to a QR-bill generator that supports structured address fields
• Update your customer data format (split street and house number)
• Validate the QR code output before sending invoices

If you run an ERP, custom invoicing system, or QR library integration (implementation risk)

If you generate QR-bills programmatically (ERP, custom code, or an older library), you must ensure:

• the generator supports standard v2.3
• the QR payload is written with address type S
• your address database supports separate fields
• your validation tests cover real edge cases (multi-word street names, house number suffixes, company names with punctuation, etc.)

Implementation notes from enterprise ecosystems exist (e.g., SAP guidance), but the universal rule is: update the QR-bill library/version and test with real invoices.
Source example: SAP support note indicates updates required for structured address changes.

What about recurring invoices, rent, leasing, and saved templates?

This is where many businesses get surprised.

Even if you update your software, you may still have:

• saved invoice drafts
• recurring invoice rules
• customer templates
• payment requests created long ago
• standing orders based on older invoice data

Banks explicitly warn that saved templates and standing orders may need updating so that address data is compliant going forward.
Source: UBS structured address guidance.

Practical takeaway: Treat recurring billing and saved templates as a separate project: review, update, and re-issue where needed.

Will payments fail if you do nothing?

What happens depends on:

• whether your QR-bill QR code contains type K (unstructured) addresses
• how strictly the receiving bank/payment channel enforces the new standard
• transitional practices in the market

But from a business perspective, the risk is real:

• Delayed payments (manual intervention)
• Rejected payments (customer has to retry)
• Support overhead (“your invoice doesn’t scan / doesn’t work”)
• Cash flow impact—especially for freelancers and small businesses

The cheapest fix is usually: update the generator + clean address data + validate.

The freelancer/SME checklist: become QR-bill-ready for late November 2025

Use this checklist to get confident quickly—without overengineering.

1) Confirm your QR-bill generator supports v2.3

Ask your provider (or check release notes) for explicit statements like:

• “QR-bill standard 2.3 supported”
• “structured addresses type S”
• “extended character set”

If you’re relying on a bank portal tool, check your bank’s guidance.

2) Audit your creditor address (your business address)

Make sure your own address is stored as:

• Street name (text only)
• House number (number + suffix if needed)
• Postal code
• City
• Country (CH or appropriate country code)

3) Audit your customer master data (top 20 first)

Start with the customers who pay you most often.

Look for these red flags:

• “Street 12” stored in one field with no separation
• P.O. box mixed into street field
• Missing country for cross-border customers
• Copy/pasted multi-line addresses that don’t map cleanly

4) Fix recurring invoices and templates

• Edit recurring invoice rules and ensure they regenerate QR parts using the updated standard
• Replace saved invoice PDFs or legacy QR images where applicable
• If you provide rent/lease invoices, validate those flows early (they’re often long-lived)

5) Validate your QR-bill output before you send

Before you email or print invoices at scale:

• generate a test QR-bill
• scan it with multiple apps (banking app + generic scanner)
• ensure the payment flow completes cleanly and the address is accepted

If your software offers a built-in validator or audit tool, use it.

6) Decide how you’ll handle special characters

If you invoice in multilingual contexts (DE/FR/IT/EN), test names with:

• umlauts/accents
• apostrophes and hyphens
• long company names

If you see scanning issues, don’t guess—validate and adjust according to your tool’s QR-bill settings.

FAQ: Swiss QR-bill changes (November 2025)

Do I need to switch to a QR‑IBAN because of the 2025 QR-bill change?

Not necessarily. The QR-bill update is mainly about structured addresses and the character set.
Whether you use IBAN or QR‑IBAN depends on your reference type (QRR vs SCOR vs NON)—not on the address rule itself.

What exactly is “structured address mandatory” (QR-bill address type S)?

It means the QR code data must contain the address split into separate fields (street, house number, postal code, city, country). The older “combined/unstructured” format (type K) is no longer allowed in QR-bill v2.3.
Source: SIX QR-bill standard page.

What happens if my QR-bill still uses an unstructured address (type K) after 21/22 Nov 2025?

You risk payment friction: rejection, manual processing, or customers reporting that scanning doesn’t work as expected. Banks advise updating tools and templates ahead of the deadline.
Source: UBS guidance.

Is this the same as the “structured address for all payments by 2026” change?

No. The QR-bill v2.3 change is effective in late November 2025 for QR-bills.
Separately, Switzerland’s broader ISO 20022 payments ecosystem is moving toward structured/hybrid address requirements by November 2026. People often mix these up.
Context source: PostFinance address changes page.

Do I need to include my customer’s address in the QR code?

Often, the crucial address is the creditor (invoice issuer) address. Debtor (payer) address handling can vary by setup and isn’t always required in the same way. If your tool includes it, ensure it’s structured as well and validated.

Can I use umlauts (ä, ö, ü) and accents (é, è) now?

QR-bill v2.3 supports an extended character set. In practice, your software must implement it correctly—so test and validate.
Source: SIX QR-bill standard page.

I invoice international clients—does anything change?

You still need to generate QR-bills compliant with Swiss QR-bill rules if you use QR-bills. Ensure country codes and structured fields are correct. If international clients struggle with QR-bill scanning, consider offering alternate payment options alongside the QR-bill.

Mini glossary (for Swiss searchers in multiple languages)

You may see these terms across bank pages and documentation:

• Structured address = strukturierte Adresse (DE) = adresse structurée (FR)
• QR-bill = QR-Rechnung (DE) = QR-facture (FR)
• Mandatory structured address = strukturierte Adresse Pflicht (DE) = adresse structurée obligatoire (FR)
• QR-bill standard 2.3 = QR-Rechnung Standard 2.3 / standard QR-facture 2.3
  Useful queries: “QR-bill November 2025 changes”, “QR-Rechnung Änderungen 2025”, “changements QR-facture novembre 2025”.

The fastest way to avoid payment problems: run a QR-bill compliance check now

If you only do three things, do these:

1. Verify your tool supports QR-bill standard v2.3
2. Clean up addresses into structured fields (type S)
3. Validate a real invoice QR code before late Nov 2025

That’s it—no panic, no unnecessary bank account changes.