Seit Januar 2025 müssen Unternehmen in Deutschland E-Rechnungen empfangen können. Das haben die meisten inzwischen gelöst. Die eigentliche Herausforderung kommt jetzt, denn am 31. Dezember 2026 endet die Übergangsfrist für den Versand. Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz im Geschäft mit anderen Unternehmen strukturierte elektronische Rechnungen ausstellen. Ein PDF per E-Mail zählt dann nicht mehr. Wer seine Rechnungsprozesse dieses Jahr nicht umstellt, riskiert ab 2027 formal unwirksame Rechnungen, im schlimmsten Fall mit Folgen für den Vorsteuerabzug des Kunden.

Was eine E-Rechnung ist und was nicht

Eine E-Rechnung im Sinne des Gesetzes ist ein strukturierter Datensatz nach der europäischen Norm EN 16931, den eine Software automatisch verarbeiten kann. In Deutschland haben sich dafür zwei Formate etabliert. Die XRechnung ist ein reines XML-Format, das ursprünglich für Rechnungen an Behörden entwickelt wurde. Maschinen lesen es perfekt, Menschen ohne passende Software gar nicht. ZUGFeRD geht einen anderen Weg und bettet die strukturierten XML-Daten in eine normale PDF-Rechnung ein. Der Mensch sieht das gewohnte Dokument, die Software liest die Daten. Für viele Mittelständler ist das der pragmatische Weg, weil bestehende Abläufe weiterlaufen können. Wichtig ist dabei, dass nur die Profile ab EN-16931-Konformität die gesetzlichen Anforderungen erfüllen.

Beide Formate sind zulässig. Entscheidend ist, dass die eigenen Systeme sie korrekt erzeugen, validieren und die Anforderungen der Empfänger erfüllen.

Das eigentliche Problem sind die Altsysteme

Eine Rechnung entsteht selten im luftleeren Raum. Sie kommt aus der Warenwirtschaft, dem ERP oder einer selbst entwickelten Branchenlösung. Und genau da liegt bei vielen Mittelständlern das Problem. Gewachsene Systeme, oft vor zehn oder zwanzig Jahren in Delphi, VB oder C# entwickelt, erzeugen Rechnungen als Druckausgabe oder PDF, aber keine EN-16931-konformen Datensätze. Der ursprüngliche Hersteller existiert nicht mehr, der Quellcode liegt brach oder das nötige Modul-Update wird schlicht nicht mehr angeboten. Solche Konstellationen sehe ich in meiner Arbeit regelmäßig.

Realistisch gibt es drei Lösungswege. Wenn Quellcode und Know-how verfügbar sind, lässt sich das Bestandssystem um ein Exportmodul für XRechnung und ZUGFeRD erweitern. Das ist solide Entwicklungsarbeit mit überschaubarem Umfang. Alternativ kann eine vorgeschaltete Konverter-Lösung die vorhandenen Rechnungsdaten aus der Datenbank oder aus Exportdateien in konforme Formate wandeln und validieren. Der dritte Weg ist der Umstieg auf neue Software. Er ist der sauberste, aber auch der teuerste und langwierigste, und allein wegen der E-Rechnung lohnt er sich selten.

Validierung und Archivierung nicht vergessen

Mit dem Erzeugen ist es nicht getan. Ausgehende Rechnungen sollten gegen die Norm validiert werden, bevor sie das Haus verlassen, denn fehlerhafte Datensätze führen zu Rückläufern und Zahlungsverzögerungen. Außerdem müssen E-Rechnungen GoBD-konform archiviert werden, und zwar im strukturierten Originalformat und nicht nur als PDF-Ansicht. Wer Empfang, Erzeugung, Validierung und Archiv von Anfang an als einen zusammenhängenden Prozess denkt, erspart sich spätere Nacharbeiten.

Der Zeitplan für den Rest des Jahres

Bis zum Sommer sollte die Bestandsaufnahme stehen. Welches System erzeugt Ihre Rechnungen, was kann es schon, was fehlt? Bis zum Herbst sollte der Lösungsweg feststehen und umgesetzt sein, ob Modul, Konverter oder Migration. Das vierte Quartal gehört dann dem Testlauf mit echten Kunden und der Validierung, damit ab Januar nichts klemmt. Für Unternehmen unter 800.000 Euro Umsatz gilt die Versandpflicht übrigens erst ein Jahr später ab 2028. Empfang und Archivierung gelten aber längst für alle.

Unterm Strich ist die E-Rechnung weniger ein Steuerthema als ein Software- und Schnittstellenthema. Und sie ist eine Gelegenheit. Wer ohnehin an seine Rechnungsprozesse muss, kann Medienbrüche, manuelle Übertragungen und Insellösungen gleich mit beseitigen.