Handels- und Steuerrechtliche Aspekte der Entwicklung, Nutzung

Handels- und Steuerrechtliche Aspekte der Entwicklung, Nutzung

erschienen in: Informationssystem Architekturen, Rundbrief des GI-Fachausschusses 5.2, Heft 1, September 1996, S. 85-88
http://www.wiwi.uni-frankfurt.de/~mphilipp/papers/gi1_96.zip
Handels- und Steuerrechtliche Aspekte der Entwicklung, Nutzung und Abwicklung
betrieblicher Informationssystem-Architekturen:
Am Informationssystem-Lebenszyklus orientierte Umsetzung der GoBS
Dipl.-Wirtsch.-Inf., CISA Mathias Philipp
Wissenschaftlicher Mitarbeiter, Institut für Wirtschaftsinformatik, J. W. Goethe-Universität, 60054 Frankfurt a.M.
Freier Mitarbeiter, Fachgruppe EDV+Prüfen, KPMG Deutsche Treuhand-Gesellschaft, 68165 Mannheim
E-Mail: [email protected]
Schlüsselworte:
Ordnungsmäßigkeit, GoBS, Internes Kontrollsystem, EDV-Revision, Systementwicklung, Software-Testat
Problemstellung und Zusammenfassung:
Betriebliche Informationssystem-Architekturen (IS-Architekturen) sind zunehmend als sich dynamisch ändernde, den
betrieblichen Gegebenheiten angepaßte Architekturen zu verstehen. Der typische Lebenszyklus einer IS-Architekturgeneration besteht aus Konzeption, Entwicklung, Einführung, Betrieb, Anpassung und Abwicklung inkl. Migration zu
einer neuen Generation. Letztendlich sind somit bereits bei der Konzeption einer Generation die Notwendigkeiten des
ordnungsmäßigen Übergangs zwischen den einzelnen Phasen sowie die ordnungsmäßige Abwicklung und Migration
zu einer neuen IS-Architektur zu berücksichtigen.
Da betriebliche IS-Architekturen Geschäftsprozesse abbilden, die größtenteils rechnungslegungsrelevanter Art sind,
unterliegen sie den Bestimmungen des Handels- und Steuerrechts. Aus diesen rechtlichen Grundlagen lassen sich
Anforderungen an jede Phase des Lebenszyklusses einer IS-Architektur ableiten.
In diesem Beitrag wird zunächst gezeigt, wie grundsätzlich aus Handels- und Steuerrecht Anforderungen für ISArchitekturen abgeleitet werden. Darauf aufbauend werden die handels- und steuerrechtlichen Bestimmungen auf die
Lebenszyklusphasen von betrieblichen IS angewendet. Dabei finden insbesondere die durch das Bundesministerium
der Finanzen - mit Veröffentlichung im Bundessteuerblatt (1995 Teil I) und in der AO-Kartei - in die Abgabenordnung (AO) übernommenen GoBS (Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme) [GoBS95] und
erste Erfahrungen aus der EDV-Revisionspraxis mit deren betrieblicher Umsetzung Berücksichtigung.
1 Rechtliche Grundlagen für betriebliche IS-Architekturen
1.1 Handels- und Steuerrecht
In betrieblichen IS-Architekturen werden betriebliche Arbeitsabläufe bzw. Geschäftsprozesse abgebildet. Ein Geschäftsprozeß „beinhaltet die Summe von Tätigkeiten, die betriebswirtschaftlich oder
technisch-logisch zusammengehören“ [HoKö90: 250]. Eine Tätigkeit, die zu einer Änderung der
Höhe oder Struktur des Vermögens und/oder Kapitals einer Unternehmung führt, ist ein
Geschäftsvorfall [AWV93: 12; Kühn93: 115]. Ein rechnungslegungsrelevanter Geschäftsprozeß
ist ein Geschäftsprozeß, der (mindestens) einen Geschäftsvorfall beinhaltet. Geschäftsvorfälle unterliegen den Bestimmungen des Handels- und Steuerrechts. Gemäß § 239 Abs. 4 HGB und § 146 Abs.
5 AO sind auf Geschäftsvorfälle und damit auf alle rechnungslegungsrelevanten Geschäftsprozesse
die GoB anzuwenden. Die GoB werden durch
InformationssystemArchitektur
werden abgebildet
enthält
Rechnungslegungsrelevanter
Geschäftsprozeß
werden abgebildet
enthält
unterliegen
werden präzisiert
Fachliche Stellungnahmen
⇒ GoBS, FAMA, ...
gewährleisten
Einhaltung
Ordnungsmäßige
Anwendung des
Verfahrens
gewährleisten
Einhaltung
DV-gestützten Buchführungssystem sind auch
solche Prozesse zu berücksichtigen, in denen
des
eigentlichen
Buchhaltungsbereiches buchführungsrelevante
übermittelt werden.“ [GoBS95: Tz. 1.1]
1.2 Fachliche Stellungnahmen
Die Präzisierung der GoB hinsichtlich DV-Einsatz erfolgt allgemein auf Basis von fachlichen
definieren
Ordnungsmäßigkeitskriterien
Nachvollziehbarkeit
des
Geschäftsvorfalls
verarbeitet werden [GoBS95: Tz. 1]. „In einem
Daten erfaßt, erzeugt, bearbeitet und / oder
Handels- u. Steuerrecht
⇒ GoB
gewährleisten
Einhaltung
anzuwenden, wenn Geschäftsvorfälle durch IS
außerhalb
Geschäftsvorfälle
definieren
Anforderungen
die GoBS präzisiert und sind genau dann
Nachvollziehbarkeit
des
Verfahrens
Stellungnahmen, die durch die Arbeitsgemeinschaft für wirtschaftliche Verwaltung e.V.
(AWV), den Fachausschuß für moderne Abrechnungssysteme (FAMA), das Institut der
Wirtschaftsprüfer (IDW) und steuerrechtliche
fordern
Internes Kontrollsystem
Verfahrensdokumentation
Aufbewahrungspflichten
Abb. 1: Ordnungsmäßigkeitskriterien für betriebliche
IS-Architekturen
Richtlinien (z.B. GoS, GoBS) erfolgen. Diese
Stellungnahmen stellen auch die Basis für die
Testierung und Prüfung von IS dar. Die bisher
gültigen GoS (Grundsätze ordnungsmäßiger
Speicherbuchführung) [GoS78] wurden zur „Anpassung an die heute eingerichteten und zukünftigen
Informationssysteme in den Unternehmen“ als GoBS neu gefaßt [GoBS95: S. 4]. Die wesentlichen
Unterschiede zwischen den GoS und den GoBS sind: (1) In den GoBS wird die Buchhaltung als
integrierte - statt isolierte und eindeutig abgrenzbare - Unternehmensfunktion gesehen. Daher sind
die GoBS auf alle Verfahren, die rechnungslegungsrelevante Geschäftsprozesse verarbeiten (z.B.
EDI,
BDE,
Materialwirtschaftssysteme,
Dokumenten-Managementsysteme,
Workflow-
Managementsysteme) anzuwenden. (2) Die GoBS sehen ihren Anwendungsbereich für moderne und
zukünftige IS-Architekturen sowie moderne Verfahren zur Anwendungsentwicklung, -pflege und
Programmdokumentation. (3) Darüber hinaus erhält in den GoBS der Begriff des Internen
Kontrollsystems (IKS) zentrale Bedeutung.
1.3 Ordnungsmäßige IS-Architekturen
Wie in Abbildung 1 dargestellt, werden für IS-Architekturen, die Geschäftsvorfälle DV-gestützt
verarbeiten, folgende Ordnungsmäßigkeitskriterien aus den GoB abgeleitet: (1) Nachvollziehbarkeit
des Geschäftsvorfalls, (2) Nachvollziehbarkeit des (Verarbeitungs-) Verfahrens und (3) ordnungsmäßige Anwendung des (Verarbeitungs-) Verfahrens [FAMA87, HaKe90, GoBS95]. Eine
ordnungsmäßige IS-Architektur muß somit über Funktionen verfügen, die die Einhaltung dieser
Ordnungsmäßigkeitskriterien und damit der GoBS, respektive der GoB, sichern. Besondere Bedeutung kommt dabei der Unterstützung bzw. Umsetzung eines IKS durch die IS-Architektur zu.
Beispielsweise zeigt [Thom94] Möglichkeiten, wie mittels (System-) Tabellendefinitionen und
Reportgenerierungen ein IKS mit der Standard-Anwendungssoftware SAP R/2 aufgebaut werden
kann. Das IKS hat auch die Aufgabe, die Einhaltung der Anforderungen, die sich aus der Verfahrensdokumentation und den Aufbewahrungspflichten ergeben, zu überwachen. „Als IKS wird
grundsätzlich die Gesamtheit aller aufeinander abgestimmten und miteinander verbundenen
Kontrollen, Maßnahmen und Regelungen bezeichnet. ... Dabei reichen wegen komplexer Abläufe
und Strukturen ... einzelne, voneinander isolierte Kontrollmaßnahmen keinesfalls aus. Vielmehr
bedarf es einer planvollen und lückenlosen Vorgehensweise, um ein effizientes Kontrollsystem im
Unternehmen zu installieren.“ [GoBS95: Tz. 4.1 u. 4.3].
2 Handels- und steuerrechtliche Bestimmungen angewendet auf den IS-Lebenszyklus
Für jede Phase wird zunächst dargelegt, welche Anforderungen sich aus den handels- und steuerrechtlichen Bestimmungen ergeben; anschließend wird beschrieben, welche Dokumentationspflichten
zum Nachweis der Umsetzung der Anforderungen zu erfüllen sind.
2.1 Konzeption
Grundsätzlich ist eine IS-Architektur so zu gestalten, daß alle Anforderungen an die Folgephasen
durch das IS erfüllt werden können. Wie in 1.3 dargelegt, kommt aus handels- und steuerrechtlicher
Sicht der konzeptionellen Gestaltung eines IKS zentrale Bedeutung zu. Die GoBS fordern ein
„effizientes Kontrollsystem“ [GoBS95: Tz. 4.3], d.h. daß mit der IS-Architektur ein definiertes
Kontroll- bzw. Sicherheitsniveau mit angemessenem Aufwand installiert werden kann. Das IKS ist so
zu gestalten, daß es alle Ebenen einer IS-Architektur (Anwendungs-, Datenbank,- Betriebssystemund Netzwerkebene) umspannt und hat folgende Aufgaben zu erfüllen: (1) Vermögenssicherung, (2)
Bereitstellung vollständiger, genauer, aussagefähiger und zeitnaher Aufzeichnungen, (3) Unterstützung der Geschäftspolitik und (4) Förderung der Effizienz durch Auswertung und Kontrolle der
Aufzeichnungen [GoBS95: Tz. 4.2]. In der Konzeptionsphase sind zur Erfüllung dieser Aufgaben
beispielsweise auf der Ebene der Anwendungssysteme folgende Schritte durchzuführen [vgl.
GoBS95: Tz. 4.4]:
• Identifizierung aller rechnungslegungsrelevanten Geschäftsprozesse, die in dem IS abgebildet
werden sollen.
• Für jeden identifizierten Geschäftsprozeß sind die zugehörigen (systemsteuernden) Tabellendaten
und Stammdaten als rechnungslegungsrelevant zu klassifizieren, da für diese besondere Dokumentations- und Archivierungspflichten bestehen (vgl. Kap. 2.4 u. 2.5).
• Für jeden identifizierten Geschäftsprozeß sind aufeinander abgestimmte manuelle und maschinelle
Kontrollen, die eine vollständige und richtige Verarbeitung aller Geschäftsvorfälle des Geschäftsprozesses sichern, zu konzipieren. Insbesondere ist auf eine Lückenlosigkeit der Kontrollen zu
achten. Jede manuelle Tätigkeit bedarf der nachträglichen Überwachung, da diese grundsätzlich
umgehbar ist oder eventuell nicht mit der nötigen Sorgfalt durchgeführt wird [GoBS95: Tz. 4.4].
• Das Berechtigungskonzept des IS ist so zu konzipieren, daß eine eindeutige Zuständigkeit bzw.
Verantwortlichkeit für die Tätigkeiten eines Geschäftsprozesses nach dem Prinzip der Funktionstrennung abbildbar ist. Folgende drei operative Funktionen sind grundsätzlich unvereinbar:
Vorgangsbearbeitung, Bestandsverwaltung und Buchen von Geschäftsvorfällen [Leff88: 246].
• Konzeption einer Protokollierungskomponente, die die Durchführung der Kontrollen dokumentiert.
Nach [Leff88: 245] ist ein lückenloses IKS so zu gestalten, daß:
•
•
•
•
Bei jeder Güter- und Geldbewegung eine Kontrolle stattfindet.
Das IKS alle Arbeitsvorgänge erfaßt.
Alle Arbeitsgänge nicht anders als vorgesehen ablaufen können.
Personen, die einen Vorgang bearbeitet haben, zu einem späteren Zeitpunkt keinen planwidrigen
Zugang zu den Unterlagen haben.
Auf den darunter liegenden Ebenen einer IS-Architektur sind analog, lückenlose und aufeinander
abgestimmte Kontrollen zu konzipieren. Dabei ist insbesondere auf folgende Punkte zu achten:
• Lückenlose Kontrollen sind nicht nur innerhalb einer Ebene einzurichten; ein lückenloses IKS
entsteht erst durch eine Abstimmung der Kontrollmechanismen und -tätigkeiten zwischen den
Ebenen (auch Mensch / Anwendungssystem).
• Des weiteren sind Mechanismen vorzusehen die verhindern, daß Kontrollen einer Ebene nach
deren Abschalten oder Ausfall umgangen werden können. Auf jeder Ebene sind auch Kontrollen
zu konzipieren, die die sogenannte Programmidentität sichern [dokumentiertes Programm (Soll) =
eingesetztes Programm (Ist)].
• Die Qualität eines IKS steigt, je mehr Kontrollen automatisiert durchgeführt werden.
Wie in den Folgekapiteln noch dargelegt, umfaßt das IKS auch die Arbeitsabläufe in der Abteilung
EDV (EDV-Durchführung, Programmierung,...). Inwiefern die Vorschrift zur Einrichtung eines
lückenlosen (weitgehend automatisierten) IKS mit datenschutz- oder arbeitsrechtlichen Bestimmungen kollidiert, wurde bisher in der Literatur nicht diskutiert. Grundsätzlich ist das IKS um
geeignete Maßnahmen der Mißbrauchsvorbeugung zu erweitern.
Im Rahmen der Konzeptionsphase ist zu beschreiben, durch welche Maßnahmen die Aufgaben des
IKS erfüllt werden. Die Beschreibung ist gemäß § 257 Abs. 1, Nr. 1 HGB i.V.m. § 239 Abs. 2 HGB
als Teil der Verfahrensdokumentation 10 Jahre versionsweise aufbewahrungspflichtig. [GoBS95: Tz.
4.5]
2.2 Entwicklung und Software-Testat
Das Handels- und Steuerrecht fordert hier lediglich, daß anhand schriftlich fixierter Richtlinien Programmierung und Test durchgeführt werden. Dazu gehören u.a. Standards zur Vergabe von Nummern und Bezeichnungen für Programme, Datenbanken, Dateien und Felder [GoBS95: Tz. 4.4;
FAMA93: Kap.2]. Entsprechende Kontrollmechanismen, die die Durchsetzung der Standards
sichern, sind zu etablieren. Die Richtlinien sind ebenfalls als Teil der Verfahrensdokumentation zu
pflegen und versionsweise 10 Jahre aufbewahrungspflichtig.
Eine Testierung eines IS erfolgt auf Basis der genannten handels- und steuerrechtlichen
Bestimmungen respektive fachlichen Stellungnahmen. Sie umfaßt idealerweise alle IS-Teile bzw.
Module, die rechnungslegungsrelevante Geschäftsprozesse ganz oder in Teilen bearbeiten. Ein
Software-Testat bescheinigt jedoch nur, daß das IS bei sachgerechter Anwendung eine den
Ordnungsmäßigkeitsgrundsätzen entsprechende Verarbeitung der Geschäftsvorfälle ermöglicht
[Ande93a; Koch85]. Da das IKS der wesentliche Baustein ist, um eine sachgerechte Anwendung zu
gewährleisten, kommt der (pro-) aktiven Durchsetzung des IKS (Kap. 2.1) während allen ISLebenszyklusphasen besondere Bedeutung zu.
2.3 Einführung, Freigabe und Erstellung einer Verfahrensdokumentation
Für die Einführung eines IS oder einzelner Programmodule ist gemäß [FAMA93: Kap.2; GoBS95:
Tz. 4.4 u. 6.2.3] nach einem formalisierten und schriftlich fixierten Freigabeverfahren (z.B. Einführungsprojektplan) vorzugehen. Das Freigabeverfahren hat folgende Punkte zu regeln:
•
•
•
•
•
•
•
Umfang der vorzunehmenden Tests durch die Systembetreuer.
Umfang der vorzunehmenden Tests durch die Fachabteilung.
Art und Umfang der Anwenderschulung.
Art und Umfang der Beteiligung der internen Revision.
Zuständigkeit für die Erstellung einer Verfahrensdokumentation (Kap. 3).
Zuständigkeit für die Freigabe.
Zuständigkeit für die Erstellung und Abzeichnung eines Freigabeprotokolls.
Durch ein Freigabeprotokoll ist festzuhalten, wie den Bestimmungen des Freigabeverfahrens entsprochen wurde und zu welchem Zeitpunkt eine Übernahme ins Produktivsystem erfolgte. Insbesondere sind Test- und Fehlerfälle und deren Nachbehandlung zu dokumentieren. Alle Versionen der
schriftlichen Dokumentation des Freigabeverfahrens sowie alle Freigabeprotokolle sind Teil der
Verfahrensdokumentation und somit jeweils 10 Jahre aufbewahrungspflichtig.
2.4 Betrieb und Anpassungen
Während der Betriebsphase hat das IS neben der Unterstützung des operativen Geschäfts eine (pro-)
aktive Durchsetzung des IKS und damit der handels- und steuerrechtlichen Ordnungsmäßigkeitskriterien zu gewährleisten. Die Durchführung aller im IKS vorgesehenen Kontrollen ist durchzusetzen und nachzuweisen. Aufgrund gesetzlicher oder betrieblicher Änderungen kann es während der
Betriebsphase zu Anpassungen des IS kommen. Erfordern die Anpassungen eine Änderung von
Programmcode, sind die Anforderungen aus Kap. 2.1 bis 2.4 (ggf. 2.5) zu beachten. Sind dagegen
Änderungen in rechnungslegungsrelevant klassifizierten (Kap. 2.1) Tabellen- oder Stammdaten vorzunehmen, sind sogenannte Tabellen- bzw. Stammdatenänderungsprotokolle zu erstellen. Diese
Protokolle sind, abhängig davon, ob sie Beleg- oder Verfahrenscharakter haben, 6 bzw. 10 Jahre
aufbewahrungspflichtig.
2.5 Abwicklung und Migration
Der Übergang von einer zur nächsten IS-Generation, u. U. bereits bei einem Releasewechsel der Fall,
hat grundsätzlich analog zu Kap. 2.3 nach einem schriftlich fixierten Freigabeverfahren stattzufinden.
Darüber hinaus sind für eine ordnungsmäßige Abwicklung des Altsystems und Migration zum neuen
System nach Handels- und Steuerrecht folgende Nachweise zu erstellen und als Bestandteil der
Übernahmedokumentation 6 bzw. 10 Jahre aufbewahrungspflichtig:
•
•
•
•
•
•
•
•
•
Beschreibung der Vorgehensweise der Übernahme analog zu Kap. 2.3.
Grund- und Hauptbücher des Altsystems.
Protokoll des rechnungslegungsrelevanten Datenbestands des Altsystems.
Protokoll des rechnungslegungsrelevanten Datenbestands des neuen Systems.
Datenübernahme- bzw. Umsetzprogramme inkl. deren Programmdokumentation.
Nachweis der Abstimmung der übernommenen Stamm- und Bewegungsdaten, insbesondere der
nicht automatisch umsetzbaren Datenfelder.
Nachweis der übernommenen oder geänderten systemsteuernden Tabellen; insb. der nicht automatisch übernommenen.
Nachweis der fehlerhaften Fälle und deren Bereinigung.
Erstellung eines Freigabeprotokolls analog zu Kap 2.3.
3 Moderne Informationssysteme und Verfahrensdokumentation
Eine Verfahrensdokumentation beschreibt zum Zwecke der Nachvollziehbarkeit das Verfahren der
(manuellen und DV-gestützten) Verarbeitung von Geschäftsvorfällen. Daraus folgt, daß die Verfahrensdokumentation sowohl die Beschreibung der eingesetzten Softwaresysteme (Handbücher) als
auch die betriebliche Einbettung der Software durch Organisations- und Arbeitsanweisungen umfaßt.
Eine (nicht abschließende) Auflistung des steuer- und handelsrechtlich geforderten Umfangs der
Verfahrensdokumentation findet sich in [GoBS95: Tz. 6]. Die Erstellung einer solchen (ordnungsmäßigen) Verfahrensdokumentation ist zur Zeit eine wichtige und umfangreiche Aufgabe, die viele
Unternehmen noch zu erfüllen haben. Moderne IS-Architekturen sollten deshalb eine in weiten
Teilen automatisierte oder DV-gestützte Erstellung dieser Verfahrensbeschreibungen ermöglichen.
Beispielsweise versprechen die Ablaufbeschreibungs- und Modellierungskomponenten von
Workflowmanagement-Systemen hier eine wesentliche Kostenersparnis [Phil96].
4 Schlußbetrachtung und Handlungsbedarf
In diesem Beitrag wurden handels- und steuerrechtliche Anforderungen auf den Lebenszyklus von
IS-Architekturen übertragen. Dabei fanden insbesondere die im November 1995 in die AO-Kartei
übernommenen GoBS Berücksichtigung. Es wurde primär auf die Anforderungen an Informationssysteme eingegangen, die rechnungslegungsrelevante Geschäftsprozesse abbilden. Anforderungen an
Buchhaltungs-Informationssysteme i.e.S., wie sie auch in den GoBS (insb. Tz. 2 u. 3) beschrieben
werden, waren nicht der primäre Betrachtungsgegenstand.
Bei der Umsetzung der GoBS in der betrieblichen Praxis und deren Kontrolle durch die EDVRevision hat sich gezeigt, daß insbesondere in den Bereichen der Erstellung und Pflege von Verfahrensdokumentationen erheblicher Handlungsbedarf besteht. Geeignete Werkzeuge zur automatisierten Erstellung sind nur in Ansätzen vorhanden. Festzustellen ist auch, daß viele Unternehmen zwar
zahlreiche interne Kontrollen in ihren Geschäftsprozessen vorgesehen haben, aber über deren Konsistenz, Zuverlässigkeit und Lückenlosigkeit oftmals keine Aussagen treffen können. Ursächlich hierfür
dürfte sein, daß es an einer „geschlossenen Konzeption zur optimalen Gestaltung und zur Prüfung
von Internen Kontrollsystemen“ fehlt [Sieb89]. Hier besteht interdisziplinärer Forschungsbedarf von
Seiten der Wirtschaftsprüfung, Wirtschaftsinformatik und EDV-Revision.
Literatur:
[Ande93] Arthur Andersen (Hrsg.): Bericht über die Prüfung der Ordnungsmäßigkeit des Finanzbuchhaltungsmoduls
FI der Software R/3, Stuttgart, 23. Juli 1993
[AWV93] AWV-Schrift 09 528: Gesetzliche Anforderungen an moderne Verfahren zur Erfassung und Übermittlung
von Buchhaltungsdaten, AWV (Hrsg.), 1993
[FAMA87] IDW (Hrsg.): Stellungnahme FAMA 1/1987: Grundsätze ordnungsmäßiger Buchführung bei
computergestützten Verfahren und deren Prüfung, IDW, 1987
[FAMA93] IDW (Hrsg.): FAMA-Fragebogen „DV-Systemprüfung“ - Anlage zur Stellungnahme FAMA 1/1987, in:
FN-IDW 11/1993, S. 462 ff.
[GoBS95] Bundesministerium der Finanzen: Abgabenordnung - Grundsätze ordnungsmäßiger DV-gestützter
Buchführungssysteme (GoBS), in: Bundessteuerblatt 1995, Teil 1, Nr. 18, S. 738 ff.; AWV-Schrift 09 546:
Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme - GoBS, AWV (Hrsg.), 1995
[GoS78] Bundesministerium der Finanzen: Abgabenordnung - Grundsätze ordnungsmäßiger Speicherbuchführung
(GoS), in: Bundessteuerblatt 1978, Teil 1, S. 250 ff.
[HaKe90] Hanisch, H., Kempf, D.: Revision und Kontrolle von EDV-Anwendungen im Rechnungswesen, 1990
[HoKö90] Hoyer, R., Kölzer, G.: Kommunikations-System-Studie, in: Lexikon der Wirtschaftsinformatik, P. Mertens
(Hrsg.), 2. Aufl., 1990, S. 249 ff.
[Koch85] Koch, B.: Das Software-Testat, in: Die Wirtschaftsprüfung, 24/1985, S. 645 ff.
[Kühn93] Kühnberger, M.: Buchhaltung - Von der Buchführung zum Jahresabschluß, 1993
[Leff88] Leffson, U.: Wirtschaftsprüfung, 4. vollst. überarb. u. erw. Aufl., 1988
[Phil96] Philipp, M.: Aus Handels- und Steuerrecht abgeleitete Anforderungen an Geschäftsprozeßmodelle und
Workflow-Managementsysteme, in: EMISA Forum, Mitteilungen der GI-Fachgruppe „Entwicklungsmethoden für
Informationssysteme und deren Anwendung“, Heft 1/1996, S. 38 ff.; Philipp, M.: Anforderungen der Internen
Revision an Workflow-Managementsysteme, in: Zeitschrift für Interne Revision (ZIR), erscheint Herbst 1996
[Sieb89] Sieben, G.: Geleitwort, in: Adenauer, P.: Die Berücksichtigung des Internen Kontrollsystems bei der
Jahresabschlußprüfung, 1989
[Thom94] Thomas, A.: IKS in und mit qualifizierter Standard-Anwendungssoftware - dargestellt am Beispiel SAP, in:
Die Wirtschaftsprüfung, 5/94, S.137 ff.; Thomas, A.: Beiträge zum Auf- und Ausbau eines Internen
Kontrollsystems bei SAP-Anwendern, in: Wirtschaftsinformatik, 3/94, S. 215 ff.