Dieser Bug ist seit Juli 2022 dokumentiert — wir haben jetzt Mai 2026.Dieser Bug ist seit Juli 2022 dokumentiert — wir haben jetzt Mai 2026. Knapp vier Jahre.

Ich kann mich den Vorrednern nur anschließen, möchte aber ergänzen, wie weitreichend die Konsequenzen tatsächlich sind. Es geht hier nicht um einen kosmetischen Anzeigefehler, sondern um Datenintegrität in einem Buchhaltungssystem.

Meine konkreten Beobachtungen aus dem laufenden Betrieb (ich arbeite aus UK, also GMT bzw. BST):

-> Buchungsübersicht inkonsistent mit sich selbst: Wähle ich in der Buchungsübersicht Q1/2026 aus, erscheint dort ein Beleg, der korrekt auf den 01.01.2026 datiert ist — aber angezeigt wird das Datum als 31.12.2025. Der Beleg wird also gleichzeitig im richtigen Quartal einsortiert und mit dem falschen Datum angezeigt. Das ist nicht nur verwirrend, das ist schlicht ein Widerspruch innerhalb derselben Ansicht.

-> DATEV-Export liefert falsche Monatslabels. Das ist die rote Linie. Der DATEV-Export ist die Schnittstelle zum Steuerberater bzw. zum Finanzamt. Wenn dort Monatszuordnungen falsch sind, sind UStVA, EÜR, und sämtliche Periodenabschlüsse betroffen. Das ist kein "Edge Case", das ist ein Fehler mit unmittelbaren steuerlichen und potenziell strafrechtlichen Konsequenzen für den Mandanten.

-> Browser-Plugins zum Spoofen der Zeitzone helfen nicht. Offenbar wird die Zeitzone nicht nur über eine einzige API ermittelt, sondern an mehreren Stellen unterschiedlich. Der einzige zuverlässige Workaround ist, die Systemzeit des gesamten Rechners umzustellen — was, wie tsief_fainans_ofisser völlig zu Recht anmerkt, eine absurde Zumutung ist und an anderen Stellen (Kalender, Logfiles, Kommunikation, andere Software) neue Probleme schafft.

Die Antwort des Supports, man möge doch einfach die Systemzeit umstellen, ist für ein professionelles Buchhaltungsprodukt nicht akzeptabel. Lexware Office wird nicht nur von Tagesreisenden genutzt, sondern auch von Selbstständigen mit ständigem Auslandswohnsitz, von remote arbeitenden Teams, und von deutschen Unternehmen mit internationaler Belegschaft. Dass eine deutsche Buchhaltungssoftware die Periodenzuordnung von der lokalen Browser-Zeitzone des bearbeitenden Nutzers abhängig macht, ist konzeptionell falsch — das Belegdatum ist ein Datum, kein Zeitstempel mit Zonenbezug, und die Periodenzuordnung muss deterministisch in Europe/Berlin erfolgen, unabhängig vom Client.

Der Fix ist technisch trivial: Belegdaten als reine Datumswerte ohne Zeitzonen-Konvertierung behandeln, und sämtliche Periodenlogik serverseitig in Europe/Berlin auflösen. Das ist eine Aufgabe von wenigen Personentagen für ein erfahrenes Team.

Bitte priorisieren. Vier Jahre sind genug.

Das gleiche Problem hatte ich auch gerade, hat ziemlich lange gedauert das heraus zu finden. Laut ChatGPT ist das ein gängiges Problem bei SaaS Produkten (Software as a Service) da die Server Zeitzonen mit den Frontend Zeitzonen im Browser kollidieren. Das müsste unbedingt mal gefixt werden, da es massive Probleme bereiten kann, vor allem in der UST Voranmeldung. Ich bin auf den Kanaren und hab die Zeitzone manuell geändert in den macOS Systemeinstellungen, so ließ sich das Problem beheben, allerdings hab ich dann die falsche Zeit auf meinem System. Dass das Problem nach 4 Jahren noch besteht ist eigentlich ein Ding, sollte ja mehrere Menschen betreffen die im Ausland mal eine RG erstellen.

P.S.: Der Tip vom Support, doch einfach die Systemzeit auf dem Laptop auf deutsche Zeit umzustellen, ist wenig hilfreich. Das führt zu X anderen Problemen, z.B. Logfiles, und ist nicht praktikabel, zumal die wenigsten ausschließlich mit Lexware Office arbeiten und dabei nichts anderes tun gleichzeitig. Außerdem total Fehleranfällig.

Das Backend von Lexware Office scheint die Uhrzeit des Users in dessen UI auszulesen und das ist ein konzeptioneller Fehler! Es kann nicht sein, dass andere Dinge gebucht werden oder Belege mit abweichenden Angaben erstellt werden, in Abhängigkeit davon, in welcher Zeitzone sich ein User im Team gerade aufhält!

Dieser Bug zieht sich duch das gesamte System bzw. hat im gesamten System Auswirkungen. So hat es z.B. Auswirkungen auf die angezeigten Lieferzeiträume auf Angeboten, auf die Datumsangaben auf Belegen generell, auf die Anzeige, ob eine UStVA rechtzeitig oder verspätet eingereicht wurde, und so weiter!

Ich habe das schon mehrfach dem Support gemeldet als bug, aber sie denken das sei unerheblich, oder egal, oder ein absoluter Edge-Case der ihnen egal ist.

In der heutigen Zeit von remote work, distributed teams, Internationalisierung etc. sollte eine Software wie Lexware Office über den Tellerrand hinaussehen und "international-ready" sein. Das Auslesen der Systemzeit beim Client ist ein konzeptioneller Bug. Einzig und alleine die Zeit des Servers in Deutschland sollte maßgeblich sein, oder, noch besser, man sollte als user eine Zeitzone für seinen Account wählen können, und welche Systemzeit die User auf ihren Laptops haben sollte völlig unerheblich sein!