
Sage 100 V9.0.11: Wenn OAuth den Rechnungsversand über Microsoft 365 blockiert
Autor: Holger Erbe • • Digitalisierung
Wer aktuell mit Sage 100 in der Version 9.0.11 arbeitet und Rechnungen, Vertragsrechnungen oder E-Rechnungen direkt aus dem Stapel per E-Mail versendet, kennt das Problem vermutlich bereits. Mitten im Versand öffnet sich plötzlich wieder das Anmeldefenster von Microsoft 365. Die OAuth Verbindung zwischen Sage 100 und dem M365 Konto bricht ab, und der komplette Rechnungsversand steht, bis sich jemand erneut manuell anmeldet.
Wer aktuell mit Sage 100 in der Version 9.0.11 arbeitet und Rechnungen, Vertragsrechnungen oder E-Rechnungen direkt aus dem Stapel per E-Mail versendet, kennt das Problem vermutlich bereits. Mitten im Versand öffnet sich plötzlich wieder das Anmeldefenster von Microsoft 365. Die OAuth Verbindung zwischen Sage 100 und dem M365 Konto bricht ab, und der komplette Rechnungsversand steht, bis sich jemand erneut manuell anmeldet. Dies wurde bereits von Sage bestätigt, eine Lösung steht noch aus.
Uns begegnet dieses Verhalten aktuell bei mehreren Mandanten, immer im gleichen Muster. Der Versand aus dem Stapel läuft eine Weile normal, dann fordert Sage 100 wieder eine Anmeldung an, unabhängig davon, wie frisch das hinterlegte Token eigentlich noch sein sollte.
Warum das Problem gerade jetzt besonders schmerzt
Microsoft zieht sich seit Jahren schrittweise von der klassischen SMTP Anmeldung mit Benutzername und Passwort zurück. Der ursprünglich für September 2025 angesetzte Termin für die endgültige Abschaltung von Basic Authentication bei SMTP AUTH wurde mittlerweile mehrfach verschoben, zuletzt auf Ende Dezember 2026. Am grundsätzlichen Kurs ändert das aber nichts, OAuth ist und bleibt der von Microsoft vorgesehene Weg für den E-Mail Versand aus ERP Systemen heraus.
Sage 100 setzt genau deshalb schon länger auf OAuth statt auf die klassische Anmeldung. Ausgerechnet diese OAuth Anbindung ist in Version 9.0.11 nun aber selbst die Fehlerquelle. Wer alles richtig gemacht und frühzeitig auf OAuth umgestellt hat, steht trotzdem wieder vor dem gleichen Problem, das damit eigentlich gelöst sein sollte.
Verschärft wird das Ganze durch die E-Rechnungspflicht. Seit Anfang 2025 müssen alle Unternehmen E-Rechnungen empfangen können, und je nach Unternehmensgröße greift ab 2027 beziehungsweise 2028 auch die Pflicht zum Versand in strukturierten Formaten. Das E-Mail Aufkommen für Rechnungen wächst also ohnehin, ein zuverlässiger Versand ist deshalb wichtiger denn je.
Die Auswirkungen in der Praxis
Ein unterbrochener Mailversand ist bei Rechnungen kein rein technisches Ärgernis. Buchhaltungsteams merken es oft erst, wenn Kunden nach einer Rechnung fragen, die eigentlich längst hätte rausgehen sollen. Bei größeren Stapeln bleibt der Versand mitten im Lauf stehen, und jemand muss die Sage 100 Sitzung wiederfinden, sich am M365 Konto anmelden und den Lauf neu anstoßen. Auf Dauer ist das ein handfestes Produktivitätsproblem, gerade in kleinen Teams, in denen genau die eine Person mit Zugriff auf das Rechnungspostfach gerade nicht am Platz ist.
Unser Workaround: Versand über ein SMTP Relay, ohne den Nachweis in M365 zu verlieren
Die naheliegende Lösung ist, den Mailversand aus Sage 100 komplett an M365 vorbeizuleiten und stattdessen über ein separates SMTP Relay beziehungsweise Gateway laufen zu lassen. Damit verschwindet das wiederkehrende Anmeldefenster, weil Sage 100 nicht mehr per OAuth gegen M365 authentifizieren muss, sondern feste SMTP Zugangsdaten des Relays nutzt.
Das bringt allerdings ein neues Problem mit sich. Sobald komplett am M365 Postfach vorbei versendet wird, taucht die verschickte Rechnung in Outlook nirgendwo mehr im Ordner Gesendete Elemente auf. Für die Nachvollziehbarkeit von Rechnungen ist das aus unserer Sicht keine akzeptable Lösung, gerade weil im Streitfall oder bei einer Prüfung genau dieser Nachweis gebraucht wird.
Deshalb ergänzen wir den Aufbau um einen zweiten Schritt.
Jede über das Relay versendete Rechnung geht zusätzlich per BCC an sich selbst Rechnungspostfachs. Das heisst in unserem Beispiel die Mail von rechnung@musterfirma.de wird zusätzlich in BCC an den Empfänger rechnung@musterfirma.de geschickt.
Im Postfach rechnung@musterfirma.de legen wir eine servergestützte Regel für eingehende E-Mails an. Diese sorgt dafür, dass jede Nachricht, die von Rechnung @musterfirma.de gesendet wurde automatisch in den Ordner Gesendete Elemente verschoben und als gelesen markiert wird. Wichtig ist hier bewusst eine serverbasierte Regel und keine reine Client Regel, damit die Verschiebung auch dann funktioniert, wenn niemand gerade in Outlook angemeldet ist.
Ergebnis: Im Postfach rechnung@musterfirma.de landen jetzt auch alle Rechnungen, die technisch über das Relay und nicht über M365 selbst verschickt wurden, ganz normal im Ordner Gesendete Elemente, so wie man es vom regulären Versand über Outlook kennt.
Der Empfänger bemerkt von diesem Umbau übrigens nichts. Die Rechnung kommt ganz normal an, nur der Weg dorthin läuft im Hintergrund anders als gewohnt.
Worauf es beim SMTP Relay wirklich ankommt
Nicht jedes Relay eignet sich für den Rechnungsversand. Microsoft bietet ohnehin keinen klassischen SMTP Zugang mehr an, auf den man notfalls zurückgreifen könnte, insofern führt an einer externen Lösung für diesen Anwendungsfall kein Weg vorbei. Entscheidend ist dabei vor allem die Zustellbarkeit. Ein Relay, das nicht sauber mit SPF, DKIM und DMARC für die eigene Domain konfiguriert ist, landet beim Empfänger schnell im Spam Ordner, und dann ist am Ende nichts gewonnen.
Für unsere Kunden setzen wir einen eigenen Dienst Mailbridge für den DSGVO konformen Versand transaktionaler E-Mails aus ERP und CRM Systemen ein, inklusive vollständiger Einrichtung von SPF, DKIM und DMARC für die jeweilige Absenderdomain. So bleibt der Versand zuverlässig, nachvollziehbar und ohne wiederkehrende Anmeldefenster.
Fazit
Der OAuth Fehler in Sage 100 V9.0.11 ist ärgerlich, lässt sich aber mit einem durchdachten Workaround gut abfedern, ohne dass dabei die Nachvollziehbarkeit der Rechnungen verloren geht. Der Umweg über ein SMTP Relay mit BCC auf einen Alias und einer servergestützten Regel im Rechnungspostfach sorgt dafür, dass am Ende trotzdem alles dort ist, wo man es erwartet, im Ordner Gesendete Elemente von M365.
Wenn Sie bei Sage 100 und M365 vor einem ähnlichen Problem stehen oder generell zuverlässigen Rechnungsversand ohne Spam Probleme beim Empfänger suchen, sprechen Sie uns gerne an. Wir schauen uns Ihre aktuelle Konfiguration an und richten den Workaround gemeinsam mit Ihnen ein.
