Warum Verfahrensdokumentation ein schwieriges Thema ist und welche Fragen in diesem Zusammenhang noch beantwortet werden müssen, damit setzen sich diese 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.
|
