Anzeigen

Anbieter von Lösungen zur elektronischen Steuerprüfung
hmd Solftware
Verfahrensdoku
DATEV eG
Caseware
Home  Verfahrensdokumentation

18 Thesen zur Verfahrensdokumentation

Von Gerhard Schmidt

14.02.2008

Gerhard Schmidt

Gerhard Schmidt
Chefredakteur des "Forum Elektronische Steuerprüfung".

Warum Verfahrensdokumentation ein schwieriges Thema ist und welche Fragen in diesem Zusammenhang noch beantwortet werden müssen, damit setzen sich die folgenden Thesen auseinander. Ziel ist, eine Diskussion und Klärung dieser Fragen anzuregen, um den betroffenen Unternehmen Klarheit und Sicherheit bei der Erstellung und Pflege ihrer Verfahrensdokumentation zu geben.

„Für jedes DV-gestützte Buchführungssystem ist eine Dokumentation zu erstellen (Verfahrensdokumentation).“ Heißt es in den GoBS  (Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme) von 1995. Obwohl bereits viele Jahre gefordert, rückte die Verfahrensdokumentation erst durch die GDPdU von 2001 (Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen) in den Fokus des Interesses der steuerlichen Außenprüfung und veranlasst die Unternehmen, sich mit einer Verfahrensdokumentation ernsthaft auseinander zu setzen. Mit den GDPdU wurde der Begriff der „DV-gestützten Buchführungssysteme“ weiter interpretiert. Alle Systeme, in denen steuerlich relevante Daten vorkommen, müssen in einer Verfahrensdokumentation mit berücksichtigt werden.

Was alles muss in einer Verfahrensdokumentation stehen? Wie detailliert muss eine Verfahrensdokumentation sein? Welchen Aufwand bedeutet eine Verfahrensdokumentation? Vor diesen Fragen stehen die Unternehmen. Und sie stehen damit ziemlich alleine da. Etablierte Leitlinien und Maßstäbe zur Erfüllung der steuerrechtlichen Anforderungen an eine Verfahrensdokumentation existieren nicht. Doch die Erfüllung dieser Anforderungen ist letztlich von steuer- und strafrechtlicher Bedeutung.

Verfasser und Leser einer Verfahrensdokumentation sind nicht Personen sondern Rollen

Eine Verfahrensdokumentation ist ein Medium für die Kommunikation zwischen ihrem Verfasser und ihrem Leser, einem „sachverständigen Dritten“. Der Verfasser einer Verfahrensdokumentation muss – wie jeder Verfasser – eine präzise Vorstellung vom Informationsinteresse des Lesers haben, um eine zielgerichtete Beschreibung zu erstellen, die nicht zu wenig und nicht zu viel Information enthält.

Beispiel: Bei einer Betriebsprüfung stellt sich die Frage, ob bei einer Systemabschaltung vor fünf Jahren alle Daten vollständig vom alten in das neue System übertragen wurden. Das alte System war im Untenehmen selbst entwickelt. Eine Systemdokumentation, wie sie bei Standardsoftware normalerweise vorhanden ist, gab es nicht. Dafür eine technische Dokumentation der Datenbank. Für den Betriebsprüfer vor Ort, der sich anhand der vorgelegten Verfahrensdokumentation zunächst schnell einen guten Eindruck von der damaligen IT-Infrastruktur verschaffen konnte, ist die Datenbankdokumentation ein Buch mit sieben Siegeln. Erst als er einen IT-Spezialisten aus der Finanzverwaltung hinzuzieht, ist er in der Lage zu beurteilen, welche Daten damals überhaupt vorhanden waren und ob diese vollständig übertragen wurden.

Das Beispiel zeigt, dass der Leser einer Verfahrensdokumentation nicht eine Peron ist, sondern eine funktionelle Rolle. Die Rolle wird hier von zwei Personen wahrgenommen, denn jede Person alleine wäre aufgrund ihres spezifischen Sachverstandes nicht in der Lage, die gewünschte Informationen aus der Dokumentation zu entnehmen.

In einfachen Fällen kann die Rolle durchaus von einer Person wahrgenommen werden. In komplexeren Fällen muss die Rolle von noch mehr Personen mit spezifischem Sachverstand wahrgenommen werden.

Wenn der Leser einer Verfahrensdokumentation eine funktionelle Rolle ist, dann muss auch der Verfasser eine funktionelle Rolle sein. Denn für den Verfasser gilt, dass unterschiedlicher Sachverstand, der durch verschiedene Personen im Unternehmen repräsentiert sein kann, in der Verfahrensdokumentation zusammengeführt werden muss.

Der „sachverständige Dritte“ als Leser einer Verfahrensdokumentation ist unbestimmt

Welcher subsummierte Sachverstand bei der funktionellen Rolle „Leser“ (sachverständiger Dritter) anzunehmen sein soll, ist nicht klar bestimmt. Steuerrechtlicher und informationstechnischer Sachverstand kommen hier zusammen. Für den Umfang des steuerrechtlichen Sachverstandes dürfte etwa der Sachverstand eines Wirtschaftsprüfers als Maßstab gelten. Der Umfang des informationstechnischen Sachverstandes dagegen ist ziemlich offen.

Die Detailtiefe einer Verfahrensdokumentation ist unbestimmt

Für den Detaillierungsgrad einer Verfahrensdokumentation gibt es keine Anhaltspunkte. Die Detaillierungstiefe muss vom Unternehmen selbst bestimmt werden, mit dem Risiko, dass im konkreten Fall genau das Detail, das interessant ist, nicht dokumentiert wurde. Das Unternehmen befindet sich bei der Festlegung der Detailtiefe der Verfahrensdokumentation in einer ähnlichen Situation wie bei der Qualifikation steuerlich relevanter Daten nach den GDPdU, wo die Finanzverwaltung sich ebenfalls auf keine konkreten, handhabbaren Aussagen einlässt.

An die Lesbarkeit einer Verfahrensdokumentation werden kaum Anforderungen gestellt

„Ein sachverständiger Dritter muss sich in dem jeweiligen Verfahren der Buchführung in angemessener Zeit zurechtfinden und sich einen Überblick über die Geschäftsvorfälle und die Lage des Unternehmens verschaffen können.“ heißt es in den GoBS. Das sind sehr schwache Anforderungen an die Lesbarkeit einer Verfahrensdokumentation. Eine angemessene Zeit kann angesichts der Komplexität von Unternehmens- und IT-Prozessen auch eine ziemlich lange Zeit sein.

Wenn eine Verfahrensdokumentation ein brauchbares Kommunikationsmedium sein soll, muss sie lesbar sein. Einfluss auf die Lesbarkeit haben die logische Struktur, die (typo)grafisch Form und die verwendeten Sprachmittel. An die Qualität von Struktur, Form und Sprache (schriftliche wie grafische) werden in den GoBS keine Anforderungen gestellt: „Wie die erforderliche Verfahrensdokumentation formal gestaltet und technisch geführt wird, kann der Buchführungspflichtige individuell entscheiden.“

Eine Verfahrensdokumentation kann vom Inhalt her breit angelegt und in jedem Detail korrekt sein, doch schlecht in Gliederung, Optik und Sprache. Welcher Leser wird sich in diesem Fall wie viel Mühe machen, die für ihn interessanten und wichtigen Informationen zu erschließen?

Andererseits kann eine Verfahrensdokumentation eine klare Gliederung haben, optisch ansprechend sein und in flüssig zu erfassender Sprache geschrieben. Klopft man die ihre Inhalte allerdings ab, klingt sie sehr hohl. Welcher Leser wird dies wie genau und wie schnell merken?

Gefälliges Äußeres suggeriert inhaltliche Qualität. Wessen Arbeit an der Verfahrensdokumentation führt beim Leser wohl zu mehr Akzeptanz, die des akribischen IT-Experten oder die des Grafik-Designers?

Eine Verfahrensdokumentation liefert dem Leser keine Wissen über das Unternehmen sondern Vertrauen in das Unternehmen

Der Leser einer Verfahrensdokumentation - beispielsweise ein Betriebsprüfer -  ist überfordert, die wichtigen und entscheidenden Informationen aus der Verfahrensdokumentation zu ziehen. Insbesondere dann, wenn die Verfahrensdokumentation für ihn nicht einfach zu lesen ist. Er hat keine Maßstäbe für die Beurteilung einer Verfahrensdokumentation, so wie er sie sonst bei seiner Arbeit hat. Es gibt insbesondere keine formalen Kriterien, vergleichbar beispielsweise den Kriterien, die eine Rechnung erfüllen muss, dass sie zum Vorsteuerabzug berechtigt. Eine Verfahrensdokumentation vermittelt dem Leser in den entscheidenden Punkten kein Wissen über das Unternehmen, sondern Vertrauen in das Unternehmen: „Wer sich für eine so ansprechend gestaltete Verfahrensdokumentation so viel Mühe gemacht hat, bei dem ist wohl alles in Ordnung.“

Für eine Unternehmen bedeutet dies im Umkehrschluss: Wer etwas zu verbergen hat, tut dies - sofern er keine eleganteren Möglichkeiten kennt - in der aufgepeppten Verfahrensdokumentation.

Die Korrektheit einer Verfahrensdokumentation lässt sich im Nachhinein nicht mehr überprüfen

War ein vor fünf Jahren verschrottetes Fahrzeug verkehrstauglich oder hatte es seine Straßenzulassung aufgrund von Mängeln oder baulichen Veränderungen verloren? Das nicht mehr existierende Fahrzeug kann, um hier Klarheit zu schaffen, nicht mehr vom TÜV untersucht werden. Es können lediglich die Dokumente ausgewertet werden, die über das Fahrzeug existieren. Kann aus einer Rechnung über eine Bremsenreparatur geschlossen werden, dass das Bremssystem des Fahrzeugs in Ordnung war?

Analoge Fragen stellen sich auch bei IT-Systemen, beispielsweise im Zusammenhang mit einer Jahre zurückliegenden Systemabschaltung. Was liefert hier der Blick in die Verfahrensdokumentation? Ein exaktes Bild der Realität von damals? Oder das Bild einer fiktiven, konstruierten Realität, die damals so hätte sein können? Ob Wahrheit oder Fiktion lässt sich im Nachhinein nicht mehr überprüfen. Genau so wenig wie man heute einem Foto ansehen kann, ob es sich um einen Schnappschuss handelt oder ob es mit einer Bildbearbeitungssoftware komponiert wurde.

Nur dann, wenn eine Verfahrensdokumentation zeitnah auf Übereinstimmung zwischen Dokument und Dokumentiertem verglichen wird, lassen sich Aussagen über die Korrektheit einer Verfahrensdokumentation treffen.

Jede Verfahrensdokumentation ist unvollständig

Angesichts der Komplexität heutiger IT-Landschaften mit unzähligen Hardware-, Firmware-, Systemsoftware- und Anwendungssoftware-Komponenten, die alle irgendwie miteinander in Beziehung stehen, ist es für niemanden möglich, sich darüber einen strukturierten Überblick zu verschaffen und diesen zu dokumentieren. Jedes auch noch so akribische Bemühen um eine vollständige Dokumentation wird scheitern.

Schon das IT-System „Stand-alone-PC“ mit einigen Office- und Anwendungsprogrammen, lässt sich aufgrund seiner Komplexität nur lückenhaft dokumentieren. Wird bei der Deinstallation eines Programmes die Frage gestellt „Die Datei xyz wird offensichtlich von keinem weiteren Programm mehr benutz. Kann die Datei entfernt werden? Möglicherweise funktionieren danach andere Programme nicht mehr.“, müsste eigentlich ein kurzer Blick in die IT-Dokumentation genügen, um diese Frage zweifelsfrei beantworten zu können. Eine IT-Dokumentation zu erstellen, die diese Frage beantworten kann, ist nicht möglich.

Jede Verfahrensdokumentation ist ungenau

Wer dokumentiert, sollte die Bedeutung (Semantik) des zu Dokumentierenden kennen. Ein quasi „Naturgesetz“ der Informatik ist, dass sich die Semantik einer Software (wenigzeilige Miniprogramme vielleicht ausgenommen) letztlich nicht erschließen lässt.

Im besten Falle gilt der Satz: „Fehlerfreie Software ist veraltet.“ Doch wer setzt schon veraltete Software ein? Letztlich ist jedoch jede Software fehlerhaft, trotz aufwändiger Qualitätssicherungsmaßnahmen, insbesondere Testen. Testen kann nur die Anwesenheit von Fehlern zeigen, nie deren Abwesenheit. Verfahren, die Abwesenheit von Fehlern in Anwendungssoftware sicherzustellen, kennt die Informatik nicht.

Doch auch dem Testen sind Grenzen gesetzt, dann, wenn eine Anwendungssoftware nicht selbst entwickelte Software wie Frameworks oder Programmbibliotheken benutzt, die ihrerseits auch wieder auf andere Software, wie das Betriebssystem, zurückgreifen. Die Semantik einer benutzten Software ist dem Programmierer in der Regel nicht bekannt. Er verlässt sich darauf, dass die mit „Drucken“ bezeichnete benutzte Funktion auch tatsächlich druckt. Doch Namen können hier Schall und Rauch sein.

Die Semantik einer Software gründet immer auf der Semantik der benutzten Software. Dies können mehrfach gestaffelte Benutzungshierarchien sein. In jedem Fall ist es eine einstufige Hierarchie, denn eine Anwendungssoftware benutzt immer das Betriebssystem. Welcher Programmierer kennt die Semantik von beispielsweise Windows?

Eine Verfahrensdokumentation beschreibt also immer IT-Objekte und -Prozesse, die der Verfasser nicht genau kennt, nicht genau kennen kann.

Selbstdokumentierende Systeme sind Voraussetzung für eine Verfahrensdokumentation

Dokumentation ist mühsam und anfällig für Dokumentationslücken. Um diese zu minimieren, muss die Dokumentation, wo immer es geht, automatisiert werden. Protokolle mit genau den für eine Verfahrensdokumentation relevanten Informationen müssen im Hintergrund einer Anwendungssoftware bzw. eines IT-Anwendungssystems automatisch mitlaufen. Diese Anforderung an Anwendungssoftware wird von deren Herstellern heute noch nicht als ihre Aufgabe betrachtet.

Es gibt keinen Standard für die Verfahrensdokumentation

Das einzige breiter kommunizierte Dokument zur Verfahrensdokumentation ist der vom VOI/TüvIT erstellte Leitfaden. Bei dessen Entwicklung standen Dokumente und deren revisionssicherere Archivierung im Fokus und nicht eine Gesamtsicht auf die alle Unternehmensdaten und -dokumente. Der Leitfaden hat eher den Charakter einr Präzisierung der Anforderungen an eine Verfahrensdokumentation als dass er als Modell einer Verfahrensdokumentation nutzbar wäre.

Ein Standard für die Verfahrensdokumentation würde für alle Beteiligten und Betroffenen die gewünschte Klarheit und Sicherheit bringen. Doch wer sollte diesen erarbeite? Und welches Gremium könnte diesen verabschieden?

Es gibt keine Pragmatik der Verfahrensdokumentation

Existiert kein Standard, wird diese Lücke vielmals durch ein „best practice“ gefüllt. Bei der Verfahrensdokumentation ist dies bislang nicht der Fall. Voraussetzung für die Etablierung von „best parctice“ ist überhaupt „practice“. Doch wie viel ernstzunehmende gibt es davon?

Es gibt keine Kultur der IT-Dokumentation

Im Prinzip weiß jeder, wie wichtig IT-Dokumentation ist. Doch eigentlich immer stehen terminbehaftete Projekt- und Routinearbeiten an, so dass die IT-Dokumentation erst einmal etwas warten muss. Und somit beliebig lange aufgeschoben wird. Aus dieser Einstellung zur IT-Dokumentation im Allgemeinen und dem Fehlen von Standards und best practices im Besonderen konnte sich nie eine Kultur der IT-Dokumentation entwickeln, in der diese als etwas Selbstverständliches angesehen wird.

Ganz anders ist dies beispielsweise bei der Buchführung. Dort ist eine „Kultur der ordnungsgemäßen Buchführung“ etabliert.

Das Fehlen einer Kultur der IT-Dokumentation zeigt sich unter anderem auch daran, dass kein Konsens existiert, wer für welche Teile einer IT-Dokumentation wie zuständig ist, Hersteller oder Anwender. Relevante Teile einer compliance-relevanten Dokumentation von Anwendungs- und Systemsoftware kann nicht vom Unternehmen geleistet werden, sondern muss vom Softwarehersteller so geliefert werden, dass sie sich einfach in die Verfahrensdokumentation des Unternehmens integrieren lässt. Dies ist weitgehend noch Neuland, da weder die Softwarehersteller geeignete Dokumentationen anbieten, noch die Unternehmen diese nachfragen.

Es gibt kein Sanktionensystem bei einer mangelhaften Verfahrensdokumentation

Welche Konsequenzen hat es für ein Unternehmen, wenn es eine mangelhafte oder gar keine Verfahrensdokumentation vorweisen kann? Das ist völlig unklar. Da es weder einen Standard noch „best practice“ der Verfahrensdokumentation gibt, fehlt ein Maßstab, an dem eine Verfahrensdokumentation zu messen wäre. Ein Maßstab wäre aber Voraussetzung für ein Sanktionensystem, das festlegt, welche Konsequenzen welche Mängel bei einer Verfahrensdokumentation nach sich ziehen. Darüber hinaus gibt es noch keine Rechtsprechung, die Hinweise auf den Grad von Sanktionen geben könnte.

Die Gerichtsverwertbarkeit einer Verfahrensdokumentation ist problematisch

Wenn eine Verfahrensdokumentation immer unvollständig, ungenau und im Nachhinein nicht mehr auf Korrektheit überprüfbar ist, darüber hinaus auch nicht leicht lesbar sein muss, welchen Stellenwert hat eine Verfahrensdokumentation dann in einer rechtlichen Auseinandersetzung etwa vor einem Finanzgericht? Auch ein Gericht kann durch eine Verfahrensdokumentation nur Vertrauen in und nicht Wissen über das Unternehmen gewinnen.

Verfahrensdokumentation muss im umfassenden Compliance-Kontext gesehen werden

Eine Verfahrensdokumentation nur unter den steuerrechtlichen Compliance-Anforderungen zu betrachten, wie sie u.a. in den GoBS und den GDPdU enthalten sind, wäre verkürzt. Anforderungen zur IT-Dokumentation ergeben sich auch im Zusammenhang mit Datenschutz, Verrechnungspreisen, Basel II, SOX, Euro-SOX. Zu diesen externen Compliance-Anforderungen kommen internen. Diese Dokumentationen überschneiden sich in vielen Teilen und müssen von daher als übergreifende Gesamt-IT-Dokumentation gesehen werden.

Die Verfahrensdokumentation ist Nebenprodukt des Risiko- und Qualitätsmanagements im Untenehmen

Jedes an wirtschaftlichem Erfolg orientierte Untenehmen muss Risiko- und Qualitätsmanagement betreiben. Dazu müssen die Unternehmensprozesse auf jeder Ebene klar definiert sein. Ohne Dokumentation der Prozesse ist dies nicht möglich. Eine so aus Unternehmensinteresse erstellte Dokumentation ist in weiten Teilen - zumindest den, die sich mit der IT-Anwendung befassen - deckungsgleich mit einer Verfahrensdokumentation. Umgekehrt bedeutet dies: Wer Probleme mit der Verfahrensdokumentation hat, offenbart Probleme mit seinem Risiko- und Qualitätsmanagement.

Eine Verfahrensdokumentation rechnet sich

Da sich Risiko- und Qualitätsmanagement im Unternehmen rechnet, rechnet sich implizit auch eine Verfahrensdokumentation.

Im Rahmen eines Risikomanagements wird auch das Risiko einer fehlenden oder lückenhaften Verfahrensdokumentation zu bewerten sein und ins Verhältnis gesetzt werden zum Aufwand für die Verfahrensdokumentation.

Es gibt kaum Interessenten dafür, einen Standard oder „best practice“ für eine Verfahrensdokumentation zu entwickeln

Während die vorhergehenden Thesen darauf abzielen, eine tiefergreifenden Diskussion um die Verfahrensdokumentation anzuregen, sollte diese These möglichst schnell nachhaltig widerlegt werden. Wer dies tun möchte, wende sich an Gerhard Schmidt, gerhard.schmidt@compario.de, 030 / 893 45 42.

Newsletter
 hier abonnieren
Gerhard Schmidt: 18 Thesen zur Vefahrensdokumentation

04.12.2024

powered by webEdition CMS
powered by webEdition CMS