Wer übernimmt die Verantwortung für E‑Invoicing? Ein Stakeholder-Leitfaden für erfolgreiche E‑Invoicing- und E‑Reporting-Programme

Warum sich E‑Invoicing/E‑Reporting von früheren Compliance-Projekten unterscheidet

In den letzten Jahren hat sich die Steuer-Compliance – und damit das Verhältnis zwischen Steuerbehörden und Unternehmen – grundlegend gewandelt. Wir leben nicht mehr in einer Ära sporadischer, chargenbasierter Berichterstattung (Batch Reporting); stattdessen sprechen wir von einer vollständigen Umstrukturierung hin zum Paradigma der „Echtzeit-Compliance“ („Real-Time Compliance“).

• Von periodischen Steuererklärungen zu Continuous Transaction Controls (CTCs): Wir bewegen uns weg von retrospektiven, monatlichen oder vierteljährlichen Umsatzsteuervoranmeldungen. Steuerbehörden fordern nun Echtzeit- oder beinahe echtzeitnahe Einblicke in Ihre Rechnungsdatenflüsse. Dieser Wandel von der „Batch“-Berichterstattung hin zur transaktionsbezogenen Berichterstattung bedeutet, dass Datenqualitätsprobleme nicht mehr am Monatsende behoben werden können: Sie müssen direkt bei der Erstellung gelöst werden.

• Direkte Auswirkungen auf Kerngeschäftsprozesse: Da diese Vorgaben direkt an Ihre Transaktionssysteme angebunden sind, ist E‑Invoicing nicht bloß ein Steuerthema. Es wirkt sich direkt auf Ihre Order‑to‑Cash- (O2C), Procure‑to‑Pay- (P2P) und Record‑to‑Report-Prozesse aus. Wenn Ihre Systeme ausfallen, stoppen Ihre Zahlungen. Das ist ein kritisches Risiko für die Geschäftskontinuität und keine bloße Fußnote zur Compliance.

• Eine Herausforderung über mehrere Jurisdiktionen hinweg: Angesichts überschneidender Mandate in der EU (ViDA), im GCC, in LATAM und APAC wird ein länderspezifischer Ansatz immer riskanter. Sie benötigen eine einheitliche Strategie, da Sie sonst riskieren, unter fragmentierten, unüberschaubaren lokalen Anforderungen zu begraben zu werden, die einen enormen Aufwand für Ihre Finanzteams verursachen.

Wichtigste Erkenntnis: E‑Invoicing ist ein funktionsübergreifendes Transformationsprogramm, keine einmalige Compliance-Aufgabe. Es erfordert ein Umdenken weg von rein reaktiver Steuer-Compliance hin zur digitalen Geschäftstransformation.

Die Stakeholder-Landschaft: Wer eingebunden werden muss und warum

Da E‑Invoicing abteilungsübergreifend wirkt, erfordert es eine multidisziplinäre Taskforce von Stakeholdern, die sowohl auf die Geschäftsziele als auch auf die technische Umsetzung ausgerichtet ist. Wenn eine dieser Gruppen isoliert agiert, riskiert das Projekt entweder das Versäumen einer Compliance-Frist oder, was noch schlimmer ist, die Unterbrechung kritischer betrieblicher Abläufe.

Kern-Stakeholder-Gruppen (in allen Organisationen vertreten)

• Steuern / Indirekte Steuern / Umsatzsteuer: Als primäre Wächter der Organisation muss die Steuerabteilung Gesetzesänderungen überwachen, deren Auswirkungen bewerten sowie die Compliance-Anforderungen und die allgemeine Risikobereitschaft definieren. Ihre Rolle besteht darin, komplexe, lokale Gesetzesänderungen in klare funktionale Anforderungen für die IT- und Finanzteams zu übersetzen und den Kontakt zu externen Beratern sowie gegebenenfalls den Steuerbehörden zu halten.

• Finanzen / Rechnungswesen / Debitorenbuchhaltung & Kreditorenbuchhaltung: Diese Gruppe verantwortet das Kerngeschäft: den tatsächlichen Cashflow. Sie muss sicherstellen, dass die Umstellung auf E‑Invoicing weder die Liquidität noch das Kunden- und Lieferantenerlebnis beeinträchtigt. Ihr Hauptaugenmerk liegt darauf, zu überprüfen, ob Rechnungsinhalte, Freigabeworkflows und Hauptbucheinträge während des gesamten Übergangs intakt bleiben.

• IT / Enterprise Architecture / ERP: Die IT-Abteilung fungiert als Architekt der Infrastruktur. Sie muss die Systemauswirkungen und Integrationsoptionen bewerten und eine Lösung entwerfen, die sogenannte „Spaghetti-Integrationen“ vermeidet – also jene unübersichtlichen Ad-hoc-Verbindungen, die mit der Zeit unmöglich zu warten sind. Ihre Aufgabe ist es, Systemleistung, Datenqualität und höchste Sicherheit zu gewährleisten.

• Einkauf / Supply Chain (insbesondere für Inbound/E‑Reporting): Oft vernachlässigt, bildet diese Gruppe das Tor für eingehende Prozesse. Sie muss den strategischen Aufwand bei der Anbindung von Lieferanten an E‑Invoicing-Netzwerke leiten. So wird sichergestellt, dass Lieferanten Ihre neuen rechtlichen und operativen Standards erfüllen und, wo anwendbar, Procure‑to‑Pay-Prozesse an neue Anforderungen anpassen können. Dies kann neue Anforderungen an die digitale Archivierung und Compliance umfassen, die Überwachung eingehender Rechnungen über Portale der Steuerbehörden, die sofortige Kennzeichnung eventueller Ablehnungen sowie die Aktualisierung der Abgleichslogik (Bestellung vs. Wareneingang vs. Rechnung) und automatische Datenanreicherungen, um manuelle Dateneingaben zu vermeiden.

• Recht / Compliance / Datenschutz: Angesichts der zunehmenden Überwachung digitaler Datenübertragungen muss die Rechtsabteilung die vertraglichen Auswirkungen auf Kunden und Lieferanten prüfen und gleichzeitig Verpflichtungen zur Datenlokalisierung und zum Datenschutz in verschiedenen globalen Regelungen bewerten.

Zusätzliche Stakeholder für größere oder internationale Konzerne

• Lokale Finanzteams / Lokales Finanzwesen: Diese Personen fungieren als Ihr lokaler Realitätscheck. Während globale Vorlagen nützlich sind, verfügen lokale Statutarteams über das feine Verständnis regionaler Verwaltungspraktiken, Sprachbarrieren und der spezifischen Erwartungen lokaler Wirtschaftsprüfer. Sie sind es, die die Lücke zwischen global standardisierten Prozessen und der rechtlichen Realität vor Ort in ihrer jeweiligen Jurisdiktion schließen müssen.

• Global Process Owners (Order‑to‑Cash / Procure‑to‑Pay): Die Rolle des GPO besteht darin, als Hüter des globalen Standards zu agieren. Ihre Herausforderung liegt darin, der Versuchung einer „Über-Lokalisierung“ zu widerstehen. Wenn jedes Land individuelle Anpassungen fordert, wird das System instabil. Der GPO muss die Notwendigkeit globaler Prozesseffizienz mit den harten Anforderungen lokaler gesetzlicher Mandate abwägen und sicherstellen, dass Ausnahmen minimiert statt institutionalisiert werden.

• Shared Services / BPO-Dienstleister: Shared Service Center sind die primären Betreiber Ihres neuen Rechnungs-Ökosystems. Ihre Betriebsmodelle, Service Level Agreements (SLAs) und Key Performance Indicators (KPIs) müssen komplett überarbeitet werden, um den Wechsel von manuellen, dokumentenzentrierten Aufgaben hin zu automatisierten, datenzentrierten Workflows zu berücksichtigen. Sie stehen an vorderster Front, wenn es darum geht, die zentralisierte Verarbeitung mit den unvermeidlich auftretenden länderspezifischen Vorgaben in Einklang zu bringen.

• Informationssicherheit / Cybersicherheit: E‑Invoicing erfordert die Anbindung Ihres internen ERPs an externe Portale von Steuerbehörden, häufig in Echtzeit. Das verändert Ihre Bedrohungsfläche. Die Cybersicherheit muss Ihre API-Verbindungen, Verschlüsselungsstandards, Authentifizierungsprotokolle und Zugriffskontrollen überprüfen. Sie muss zudem strenge Risikobewertungen von Drittanbietern für alle Lieferanten oder Plattformen durchführen, die Sie zur Abwicklung dieser Transaktionen nutzen.

• Customer Success / Vertriebsinnendienst (Sales Operations): Rechnungen sind nicht nur Buchhaltungsdokumente; sie sind ein zentraler Bestandteil der Customer Journey. Wenn sich ein Rechnungsformat ändert oder ein neues digitales Portal eingeführt wird, muss der Vertriebsinnendienst die Kommunikationsstrategie leiten. Er muss die Botschaft an die Kunden proaktiv steuern, um das Risiko von Zahlungsverzögerungen, Streitigkeiten oder beeinträchtigten Kundenbeziehungen durch die Reibungsverluste neuer digitaler Prozesse zu minimieren.

Wie sich die Stakeholder-Landschaft je nach Organisationstyp entwickelt

Die Zusammensetzung Ihres Projektteams wird sich je nach Skalierung und Grundfläche Ihrer Organisation unweigerlich verschieben. Während das Grundprinzip – dass E‑Invoicing nicht von einer einzelnen Abteilung allein getragen werden kann – universell bleibt, verändern sich das Gewicht und die Anzahl der beteiligten Stakeholder mit zunehmender Komplexität erheblich.

Für KMU und kleinere Unternehmen wird das Projekt oft von einem schlanken Team betreut – häufig der Eigentümer, Geschäftsführer oder ein externer Steuerberater –, das mehrere Aufgaben gleichzeitig übernimmt. In diesen Szenarien liegt der Fokus eindeutig auf Einfachheit, Kosten und der Minimierung von Störungen. Da diesen Unternehmen in der Regel dedizierte Steuer- oder IT-Abteilungen fehlen, geht es weniger um interne Orchestrierung als vielmehr um das Vertrauen in den Dienstleister. Die Organisation verlässt sich stark auf ihren bestehenden ERP- oder Softwareanbieter als „Compliance-Partner“, um die technische Hauptlast auszulagern.

Nationale Unternehmen mit rein lokalem Fokus stehen vor einer anderen Herausforderung. Hier sind interne Funktionen wie Steuern, Finanzen und IT klar definiert, was ein strukturiertes internes Projektteam ermöglicht. Die primäre Herausforderung der Stakeholder besteht darin, bestehende Systeme an die spezifischen Anforderungen dieser einen Jurisdiktion anzupassen. Da die internationale Komplexität gering ist, liegt der Schwerpunkt auf Prozesseffizienz und der nahtlosen Integration der E‑Invoicing-Lösung in etablierte ERP-Workflows. Das Risiko besteht hier nicht in globaler Fragmentierung, sondern vielmehr in der Schaffung einer Einzellösung, die sich bei einer späteren Expansion des Unternehmens nicht skalieren lässt.

Für multinationale Konzerne wächst die Komplexität exponentiell. Mit mehreren Jurisdiktionen, Sprachen und unterschiedlichen gesetzlichen Zeitplänen wird das Projekt zu einer Übung in hochgradiger Orchestrierung. Sie steuern ein dichtes Netz von Stakeholdern, darunter globale und regionale Steuerverantwortliche, lokale Finanzteams, Global Process Owners (GPOs) und Shared Service Center. Der entscheidende Erfolgsfaktor besteht darin, die globale Standardisierung aufrechtzuerhalten und gleichzeitig die notwendigen Lokalisierungen vorzunehmen. Das ultimative Ziel ist es, die Falle von länderspezifischen Silos zu vermeiden, bei denen jede Region ihre eigene technische Lösung entwickelt. Dies gelingt durch die Implementierung eines globalen Governance-Frameworks, das gemeinsame Standards gegenüber lokalen Sonderwünschen priorisiert.

Ein praktischer Projektlebenszyklus und Stakeholder-Einbindung

Erfolgreiches E‑Invoicing ist kein Projekt mit einem festen Enddatum; es ist ein fortlaufender Lebenszyklus. Der Prozess beginnt mit Horizon Scanning oder dem Compliance Watch, bei dem das Steuerteam als „Radarsystem“ fungiert, neue Mandate und Gesetzesentwürfe überwacht, um zu identifizieren, welche der anstehenden Vorgaben die Organisation betreffen werden, und um präzise zu bewerten, welche Einheiten, Systeme und Prozesse betroffen sein werden.

Mündet dies in das Lösungsdesign, müssen IT, Steuern und Finanzen zusammenarbeiten, um künftige funktionale und technische Anforderungen zu definieren sowie aktuelle Systeme und Datenflüsse zu kartieren. In dieser Phase sollten Sie auch Ihre initiale Bewertung hinsichtlich „Build vs. Buy“ starten: Reicht eine Eigenentwicklung aus oder soll ein Managed Service beschafft werden (siehe unsere strategische Aufschlüsselung in Abschnitt 4), bevor gegebenenfalls ein Anbieter ausgewählt wird.

Nach dem Design erfordert die Implementierungsphase eine intensive Abstimmung zwischen IT und Fachbereichen. Sie umfasst die Konfiguration oder Entwicklung der Lösung sowie die Integration in ERP-, Fakturierungs-, Beschaffungs- und Dokumentenmanagementsysteme. Dies ist auch der Schritt, in dem Verbindungen zu Plattformen oder Netzwerken von Steuerbehörden (wie Peppol oder anderen nationalen Portalen) eingerichtet werden.

Nach der Implementierung ist es entscheidend, von der Theorie des Designs zur Realität des Testens und Schulens überzugehen: Verlassen Sie sich niemals ausschließlich auf die „Sandbox“-Umgebung eines Anbieters. Binden Sie unbedingt die operativen Teams ein, die wissen, welche realen Rechnungs-Szenarien verwendet werden müssen, um die Daten zu validieren. Entscheidend ist, dass diese Phase Ihre beste Gelegenheit für Change Management bietet. Indem Sie operative Mitarbeiter aus Debitoren- und Kreditorenbuchhaltung in die Tests einbinden, validieren Sie nicht nur die Daten, sondern schulen sie auch auf neuen Systemen. So wird sichergestellt, dass das Team am Go-Live-Tag bereits mit den neuen Prozessen vertraut ist.

Schließlich erfordert die Go-Live- und Hypercare-Phase einen „Command Centre“-Ansatz mit einem sorgfältig choreografierten Umstellungsplan sowie einer klaren Kunden- und Lieferantenkommunikation. Wir empfehlen am Launch-Tag dringend Smoke-Tests – also die Ausführung einer kleinen, kontrollierten Gruppe von Live-Transaktionen mit vertrauenswürdigen Lieferanten oder Kunden, bevor auf große Volumina skaliert wird. Zentrale Aspekte sind die aktive Überwachung der ersten Rechnungen und das Fehlermanagement, wobei regelmäßige (falls nötig tägliche) Abstimmungen in den ersten 30 Tagen die unvermeidlichen Kinderkrankheiten lösen, die beim Go-Live neuer Integrationen auftreten. Dadurch entsteht eine Feedbackschleife, die sicherstellt, dass sich das System mit dem Unternehmen weiterentwickelt.

Nach Ablauf der Hypercare-Phase verlagert sich der Schwerpunkt auf Nachhaltigkeit sowie auf den laufenden Betrieb und das Change Management. Dazu gehört die Etablierung einer dauerhaften Routine zur Überwachung gesetzlicher Updates, die Durchführung regelmäßiger Überprüfungen der Anbieterleistung und der internen Kontrollen sowie die Planung der Ausweitung auf weitere Länder. So wird sichergestellt, dass Ihr Projekt ein belastbares Asset bleibt und nicht zu technischen Schulden führt.

Build vs. Buy: Strategische Überlegungen

Die Diskussion auf Führungsebene über „Build vs. Buy“ (Eigenentwicklung vs. Kaufen) wird oft als reine Technologieentscheidung dargestellt, ist aber tatsächlich eine strategische Entscheidung über Ihr Betriebsmodell. Einfach ausgedrückt: Möchten Sie die technische Infrastruktur selbst besitzen und warten, um hunderte globale Steuervorschriften einzuhalten, oder möchten Sie einen Spezialisten bezahlen, der diese Last für Sie übernimmt? Diese Debatte stellt den Wunsch nach absoluter Kontrolle dem Bedürfnis nach Agilität und Geschwindigkeit gegenüber.

Wann „Buy“ (Drittanbieter/Managed Service) sinnvoll ist

Der Kauf eines Managed Service ist der logische Weg für Organisationen, die Geschwindigkeit, Abdeckung mehrerer Länder und einen Dienst zur rechtlichen Überwachung („Regulatory Watch“) benötigen, der Sie bei Gesetzesänderungen konform hält. Risiko wird dadurch effektiv ausgelagert. Wichtige Gründe für das Buy-Modell sind:

• Begrenzte interne Entwicklungskapazitäten (typisch für KMU und viele Mid-Caps).

• Notwendigkeit von Geschwindigkeit zur Einhaltung enger gesetzlicher Fristen.

• Wunsch nach vorzertifizierten, regelmäßig aktualisierten Compliance-Inhalten.

• Abdeckung mehrerer Länder über eine einzige Plattform oder ein Netzwerk.

• Bevorzugung kalkulierbarer Betriebskosten (OPEX) gegenüber großen Investitionsprojekten (CAPEX).

Wann „Build“ (Inhouse/Eigenentwicklung) gerechtfertigt sein kann

Eine Eigenentwicklung ist in der Regel nur bei sehr großen, proprietären Systemen gerechtfertigt, bei denen sich ein Standardprodukt nicht ohne umfangreiche, kostspielige Middleware integrieren lässt. Wichtige Treiber sind:

• Sehr große Skalierung mit hochgradig standardisierten globalen Prozessen.

• Starke interne Entwicklungs- und Integrationsfähigkeiten.

• Komplexe, einzigartige Geschäftsmodelle, die durch Standardprodukte nicht gut abgedeckt werden.

• Das strategische Bestreben, die Roadmap und die Datenflüsse durchgehend selbst zu kontrollieren.

Hybride Modelle

Für die meisten multinationalen Konzerne ist ein hybrides Modell der Goldstandard: Die Nutzung einer globalen Compliance-Plattform als Kernstück („Core“) für Konsistenz, kombiniert mit lokalen, maßgeschneiderten Konnektoren, die spezifische länderspezifische Vorgaben abdecken.

• Zentrale Compliance-Engine eines Anbieters mit individuellen Frontends oder Workflows.

• Zentrale Plattform mit lokalen Erweiterungen für spezifische Länderregeln.

• Internes Team zur Verwaltung von Integrationen und Lieferantenbeziehungen.

Strategische Treiber für die Build-vs.-Buy-Entscheidung

KMU

• Fast immer „Buy“ oder Nutzung von Bündeln des Steuerberaters/ERP-Anbieters.

• Hauptkriterien: Benutzerfreundlichkeit, Kosten, lokale Compliance, Support.

Nationale Unternehmen

• Häufig „Buy“ einer lokalen oder regionalen Lösung, möglicherweise integriert in das bestehende ERP.

• Hauptkriterien: Lokale Expertise, ERP-Kompatibilität, Zeitplan für die Implementierung.

Multinationale Konzerne

• Wählen häufig ein hybrides Modell: Globale Plattform + lokale Konnektoren.

• Hauptkriterien: Skalierbarkeit, Abdeckung mehrerer Jurisdiktionen, Governance, Sicherheit, Gesamtkosten des Betriebs (Total Cost of Ownership).

Letztendlich geht es bei dieser Wahl weniger um technologische Präferenzen, sondern vielmehr um Ihre Risikobereitschaft, Ihre internen Fähigkeiten und Ihr langfristiges Betriebsmodell.

Governance und Betriebsmodell

Ohne eine formelle Governance-Struktur enden Sie unweigerlich mit einem Projekt, das entweder „konform, aber funktionsunfähig“ ist (steuerlastig, O2C-Abläufe ignorierend) oder „betriebsbereit, aber nicht konform“ (IT-lastig, Vorschriften ignorierend).

Die Governance-Struktur

Um dies zu steuern, empfehlen wir einen mehrstufigen Ansatz:

• An der Spitze muss ein Lenkungsausschuss (Steering Committee) stehen, der sich aus leitenden Vertretern des gesamten Unternehmens zusammensetzt (Steuern, Finanzen, IT und bei Multis regionale Verantwortliche), um Prioritäten zu setzen, Budgets zu genehmigen und Zielkonflikte zu lösen – und nicht nur Statusberichte entgegenzunehmen.

• Darunter steuert das Projekt-Kernteam (Projektleiter, Steuer-/IT-/Finanzverantwortliche und Prozessverantwortliche) die tägliche Umsetzung.

• Schließlich müssen Sie lokale Länder-Arbeitsgruppen bevollmächtigen; diese lokalen Steuer-/Finanz-/IT-Vertreter sind essenziell, da nur sie in der Lage sind, die spezifischen Nuancen einer lokalen Jurisdiktion umzusetzen.

RACI-Klarheit

Entscheidend ist, dass Sie frühzeitig für RACI-Klarheit sorgen. Wer trägt wirklich die Verantwortung für die finale Go-Live-Entscheidung? Wenn dies unklar bleibt, stehen Sie bei der ersten fehlgeschlagenen Rechnung vor monatelangen Gegenseitigen Schuldzuweisungen. Indem Sie klar definieren, wer für jeden Meilenstein – von der Auslegung der Vorschriften über das Lösungsdesign bis hin zum Testen und zur Abnahme – verantwortlich (Responsible), rechenschaftspflichtig (Accountable), zu konsultieren (Consulted) und zu informieren (Informed) ist, verwandeln Sie ein komplexes Multistakeholder-Programm in eine überschaubare Abfolge von Entscheidungen.

Häufige Fallstricke und wie man sie vermeidet

Die meisten Fehler beim E‑Invoicing sind organisatorischer und nicht technischer Natur. Der häufigste Killer ist der sogenannte „Silo-Effekt“ in Kombination mit der späten Einbindung wichtiger Stakeholder. Wenn die IT im luftleeren Raum agiert oder wenn Debitorenbuchhaltung, Kreditorenbuchhaltung und lokale Teams erst in letzter Minute hinzugezogen werden, bauen Sie ein System, das technisch funktioniert, aber an den operativen Realitäten vorbeigeht.

Umgekehrt ist die „Datenfalle“ – also das Unterschätzen des Zustands Ihrer Stammdaten – ein häufiges Versäumnis. Wenn die Steuernummern Ihrer Kunden fehlen, ungültig oder im ERP falsch zugeordnet sind, schlägt Ihre Automatisierung fehl, unabhängig davon, wie viel Sie für die Plattform ausgeben.

Darüber hinaus ignorieren viele Teams die externe Seite der Gleichung. E‑Invoicing bedeutet eine Umstellung für Ihre Kunden und Lieferanten. Wenn Sie nicht frühzeitig mit ihnen kommunizieren und sie auf den Wechsel vorbereiten, drohen Zahlungsverzögerungen und Datenkonflikte.

Vermeiden Sie schließlich eine übermäßige Individualisierung. Eine Lösung zu schaffen, die so maßgeschneidert ist, dass ihre Wartung bei Regeländerungen unmöglich wird, ist eine strategische Sackgasse.

Praktische Anleitung für die Implementierung

Für KMU

Setzen Sie auf Einfachheit. Ihr Fokus sollte darauf liegen: „Lässt sich das an meine Buchhaltungssoftware anbinden?“ Binden Sie Ihren Steuerberater oder ERP-Partner frühzeitig ein und suchen Sie nach einer Lösung, die starken lokalen Support bietet. Testen Sie mit einem kleinen Satz von Rechnungen, bevor Sie die Umstellung vollständig durchführen.

Für nationale Unternehmen

Starten Sie mit einem Pilotprojekt. Versuchen Sie keinen „Big Bang“-Rollout im gesamten Unternehmen. Benennen Sie einen Projektleiter, der die Lücke zwischen Steuer- und IT-Abteilung schließen kann, kartieren Sie Ihre aktuellen Prozesse und bewerten Sie Anbieter nach ihrer Fähigkeit zur Integration in Ihr bestehendes ERP.

Für multinationale Konzerne

Entwickeln Sie ein „globales Playbook“. Machen Sie Ihre Prozesse wiederholbar, damit Sie beim nächsten Ländermandat nicht wieder bei null anfangen müssen. Richten Sie ein Global Program Office ein und priorisieren Sie Ihren Rollout nach Risiko, Transaktionsvolumen und gesetzlichen Fristen.

Fazit

E‑Invoicing und E‑Reporting sind mittlerweile feste Bestandteile der Steuer- und Finanzlandschaft. Für KMU liegt die Priorität darin, einfache, konforme Lösungen zu wählen und Hektik in letzter Minute zu vermeiden. Für nationale Unternehmen liegt der Schwerpunkt auf der Abstimmung der Regeln einer Jurisdiktion mit den bestehenden Systemen. Für multinationale Konzerne besteht die Herausforderung darin, mehrere Stakeholder, Systeme und Zeitpläne zu orchestrieren, ohne fragmentierte, länderspezifische Silos zu schaffen.

Über alle Organisationstypen hinweg ist der Unterscheidungsfaktor zwischen Erfolg und Misserfolg selten die Technologie selbst. Es sind die klare Einbindung der Stakeholder, eine disziplinierte Governance und eine realistische „Build vs. Buy“-Strategie, die sich mit der Zunahme von Vorgaben weiterentwickeln kann. Die für die heutigen Anforderungen aufgebauten Kapazitäten werden das Fundament für zukünftige digitale Steuer- und Berichtspflichten bilden.