Eine Buchhaltung lässt sich heute innerhalb weniger Stunden in eine Cloudplattform verlagern. Rechnungen werden hochgeladen, OCR-Systeme erkennen Inhalte, Banktransaktionen laufen über Schnittstellen ein, Freigaben werden digital dokumentiert, Buchungsvorschläge entstehen automatisch und der Steuerberater arbeitet direkt auf denselben Datenbeständen.
Technisch wirkt das komfortabel. Rechtlich entsteht jedoch eine Frage, die viele Unternehmen und Kanzleien erst beim Anbieterwechsel stellen: Wem gehören eigentlich die Daten?
Die naheliegende Antwort lautet: dem Unternehmen, dessen Buchhaltung verarbeitet wird. Juristisch ist das zu einfach. Das deutsche Zivilrecht kennt kein allgemeines Eigentumsrecht an digitalen Daten, das dem Eigentum an einer Maschine, einem Fahrzeug oder einer Immobilie entspricht. Gleichzeitig können Herausgabeansprüche, Datenschutzrechte, vertragliche Nutzungsrechte, Urheberrechte, Datenbankrechte, Geschäftsgeheimnisse, steuerrechtliche Aufbewahrungspflichten und inzwischen der europäische Data Act gleichzeitig auf denselben Datenbestand einwirken.
Das Problem wird besonders sichtbar, wenn ein Unternehmen seine Buchhaltungssoftware wechseln möchte. Vielleicht lassen sich Rechnungen exportieren. Vielleicht auch Buchungssätze. Aber was passiert mit OCR-Informationen, Freigabehistorien, Benutzerrechten, Kostenstellenlogiken, Kommentaren, Schnittstelleninformationen, Kontierungsregeln oder Audit-Logs?
Ein PDF-Archiv ist nicht zwangsläufig eine portable Buchhaltung.
Und genau deshalb entwickelt sich Vendor Lock-in von einem technischen Problem zu einem rechtlichen und steuerlichen Risiko.
Der erste Irrtum: Daten haben nicht einfach einen Eigentümer
Das Sachenrecht des Bürgerlichen Gesetzbuchs beginnt für diese Diskussion mit einer entscheidenden Definition. Nach § 90 BGB sind Sachen im Sinne des Gesetzes körperliche Gegenstände. Digitale Daten sind nicht körperlich. Das klassische Eigentumsrecht der §§ 903 ff. BGB lässt sich deshalb nicht ohne Weiteres auf einen Datensatz übertragen.
Juristisch präziser muss daher gefragt werden: Wer darf auf welche Daten zugreifen, sie nutzen, kopieren, verändern, übertragen oder löschen?
Diese Rechte können sich aus völlig unterschiedlichen Rechtsgebieten ergeben.
Eine Rechnung eines Lieferanten kann beispielsweise handels- und steuerrechtlich für das Unternehmen aufbewahrungspflichtig sein. Enthält sie personenbezogene Daten, greift zusätzlich die Datenschutz-Grundverordnung. Eine vom Softwareanbieter aufgebaute Datenbank kann unter bestimmten Voraussetzungen nach den §§ 87a ff. UrhG geschützt sein. Technische Kontierungsmodelle oder interne Datenstrukturen können wiederum unter den Voraussetzungen des Geschäftsgeheimnisgesetzes geschützt sein.
Hinzu kommt der Vertrag zwischen Softwareanbieter und Kunde. Er kann festlegen, welche Daten bei Vertragsende herausgegeben werden, in welchem Format dies geschieht und wie lange ein Zugriff nach Kündigung bestehen bleibt. Die Vertragsfreiheit wird allerdings inzwischen durch zwingende europäische Vorgaben zur Datenportabilität begrenzt.
Das erklärt, weshalb die Aussage „Meine Daten gehören mir“ juristisch nur eingeschränkt weiterhilft.
Die Rechtsordnung schützt kein einheitliches Eigentum am Datensatz. Sie verteilt unterschiedliche Rechtspositionen auf unterschiedliche Beteiligte.
Für Unternehmen ist das keineswegs akademisch. Wer vor Einführung einer Software nicht weiß, auf welcher Rechtsgrundlage und in welchem Format er seine Informationen später zurückerhält, entdeckt die Schwäche häufig erst beim Wechsel.
Nicht jeder Bestandteil einer digitalen Buchhaltung ist rechtlich dasselbe
Eine moderne Buchhaltungsplattform enthält mehrere Datenebenen. Genau diese Trennung ist entscheidend dafür, welche Informationen beim Wechsel herausgegeben oder übertragen werden müssen.
| Datenebene | Beispiel | Rechtliche Ausgangslage |
|---|---|---|
| Originäre Unternehmensdaten | Rechnungen, Kontoauszüge, Verträge | starke Zugriffs- und Aufbewahrungsinteressen des Unternehmens |
| Buchführungsdaten | Buchungssätze, Konten, OPOS, Stammdaten | regelmäßig steuerlich relevant |
| Nutzungsbezogene Metadaten | Freigaben, Zeitstempel, Zuordnungen | können vom Data Act erfasst werden |
| Personenbezogene Daten | Mitarbeiter, Kunden, Ansprechpartner | zusätzlich DSGVO |
| Systemkonfiguration | Kontenmapping, Workflows, Einstellungen | abhängig von Vertrag, Zweck und Data Act |
| Anbieterinterne Daten | Algorithmen, interne Modelle | können geschützt sein |
| Datenbankstruktur | proprietäre Organisation der Daten | möglicherweise Datenbank- oder Urheberrecht |
| Geschäftsgeheimnisse | Automatisierungslogik, interne Scorings | Schutz nach GeschGehG möglich |
Bereits diese Unterscheidung zeigt das Kernproblem: Ein vollständiger Export der für das Unternehmen relevanten Daten ist nicht identisch mit einer vollständigen Kopie der bisherigen Software.
Das europäische Recht unterscheidet inzwischen ausdrücklich zwischen übertragbaren Kundendaten und geschützten Vermögenswerten eines Anbieters. Der seit September 2025 anwendbare Data Act, Verordnung (EU) 2023/2854, hat diese Grenze für Cloud- und Datenverarbeitungsdienste erheblich konkreter gemacht.
Der Data Act verändert die Machtverhältnisse zwischen Kunde und Cloudanbieter
Der europäische Data Act gilt grundsätzlich seit dem 12. September 2025. Für die Diskussion über Software Lock-in ist insbesondere Kapitel VI der Verordnung relevant. Es beschäftigt sich mit dem Wechsel zwischen Datenverarbeitungsdiensten.
Der europäische Gesetzgeber wollte ausdrücklich verhindern, dass Kunden durch technische, vertragliche oder wirtschaftliche Hindernisse faktisch an einen Cloudanbieter gebunden bleiben.
Die Regelungen erfassen Datenverarbeitungsdienste sehr weit. Die Verordnung berücksichtigt dabei unterschiedliche Cloudmodelle und stellt nicht nur auf klassische Infrastrukturangebote ab. Auch typische Software-as-a-Service-Modelle können unter den Anwendungsbereich fallen.
Für cloudbasierte Buchhaltungs-, ERP- oder Kanzleilösungen ist das von erheblicher Bedeutung.
Nach Art. 23 ff. Data Act müssen Anbieter Hindernisse beseitigen, die Kunden daran hindern, zu einem anderen Datenverarbeitungsdienst zu wechseln oder ihre Daten auf eine eigene IT-Infrastruktur zu übertragen.
Das betrifft nicht ausschließlich technische Hindernisse. Auch vertragliche, kommerzielle und organisatorische Wechselbarrieren werden erfasst.
Besonders relevant ist die Definition der exportierbaren Daten. Der Data Act erfasst dabei grundsätzlich Eingabe- und Ausgabedaten einschließlich bestimmter Metadaten, die unmittelbar oder mittelbar durch die Nutzung des Dienstes erzeugt werden.
Damit geht die europäische Regelung deutlich über die Frage hinaus, ob ein Anwender seine PDF-Rechnungen herunterladen kann.
Bei einem Buchhaltungssystem können beispielsweise Buchungsinformationen, Stammdaten, Konfigurationen, vom Kunden erzeugte Einstellungen oder bestimmte nutzungsbezogene Metadaten relevant sein.
Der Anbieter muss zudem transparenter machen, welche Daten und digitalen Vermögenswerte übertragen werden können, welche Datenstrukturen verwendet werden und welche technischen Grenzen bestehen.
Für SaaS-Anbieter verändert sich damit die Ausgangslage. Datenportabilität ist nicht mehr ausschließlich eine freiwillige Komfortfunktion. Sie ist in bestimmten Fällen Bestandteil eines gesetzlich abgesicherten Wechselprozesses.
Der Anbieter muss seine Software trotzdem nicht herausgeben
Der Data Act verpflichtet einen Softwareanbieter nicht dazu, beim Wechsel eines Kunden sein gesamtes geistiges Eigentum auf einen Wettbewerber zu übertragen.
Genau diese Grenze ist für eine sachliche Betrachtung wichtig.
Geschützt bleiben insbesondere bestimmte Geschäftsgeheimnisse, geistige Eigentumsrechte und anbieterspezifische digitale Vermögenswerte. Art. 30 Data Act berücksichtigt ausdrücklich, dass Anbieter durch den Wechselprozess nicht gezwungen werden sollen, geschützte Technologien oder Geschäftsgeheimnisse in einer Weise offenzulegen, die über das Erforderliche hinausgeht.
Das ist wirtschaftlich nachvollziehbar.
Ein Unternehmen kann verlangen, seine relevanten Buchhaltungsdaten aus einer Plattform herauszubekommen. Daraus folgt aber kein Anspruch darauf, den internen OCR-Algorithmus, den Quellcode, eine proprietäre Datenbankarchitektur oder ein vom Anbieter entwickeltes KI-Modell mitzunehmen.
Die schwierigen Fälle liegen genau dazwischen.
Angenommen, eine Buchhaltungssoftware analysiert eine Eingangsrechnung und erzeugt automatisch einen Buchungsvorschlag. Die Rechnung selbst ist eindeutig kundenseitiger Inhalt. Auch der gespeicherte Buchungssatz dürfte typischerweise ein erhebliches Portabilitätsinteresse des Kunden auslösen.
Aber wie ist ein interner Confidence Score des KI-Modells zu behandeln? Gehört die Information, dass das System mit 98,7 Prozent Wahrscheinlichkeit Konto X gewählt hat, zum exportierbaren Ergebnis? Was ist mit einer systeminternen Risikoklassifizierung? Mit embeddings? Mit einem proprietären Merkmalsvektor? Mit der Historie darüber, welche alternativen Buchungskonten das Modell geprüft hat?
Für solche hochspezifischen Fragen existiert bislang keine gefestigte höchstrichterliche Rechtsprechung für KI-gestützte Buchhaltungssysteme.
Der Data Act gibt einen rechtlichen Rahmen vor. Wo bei komplexen SaaS- und KI-Systemen die Grenze zwischen exportierbaren Kundendaten und geschützten internen Informationen genau verläuft, wird sich teilweise erst durch Behördenpraxis, Vertragsgestaltung und Rechtsprechung konkretisieren.
Das ist derzeit einer der juristisch interessantesten offenen Punkte.
Ein Export muss mehr sein als eine Datenhalde
Der Data Act gibt dem Kunden keinen Anspruch darauf, dass das Zielsystem nach einem Anbieterwechsel exakt so funktioniert wie das vorherige System.
Auch diese Differenzierung ist entscheidend.
Bei Datenverarbeitungsdiensten sollen Portabilität und ein Wechsel technisch ermöglicht werden. Das bedeutet jedoch nicht, dass Anbieter verpflichtet wären, die Software eines Wettbewerbers nachzubauen oder sämtliche Unterschiede zwischen zwei Plattformen zu beseitigen.
Damit entsteht eine praktische Kernfrage: Wann ist ein Export tatsächlich brauchbar?
Eine CSV-Datei mit zehn Millionen Datensätzen kann formal maschinenlesbar sein und wirtschaftlich trotzdem nahezu wertlos, wenn beispielsweise Beziehungen zwischen Datensätzen, Felddefinitionen, Zuordnungen, Zeitstempel oder notwendige Mappinginformationen fehlen.
Umgekehrt kann von einem Anbieter nicht verlangt werden, jede interne Systemstruktur offenzulegen, nur weil die Konkurrenzsoftware ein anderes Datenmodell verwendet.
Aus juristischer Sicht dürften deshalb drei Fragen zunehmend relevant werden:
Welche Informationen sind objektiv erforderlich, damit Daten wirtschaftlich weiterverwendet werden können?
Welche davon sind tatsächlich exportierbare Kundendaten?
Und an welcher Stelle beginnen geschützte anbieterspezifische Strukturen?
Der Data Act gibt dafür einen rechtlichen Rahmen. Die konkrete Grenzziehung bei komplexen Unternehmensanwendungen ist jedoch noch nicht für jede Konstellation geklärt.
Wechselgebühren verlieren ihre Funktion als Lock-in-Instrument
Auch wirtschaftliche Wechselbarrieren werden durch den Data Act begrenzt.
Historisch konnten hohe Gebühren für Datenexporte, Migrationen oder technische Unterstützung einen Anbieterwechsel erheblich verteuern. Selbst wenn Daten theoretisch verfügbar waren, konnte ein Wechsel dadurch wirtschaftlich unattraktiv werden.
Art. 29 Data Act sieht einen schrittweisen Abbau solcher Switching Charges vor. Ab dem 12. Januar 2027 dürfen Anbieter für den eigentlichen Wechsel grundsätzlich keine entsprechenden Wechselentgelte mehr verlangen.
Bis dahin gelten Übergangsregelungen, die die Höhe solcher Gebühren begrenzen.
Davon zu unterscheiden sind normale Vergütungen für zusätzliche Dienstleistungen. Beauftragt ein Unternehmen beispielsweise individuelle Datenbereinigung, Beratungsleistungen oder eine aufwendige Sondermigration, kann hierfür weiterhin eine Vergütung vereinbart werden.
Auch eine zulässige Zahlung wegen einer vorzeitigen Vertragsbeendigung ist nicht automatisch mit einer verbotenen Wechselgebühr gleichzusetzen.
Dennoch nimmt der Data Act einem klassischen Vendor-Lock-in-Modell einen Teil seiner wirtschaftlichen Wirkung: Der Wechsel soll nicht künstlich dadurch verhindert werden können, dass allein der Export der eigenen Daten unverhältnismäßig teuer wird.
Die DSGVO löst das Problem der Unternehmensdaten nicht
Vor Einführung des Data Act wurde bei Portabilitätsfragen häufig auf Art. 20 DSGVO verwiesen.
Das dort geregelte Recht auf Datenübertragbarkeit ist wichtig, aber für die vollständige Unternehmensbuchhaltung regelmäßig zu eng.
Art. 20 DSGVO schützt personenbezogene Daten einer betroffenen Person unter bestimmten Voraussetzungen. Die Daten müssen insbesondere auf einer entsprechenden Rechtsgrundlage verarbeitet werden und die Verarbeitung muss automatisiert erfolgen.
Eine GmbH kann sich deshalb nicht einfach auf Art. 20 DSGVO berufen und verlangen, ihre gesamte Buchhaltung in ein anderes ERP-System übertragen zu bekommen. Eine Kapitalgesellschaft ist keine natürliche Person und Unternehmensdaten sind nicht automatisch personenbezogene Daten.
Anders liegt der Fall bei Auftragsverarbeitung.
Verarbeitet ein Cloudanbieter personenbezogene Daten für ein Unternehmen, ist Art. 28 DSGVO relevant. Nach Beendigung der Auftragsverarbeitung muss der Dienstleister personenbezogene Daten nach Wahl des Verantwortlichen grundsätzlich löschen oder zurückgeben, soweit keine gesetzliche Verpflichtung zur weiteren Speicherung besteht.
Auch daraus folgt jedoch kein allgemeiner Anspruch darauf, sämtliche Funktionen oder internen Datenmodelle des Dienstleisters zu erhalten.
Data Act und DSGVO verfolgen daher unterschiedliche Zwecke und ergänzen sich. Bei personenbezogenen Daten bleibt die DSGVO maßgeblich. Für zahlreiche nicht personenbezogene Unternehmensdaten schafft der Data Act zusätzliche Rechte.
Steuerrechtlich bleibt der Unternehmer verantwortlich
Für Buchhaltungsdaten kommt eine weitere Ebene hinzu, die im normalen SaaS-Vertrag leicht unterschätzt wird.
Die steuerrechtliche Verantwortung lässt sich nicht dadurch beseitigen, dass Daten bei einem externen Anbieter gespeichert werden.
§ 146 AO verlangt unter anderem, dass Bücher und erforderliche Aufzeichnungen vollständig, richtig, zeitgerecht und geordnet geführt werden. Werden Daten elektronisch verarbeitet, muss das verwendete Verfahren die steuerlichen Ordnungsvorschriften erfüllen.
§ 147 AO regelt die Aufbewahrung der steuerlich relevanten Unterlagen. Je nach Dokumentenart bestehen unterschiedliche Aufbewahrungsfristen. Bestimmte Bücher, Inventare und Abschlüsse sind zehn Jahre aufzubewahren, Buchungsbelege inzwischen grundsätzlich acht Jahre.
Für digitale Buchführungsdaten reicht es nicht, dass sie irgendwann einmal vorhanden waren. Sie müssen während der gesetzlichen Fristen verfügbar bleiben und in den gesetzlich vorgesehenen Fällen maschinell ausgewertet beziehungsweise für den Datenzugriff bereitgestellt werden können.
Besonders relevant ist die Situation, wenn Daten bei einem Dritten gespeichert werden. Auch dann können steuerliche Zugriffsrechte bestehen. Die technische Auslagerung auf einen Cloudanbieter beendet die steuerrechtliche Verantwortung des Unternehmens nicht.
Der Bundesfinanzhof hat dies bereits in einer Entscheidung aus dem Jahr 2011 in einem für heutige Cloudmodelle erstaunlich aktuellen Zusammenhang deutlich gemacht. Im BFH-Beschluss vom 9. Februar 2011, I B 151/10 ging es unter anderem um digitalisierte Eingangsrechnungen in einem Dokumentenmanagementsystem. Der BFH bestätigte, dass sich steuerlicher Datenzugriff nicht auf das klassische Buchhaltungsprogramm beschränken muss.
Diese Rechtsprechung ist heute wichtiger denn je.
Steuerlich relevante Informationen entstehen inzwischen in Dokumentenmanagementsystemen, ERP-Systemen, Shopsystemen, Kassensoftware, Zahlungsplattformen und Cloudanwendungen.
Wer bei einem Softwarewechsel lediglich Anfangssalden und eine Summen- und Saldenliste übernimmt, hat deshalb noch lange nicht automatisch alle steuerlich erforderlichen Daten gesichert.
Die E-Rechnung verschärft das Problem
Mit der E-Rechnung verschiebt sich die Bedeutung zunehmend von der sichtbaren Rechnung zum strukturierten Datensatz.
Das Bundesfinanzministerium hat die GoBD deshalb mit dem BMF-Schreiben vom 14. Juli 2025 erneut angepasst. Die Änderungen berücksichtigen unter anderem die zunehmende Bedeutung strukturierter elektronischer Rechnungsdaten.
Bei einer E-Rechnung kann gerade der strukturierte elektronische Datensatz steuerlich relevant sein. Eine zusätzlich erzeugte PDF-Darstellung bildet diesen Datensatz nicht zwangsläufig vollständig ab.
Das verändert die Anforderungen beim Systemwechsel erheblich.
Wer beispielsweise über Jahre XRechnungen oder ZUGFeRD-Rechnungen verarbeitet hat, muss prüfen, ob die originären Dateien weiterhin verfügbar sind. Der alleinige Export einer menschenlesbaren PDF-Ansicht kann zu wenig sein.
Ein Softwareanbieter, der lediglich visualisierte Rechnungen exportiert, aber die ursprünglich eingegangenen strukturierten Daten nicht mehr verfügbar macht, könnte für das Unternehmen ein erhebliches Aufbewahrungsproblem verursachen.
Die richtige Frage lautet deshalb nicht mehr nur: Kann ich meine Rechnungen herunterladen?
Sie lautet: Kann ich die steuerlich relevanten Originaldaten in dem Format sichern, das für die gesetzliche Aufbewahrung und eine spätere Prüfung erforderlich ist?
Beim Steuerberater existiert ein eigenständiges Herausgaberecht
Noch interessanter wird die Rechtslage, wenn die Daten nicht unmittelbar beim Unternehmen, sondern beim Steuerberater oder in einem von ihm verwendeten Rechenzentrum gespeichert sind.
§ 66 StBerG regelt die Herausgabe von Handakten. Die Vorschrift berücksichtigt ausdrücklich auch elektronische Datenverarbeitung.
Für die zivilrechtliche Grundlage ist zusätzlich § 667 BGB relevant. Ein Beauftragter muss grundsätzlich herausgeben, was er zur Ausführung des Auftrags erhält und was er aus der Geschäftsbesorgung erlangt.
Bereits vor mehr als 20 Jahren beschäftigte diese Frage den Bundesgerichtshof.
Im BGH-Urteil vom 11. März 2004, IX ZR 178/03 verlangte ein Insolvenzverwalter von einer früheren Steuerberaterin unter anderem die Zustimmung zur Übertragung bei DATEV gespeicherter Daten auf einen neuen Steuerberater.
Der BGH erkannte grundsätzlich an, dass auch die Zustimmung zur Übertragung elektronisch gespeicherter Daten Gegenstand eines Herausgabeanspruchs sein kann.
Die Entscheidung enthält jedoch eine wichtige Einschränkung.
Es muss unterschieden werden, ob die vorhandenen Daten bereits das vertraglich geschuldete Arbeitsergebnis darstellen oder lediglich interne beziehungsweise vorbereitende Arbeitsschritte betreffen.
Damit lässt sich auch beim Steuerberater nicht pauschal sagen, dass der Mandant Anspruch auf jeden Datenbestand besitzt, der technisch im Kanzleisystem vorhanden ist.
Die Grundentscheidung ist dennoch bemerkenswert: Die technische Speicherung der Daten bei DATEV verhindert einen möglichen Herausgabeanspruch nicht.
Das Thema Vendor Lock-in beim Steuerberater ist damit keineswegs eine neue juristische Erfindung. Die Digitalisierung verändert lediglich Umfang und Komplexität des Problems.
Auch beim Steuerberater muss nicht jede interne Information herausgegeben werden
§ 66 StBerG zeigt gleichzeitig die Grenze der Herausgabepflicht.
Nicht jedes Dokument und nicht jede interne Information einer Kanzlei gehört automatisch zu den herauszugebenden Handakten. Interne Arbeitspapiere und bestimmte organisatorische Unterlagen können davon ausgenommen sein.
Diese Abgrenzung könnte durch KI-Systeme künftig schwieriger werden.
Ein Beispiel: Eine Kanzleisoftware analysiert automatisch einen Mandanten und kennzeichnet bestimmte Geschäftsvorfälle als umsatzsteuerlich riskant. Das System speichert dafür einen internen Risikoscore.
Ist dieser Risikoscore Bestandteil des Arbeitsergebnisses für den Mandanten?
Oder handelt es sich lediglich um ein internes Kontrollinstrument der Kanzlei?
Was gilt für automatisch erzeugte Prüfhinweise, interne Notizen einer KI, Confidence Scores oder nicht freigegebene Buchungsvorschläge?
Für solche Sachverhalte existiert bislang keine gefestigte höchstrichterliche Rechtsprechung.
Die Antwort wird voraussichtlich stark vom jeweiligen Mandatsvertrag, dem Zweck der Information und der konkreten Nutzung abhängen.
Ein finales, dem Mandanten übermitteltes Ergebnis ist rechtlich anders zu beurteilen als eine rein interne Arbeitshilfe zur Vorbereitung dieses Ergebnisses.
Hier treffen jahrzehntealte Herausgabegrundsätze auf Systeme, die eine Vielzahl neuer Zwischeninformationen erzeugen.
Das Datenbankrecht kann zusätzliche Schutzrechte schaffen
Auch das Urheberrecht darf in dieser Diskussion nicht übersehen werden.
Die §§ 87a und 87b UrhG schützen unter bestimmten Voraussetzungen Datenbanken, deren Beschaffung, Überprüfung oder Darstellung eine wesentliche Investition erfordert.
Der Hersteller einer geschützten Datenbank kann dadurch eigene Rechte besitzen.
Das bedeutet jedoch nicht, dass ihm sämtliche in der Datenbank gespeicherten Einzelinformationen „gehören“.
Genau diese Unterscheidung ist entscheidend.
Ein Unternehmen kann Rechte an seinen Buchhaltungsdaten haben, während der Softwareanbieter gleichzeitig Rechte an der systematischen Struktur seiner Datenbank besitzt.
Der Europäische Gerichtshof hat im Verfahren C-203/02, British Horseracing Board gegen William Hill wichtige Grenzen des Datenbankherstellerrechts herausgearbeitet. Nicht jede Investition in die Erzeugung von Informationen gilt automatisch als geschützte Investition in die Beschaffung des Datenbankinhalts.
Auch das Urteil C-30/14, Ryanair gegen PR Aviation zeigt, wie erheblich neben gesetzlichen Schutzrechten die vertraglichen Bedingungen einer Datenbanknutzung sein können.
Für SaaS-Systeme bedeutet dies: Daten, Datenbank und Software müssen rechtlich getrennt betrachtet werden.
Dass der Kunde einen Anspruch auf bestimmte Daten hat, bedeutet nicht automatisch, dass er einen Anspruch auf die vollständige Datenbankstruktur erhält.
Geschäftsgeheimnisse sind kein pauschaler Ausweg für Anbieter
Softwareanbieter haben berechtigte Interessen daran, proprietäre Technologien nicht offenlegen zu müssen.
Das bedeutet jedoch nicht, dass jeder interne Datensatz automatisch als Geschäftsgeheimnis bezeichnet werden kann.
Nach § 2 GeschGehG setzt ein Geschäftsgeheimnis unter anderem voraus, dass die betreffende Information nicht allgemein bekannt oder ohne Weiteres zugänglich ist, einen wirtschaftlichen Wert besitzt und Gegenstand angemessener Geheimhaltungsmaßnahmen ist.
Der bloße Hinweis „proprietär“ reicht nicht aus.
Der Data Act berücksichtigt Geschäftsgeheimnisse ausdrücklich und schafft Schutzmechanismen. Gleichzeitig darf dieser Schutz nicht dazu benutzt werden, die gesetzlich vorgesehene Datenportabilität faktisch vollständig zu umgehen.
Genau hier entsteht ein möglicher zukünftiger Konflikt.
Ein Anbieter kann nachvollziehbar argumentieren, dass seine interne Scoring-Logik, Sicherheitsarchitektur oder KI-Modellparameter geschützt werden müssen.
Ein Kunde kann ebenso nachvollziehbar argumentieren, dass bestimmte vom System erzeugte Informationen zwingend benötigt werden, um seine Buchführung nachvollziehbar fortführen zu können.
Welche dieser Argumente im konkreten Fall überwiegen, hängt von der Art der Information ab.
Eine generelle Lösung gibt es bisher nicht.
Für Steuerberater kommt die Verschwiegenheit hinzu
Steuerberatungskanzleien haben bei der Auswahl von Cloudlösungen zusätzliche rechtliche Anforderungen.
Nach § 57 StBerG gehört die Verschwiegenheit zu den zentralen Berufspflichten des Steuerberaters. Zusätzlich schützt § 203 StGB fremde Geheimnisse und erfasst unter anderem Steuerberater.
Der Einsatz externer Dienstleister ist deshalb nicht allein eine IT-Entscheidung.
§ 62a StBerG regelt die Inanspruchnahme von Dienstleistungen. Externe Anbieter müssen sorgfältig ausgewählt und vertraglich zur Verschwiegenheit verpflichtet werden.
Bei ausländischen Dienstleistern können weitere Anforderungen entstehen.
Parallel gelten die datenschutzrechtlichen Vorgaben zur Auftragsverarbeitung und gegebenenfalls zum Drittlandtransfer.
Damit kann eine Software technisch hervorragend funktionieren und dennoch aus Sicht einer Kanzlei problematisch sein.
Subunternehmerketten, Serverstandorte, Zugriffsmöglichkeiten, Verschlüsselung, vertragliche Exit-Regelungen und der Umgang mit Daten nach Vertragsende sollten deshalb bereits bei der Softwareauswahl geprüft werden.
Für eine Steuerberatungskanzlei ist Cloudbeschaffung immer auch Berufsrecht.
Die Insolvenz des SaaS-Anbieters bleibt ein Schwachpunkt
Alle Portabilitätsrechte besitzen eine praktische Grenze: Der Anspruch muss technisch noch erfüllbar sein.
Gerät ein Softwareanbieter in die Insolvenz, können sich die rechtlichen Rahmenbedingungen erheblich verändern.
Bei noch nicht vollständig erfüllten gegenseitigen Verträgen kann § 103 InsO relevant werden. Der Insolvenzverwalter kann unter den gesetzlichen Voraussetzungen entscheiden, ob der Vertrag weiter erfüllt wird.
Lehnt er die Erfüllung ab, können dem Vertragspartner grundsätzlich Insolvenzforderungen wegen Nichterfüllung verbleiben.
Welche Auswirkungen dies konkret auf einen SaaS-Vertrag hat, hängt jedoch von Vertragsstruktur, Leistungsstand und tatsächlicher Ausgestaltung ab.
Noch schwieriger ist die technische Seite.
Wenn Infrastruktur abgeschaltet wird, Administratoren das Unternehmen verlassen oder zentrale Dienste kurzfristig nicht mehr funktionieren, hilft ein theoretisch bestehender Herausgabeanspruch möglicherweise wenig.
Auch ein pauschales Aussonderungsrecht an Daten lässt sich nicht ohne Weiteres annehmen.
§ 47 InsO setzt voraus, dass ein Gegenstand aufgrund eines dinglichen oder persönlichen Rechts nicht zur Insolvenzmasse gehört. Gerade weil digitales Datenmaterial nicht ohne Weiteres Sacheigentum im Sinne von § 90 BGB darstellt, sind pauschale Analogien zum Eigentum an einem physischen Gegenstand problematisch.
Der Data Act verbessert die Position des Kunden bei einem regulären Anbieterwechsel deutlich. Er ersetzt aber kein funktionierendes Business-Continuity-Konzept.
Unternehmen sollten deshalb überlegen, ob kritische Buchhaltungsdaten regelmäßig unabhängig vom Anbieter gesichert werden können.
Der Vertrag bleibt trotz Data Act entscheidend
Der Data Act beseitigt die Bedeutung vertraglicher Regelungen nicht.
Im Gegenteil: Die Verordnung verlangt gerade mehr Transparenz über die Bedingungen eines Anbieterwechsels.
Unternehmen sollten deshalb bei einem SaaS-Vertrag nicht nur Preis, Laufzeit und Funktionen prüfen.
Relevant sind unter anderem folgende Fragen:
Welche Daten können exportiert werden?
Welche Metadaten gehören zum Export?
Welches Dateiformat wird verwendet?
Wie lange bleibt nach Kündigung Zugriff bestehen?
Wann werden Daten endgültig gelöscht?
Welche Unterauftragnehmer sind beteiligt?
Welche technischen Hilfen werden beim Wechsel bereitgestellt?
Welche Daten betrachtet der Anbieter als eigenes geistiges Eigentum?
Welche Dienstleistungen beim Wechsel sind zusätzlich kostenpflichtig?
Zusätzlich bleiben die allgemeinen Regeln über Allgemeine Geschäftsbedingungen relevant. § 307 BGB verbietet unangemessene Benachteiligungen durch AGB. Über § 310 BGB findet die Inhaltskontrolle mit Besonderheiten auch im unternehmerischen Geschäftsverkehr Anwendung.
Seit Geltung des Data Act kommt hinzu, dass vertragliche Regelungen zwingende europäische Wechselrechte nicht einfach beseitigen können.
Damit verändert sich auch die Due Diligence bei Softwarebeschaffung.
Die Frage lautet nicht mehr nur: Was kann die Software?
Sie muss zusätzlich lauten: Wie verlassen wir sie wieder?
Der Exit-Test sollte zum Standard werden
Für Unternehmen und Kanzleien lässt sich daraus ein vergleichsweise einfacher Prüfrahmen ableiten.
Vor Vertragsabschluss sollte nicht nur eine Produktdemo stattfinden. Mindestens gedanklich sollte ein vollständiger Anbieterwechsel simuliert werden.
| Prüffrage | Warum sie relevant ist |
|---|---|
| Können originäre Belege vollständig exportiert werden? | steuerliche Aufbewahrung |
| Werden strukturierte E-Rechnungen im Originalformat herausgegeben? | GoBD und E-Rechnung |
| Sind Buchungssätze vollständig exportierbar? | Migration der Finanzbuchhaltung |
| Können OPOS und Stammdaten übernommen werden? | Fortführung im Zielsystem |
| Welche Metadaten werden exportiert? | Nachvollziehbarkeit |
| Sind Freigabehistorien enthalten? | internes Kontrollsystem |
| Werden Kommentare und Anhänge mit übertragen? | Dokumentation |
| Existieren dokumentierte Schnittstellen? | technische Migration |
| Wie lange besteht Zugriff nach Kündigung? | Migrationssicherheit |
| Welche Daten gelten als Anbieter-IP? | Lock-in-Risiko |
| Welche Kosten entstehen beim Wechsel? | wirtschaftliches Risiko |
| Was geschieht bei Insolvenz? | Business Continuity |
| Können Daten unabhängig gesichert werden? | Notfallvorsorge |
| Kann ein anderes System den Export tatsächlich lesen? | praktische Portabilität |
Der letzte Punkt wird häufig unterschätzt.
Ein Unternehmen sollte sich nicht ausschließlich darauf verlassen, dass laut Leistungsbeschreibung ein Export vorhanden ist.
Sinnvoll wäre bei kritischen Systemen ein tatsächlicher Test während der Vertragslaufzeit.
Ein Unternehmen könnte beispielsweise einmal jährlich einen vollständigen Export durchführen und stichprobenartig kontrollieren:
Sind alle Rechnungen vorhanden?
Sind strukturierte Rechnungsdateien enthalten?
Sind Buchungsinformationen vollständig?
Sind Zeitstempel und Freigaben nachvollziehbar?
Können Anhänge geöffnet werden?
Ist die technische Datenbeschreibung verständlich?
Könnte ein anderes System mit diesen Informationen grundsätzlich weiterarbeiten?
Der Aufwand dafür ist überschaubar.
Der erste Test fünf Jahre später, nachdem der Vertrag bereits gekündigt wurde, kann erheblich teurer werden.
Was heute rechtlich weitgehend klar ist und was offen bleibt
Einige Punkte lassen sich inzwischen relativ belastbar beantworten.
Das deutsche Recht kennt kein allgemeines Sacheigentum an digitalen Daten. Unternehmen können aber umfangreiche vertragliche, steuerrechtliche und datenschutzrechtliche Rechte besitzen. Steuerliche Aufbewahrungs- und Mitwirkungspflichten bleiben beim Unternehmen bestehen, selbst wenn Daten an einen Cloudanbieter ausgelagert werden.
Steuerberater unterliegen zusätzlichen berufsrechtlichen Vorgaben zu Herausgabe, Verschwiegenheit und externen Dienstleistern.
Der Data Act stärkt seit September 2025 die Position von Kunden beim Wechsel zwischen Datenverarbeitungsdiensten erheblich. Der europäische Gesetzgeber will technische, wirtschaftliche und vertragliche Lock-in-Effekte reduzieren.
Ebenso eindeutig ist die andere Seite: Ein Kunde erhält dadurch keinen generellen Anspruch auf Quellcode, proprietäre Algorithmen, Geschäftsgeheimnisse oder die vollständige technische Architektur eines Softwareanbieters.
Weniger eindeutig ist die Grenze zwischen beiden Bereichen.
Moderne Software erzeugt zunehmend Informationen, die weder klassische Eingabedaten des Kunden noch eindeutig interne Informationen des Anbieters sind.
OCR-Systeme strukturieren Rechnungsinformationen. KI-Systeme erzeugen Buchungsvorschläge. Fraud-Systeme bilden Risikowerte. Workflows produzieren Freigabehistorien. Automatisierungsplattformen speichern Entscheidungspfade und Metadaten.
Welche dieser Informationen beim Anbieterwechsel zwingend mitgenommen werden können, wird nicht für jede technische Konstellation allein aus dem Gesetzestext beantwortet werden können.
Auch „maschinenlesbar“ ist nicht automatisch gleichbedeutend mit „wirtschaftlich migrierbar“.
Genau deshalb entwickelt sich Datenportabilität zu einem neuen Risikofeld für Unternehmen und Steuerberatungskanzleien.
Eine Software kann während ihrer Nutzung hervorragend funktionieren und trotzdem eine schlechte strategische Entscheidung sein, wenn das Unternehmen sie später praktisch nicht mehr verlassen kann.
Digitale Souveränität zeigt sich deshalb nicht daran, wie schnell Daten in ein System hineinkommen.
Sie zeigt sich daran, ob sie zehn Jahre später vollständig, rechtssicher und technisch nutzbar wieder herauskommen.
