GDPdU: originär elektronisch, operative Systeme und andere Begriffe
Im vorangegangenen Newsletter 20030903Newsletter 20030903 haben wir versucht, eine Reihe von Begriffen wie Daten und Archive zu klären, was auch zu einigen Diskussionen im IT-Forum.org geführt hat. Eine Reihe weiterer Begriffe aus dem Umfeld der GDPdU harrt aber noch einer eindeutigen Definition. So wollen wir uns in diesem Beitrag mit einigen weiteren Aspekten der begrifflichen Interpretation auseinandersetzen. „originär elektronisch“
Originär elektronische Daten sind unter dem Datenbegriff zu differenzieren, der im vergangenen Newsletter diskutiert wurde. In erster Linie handelt es sich hierbei um Daten, die in einem System selbst durch Verarbeitungsschritte entstanden sind. Dabei darf man nicht vergessen, dass am Beginn einer solchen Verarbeitung immer eine manuelle Eingabe, sei es von Daten selbst oder von Programmlogik zur Verarbeitung von Daten, gibt. Viele Daten werden aber auch automatisiert aus Nebensystemen oder vorgelagerten Systemen übernommen und sind dann in dem System, dass die steuerrelevanten Daten speichert und verarbeitet, in jedem Fall als originär elektronisch zu betrachten. Anders sieht dies mit Dokumenten aus, z.B. mit einer von Hand eingegebenen Rechnung in einem Textverarbeitungsprogramm. Hier handelt es sich um die Übertragung von Daten in ein Dokument, das hierdurch Belegcharakter erhalten kann.
"Auswertbarkeit"
Unter Auswertbarkeit würden wir die "maschinelle Auswertbarkeit von Daten, die strukturiert als Datensatz vorliegen" und das "Anzeigen von Belegen über einen eindeutigen Index, der den maschinell auswertbaren Daten zugeordnet ist", verstehen können. Auswertbarkeit beinhaltet dabei, dass die Daten mit einer dafür vorgesehenen Software verarbeitet werden können. Dies trifft auf die Belege nicht zu, sie werden recherchiert und zur Anzeige gebracht. Der Begriff der Auswertbarkeit betrifft daher lediglich die strukturierten Daten, die als Datensätze vorliegen. Nach den jüngsten Veröffentlichungen und Einschätzungen ist der Maßstab für die Auswertbarkeit einerseits durch das die Daten erzeugende Programm andererseits durch eine separate Auswertungssoftware wie IDEA, ACL oder ähnlich definiert.
"Nutzung aller Auswertungsmöglichkeiten vorhandener Software"
Hier wäre an erster Stelle diejenige Software zu sehen, in der die Daten entstanden sind und originär vorliegen, bzw. vorlagen. Die Einschränkung "originär" würde es möglich machen, andere Systeme, in denen die Daten für andere Zwecke erneut oder parallel als Kopie gespeichert oder verarbeitet wurden (z.B. ein Management-Informationssysteme) von der Forderung, alle Funktionalität der vorhandenen Software nutzen zu dürfen, auszuschließen. Es geht also um die Systeme, wo die steuerrelevante Informationen "originär" vorliegen oder ursprünglich vorlagen.
"Auswertung mit IDEA"
Natürlich darf ein Prüfer alle heutigen (und auch zukünftigen) Funktionen der Software IDEA bei der Auswertung der "Daten, die als strukturierte Datensätze vorliegen", benutzen. Das ist ja der Zweck der Übung bei Z3. Also geht es hier bei IDEA vielmehr darum, wie viele Daten in welchem Format auswertbar für Z3 zur Verfügung gestellt werden. Hat ein Anwender selbst IDEA oder TaxAudit auf seinen Systemen installiert, um seine Daten selbst zu kontrollieren und zu qualifizieren, so muss er seine eigene IDEA-Software nicht bereitstellen, da in dieser keine steuerrelevanten Daten "originär" entstanden sind. Anders sieht dies aus, wenn das kaufmännische System, z.B. ein ERP mit zahlreichen Auswertungsmöglichkeiten, installiert ist. Nach Auslegung von Frage 11 und Frage 12 darf dann der Prüfer alle vorhandene (aber auch vorhandene und nicht installierte) Software zur Auswertung der steuerrelevanten Daten nutzen. Andere Daten darf er nicht sehen. Hier liegt das Problem in zahlreichen kaufmännischen Anwendungslösungen, dass entsprechende Daten- und Perioden-Abgrenzungen sowie die Historisierung und eindeutige periodenbezogenen Zuordnung von Stammdaten nicht immer gegeben ist. Diese Probleme müssen von den Anbietern der kaufmännischen Softwarepakete gelöst werden. Der Idealfall, dass alle steuerrelevanten Daten nach Perioden organisiert bereits vorliegen und direkt mit IDEA ausgewertet werden können, ist noch nicht gegeben. Bei großen Anwendern können dies zudem Datenmengen werden, die sich nicht mehr mit Z3 bewältigen lassen. Ebenso wie mit einem hauseigenem IDEA muss der Anwender dem Steuerprüfer auch nicht seine eigene ACL-Software bereitstellen.
"Datenverarbeitungssystem im Sinne der GDPdU"
Man kann nicht erwarten, dass hier eine Liste "typischer Anwendungen" herausgegeben wird, da wir das gleiche Problem wie mit einer Liste "steuerrelevanter Daten" hätten. Man müsste sich hier der Fragestellung ebenfalls wie bei "Daten" und "Belegen" neutral nähern (steuerrelevante Daten können auf Webseiten, in Zeiterfassungssystemen, in Materialverwaltungen etc. originär entstehen). Natürlich muss man sich auch immer vor Augen halten, dass die meisten steuerrelevanten Daten in Buchführungssystemen entstehen - durch die Eingabe von Daten, Zuordnung zu Konnten und Verknüpfung mit Stammdaten. Daher wird es schwierig sein, zu verlangen, dass alle erzeugenden Systeme auch für die Prüfung zugänglich gemacht werden müssen. Schwierig wird es beispielsweise dann, wenn eine Materialwirtschaft automatisch Daten an eine Buchführungssoftware übermittelt, diese dort zur Buchung geführt werden und erst in der Buchführungssoftware z.B. der Betrag mit herausgezogenem Steueranteil gebildet wird. Viele Systeme sind auf solche Auswertungen nicht ausgelegt sondern liefern ihre "originären" Daten in anderen Verarbeitungssystemen nur ab. Das gleiche gilt für eine "Scanning-Lösung", die zwar steuerrelevante Belege erfasst und diese an ein Archiv übergibt, aber selbst nicht für Auswertung und Retrieval ausgelegt ist.
"Produktivsystem"
Der Begriff "Produktivsystem" bezeichnet einen Zustand und nicht eine Art oder einen Typ einer Anwendungslösung - also auch nicht im Sinne eines "steuerrelevante Daten produzierendes System". Der Begriff dient zur Unterscheidung von noch nicht in Betrieb genommenen oder nicht mehr in Betrieb befindlichen Systemen sowie von Testsystemen und redundanten, nicht aktiv genutzten Sicherheitssystemen. Unter einem Produktivsystem versteht man eine Anwendung, die aktiv und nutzbar ist, und die für den Zweck der Anwendung benötigten Daten enthält oder auf diese direkt zugreifen kann. Bei einer kaufmännischen Anwendung wären dies auch die aktuellen steuerrelevanten Daten. Diese aktuellen Daten können, müssen aber nicht, mit den Daten übereinstimmen, die der Steuerprüfer prüfen möchte. Daher kommt die Diskussion um das Archivieren von Daten, d.h. die Speicherung der nicht mehr aktuell im Produktivsystem benötigten Daten auf einem externen Speichermedium oder in einem externen Softwaresystem. Um die Prüfung zu ermöglichen, müssten also entweder die zu prüfenden Daten in das Produktivsystem zurückgeladen werden, oder das externe Softwaresystem soll die gleiche Funktionalität (Frage 11, Frage 12) wir das ursprüngliche, die Daten erzeugende System in Hinblick auf die Auswertungsmöglichkeiten bieten.
„Nebensystem“
Unter „Nebensystemen“ versteht man Softwarelösungen, in denen steuerrelevanten Daten entstehen, gespeichert und verarbeitet werden, die nicht oder nicht vollständig in einem Buchhaltungs- oder ERP-System vorliegen. Diese Systeme dürfen auch der elektronischen Steuerprüfung unterworfen werden.
„Vorgelagertes System“
„Vorgelagerte Systeme“ sind Lösungen, mit denen steuerrelevante Daten und Belege erfasst und verarbeitet werden (z.B. Scannen mit automatischer Klassifikation von Rechnungen mit Übertragung ins ERP), deren Ergebnisse jedoch in ein Buchführungs-, ERP- oder vergleichbares System übertragen werden und dort für den Zugriff bereitstehen. Dabei ist sicherzustellen, dass die Verarbeitung und Übertragung verlustfrei, nachvollziehbar und die originär Information nicht verändernd geschieht.
„Universelles Auswertungsprogramm“
Durch die Neudefinition der Aufgaben eines Archivsystems, das nur noch vollständige, auswertbare steuerrelevante Daten übernimmt und auf Anforderung wieder bereitstellt, wurde die Frage laut, wie denn ein „universelles Auswertungswerkzeug“ zu positionieren sei. Die Bundesfinanzministerien scheuen sich natürlich gleich „IDEA“ zu schreiben, obwohl dies die Software ist, die bei der Steuerprüfung eingesetzt wird. Man kann aber Produkte wie ACL nicht grundsätzlich benachteiligen. Mit IDEA hätte man den Vorteil, dass die Funktionalität bekannt ist. Will man einen neutralen Begriff wie z.B. „Universelles Auswertungsprogramm“ benutzen, muss der Funktionsumfang auch neutral definiert werden. Da das BMF mit Definitionen nicht gerade sehr professionell war, steht wahrscheinlich neues Wirrwarr ins Haus. Die Formulierung aus dem Fragen-und-Antworten-Katalog, dass die gleiche Auswertungsfunktionalität wie beim die Daten erzeugenden System vorhanden sein soll, greift bei Auswertungsprogrammen wie IDEA oder ACL nicht.
Im Umfeld der GDPdU gibt es noch zahlreiche weitere Begriffe die einer Klärung harren. Ob unsere Definitions- und Abgrenzungsvorschläge in eine Neufassung der GDPdU oder des Fragen-und-Antworten-Kataloges des BMF Eingang finden, muss sich noch zeigen. Doch zunächst steht erst einmal eine Aktualisierung der GoBS an, bevor es nach dem Sammeln von Praxis-Erfahrungen mit der Umsetzung noch einmal an die GDPdU geht. Das IT-Forum.org bietet Raum und Gelegenheit, bei diesen Fragen mit zu diskutieren. (Kff)
Metadata