Structured Addresses in QR-Bills: The 2025 Change You Need to Know

In late November 2025, the Swiss QR-bill standard moved to version 2.3, and one change affects almost every invoice issuer: structured addresses are now mandatory.

Structured vs. combined addresses

A structured address (type S) is split into separate fields: name, street, house number, postcode, city, and country. A combined address (type K) sits in fewer free-text lines, such as "Musterstrasse 12, 8000 Zürich" in one field.

The difference is easier to see than to explain:

• Structured (type S) — the address is split into separate fields: name, street, house number, postcode, city, country.
• Combined (type K) — the address sits in fewer free-text lines, e.g. "Musterstrasse 12, 8000 Zürich" in one field.

Before v2.3, type K was tolerated for convenience. As of 21–22 November 2025, only structured addresses are permitted in the QR code.

The trap is that an old template can still print a readable address while the underlying data no longer scans. The printed result is not enough — the data has to be structured too.

What also changed

Version 2.3 introduced an extended character set, so umlauts, accents, and other special characters are handled more reliably in names and addresses.

For a multilingual country like Switzerland, this is a real improvement. Addresses in German, French, Italian, and Romansh can now be encoded without being mangled or replaced.

The change reduces the chance of a payment being rejected because of a special character in a street or company name. Fewer rejected orders means fewer manual corrections.

In practice, though, the character-set fix only helps if your invoicing software supports it. Older tools that still emit the old encoding can still produce faulty QR codes.

Why it matters now

There is a transition period, but it is ending. As of 30 September 2026, banks are expected to reject payment orders with non-compliant addresses.

Invoices that scan unreliably mean manual corrections, delayed payments, and frustrated customers. Every rejected order is a cost you could have avoided.

The risk is not theoretical — many issuers still store customer addresses in combined form from CRM exports, CSV imports, and Excel lists. Those records are exactly the ones that will fail.

Fixing this now, while you still have time, is far cheaper than dealing with a wave of rejected payments after the deadline. The deadline is firm, and the consequences are on you.

How to make sure you comply

Compliance comes down to three habits: split every address, check imported data, and use software that generates structured QR data.

1. Split every address into street, house number, postcode, city, and country in your customer records.
2. Check imported data — CRM exports, CSV imports, and Excel lists often keep combined addresses.
3. Watch for edge cases — PO box addresses, missing house numbers, and merged street fields.
4. Use invoicing software that generates compliant QR data — the machine-readable data must be structured, not just the printed layout.

Start by splitting every customer address into street, house number, postcode, city, and country in your records. Do it once, properly, and the problem stays solved.

Then audit the data you import. CRM exports, CSV imports, and Excel lists are the most common places combined addresses hide, so check them before they reach an invoice.

Watch for edge cases such as PO box addresses, missing house numbers, and merged street fields. And remember: the machine-readable data must be structured — not just the printed layout.