E-Rechnung Pflicht 2027: Compliance als Einstieg in automatisierte Finanzprozesse

Unser Head of Business Integration & Architecture Patrizio Doktor erklärt, wie Unternehmen die E-Rechnungspflicht erfüllen, ohne eine weitere Insellösung aufzubauen.

Die E-Rechnung Pflicht 2027 ist für mich vor allem eine Integrationsaufgabe. Formate und Fristen stehen fest. Offen ist in vielen Unternehmen, ob Empfang, Versand und Partneranbindung in einem gemeinsamen Prozess laufen oder in mehreren, die nichts voneinander wissen.

Wie groß der Handlungsbedarf ist, zeigt eine Bitkom-Studie unter 1.103 Unternehmen: Kurz vor dem 1. Januar 2025, ab dem der Empfang von E-Rechnungen verpflichtend ist, konnten erst 45 % der Unternehmen in Deutschland E-Rechnungen empfangen. Beim Empfang dominieren EDI-Formate mit 71 %, ZUGFeRD bzw. Factur-X nutzen 27 %, das rein XML-basierte Format XRechnung 5 %.

Ab dem 1. Januar 2027 folgt die nächste Stufe. Unternehmen mit einem Vorjahresumsatz von mehr als 800.000 Euro müssen inländische B2B-Rechnungen als E-Rechnung ausstellen, ab 2028 gilt die Pflicht grundsätzlich für alle Unternehmen, ausgenommen sind etwa Kleinunternehmer und Kleinbetragsrechnungen bis 250 Euro. Verbindlich regelt das BMF-Schreiben zur E-Rechnung die Details, einen Überblick geben die FAQ des Bundesfinanzministeriums. Viele Unternehmen haben 2025 eine Empfangslösung eingeführt, für den Versand entsteht jetzt häufig eine zweite. Darin sehe ich das eigentliche Risiko: Jede zusätzliche Insellösung bringt eigene Mappings, eigene Prüfregeln und eigenes Monitoring mit.

In diesem Beitrag erkläre ich, was die Pflicht technisch verlangt, welche Architekturwege es gibt und wie daraus eine automatisierte Rechnungsverarbeitung entsteht.

Was die E-Rechnung Pflicht 2027 technisch verlangt

Eine E-Rechnung ist eine Rechnung in einem strukturierten elektronischen Format nach der europäischen Norm EN 16931. Eine PDF-Datei per E-Mail erfüllt diese Anforderung nicht und gilt als sonstige Rechnung. In Deutschland sind XRechnung und ZUGFeRD verbreitet, im grenzüberschreitenden Austausch kommt Peppol BIS Billing hinzu. In Europa entsteht dabei kein einheitliches Bild. Italien hat die E-Rechnung bereits 2019 über die staatliche Plattform SdI verpflichtend eingeführt, Rumänien folgte 2024. Seit 2026 gelten Pflichten in Belgien über das Peppol-Netzwerk und in Polen über die staatliche Plattform KSeF. Frankreich führt die Pflicht seit September 2026 schrittweise über staatlich zugelassene Plattformen ein, Spanien folgt voraussichtlich ab 2027. In Österreich ist die E-Rechnung bislang nur gegenüber Bundesbehörden verpflichtend. Die EU-Initiative ViDA (VAT in the Digital Age) vereinheitlicht die Vorgaben für den grenzüberschreitenden Rechnungsaustausch: Ab dem 1. Juli 2030 werden E-Rechnungen und digitale Meldepflichten für innergemeinschaftliche B2B-Umsätze verbindlich, bis 2035 sollen nationale Meldesysteme an das EU-Modell angeglichen werden.

Der strukturierte Datensatz ist damit der führende Teil der Rechnung, alle umsatzsteuerlichen Pflichtangaben müssen dort vollständig enthalten sein. In Projekten sehe ich den größten Aufwand deshalb selten beim Format. Er liegt in den Stammdaten im ERP-System, also in Steuerkennzeichen, Bestellreferenzen und Mengeneinheiten, und vor allem in den Geschäftsfällen: Anzahlungs- und Schlussrechnungen, Sammelrechnungen mit Bezug auf einzelne Auftragspositionen, Gutschriften und Korrekturen müssen im strukturierten Datensatz korrekt abgebildet werden.

Dazu kommen fachliche Anforderungen, die in keinem Formatstandard stehen. In Frankreich muss jede Rechnung zum Beispiel als Lieferung, Dienstleistung oder gemischter Umsatz gekennzeichnet sein. Diese Einordnung muss fachlich vorbereitet und im Prozess verankert werden. Unternehmen mit Auslandsgesellschaften und gemischten B2B-, B2C- und B2G-Geschäften müssen unterschiedliche Netzwerke und Plattformen ansprechen. Branchenvorgaben wie die Marktkommunikation nach dem Energiewirtschaftsgesetz folgen eigenen Formaten und sind nicht auf EN 16931 ausgelegt. Hier braucht es Brücken zwischen den Regelwerken. All das ist umsetzbar, lässt sich aber nicht eins zu eins übernehmen. Gesetzliche Vorgaben müssen in fachliche Prozesse übersetzt werden, und dieser Aufwand wird oft unterschätzt.

Wo Insellösungen entstehen

Insellösungen entstehen meist entlang der Fristen. 2025 kam ein Empfangsportal oder ein Postfach mit Konverter hinzu, 2027 folgt ein Versandmodul im ERP-System, für einzelne Großkunden bestehen seit Jahren EDI-Verbindungen. Jede dieser Komponenten bringt eigene Formatlogik, eigene Prüfregeln und eine eigene Fehlerbehandlung mit. 58 Prozent der Unternehmen geben laut Bitkom an, ihre Prozesse in Buchhaltung, Finanzen und Controlling weitestgehend oder vollständig digitalisiert zu haben. Parallele Rechnungsstrecken unterbrechen diese Durchgängigkeit an der Schnittstelle zu Kunden und Lieferanten.

Die Formatfrage ist in den meisten Projekten schnell gelöst. Aufwendig wird es bei den Fragen, wer Validierungsfehler bearbeitet, wie Anhänge der richtigen Rechnung zugeordnet werden und wie der Status zurück ins ERP-System kommt. Diese Logik gehört für mich in eine Schicht und nicht in drei.

Drei Architekturwege für die E-Rechnung im Vergleich

Für die Umsetzung sehe ich drei Architekturwege. Sie unterscheiden sich darin, wo Formatkonvertierung, Validierung und Kanalanbindung liegen und wie weit die Automatisierung über die reine Compliance hinausreicht.

Die Wege lassen sich kombinieren. In vielen Landschaften bleibt das ERP-System für Buchung und Stammdaten führend, eine Integrationsplattform übernimmt Konvertierung, Validierung, Versand und Monitoring für alle angebundenen Systeme. Welcher Weg passt, entscheidet sich weniger an der Technik als an den Prozessen. Bei der Auswahl prüfe ich deshalb:

• welche Rechnungsfälle im Unternehmen tatsächlich vorkommen und wie die Prozesse dahinter laufen,
• welche Geschäftsbereiche betroffen sind (B2B, B2C, B2G),
• in welchen Ländern und Gesellschaften Rechnungen entstehen und welche Fristen dort gelten,
• wie viele ERP-Systeme, Netzwerke und Partnerkanäle angebunden werden müssen, einschließlich bestehender EDI-Verbindungen,
• welche Volumina und Lastspitzen zu erwarten sind, etwa beim Monatsabschluss,
• wo Rechnungsdaten gespeichert, verarbeitet und revisionssicher archiviert werden.

Oft analysieren wir dafür einen repräsentativen Datenauszug aus der Produktivumgebung. So wird schnell sichtbar, welche Rechnungsfälle es wirklich gibt und wo Stammdaten oder Pflichtangaben fehlen, bevor das Projekt startet.

Von der Compliance zur automatisierten Rechnungsverarbeitung

Strukturierte Rechnungsdaten sind die Voraussetzung für Rechnungsautomatisierung im Eingang. Liegen Positionsdaten, Bestellnummern und Steuerinformationen maschinenlesbar vor, werden Eingangsrechnungen automatisch gegen Bestellung und Wareneingang abgeglichen, kontiert und zur Freigabe weitergeleitet. Im Ausgang liefert das ERP-System die Rechnungsdaten. Je nach Architektur erzeugt es die E-Rechnung selbst, oder eine Integrationsplattform übernimmt diesen Schritt: Sie überführt die Daten über eine Schnittstelle in das jeweils geforderte Format, ob XRechnung, ZUGFeRD, Peppol BIS oder EDI, prüft sie und stellt sie je nach Land und Empfänger über das passende Netzwerk zu, etwa Peppol, eine staatliche Plattform oder E-Mail. Rechnungsaussteller bleibt dabei steuerlich immer das Unternehmen selbst, die Plattform erzeugt und versendet die E-Rechnung in seinem Auftrag.

Ein Thema, das in vielen Projekten unterschätzt wird, sind Rechnungsanhänge, im Ausgang wie im Eingang. Lieferscheine, Leistungsnachweise, Stundenzettel oder AGB müssen der richtigen Rechnung zugeordnet werden, teils eingebettet in den strukturierten Datensatz, teils als separates Dokument. Im Ausgang stammen sie selten aus einem System, sondern aus ERP, Fachanwendungen oder einem DMS. Im Eingang müssen sie aus der E-Rechnung ausgelesen und dem Beleg im ERP-System zugeordnet werden. Das DMS spielt in beiden Richtungen eine zentrale Rolle: Ein- und Ausgangsrechnungen müssen samt strukturiertem Datensatz und Anhängen GoBD-konform und revisionssicher archiviert werden.

Für mich endet der Rechnungsprozess deshalb nicht mit dem Versand. Statusmeldungen, Mahnwesen, Archivierung und Reporting hängen an denselben Daten. Wer die E-Rechnung als Integrationsprojekt plant, automatisiert diese Schritte gleich mit.

E-Rechnung umsetzen: drei Prinzipien

Drei Prinzipien wende ich in jedem E-Rechnungsprojekt an:

01 Formatlogik vom ERP-System entkoppeln. Konvertierung und Validierung liegen in einer eigenen Integrationsschicht. Neue Formate, weitere Länder oder ViDA-Anforderungen werden dort ergänzt, ohne Eingriff in das ERP-System.

02 Vor Versand und Buchung validieren. Prüfregeln nach EN 16931 und länderspezifischen Vorgaben laufen automatisch. Fehlerhafte Rechnungen landen mit Prüfbericht bei einer klar benannten Stelle, bevor sie Kunden erreichen oder in die Buchhaltung gelangen.

03 Monitoring und Verantwortung festlegen. Jede Rechnung ist im Prozessverlauf nachvollziehbar, Status und Fehler fließen ins ERP-System zurück. Fachbereich, IT und Betrieb teilen die Verantwortung entlang definierter Schnittstellen. Die GoBD-konforme Archivierung ist Teil desselben Prozesses.

Die E-Rechnung als Teil der Integrationsarchitektur

Die E-Rechnung Pflicht 2027 betrifft zunächst den Rechnungsversand. Unternehmen, die Eingang, Ausgang und Partneranbindung über eine zentrale Integrationsschicht abbilden, reduzieren die Zahl der Schnittstellen und schaffen die Grundlage für automatisierte Rechnungsverarbeitung über Länder und ERP-Systeme hinweg.

Am Anfang steht eine Bestandsaufnahme der heutigen Rechnungskanäle, Formate und Systeme. Ein E-Rechnungsprojekt ist für mich dann erfolgreich, wenn Rechnungen schneller, zuverlässiger und mit weniger manuellem Aufwand verarbeitet werden. Dafür braucht es klare Prozesse, eine saubere Systemintegration und möglichst wenige Fehlerquellen. Weitere Informationen zu Formaten, ERP-Anbindung und Betrieb bietet die Seite zu E-Invoicing und Invoice Automation.