E-Rechnung wird 2027 Pflicht: Was Ihre individuelle Software unterstützen muss

Wenn Ihr Unternehmen auf einem individuellen ERP-System, einem selbst entwickelten Webshop oder einem Kundenportal läuft, das eigene Rechnungen erzeugt, ist 2027 das Jahr, in dem die Bundesregierung aufhört, E-Rechnungen als optional zu behandeln. Ab dem 1. Januar 2027 müssen inländische B2B-Unternehmen mit mehr als 800.000 Euro Umsatz im Jahr 2026 elektronische Rechnungen in einem strukturierten, maschinenlesbaren Format ausstellen. Ein PDF im Anhang einer E-Mail erfüllt die Vorgabe nicht mehr, selbst wenn eine Person es öffnen und jede Zeile lesen kann. Ab dem 1. Januar 2028 gilt die Pflicht für jedes Unternehmen, und der Empfang von E-Rechnungen ist bereits seit 2025 im Rahmen des Wachstumschancengesetzes vorgeschrieben. Die Pflicht geht auf das Bundesfinanzministerium zurück und wurde in den Hinweisen der IHK an ihre Mitgliedsunternehmen bestätigt. Sie gilt unabhängig davon, ob Ihre Rechnungen aus SAP, einem vor fünf Jahren von einem Auftragnehmer gebauten ERP-System oder einem Checkout-Flow in einem individuellen Webshop stammen.

Für ein Unternehmen mit Standard-Buchhaltungssoftware ist das größtenteils ein Problem des Anbieters. Für ein Unternehmen, dessen Rechnungsstellung über individuelle Software läuft, liegt es eindeutig bei Ihnen selbst, und die Frist rückt nahe genug, dass eine spätere Klärung kein sicherer Plan mehr ist.

Was Deutschland 2027 unter E-Rechnung versteht

Das deutsche Recht definiert eine E-Rechnung über das Datenmodell EN 16931, einen europäischen Standard, der festlegt, welche Felder eine Rechnung enthalten muss (Käufer- und Verkäuferkennungen, Steueraufschlüsselung, Zahlungsbedingungen, Rechnungspositionen) und wie sie strukturiert sind, damit eine Maschine sie lesen kann, ohne dass jemand alles erneut in eine Buchhaltungssoftware eintippen muss. Ein gut formatiertes PDF, selbst ein ansprechendes mit Ihrem Logo und übersichtlichen Rechnungspositionen, besteht diesen Test nicht, weil darunter keine strukturierte Datenebene liegt, die das System des Empfängers auslesen könnte.

Zwei Formate erfüllen in Deutschland die EN 16931: XRechnung und ZUGFeRD. XRechnung ist ein reines XML-Format, dasjenige, das die meisten Behörden seit Jahren für öffentliche Aufträge verlangen. ZUGFeRD ist ein Hybrid: ein gewöhnliches, für Menschen lesbares PDF mit einer eingebetteten XML-Datei. Öffnet man das PDF, sieht man eine Rechnung. Lädt man dieselbe Datei in eine Buchhaltungssoftware, liest diese die eingebettete XML.

XRechnung vs. ZUGFeRD: das richtige Format wählen

Für die meisten B2B-Unternehmen ist ZUGFeRD im Comfort- oder Extended-Profil die praktischere Wahl. Geschäftspartner, die noch nicht bereit sind, XML zu verarbeiten, können das PDF weiterhin öffnen und lesen, während Ihre E-Rechnungspflicht im Hintergrund erfüllt wird. XRechnung ist eher sinnvoll, wenn ein Partner, insbesondere ein Kunde aus dem öffentlichen Sektor, sie ausdrücklich verlangt, da dies das Format ist, das die meisten deutschen öffentlichen Aufträge bereits erwarten.

Welche Wahl die richtige ist, hängt davon ab, an wen Sie Rechnungen stellen, nicht nur davon, welches Format moderner wirkt. Ein Bauunternehmen, das überwiegend öffentliche Kunden abrechnet, hat eine andere Antwort als ein SaaS-Unternehmen, das direkt an andere Unternehmen abrechnet.

Validierung, Archivierung und Übermittlung: die Teile, die Inhaber vergessen

Eine Datei zu erzeugen, die wie eine XRechnung oder ein ZUGFeRD-Rechnung aussieht, ist nicht dasselbe wie eine Datei zu erzeugen, die die Validierung besteht. Die KoSIT, die deutsche Koordinierungsstelle für IT-Standards, veröffentlicht einen offiziellen Validator, und Rechnungen sollten vor dem Versand dagegen geprüft werden, statt anzunehmen, sie seien konform, nur weil die Dokumentation einer Bibliothek EN-16931-Konformität behauptet. Ein fehlendes Steuernummernfeld oder ein fehlerhaftes Datum kann die Validierung auf der Empfängerseite scheitern lassen, obwohl die Rechnung bei Ihnen problemlos öffnet.

Die Archivierung ist der Teil, der am häufigsten übersehen wird. Nach den GoBD, den deutschen Vorschriften für die digitale Buchführung, müssen Rechnungen acht bis zehn Jahre lang im ursprünglichen, unveränderten Format aufbewahrt werden. Für ZUGFeRD bedeutet das, genau das erzeugte PDF samt eingebetteter XML aufzubewahren, nicht eine später für ein Kundenportal neu gerenderte Kopie. Wenn Ihr aktuelles System Rechnungen als abgeflachte Bilder archiviert oder sie bei Bedarf neu erzeugt, muss dieser Prozess vor der Frist geändert werden, nicht erst nachdem eine Prüfung es aufdeckt.

Die Übermittlung ist der Punkt, an den die wenigsten Inhaber denken. E-Mail mit angehängter Rechnung funktioniert für die meisten inländischen B2B-Beziehungen weiterhin. Doch Peppol, das paneuropäische Austauschnetzwerk, wird zunehmend zum erwarteten Kanal für Rechnungen an öffentliche Stellen und für grenzüberschreitende Rechnungsstellung, und einige größere Kunden beginnen, von Lieferanten den Versand über Peppol statt per E-Mail zu verlangen. Es lohnt sich, bei Ihren wichtigsten Kunden jetzt nachzufragen, ob sie Peppol erwarten, denn das verändert den Integrationsaufwand erheblich.

Bibliothek, Dienstleister oder Eigenentwicklung

Sobald die Formatfrage geklärt ist, gibt es drei realistische Wege für ein individuelles ERP-System, einen Webshop oder ein Portal.

Eine spezialisierte Bibliothek für Ihren Stack übernimmt die XML-Erzeugung und die EN-16931-Validierung in Code, den Sie direkt integrieren. Für PHP- und Symfony-Anwendungen ist dies in der Regel der günstigste Weg, wenn Ihre Rechnungsdaten bereits einigermaßen strukturiert sind, da die Bibliothek die Formatübersetzung übernimmt und Sie nur das Daten-Mapping liefern. Die laufenden Kosten bestehen darin, die Bibliothek aktuell zu halten, während sich der Standard weiterentwickelt, was bereits mehr als einmal passiert ist.

Ein externer Rechnungs- oder Compliance-Dienstleister nimmt die Daten, die Sie über eine API senden, und liefert eine validierte XRechnung oder ZUGFeRD-Datei zurück, teilweise übernimmt er auch Archivierung und Peppol-Übermittlung. Das kostet mehr pro Rechnung oder pro Monat, nimmt aber den größten Teil des Entwicklungsaufwands ab, was für ein kleineres Team oder ein Unternehmen sinnvoll sein kann, das intern eine Compliance-Fläche weniger betreuen möchte.

Das gesamte System selbst zu bauen, einschließlich Erzeugung und Validierung, lohnt sich nur bei wirklich hohem Rechnungsvolumen, bei dem die Kosten pro Rechnung für einen Dienstleister schnell ins Geld gehen und bereits Entwicklungskapazität vorhanden ist, um Änderungen am Standard mitzuverfolgen. Für die meisten mittelständischen Unternehmen mit individueller Software ist dies die Option, die vermieden werden sollte, da sich die Spezifikation ständig weiterentwickelt und niemand das allein pflegen möchte.

Realistischer Aufwand und Zeitplan

Wenn Ihre Rechnungsdaten bereits strukturiert sind, also saubere Kundendatensätze, korrekte Steuerfelder und Rechnungspositionen, die kein reiner Textblock sind, ist die Integration einer Bibliothek oder eines Dienstleisters in der Regel eine Angelegenheit von wenigen Wochen: vorhandene Felder auf das EN-16931-Schema abbilden, Erzeugung und Validierung einbinden, gegen den KoSIT-Validator testen und eine Archivierung einrichten, die die Originaldatei statt einer abgeflachten Kopie aufbewahrt.

Wenn Ihre Rechnungsdaten unübersichtlich sind, die Steuerbehandlung über Produkte hinweg inkonsistent ist oder das System nie mit strukturierten Rechnungspositionen im Sinn entworfen wurde, kann die Datenbereinigung länger dauern als die E-Rechnungs-Integration selbst. Das sollte man jetzt herausfinden, nicht erst im Dezember 2026. Eine kurze Codebase-Bewertung reicht meist aus, um zu klären, in welcher Lage Sie sich tatsächlich befinden, bevor Sie sich auf ein Format oder einen Anbieter festlegen.

Wenn Sie sich beim betreffenden System ohnehin schon unsicher sind, ob Sie es langfristig behalten wollen, ist dies auch ein passender Moment für das schwierigere Gespräch darüber, ob das aktuelle ERP-System für die Compliance angepasst oder durch etwas richtig Gebautes ersetzt werden soll. Und falls Sie mitten in dieser Entscheidung stecken und nur wollen, dass das aktuelle System währenddessen korrekt weiterläuft, deckt Legacy-Software-Support genau diese Lücke ab, ohne Sie vorab auf eine Richtung festzulegen.

Eine Checkliste für Ihren Entwickler

Bevor die Frist näher rückt, lassen Sie sich von demjenigen, der Ihr Rechnungssystem betreut, schriftlich bestätigen, welches Format erzeugt werden soll, XRechnung oder ZUGFeRD, und warum es zu Ihren Kunden passt. Fragen Sie, ob Rechnungen vor dem Versand gegen den offiziellen KoSIT-Validator geprüft werden und wie oft diese Prüfung läuft. Fragen Sie, wo und in welchem Format Rechnungen archiviert werden und ob dieses Setup tatsächlich die acht- bis zehnjährige GoBD-Aufbewahrungsfrist erfüllt und nicht nur irgendwo eine Kopie ablegt. Fragen Sie, ob aktuelle oder voraussichtlich künftige Kunden eine Peppol-Übermittlung erwarten. Und bitten Sie um einen realistischen Zeitplan und realistische Kosten, um von Ihrem aktuellen Stand zur Konformität zu kommen, basierend auf dem tatsächlichen Zustand Ihrer Rechnungsdaten, nicht auf dem Zustand, den Sie vermuten.

Wenn die Antworten vage bleiben oder niemand in Ihrem Team sie sicher beantworten kann, lohnt es sich, das deutlich vor Januar 2027 zu klären, nicht erst nachdem eine Rechnung mit einem Validierungsfehler vom Buchhaltungssystem eines Kunden zurückgewiesen wird, den niemand erklären kann.

Wolf-Tech arbeitet mit Unternehmen genau an dieser Art von Integration und fügt E-Rechnungs-Compliance in individuelle ERP-Systeme, Webshops und Kundenportale ein, ohne einen Neubau zu erzwingen. Wenn Sie eine zweite Meinung dazu wünschen, wo Ihr System steht, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io für mehr darüber, wie wir an diese Art von Arbeit herangehen.