„E‑Rechnungsprojekte scheitern selten an XML. Sie scheitern daran, dass Unternehmen ihren eigenen Rechnungsausgang nicht mehr vollständig verstehen – und erwarten, Compliance technisch einkaufen zu können.“

Die E‑Rechnung wird noch immer häufig als technisches Umsetzungsprojekt betrachtet: Ein neues Dateiformat muss erzeugt, eine Schnittstelle eingerichtet und ein Übertragungsweg angebunden werden. Danach, so die Erwartung, ist das Unternehmen gesetzeskonform.

Diese Sichtweise greift zu kurz.

E‑Invoicing ist weder ein reiner Formatwechsel noch ein isoliertes IT-Projekt. Es ist ein unternehmensweites Tax-, Compliance- und Transformationsprojekt, das mit der Rechnungsstellung einen der geschäftskritischsten Prozesse eines Unternehmens betrifft.

Denn erstmals seit langer Zeit müssen viele Unternehmen nicht nur ihre technische Rechnungserzeugung verändern. Sie müssen zunächst wieder verstehen, warum ihre Rechnungen heute so aussehen, welche fachlichen Entscheidungen dahinterstehen und wie diese technisch umgesetzt wurden.

Andere Länder mussten handeln – Deutschland glaubte, noch Zeit zu haben

In mehreren europäischen Ländern waren die gesetzlichen Einführungsfristen äußerst knapp. Gleichzeitig waren staatliche Portale, Spezifikationen und technische Übertragungswege teilweise noch nicht vollständig ausgereift.

Das führte dazu, dass Dienstleister und Unternehmen nahezu parallel in die Umsetzung gingen: Die Dienstleister entwickelten Formate, Schnittstellen und Anbindungen, während die Unternehmen ihre fachlichen Prozesse, steuerlichen Anforderungen und organisatorischen Verantwortlichkeiten konkretisierten.

Nach unserer Projekterfahrung waren viele dieser international tätigen Unternehmen trotz des hohen Zeitdrucks fachlich gut vorbereitet. Anforderungen wurden konkret formuliert, Tax- und Compliance-Bereiche waren eingebunden und die Verantwortung für einzelne Geschäftsvorfälle war vergleichsweise klar geregelt.

In Deutschland zeigt sich häufig ein anderes Bild. Die Übergangsfristen wurden vielerorts nicht als notwendige Vorbereitungszeit, sondern als Aufschub verstanden. Viele Unternehmen beginnen deshalb erst jetzt damit, sich ernsthaft mit ihrem Rechnungsausgang und den zugrunde liegenden Daten auseinanderzusetzen.

Dabei ist die Entwicklung längst im Gange: Seit dem 1. Januar 2025 müssen inländische Unternehmen grundsätzlich E‑Rechnungen empfangen können. Ein einfaches PDF gilt seitdem nicht mehr als E‑Rechnung, sondern als „sonstige Rechnung“. Bis Ende 2026 dürfen Rechnungsaussteller noch allgemein von den Übergangsregelungen Gebrauch machen. Für Unternehmen mit einem Vorjahresumsatz von höchstens 800.000 Euro verlängert sich diese Möglichkeit bis Ende 2027. Nach Ablauf dieser Übergangsfristen wird die E‑Rechnung für die grundsätzlich betroffenen inländischen B2B-Umsätze verpflichtend; gesetzliche Ausnahmen bleiben bestehen. (Bundesministerium der Finanzen)

Der Rechnungsausgang ist in vielen Unternehmen zur Blackbox geworden

Eine der größten Herausforderungen beginnt noch vor der eigentlichen E‑Rechnung.

In vielen Unternehmen fehlt heute nicht nur das Wissen über EN 16931, XRechnung, ZUGFeRD, Peppol oder nationale Meldesysteme. Teilweise ist bereits das fachliche und technische Verständnis des bestehenden Rechnungsausgangs verloren gegangen.

Die Rechnungserstellung wurde vor Jahren oder sogar Jahrzehnten einmal fachlich abgestimmt, technisch eingerichtet und anschließend einfach genutzt. Solange Rechnungen erzeugt, versendet, bezahlt und verbucht wurden, galt der Prozess als funktionierend.

Im operativen Kern vieler Unternehmen änderten sich die grundlegenden Abläufe der Rechnungsschreibung über lange Zeiträume nur wenig. Entsprechend selten wurde hinterfragt, warum eine Rechnung bestimmte Angaben enthält, aus welchem System diese stammen oder welche technische Logik im Hintergrund greift.

Über die Jahre wurden zusätzlich Sonderfälle, individuelle Formulare, kundenspezifische Anforderungen, manuelle Ergänzungen und technische Ausnahmen eingebaut. Gleichzeitig wechselten Mitarbeitende, externe Berater und Systemverantwortliche. Dokumentationen wurden nicht immer vollständig fortgeführt.

Das Ergebnis: Unternehmen können teilweise nicht mehr belastbar erklären,

• warum bestimmte Angaben auf einer Rechnung erscheinen,
• aus welcher Datenquelle sie stammen,
• wie einzelne Geschäftsvorfälle steuerlich abgebildet werden,
• welche Regeln hinter Steuerkennzeichen und Rechnungsarten liegen,
• welche Sonderlogiken im ERP-System oder in der Formularerzeugung greifen,
• und wer für diese Entscheidungen fachlich verantwortlich ist.

Solange ein Mensch eine PDF-Rechnung betrachtet, können Unklarheiten teilweise durch Erfahrung, Kontext oder manuelle Nachfragen ausgeglichen werden. Bei strukturierten Rechnungsdaten funktioniert das nicht. Informationen müssen eindeutig definiert, semantisch korrekt zugeordnet und maschinenlesbar bereitgestellt werden. Genau darin liegt der Kern der EN 16931: Sie definiert nicht nur technische Felder, sondern die Bedeutung zentraler Rechnungsinformationen und die dazugehörigen Geschäftsregeln. (European Commission)

Die E‑Rechnung erzeugt dieses Wissensdefizit also nicht. Sie macht es sichtbar.

Das schöne PDF ist nicht die Compliance

Viele deutsche Unternehmen konzentrieren sich zunächst weiterhin auf die sichtbare Rechnung: Logo, Schriftart, Seitenaufteilung, Positionstabellen und das gewohnte Erscheinungsbild sollen möglichst unverändert bleiben.

Eine gute menschliche Darstellung ist weiterhin sinnvoll. Sie ist aber nicht der entscheidende Maßstab für die E‑Rechnungs-Compliance.

Seit dem 1. Januar 2025 liegt eine E‑Rechnung nur dann vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Ein einfaches PDF erfüllt diese Voraussetzung nicht. (Bundesministerium der Finanzen)

Besonders deutlich wird der Paradigmenwechsel bei hybriden Formaten wie ZUGFeRD. Weichen der sichtbare PDF-Teil und die eingebetteten strukturierten Daten voneinander ab, sind inzwischen die Daten des strukturierten Teils maßgeblich. Das für den Menschen sichtbare Rechnungsbild ist damit nicht länger automatisch die führende Information. (Bundesministerium der Finanzen)

Unternehmen müssen deshalb ihre Prioritäten verändern. Die zentrale Frage lautet nicht mehr:

Sieht die neue Rechnung genauso aus wie die alte?

Sondern:

Bilden die strukturierten Daten den tatsächlichen Geschäftsvorfall vollständig, eindeutig und regelkonform ab?

E‑Invoicing ist ein unternehmensweites Tax- und Compliance-Projekt

Ein B2B-Unternehmen, das seinen eigenen Rechnungsausgang fachlich oder technisch nicht vollständig erklären kann, muss zeitnah handeln.

Vor der technischen Anbindung müssen zunächst die vorhandenen Rechnungsprozesse aufgenommen werden. Dazu gehören insbesondere die unterschiedlichen Rechnungsarten, Geschäftsvorfälle, Quellsysteme, Steuerlogiken, Datenherkünfte, Korrekturprozesse, Sonderfälle und manuellen Eingriffe.

Das kann nicht allein durch die IT erfolgen. Benötigt werden mindestens das Wissen und die Entscheidungen aus Tax, Finance, Vertrieb, Stammdatenmanagement, IT sowie den jeweils betroffenen operativen Fachbereichen.

Dabei muss geklärt werden:

Welche Geschäftsvorfälle existieren? Wie werden sie steuerlich behandelt? Welche Rechnungsangaben werden benötigt? Woher kommen diese Informationen? Sind sie im Quellsystem strukturiert verfügbar? Welche Angaben werden heute erst in der Formularlogik erzeugt? Welche Kundenvorgaben bestehen? Welche nationalen Besonderheiten müssen berücksichtigt werden? Und wer entscheidet verbindlich, wie ein Sonderfall künftig abgebildet wird?

Diese Fragen können nicht an einen technischen Dienstleister delegiert werden.

Nach unserer Erfahrung kann bereits der Aufbau eines belastbaren E‑Invoicing-Verständnisses bei einzelnen verantwortlichen Personen ein bis zwei Monate beanspruchen. Dieses Wissen anschließend im gesamten Unternehmen zu verankern, dauert deutlich länger.

Positiv ist: Sobald ein Unternehmen das Projekt ernsthaft begonnen, die richtigen Fachbereiche eingebunden und klare Verantwortlichkeiten geschaffen hat, ist die Lernkurve meist steil. Datenprobleme werden sichtbar, Abhängigkeiten verständlich und Entscheidungen konkreter.

Fehlt dieses Grundverständnis jedoch zu Projektbeginn, werden Anforderungen erst während des Mappings, der Validierung oder der Tests entdeckt. Aus vermeintlich technischen Fehlern entstehen dann fachliche Rückfragen, neue Sonderfälle und wiederholte Anpassungsschleifen.

Die daraus resultierenden Verzögerungen werden häufig dem Dienstleister zugeschrieben. Tatsächlich liegt ihre Ursache aber oft in einem Rechnungsausgang, der im Unternehmen selbst nicht mehr vollständig verstanden wird.

Compliance kann unterstützt, aber nicht eingekauft werden

Eine der häufigsten Fehlannahmen lautet: Wenn ein E‑Rechnungsdienstleister beauftragt wurde, übernimmt dieser automatisch die vollständige Compliance.

Das ist nicht die Rolle des Dienstleisters.

Ein Dienstleister kann Quellsysteme anbinden, Daten normalisieren, Rechnungsformate erzeugen, Geschäftsregeln technisch prüfen, länderspezifische Validierungen durchführen, Übertragungswege bedienen und Verarbeitungsstatus überwachen.

Er kann beispielsweise feststellen, dass eine Pflichtangabe fehlt, ein Code nicht zulässig ist, eine Berechnung nicht den implementierten Regeln entspricht oder ein Zielformat technisch nicht valide ist.

Er kann aber nicht ohne fachliche Informationen des Unternehmens wissen,

• ob der zugrunde liegende Geschäftsvorfall richtig bewertet wurde,
• ob die steuerliche Behandlung tatsächlich zutrifft,
• ob eine Steuerbefreiung sachlich berechtigt ist,
• ob ein Rechnungsadressat korrekt bestimmt wurde,
• ob die Leistungsbeschreibung den tatsächlichen Sachverhalt wiedergibt,
• oder ob die aus dem ERP-System gelieferten Daten inhaltlich vollständig sind.

Die Europäische Kommission stellt bei der EN 16931 ausdrücklich auf die Verantwortung des Rechnungsausstellers ab, die Übereinstimmung des Rechnungsinhalts mit den Spezifikationen sicherzustellen. Technische Validierungsartefakte unterstützen diese Prüfung im Entwicklungs- und im laufenden Betrieb. Auch das Bundesfinanzministerium empfiehlt eine Validierung bei der Erstellung und dem Versand, weist aber zugleich darauf hin, dass sie allein keine steuerliche Anerkennung garantiert. (European Commission)

Die entscheidende Abgrenzung lautet daher:

Der Dienstleister stellt die technische Befähigung bereit. Das Unternehmen bleibt für Geschäftsvorfall, Rechnungsinhalt und steuerliche Bewertung verantwortlich.

Oder noch einfacher:

Aus unvollständigen oder fachlich falschen Quelldaten kann auch die beste Plattform keine korrekte Rechnung erzeugen.

Wie eDNA die technische Komplexität beherrschbar macht

An genau dieser Grenze setzt xSuite eDNA an.

eDNA übernimmt nicht die fachliche Entscheidung des Kunden, sondern schafft eine technische Integrations-, Transformations- und Validierungsschicht zwischen den angebundenen Quellsystemen und den jeweils erforderlichen Rechnungsformaten und Übertragungswegen.

Rechnungsdaten werden aus den Quellsystemen über definierte Schnittstellen und produktspezifische Connectoren übernommen und in einem normalisierten Rechnungsmodell verarbeitet. Dadurch muss nicht jedes ERP-System sämtliche länderspezifischen Zielformate und Übertragungsverfahren selbst vollständig implementieren.

Die Prüfung erfolgt mehrstufig:

Zunächst wird kontrolliert, ob die für die Verarbeitung notwendigen Daten im normalisierten Rechnungsmodell vorhanden und technisch plausibel sind. Anschließend wird das Dokument in das erforderliche Zielformat transformiert und gegen die Regeln der EN 16931 beziehungsweise die zugehörigen Business Rules geprüft. Darauf folgen – abhängig vom jeweiligen Ziel – zusätzliche Validierungen gegen nationale oder netzwerkspezifische Vorgaben.

Nach erfolgreicher Verarbeitung wird die Rechnung über den konfigurierten Übertragungsweg bereitgestellt oder versendet. Statusinformationen und technische Fehler können im eDNA WebClient und, abhängig von der jeweiligen Integration, auch im angebundenen Quellsystem nachvollzogen werden.

Dadurch unterstützt eDNA Unternehmen insbesondere dabei,

• unterschiedliche Quellsysteme technisch anzubinden,
• Rechnungsdaten zentral zu normalisieren,
• Formate und Ländervarianten zu entkoppeln,
• technische und regelbasierte Fehler frühzeitig zu erkennen,
• Übertragungswege zentral zu steuern,
• und Verarbeitungsstatus transparent nachzuverfolgen.

Diese technische Unterstützung reduziert Komplexität und verkürzt die Fehlersuche. Sie ersetzt jedoch nicht die fachliche Analyse des Rechnungsausgangs.

eDNA kann sichtbar machen, dass eine Information fehlt oder gegen eine implementierte Regel verstößt. Die Plattform kann aber nicht selbst rekonstruieren, warum ein Unternehmen einen Geschäftsvorfall seit Jahren auf eine bestimmte Weise abrechnet oder ob diese Vorgehensweise steuerlich weiterhin richtig ist.

Genau diese klare Arbeitsteilung ist entscheidend für ein erfolgreiches Projekt.

Was Unternehmen in der Praxis unterschätzen

Unternehmen unterschätzen häufig nicht die reine Implementierungsdauer einer Schnittstelle, sondern die Vorarbeiten, die notwendig sind, damit diese Schnittstelle fachlich richtige Daten liefern kann.

Besonders häufig werden vier Themen zu spät erkannt:

Erstens wird das Projekt als Aufgabe der IT eingeordnet, obwohl ein erheblicher Teil der notwendigen Entscheidungen aus Tax, Finance und den operativen Fachbereichen kommen muss.

Zweitens wird davon ausgegangen, dass der bestehende Rechnungsausgang bereits sauber dokumentiert und fachlich eindeutig ist. In der Projektarbeit zeigt sich dann, dass historische Logiken, Sonderprozesse und manuelle Eingriffe zunächst rekonstruiert werden müssen.

Drittens konzentriert sich die Aufmerksamkeit auf das sichtbare Rechnungsbild, während Datenqualität, semantische Zuordnung und maschinenlesbare Pflichtinformationen nachrangig behandelt werden.

Viertens wird erwartet, dass der Dienstleister fachliche und steuerliche Entscheidungen aus dem bestehenden Rechnungsbild oder aus unvollständigen ERP-Daten ableiten kann.

Diese Fehleinschätzungen führen zu Verzögerungen. Nicht weil die technische Plattform grundsätzlich nicht funktioniert, sondern weil die Voraussetzungen für eine eindeutige technische Umsetzung fehlen.

2028 endet die Übergangsphase – nicht der Markt

Ab 2028 wird die E‑Rechnung für die grundsätzlich betroffenen inländischen B2B-Umsätze verbindlich. Das bedeutet jedoch nicht, dass der Markt für E‑Rechnungsdienstleistungen anschließend verschwindet.

Im Gegenteil: Er verändert sich.

Heute lässt sich der Markt weniger eindeutig mit Begriffen wie Polypol oder Oligopol beschreiben als über die aktuelle Verteilung der Verhandlungsmacht. Hoher Zeitdruck, parallele Länderanforderungen, begrenzte Umsetzungskapazitäten und knappes Fachwissen führen in vielen Segmenten zu einem Anbietermarkt.

Unternehmen benötigen kurzfristig technische Lösungen und qualifizierte Unterstützung. Dienstleister können ihre verfügbaren Kapazitäten nur begrenzt ausweiten. Dadurch bestimmt aktuell häufig das Angebot, welche Projekte in welcher Geschwindigkeit umgesetzt werden können.

Nach 2028 dürfte sich diese Situation schrittweise verändern. Standardleistungen wie einfache Formatkonvertierung, Validierung und Übertragung werden vergleichbarer. Mehr Unternehmen werden produktive Lösungen besitzen, die unmittelbare Deadline entfällt und neue Anbieter beziehungsweise standardisierte Angebote erhöhen den Wettbewerbsdruck.

In diesen standardisierten Bereichen wird sich der Markt voraussichtlich stärker in Richtung eines Wettbewerbs- und teilweise Käufermarktes entwickeln. Kunden werden Preise, Servicequalität, internationale Abdeckung, Integrationsfähigkeit und Betriebsmodelle genauer vergleichen können.

Der Gesamtbedarf wird dadurch jedoch nicht zwangsläufig kleiner. Er verlagert sich von der einmaligen Erstbefähigung hin zum dauerhaften Betrieb.

Gefragt sein werden zunehmend:

• die Betreuung produktiver internationaler E‑Invoicing-Landschaften,
• die Anpassung an neue Länderanforderungen,
• Monitoring und Fehlerbehandlung,
• die Weiterentwicklung von Formaten und Validierungsregeln,
• die Verbesserung der Datenqualität,
• die Integration zusätzlicher Quellsysteme,
• sowie die Verbindung von E‑Invoicing und digitalem VAT Reporting.

Plattformen wie eDNA werden daher nach 2028 weniger als einmalige Konvertierungswerkzeuge und stärker als dauerhafte Integrations- und Verarbeitungsschicht benötigt. Der Wert liegt dann nicht allein darin, ein XML-Dokument zu erzeugen, sondern regulatorische und technische Veränderungen zentral beherrschbar zu machen und nicht für jede Anpassung sämtliche ERP-Systeme einzeln neu entwickeln zu müssen.

ViDA eröffnet bereits die nächste Veränderungsphase

Die deutsche E‑Rechnung ist nicht das Ende der regulatorischen Entwicklung.

Die EN 16931 ist dabei keine Verordnung, sondern ein europäischer semantischer Standard für elektronische Rechnungen. Sie definiert zentrale Rechnungsinformationen, deren Bedeutung und die zugehörigen Geschäftsregeln und wird weiterentwickelt. (European Commission)

Hinzu kommt das bereits verabschiedete EU-Reformpaket VAT in the Digital Age – ViDA. Die digitalen Meldepflichten für grenzüberschreitende B2B-Transaktionen sollen ab dem 1. Juli 2030 greifen. Bis zum 1. Januar 2035 müssen Mitgliedstaaten mit bereits bestehenden inländischen transaktionsbezogenen Echtzeit-Meldesystemen ihre Systeme an das europäische Modell und dessen Standards angleichen. (Taxation and Customs Union)

Auch das Bundesfinanzministerium beschreibt die deutsche E‑Rechnung ausdrücklich als Vorbereitung auf ein späteres zeitnahes und transaktionsbezogenes Meldesystem. Die dafür notwendigen konkreten gesetzlichen Änderungen in Deutschland stehen allerdings noch aus. (Bundesministerium der Finanzen)

Für Unternehmen bedeutet das: Wer die E‑Rechnung heute nur als gesetzlich vorgeschriebenes Ausgangsformat betrachtet, wird seine Umsetzung später erneut grundlegend hinterfragen müssen.

Wer dagegen bereits jetzt seine Geschäftsvorfälle versteht, Datenquellen bereinigt, Verantwortlichkeiten festlegt und einen strukturierten Rechnungsausgang etabliert, schafft damit zugleich eine wichtige Grundlage für kommende digitale Reporting-Anforderungen.

eDNA kann diese Grundlage technisch unterstützen, indem Rechnungsdaten strukturiert übernommen, normalisiert, validiert, transformiert und mit nachvollziehbaren Verarbeitungsstatus geführt werden. Daraus folgt jedoch nicht automatisch die Erfüllung künftiger ViDA- oder nationaler VAT-Reporting-Pflichten. Die konkrete Erzeugung und Übermittlung der jeweiligen Meldedaten bleibt ein eigener fachlicher und technischer Ausbauschritt.

Fazit: Die eigentliche Transformation beginnt vor der Schnittstelle

Die größte Herausforderung der E‑Rechnung ist nicht das XML-Format. Sie ist auch nicht das Portal, der Übertragungskanal oder die Visualisierung.

Die größte Herausforderung besteht darin, dass Unternehmen ihren Rechnungsausgang fachlich wieder vollständig verstehen, Verantwortlichkeiten neu festlegen und historisch gewachsene Prozesse in eindeutige strukturierte Daten übersetzen müssen.

Ein Dienstleister kann diesen Prozess technisch unterstützen. Er kann Daten normalisieren, Formate erzeugen, Regeln prüfen, Übertragungswege bedienen und Fehler transparent machen. Er kann dem Unternehmen aber weder die steuerliche Bewertung noch die Verantwortung für den tatsächlichen Geschäftsvorfall abnehmen.

Deshalb ist E‑Invoicing kein isoliertes IT-Projekt.

E‑Invoicing ist ein unternehmensweites Tax-, Compliance- und Transformationsprojekt, das einen der kritischsten Prozesse des Unternehmens neu ordnet.

Der Markt für entsprechende Lösungen und Dienstleistungen wird mit dem Ende der deutschen Übergangsfristen nicht verschwinden. Standardleistungen werden wettbewerbsintensiver, während der Bedarf an internationaler Skalierung, laufender Regelpflege, Datenqualität, Monitoring und digitalem Reporting weiter zunimmt.

„2028 endet nicht der E‑Rechnungsmarkt. Es endet lediglich die Phase, in der Unternehmen Compliance mit einem neuen Dateiformat verwechseln konnten.“