E-Rechnung in SAP: Warum das XML nur der Anfang ist

Mit der E-Rechnung stehen viele SAP-Unternehmen vor der Frage: Wie wird aus einer SAP-Rechnung eine gesetzeskonforme E-Rechnung?

Auf den ersten Blick scheint es vor allem um das richtige Format zu gehen: Daten bereitstellen, XML erzeugen, Rechnung versenden. Doch das eigentliche Problem ist nicht das XML.

Die Herausforderung beginnt dort, wo neue regulatorische Anforderungen auf bestehende SAP-Prozesse treffen. Denn die benötigten Daten müssen vollständig und in der richtigen Form zur Verfügung stehen.

Nachdem wir in unserem Beitrag „E-Rechnungspflicht 2027: Was SAP-Unternehmen jetzt wissen müssen“ die rechtlichen Anforderungen eingeordnet haben, geht es diesmal um die technische Praxis: Wo entsteht die eigentliche Komplexität in SAP?

Warum die E-Rechnung in SAP komplexer ist als ein XML

Viele Unternehmen erzeugen ihre Rechnungen seit Jahren über etablierte SAP-Prozesse. Mit der E-Rechnung werden nun zusätzliche Informationen benötigt oder vorhandene Daten müssen anders bereitgestellt werden.

Dann stellen sich schnell ganz praktische Fragen: Wo steht die Bestellreferenz? Woher kommt das Leistungsdatum? Wie werden steuerliche Sonderfälle behandelt? Was passiert mit Anlagen? Und wie werden Gutschriften oder Korrekturen abgebildet?

Die Informationen dafür sind im SAP-System häufig vorhanden. Sie liegen aber nicht bei jedem Unternehmen an derselben Stelle und nicht immer in der Form vor, in der sie für die E-Rechnung benötigt werden.

Genau deshalb greift die Betrachtung des XML-Formats allein zu kurz.

Das XML steht am Ende eines Prozesses. Die eigentliche Arbeit beginnt vorher: bei den Daten und den Geschäftsprozessen, aus denen diese Daten entstehen.

Der Happy Flow ist deshalb selten das Problem. Die realen Geschäftsprozesse sind es.

Drei Wege zur E-Rechnung – und wo die Komplexität entsteht

Für die technische Umsetzung gibt es unterschiedliche Ansätze. Unternehmen können beispielsweise mit einem externen Dienstleister arbeiten, eine eigene Lösung entwickeln oder auf eine standardnahe SAP-Lösung wie SAP Document and Reporting Compliance setzen.

Alle drei Wege können funktionieren. Die entscheidende Frage ist jedoch, wo die notwendige Komplexität am Ende liegt und wer sie dauerhaft beherrschen muss.

Externe Lösung: Wenn das IDoc immer weiter wächst

Viele SAP-Unternehmen übergeben ihre Rechnungsdaten beispielsweise über das INVOIC02-IDoc an einen externen Dienstleister. Dieser übernimmt anschließend die länderspezifische Verarbeitung, die Umwandlung in das benötigte Zielformat und die Übertragung.

Das kann Aufgaben aus dem SAP-System verlagern. Die benötigten Geschäftsdaten müssen trotzdem zunächst aus SAP kommen.

Fehlen im IDoc Informationen, die der externe Dienstleister benötigt, liegt eine Lösung nahe: Das IDoc wird erweitert. Neue Segmente kommen hinzu, weitere Felder werden ergänzt, Qualifier angelegt und zusätzliche Logik implementiert.

Technisch ist das alles möglich. Mit jedem weiteren Land kann der Umfang jedoch wachsen. Für Ungarn wurden bei Kunden beispielsweise bereits zusätzliche Segmente, Felder und Qualifier benötigt. Für Polen kamen weitere Anforderungen hinzu. Mit Deutschland entstehen erneut neue Datenbedarfe.

Aus einem etablierten Standard-IDoc wird dadurch schrittweise ein immer stärker kundenspezifisch erweiterter Datenträger. Jede dieser Erweiterungen muss dokumentiert, getestet und langfristig gewartet werden.

Die entscheidende Frage lautet deshalb nicht nur: Können wir das IDoc erweitern?

Sondern auch: Wollen wir unser SAP-System bei jeder neuen regulatorischen Anforderung erneut erweitern?

Eigenentwicklung: Warum der reine E-Mail-Versand zu kurz greift

Auch eine Eigenentwicklung ist ein möglicher Weg. Für einen klar begrenzten deutschen Anwendungsfall kann es zunächst überschaubar erscheinen, die benötigten Rechnungsdaten selbst aufzubereiten, das entsprechende Format zu erzeugen und die Rechnung anschließend per E-Mail zu versenden.

Die Herausforderung endet allerdings nicht beim Versand einer Datei.

Auch Datenbeschaffung und Mapping, Validierung, Statusverarbeitung oder digitale Meldeprozesse müssen berücksichtigt werden. Entwicklungen wie ViDA zeigen zudem, dass es je nach Land und Geschäftsszenario künftig um mehr gehen kann als den reinen Austausch einer Rechnungsdatei.

Je mehr Länder, Formate und Prozesse hinzukommen, desto mehr individuelle Logik muss eine Eigenentwicklung abbilden. Was für einen einzelnen Anwendungsfall zunächst pragmatisch wirkt, kann deshalb langfristig zu einem dauerhaften Entwicklungs- und Wartungsthema für die SAP-Abteilung werden.

SAP DRC: Standardnah, aber nicht ohne Aufwand

Eine Alternative zu individuellen Länderentwicklungen ist eine standardnahe Lösung wie SAP Document and Reporting Compliance (SAP DRC).

Der wesentliche Vorteil liegt auf der Hand: Unternehmen bleiben nah am SAP-Standard. Das bedeutet jedoch nicht, dass Einführung und Betrieb ohne zusätzlichen Aufwand auskommen.

Es braucht Mitarbeiter oder Dienstleister, die SAP DRC, die jeweiligen Länderszenarien und die zugrunde liegenden SAP-Prozesse kennen. Auch kundenspezifische Anforderungen verschwinden nicht vollständig. Je nach Szenario können beispielsweise BAdIs notwendig sein, um zusätzliche Daten bereitzustellen oder individuelle Prozesse abzubilden.

Hinzu kommt die technische Pflege. Für neue Länder, Funktionen oder Fehlerkorrekturen müssen SAP-Hinweise eingespielt werden. Dabei können weitere Abhängigkeiten entstehen. Je nach Systemstand und Szenario können im Einzelfall 50 oder mehr abhängige SAP-Hinweise zusammenkommen, die anschließend eingespielt und getestet werden müssen.

Gerade bei mehreren SAP-Systemen kann daraus ein erheblicher Aufwand entstehen.

Das spricht nicht gegen SAP DRC. Die Standardnähe bleibt ein klarer Vorteil. Es zeigt jedoch, dass auch eine Standardlösung einem Unternehmen die organisatorische und technische Verantwortung für das Thema E-Rechnung nicht vollständig abnimmt.

Die entscheidende Frage: Wo soll die Komplexität liegen?

Ob externe Lösung, Eigenentwicklung oder SAP DRC: Die regulatorischen Anforderungen verschwinden durch die Wahl einer technischen Lösung nicht.

Damit stellt sich eine grundlegendere Frage: Wie viel dieser Komplexität sollte eigentlich im SAP-System liegen?

Natürlich lassen sich IDocs erweitern, BAdIs implementieren und SAP-Hinweise einspielen. Auch zusätzliche Logik für weitere Länder kann im SAP-System abgebildet werden.

Gleichzeitig verfolgen viele Unternehmen im Zuge von S/4HANA und Clean Core jedoch das gegenteilige Ziel: den SAP-Kern möglichst schlank und beherrschbar zu halten.

Genau daraus ergibt sich für uns ein wichtiger Grundsatz:

Nicht jede regulatorische Änderung sollte automatisch eine Änderung im SAP-System auslösen.

Die E-Rechnung ist dabei ein gutes Beispiel. Denn die Geschäftsdaten entstehen zwar in SAP. Die regulatorischen Anforderungen an Verarbeitung, Format und Übertragung unterscheiden sich jedoch von Land zu Land und können sich im Laufe der Zeit verändern.

Geschäftsdaten aus SAP, Länderlogik außerhalb des SAP-Kerns

Eine mögliche Trennung besteht deshalb darin, SAP auf seine zentrale Aufgabe in diesem Prozess zu konzentrieren: die benötigten Geschäftsdaten bereitzustellen.

Die länderspezifische Interpretation dieser Daten, ihre Validierung, die Konvertierung in das jeweilige Format und die anschließende Übertragung müssen dagegen nicht zwangsläufig vollständig im SAP-Kern stattfinden.

Damit wird die regulatorische Logik stärker von den eigentlichen SAP-Prozessen entkoppelt.

Das ist besonders mit Blick auf weitere Länder und neue Anforderungen relevant. Denn der 1. Januar 2027 in Deutschland ist nicht das Ende der Entwicklung. Bestehende Vorgaben können sich ändern, weitere Länder kommen hinzu und auch auf europäischer Ebene entwickeln sich Rechnungs- und Meldeprozesse weiter.

Die technische Architektur sollte deshalb nicht nur die aktuelle deutsche Anforderung lösen. Sie sollte auch berücksichtigen, was passiert, wenn sich die nächste regulatorische Vorgabe ändert.

Warum wir die Global E-Invoice Cloud entwickelt haben

Genau diese Erfahrungen waren ein wesentlicher Grund dafür, dass wir bei Softway begonnen haben, die Global E-Invoice Cloud (GEC) zu entwickeln.

Die Ausgangsfrage war dabei nicht einfach: Wie bauen wir noch eine E-Rechnungslösung?

Viel wichtiger war für uns die Frage: Wie können neue Anforderungen erfüllt werden, ohne bei jeder regulatorischen Änderung wieder tief in die SAP-Systeme unserer Kunden eingreifen zu müssen?

Unser Ziel ist deshalb, möglichst viel der länderspezifischen und regulatorischen Komplexität vom SAP-Kern zu entkoppeln. SAP stellt die benötigten Geschäftsdaten bereit. Die weitere Verarbeitung kann außerhalb des Kerns erfolgen.

Ganz ohne Blick auf die individuellen Prozesse eines Unternehmens funktioniert auch dieser Ansatz nicht. Denn die benötigten Daten und Abläufe unterscheiden sich je nach SAP-Landschaft und Geschäftsszenario.

Unser Anspruch lautet deshalb: So viel Standardisierung wie möglich, so viel Flexibilität wie nötig.

Deutschland ist der Anlass – nicht das Ende

Aktuell sorgt vor allem die E-Rechnung in Deutschland dafür, dass viele Unternehmen ihre bestehenden Prozesse und SAP-Systeme überprüfen.

Langfristig ist jedoch eine andere Frage entscheidend: Wie stellen wir unsere SAP-Landschaft heute so auf, dass das nächste Land, die nächste regulatorische Änderung oder eine neue technische Anforderung nicht wieder zu einem eigenen SAP-Projekt wird?

Genau deshalb lohnt es sich, bei der E-Rechnung nicht nur über XML-Formate und den 1. Januar 2027 zu sprechen. Ebenso wichtig ist die Frage, welche Aufgaben dauerhaft im SAP-Kern liegen sollen – und welche sich sinnvoll davon entkoppeln lassen.

Im nächsten Beitrag betrachten wir die Situation in Deutschland zum 1. Januar 2027 und den Ausblick auf ViDA zum 1. Juli 2030. Dabei ordnen wir ein, welche Entwicklungen SAP-Unternehmen für ihre E-Rechnungsprozesse im Blick behalten sollten.