QR-Rechnung mit Adresstyp K und Mailversand über Microsoft 365: Was deine PHP-Anwendung jetzt anpassen muss

Stand dieses Artikels: 6. November 2026. Die Fristen setzen die Banken und Microsoft, und sie haben sich schon mehrmals verschoben. Massgebend ist, was deine Bank und das Admin-Center deines Microsoft-365-Kontos melden.

Was ändert sich bei der QR-Rechnung?

Seit dem 22. November 2025 gelten neue Vorgaben für die QR-Rechnung. Die wichtigste: Im Swiss QR Code ist nur noch die strukturierte Adresse erlaubt, der Adresstyp S. Umgestellt sein musste die Rechnungsstellung laut SIX bis 21. November 2025. Das gilt für beide Adressen auf der Rechnung, deine eigene als Zahlungsempfänger und die deines Kunden unter «Zahlbar durch».

• Adresstyp S (strukturiert): Strasse, Hausnummer, Postleitzahl, Ort und Land stehen je in einem eigenen Feld. Postleitzahl, Ort und Land müssen immer gefüllt sein, das Land als zweistelliger Code wie CH.
• Adresstyp K (kombiniert): Die Adresse steht in zwei freien Zeilen, etwa «Musterstrasse 22» und «8999 Seldwyla». Diese Form ist aus den Implementation Guidelines gestrichen.

Auf dem gedruckten Zahlteil siehst du den Unterschied nicht, der Adresstyp steht nur im QR-Code. Eine Rechnung kann also korrekt aussehen und trotzdem die alte Form enthalten.

Bis wann verarbeiten Banken QR-Rechnungen mit Adresstyp K?

Das ist je Bank verschieden. SIX sieht für Belege mit Adresstyp K nach dem 21. November 2025 nur «eine kurze Übergangsfrist» vor, ohne ein Enddatum für alle Banken. Was die Banken selbst veröffentlichen (Stand 6. November 2026):

Stelle	Was für Adresstyp K gilt
SIX	Nach dem 21. November 2025 nur noch kurz verwendbar. Die Banken müssen bestehende Daueraufträge und Vorlagen bis 13. November 2026 bereinigen.
PostFinance	Die Verarbeitung ist «bis 13. November 2026 gewährleistet». Danach können Finanzinstitute QR-Rechnungen ohne strukturierte Adresse ablehnen.
Zürcher Kantonalbank	Seit dem 21. November 2025 ist die durchgängige Verarbeitung nicht mehr gewährleistet. Solche Rechnungen können beim Zahlen abgewiesen werden, auch am Postschalter.
Luzerner Kantonalbank	Im E-Banking seit 21. November 2025 nicht mehr zuverlässig scanbar, die Angaben lassen sich aber von Hand erfassen. Für Zahlungen aus solchen Rechnungen per Zahlungsdatei galt eine Frist bis 30. September 2026.

Für dich heisst das: Spätestens ab dem 14. November 2026 musst du damit rechnen, dass deine Kunden eine Rechnung mit Adresstyp K nicht mehr einfach einscannen und bezahlen können. Zahlungen kommen später, oder dein Kunde muss nachfragen. Welche Frist die Bank jedes einzelnen Kunden setzt, kannst du nicht wissen. Sicher bist du nur mit Adresstyp S.

Zum selben Termin führt SIX mit dem SIC-Release vom 13. November 2026 die Version 2.4 der Implementation Guidelines ein, gültig ab 14. November 2026. Für Rechnungen in Franken bringt sie laut SIX keine technischen Anpassungen.

Was muss deine Anwendung für die QR-Rechnung anpassen?

Betroffen ist jede Stelle, die einen Swiss QR Code erzeugt: das Rechnungsmodul im Shop, das Kundenportal, der PDF-Export für die Buchhaltung oder ein Eigenbau mit einer QR-Bibliothek.

1. Adressdaten trennen. In vielen älteren Anwendungen steht die Adresse in einem einzigen Feld oder in zwei freien Zeilen. Für Adresstyp S braucht es mindestens eigene Felder für Postleitzahl, Ort und Land. Strasse und Hausnummer getrennt zu führen, empfiehlt PostFinance, die Hausnummer im Feld «Strasse» ist aber bis auf Weiteres zugelassen. Bestehende Kundendaten müssen entsprechend aufgeteilt werden, am besten mit einer Liste der Datensätze, die sich nicht automatisch zuordnen lassen.
2. Feldlängen beachten. Name und Strasse dürfen höchstens 70 Zeichen lang sein, Hausnummer und Postleitzahl höchstens 16, der Ort höchstens 35. Was länger ist, prüft die Anwendung besser vor dem Erzeugen der Rechnung, statt es stillschweigend abzuschneiden.
3. QR-Code-Erzeugung umstellen. Der Code muss für beide Adressen den Typ S schreiben. Nutzt deine Anwendung die Open-Source-Bibliothek sprain/swiss-qr-bill: Ab Version 5.0 vom November 2025 kennt sie nur noch strukturierte Adressen, und diese Version verlangt PHP 8.1 oder neuer. Läuft deine Anwendung auf einer älteren Version, gehört das PHP-Upgrade mit dazu.
4. Deine eigene Adresse in der Konfiguration. Die Firmenadresse steht oft fest im Template oder in einer Einstellung, als zwei Zeilen. Auch sie muss strukturiert sein.
5. Laufende Rechnungen ersetzen. Haben deine Kunden QR-Rechnungen für Monate im Voraus bekommen, etwa für Abos, Mieten oder Ratenzahlungen, brauchen sie neue Belege. Weise sie gleich darauf hin, Daueraufträge mit alten Vorlagen anzupassen.
6. Rechnungen in Euro. Ab Version 2.4 der Implementation Guidelines sind QR-IBAN und QR-Referenz nur noch für Franken zugelassen. Für Euro bleiben die IBAN mit Creditor Reference (SCOR) oder mit unstrukturierter Mitteilung.
7. Zahlungsdateien. Erzeugt deine Anwendung selbst Zahlungsaufträge für die Bank (pain.001), etwa für Rückzahlungen, verlangt der Schweizer Finanzplatz ab 14. November 2026 auch dort strukturierte oder hybride Adressen. Die Zürcher Kantonalbank gewährt dafür vorläufig eine Fristverlängerung.

So prüfst du deine QR-Rechnungen

1. Testrechnung erzeugen, mit einer echten Kundenadresse aus deinem Bestand und nicht mit einem Musterdatensatz.
2. QR-Code auslesen, mit einer App, die den Text des Codes anzeigt. Der Inhalt besteht aus Zeilen: Die erste lautet SPC, die vierte ist deine IBAN, die fünfte der Adresstyp deiner eigenen Adresse. Steht dort S, ist sie strukturiert, steht dort K, erzeugt deine Anwendung noch die alte Form. Die Adresse deines Kunden beginnt in Zeile 21, auch dort muss S stehen.
3. Kundendaten durchsuchen. Datensätze ohne Postleitzahl, ohne Ort oder ohne Land sind die, bei denen die Rechnung scheitert.
4. Auf der Testplattform prüfen. PostFinance bietet Rechnungsstellern eine Testplattform für QR-Rechnungen an.
5. Offene Rechnungen ansehen. Rechnungen mit Adresstyp K, die nach dem 13. November 2026 fällig werden, stellst du besser neu aus.

Was ändert sich beim Mailversand über Microsoft 365?

Viele PHP-Anwendungen verschicken Mails, indem sie sich mit Benutzername und Passwort eines Postfachs bei smtp.office365.com anmelden: Kontaktformulare, Bestellbestätigungen, «Passwort vergessen», Rechnungen. Microsoft nennt diesen Weg SMTP AUTH oder Client Submission, die Anmeldung mit Benutzername und Passwort heisst Basic Auth. Genau diese Kombination stellt Microsoft ab.

Der Zeitplan hat sich mehrmals verschoben. Angekündigt hat Microsoft das Ende im April 2024, im Exchange Team Blog und mit der Meldung MC786329 im Message Center, zuerst für September 2025, später für März bis April 2026. Seit dem 27. Januar 2026 gilt ein neuer Zeitplan (Stand 6. November 2026):

• Bis Dezember 2026: Alles bleibt, wie es ist.
• Ende Dezember 2026: Für bestehende Microsoft-365-Umgebungen (Tenants) wird SMTP AUTH mit Basic Auth standardmässig abgeschaltet. Admins können es bei Bedarf wieder einschalten.
• Neue Tenants nach Dezember 2026: Basic Auth ist standardmässig nicht verfügbar, unterstützt ist OAuth.
• Zweite Jahreshälfte 2027: Microsoft kündigt das endgültige Abschaltdatum an.

Einen genauen Tag für «Ende Dezember 2026» nennt Microsoft nicht, und das endgültige Datum steht noch aus. Nicht betroffen ist der Versand mit OAuth, bei Microsoft «Modern Authentication». Ebenfalls nicht betroffen sind Anwendungen, die gar nicht über Microsoft 365 versenden.

Was muss deine Anwendung für den Mailversand anpassen?

Prüf zuerst, ob deine Anwendung überhaupt so versendet: In ihrer Konfiguration steht dann smtp.office365.com als Mailserver, meist mit Port 587, dazu Benutzername und Passwort eines Postfachs. Für diesen Fall nennt Microsoft folgende Wege:

• OAuth statt Passwort. Die Anwendung meldet sich mit einem Token an (XOAUTH2). Dafür braucht es eine App-Registrierung in Microsoft Entra ID und eine Mail-Bibliothek, die OAuth kann. Für PHPMailer gibt es eine Anleitung der Entwickler, das dafür vorgesehene Zusatzpaket verlangt mindestens PHP 7.3. Laut dieser Anleitung laufen die geheimen Schlüssel der App-Registrierung nach höchstens 24 Monaten ab. Das Ablaufdatum gehört in deinen Betriebskalender, sonst fällt der Versand später erneut aus.
• High Volume Email for Microsoft 365, wenn die Anwendung nur an Empfänger in deiner eigenen Organisation schreibt.
• Azure Communication Services Email für Mails an interne und externe Empfänger.
• SMTP-Relay über einen Connector, mit fester IP-Adresse oder Zertifikat. Für Anwendungen bei einem Drittanbieter wie Azure schliesst Microsoft diesen Weg aus.

Ausserhalb von Microsoft kann deine Anwendung auch über einen anderen Mailserver versenden, etwa den deines Hosters. Dann müssen SPF und DKIM deiner Domain zum neuen Absender passen. Für SMTP AUTH verlangt Microsoft ausserdem TLS 1.2 oder 1.3.

Ab Ende Dezember kann dein Admin Basic Auth wieder einschalten. Das verschafft Zeit bis zum endgültigen Datum, ersetzt die Umstellung aber nicht.

So prüfst du den Mailversand

1. Konfiguration durchsuchen nach smtp.office365.com: in der .env-Datei, in den Einstellungen des CMS oder Shops, in eigenen Skripten und Cronjobs.
2. Bericht im Exchange Admin Center öffnen. Unter Reports > Mail Flow zeigt der Bericht «SMTP AUTH Clients», welche Absender per SMTP AUTH versenden, ob mit Basic Auth oder OAuth und mit welcher TLS-Version. Standardmässig zeigt er die letzten 7 Tage.
3. Jede Versandart einzeln testen: Kontaktformular, Registrierung, «Passwort vergessen», Bestellbestätigung, Rechnungsversand und automatische Mails aus Cronjobs.
4. Fehlerlog beobachten. Schlägt der Versand fehl, steht die Antwort des Mailservers meist im Log der Anwendung, nicht im Browser.
5. Absender prüfen. Versendet die Anwendung im Namen einer anderen Adresse als der angemeldeten, braucht das Konto die Berechtigung «Senden als».

Warum trifft es gerade ältere PHP-Anwendungen?

Beide Änderungen sind für sich klein. Schwierig werden sie, wenn niemand mehr weiss, wo in der Anwendung Rechnungen und Mails entstehen, oder wenn die nötige Bibliothek auf der eingesetzten PHP-Version nicht läuft. Dann hängt an der QR-Rechnung plötzlich ein PHP-Upgrade. Welche Fristen in den nächsten Jahren sonst noch anstehen, zeigt der End-of-Life-Kalender. Ist unklar, ob dein Hoster, dein früherer Entwickler oder du die Anpassung übernimmst, hilft der Artikel Wer ist zuständig: Hoster, Entwickler oder du?

Was, wenn niemand die Anwendung mehr kennt?

Dann klärt das Übernahme-Assessment, wo deine Anwendung Rechnungen und Mails erzeugt, was für die neuen Vorgaben fehlt und wie gross die Anpassung ist, mit einem Fixpreis für die Umsetzung. Bleiben Zahlungen oder Mails schon aus, hilft der Notfall-Eingriff. Danach behält die laufende Wartung solche Fristen im Blick, bevor sie drängen.