Am 24. September 2026 hat Japan sein nationales Steuersystem grundlegend erneuert. Gleich danach dauerten an den Schaltern der Finanzämter Barzahlungen und die Ausstellung von Steuerbescheinigungen „ungewöhnlich lange“, und auch rund um das Online-Portal e-Tax gab es mehrere Störungen und Notwartungen. Dass ein riesiges, integriertes System kurz nach der Umstellung wackelt, versteht jeder gut, der schon einmal mit verteilten Systemen oder automatisierten Abläufen zu tun hatte. Aber „Ich verstehe, dass es kaputtgeht“ und „Für den Ernstfall gab es genug Ausweichmöglichkeiten“ sind zwei verschiedene Dinge.
Stell dir vor, du musst dringend etwas erledigen, und am Schalter heißt es: „Das gesamte System läuft schlecht, wann es wieder geht, wissen wir noch nicht. Wenn es eilig ist, kommen Sie persönlich vorbei, dann kümmern wir uns darum.“
Normalerweise denkt man: „Dann gehe ich eben hin.“
Wenn man ein bisschen weiterdenkt, sieht die Lage aber ziemlich düster aus.
Wer sein Anliegen nicht online oder auf dem üblichen Weg klären kann, strömt an die Schalter. Auf der Seite der Beschäftigten ist das System instabil, jeder einzelne Vorgang dauert länger. Es kommen mehr Leute, aber die Abfertigungskapazität sinkt.
„Kommen Sie vorbei, wir kümmern uns“ heißt nicht „Kommen Sie vorbei, dann ist es im Handumdrehen erledigt“.
Wenn deine Frist also noch Luft hat, ist Abwarten eine ziemlich vernünftige Entscheidung.
Und innerlich möchte man schreien:
„Nehmt es doch einfach auf Papier an, ehrlich!“
Nur ist Papier keine magische Backup-Datenbank.
1. Was im September 2026 passiert ist
Die japanische Nationale Steuerbehörde (NTA) hat ihr System am 24. September 2026 erneuert. Zum Nachfolgesystem KSK2 nannte die NTA schon länger drei Leitideen:
- Weg von der papierzentrierten Bearbeitung, hin zu einer datenzentrierten Bearbeitung
- Die bisher nach Steuerarten getrennten Datenbanken und Anwendungen zusammenführen
- Von Großrechnern mit eigenem Betriebssystem auf offene Systeme mit gängigen Betriebssystemen umsteigen
Es geht also nicht um einen bloßen Anstrich der Bildschirme. Die Art der Datenhaltung, die Grenzen zwischen den Anwendungen und die Plattform selbst werden auf einen Schlag ausgetauscht.
Am Tag der Umstellung, dem 24. September, veröffentlichte die NTA eine Mitteilung über „Verzögerungen bei verschiedenen Vorgängen an den Schaltern der Finanzämter“. Barzahlungen, die Ausstellung von Steuerbescheinigungen und weiteres dauerten demnach erheblich länger, und selbst eine Beantragung über e-Tax führe nicht zu sofortiger Ausstellung. Die Erneuerung selbst sei abgeschlossen, doch beim Betrieb der für den Schalterdienst nötigen Systeme gebe es Probleme.
In derselben Umstellungswoche gab es außerdem Probleme beim Login über Mynaportal (Japans Behördenportal, das an die persönliche Nummernkarte gekoppelt ist), fehlerhafte Anzeigen zum Abschluss von Zahlungen per Online-Banking, den Ausfall einzelner e-Tax-Funktionen und Notwartungen zur Störungsbehebung. Der Ausfall einzelner e-Tax-Funktionen wurde bis zum 27. September als behoben gemeldet.
Die Mitteilung zur Schalterverzögerung stand dagegen am 28. September noch als dringende Information auf der NTA-Website. Die genaue Ursache war zu diesem Zeitpunkt nicht veröffentlicht.
Noch wichtiger: Geplante Wartung und Störung sollte man nicht in einen Topf werfen. Bei dieser Erneuerung waren ohnehin ein langer Stillstand vom 19. September, 0 Uhr, bis zum 24. September, 8:30 Uhr, und ein ganztägiger Stillstand am 26. September angekündigt. Dazu kamen die Fehler nach der Umstellung und die Notwartungen.
Das Gefühl „Steht das nicht dauernd?“ ist also verständlich, aber darin stecken sowohl geplante als auch störungsbedingte Ausfälle.
2. Auch ein seriöses System, das mit Geld umgeht, fällt aus. Manchmal hält man es gerade deshalb an
„Wenn es ein System für Steuern und Geld ist, baut man es doch so, dass es unter keinen Umständen ausfällt?“
Dem Bauchgefühl nach ja.
Bei kritischen Systemen geht es aber nicht nur um Verfügbarkeit, sondern auch um Konsistenz.
Beim Zahlungsvorgang ist zum Beispiel nicht das Schlimmste, dass eine Seite fünf Minuten lang nicht lädt.
- Du hast gezahlt, giltst aber als säumig
- Ein einzelner Vorgang wird doppelt verbucht
- Eine Bescheinigung wird auf Basis veralteter Daten ausgestellt
- Nur eines von zwei Systemen wird aktualisiert, das andere bleibt zurück
- Beim erneuten Ausführen nach der Wiederherstellung läuft derselbe Vorgang noch einmal
In so einem Zustand kann „wir haben es halt weiterlaufen lassen“ gefährlicher sein als ein Stopp.
Auch die SRE-Unterlagen (Site Reliability Engineering) von Google erklären, dass man bei einer großen Störung zuerst die Ausbreitung des Schadens stoppen sollte, bevor man die Grundursache sucht, und dass es bei möglicher Datenbeschädigung besser sein kann, das System einzufrieren.
Es steht nicht still, obwohl es um Geld geht.
Es muss gerade deshalb manchmal angehalten werden, weil es um Geld geht und man keinen korrekten Zustand mehr garantieren kann.
Wenn „Haben Sie es schon mit einem Neustart versucht?“ alles lösen würde, hätten die Betreiber der Kernsysteme im ganzen Land längst früher Feierabend.
3. Selbst wenn alle Einzeltests bestehen, knallt es bei der Integration trotzdem
Das Fiese an integrierten Systemen: Jedes Teil kann in Ordnung sein, und das Ganze geht trotzdem kaputt.
System A läuft normal.
System B auch.
Die Datenbank auch.
Die Authentifizierung auch.
Trotzdem bleibt alles stehen, wenn sich das Format bei der Übergabe von A an B um ein einziges Zeichen unterscheidet.
Es bleibt stehen, wenn die vom alten ins neue System übertragenen Daten einen Ausnahmewert enthalten.
Geht mitten in einem Wiederholungsversuch nur die Antwort verloren, weiß man nicht mehr, ob der Vorgang verarbeitet wurde oder nicht.
Alte Zwischenspeicher, alte Formulare, Anbindungen an externe Stellen, Berechtigungen, Uhrzeiten, Stapelverarbeitung, Zeichenkodierung, alte Schreibvarianten von Zeichen, erneutes Senden nach Störungen. Je mehr Grenzen es gibt, desto mehr Kombinationen entstehen, die man einzeln nicht sieht.
Schon eine kleine private Automatisierung verunglückt leicht durch alte Zustände, doppelte Ausführung, übersehene Fälle, Unterschiede bei externen Schnittstellen und Nebenwirkungen von Wiederholungen.
Und das Ganze jetzt bei einem Kernsystem, das Finanzämter im ganzen Land, mehrere Steuerarten, Einzug, Erstattung, Bescheinigungen, e-Tax und externe Stellen umfasst.
Wer weiß, wie schwer Integration ist, denkt: „Na ja, direkt nach der Umstellung kommt immer irgendetwas hoch.“
Das ist aber kein Freibrief.
Zu bewerten ist nicht nur, ob es keine einzige Störung gab, sondern wie sicher der Betrieb bei einer Störung heruntergefahren werden konnte.
4. Warum es dann heißt: „Ein Wiederherstellungstermin steht nicht fest“
Für Nutzer ist das einer der ärgerlichsten Sätze:
„Der Zeitpunkt der Wiederherstellung steht noch nicht fest.“
Aber eine beliebige Uhrzeit zu versprechen, solange die Ursache unklar ist, kann gefährlicher sein.
Bei einem kritischen System ist die Wiederherstellung nicht damit erledigt, dass der Server wieder startet.
Zuerst wird der Umfang der Störung eingegrenzt.
Dann wird geprüft, ob Daten nur halb geschrieben wurden.
Man prüft, ob ein erneutes Ausführen zu Doppelverarbeitung führt.
Man prüft, ob der Zustand mit den angebundenen externen Systemen auseinanderläuft.
Falls nötig, werden ein Zurückrollen oder ein Ausweichweg erwogen.
Nach der Wiederherstellung werden die während des Stillstands aufgelaufenen Vorgänge der Reihe nach abgearbeitet und die Ergebnisse abgeglichen.
Besonders lästig wird es, wenn sich Zustände mischen wie „Beim Sender sieht es erfolgreich aus, beim Empfänger ist es nicht bestätigt“.
Auch in einem von Amazon veröffentlichten Text zum Entwurf verteilter Systeme wird erklärt, dass für sichere Wiederholungen Idempotenz entscheidend ist, also eine Auslegung, bei der das erneute Senden derselben Anfrage ihre Wirkung nicht verdoppelt.
Dass man keinen Wiederherstellungszeitpunkt nennen kann, beweist nicht, dass die Zuständigen nichts tun.
Solange unklar ist, wie weit etwas kaputt ist, wie weit man zurückgehen kann und ab wo man ohne Doppelverarbeitung neu starten kann, ist eine genaue Prognose schon an sich schwierig.
5. „Wenn es eilt, kommen Sie zum Schalter“ ist als Warteschlange ziemlich beängstigend
Hier kommt der Schalter ins Spiel.
Auch bei einer Systemstörung heißt es manchmal: „Wenn Sie persönlich kommen, kümmern wir uns.“
Das ist ein dankbarer Ausweg.
Aus Sicht der Wartezeit kommen aber ziemlich gefährliche Bedingungen zusammen.
Vereinfachen wir den Normalfall.
Nennen wir die Zahl der Ankommenden am Schalter λ und die Zahl, die die Beschäftigten abarbeiten können, μ.
Bei einer Störung können zwei Dinge gleichzeitig passieren.
Erstens kommen auch Leute zum Schalter, die sonst online oder über interne Abläufe fertig würden, also steigt λ.
Zweitens können die Beschäftigten das System schlechter nutzen, pro Vorgang nehmen Prüfungen und Handeingaben zu, also sinkt μ.
Die Nachfrage steigt und die Kapazität sinkt.
Für eine Warteschlange ist das die schlimmste Kombination.
Und die Beschäftigten der Finanzämter vermehren sich nicht von selbst, wenn eine Störung auftritt.
Die SRE-Unterlagen von Google weisen außerdem darauf hin, dass ein System nahe der Überlast nicht einfach nur etwas langsamer wird, sondern sich durch längere Wartezeiten und Kettenausfälle nichtlinear verschlechtern kann. Deshalb sind Laststeuerung und eingeschränkte Antworten wichtig.
„Am Schalter wird es erledigt“ heißt nicht „Am Schalter ist es leer“.
Hat deine Frist Luft, ist es mit Blick auf die Zeitkosten durchaus vernünftig, nicht am Störungshöhepunkt hinzustürmen, sondern die Wiederherstellung abzuwarten.
Spielen dagegen gesetzliche Fristen oder Dringlichkeit eine Rolle, sollte man es nicht nach eigenem Ermessen liegen lassen, sondern in den dann aktuellen offiziellen Hinweisen der NTA oder des Finanzamts nach Ersatzwegen schauen.
6. „Macht es auf Papier“ stimmt zur Hälfte. Papier taugt als Ausweg für die Annahme, ist aber keine Backup-Datenbank
Wenn man diese Störungen beobachtet, kommt einem allmählich der Gedanke:
„Dann nehmt es doch einfach auf Papier an.“
Diese Idee ist nicht völlig falsch.
Auch der Leitfaden des NIST (der US-Normungsbehörde) zur Notfallplanung für Informationssysteme nennt als Ersatzverfahren bei Störungen, Geschäftsprozesse für kurze Zeit ganz oder teilweise manuell durchzuführen.
Manuelle Bearbeitung ist also durchaus eine anerkannte Maßnahme zur Betriebsfortführung.
Aber „Aufs Papier schreiben, dann ist alles erledigt“ gilt nicht.
Auf Papier lässt sich zum Beispiel Folgendes machen:
- Festhalten, dass ein Antrag oder eine Anfrage eingegangen ist
- Datum und Uhrzeit des Eingangs festlegen
- Notwendige Unterlagen entgegennehmen
- Eine Reihenfolge für die Bearbeitung nach der Wiederherstellung anlegen
- Eine Vorgangsnummer oder einen Beleg aushändigen
Dagegen lassen sich der Abgleich mit zentralen Daten, die Prüfung des Zahlungsstatus, der Zugriff auf frühere Einträge, die korrekte Ausstellung von Bescheinigungen und die Anbindung externer Stellen ohne das Kernsystem unter Umständen nicht abschließen.
Das Ideal ist deshalb nicht, „alles aufs Papier zurückzudrehen“.
Das Ideal ist: Auch wenn das Kernsystem stirbt, stirbt die Annahme nicht mit.
Papier ist keine Backup-Datenbank.
Aber ein Eingangsbeleg auf Papier kann ein Notausgang sein.
7. Was man wirklich braucht, ist ein „Notbetrieb“, der nicht komplett stillsteht
Ein störungsfestes System hält nicht unbedingt 100 % der normalen Funktionen aufrecht.
Es behält vielmehr nur die wichtigen Funktionen und fällt in einen vereinfachten Modus zurück.
Google SRE behandelt das als schrittweise Funktionsminderung, sogenannte graceful degradation. Auch das NIST nennt Ersatzeinrichtungen, Ersatzstandorte und manuelle Bearbeitung als Optionen eines Notfallplans.
Auf Steuerverfahren übertragen sähe das Idealbild so aus:
- Die Annahme nicht stoppen. Zumindest die wichtigsten Antragsdaten lassen sich auch offline oder auf Papier entgegennehmen.
- Eine Eingangsnummer vergeben. Das „Ich weiß nicht, ob es angekommen ist“ verschwindet.
- In eine Nachbearbeitungs-Warteschlange einreihen. Nach der Wiederherstellung kann in der richtigen Reihenfolge nachverarbeitet werden.
- Doppelverarbeitung verhindern. Es gibt eine Kennung, durch die derselbe Antrag auch bei erneuter Eingabe nur einmal zählt.
- Nach Dringlichkeit unterscheiden. Vorgänge mit nahender Frist oder großer Auswirkung auf das Leben haben Vorrang.
- Den Zustand für Nutzer sichtbar machen. Getrennt bekannt geben, was steht, was nutzbar ist und was wieder läuft.
- Nach der Wiederherstellung abgleichen. Papier- und Offline-Annahmen mit den Produktivdaten abgleichen, um Lücken und Doppelungen zu finden.
Wichtig ist nicht die Illusion, dass „auch bei einer Störung alles unverändert weiterläuft“.
Wichtig ist, die Art des Kaputtgehens zu gestalten.
8. Wie oft hat e-Tax eigentlich Probleme?
Schaut man in die offiziellen e-Tax-Mitteilungen von 2026, finden sich über das Jahr mehrere Störungsmeldungen: im Januar eine verspätete Benachrichtigung über abgeschlossene Zahlungen, im Februar Fehler bei der Anbindung an Mynaportal und Login-Schwierigkeiten, im März Login-Schwierigkeiten, im Juli Fehler bei der Nutzung über Mynaportal, im August Ausfälle bei der Direktzahlung und anderen Funktionen und im September mehrere Fehler direkt nach der Erneuerung.
Hier darf man aber nicht grob zählen.
Das sind nicht alles dieselben Störungen.
Es gibt Probleme von e-Tax selbst, aber auch bei der Anbindung an Mynaportal, bei Zahlungen, bei der Anzeige und auf Seiten externer Dienste. Außerdem ist geplante Wartung keine Störung.
Aus der offiziellen Liste lässt sich daher nur sagen, dass „teilweise Fehler und Störungen bei angebundenen Diensten mehrmals im Jahr gemeldet werden“, nicht aber, dass „das gesamte Steuersystem ständig landesweit ausfällt“.
Der September 2026 fällt vor allem deshalb auf, weil sich in der Umstellungswoche einer riesigen Erneuerung ein langer geplanter Stillstand und mehrere Fehler nach der Umstellung überlagerten.
9. Wer die Integrationshölle kennt, ärgert sich ein wenig anders
Wer schon einmal ein kleines automatisiertes System gebaut hat, schaut etwas anders auf Störungen großer Systeme.
Früher blieb es bei:
„Wie kann so etwas ausfallen?“
Wer aber einmal mehrere Dienste verbunden, Warteschlangen eingesetzt, Wiederholungen eingebaut, Zustände gespeichert und externe Schnittstellen angebunden hat, denkt auch:
„Oh, eine Umstellung auf ein integriertes System. Das ist die Hölle.“
Einzeln läuft alles, im Ganzen geht es kaputt.
Repariert man etwas, geht eine andere Grenze kaputt.
Alte Zustände bleiben übrig.
Wiederholt man, wird es doppelt.
Im Log stehen Informationen von gestern.
Schon wer eine kleine Version davon erlebt hat, kann sich die Schwierigkeit eines riesigen Kernsystems leichter vorstellen.
Verstehen und Bewerten sind aber zweierlei.
Statt es bei „Ist eben schwierig, kann man nichts machen“ zu belassen, sollte man auf Folgendes achten:
- Wie weit Last- und Migrationstests vor der Umstellung gingen
- Wie weit bei der Störung im Notbetrieb gearbeitet werden konnte
- Wie weit die manuelle Annahme funktionierte
- Ob die Statusmeldungen für die Nutzer ausreichten
- Ob nach der Wiederherstellung Ursache und Gegenmaßnahmen veröffentlicht werden
- Ob sich bei der nächsten Umstellung dieselbe Art von Unfall vermeiden lässt
Weil es komplex ist, können Unfälle passieren.
Gerade weil es komplex ist, zählen Gestaltung und Lernen nach dem Unfall.
10. Fazit: nicht „alles auf Papier“, sondern „Auch auf Papier darf der Eingang nicht sterben“
Wenn das Kernsystem eines Finanzamts ausfällt, wirkt das aus Nutzersicht ziemlich unfair.
Ein Ort, der mit Geld und rechtlichen Verfahren umgeht, steht still.
Wann es wieder läuft, weiß man auch nicht.
Es heißt, man könne zum Schalter kommen, aber der wird garantiert voll sein.
Da möchte man sagen: „Macht es doch einfach auf Papier.“
In diesem Gefühl steckt eine ziemlich wichtige Anforderung an den Entwurf.
Das gesamte Steuersystem allein durch Papier zu ersetzen, ist nicht realistisch.
Aber es muss auch nicht sein, dass in dem Moment, in dem das System ausfällt, Annahme, Erfassung, Priorisierung und Nachbearbeitungs-Warteschlange gleich mit sterben.
Ein riesiges System braucht nicht den Mythos „Es geht nie kaputt“.
Es braucht, dass trotz Ausfall zumindest die minimale Arbeit erhalten bleibt.
Dass man ohne Doppelverarbeitung zurückkehren kann.
Dass den Nutzern gesagt wird, was funktioniert und was nicht.
Und dass man nach der Wiederherstellung die liegengebliebene Arbeit sicher aufholen kann.
Die letzte Forderung lautet also:
Nicht „alles auf Papier“.
Sondern „Wenigstens die Annahme muss notfalls auf Papier laufen. Ehrlich.“
Quellen
- Nationale Steuerbehörde (NTA), „Zu den Verzögerungen bei verschiedenen Vorgängen an den Schaltern der Finanzämter“, 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, „Zur Erneuerung des nationalen Steuersystems“
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - NTA-Bericht 2025, „Nachfolgesystem (KSK2)“
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, „Zu den Wartungszeiten im Zusammenhang mit der Erneuerung des nationalen Steuersystems“
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, „Übersicht der Mitteilungen“
https://www.e-tax.nta.go.jp/topics/ - e-Tax, „[Behoben] Zur Nichtverfügbarkeit von e-Tax“
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
