Zu den GDPdU gibt es nun schon seit langer Zeit einen etwas diffusen Diskussionsprozess, der vor allem durch Unklarheiten zur Realisierung bei den steuerpflichtigen Unternehmen und teils widersprüchlichen Stellungnahmen unterschiedlicher Personenkreise gekennzeichnet ist. Der Verfasser möchte in dieser Ausarbeitung aus seiner IT-Sicht Aspekte der Situation beschreiben, Lösungsansätze darstellen, Anregungen geben und auch die Diskussion in eine konkretere Richtung lenken. Vorausgesetzt wird ein Grundwissen zur entsprechenden Rechts- und Gesetzeslage und zu den GDPdU. Stellungnahmen des Verfassers zur GDPdU erfolgen aus Sicht des IT-Fachmannes und nicht aus der eines Beteiligten der Rechtspflege.

Die GDPdU - rechtswirksam seit Januar 2002, Datenzugriff, Konsequenzen

Die GDPdU schreibt vom Grundsatz die maschinelle Auswertbarkeit aller steuerrelevanten Daten seit dem 1. Januar 2002 vor. Das steuerrelevante IT-System wird als Träger der steuerrelevanten Daten (und Dokumente) zu einer zusätzlichen Informationsquelle für die Steuerprüfung.

Es ist zu gewährleisten, dass steuerrelevante Datenbestände auch dann für den auswertenden Zugriff gemäß Z1 - Z3 dem Steuerprüfer zur Verfügung stehen, wenn das ursächlich datenerzeugende Produktivsystem, oder dessen Teilsysteme, nicht mehr im Einsatz sein sollte.

Die auszuwertenden Daten, Bewegungsdaten und die zugehörigen Stammdaten, müssen konsistent und schlüssig, vor allem auch periodengerecht sein.

Der eigentliche "Sprengstoff" der GDPdU ist in diesen generellen Forderungen verborgen!

Unstrittig ist, dass die Umsetzung dieser Forderungen erhebliche technische und kostenorientierte Konsequenzen für die betroffenen steuerpflichtigen Unternehmen haben kann.

Die GDPdU - und im Kontext der sog. "Fragen und Antwortenkatalog" des BMF - sind in Ihrer inhaltlichen Abfassung allerdings auch geeignet, Verwirrung durch Unklarheiten und fehlende Praxisnähe zu schaffen.

Der "Fragen- und Antwortenkatalog", eine wichtige Orientierungshilfe?

Das BMF selbst sagt leider in der Einleitung, dass dieses Dokument eine Orientierungshilfe ohne Rechtbindung ist und im Einzelfall das zuständige Finanzamt entscheiden wird.

Was nun eigentlich?

Erwartet das BMF denn tatsächlich, dass es hier "unverbindlich" Orientierungshilfe und Hinweise gibt, die der Steuerpflichtigen interpretiert und berücksichtigt, welche in einer späteren Betriebprüfung infrage gestellt werden?

Eine mangelnde Rechtsverbindlichkeit für die Finanzverwaltung könnte im Ernstfall weitreichende Konsequenzen für den Steuerpflichtigen haben, wenn er - wie zum Beispiel beim "steuerlichen Archiv" - Lösungen aufgesetzt hat, die zwar konform zum "Fragen- und Antwortenkatalog" sind, aber in der GDPdU selbst nicht stehen!

Der Verfasser hält das rechtlich für sehr bedenklich und sieht hier Klärungsbedarf!

"Die Falle " - Auswertungsmöglichkeiten, steuerliches Daten-Archiv

Das Erfüllen der Vorgaben aus den GDPdU ist insbesondere dann problematisch, wenn der Anwender eine heterogene Softwareumgebung hat. Wenn also ein Mix von Software unterschiedlicher Hersteller, vielleicht zusätzlich auch Individualsoftware, über diverse steuerrelevanten Schnittstellen untereinander verbunden sind und auch Daten zum Hauptsystem der Buchführung, i.d.R. die FIBU, übergeben.

Bei einer Aufbewahrungspflicht von, im Regelfall, 10 Jahren stellt sich hier natürlich auch massiv die Frage, wie sich Releasewechsel, Systemwechsel, Änderungen in den Datenmodellen, etc., auf die unverfälschte und fehlerfreie Bereitstellung, Vorhaltung, korrekte Präsentation der Daten für die Außenprüfung auswirken.

Muß man wirklich Systeme, Programme, aufbewahren, "archivieren", "in den Keller stellen", die nicht längst mehr produktiv im Einsatz sind, damit der Steuerprüfer "irgendwann mal" auf diese Systeme und deren Daten auswertend zugreifen kann? Wie soll das denn funktionieren.

Vor diesem Hintergrund hat auch das BMF im bereits zitierten "Fragen- und Antwortenkatalog" zur Sache Stellung genommen, welche Anforderungen an den Zugriff aus einem Archivsystem heraus zu stellen sind (siehe Punkte 11 + 12, "Archiv"). Diese im Grundsatz begrüßenswerten Ausführungen wurden jedoch mit einschränkenden Formulierungen ausgestattet, welche das "Zugeständnis" im Einzelfalle vor neue praktische Probleme stellt.

In Punkt 11 heißt es u.a.:

".. b) Soll hingegen aus dem Archivsystem heraus der Datenzugriff erfolgten, gilt Folgendes: Die nach § 147 Abs. 2 Nr. 2 Abgabenordnung geforderte "maschinelle Auswertbarkeit" von Daten ist durch ein Archivsystem nur sichergestellt bzw. gegeben, wenn das Archivsystem in quantitativer und qualitativer Hinsicht die gleichen Auswertungen ermöglicht als wären die Daten (einschl. Auswertungstools) noch im Produktivsystem. "

Der Knackpunkt ist "...die gleichen" (also nicht "gleichwertigen"!) Auswertungsmöglichkeiten!

Unter Punkt 12 wird definiert:

.. "Eine Nutzung von Auswertungsprogrammen (Auswertungstools) im Sinne des Abschn. I Nr. 2 a der GDPdU ist nach einem Wechsel des DV-Systems auch dann gewährleistet, wenn die zum neuen System gehörenden Auswertungsprogramme (Auswertungstools) in quantitativer und qualitativer Hinsicht die gleichen Auswertungsmöglichkeiten wie die des alten DV-Systems bieten. Ansonsten sind die Auswertungsprogramme (Auswertungstools) des alten DV-System in uneingeschränkt nutzbarem Umfang (z.B. durch Migration) bis zum Ende der Aufbewahrungsfrist vorzuhalten. Standardisierte Auswertungsprogramme, die zwar vorhanden (archiviert), aber nicht installiert sind, müssen für den Datenzugriff in maschinell auswertbarer Form zur Verfügung gestellt werden."

Salopp ausgedrückt: Die Auswertungsmöglichkeiten müssen immer die gleichen sein - bezogen auf die Ursprungsdaten und -Umgebung. Nach diesen Vorstellungen müsste man ggf. die alten Auswertungsprogramme auf die neue Umgebung migrieren oder aber aufbewahren.

Da nach allgemeinem technischem Erkenntnisstand die Auswertungstools (Programme) auf den Datenmodellen des zugehörigen Produktivsystems basieren, sind die Tools Bestandteil des Produktivsystem. Bei Änderung der Produktivumgebung, der Datenmodelle, werden sich auch die Auswertungstools ändern und damit eventuell auch die Auswertungsmöglichkeiten.

Da wollen wir doch mal von (z.B.) einer alten COMET-FIBU (Siemens-Nixdorf) auf eine AS/400-Lösung wechseln!! Oder von einer PROGRESS-Lösung auf eine VARIAL-Umgebung.

Oftmals ist es kaum möglich, durch Datenmigration die "alten" Daten auf die neue Umgebung zu migrieren, weil die Schlüsselsysteme (Kontenverschlüsselung, Zuordnungen zur Bilanz + GuV) nicht konform sind.

Viele Unternehmen strukturieren um oder haben dies vor und stimmen zu den neuen bzw. veränderten Geschäftsprozessen auch ihre IT-Prozesse ab. Dem BMF scheint das (noch) nicht klar zu sein! Hier können sich künftig die Gelehrten und Juristen streiten, was hier mit "gleich" gemeint sein soll und ob diese Anforderungen im Einzelfall zumutbar oder verhältnismäßig sind

Aus Sicht des Verfassers sind diese Forderungen des BMF im Einzelfall real kaum umsetzbar - hier wird mit Sicherheit nachgebessert werden müssen.

Die im "Fragen- und Antwortenkatalog" niedergelegte Anforderung nach qualitativ und quantitativ vergleichbaren Auswertungsmöglichkeiten muß sich sowohl an den technischen Gegebenheiten als auch an dem hierfür notwendigen Investitionsbedarf für das betroffene Unternehmen orientieren. Davon unabhängig ist jedoch die Anforderung einer grundsätzlichen maschinellen Auswertbarkeit zu sehen.

Ein Königsweg könnte insoweit in einem Datenarchiv mit "IDEA-Auswertbarkeit" gesehen werden! Für Z3 mit allen Strukturinformationen der ursprünglichen Daten- und Programmquellen.

Ein weiterer Lösungsansatz ist ein Datenarchiv mit Schnittstellen und Migration zu Auswertungstools, welche zwar parallel zum aktuellen Produktivsystem implementiert sind, aber von diesem technisch unabhängig (übergeordnet) sind. Also sinngemäß eine "Auswertungsschicht", unabhängig von der "Produktivschicht" und über Schnittstellen mit dem Datenarchiv gekoppelt. Hier geht z.B. die AUDICON Wege (AIS, TAX Mart) die durchaus begehbar sind!

Die GoBS - 1995, Verfahrensbeschreibung, Systemprüfung, Revisionssicherheit

In den Bereich der AO fällt auch die GoBS, die "Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme" (Schreiben des BMF an die obersten Finanzbehörden der Länder vom 7.11.1995). Schon begrifflich ist erkennbar, dass hier der Gesetzgeber integrierte DV-Systeme betrachtet.

Die GDPdU mit ihren Anforderungen zum auswertenden Datenzugriff kann als weitere Fortschreibung bzw. Ergänzung der GoBS betrachtet werden. Wie einst die GoB durch die GoS und diese durch die GoBS weiterentwickelt wurden und somit dem technischen Fortschritt folgten.

Da die GoBS maßgebliche Bestimmungen hinsichtlich der Dokumentation (Verfahrensbeschreibung), Prüfbarkeit und Revisionssicherheit von Buchführungssystemen beinhaltet, ist die GoBS auf jeden Fall im Zusammenhang mit Maßnahmen zur Implementierung der GDPdU zu betrachten und zu berücksichtigen.

Die Steuerberater - IT-Wissen ist notwendig!

Steuerberater sind Experten des Steuerrechts, jedoch nur in Ausnahmefällen IT-Spezialisten. Insoweit können sie kaum einen Bezug zu den komplexen technischen Fragen der IT herstellen. Die Fokussierung auf die EDV-Finanzbuchhaltung und deren Datenbestände und Auswertungen scheint manchen vor diesem Hintergrund ausreichend. Daß dies aber in vielen Fällen nicht zutrifft, wenn nämlich steuerrelevante Vor- oder Sub-Systeme Daten an die FIBU liefern, wird oftmals entweder nicht erkannt oder ausgeblendet.

Die GDPdU stellen sich in der Praxis vielmehr als eine interdisziplinäre Aufgabe dar, welche an der Schnittstelle - Steuerrecht und IT - Experten beider Professionen fordert. Nur ein Zusammenspiel aus Steuerrechts- und IT-Experten stellt eine ganzheitliche Sichtweise sicher und ist letztlich bei der praktischen Umsetzung der GDPdU zielführend.

Die steuerpflichtigen Unternehmen - Unsicherheiten, Risiken

In weiten Bereichen, vor allem dem ohnehin schon strapazierten Mittelstand, hat man in zunächst, 2002 und 2003 abwartend und hinhaltend reagiert. Manchen sind die teils massiven Auswirkungen der GDPdU auf die IT auch nicht vollumfänglich klar geworden.

IT-Fachleute erkennen die Brisanz.

Aber manche, wenn nicht sogar viele, Unternehmen zweifeln Notwendigkeiten bestimmter Ausführungen an, argumentieren mit vagen Auslegungen der Zumutbarkeit oder Verhältnismäßigkeit, und den -zugegeben - unklaren scheinenden Bestimmungen. Damit begibt man sich aber auf ein Glatteis, denn diese Klärungen werden in aller Regel wesentlich später bei Eintreten des Rechtsfalles vor dem Finanzgericht entschieden. Die erste Entscheidung zum Datenzugriff des FG Rheinland-Pfalz bildet hier erst den Anfang, gibt aber bereits eine erste Richtung vor.

Tatsache ist, dass die entsprechenden Paragraphen der AO und die GDPdU seit Januar 2002 rechtswirksam sind, 14.000 IDEA-Systeme von den Finanzbehörden längst beschafft sind und die flächendeckende Ausbildung der Betriebsprüfer voll im Gange ist. So ist im Bundesland Bayern inzwischen jeder Betriebsprüfer mit IDEA ausgestattet und entsprechend ausgebildet. In anderen Bundesländern wird es sicher ähnlich sein.

Ein "Aussitzen" der Probleme seitens der steuerpflichtigen Unternehmen wird mit Sicherheit keine tragfähige Lösung sein und im Ernstfall bei der Steuerprüfung im Zweifel sanktionsbewehrt sein.

Die Nichtbeachtung der GDPdU wird zumindest dazu führen, dass das Prüfungsklima nachhaltig gestört ist und dies mag viele Unternehmen mehr beunruhigen als das Sanktionsschwert, dessen Schärfe ohnehin in Frage steht.

Pragmatisches Handeln ist also unausweichlich und sinnvoll!

Die Hersteller kaufmännischer Standardsoftware - die "Insel der Seligen"

Warum "Insel der Seligen"? Mit Verwunderung ist manchmal zu beobachten, wie konsequentes "Insel-Denken" Probleme ausblendet, denen man sich nicht stellen kann oder will.

Der Verfasser ist der Meinung, dass die Hersteller von Standardsoftware des Rechnungswesens auch Berater ihrer Kunden sind und deshalb diese auch darauf hinweisen sollten, dass mit einer GDPdU-konformen Lösung innerhalb ihrer Standardsoftware als "Insel" nicht alle Aufgaben gelöst sein könnten.

Wenn nämlich, wie es häufig der Fall ist, steuerrelevante "Fremddaten" als Schnittstellen an die Standardsoftware übergeben werden, ist zu prüfen, ob diese Daten in den GDPdU-Lösungen der Standardsoftware auch auswertbar gemäß Z1 - Z3 sind!

nn nicht, dann ist eine korrekte Beratung und ein Hinweisen auf diese Probleme wichtig für den Anwender und es müssen Möglichkeiten gesucht werden, diesen Problemkreis einer Lösung zuzuführen!

Die Hersteller von MIS-Systemen - Chancen erkannt?

Für die Hersteller von MIS (BI, OLAP On-Line Analytical Processing) - Systemen ergibt sich durch die GDPdU und dazu generierbarem Zusatznutzen ein weites und ergiebiges Betätigungsfeld. Ob das in der Breite erkannt wird?

"Information Warehouse on Demand" - das wäre ein Konzept mit Strategieansatz!

Grundlage wäre ein Datenarchiv, sowohl für GDPdU wie auch andere strategische Unternehmensdaten, mit Schnittstellen und Migration zu den Auswertungstools des MIS, welche zwar parallel zum aktuellen Produktivsystem implementiert sind, aber von diesem technisch unabhängig sind. Also sinngemäß eine "Auswertungsschicht", unabhängig von der "Produktivschicht" und über Schnittstellen mit dem Datenarchiv gekoppelt.

Dabei könnten insbesondere auch hier durch die zunehmende Akzeptanz des empfohlenen Beschreibungsstandards (s.u.) Synergien zum Tragen kommen, welche derartige Lösungen neue Chancen eröffnen.

Die Hersteller von DMS - Daten und Dokumente

Die heute verfügbaren GDPdU-Lösungen der DMS-Hersteller setzen auf meist dem sogenannten Beschreibungsstandard für Datenträgerüberlassung (BMF, AUDICON) auf. Gemäß dieser Spezifikation sind die Nutzdaten mit konsistenter XML-Beschreibungsdatei an diese GDPdU-Lösungen zu übergeben.

Grundsätzlich bedeutet das aber, dass man eine Datenträgerüberlassung gemäß Z3 produziert. Also Daten bereitstellt, als wären sie für IDEA direkt bestimmt.

Was ist aber bei einer heterogenen Softwareumgebung, also einem MIX von Software und Schnittstellen?

Es wird nicht beschrieben, dass es für eine validierte und kontrollierte Datenübergabe dann einer gesonderten Entwicklung bedarf, wenn außer bei Standardsoftware, für die der Hersteller die Z3 realisiert hat, Daten diverser andere Programme an das DMS übergeben werden sollen. Das ist erfahrungsgemäß mit teils erheblichem Aufwand verbunden.

So ist z.B. sicherzustellen, dass Datenbestände nicht versehentlich doppelt übergeben werden, dass die Feld (Spalten) - Beschreibungen für den Prüfer klar interpretierbar sind, dass datentechnische Fehler vor der Übergabe erkannt werden müssen. Insbesondere müssen Strukturänderungen in den Daten erkannt werden.

Werden vom Steuerpflichtigen solche Implementierungen für die Übergabe gemäß Z3 programmiert, so ist zu bedenken, dass diese individuell erstellten Programme in den Anwendungsumgebungen zu implementieren sind, die später möglicherweise einem System- oder Releasewechsel unterliegen.

Die DMS-Hersteller sind also gut beraten, hier nach Standardlösungen zu suchen, die im Vorfeld der Datenübergabe an das DMS eine konfliktfreie Koppelung unterschiedlichster Schnittstellen ermöglicht.

IDEA - Daten validieren und auswerten, eine Präventivaufgabe

Im Kern ist bei der GDPdU die Steuerprüfung die letzte und einzige auswertende Instanz für steuerrelevante Daten! Diese Daten betreffen zurückliegende Geschäftsjahre. Im technisch klassischen Sinne ist aus Sicht des Produktivsystems eine Teilmenge "Altdaten".

Es ist davon auszugehen, dass nach der Implementierung einer GDPdU-Lösung, deren wesentlicher Kern auch im Z3-Zugriff zu sehen ist, steuerrelevante Daten rückwirkend kontinuierlich aus einer Produktivumgebung an ein - wie auch immer geartetes - Archiv bzw. Datenarchiv übergeben werden. Es ist also hohe Konzentration auf alle Kontrollfunktionen anzuwenden, die Fehlerquellen bei der Datenablage für die spätere Steuerprüfung ausschließen helfen. Diese Kontrollfunktionen müssen so implementiert sein, dass Fehler oder Veränderungen im aktuell abzulegenden Datenstrom erkannt und automatisch reklamiert werden. Diese Kontrollfunktionen müssen jene Instanzen ersetzen, die üblicherweise im operativen Bereich als Anwender solcher Daten mögliche datentechnische Fehler erkennen und deren Korrektur veranlassen. Hierzu das klassische Beispiel der Rechnungsdatenübergabe an die FIBU. Sollte in den Rechnungsdaten aus der Fakturierung ein Fehler sein, so wird dieser mit Sicherheit in der FIBU erkannt!

Wenn nun - vielleicht nach Jahren - die steuerliche Außenprüfung gemäß GDPdU auf lange vorher abgelegte Daten auswertend zugreift und feststellt, dass diese fehlerhaft sind, dann ist es wahrscheinlich zu spät um Korrekturen vorzunehmen zu können.

Zu unterstellen ist auch, dass bei einer Datenablage steuerrelevanter Daten für die GDPdU kein Verantwortlicher die Daten inhaltlich genau kennen kann. Wer kann denn schon wirklich behaupten, den Inhalt und damit die generierbaren Informationen von Dateien zu kennen und dafür beim Eintritt des Ereignisses (Betriebsprüfung) auch die Verantwortung übernehmen zu können!

Die IT ist Dienstleister des Unternehmens und für die Daten verantwortlich, sowohl gegenüber den Fachbereichen (Rechnungswesen) wie auch der Unternehmensleitung.

IDEA ist ein mächtiges Tool für Auswertungen auf Daten unterschiedlichster Herkunft und Struktur. Es ist ein Irrglaube zu unterstellen, dass IDEA alleine für die Prüfer interessant wäre!

Im Gegenteil! Wenn man Daten für Z3 bereitstellt, sollte man diese Daten immer (!) mit IDEA prüfen um sicherzustellen, dass die Daten korrekt sind und auch nur die Daten beinhalten, die wirklich für die Steuerprüfung bestimmt sind! Im Rahmen einer GDPdU-Implementierung verhilft IDEA allen Beteiligten dazu, die Z3-Datenbestände zu prüfen um dann auch die Verantwortung für die Daten übernehmen zu können.Im Gegenteil! Wenn man Daten für Z3 bereitstellt, sollte man diese Daten immer (!) mit IDEA prüfen um sicherzustellen, dass die Daten korrekt sind und auch nur die Daten beinhalten, die wirklich für die Steuerprüfung bestimmt sind! Im Rahmen einer GDPdU-Implementierung verhilft IDEA allen Beteiligten dazu, die Z3-Datenbestände zu prüfen um dann auch die Verantwortung für die Daten übernehmen zu können.

IDEA sollte man also durchaus als notwendigen Bestandteil eines GDPdU-Projektes betrachten. Die Vorteile wiegen die Kosten auf jeden Fall auf.

Mit IDEA kann man im Wesentlichen eine einfache technische Datenvalidierung sicherstellen. Die "kaufmännische Validierung", also Konsistenz der Buchungswerte nur eingeschränkt. Hier müssen noch Lösungen gesucht werden, die eine kaufmännische Validierung auf der Grundlage des Buchungstoffes einer Finanzbuchhaltung ermöglichen.

Was sind steuerrelevante Daten - die Problematik von Schnittstellen

Generell greift die GDPdU für alle "originär digital erzeugte Unterlagen".

Die Steuerrelevanz von Daten wird vom BMF nicht definiert. Diese Qualifizierung ist vom steuerpflichtigen Unternehmen in Zusammenarbeit mit dem Wirtschaftsprüfer / Steuerberater vorzunehmen. Dies bedeutet, dass die Qualifizierung nicht restriktiv, sondern im Sinne von "steuerrelevant" und "eventuell steuerrelevant" zunächst weit auszulegen ist. Später, zum Zeitpunkt der Prüfung, muß dann die Möglichkeit bestehen, aus den abgelegten Daten nur die vom Prüfer gewünschten bzw. in enger Auslegung tatsächlich steuerrelevante Daten zu übergeben.

Davon betroffen sind alle Daten eines Geschäftsjahres. Sowohl Daten aus den steuerrelevanten Hauptsystemen (z.B. verdichtet FIBU, LOHN), wie auch unverdichtete Daten aus Vorsystemen (Schnittstellendaten), die in automatisierten Prozessen zur Buchung an die Hauptsysteme übergeben werden. Als klassische Beispiele gelten hier automatisiert erzeugte Rechnungsdaten mit Schnittstelle zur Finanzbuchhaltung, Bestandsbewegungen aus der Lagerbuchhaltung/Warenwirtschaft. Insbesondere auch EDI-Daten des ausgehenden Rechnungsverkehrs als Bestandteil der automatisierten logistischen EDI-Prozesse. Hier wird aller Voraussicht nach der Z3-Zugriff Priorität haben. Es ist anzunehmen, dass diese Zugriffsform für unverdichtete Schnittstellendaten aus Vorsystemen überwiegend angewendet wird, weil häufig diese Daten in den Auswertungssystemen der Produktivumgebung nicht direkt in Erscheinung treten, da sie z.B. verdichteten Buchungen bereits enthalten sind.

Z1 und Z2 - keine Probleme bei Systemänderungen?

Wie beschrieben, beträgt die Aufbewahrungsfrist für Unterlagen/Daten, die der steuerlichen Außenprüfung unterliegen, in der Regel 10 Jahre. Da im Einzelfall einer Steuerprüfung ggf. auch auf Daten zurückliegender, bereits geprüfter, Jahre zurückgegriffen werden kann, muß man den Aufbewahrungszeitraum mit ca. bis zu 12 Jahren gleitend annehmen.

Dieser Zeitrahmen sprengt wahrscheinlich den Betrachtungszeitraum von Daten und Dokumenten, der üblicherweise unter betriebswirtschaftlichen Aspekten und aus Sicht der gesetzlichen Gewährleistung anzunehmen ist. Dieser Betrachtungszeitrahmen beträgt bei vielen Unternehmen ca. 3 - 5 Jahre.

Nach heutigen Erfahrungen ist auch zu unterstellen, dass eine Vielzahl von Unternehmen, gleichgültig welcher Größenordnung, zum gegenwärtigen Zeitpunkt nicht über Planungshorizonte verfügen - oder verfügen können -, welche die reale Zukunft ihrer IT-Umgebung für die nächsten zehn und mehr Jahre beschreiben.

Wenn es aber solche Planungen gibt und davon ausgegangen wird, dass sich mehr oder minder gravierende Änderungen in der System- und Softwarelandschaft ergeben, dann ist ein anwendersystemneutrales "steuerliches Datenarchiv" und die nachfolgend beschriebenen Planungen hierfür für die Zukunft erst recht substanziell brisant.

Diese sind mindestens:

• Planung eines systemunabhängigen Datenarchivs, dessen primärer Zweck die langfristige und strukturneutrale Datenhaltung für Z3 und eine unbestimmte  und heute nicht näher zu spezifizierende Auswertungssicht ist.
• Die Beschreibung der Strukturen muß mit den beschriebenen Daten unabhängig von der Anwendungsschicht sein. Die Strukturbeschreibungen sind also eigenständiges Mitglied des Datenarchivs und gehören zu den archivierten Daten.
• Das Datenarchiv muß unabhängig von System- und Releasewechseln auf der Anwendungsebene (Anwendungsschicht) sein.
• Festlegen einer Strategie für die Auswertungsmöglichkeiten (Tools) zum jeweils aktuellen Produktivsystem.
• Möglichkeit der Übergabe von Archiv-Daten an ein DMS als revisionssichere Datenbestände.

Z3 und IDEA - die Präferenz für die Betriebsprüfer?

Spricht man mit Experten der Finanzbehörde, so kann man immer wieder hören, dass Z3 für spezielle Datenanalysen mit Sicherheit angewendet wird. Nicht ausschließlich sondern kumulativ zu anderen Methoden der Betriebsprüfung.

Zu beachten ist dabei, dass es immer wieder steuerrelevante Datenbestände geben wird, die sich der Auswertung gemäß Z1 oder Z2 deshalb "entziehen", weil sie als unverdichtete Schnittstellen in Hauptsysteme (z.B. FIBU) übertragen werden und dort beim Einlesen verändert, kontiert, verdichtet, etc. werden.

Auf solche Datenbestände als Schnittstellendaten wird meist nur ein Z3-Zugriff sinnvoll und möglich sein.

Ein GDPdU-Projekt - Grundsätzliche Planungsschritte

Im Sinne einer groben Rahmenplanung sind für ein GDPdU-Projekt folgende wesentliche Punkte zu behandeln.

Beteiligte: Leitende und Spezialisten von Rechnungswesen, IT, Steuerberater.

• Klärung von Rahmenbedingungen wie z.B. Projektleitung, Ansprechpartner, Zuständigkeiten, externe Dienstleister (z.B. Softwarelieferanten).
• Klärung aller bestehender steuerrelevanten Inhouse-Anwendungen, Programme.
• Klärung zu GDPdU-relevanten Daten aus Outsourcing-Anwendungen (z.B. FIBU als Fremdleistung).
• Klärung Datenfluß zwischen steuerrelevanten Anwendungen (Schnittstellen).
• Klärung künftiger Systemstrategie: Releasewechsel, Systemwechsel, etc.
• Klärung der Implementierung oder Verfügbarkeit von GDPdU-Modulen im Bereich Standardsoftware des Rechnungswesens (s. Softwarelieferanten).
• Klärung der Notwendigkeit eines "GDPdU-Datenarchiv".
• Klärung der Präsentation steuerrelevanter Daten für die Außenprüfung. (Können die Daten in geeigneter und verständlicher Form bereitgestellt werden?)
• Klärung des periodischen Datenanfalls, also Termine, Perioden, Mengengerüste.
• Qualifizierung der Steuerrelevanz von Daten und Datenbeständen (Ggf. Abstimmung mit der zuständigen Finanzbehörde).
• Klärung zur Beschaffung oder Entwicklung von Software für die GDPdU-Realisierung.
• Klärung auf vorhandene oder fehlende Verfahrensbeschreibungen (s. GoBS).
• Planung der Vorgehensweise und Termine für die weiteren Schritte.
• Abstimmung des Kostenrahmens, Kosten von Teilprojekten.
• Klärung von Einzelprojekten, Zuständigkeiten und Ausführenden.
• Bericht für die Projektplanung und Realisierung GDPdU.
• Planung weiterer Schritte für eventuelle Erweiterungen oder Änderungen im Anwendungssystem und der Prozesse für zusätzlichen betrieblichen Nutzen. Siehe z.B. erweiterte Auswertungsmöglichkeiten (betriebliche Auswertungen), Daten- und Dokumentenarchiv. Zusatznutzen aus einem erweiterten GDPdU-Projekt!
• Abstimmung des diesbezüglichen Kostenrahmens.
• Planungs- und Strategiebericht.

Standardsoftware (Tools) für Langzeit-Datenarchive - Probleme zügig lösen

Wie wir bisher gesehen haben, können die Aufgaben, die aus den GDPdU resultieren je nach Ausprägung der Softwarelandschaft eines Unternehmens anspruchsvoll und vielfältig sein.

Die IT-Leitung als Dienstleister des Unternehmens muß genau überlegen, welche Systemerweiterungen in der Produktivumgebung in Eigenleistung und welche mit passenden Tools sinnvoll und mit möglichst geringem Zeit/Kostenaufwand zu realisieren sind.

Zentrale Funktionen eines Tools sind u.a.:

• Customizing und Generierung von Schnittstellen (IMPORT / EXPORT) für Datenübergabe zwischen Anwendungssoftware, Datenarchiv und Endanwendung (IDEA, Tools).
• Beschreibungssystem mit integrierter Dokumentation für Datenschnittstellen.
• Datenvalidierung auf Feld- und Dateiebene, Absicherung gegen Fehlimporte.
• Konnektoren für Fremdsysteme (Archivsysteme (DMS) und IMS-Tools).
• Auftragssteuerung, automatisierter IMPORT / EXPORT.
• Protokolle parallel zur Datenhaltung und zur Aufbewahrungsfrist.
• Benutzerverwaltung mit Zugriffsberechtigungen auf Datenebene.
• Kontroll- und Überwachungssystem.

Nach den Erfahrungen des Verfassers sind viele Funktionen, welche die erforderliche datentechnische Sicherheit, Überwachung und Protokollierung für die Zukunft gewährleisten müssen, nur mit erheblichem Aufwand individuell zu implementieren.

Es bietet sich an, vorgefertigte Standardlösungen, Tools, einzusetzen, die leicht und effizient auf die Anforderungen der Systemumgebung einstellbar sind um damit erheblich Zeit und Kosten einzusparen.

Die GDPdU - Herausforderung und Chance zugleich

Es existieren bei jedem Unternehmen durchaus sachliche und technische Grundlagen um die GDPdU "Zug um Zug" entsprechend den aktuellen Anforderungen zu implementieren.

Zugleich sollte man sein System in weiteren Schritten so ausstatten, dass man auch für absehbare Releasewechsel oder Systemwechsel mittel- und langfristig gesehen für die Prüfung gemäß GDPdU gut gerüstet ist.

Man kann auch durchaus die Situation nutzen, aus den Anforderungen der GDPdU eine "Revision" der implementierten Prozesse zu entwickeln, hin zu neuen Möglichkeiten, die betriebsinternen Auswertungen, Statistiken - Sicht auf die Unternehmenszahlen - zu erweitern und zu verbessern.

Bei vielen Unternehmen wird der Einsatz elektronischer Dokumentenarchive (DMS) nun erst recht sinnvoll sein und erforderlich werden. Man denke z.B. an die mögliche Ablösung von Microfilm-Systemen und insbesondere auch die durchaus massive personelle Entlastung und steigende Prozesseffizienz durch erhebliche Reduzierung der klassischen Papierablage.

Bei der Umsetzung der GDPdU ist also auch strategisches Denken hinsichtlich der Weiterentwicklung seiner IT angesagt!