Fast unbemerkt von der aktuellen Diskussion um die GDPdU rüstet die Finanzverwaltung demnächst vielleicht schon weiter auf. Die "IDEA-Waffe" wurde von der Firma Audicon mit einem Nachbrenner ausgestattet, der es in sich hat: Mit "AIS TaxAudit" lassen sich steuerrelevante Daten weitgehend automatisiert analysieren, so dass Unregelmäßigkeiten schnell ans Licht kommen. Ob und wann die Finanzverwaltung diese Makros einsetzen wird, ist zwar noch offen, doch die Unternehmen können bereits jetzt darauf zugreifen und sich so auf künftige, nicht nur digitale Betriebsprüfungen vorbereiten. Eile ist geboten, denn die Schonfrist für die Unternehmer ist schneller vorbei, als viele prognostiziert haben - die ersten digitalen Prüfungen haben bereits begonnen.
Bild: Photodisc
In der Diskussion um die GDPdU spielte die elektronische Archivierung und die Frage, wie man die Daten über einen Zeitraum von zehn Jahren vorhalten soll, eine wichtige Rolle. Anbieter elektronischer Archivsysteme waren mit schnellen Ankündigungen GDPdU-konformer Lösungen zur Hand, ohne eigentlich zu wissen, welche Anforderungen die Finanzverwaltung hier stellt. Auch die Flut diverser Checklisten und Leitfäden vermochte kein Licht in das Dunkel GDPdU-konformer Archivierung bringen.
Flut der Leitfäden
Als die Entwürfe zu den GDPdU zum ersten Mal im Jahr 2000 in die Öffentlichkeit gelangten, regte sich nur in Fachkreisen etwas Interesse. Selbst als die GDPdU rechtskräftig wurden, fand eine Diskussion lediglich in Fachzirkeln, bei den Archivsystemherstellern und bei Wirtschaftsprüfern sowie Steuerberatern statt. Erst sehr spät reagierten die Anwender. Zunächst die großen Unternehmen, in denen praktisch ständig eine Betriebsprüfung läuft und wo für den Prüfer längst der Zugriff auf die Daten möglich ist. Die breite Masse der Steuerpflichtigen und selbst die Steuerberater beginnen erst jetzt die Dimension der elektronischen Steuerprüfung zu erkennen.
Aufklärung tut not. So fühlen sich viele berufen, mit Argumentarien, Checklisten, Fragen- und Antwortenkatalogen, Leitlinien, Büchern, Folienvorträgen und Web-Seiten das Informationsbedürfnis zu stillen. Nach zwei Jahren GDPdU ist nunmehr eine Flut von Handreichungen zu beobachten. Einzelne Hersteller, Berater, Rechtsanwälte und Steuerberater, Verbände wie AWV, BitKOM, VOI sowie Industrie- und Handelskammern bedienen den Markt.
Doch nicht nur die GDPdU ließen Spielraum in der Interpretation, die erst zu dieser Flut von Leitfäden geführt hat, sondern auch die vielen Checklisten und Fragen- und Antwortenkataloge divergieren in ihren Aussagen. Dies ist zum Teil darauf zurückzuführen, dass sich durch den Praxiseinsatz der elektronischen Steuerprüfung laufend neue Auslegungen und Problemstellungen ergeben, zum Teil aber auch darauf, dass aus wirtschaftlichem Interesse oder aus Positionierungsgründen die eine oder andere Interpretation favorisiert wird. Das Bundesministerium der Finanzen (BMF) hat sich seinerseits an dieser Leitfadenflut beteiligt. Der aktuell in der dritten Fassung vorliegende Frage- und Antwortenkatalog vom März 2003 auf der Web-Seite des BMF hat zwar in vielen Fragen zur Klärung beigetragen. Eine Reihe der Antworten hat aber erneut zur Verunsicherung geführt.
Die vielen Leitfäden haben zumindest eine positive Komponente. Sie können den Bundesfinanzbehörden Orientierungshilfe sein und für bekannte Probleme praktikable Lösungen vorschlagen. Endgültige Klarheit kann es aber nur durch das BMF selbst geben. Die GDPdU müssen überarbeitet, GDPdU und GOBS aufeinander harmonisiert und der Fragen- und Antwortenkatalog im Internet muss durch eine belastungsfähige, nicht nur die Finanzbehörden selbst verpflichtende, Sicherheit schaffende Ausarbeitung offiziellen Charakters ersetzt werden. Solange das BMF selbst nicht für Klarheit sorgt, ist immer neuen Interpretationen und Leitfäden Tür und Tor geöffnet.
Im Dschungel der Definitionen
Die GoBS und die GDPdU benutzen eine Reihe von Begriffen, die auf Softwaresysteme zur Verarbeitung und Speicherung von Daten abzielen. Zur Klärung dieser Begriffswelt hat auch das BMF beigetragen, ohne allerdings mit seinem Fragen- und Antwortenkatalog die grundsätzlichen Missverständnisse ausräumen zu können.
Steuerrelevante Daten
Der sehr weiche Begriff der "steuerrelevanten Daten" ist unter zwei Gesichtspunkten zu betrachten: inhaltlich und technisch. Inhaltlich geht es darum, auf welche Informationen der Steuerprüfer im Rahmen einer Außenprüfung zugreifen darf. Diese Frage muss das steuerpflichtige Unternehmen in Abhängigkeit von seiner Geschäftstätigkeit zusammen mit seinem Steuerberater oder Wirtschaftsprüfer beantworten. Wichtig: Dies ist keine Aufgabe der Softwarebranche. Nach Auffassung der Bundessteuerberaterkammer gehört die Ermittlung der steuerlich relevanten Daten zu den "Vorbehaltsaufgaben" der steuerberatenden Berufe.
Dabei gilt, dass sich durch die GDPdU am fachlichen Umfang und Inhalt der Prüfung eigentlich nichts ändert, sondern dass sich die Form der Bereitstellung, des Zugriffs und der Auswertung an die technologische Entwicklung angepasst hat.
Immer mehr Information entsteht originär elektronisch und kann auch nur elektronisch ausgewertet werden. Technisch geht es darum, wie diese Informationen für eine Auswertung bereitgestellt werden kann. Steuerrelevante Daten können in einem Unternehmen in unterschiedlichen Systemen entstehen und gespeichert werden. Hier ist die Aufgabe, nach der fachlichen Qualifizierung der steuerrelevanten Daten die entsprechenden Systeme, Speicherorte und Formate zu ermitteln, um die Daten anhaltend auswertbar bereitzustellen.
"Originär elektronische Unterlagen"
Bei originär elektronischen Unterlagen handelt es sich in erster Linie um Daten, die in einem kaufmännischen System durch Verarbeitungsschritte entstanden sind. Bei der Entstehung dieser Daten sind unterschiedliche Quellen zu berücksichtigen. Sie können aus anderen Datenverarbeitungssystemen importiert (siehe Nebensysteme und vorgelagerte Systeme), von Dritten durch Datenübertragung übermittelt (zum Beispiel EDI, E-Mail) oder aber durch manuelle Eingaben erfasst worden sein. Durch die Verarbeitung, das heißt im wesentlichen durch die Zuweisung zu Vorgängen, Konten, Lieferanten oder Kunden, durch Berechung von abgeleiteten Werten, Zuordnung von Stammdaten und andere Operationen der Programmlogik entstehen erst die originär elektronischen, steuerrelevanten Daten. Die Rohdaten vor der Verarbeitung haben daher eher einen Belegcharakter, der die Nachvollziehbarkeit der durchgeführten Operationen der Software sicherstellen muss.
"Maschinell auswertbare Daten"
Steuerrelevante Daten sind maschinell auswertbare Daten aus kaufmännischen Softwaresystemen, die als Datensatz vorliegen. Jeder Datensatz repräsentiert eine steuerrelevante Transaktion und beinhaltet alle notwendigen Informationen, die für eine steuerliche Veranlagung im Sinne von Entstehen, Entfallen oder Minderung einer Steuerlast relevant sind. Er setzt sich hierfür aus identifizierenden Attributen und Stammdaten wie Konto, Adressat, Steuersatz etc., Zweck oder Objekt und den Werten wie Betrag, Währung und Datum zusammen. Die Vollständigkeit und der Zusammenhang dieser Attribute sichert die Auswertbarkeit des Datensatzes im Kontext. Diese Daten müssen in Deutschland strukturiert, geordnet, periodengerecht und vollständig durch die Software "IDEA" (offizielle Prüfsoftware der Finanzverwaltung) in der jeweils gültigen Version auswertbar bereitgestellt werden. Anders sieht dies mit Dokumenten aus, zum Beispiel 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.
"Nicht maschinell auswertbare Belege"
Belege sind der Nachweis zum Datensatz mit den steuerrelevanten Daten. Belege sind in der Regel nicht maschinell automatisch auswertbare, schwach strukturierte oder unstrukturierte Dokumente. Entsprechend ihrer Entstehung können sie beim Steuerpflichtigen in Papier, elektronischer oder anderer Form vorliegen. Sind die Dokumente originär elektronisch entstanden oder beim Steuerpflichtigen originär elektronisch eingegangen, so sind sie im Originalformat mit den dazugehörigen Entstehungs- oder Eingangsdaten zu speichern. Elektronische Dokumente können auch als strukturierte Datensätze vorliegen und müssen dann auch für eine maschinelle Auswertung bereitgestellt werden.
Elektronische Dokumente müssen über einen eindeutigen Index wieder auffindbar und über die Attribute des Index eindeutig mit dem dazugehörigen steuerrelevanten Datensatz verknüpft sein. Diese Dokumente sind so zu speichern, dass - keine Veränderung der Dokumente selbst möglich ist, - die Beziehung zwischen Dokument und zugehörigem Datensatz nicht aufgelöst oder verändert werden kann und - der Bestand der Dokumente gegen Verlust und Veränderung geschützt ist.
Das System hat sicherzustellen, dass die gespeicherten Dokumente über den vorgegebenen Aufbewahrungszeitraum recherchiert und verlustfrei zur Anzeige gebracht werden können. In der Dokumentation nach GoBS ist dieses Verfahren nachprüfbar zu beschreiben und die Prozesse müssen durch eine revisionssichere Protokollierung nachvollziehbar sein.
Die Zugriffsarten
Beim Datenzugriff nach den GDPdU ergeben sich je nach Typus unterschiedliche Zugriffsarten. Für originär elektronische Unterlagen ist die direkte Auswertbarkeit der Daten für die Zugriffsarten Z1 (unmittelbarer Zugriff) und Z2 (mittelbarer Zugriff) sowie Z3 (Datenträgerüberlassung) sicherzustellen. Liegen die Daten noch im operativen System, also in der sie ursprünglich erzeugenden Anwendung vollständig vor, kann Z1 und Z2 direkt auf diesen Datenbestand erfolgen. Die Anwendung muss jedoch in der Lage sein, auch Datenträger nach Z3 für die Auswertung mit IDEA zu erzeugen. Für nicht maschinell auswertbare Belege gilt, dass die Dokumente über die Attribute des Index im ersten Schritt recherchiert werden, um dann im zweiten Schritt angezeigt zu werden.
Durch die vorgeschlagene Unterscheidung zwischen maschinell auswertbarem Datensatz und zugehörigem, nicht maschinell auswertbarem Belegdokument ist das Problem der steuerrelevanten Daten lösbar. Letztlich lässt sich damit unabhängig von der Form der Daten und Dokumente die "Auswertbarkeit" als "wahlfreier Zugriff auf die steuerrelevanten Daten" beschreiben.
Datenverarbeitungssystem im Sinne der GDPdU
Durch die GDPdU sind eine Reihe von unterschiedlichen Datenverarbeitungssystemen betroffen. Je nach dem, in welchem Umfang steuerrelevante Daten in ihnen entstehen und gespeichert werden, ist ihre Relevanz für eine elektronische Steuerprüfung verschieden. Daher ist eine Differenzierung notwendig.
Das Hauptsystem
Unter einem Hauptsystem ist das aus Software und Hardware bestehende System zu verstehen, in dem die originär steuerrelevanten Daten verarbeitet und gespeichert werden. Dies sind in der Regel kaufmännische Anwendungen, ERP- und Buchhaltungssysteme. Solange dieses Hauptsystem im Betrieb ist, spricht man auch vom operativen, Produktiv- oder Produktionssystem, um es von stillgelegten, redundanten Sicherheits- oder im Testbetrieb befindlichen Systemen zu unterscheiden. Unter einem Produktivsystem versteht man somit eine Anwendung, die aktiv und nutzbar ist und welche 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. Das Hauptsystem mit seiner Programmfunktionalität und seinen Auswertungsmöglichkeiten erfüllt auch die Voraussetzungen von Z1 (unmittelbarer Zugriff) und Z2 (mittelbarer Zugriff). Es sollte auch die Erstellung von
Datenträgern nach Z3 (Datenträgerüberlassung) ermöglichen.
Vorgelagertes System
Vorgelagerte Systeme sind Lösungen, mit denen steuerrelevante Daten und Belege erfasst und verarbeitet werden (zum Beispiel Scannen mit automatischer Klassifikation von Rechnungen und 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 und nachvollziehbar sind und die originäre Information nicht verändert wird.
Häufig geben diese vorgelagerten Systeme aber nur Teile oder konsolidierte, verdichtete Daten an das Hauptsystem ab. Die Auswertbarkeit dieser Daten im Sinne des wahlfreien Zugriffs ist im Hauptsystem dann nicht mehr vollständig gegeben. Bei vorgelagerten Systemen kann es sich zum Beispiel um Kassensysteme, Zahlungsverkehrssysteme oder andere Lösungen handeln, in denen steuerrelevante Daten entstehen. Die Daten dieser Systeme rechnen zum Umfang einer digitalen Außenprüfung. Vorgelagerte Systeme sind im Regelfall nicht darauf ausgelegt Z1 und Z2 zu unterstützen und besitzen auch keine Funktionalität, um selektiv Datenträger nach Z3 zu erstellen. Häufig sind die Datenmengen so groß, etwa in Kommunikations-, Energie- und Handelsunternehmen, dass eine vollständige Übergabe nach Zugriffsart Z3 unmöglich ist.
Nebensystem
Unter Nebensystemen versteht man Systemlösungen, in denen steuerrelevanten Daten entstehen, gespeichert und verarbeitet werden, die nicht oder nur sehr stark verdichtet im Buchhaltungs- oder ERP-System vorliegen. Hierbei kann es sich um Materialwirtschafts-, Zeiterfassungs- oder E-Business-Anwendungen handeln, die eine eigenständige Logik und Speicherung besitzen. Die Daten dieser Systeme dürfen auch der elektronischen Steuerprüfung unterworfen werden. Sofern die steuerrelevanten Daten in diesen Systemen qualifiziert und identifiziert werden können, kann auch ein direkter Zugriff über die Anwendung möglich sein. Da Nebensysteme aber in der Regel nicht über den Programm- und Datenaufbau wie ein kaufmännisches System verfügen, kann der Zugriff nach Z1 und Z2 beschränkt sein. Es besteht daher im Regelfall auch bisher nicht die Möglichkeit, aus solchen Nebensystemen Datenträger für Z3 zu erstellen.
Archivsystem
Archivsysteme kommen erst dann ins Spiel, wenn in den operativen Haupt-, Neben- und vorgelagerten Systemen die steuerrelevanten Daten des Prüfungszeitraums nicht mehr auswertbar vorliegen. Angesichts der Aufbewahrungsfristen von sechs oder zehn Jahren ist die Auslagerung von Datenbeständen aus den Produktivsystemen besonders bei mittleren und größeren Anwendungen der Regelfall. In Archivsystemen entstehen jedoch selbst keine steuerrelevanten Daten, sondern sie dienen lediglich der Speicherung und der Bereitstellung der Daten. Die Auswertbarkeit und die Vollständigkeit muss von den Hauptsystemen und den Nebensystemen bereits bei der Übergabe der Daten an das Archivsystem sichergestellt sein. Die Frage der Aufgaben eines Archivsystems soll im Folgenden noch näher betrachtet werden.
Universelles Auswertungsprogramm für steuerrelevante Daten
Die Diskussion um ein universelles Auswertungsprogramm entstand durch den Artikel "Rückstellung für Kosten des Datenzugriffs der Finanzverwaltung" von Groß, Lindgens und Matheis (veröffentlich im DStR Heft 23/2003, S. 921ff), in dem die Lösung der Archivierungsproblematik beschrieben wurde. Wenn Archivsysteme selbst nicht mehr über die Auswertungslogik des Hauptsystems verfügen müssen, wenn es nur noch vollständige, auswertbare steuerrelevante Daten übernimmt und auf Anforderung wieder bereitstellt, muss die Auswertbarkeit der steuerrelevanten Daten mit anderen Mitteln sichergestellt werden. Hier kommt natürlich sofort das Auswertungsprogramm ins Spiel, mit dem die Finanzbehörden prüfen. Zumindest für die Daten nach der Zugriffsart Z3 ist dies der gesetzte Auswertungsstandard, der die Struktur der Daten vorgibt.
Das Bundesministerium der Finanzen scheut sich natürlich, ein einzelnes Produkt wie IDEA offiziell zu verankern. Man kann Wettbewerbsprodukte wie ACL nicht grundsätzlich benachteiligen. Mit einer Festlegung auf IDEA hätte man jedoch den Vorteil, dass die Funktionalität und die benötigten Strukturen bekannt sind. Will man jedoch einen neutralen Begriff wie "universelles Auswertungsprogramm" benutzen, muss der Funktionsumfang auch neutral definiert werden. Die Formulierung aus dem Fragen- und Antwortenkatalog des BMF vom März 2003, dass bei der Auslagerung der steuerrelevanten Daten aus dem operativen System für die Archivierungssysteme die gleiche Auswertungsfunktionalität wie bei dem die Daten erzeugenden System vorhanden sein soll (Frage und Antwort Nr. 11), greift bei Auswertungsprogrammen wie IDEA oder ACL nicht mehr.
Keine Zertifizierung für Archiv und Speichersysteme
In jüngst erfolgten Stellungnahmen auf Eingaben hat das BMF deutlich gemacht, dass es weder für Speichersubsysteme noch für Archivsysteme eine Zertifizierung gibt oder geben wird. Damit erübrigen sich auch die Diskussionen um die Marketing-Slogans "GDPdU-konforme Archivierung" und die Frage des "richtigen" Speichermediums. GDPdU-Konformität beschränkt sich auf die Vollständigkeit und Auswertbarkeit der Daten selbst. Dies ist Angelegenheit der die Daten originär erzeugenden Systeme. Das "richtige" Speichermedium gibt es nicht. Eine Festlegung auf nur eine Technik ist weder sinnvoll noch angesichts des schnellen technologischen Wechsels machbar. Sicherheit und Verfügbarkeit sind außerdem nicht allein vom Speichermedium abhängig. Die gespeicherte Information muss auch auslesbar, anzeigbar und verarbeitungsfähig sein. Hierfür sind entsprechende Betriebssysteme, Treibersoftware und Verarbeitungsprogramme notwendig. Die Information auf einem
sicheren Speicher zu haben nützt nicht viel, wenn man sie nicht mehr verwenden kann.
Dementsprechend kann man heute verschiedene Techniken als mehr oder weniger gleichberechtigt betrachten, wenn es um die veränderungssichere Speicherung von steuerrelevanten Daten geht. Traditionelle WORM-Technologien mit unterschiedlichen Verfahren stehen dabei zu CD und DVD, speziell abgesicherten Festplattensubsystemen und WORM-Bändern für Tape-Libraries im Wettbewerb. Entsprechend der beim Anwender im Einsatz befindlichen IT-Infrastruktur wird das eine oder andere Verfahren bevorzugt: in Rechenzentren etwa WORM-Tapes oder Festplattensubsysteme, bei Anwendern mit vorhandenen Archivsystemen traditionelle WORM-Medien und bei Kleinanwendern eher CD und DVD. Letztere eignen sich besonders, wenn man alle Daten einer Periode auf nur einem Medium unterbringen kann.
Revisionssicherheit
Grundsätzlich sollte jedoch gelten: Ein Medium allein reicht nicht aus! Es geht um die Erstellung von Sicherheitskopien, die regelmäßige Prüfung der Medien und Sicherheitskopien auf Lesbarkeit und Verarbeitungsfähigkeit, die Migration auf neue Medien sowie andere Themen der Sicherheit. Revisionssicherheit ist hierbei mehr als nur technische Sicherheit zum Schutz vor Veränderung. Sie schließt den ganzen Prozess von der Entstehung der Daten bis zu ihrer Entsorgung ein. Speichermedien und Speichersubsysteme stellen daher nur eine Komponente eines revisionssicheren Systems dar.
Im Vordergrund der Überlegungen zur Revisionssicherheit steht die Information und ihr Kontext. Wie die Information aufbewahrt wird ist wichtig, aber im Rahmen eines Gesamtkonzeptes zur revisionssicheren Archivierung nur ein Baustein. Die Wahl des Mediums muss dem Wert der Information gerecht werden. Die Erfüllung gesetzlicher Vorgaben ist hierbei auch nur ein Aspekt des Wertes von Information. Archivsysteme nur für die Erfüllung der GDPdU, also nur zur Speicherung steuerrelevanter Daten, die ein Prüfer vielleicht in ein paar Jahren auswerten will, sind unwirtschaftlich. Elektronische Archivsysteme machen nur dann Sinn, wenn man sie auch zur Speicherung aller anderen elektronischen Informationen eines Unternehmens einsetzt. Steuerrelevante Daten sind dann nur noch ein spezieller Informationstyp, der vom universellen Unternehmensarchivsystem quasi nebenbei mitverwaltet wird.
Zugriff auf das Hauptsystem?
Beim Vorhaltenden der Daten für den unmittelbaren beziehungsweise mittelbaren Datenzugriff der Finanzverwaltung wurde immer wieder die Frage gestellt, in welchem Bereich der Unternehmens-EDV dies zu gewährleisten ist. Das Gesetz, nichts anderes bindet den Steuerpflichtigen, geht von einer Auswertung der steuerlich relevanten Datenbestände im Haupt- oder Produktivsystem aus. Um dieses jedoch nicht mit einer zu großen Datenmenge zu überlasten, sind Archivsysteme notwendiger Bestandteil der meisten IT-Umgebungen. Archivierte Daten müssten so für Zwecke der Betriebsprüfung in das laufende System zurückgespielt werden um eine Verarbeitung mit den dort vorhandenen Auswertungsmöglichkeiten zu gewährleisten. Doch genau hier entstehen große technische Probleme, da es beim Zurückladen dieser alten Daten in der Regel zu Unverträglichkeiten mit den inzwischen aktualisierten Systemen kommt. Dies betrifft nicht nur die auszuwertenden Daten, sondern
besonders die Strukturinformationen und veränderte Stammdaten.
Einfacher wäre es, archivierte Daten durch einen direkten Zugriff auf das Archivsystem auszuwerten - die meisten Lösungen halten dafür jedoch nur eingeschränkte Möglichkeiten vor.
Revisionssichere elektronische Archivsysteme zur Aufbewahrung steuerrelevanter Daten
Die Diskussion um die elektronische Archivierung hat inzwischen zu einer Klarstellung geführt. Elektronische Archivsysteme müssen selbst keine Auswertungsfunktionen wie ein Hauptsystem oder eine universelles Auswertungsprogramm besitzen. Sie unterliegen jedoch dann den Anforderungen der GDPdU:
Der wahlfreie Zugriff muss so abgebildet werden, dass die entsprechenden archivierten Daten auch vollständig bereitgestellt werden.
Die Speicherung muss so erfolgen, dass die Unveränderbarkeit der Daten sichergestellt ist.
Das Archivsystem muss in quantitativer und qualitativer Hinsicht Auswertungs-möglichkeiten gewährleisten, die denen des Hauptsystems gleichwertig sind.
Während in anderen Gesetzen immer nur von Speicherung und Aufbewahrung die Rede ist, wird hier konkret von digitalen Speichermedien und Archivierung gesprochen. Die GDPdU verweist hier auf die entsprechenden Passagen in der Abgabenordnung (AO) und führt aus: "Originär digitale Unterlagen nach § 146 Abs. 5 AO sind auf maschinell verwertbaren Datenträgern zu archivieren." Wie dies im Einzelfall zu geschehen hat, ist in den GoBS nachzulesen. Für das Thema Archivierung gewinnt die GoBS damit eine größere Bedeutung als die GDPdU selbst. Originär digitale Unterlagen nach der AO und den GoBS sind aber nicht nur maschinell auswertbare Datensätze, sondern auch Dokumente.
Der Begriff maschinell verwertbarer Datenträger impliziert, dass es einen Zugriff auf die Daten auf dem Speichermedium gibt. Nach den GDPdU heißt dies "wahlfreier Zugriff mittels eines Programmes". Im Prinzip sind dies für elektronische Archivsysteme Selbstverständlichkeiten, da sie in der Regel über eine Datenbank zielgenau die gewünschten Daten ermitteln und bereitstellen. Bei kleineren Datenmengen, die als Dateien gespeichert sind, kann sogar der Zugriff über ein Dateiverwaltungssystem ausreichend sein. Entscheidend ist jedoch unter dem Gesichtspunkt der Aufbewahrungsfristen, dass die Information über einen bestimmten Zeitraum maschinell verarbeitungsfähig bereitsteht. Angesichts der schnellen Veränderung von Komponenten, Betriebsystemen, Formaten und Standards eine Aufgabe, die nur durch die rechtzeitige, verlustfreie, die Information selbst nicht verändernde, dokumentierte und nachvollziehbare Migration der Daten von einem Medium auf ein anderes
bewältigt werden kann.
Der Anforderung, das Archivsystem mit Auswertungen zu versehen, die jenen im Produktivsystem in quantitativer und qualitativer Hinsicht gleichwertig sind, kann ein Archiv mit IDEA-Funktionalität bei entsprechender Ausgestaltung durchaus gerecht werden. Doch was bedeutet dies für die praktische Umsetzung und reicht IDEA wirklich aus?
IDEA-Client zielführend
Die Diskussion um die GDPdU war für den Steuerpflichtigen - und auch für die Steuerberater selbst - mehr als verwirrend. So stellt sich bei vielen die Frage, warum ein "IDEA-Client" eine neue Qualität bringen soll. Das BMF hat selbst in einem Schreiben diesen Ansatz als "zielführend" und "substantiiert" bezeichnet. Für den Anwender bringt dies eine Vielzahl von Vorteilen. Wenn man mit einer unabhängigen Auswertungssoftware die steuerrelevanten Daten auswerten kann, muss man sie weder im operativen System vorhalten, noch muss man sie in dieses System zurückladen.
Besonders bei größeren Anwendungen ist es üblich, nicht mehr benötigte Daten aus dem operativen System auszulagern, um es zu entlasten, die Performance zu steigern und Online-Speicherplatz zu sparen. Wollte man im laufenden Betrieb alte Daten wieder in das System zurückladen, gäbe dies vielfach Probleme. Die Installation kann sich geändert haben, Strukturen, Formate und Stammdaten haben sich verändert, die Altdaten würden Laufzeit und Stabilität der genutzten Produktivumgebung beeinträchtigen. Statt dessen braucht man "nur" noch sauber aufbereitet die Daten an ein externes Speicher-, Archiv- oder Datensicherungssystem übertragen und kann sie bei Bedarf dem Steuerprüfer zur Auswertung unabhängig bereitstellen. Bei der Übergabe der Daten kommt es jedoch besonders darauf an, auch die richtigen Strukturinformationen über den Aufbau der Dateien und im System vorhandene Auswertungen mit zu übergeben. Die Beschränkung auf die
IDEA-Funktionalität erlaubt dem Steuerpflichtigen darüber hinaus seine Daten zu testen, bevor sie unveränderbar archiviert werden. Vollständigkeit und Auswertungsfähigkeit können so sichergestellt werden. Dies verringert Unsicherheit, Abhängigkeit und spart Kosten.
So erübrigt sich auch die Anforderung aus dem BMF-Fragen-und-Antwortenkatalog, in der die gleiche Auswertungsfunktionalität gefordert wurde, wie sie das Ursprungssystem besitzt. Bei einem größeren ERP-System gibt es Hunderte von Auswertungen, nahezu beliebige Kombinations- und Recherchemöglichkeiten, die nie in einem Archivsystem hätten nachgebildet werden können. Wenn nun die Auswertung mit IDEA ausreichend ist, kann man auch gleich einen Schritt weiter gehen und einen IDEA-Client konzipieren, der direkt auf den archivierten Dateien nebst zugehörigen Stammdaten und Strukturinformationen alle drei Zugriffsarten Z1, Z2 und Z3 realisiert. Da die Auswertungsalgorithmen vorhanden sind, ist der Schritt vom reinen Auswertungs-Tool zum IDEA-Client nur ein sehr kleiner.
Eine Verfahrensdokumentation ist wichtig
Diese Prozesse, von der Entstehung der Daten und Dokumente über das Wiederfinden und Bereitstellen bis hin zur gesetzeskonformen Entsorgung sind in einer Verfahrensdokumentation nach GoBS zu dokumentieren und entsprechend dem Ausbau und der Veränderung der Systeme fortzuschreiben. Bisher waren die beim Anwender installierten Systeme eher selten Gegenstand einer Prüfung durch den Außenprüfer. In dem Maße, wie der Außenprüfer selbst solche Systeme für Z1 und Z2 benutzt, wird der Nachweis von ordnungsgemäßer Verarbeitung, Nutzung und Betrieb immer wichtiger. Der Steuerpflichtige mit größeren Anwendungssystemen muss sich daher darauf einrichten, dass bei einer Prüfung zukünftig nach der Verfahrensdokumentation gefragt wird, damit der Prüfer sich einen Überblick über die Systeme, deren Funktionsweise, die Zugriffsmöglichkeiten und die enthaltenen Daten verschaffen kann.
Die Forderung nach einer Verfahrensdokumentation ist nicht neu. Sie ist Bestandteil einer GoBS-konformen Verarbeitung und Speicherung von kaufmännischen Daten und Dokumenten. Darüber hinaus ist sie auch für den Anwender selbst von Nutzen, da sie ihm die Nachvollziehbarkeit der Auslegung und der Weiterentwicklung seiner Systeme ermöglicht. Spätestens wenn eine Migration ansteht, wünscht man sich eine sauber geführte und vollständige Verfahrensdokumentation. Wird die Verfahrensdokumentation und deren Umsetzung im Unternehmen durch einen Wirtschaftsprüfer oder durch den TüV-IT zertifiziert, kann man sicher sein, alle notwendigen Vorbereitungen für den Besuch des Steuerprüfers getroffen zu haben.
Win-Win Situation
Die Frage nach der GDPdU-konformen Archivierung scheint gelöst. Die beschriebene, vom Quellsystem unabhängige Lösung bringt sowohl den steuerpflichtigen Unternehmen, als auch der Finanzverwaltung durchweg Vorteile. Die Unternehmen sind, was die GDPdU anbetrifft, künftig weitgehend unabhängig von Migrationen im Hauptsystem und müssen sich keine Gedanken über die Aufbewahrung auszumusternder Hard- oder Software machen. Die Finanzverwaltung kann auf Bekanntes zurückgreifen und muss sich nicht mit einer Vielzahl von unterschiedlichen DV-Systemen vertraut machen. Der für die Finanzverwaltung sonst dringend erforderliche Einarbeitungsaufwand, bedingt durch die Vielzahl unterschiedlicher Auswertungsprogramme, entfällt weitgehend und die Unternehmen wären von aufwändigen Einweisungen in die Besonderheiten ihrer IT entbunden. Der Befürchtung, dass Unternehmen mit ohnehin wenigen Auswertungs-Tools durch einen IDEA-Client einen Mehrwert für die
Betriebsprüfung schaffen, ist falsch, da der Finanzverwaltung im Rahmen der Datenträgerüberlassung diese Funktionalität ohnehin zur Verfügung steht, wenn auch nicht in der Unternehmens-DV selbst. Im Gegenteil, die Beschränkung auf diese Analysemöglichkeiten würde es den Steuerpflichtigen ersparen, über eine Trennung von Auswertungen nachzudenken, die ausnahmslos der Steuerung interner Betriebsabläufe dienen und damit nicht in Beziehung zu steuerlich relevanten Daten stehen. Lastintensive Auswertungen für die Prüfer könnten auf diesen Systembereich verlagert werden und das operative System so konstant performant halten.
Fazit
Unternehmen müssen jetzt Handeln, um das "Team-Eichel" in der Gesamtwertung noch abzufangen. IDEA-Client, Simulation der Betriebsprüfung und Datentrennung sind dabei Tuningfaktoren, welche die Waffengleichheit wieder herstellen. Und eines darf man nicht vergessen: Die Unternehmen haben jenseits der Steuerwelt die Chance, Daten weitaus besser auszuwerten und zur verbesserten Steuerung einzusetzen. Dies ist ein Baustein im künftigen Wettbewerb und sichert letztlich die Grundlage für die digitale Betriebsprüfung, nämlich die Unternehmen selbst.
Zehn Schritte zur GDPdU-konformen Archivierung
Extraktion (zwingend): Das Hauptsystem und gegebenenfalls Neben- und vorgelagerte Systeme extrahieren aus ihrem Datenbestand periodisch die steuerrelevanten Daten nebst den zugehörigen Stammdaten, wie sie bei der Qualifizierung und Identifizierung festgelegt worden sind. Diese Daten werden zusammen mit der Strukturdefinition, in der das Format und die Attribute der Daten beschrieben sind, als Dateien exportiert. Zu den Strukturdateien gehören auch die Zusammenstellungen und Regeln der im Hauptsystem vorhandenen Auswertungen. Die Aufbereitung entsprechend dem Beschreibungsstandard für IDEA (abrufbar unter www.audicon.net) ist hierbei zu empfehlen.
Validierung (empfohlen): Manuell oder automatisiert erfolgt eine Prüfung und Validierung, ob die Daten vollständig, richtig und verarbeitungsfähig sind. Hierzu kann man die Daten zum Beispiel mit IDEA beziehungsweise AIS TaxAudit testweise auswerten. Sind die Daten nicht vollständig oder nicht auswertbar, müssen entsprechende Anpassungen in den operativen Systemen vorgenommen und die Daten erneut ausgegeben werden. Zukünftig werden für diesen Zweck voraussichtlich auch Programme angeboten, die man als "Validator" bezeichnen kann.
Schritt 3 - Übergabe (zwingend): Die Daten und die dazugehörigen Strukturinformationen werden an das Archiv übergeben. Dies kann durch manuellen Import oder nach erfolgreicher Überprüfung durch ein Validator-Programm automatisiert geschehen. Letzteres hat den Vorteil, dass keine manuelle Interaktion erfolgt, bei der noch eine Veränderung der Daten theoretisch möglich wäre.
Indizierung (zwingend): Die Daten und die dazugehörigen Strukturinformationen werden in die Verwaltung des Archivsystems übernommen. Hierbei werden sie zusammenhängend manuell oder automatisiert indiziert, so dass sie unter dem gleichen Index eindeutig identifizierbar und wieder auffindbar gespeichert werden. Werden die gleichen Daten oder Daten der gleichen Periode gewollt oder fehlerhaft mehrfach übertragen, so muss das Archivsystem für eine entsprechende Versionierung bei der Indizierung sorgen, damit der Prüfer den Zugriff auf die richtigen Daten erhält.
Speicherung (zwingend): Das Archivsystem speichert die Informationen und sichert durch seine Medien beziehungsweise Verwaltungssoftware, dass die eindeutige Identifizierung, Vollständigkeit und Unveränderbarkeit sichergestellt ist. Mit der Übernahme, Indizierung und Speicherung erstellt das Archivsystem eine Protokolldatei, die den Vorgang sowie die veränderungs- und verlustfreie Speicherung im System dokumentiert und zusammen mit den Daten und Strukturinformationen unter dem gleichen Index speichert. Die Verwendung eines Zeitstempels nach Signaturgesetz kann die rechtliche Qualität des Nachweises der Unveränderbarkeit und des Speicherdatums zusätzlich absichern.
Migration (optional): Ist während der Aufbewahrungsfrist eine Migration der Daten erforderlich, so sind nicht nur die Daten und die zugehörige Strukturinformation verlust- und veränderungsfrei zu überführen, sondern auch die Indexinformation, die ein Wiederfinden und Identifizieren sicherstellt, unverändert zu migrieren. Hierüber ist wiederum eine Protokolldatei zu führen und zu archivieren, die den Nachweis der verlustfreien Migration ermöglicht. Wie das Gesamtverfahren selbst, ist auch die Migration in der Verfahrensdokumentation zu beschreiben.
Zugriff auf die steuerrelevanten Daten (zwingend): Wird im Rahmen einer Steuerprüfung auf die archivierten Daten zurückgegriffen, lässt sich über die Anwendung des Archives eine Suche nach den entsprechenden Daten für den zu prüfenden Zeitraum starten. Das Archivsystem liefert eine Ergebnisliste, in der periodengerecht die gefundenen Dateien angezeigt werden. Hierbei handelt es sich zusammenhängend unter dem gleichen Index immer um die Daten mit den dazugehörigen Strukturinformationen sowie die dazugehörige Protokolldatei. Wurden die Daten zwischenzeitlich migriert, wird auch das Migrationsprotokoll angezeigt.
Prüfung auf Richtigkeit und Vollständigkeit (empfohlen): Die Indizierung hat sicherzustellen, dass entsprechend der Suchanfrage die gefundenen Daten vollständig und richtig sind. Dies wird durch die Anzeige der archivierten Protokolle mit der Anwendung und dem Vergleich der Protokolleinträge mit den gefundenen Dateien ermöglicht. Ein Zeitstempel nach Signaturgesetz kann auch hier die Aussagekraft des Protokolls verbessern. Die Protokolle sollten für den Nachweis auch druckbar und exportierbar sein.
Bereitstellung (zwingend): Entsprechend der Strategie des Anwenders gibt es verschiedene Optionen für die Bereitstellung der aufgefundenen steuerrelevanten Daten:
Liegen die Daten nach dem Beschreibungsstandard für IDEA formatiert vor, werden sie in das File-System beim Anwender oder auf einem Speichermedium (Transportmedium) exportiert. Sie können dann mit IDEA ausgewertet werden und erfüllen die Zugriffsart Z3.
Wenn das operative System auf das Wiedereinladen historischer Daten vorbereitet ist, können die Daten dorthin importiert werden und alle Z1- und Z2-Operationen in dem System erfolgen, in dem die Daten entstanden sind. Dies kann dann notwendig werden, wenn die Daten bei der Übergabe nicht nach dem Beschreibungsstandard für IDEA aufbereitet worden sind. In diesem Fall müsste das operative System in der Lage sein, einen Datenträger nach Z3 zu erstellen
Steht ein "universelles Auswertungsprogramm", zum Beispiel ein "IDEA-Client", zur Verfügung, dass direkt auf die Dateien aus dem Archivsystem zugreift, wären damit uneingeschränkt alle drei Zugriffsarten Z1, Z2 und Z3 realisierbar. Ein solches universelles Auswertungsprogramm würde eine Vereinfachung und Erleichterung für die beiden zuvor genannten Varianten darstellen. Dies gilt besonders dann, wenn das Archivsystem über eine Schnittstelle an das universelle Auswertungsprogramm angepasst ist. Es würde eine direkte Aufbereitung der Daten entsprechend den Strukturbeschreibungsinformationen ohne weitere Zwischenschritte ermöglicht. Das Archivsystem benötigt durch die Kombination mit einem IDEA-Client keine eigene Auswertungslogik.
Besonderes Augenmerk ist hierbei auch auf die archivierten Dateien mit den Auswertungen zu legen, um den Anspruch einer qualitativ und quantitativ gleichwertigen Auswertungsmöglichkeit gerecht zu werden.
Zugriff auf digitale Belege (optional): Sind im Archivsystem auch die Belege als Dokumente archiviert, muss über die Indexdatenbank das zu einem Datensatz gehörende Dokument gefunden und angezeigt werden können. Dies betrifft alle Anwender, die nicht nur die maschinell auswertbaren Datensätze aus den kaufmännischen Systemen archiviert haben, sondern auch Dokumente gescannt, digital eingegangene Faxmitteilungen und E-Mails abgelegt sowie selbst erzeugte elektronische Dokumente im Archiv speichern. Handelt es sich bei diesen um kaufmännische Dokumente, die steuerrelevante Daten enthalten, so müssen sie über einen eindeutigen Index wieder auffindbar sein. Der Index muss mindestens zwei eindeutige Attribute aus dem Datensatz mit den steuerrelevanten, maschinell auswertbaren Daten beinhalten. Neben dem Datum ist dies in der Regel eine Beleg-, Rechnungs- oder Buchungsnummer. Diese Funktionalität muss über die Indexdatenbank und die Anwendung des Archivsystems
gegeben sein, damit der Prüfer zu einem Prüfgegenstand alle zugehörigen Belege finden kann. Wünschenswert ist eine zumindest teilautomatisierte Suche, die ohne aufwändige manuelle Eingabe durch Übernahme eines angezeigten Datensatzes die zugehörigen Dokumente findet und anzeigt.