Was Unternehmen für die E-Rechnung lernen können
Am Abend des 5. Mai 2026 waren zahlreiche Webseiten mit der Endung .de zeitweise nicht erreichbar. Betroffen waren sehr unterschiedliche Anbieter: Handel, Banken, Bahn, Portale, Medien und Hostinganbieter. Die Ursache lag nach den bisherigen Meldungen nicht bei den einzelnen Webseiten selbst. Die DENIC meldete eine Störung im DNSSEC-Bereich für .de-Domains; die Störung wurde später als behoben gemeldet, die genaue Ursache wird weiterhin analysiert.
Das Problem lag bei der Namensauflösung und deren Sicherheitsprüfung
Für Nutzer sah es zunächst einfach aus: Eine Webseite ließ sich nicht aufrufen. Technisch war die Lage aber komplexer. Viele Server liefen offenbar weiter. Auch die Netze waren nicht grundsätzlich gestört.
DNS sorgt dafür, dass ein Domainname wie eine Internetadresse zur richtigen technischen Adresse führt. DNSSEC ergänzt diese Namensauflösung um eine Vertrauenskette, mit der Manipulationen verhindert werden sollen. Genau dieser Schutzmechanismus wurde in diesem Fall zum Verfügbarkeitsproblem. Heise berichtete, dass die Störung unabhängig von einzelnen Providern und DNS-Anbietern wirkte.
Vermutlich war das Einspielen eines nicht ausreichend geprüften Sicherheitszertifikats Ursache der Störung.
Praxiskasten: Meine Beobachtungen während der Störung
Am Abend des 5. Mai 2026 zeigte sich die Störung zunächst nicht als klarer DNS-Ausfall. Einige Webseiten waren erreichbar, andere nicht. Betroffen waren nach eigener Beobachtung unter anderem zahlreiche bekannte .de-Webseiten aus Handel, Banken, Bahn, Portalen und Hosting.
Auffällig war: Die Namensauflösung wirkte nicht vollständig gestört. Verschiedene Dienste funktionierten weiterhin. So waren zum Beispiel Zoom, Microsoft Teams, LinkedIn, weclapp, Zattoo und der eigene Mailserver über Strato erreichbar. Gleichzeitig waren andere .de-Angebote zeitweise nicht abrufbar.
Dadurch entstand zunächst der Eindruck eines Routing-, Peering- oder Provider-Problems. Auch die Störungsmeldungen bei verschiedenen Anbietern stiegen zeitgleich an. Erst später verdichteten sich die Hinweise auf eine Störung im Bereich der DNSSEC-Prüfung der .de-Zone.
Die praktische Erkenntnis daraus: Für Nutzer ist bei einer solchen Störung zunächst nur sichtbar, dass ein Dienst nicht erreichbar ist. Die tatsächliche Ursache kann aber an einer ganz anderen Stelle der digitalen Prozesskette liegen.
Und das ist die Parallele zur E-Rechnung: Auch dort reicht es nicht, nur das eigene System zu betrachten. Entscheidend ist, ob die gesamte Kette funktioniert – vom ERP-System über Format und Validierung bis zum Empfänger.
Übrigens: Wer immer auch das Problem gelöst hat, das Team war sehr schnell. Nach meiner Beobachtung begann die Störung um etwa 21.46h, schon gegen 23.05h war die Störung behoben. Also weniger als rund 80 Minuten von der ersten Beobachtung bis zur Entwarnung.
Aus meiner Sicht ein perfektes Beispiel für Resilienz:
Resilienz bedeutet nicht, dass nie etwas ausfällt. Resilienz bedeutet, dass Störungen begrenzt bleiben, erkannt werden und der Betrieb über alternative Wege möglichst schnell weiterlaufen kann.
Wenn der Wegweiser ausfällt
DNS lässt sich gut mit einem Verkehrsleitsystem vergleichen. Die Straße kann frei sein. Das Gebäude kann stehen. Der Server kann laufen. Trotzdem kommt niemand an, wenn die Wegweiser nicht zuverlässig geprüft werden können.
Das ist die eigentliche Lehre aus dem Vorfall:
Digitale Prozesse hängen nicht nur an Servern, Leitungen und Rechenzentren. Sie hängen auch an vorgelagerten Prüfmechanismen, Vertrauensketten und Standards.
Das gilt nicht nur für Webseiten. Es gilt genauso für Rechnungsprozesse.
Die Parallele zur E-Rechnung
Ab 2027 rückt für viele Unternehmen der elektronische Rechnungsausgang stärker in den Mittelpunkt. Dann geht es nicht mehr nur darum, E-Rechnungen empfangen zu können. Unternehmen müssen strukturierte elektronische Rechnungen in größerem Umfang selbst erstellen und versenden.
Viele Unternehmen denken dabei zuerst an das Format: XRechnung, ZUGFeRD, UBL oder CII. Das ist richtig, aber nicht ausreichend.
Entscheidend ist die gesamte Prozesskette:
- Stammdaten
- Pflichtangaben
- Steuerlogik
- ERP-System
- Validierung
- Versandweg
- Empfängersystem
- Rückmeldungen
- Korrekturprozess
Eine Rechnung kann im eigenen System plausibel aussehen und trotzdem beim Empfänger hängen bleiben. Der Grund kann ein technischer Fehler sein. Es kann aber auch an fehlenden Pflichtangaben, unpassenden Stammdaten, einem falschen Übertragungsweg oder unterschiedlichen Prüfregeln liegen.
Erkenntnis: Rollout in Wellen statt Alles-auf-einmal
Die wichtigste Lehre aus der Internetstörung lautet:
Kritische digitale Änderungen müssen kontrolliert ausgerollt, geprüft und bei Bedarf zurückgenommen oder angepasst werden können.
Für die E-Rechnung bedeutet das: Nicht alle Kunden auf einmal umstellen.
Ein praxistauglicher Ansatz ist ein Rollout in Wellen:
Welle 1: 5 Kunden
Zunächst sollten wenige Kunden ausgewählt werden, mit denen gut kommuniziert werden kann. Ziel ist die technische Grundprüfung: Funktionieren Format, Pflichtfelder, Leitweg-ID und Versandweg? Wird die Rechnung akzeptiert? Welche Rückmeldung kommt vom Empfänger?
Welle 2: 25 Kunden
In der zweiten Welle kommen mehr Varianten hinzu. Unterschiedliche ERP-Systeme, Portale, Prüfregeln und Empfängerprozesse werden sichtbar. Jetzt lassen sich typische Fehlerklassen erkennen. Stammdaten und Prozesse können gezielt nachgezogen werden.
Welle 3: 125 Kunden
Erst danach beginnt der breitere Rollout. Jetzt geht es um Serienfähigkeit: Wie hoch ist der Supportaufwand? Welche Rückfragen wiederholen sich? Welche Abläufe müssen stabilisiert werden?
Ich nenne dieses Vorgehen Deploy & Check.
Also: ausrollen, prüfen, Fehler erkennen, nachbessern – und erst dann skalieren.
Wichtig: Validatoren sind keine einheitlichen Messlatten
Bei der E-Rechnung kommt ein weiterer Punkt hinzu: Validatoren sind in Deutschland nicht zentral zertifiziert. Sie sind wichtige Werkzeuge, aber nicht alle prüfen zwingend identisch.
Das bedeutet: Eine Rechnung kann bei einem Empfänger akzeptiert werden und bei einem anderen wegen anderer Prüfregeln hängen bleiben. Das ist kein theoretisches Problem. Es kann in der Praxis zu Rückfragen, Klärungsaufwand, Zahlungsverzögerungen und Liquiditätsproblemen führen.
Deshalb reicht eine interne Prüfung nicht aus. Entscheidend ist die Prüfung im echten Ablauf mit echten Empfängern.
Was Unternehmen jetzt tun sollten
Unternehmen sollten die Einführung der E-Rechnung nicht als einmaliges IT-Projekt behandeln. Es geht um einen digitalen Geschäftsprozess mit vielen Abhängigkeiten.
Sinnvoll sind deshalb:
- ein klarer Rollout-Plan
- Testkunden für die erste Welle
- Prüfung der Stammdaten
- Prüfung der Pflichtfelder
- Klärung der Versandwege
- Dokumentation typischer Fehler
- klare Zuständigkeiten für Rückfragen
- Monitoring der Annahmequote
- Rückfallwege für Problemfälle
Die Internetstörung bei .de-Domains zeigt sehr deutlich: Ein digitaler Prozess kann trotz funktionierender Einzelkomponenten scheitern, wenn ein vorgelagerter Prüfmechanismus nicht funktioniert.
Bei der E-Rechnung ist das ähnlich. Nicht das einzelne XML-Dokument entscheidet allein. Entscheidend ist, ob die gesamte Kette funktioniert.
Fazit
Die Internetstörung vom 5. Mai 2026 war kurz, aber lehrreich. Sie zeigte, wie abhängig digitale Prozesse von zentralen Prüf- und Vertrauensmechanismen sind.
Für die E-Rechnung lautet die wichtigste Erkenntnis:
Nicht alles auf einmal umstellen. Erst testen, dann skalieren.
Oder kurz:
Deploy & Check.
Wer den Rechnungsausgang ab 2027 sicher vorbereiten will, sollte genau so vorgehen: kontrolliert ausrollen, Rückmeldungen auswerten, Fehler klein halten und Prozesse stabilisieren, bevor sie in die Breite gehen.
Seminarhinweis
Mehr dazu im Online-Seminar am 21. Mai 2026:
Update E-Rechnung 2026/2027 – Rechnungsverarbeitung sicher vorbereiten
Im Mittelpunkt stehen die Anforderungen an die E-Rechnung, typische Fehlerquellen, Prüfregeln, Validatoren und ein praxistauglicher Rollout in Wellen.
