Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV...

244
Rechnungslegung von Standard-Softwareunternehmen DISSERTATION der Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG) zur Erlangung der Würde eines Doktors der Wirtschaftswissenschaften vorgelegt von Michael Studer von Winterthur (Zürich) und Oberhof (Aargau) Genehmigt auf Antrag der Herren Prof. Dr. Giorgio Behr und Prof. Dr. Beat Schmid Dissertation Nr. 3280 Gutenberg AG, Schaan 2007

Transcript of Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV...

Page 1: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

Rechnungslegung von Standard-Softwareunternehmen

DISSERTATION

der Universität St. Gallen,

Hochschule für Wirtschafts-,

Rechts- und Sozialwissenschaften (HSG)

zur Erlangung der Würde eines

Doktors der Wirtschaftswissenschaften

vorgelegt von

Michael Studer von

Winterthur (Zürich) und Oberhof (Aargau)

Genehmigt auf Antrag der Herren

Prof. Dr. Giorgio Behr

und

Prof. Dr. Beat Schmid

Dissertation Nr. 3280

Gutenberg AG, Schaan 2007

Page 2: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

Die Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissen-schaften (HSG), gestattet hiermit die Drucklegung der vorliegenden Dissertation, ohne damit zu den darin ausgesprochenen Anschauungen Stellung zu nehmen.

St. Gallen, den 13. November 2006

Der Rektor:

Prof. Ernst Mohr, PhD

Page 3: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

Vorwort

Im Hinblick auf die vorliegende Arbeit bin ich einer ganzen Reihe von Personen zu Dank verpflichtet, welche alle massgeblich beigetragen haben, dass diese Dissertation schlussendlich in dieser Form vorliegt.

Ich danke ganz herzlich meinem Doktorvater Herrn Prof. Dr. Behr für seine grosse Unterstützung und die mir gewährte akademische Freiheit, welche es mir erlaubte, mit dieser Arbeit meine persönlichen Interessen zu verfolgen. Grossem Dank bin ich auch meinem Korreferenten Prof. Dr. Beat Schmid schuldig, welcher sich bereit erklärte, diese Arbeit fachlich zu begleiten.

Ein weiterer Dank richtet sich an die Doktoranden des Lehrstuhls für Rechnungsle-gung, welche mir zum einen Anregungen in der konzeptionellen Phase zukommen liessen, mich zum anderen aber auch in der Schlussphase der Dissertation unterstützt haben. Dabei möchte ich mich namentlich bei Dr. Rainer Schöllhammer und bei Sven Hoffmann für ihren besonderen Einsatz bedanken.

Die vorliegende Arbeit stützt sich wesentlich auf Anregungen von Unternehmensver-tretern, Wirtschaftsprüfern und Analysten der Standard-Softwareindustrie. Sie haben in zahlreichen Expertengesprächen bereitwillig und offen ihr umfangreiches Fachwis-sen für die Dissertation zur Verfügung gestellt.

Den grössten Dank schulde ich jedoch meiner Freundin Marion Ulmer, welche mich tatkräftig in der Korrekturphase unterstützte und zudem trotz eigener Belastung mir immer viel Verständnis entgegenbrachte.

Michael Studer

Page 4: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability
Page 5: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSÜBERSICHT i

Inhaltsübersicht

Teil I: Einleitung....................................................................................................... 1

1. Hintergrund.................................................................................................... 1

2. Zielsetzung und Struktur ............................................................................... 2

3. Definitionen................................................................................................... 5

4. Forschungsmethodik ................................................................................... 12

Teil II: Charakteristika von Standard-Softwareunternehmen.......................... 14

1. Struktur der (Standard-)Softwareindustrie .................................................. 14

2. Marktmechanismen in der Standard-Softwareindustrie.............................. 16

3. Charakteristika von Standard-Softwareunternehmen.................................. 26

4. Zusammenfassung: Besonderheiten von Standard-Softwareunternehmen. 43

Teil III: Anforderungen der externen Analyse.................................................... 45

1. Definition der Qualitätskriterien ................................................................. 45

2. Problembereiche der Rechnungslegung ...................................................... 51

3. Zusammenfassung: Informationsbedürfnisse der Investoren...................... 61

Teil IV: Analyse der Rechnungslegung von Standard-Softwareunternehmen 63

1. Relevante Rechnungslegungssysteme......................................................... 63

2. Beurteilung der Rechnungslegungsvorschriften ......................................... 69

3. Zusammenfassung: Nutzen der bestehenden Rechnungslegung für Investoren .................................................................................................. 114

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen....... 116

1. Einleitung .................................................................................................. 116

2. Umsatzerfassung ....................................................................................... 117

3. (Selbsterstellte) Standard-Software........................................................... 148

4. Immaterielle Werte (ohne Software)......................................................... 167

5. Zukunftsbezogene Berichterstattung......................................................... 182

Page 6: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSÜBERSICHT ii

Teil VI: Schlussfolgerungen und Ausblick......................................................... 188

1. Zusammenfassung der Ergebnisse ............................................................ 188

2. Evaluation und Schlussfolgerungen .......................................................... 189

Anhang 1: Untersuchung von Geschäftsberichten.................................................I

Anhang 2: Expertengespräche ..............................................................................III

Quellenverzeichnis.................................................................................................. IX

Page 7: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSVERZEICHNIS iii

Inhaltsverzeichnis

Abbildungsverzeichnis .......................................................................................... viii

Fallstudienverzeichnis .............................................................................................. x

Abkürzungsverzeichnis ........................................................................................... xi

Teil I: Einleitung....................................................................................................... 1

1. Hintergrund.................................................................................................... 1

2. Zielsetzung und Struktur ............................................................................... 2

3. Definitionen................................................................................................... 5

3.1. Definition Standard-Software............................................................... 6

3.2. Definition Standard-Softwareunternehmen.......................................... 9

3.3. Definition Externe Analyse ................................................................ 10

4. Forschungsmethodik ................................................................................... 12

Teil II: Charakteristika von Standard-Softwareunternehmen.......................... 14

1. Struktur der (Standard-)Softwareindustrie .................................................. 14

2. Marktmechanismen in der Standard-Softwareindustrie.............................. 16

2.1. Einfache Skalierbarkeit....................................................................... 16

2.2. Netzwerkeffekte und Standards.......................................................... 17

2.3. Diskontinuierliche, technologische Innovationen .............................. 20

2.4. Bedeutung von Wachstum.................................................................. 22

2.5. Exkurs: Open Source Software........................................................... 24

2.6. Fazit .................................................................................................... 25

3. Charakteristika von Standard-Softwareunternehmen.................................. 26

3.1. Geschäftstätigkeitsbezogene Charakteristika ..................................... 27

3.1.1. Forschung und Entwicklung........................................................... 27

3.1.2. Vertrieb........................................................................................... 28

3.1.3. Partnerschaften ............................................................................... 31

3.2. Organisatorische Charakteristika........................................................ 34

Page 8: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSVERZEICHNIS iv

3.3. Finanzbezogene Charakteristika......................................................... 36

3.3.1. Kapitalfluss..................................................................................... 36

3.3.2. Finanzierung................................................................................... 39

3.3.3. Ertragsmodell ................................................................................. 39

3.3.3.1. Support Seller Ertragsmodell .................................................... 40

3.3.3.2. Loss Leader Ertragsmodell........................................................ 41

3.3.3.3. Widget Frosting Ertragsmodell ................................................. 42

3.3.3.4. Accessorizing Ertragsmodell..................................................... 43

4. Zusammenfassung: Besonderheiten von Standard-Softwareunternehmen. 43

Teil III: Anforderungen der externen Analyse.................................................... 45

1. Definition der Qualitätskriterien ................................................................. 45

1.1. Anforderungen im Rahmen der relevance.......................................... 47

1.2. Anforderungen im Rahmen der reliability ......................................... 49

2. Problembereiche der Rechnungslegung ...................................................... 51

2.1. Umsatzerfassung................................................................................. 52

2.2. Berichterstattung über Standard-Software ......................................... 53

2.3. Berichterstattung über immaterielle Werte ........................................ 55

2.4. Zukunftsbezogene Berichterstattung .................................................. 59

3. Zusammenfassung: Informationsbedürfnisse der Investoren...................... 61

Teil IV: Analyse der Rechnungslegung von Standard-Softwareunternehmen 63

1. Relevante Rechnungslegungssysteme......................................................... 63

1.1. IFRS.................................................................................................... 64

1.2. US-GAAP........................................................................................... 65

2. Beurteilung der Rechnungslegungsvorschriften ......................................... 69

2.1. Einleitung............................................................................................ 69

2.2. Berichterstattung zur Umsatzerfassung.............................................. 69

2.2.1. Definition ....................................................................................... 70

Page 9: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSVERZEICHNIS v

2.2.2. Realisierung.................................................................................... 71

2.2.2.1. Standard-Software-Vereinbarungen mit einer Komponente..... 74

2.2.2.2. Standard-Software-Vereinbarungen mit mehreren Komponenten ............................................................................ 75

2.2.3. Bilanzierung und Bewertung.......................................................... 86

2.2.4. Offenlegung.................................................................................... 88

2.2.5. Beurteilung aus Sicht der externen Analyse .................................. 90

2.3. Berichterstattung über (selbsterstellte) Standard-Software ................ 92

2.3.1. Bilanzierung und Bewertung.......................................................... 93

2.3.2. Offenlegung.................................................................................. 102

2.3.3. Beurteilung aus Sicht der externen Analyse ................................ 102

2.4. Berichterstattung über immaterielle Werte (ohne Software)............ 104

2.4.1. Bilanzierung und Bewertung........................................................ 106

2.4.2. Offenlegung.................................................................................. 110

2.4.3. Beurteilung aus Sicht der externen Analyse ................................ 111

2.5. Zukunftsbezogene Berichterstattung ................................................ 112

2.5.1. Regelungen von IFRS und US-GAAP......................................... 113

2.5.2. Beurteilung aus Sicht der externen Analyse ................................ 113

3. Zusammenfassung: Nutzen der bestehenden Rechnungslegung für Investoren .................................................................................................. 114

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen....... 116

1. Einleitung .................................................................................................. 116

1.1. Ziel des Rahmenkonzeptes ............................................................... 116

1.2. Methodologie.................................................................................... 116

1.3. Übersicht........................................................................................... 117

2. Umsatzerfassung ....................................................................................... 117

2.1. Einleitung.......................................................................................... 117

2.2. Optionen ........................................................................................... 119

2.2.1. Vorschläge der Standardsetter...................................................... 119

2.2.2. Der assets-and-liabilities Ansatz ................................................. 123

2.2.2.1. Umsatzabgrenzung .................................................................. 123

Page 10: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSVERZEICHNIS vi

2.2.2.2. Umsatzrealisation .................................................................... 125

2.2.2.3. Bewertung ............................................................................... 130

2.2.2.4. Offenlegung............................................................................. 137

2.3. Entscheidungsnutzenanalyse ............................................................ 138

2.3.1. Wahl des Ansatzes ....................................................................... 138

2.3.2. Umsatzabgrenzung ....................................................................... 140

2.3.3. Umsatzrealisation ......................................................................... 143

2.3.4. Bewertung .................................................................................... 144

2.3.5. Offenlegung.................................................................................. 146

2.4. Fazit .................................................................................................. 147

3. (Selbsterstellte) Standard-Software........................................................... 148

3.1. Einleitung.......................................................................................... 148

3.2. Optionen ........................................................................................... 150

3.2.1. „Identifikation“ als Ansatzkriterium ............................................ 152

3.2.2. Rückwirkende Aktivierung .......................................................... 157

3.2.3. Vermögenswerte in Entstehung ................................................... 161

3.3. Entscheidungsnutzenanalyse ............................................................ 163

3.4. Fazit .................................................................................................. 166

4. Immaterielle Werte (ohne Software)......................................................... 167

4.1. Einleitung.......................................................................................... 167

4.1.1. Kontrolle / Partieller Ausschluss.................................................. 168

4.1.2. Finanzielle Messgrössen .............................................................. 169

4.1.3. Interner oder externer Zugang...................................................... 169

4.2. Optionen ........................................................................................... 170

4.2.1. Monetäre Bewertung von immateriellen Werten......................... 171

4.2.1.1. Marktwert-Buchwert Relation................................................. 171

4.2.1.2. Cash Flow Bewertung ............................................................. 172

4.2.2. Nicht-monetäre Berichterstattung ................................................ 173

4.2.2.1. Skandia Navigator ................................................................... 174

4.2.2.2. Jenkins Report ......................................................................... 177

Page 11: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

INHALTSVERZEICHNIS vii

4.3. Entscheidungsnutzenanalyse ............................................................ 178

4.4. Fazit .................................................................................................. 180

5. Zukunftsbezogene Berichterstattung......................................................... 182

5.1. Einleitung.......................................................................................... 182

5.2. Optionen ........................................................................................... 182

5.2.1. Generelle Vorschriften ................................................................. 182

5.2.2. Branchenspezifische Sonderregelungen....................................... 183

5.3. Entscheidungsnutzenanalyse ............................................................ 184

5.4. Fazit .................................................................................................. 185

5.5. Zusammenfassung: Rechnungslegungskonzept für Standard-Softwareunternehmen....................................................................... 186

Teil VI: Schlussfolgerungen und Ausblick......................................................... 188

1. Zusammenfassung der Ergebnisse ............................................................ 188

2. Evaluation und Schlussfolgerungen .......................................................... 189

2.1. Evaluation ......................................................................................... 189

2.1.1. Evaluation aus Stakeholdersicht................................................... 189

2.1.1.1. Investoren ................................................................................ 189

2.1.1.2. Standard-Softwareunternehmen .............................................. 191

2.1.1.3. Externe Wirtschaftsprüfer ....................................................... 192

2.1.1.4. Standardsetter .......................................................................... 192

2.1.2. Evaluation aus Implementierungssicht ........................................ 193

2.2. Schlussfolgerungen........................................................................... 195

Anhang 1: Untersuchung von Geschäftsberichten.................................................I

Anhang 2: Expertengespräche ..............................................................................III

2.1. Gesprächsleitfaden Analysten ..................................................................... III

2.2. Gesprächsleitfaden Ersteller/Wirtschaftsprüfer ........................................... V

2.3. Übersicht der Gesprächspartner .................................................................VII

Quellenverzeichnis.................................................................................................. IX

Literaturverzeichnis .............................................................................................. IX

Normenverzeichnis ...........................................................................................XXV

Page 12: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ABBILDUNGSVERZEICHNIS viii

Abbildungsverzeichnis

Abbildung 1: Struktur und Inhalt der Dissertation ................................................. 5

Abbildung 2: Software-Typologie.......................................................................... 8

Abbildung 3: Typen von Aktienanalyse-Techniken ............................................ 10

Abbildung 4: Prozessschritte der Fundamentalanalyse........................................ 11

Abbildung 5: Struktur der (Standard-)Softwareindustrie ..................................... 15

Abbildung 6: Unterschiede zwischen Standard- und Individualsoftwaregeschäft ............................................................ 15

Abbildung 7: Jährliches Wachstum der Softwareindustrie .................................. 23

Abbildung 8: Kapitalflussdiagramm .................................................................... 38

Abbildung 9: Qualitätskriterien der Rechnungslegung ........................................ 47

Abbildung 10: Wertschöpfungskette von Standard-Softwareunternehmen........... 52

Abbildung 11: Typen von immateriellen Werten................................................... 59

Abbildung 12: Anforderungen an die Berichterstattung ........................................ 62

Abbildung 13: House of GAAP ............................................................................. 67

Abbildung 14: Kategorien von Nebenkomponenten nach SOP 97-2..................... 79

Abbildung 15: Indikatoren zur Wesentlichkeit von Dienstleistungen ................... 80

Abbildung 16: Behandlung von Software nach IFRS und US-GAAP................... 93

Abbildung 17: Unterschiedliche Verbuchung von Softwareaufwendungen........ 103

Abbildung 18: Ziel und Struktur von Teil V........................................................ 117

Abbildung 19: Bilanzieller Ansatz von pre-und post-performance assets und liabilities ................................................................................ 129

Abbildung 20: Vergleich der Alternativen zur Bewertung von Leistungspflichten ................................................................. 136

Abbildung 21: Entstehungsphasen von (Standard-)Software aus Rechnungslegungssicht ................................................................ 149

Abbildung 22: Stufendarstellung der Reifegrade des CMMI .............................. 155

Abbildung 23: Vorgang der rückwirkenden Aktivierung .................................... 158

Abbildung 24: Kategorisierung der Modelle zur Bemessung von immateriellen Werten................................................................... 171

Abbildung 25: IC-Navigator von Skandia............................................................ 175

Page 13: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ABBILDUNGSVERZEICHNIS ix

Abbildung 26: Model of business reporting (Jenkins) ......................................... 177

Abbildung 27: Rechnungslegungskonzept für Standard-Softwareunternehmen . 187

Abbildung 28: Zusammenfassung der Hauptergebnisse dieser Dissertation ....... 188

Page 14: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

FALLSTUDIENVERZEICHNIS x

Fallstudienverzeichnis

Fallstudie 1: Browserkrieg I .................................................................................. 20

Fallstudie 2: Browserkrieg II................................................................................. 22

Fallstudie 3: Adobe Acrobat.................................................................................. 30

Fallstudie 4: Lean Edition ..................................................................................... 31

Fallstudie 5: Vertriebspartnerschaften bei Abacus................................................ 32

Fallstudie 6: Suse Linux ........................................................................................ 41

Fallstudie 7: Quicktime Player .............................................................................. 41

Fallstudie 8: Intel................................................................................................... 42

Fallstudie 9: O'Reilly............................................................................................. 43

Fallstudie 10: Lotus 1-2-3 ....................................................................................... 61

Fallstudie 11: Realisationsalternativen bei Standard-Software-Vereinbarungen ... 74

Fallstudie 12: Standard-Softwarelizenzverkauf bei Unternehmen A...................... 76

Fallstudie 13: Umsatzrealisierung bei Esmertec ..................................................... 77

Fallstudie 14: Aufteilung von Rabatten auf die Einzelkomponenten nach SOP 97-2.................................................................................. 83

Fallstudie 15: Computer Associates ........................................................................ 86

Fallstudie 16: Aktivierung von selbsterstellter Software nach IFRS ...................... 95

Fallstudie 17: Keine Aktivierung von selbsterstellter Software nach IFRS ........... 96

Fallstudie 18: Standard-Softwarebilanzierung bei Microsoft ............................... 100

Fallstudie 19: Aktivierung von Marken ................................................................ 112

Fallstudie 20: Standard-Softwareunternehmen X ................................................. 121

Fallstudie 21: Standard-Softwareunternehmen X fortgesetzt ............................... 133

Page 15: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ABKÜRZUNGSVERZEICHNIS xi

Abkürzungsverzeichnis

AcSEC Accounting Standards Executive Committee (der AICPA)

AICPA American Institute of Certified Public Accountants

APB Accounting Principles Board (Opinion)

ARB Accounting Research Bulletin

ASB Accounting Standards Board (Grossbritannien)

AU Auditing Standard (der AICPA)

BB Betriebsberater

bzw. beziehungsweise

CAP Committee on Accounting Procedure

CASE Computer Aided Software Engineering

CBV Customer Based Value

CD Compact Disk

CEO Chief Executive Officer

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration

CPA Certified Public Accountant

DCF Discounted Cash Flow

DVD Digital Versatile Disk

d. h. das heisst

EITF Emerging Issues Task Force

ERP Enterprise Resource Planning

e. V. eingetragener Verein

Page 16: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ABKÜRZUNGSVERZEICHNIS xii

f. folgende

ff. fortfolgende

F. Framework (Rahmenkonzept des IASB)

FASB Financial Accounting Standards Board

F&E Forschung und Entwicklung

FIN FASB Interpretation

GAAP Generally Accepted Accounting Principles

Hrsg. Herausgeber

HTML HyperText Markup Language

IAS International Accounting Standards

IASB International Accounting Standards Board

IDC International Data Corporation

IDW Institut der Wirtschaftsprüfer in Deutschland e. V.

IFRS International Financial Reporting Standards

IT Informationstechnologie

Jg. Jahrgang

Mio. Million

Nr. Nummer

o.V. ohne Verfasser

Par. Paragraph

Page 17: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ABKÜRZUNGSVERZEICHNIS xiii

SAB Staff Accounting Bulletin

SAS Statement on Auditing Standards

SEC Securites and Exchange Commission

SFAC Statement on Financial Accounting Concepts

SFAS Statement on Financial Standards

SIIA Software and Information Industry Association

SOP Statement of Position

USA United States of America

US-GAAP United States Generally Accepted Accounting Principles

vgl. vergleiche

Vol. Volume

W3C World Wide Web Committee

WLAN Wireless Local Area Network

WWW World Wide Web

z. B. zum Beispiel

ZfB Zeitschrift für Betriebswirtschaft

Page 18: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability
Page 19: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 1

Teil I: Einleitung

1. Hintergrund

Der Wandel unserer Gesellschaft zur Wissensgesellschaft zeigt sich deutlich im ste-tig steigenden Stellenwert von Informations- und Kommunikationstechnologien in allen Lebensbereichen. Dabei stützen sich alle diese Technologien in der einen oder anderen Art auf Software. Diese Tatsache lässt Software zunehmend zu einem der wichtigsten Erfolgsfaktoren in Unternehmen werden. HOCH ET AL. sprechen sogar plakativ vom Leben in einer „softwaresüchtigen Welt“1. Die steigende Bedeutung von Software führt zu einem entsprechend höheren Stellenwert der Softwareindust-rie und einem ungebrochenen Wachstum der meisten Softwareunternehmen.2 Eine erfolgreiche Softwareindustrie wird in der Öffentlichkeit mehr denn je als ein zent-raler Faktor der Wettbewerbsfähigkeit einer Volkswirtschaft in der neuen „Wis-senswirtschaft“ wahrgenommen; eine Industrie, die Wohlstand und zahlreiche hochwertige Arbeitsplätze hervorbringt.

Die Softwareindustrie wird durch Standard-Softwareunternehmen dominiert. Dies wird nicht zuletzt dadurch ersichtlich, dass weltweit bekannte Softwareunternehmen wie Microsoft, Oracle oder SAP alle Produkte im Bereich der Standard-Software entwickeln. Die Vorherrschaft der Standard-Software liegt in der enormen und ste-tig steigenden Komplexität von Software begründet. Nur die Standardisierung er-möglicht es, Lösungen mit vertretbaren Entwicklungskosten hervorzubringen. Fol-gende Tendenzen sind zudem auszumachen:3

• Der stetig steigende Anteil von Standard-Software an der weltweiten Soft-wareindustrie zeigt eine zunehmende Bedeutung dieses Segments.

• Nicht nur auf Unternehmensebene lässt sich ein Trend hin zu Standard-Software (viele Unternehmen verlagern ihren Fokus zunehmend von der Entwicklung von Individualsoftware hin zu Standard-Software) beobachten,

1 Hoch et al. (2000), S. 5. 2 So schätzt das Marktforschungsunternehmen Gartner für die Softwarebranche ein globales Umsatz-

wachstum mit Endabnehmern von 8.5 Prozent für das Jahr 2005. Vgl. o.V. (2004a). 3 Vgl. Müller (1999), S. 33.

Page 20: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 2

sondern auch auf Länderebene (die meisten Schwellenländer mit Software-industrie beginnen aufgrund der niedrigen Eintrittsbarrieren in der Individu-alsoftwareindustrie und steigen langsam auf Standard-Software um).

• Die höhere Misserfolgsquote im Standard-Softwaresegment lässt darauf schliessen, dass dieses Segment komplizierter und damit schwerer be-herrschbar ist. Dies macht die Kenntnis der Erfolgsfaktoren dieses Segments noch wichtiger.

Die Relevanz des Dissertationsthemas ergibt sich daraus, dass Standard-Software-unternehmen offensichtlich eine steigende gesamtwirtschaftliche Bedeutung ein-nehmen und zugleich aufgrund ihres Wachstums eine zunehmend wichtigere Rolle als Nachfrager auf den internationalen Finanzmärkten spielen.4 Viele Stan-dard-Softwareunternehmen können ihr rasantes Wachstum nicht selbst finanzieren. Sie sind deshalb auf den Zufluss externer finanzieller Mittel angewiesen. Die klassi-sche Fremdfinanzierung ist dabei meist nicht möglich, denn die Investitionen in immaterielle Werte können nicht als Sicherheiten für die getätigte Finanzierung dienen. Entsprechend finanziert sich die Mehrzahl der Standard-Softwareunter-nehmen über den freien Kapitalmarkt. Unter diesen Gesichtspunkten ist eine aussa-gekräftige Rechnungslegung für Standard-Softwareunternehmen von grosser Be-deutung, um dem potenziellen externen Investor ausreichend Informationen zur A-nalyse des Unternehmens bereitstellen zu können und ihm somit eine ausreichende Basis für seine Investitionsentscheidung zu schaffen.

2. Zielsetzung und Struktur

Primäres Ziel dieser Dissertation ist die Entwicklung eines Rahmenkonzepts für die Rechnungslegung von Standard-Softwareunternehmen, welches den Fokus auf die Befriedigung der Informationsbedürfnisse von (externen) Investoren legt. Dabei ist es nicht das Ziel, einen detaillierten technischen Standard zu entwickeln, sondern

4 Nach der Financial Times Global 500 sind unter den hundert grössten Unternehmen der Welt (nach Marktkapitalisierung) vier (Standard-)Softwareunternehmen vertreten, Microsoft (3), IBM (13), Oracle (66) und SAP (97). Vgl. Coggan (2005).

Page 21: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 3

einen konzeptionellen Rahmen zu gestalten, der Vorschläge für zentrale Rech-nungslegungsfragen von Standard-Softwareunternehmen beinhaltet.

Um dieses Ziel zu erreichen, ist die Dissertation in folgende sechs Teile gegliedert. Im Anschluss an diesen einleitenden Teil (Teil I: Einleitung) folgen drei Teile, wel-che die deskriptive Basis bilden. Daraus wird in Teil V ein normatives Rahmenkon-zept für die Rechnungslegung von Standard-Softwareunternehmen abgeleitet:

Teil II: Charakteristika von Standard-Softwareunternehmen

Die Beschreibung der Besonderheiten des Betrachtungsobjekts bildet die Grundlage für die weitere Arbeit. Dieser Teil beginnt mit der Analyse der Marktmechanismen in der Standard-Softwareindustrie. Darauf basierend werden die Charakteristika von Standard-Softwareunternehmen dargestellt. Beispiele aus der Praxis illustrieren die gemachten Feststellungen.

Teil III: Anforderungen der externen Analyse

Dieser Teil widmet sich den Anforderungen der externen Analyse an die Be-richterstattung von Standard-Softwareunternehmen. Um eine möglichst gros-se Allgemeingültigkeit der Resultate zu erreichen, wird dabei auf die allge-mein anerkannten Qualitätskriterien der Rahmenkonzepte der IFRS und US-GAAP zurückgegriffen.

Teil IV: Analyse der Rechnungslegung von Standard-Softwareunternehmen

Der Inhalt dieses Teils umfasst primär eine Zusammenfassung der bestehen-den internationalen Rechnungslegungsstandards (IFRS und US-GAAP), wel-che für Standard-Softwareunternehmen relevant sind. In einem weiteren Schritt werden die einzelnen Standards anhand der Informationsbedürfnisse der Investoren miteinander verglichen und beurteilt. Abschliessend wird die Frage diskutiert, inwiefern die bestehenden Rechnungslegungsvorschriften die Informationsbedürfnisse der Investoren befriedigen.

Die Teile III und IV stellen somit die institutionellen Strukturen bereit, in welchen das investororientierte Rahmenkonzept für die Rechnungslegung von Standard-Softwareunternehmen zu entwickeln ist. Teil III definiert die Informationsbe-dürfnisse von Investoren für die externe Analyse. Teil IV untersucht, inwiefern diese

Page 22: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 4

Informationsbedürfnisse durch die bestehende Rechnungslegung befriedigt werden. Alle diese Ergebnisse bilden die Basis für die Entwicklung eines investororientier-ten Rahmenkonzepts für die Rechnungslegung von Standard-Softwareunternehmen in Teil V:

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen

Dieser Themenbereich bildet den Hauptteil der Dissertation und entwickelt einen Vorschlag für ein Rahmenkonzept für die Rechnungslegung von Stan-dard-Softwareunternehmen, welches die Informationsbedürfnisse der Inves-toren am besten befriedigt.

Der letzte Teil fasst die zentralen Ergebnisse dieser Dissertation zusammen und evaluiert sie:

Teil VI: Schlussfolgerungen und Ausblick

Das erste Kapitel von Teil VI fasst die wichtigsten Ergebnisse der Dissertati-on zusammen. Das zweite und finale Kapitel evaluiert das vorgeschlagene Rahmenkonzept aus der Perspektive der wichtigsten Stakeholder und be-schäftigt sich zudem mit möglichen Implementierungsfolgen. In diesem Kontext werden zukünftige Forschungsgebiete identifiziert.

Die folgende Abbildung stellt die Struktur der Dissertation grafisch dar:

Page 23: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 5

• Untersuchung der Besonderheiten der Standard-Softwareindustrie • Analyse der Charakteristika von Standard-Softwareunternehmen

• Identifikation der Informationsbedürfnisse der Investoren

• Untersuchung der bestehenden Rechnungslegungsstandards (IFRS und US-GAAP) im Bereich der Standard-Softwareunternehmen

• Anwendung der bestehenden

Regelungen von Standard-Softwareunternehmen

Teil II: Analyse der Standard-Softwarebranche

Teil III: Informationsbedürfnisse des Investors

• Entwicklung eines Rahmenkonzepts für die Rechnungslegung von Standard-Softwareunternehmen, welches die Informationsbedürfnisse von Investoren am besten befriedigt

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen

Teil IV: Analyse der Rechnungslegung

Teil VI: Zusammenfassung und Schlussfolgerung

Durch die Rechnungslegung bereitgestellte Information

Informationsbedarf des externen Investors

STA

ND

ARD

PR

AX

IS

• Zusammenfassung der Schlussfolgerungen • Betrachtung der Implementationsfolgen • Ausblick

• Hintergrund, Struktur und Ziel der Dissertation • Forschungsmethodik

Teil I: Einleitung

Abbildung 1: Struktur und Inhalt der Dissertation

3. Definitionen

Entsprechend dem Titel und der Struktur dieser Dissertation müssen einige Begriffe definiert werden, um die Themenstellung klar darlegen zu können. Es handelt sich dabei um die Begriffe Standard-Software, Standard-Softwareunternehmen und ex-terne Analyse.

Page 24: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 6

3.1. Definition Standard-Software

Insbesondere aus theoretischer Sicht wird Software häufig in einem engeren und in einem weiteren Sinn definiert.5 Software im engeren Sinn ist „als Sammelbegriff für Programme“6 zu verstehen. Ein Programm definiert sich gemäss HANSEN als eine „zur Lösung einer Aufgabe vollständige Anweisung an eine Datenverarbeitungs-anlage“7. Diese technisch geprägte Begriffsdefinition entspricht weitgehend dem alltäglichen Sprachgebrauch, wo die Begriffe „Software“ und „Programm“ eine synonyme Verwendung finden. Im weiteren Sinne erfasst der Begriff Software nicht nur das Programm, sondern auch ergänzende materielle und immaterielle Zusatz-leistungen, „die zusammen ein marktfähiges Produkt bilden“8. Der erweiterte Beg-riff umfasst damit – im Sinne eines erweiterten Produktbegriffes – auch die zugehö-rigen Dienstleistungen wie zum Beispiel Dokumentation, Schulung und Beratung.9

In der vorliegenden Dissertation findet der weiter gefasste Software-Begriff An-wendung, da nicht die technischen, sondern die marktorientierten Aspekte unter-sucht werden sollen.

In Wissenschaft und Praxis sind zahlreiche Arten der Segmentierung von Software bekannt, wobei meist entweder eine technische Perspektive oder eine betriebswirt-schaftlich-marktorientierte Perspektive eingenommen wird.10

Aus technischer Perspektive hat sich überwiegend eine Segmentierung nach der Dimension der Systemnähe, d. h. der Nähe zum Hardware-Kern durchgesetzt.11 Da-bei wird mehrheitlich eine Grobunterteilung in Systemsoftware und Anwendungs-software vorgenommen.12 Unter Systemsoftware werden Programme verstanden,

5 Vgl. Müller (1999), S. 10. 6 Hansen/Neumann (2001), S. 35. 7 Hansen/Neumann (2001), S. 12. 8 Hoppenheit (1993), S. 19. 9 Vgl. Österle (1990), S. 10. 10 Vgl. die Auflistung ausgewählter Definitionen für Computersoftware und -dienstleistungen der OECD

(1998), S. 13-15. 11 Ein weiteres Segmentierungskriterium kann die Zielplattform sein. Die Bedeutung dieser Dimension hat

aber unter anderem durch das Aufkommen von Middleware stark abgenommen. 12 Vgl. Hansen (1992), S. 354ff.; Schildhauer (1992), S. 14; Sauer (1988), S. 13ff.

Page 25: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 7

welche die Rechnerressourcen steuern und das Zusammenwirken der verschiedenen Hardware- und Software-Komponenten ermöglichen. Im Gegensatz zur maschinen-orientierten Systemsoftware ist die Anwendungssoftware am konkreten Bedarf des Anwenders orientiert und versucht, die speziellen Erfordernisse des Anwenders zu erfüllen. Aufgrund der betriebswirtschaftlichen Orientierung dieser Dissertation wird die technische Perspektive nicht weiter verfolgt.

Aus betriebswirtschaftlich-marktorientierter Perspektive wird Software zumeist nach dem Standardisierungsgrad gegliedert. In der Regel wird zwischen Standard- und Individualsoftware unterschieden, wobei Standard-Software auf Allgemein-gültigkeit und mehrfache Nutzung hin ausgelegt ist, während Individualsoftware für einen Anwendungsfall massgeschneidert erzeugt wird.13 Häufig wird das Segment der Standard-Software nochmals nach dem Grad der Anpassungsfähigkeit in fixe und variable Standard-Software unterteilt.14 Dabei ist fixe Standard-Software da-durch charakterisiert, dass sie vom Anwender nicht verändert bzw. kaum an seine individuellen Bedürfnisse angepasst werden kann. Im Gegensatz dazu steht die va-riable Standard-Software, die zwar für viele Anwender produziert, aber trotzdem durch das Customizing15 an individuelle Anforderungen angepasst werden kann.16 Mit abnehmendem Standardisierungsgrad lassen sich demnach drei Segmente iden-tifizieren: Fixe Standard-Software, variable Standard-Software und Individualsoft-ware.

Software: Produkt oder Dienstleistung? Insbesondere aus Sicht der Rechnungslegung ist die Frage, ob es sich bei Software um ein (immaterielles17) Produkt oder eine Dienstleistung handelt, von hoher Be-deutung. Dabei lassen sich bei Standard-Software durchaus Produkteigenschaften

13 Vgl. Hansen/Neumann (2001), S. 152. 14 Vgl. Pirker (1997), S. 23-25; Müller (1999), S. 16. MÜLLER spricht dabei von Standard-Software (für

fixe Standard-Software) und Kernproduktsoftware (für variable Standard-Software). 15 HANSEN/NEUMANN definieren Customizing als „Anpassung von Standardprogrammen an anwender-

spezifische Gegebenheiten durch das Einstellen von Parametern nach betriebsspezifischen Vorgaben und Verarbeitungsregeln.“ Hansen/Neumann (2001), S. 526.

16 Vgl. Pirker (1997), S. 23-25. 17 Software wird heutzutage in der Literatur generell Immaterialität zugesprochen. Es sei denn, die Soft-

ware ist integraler Bestandteil der zugehörigen Hardware und wird damit als Sachanlage behandelt. Vgl. zur Diskussion Pirker (1997), S. 42-49.

Page 26: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 8

feststellen: Standard-Software ist lagerfähig und auf Vorrat produzierbar, zudem ist nicht jede Kopie individuell. Die beschriebenen Eigenschaften weisen somit eher auf den Produktcharakter von Software hin. Dies alles gilt jedoch nicht für Indivi-dualsoftware. Es scheint somit eine Beziehung zwischen dem Standardisierungsgrad einer Software und ihrer Typologie zu bestehen. Während Individualsoftware über-wiegend Dienstleistungscharakter hat, weist Standard-Software eher Produkteigen-schaften auf.18 Innerhalb der Standard-Software zeichnet sich die fixe Standard-Software fast ausschliesslich durch Produkteigenschaften aus, während variable Standard-Software zusätzlich zu den Produkt- auch noch einige Dienstleistungs-eigenschaften aufweist. Die folgende Abbildung soll diesen Sachverhalt verdeut-lichen:

Fix Variabel

Individualsoftware

Konsumgut Investitionsgut Dienstleistung

Standardsoftware

Abbildung 2: Software-Typologie19

Fixe und variable Standard-Software weisen vor allem Produkteigenschaften auf und unterscheiden sich daher in bedeutendem Masse von Individualsoftware, die Dienstleistungscharakter aufweist.20 Unter (fixer wie variabler) Standard-Software wird Software verstanden, die von Anbietern für eine Vielzahl von Anwendern mit gleichen oder ähnlichen Anforderungen entwickelt wird.21 Im Gegensatz dazu steht die Individualsoftware, welche meist in Projektform, basierend auf einem individu-ellen internen oder externen Auftrag erstellt wird. Diese Unterscheidung von Stan-dard- und Individualsoftware entspricht damit auch weitestgehend der Klassifikati-on der International Data Corporation (IDC), welche Software in die Hauptgruppen

18 Vgl. Müller (1999), S. 15-16. MÜLLER spricht deshalb auch von Produktgeschäft und Projektgeschäft. 19 In Anlehnung an Müller (1999), S. 16. 20 Es soll an dieser Stelle nochmals darauf hingewiesen werden, dass das Verkaufspaket einer Standard-

Software jedoch durchaus auch Dienstleistungen wie Updates, Wartung usw. enthalten kann. Die OECD definiert Individualsoftware als Programme „developed to order for a particular client“. Vgl. OECD (2001), S. 6.

21 Vgl. z. B. Mertens et al. (2001), S. 21.

Page 27: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 9

Packaged Software und Services unterteilt.22 Die IDC-Definition geht somit auch implizit von der Vorstellung aus, dass Software sowohl als Produkt als auch als Dienstleistung vorliegen kann.

Somit soll die in der Literatur landläufige Unterscheidung von Standard- und Indi-vidualsoftware auch an dieser Stelle vorgenommen werden und für diese Dissertati-on gelten.

3.2. Definition Standard-Softwareunternehmen

(Standard-)Softwareunternehmen definieren sich als organisatorische Einheiten, deren Tätigkeit überwiegend auf die Erzeugung und den Absatz von Software aus-gerichtet ist.23 Eine Abgrenzung zu Unternehmen, die Software nur in vernachläs-sigbarem Masse herstellen oder Software nur vertreiben (wie z. B. Hardware-Hersteller) ist jedoch meist schwierig. Um eine Fokussierung auf diese Unterneh-men zu ermöglichen, „deren Unternehmenserfolg aus ihrer Tätigkeit im Software-Markt und nicht in anderen Märkten resultiert“24, sollen nur solche Unternehmen betrachtet werden, deren Umsatz zumindest zu zwei Dritteln aus der Erstellung und Vermarktung von Software stammen.

Die Abgrenzung der Standard-Softwareunternehmen von anderen Softwareunter-nehmenstypen gelingt am besten über die Art ihrer entwickelten und vertriebenen Softwareprodukte. So führte die im vorherigen Unterkapitel vorgestellte Differen-zierung von Software aus betriebswirtschaftlich-marktorientierter Perspektive zu einer Unterscheidung von fixer und variabler Standard-Software sowie Individual-software. Entsprechend dieser Abgrenzungslinie werden von den meisten Autoren auch die am Markt teilnehmenden Unternehmen eingeordnet.25 Entsprechend sollen in dieser Dissertation Standard-Softwareunternehmen als Unternehmen definiert werden, welche mehr als fünfzig Prozent ihres Umsatzes mit der Erstellung und dem Verkauf von fixer und/oder variabler Standard-Software erzielen.

22 Vgl. OECD (1998), S. 13. 23 Vgl. Neugebauer (1986), S. 14. 24 Neugebauer (1986), S. 15. 25 Vgl. Baaken/Launen (1993), S. 9; Müller (1990), S. 123 und S. 141; Neugebauer (1986), S. 250f.

Page 28: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 10

3.3. Definition Externe Analyse

(Externe) Investoren, die ihr Investmentportfolio aktiv bewirtschaften, stützen sich grundsätzlich auf eine Form von Aktienanalyse (equity security analysis), um un-terbewertete Werte zu identifizieren.26 Die Aktienanalyse lässt sich grundsätzlich in zwei Typen unterteilen: Die technische Analyse und die Fundamentalanalyse.27 Die technische Analyse fokussiert auf Finanzmarktdaten wie zum Beispiel die relative Bewertung von Wertpapieren, welche für eine kurzfristige Prognose zukünftiger Kursentwicklungen verwendet werden können.28 Die grundsätzlich langfristig ori-entierte Fundamentalanalyse untersucht das Geschäftsumfeld eines Unternehmens und insbesondere die Jahresabschlussdaten, um Einblick in seinen Fundamentalwert zu erhalten.29 Der Fokus dieser Dissertation liegt auf der Fundamentanalyse, da die-se den Jahresabschluss, also die Rechnungslegung als primäre Informationsquelle nutzt:30

Aktienanalyse

Technische Analyse

Fundamental- analyse

Primäre Datenquelle: Finanzmarktdaten Jahresabschlussdaten

Fokus der Dissertation

Abbildung 3: Typen von Aktienanalyse-Techniken

Die Fundamentalanalyse hat die Aufgabe, existierende Informationen wie Jahresab-schlussdaten für Prognosen von zukünftigen Erträgen (mit anderen Worten zur Be-wertung des Unternehmens) zu nutzen.31 Dabei wird der Prozess der Fundamental-analyse generell in folgenden vier Schritten durchlaufen:

26 Vgl. Palepu et al. (2004), S. 9-6. 27 Vgl. Spremann (2002), S. 369-381. 28 Vgl. Spremann (2002), S. 374f. 29 Vgl. Brealey/Myers (1996), S. 328; Spremann (2002), S. 372-376. 30 Vgl. Spremann (2002), S. 439. 31 Vgl. Lee (1999), S. 415.

Page 29: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 11

Rechnungs-legungs- analyse

Finanz-analyse

Prospektive Analyse

Geschäfts- analyse

• Entwicklung von Prognosen • Bewertung

• Performance-Messung durch Ratios und Cash Flow-Analyse

• Industrie-Analyse • Wettbewerbsanalyse

• Evaluation der Rechnungslegungs-qualität

Fokus der Dissertation

Abbildung 4: Prozessschritte der Fundamentalanalyse32

Die Geschäftsanalyse stellt den ersten Schritt der Fundamentalanalyse dar. Sie um-fasst typischerweise die Aufgabe, das Industrie- und Wettbewerbsumfeld des be-trachteten Unternehmens zu analysieren und Schlüsseltreiber sowie -risiken im Markt zu identifizieren. Diese Analyse ist wichtig, um die Resultate der Rechnungs-legungsanalyse und der Finanzanalyse besser interpretieren zu können. So ermög-licht beispielsweise die Identifikation der vorhandenen Marktmechanismen ein bes-seres Verständnis für gewisse Rechnungslegungsgrundsätze bzw. für allfällige Rechnungslegungsprobleme.

Das Ziel der Rechnungslegungsanalyse ist zu evaluieren, inwieweit die Rechnungs-legung eines Unternehmens die zugrunde liegende Geschäftsrealität erfasst. Da die primäre Informationsquelle der Fundamentalanalyse Rechnungslegungsdaten sind, kommt deren Genauigkeit besondere Bedeutung zu. Obwohl das erklärte Ziel der finanziellen Berichterstattung die akkurate Präsentation der ökonomischen Situation eines Unternehmens ist, produziert sie nicht unbedingt adäquate Angaben über die Erträge oder das Eigenkapital eines Unternehmens.33 Dies ist durch drei Faktoren bedingt, welche Rechnungslegungsinformationen verzerren können: Rechnungs-legungsstandards, welche eine ungenügende Erfassung der finanziellen Realitäten bewirken; Prognosefehler durch das Management, welche in zahlreiche Positionen der Rechnungslegung einfliessen; bewusste Managemententscheidungen mit dem Ziel, die finanzielle Situation des Unternehmens möglichst positiv darzustellen (so genanntes window dressing).

32 Basierend auf den Prozessschritten von Palepu et al. (2004), S. 1-7f. 33 Vgl. Cohen et al. (1987), S. 339.

Page 30: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 12

Aufgrund des im Bereich der Rechnungslegung liegenden Schwerpunkts des Dis-sertationsprojekts soll auf die Prozessschritte Finanzanalyse und prospektive Analy-se nicht weiter eingegangen werden.

Somit wird im Rahmen dieses Dissertationsprojektes unter externer Analyse die Untersuchung der Rechnungslegung34 von Standard-Softwareunternehmen aus der Sichtweise eines idealtypischen externen (Eigenkapital-)Investors verstanden. Die externe Analyse dient dazu, dem Investor im Rahmen der Fundamentalanalyse ent-scheidungsnützliche Informationen zu liefern und bildet damit die Grundlage zur Bewertung eines Unternehmens.

4. Forschungsmethodik

Die Forschungsmethodik dieser Dissertation basiert auf dem Konzept der anwen-dungsorientierten Wissenschaften. Somit beginnt der Forschungsprozess mit der Untersuchung von Problemen in der Praxis und versucht entsprechend praxisnahe Lösungen zu entwickeln.35 Dabei steht „als Beurteilungsmassstab die unmittelbare Brauchbarkeit (Praxisrelevanz) der Ergebnisse für die aktuell von ihnen [Praktikern] zu lösenden Probleme im Vordergrund.“36 Um diese postulierte Praxisrelevanz si-cherzustellen, basiert die Dissertation sowohl auf theoretischen als auch auf empiri-schen Erkenntnissen. Die theoretische Untersuchung umfasst das Studium der wis-senschaftlichen Literatur und der Dokumentation der Rechnungslegungswerke, während sich der empirische Teil aus der Analyse von Geschäftsberichten und Ex-perteninterviews zusammensetzt:

• Wissenschaftliche Literatur und Rechnungslegungswerke: Das theoretische Fun-dament dieser Dissertation basiert auf der wissenschaftlichen Literatur und der Dokumentation von Standardsettern. Die akademische Literatur umfasst Bücher, wissenschaftliche Artikel, Arbeitspapiere und andere relevante Publikationen, verfasst von Akademikern oder Praktikern. Die von den Standardsettern publi-zierte Dokumentation umfasst primär die jeweiligen Rechnungslegungsstandards,

34 An dieser Stelle soll angemerkt werden, dass die externe Analyse neben Rechnungslegungsinformatio-nen grundsätzlich auch weitere Informationen umfassen kann.

35 Vgl. Ulrich (1984), S. 192. 36 Kromrey (1998), S. 20.

Page 31: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL I: EINLEITUNG 13

Interpretationen dieser Standards, Diskussionspapiere, Entwürfe von Standards und die öffentlichen Kommentare dazu.

• Empirische Analyse von Geschäftsberichten: Um die praktische Relevanz sicher-zustellen, werden die theoretischen Erkenntnisse, insbesondere im Teil IV: Ana-lyse der Rechnungslegung von Standard-Softwareunternehmen, mit Beispielen aus Geschäftsberichten illustriert, beziehungsweise wo zutreffend, der Berichter-stattungspraxis gegenübergestellt. Die Beispielunternehmen wurden nach dem Konzept der bewussten Auswahl ermittelt. Es handelt sich dabei um eine gezielte Auswahl nach „Kriterien, die im Zusammenhang des Forschungsprojektes als sinnvoll erscheinen.“37 Im Rahmen dieses Dissertationsprojekts basiert die Selek-tion auf folgenden Auswahlkriterien: Listung des Unternehmens am NASDAQ-100 (Dezember 2005), an der Deutschen Börse und/oder an der SWX bzw. das Vorhandensein von für die entsprechenden Themenbereiche bedeutenden Beson-derheiten. Anhang I umfasst eine Liste der ausgewählten Unternehmen.

• Experteninterviews: Erklärtes Ziel dieser Interviews war es, die Ansichten von Praktikern zu den verschiedenen Forschungsfragen einzubeziehen und damit die Praxisrelevanz des Dissertationsprojektes weiter zu erhöhen. Die Selektion der Interviewpartner erfolgte wiederum nach dem Konzept der bewussten Auswahl. Schlüsselkriterium bei der Wahl der Interviewpartner war es, alle Gruppen zu er-fassen, welche sich mit der Rechnungslegung von Standard-Softwareunter-nehmen beschäftigen oder sich dafür interessieren. Entsprechend umfasste die Auswahl Analysten, Standard-Softwareunternehmen und Wirtschaftsprüfer. Vor der Befragung erhielten die Interviewpartner einen Fragebogen mit einer Auflis-tung der wichtigsten Diskussionspunkte. Die eigentlichen Interviews erfolgten dabei in Form eines Leitfadengesprächs, welches auf einem teil-standardisierten Fragebogen basierte: „Diese Form der Befragung erlaubt es, zu bestimmten Themen genauer nachzufragen, Sachverhalte intensiver oder mehr in der Tiefe gehend zu erfassen.“38 Die Gesprächsleitfaden für Analysten und für Erstel-ler/Wirtschaftsprüfer sind in Anhang II wiedergegeben.

37 Stier (1996), S. 120. 38 Kromrey (1998), S. 364.

Page 32: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 14

Teil II: Charakteristika von Standard-Software-unternehmen

In diesem Kapitel soll zuerst die Struktur der (Standard-)Softwareindustrie aufge-zeigt werden. Danach sollen ausgehend von der Marktbeobachtung von GALLAUGHER/WANG39 die Charakteristika von Standard-Softwareunternehmen her-ausgearbeitet werden. Dazu werden in einem ersten Schritt die grundlegenden Me-chanismen und Gesetzmässigkeiten in der Standard-Softwareindustrie identifiziert. In einem zweiten Schritt werden die daraus resultierenden Charakteristika der Stan-dard-Softwareunternehmen abgeleitet und erläutert.

Die Erkenntnisse dieses Kapitels bilden die Basis für die im weiteren Fortgang der Untersuchung zu beantwortende Frage, welche Informationen für einen Investor gerade bei Standard-Softwareunternehmen von besonderer Bedeutung sind.

1. Struktur der (Standard-)Softwareindustrie

Die definitorisch40 festgelegte Unterscheidung von Software nach betriebswirt-schaftlich-marktorientierter Perspektive führte zur Abgrenzung von fixer und vari-abler Standard-Software sowie Individualsoftware. Entsprechend dieser Abgren-zungslinie stellt sich auch die Struktur der (externen) Softwareindustrie dar. So kann die Gruppe der Softwareunternehmen bezüglich der von ihnen angebotenen Software weiter untergliedert werden in Standard-Softwareunternehmen, die fixe und/oder variable Standard-Software erstellen und Software-Dienstleistungsunter-nehmen, die Individualsoftware entwickeln. Die folgende Abbildung veran-schaulicht die Struktur der (externen) Softwareindustrie grafisch und nennt Bei-spielunternehmen für die einzelnen Bereiche:

39 Vgl. Gallaugher/Wang (2002), S. 304. 40 Vgl. Abschnitt I 3.1.

Page 33: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 15

Microsoft Adobe Novell

IBM Oracle Computer Associates SAP

Accenture EDS CSC

(Externe) Softwareindustrie

Standard-Software- unternehmen

Fixe Standard-software

Variable Standard-software

Software-Dienstleistungs-unternehmen

Fokus der Dissertation

Individual-software

Produkt-gattung

Unternehm

ens-gattung

Beispiel-unternehm

en

Abbildung 5: Struktur der (Standard-)Softwareindustrie

Aufgrund der Verschiedenartigkeit von Standard- und Individualsoftware unter-scheiden sich auch die Unternehmenstypen stark voneinander. Während sowohl fixe als auch variable Standard-Software eher Produkteigenschaften aufweisen und so-mit Standard-Softwareunternehmen ein Produktgeschäft betreiben, so entspricht dem Individual-Softwareunternehmen das Projektgeschäft. Die folgende Abbildung zeigt die Unterschiede zwischen den beiden Segmenten:

Segment Ausprägung

fixes und variables Standardsoftwaregeschäft Individualsoftwaregeschäft

Geschäftstyp Produktgeschäft Projektgeschäft

Installationshäufigkeit sehr viele Installationen Wenige Installationen

Produkt-Individualität niedrig hoch

Produkt-Typologie Konsum-/Investitionsgut Dienstleistung

Fixkosten hoch niedrig

Kapitalintensität hoch niedrig

Unternehmensrisiko hoch niedrig

Zielmarkt fast immer global auch regional möglich

Infrastruktur eigene die des Kunden

Prozessreihenfolge Produktion vor Verkauf Verkauf vor Produktion

Treibendes Element Marketing Engineering

Abbildung 6: Unterschiede zwischen Standard- und Individualsoftwaregeschäft41

41 In Anlehnung an Müller (1999), S. 31.

Page 34: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 16

Die grossen Unterschiede zwischen den beiden Branchensegmenten Produktge-schäft und Projektgeschäft erfordern eine getrennte Analyse der Standard-Softwareindustrie und der Individual-Softwareindustrie. Wie in Abschnitt I 1 dieser Dissertation bereits erläutert, soll im Folgenden aufgrund der grösseren Bedeutung und der schwierigeren Marktbedingungen auf die Standard-Softwareindustrie fo-kussiert werden.

2. Marktmechanismen in der Standard-Softwareindustrie

Bei einer vertieften Betrachtung der Standard-Softwareindustrie fällt auf, dass sich die Marktmechanismen in grossen Teilen von denen in anderen Industrien unter-scheiden. Insbesondere das immaterielle Gut Standard-Software weist Eigenschaf-ten auf, welche die Funktionsweise des Standard-Softwaremarkts stark beeinflus-sen. Diese Mechanismen lassen sich unter den Stichworten einfache Skalierbarkeit, Netzwerkeffekte, diskontinuierliche technische Innovation und Wachstum zusam-menfassen.42

2.1. Einfache Skalierbarkeit

Die einfache Skalierbarkeit ist eine typische Eigenschaft von immateriellen Werten wie Standard-Software. Sie bedeutet, dass das Angebot praktisch ohne Restriktion an die vorhandene Nachfrage anpassbar ist, das heisst mit anderen Worten, dass eine vorhandene Software quasi ohne finanzielle oder zeitliche Restriktion beliebig vervielfältigt werden kann.43 Die einfache Skalierbarkeit von Standard-Software ergibt sich dabei aus der Nicht-Rivalität und der Kostenstruktur.44

Die Nicht-Rivalität zeigt sich darin, dass dieselbe Standard-Software grundsätzlich zeitgleich mehrfacher Nutzung offen steht. Ein einmal geschriebenes Standard-Softwareprogramm kann potenziell von einer unlimitierten Anzahl Nutzer zur glei-chen Zeit verwendet werden. Es ist keine Mengen- und Zeitrestriktion vorhanden –

42 Vgl. Lev (2001), S. 9-49. 43 Vgl. Liebowitz (2002), S.17. 44 Vgl. Lev (2001), S. 25.

Page 35: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 17

abgesehen von der Vervielfältigung der Software.45 Die Nicht-Rivalität von Soft-ware führt daher dazu, dass die Skalierbarkeit von Standard-Software prinzipiell nur durch die Nachfrage limitiert ist.

Die Kostenstruktur von Standard-Software zeichnet sich durch hohe Fixkosten in Form von Entwicklungs- und Marketingkosten und vernachlässigbaren Grenz-kosten46 für die Erstellung der einzelnen Produkte aus. Die Entwicklung eines Stan-dard-Softwareprogramms verlangt hohe Anfangsinvestitionen, während die Produk-tions- und Vertriebskosten der einzelnen Softwarepakete insbesondere im Falle ei-ner rein elektronischen Verteilung über das Internet vernachlässigbar sind. Die Kos-tenstruktur erhöht somit die durch die Nicht-Rivalität gegebene einfache Skalier-barkeit von Standard-Software.

Die einfache Skalierbarkeit von Standard-Software führt dazu, dass nach der Über-windung der Initialphase mit hohen Fixkosten eine vollständige Marktdurchdrin-gung grundsätzlich äusserst schnell und mit geringem Aufwand möglich ist.

2.2. Netzwerkeffekte und Standards

Der Markt für Standard-Software zeichnet sich insbesondere durch das Vorhanden-sein starker Netzwerkeffekte47 aus. Bei Netzwerkeffekten handelt es sich nach der neoklassischen Theorie48 um eine spezielle Form positiver externer Effekte (positi-ve feedback). Externe Effekte bezeichnen generell Nebenwirkungen individuellen Handelns, die nicht über den Markt abgegolten werden. Netzwerkeffekte beschrei-ben die positiven Auswirkungen der Teilnahme einer Person an einem Netzwerk auf die übrigen Teilnehmer dieses Netzwerks.49 In der Literatur wird meist zwischen direkten und indirekten Netzwerkeffekten unterschieden, welche beide im Standard-Softwaremarkt zu finden sind:50

45 Genauer muss von einer Vervielfältigung von kompilierten, also maschinenlesbaren Versionen des Quellcodes gesprochen werden.

46 Vgl. Liebowitz (2002), S. 15. 47 In der Literatur werden auch die Begriffe Netzwerkexternalitäten (network externalities) oder Netzef-

fekte verwendet. 48 Vgl. Schumann (1992), S. 40. 49 Vgl. Hess (2000), S. 96. 50 Vgl. Katz/Shapiro (1985), S. 424; Zerdick et al. (1999), S. 155-158.

Page 36: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 18

Von direkten Netzwerkeffekten wird gesprochen, wenn Kompatibilität zwischen Elementen oder Akteuren realisiert wird. So steigt etwa für den Anwender einer Standard-Software der Nutzen mit der Anzahl der Anwender, die ebenfalls eine sol-che Software einsetzen. Der Nutzen des Netzwerkeffekts ergibt sich für den An-wender dabei zum Beispiel aus der Möglichkeit, Dateien mit anderen Anwendern austauschen zu können.

Indirekte Netzwerkeffekte entstehen bei einer positiven Abhängigkeit zwischen der Verbreitung einer Technologie oder eines Standards und dem dazugehörigen Ange-bot an Komplementärgütern. Sie sind charakteristisch für Systemprodukte, welche sich durch zwei Phasen der Beschaffung auszeichnen. In einer ersten Phase wird das Basissystem beschafft. Dieses Basissystem wird in einer zweiten Phase durch An-wendungskomponenten ergänzt, welche in der Regel erst den unmittelbaren An-wendernutzen schaffen. Der Nutzen ist für den Anwender umso grösser, je mehr Nutzer dieselben Anwendungskomponenten verwenden. Da die Anwendungs-komponenten kompatibel mit dem Basissystem sein müssen, ist der Entscheidungs-spielraum in der zweiten Phase jedoch stark eingeschränkt.51 Klassisches Beispiel eines solchen indirekten Netzwerkeffekts ist das Betriebssystem-Anwendungssoft-ware Paradigma52: Ein Nutzer, welcher sich auf ein Betriebssystem festlegt, wird bei seiner Entscheidung berücksichtigen, wie viele andere Nutzer womöglich auch dieses Betriebssystem erwerben. Denn die Anzahl und die Vielfalt der auf diesem Betriebssystem verfügbaren Anwendungssoftware ist eine steigende Funktion für die Anzahl Betriebssysteme, die verkauft werden.53 Die Verbreitung eines Betriebs-systems ist daher ein wichtiger Bestimmungsfaktor des Angebots der zu dieser Sys-temsoftware kompatiblen Anwendungssoftware.

Mit dem Netzwerkeffekt eng verbunden ist das Phänomen des lock-in: Wenn ein Nutzer beim Wechsel von einem Gut auf ein anderes, signifikante Umstellungs-kosten (switching costs) zu gewärtigen hat, so bleibt er auf dem alten Gut „gefan-gen“; er ist locked-in. Insbesondere im Standard-Softwaremarkt führen die Netz-werkeffekte dazu, dass solche lock-in Effekte beim Wechsel einer Standard-

51 Vgl. Buxmann (2002), S. 443. 52 Katz/Shapiro (1985) sprechen vom Hardware-Software Paradigma. 53 Vgl. Katz/Shapiro (1985), S. 424.

Page 37: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 19

Software auftreten. So ist häufig der Austausch von Daten zwischen den Produkten verschiedener Anbieter erschwert. Hinzu kommen Lerneffekte der Benutzer und notwendige Anpassungen der neuen Software an die Geschäftsprozesse, welche bei einem Produktwechsel zu hohen Umstellungskosten führen.

Die Etablierung von Standards ist ein Versuch, diesen lock-in Effekten entgegen zu treten. So wurden zum Beispiel Schnittstellen für Programme oder Formate zum Datenaustausch definiert. Denn bei fehlenden Standards riskieren die Kunden ein proprietäres System zu erwerben, welches sich im Markt als unterlegen herausstellt. Netzwerkeffekte führen dann schnell dazu, dass das unterlegene System fast voll-ständig vom Markt verschwindet. Dieser Marktmechanismus verleitet die Kunden dazu abzuwarten, bis sich abzeichnet, welches System sich durchsetzen wird. Um eine schnelle Adaption neuer Technologien durch die Kunden zu erreichen, soll die Etablierung von Standards diese Unsicherheiten eliminieren, indem alle Systeme industrieweit definierte Eigenschaften erfüllen und somit zueinander kompatibel gestaltet sind. In der Praxis stellt sich jedoch die Situation meist so dar, dass erfolg-reiche Anbieter versuchen, die Standards „weiterzuentwickeln“, so dass faktisch wieder ein proprietäres System mit lock-in Effekt entsteht. Durch diese Strategie kann das Unternehmen seine Marktposition gegenüber der Konkurrenz absichern.

Fallstudie 1

Im so genannten Browserkrieg der Unternehmen Microsoft und Netscape haben beide Wettbewerber schon früh versucht, Funktionen in ihre Internetbrowser Inter-net Explorer bzw. Netscape Navigator einzufügen, welche nicht dem HTML-Standard entsprachen wie er vom Standardisierungskomitee W3C verabschiedet wurde. Diese „erweiterten“ Funktionalitäten sollten den Webprogrammierern erlau-ben, neuartige Effekte in ihre Webseiten zu integrieren. Durch die Adaption dieser nicht standardisierten Funktionen durch Programmierer und Nutzer sollte die Att-raktivität des Browser-Produkts gesteigert und gleichzeitig ein lock-in der An-wender stattfinden. So hat zum Beispiel Microsoft mit dem ActiveX-Modell eine Technologie in ihrem Internet Explorer eingeführt, welche es erlaubt, Programmco-de auf Webseiten auszuführen. Dies ermöglicht eine enge Interaktion von Micro-softs Betriebssystem Windows über den Browser Internet Explorer mit Webseiten. So unterstützt die ActiveX-Technologie zum Beispiel das internetbasierte Scannen

Page 38: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 20

von Computern nach Viren oder nach fehlenden Updates. Diese Technologie funk-tioniert jedoch nur in Kombination mit den Microsoftprodukten Internet Explorer und dem Betriebssystem Windows.

Fallstudie 1: Browserkrieg I

Die bisher vorgestellten Marktmechanismen sind dafür verantwortlich, dass die Standard-Softwareindustrie die Eigenschaften eines so genannten winner-take-all (bzw. winner-take-most) Marktes aufweist. Die starken Netzwerkeffekte führen da-zu, dass der Marktführer monopolartige Marktanteile erreichen kann. Durch die schnelle und einfache Verbreitung von Software kann sich dieser Prozess zudem enorm schnell entfalten – denn grundsätzlich sind für die Verbreitung von Standard-Software keine geografischen oder finanziellen Hürden vorhanden.

Dieser fundamentalen Bedeutung von Netzwerkeffekten und einfacher Skalierbar-keit in der Standard-Softwareindustrie sind sich die Marktteilnehmer sehr wohl be-wusst und versuchen diese in ihren Vertriebsstrategien zu nutzen wie in Abschnitt II 3.1.2 illustriert wird.

2.3. Diskontinuierliche, technologische Innovationen

Diskontinuierliche, technologische Innovationen sind bis heute ein typisches, immer wiederkehrendes Phänomen der Standard-Softwareindustrie. Diskontinuierliche, technologische Innovation bedeutet, dass neue technologische Entwicklungen derart revolutionär sind, dass sie bestehende Marktmechanismen zumindest kurzfristig aufzuheben vermögen und dadurch zu neuen Wettbewerbssituationen führen. In der Standard-Softwareindustrie führt die hohe technologische Innovationsrate immer wieder dazu, dass disruptive Entwicklungen auftreten, welche die bestehenden Netzwerkeffekte zumindest kurzfristig ausser Kraft setzen und damit eine neue Ausgangslage schaffen:

• Unterbrechung positiver Feedback-Mechanismen (direkte Netzwerkeffekte)

• Störung von Komplementär-Effekten (indirekte Netzwerkeffekte)

• Störung von lock-in Effekten (direkte wie indirekte Netzwerkeffekte)

In der relativ kurzen Geschichte der (Standard-)Softwareindustrie werden bisher mindestens drei grosse Innovationen anerkannt, die ein solches Diskontinuum dar-

Page 39: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 21

stellten: Das Aufkommen der grafischen Benutzeroberfläche, die Entwicklung der Client-Server Architektur und die letzte, die Erfindung des World Wide Web (WWW). Sie alle führten dazu, dass ehemals wichtige Marktteilnehmer vom Markt verschwanden bzw. in arge Bedrängnis gerieten.

Fallstudie 2 Im Jahre 1995 verfügte das Standard-Softwareunternehmen Microsoft über ein ein-maliges Geschäftsportfolio und war unter anderem unangefochtener Marktführer in den grössten Standard-Softwaremärkten wie Betriebssystemen (mit Windows) und Büroapplikationen (mit Office Suite).54 Microsoft hatte damit in den wichtigsten Märkten längst die kritische Grösse erreicht, um von den direkten, aber auch indi-rekten Netzwerkeffekten in der Standard-Softwareindustrie optimal profitieren zu können. Ein Abwandern der Kunden zu Konkurrenten war durch den lock-in Effekt stark erschwert. Entsprechend änderte das Unternehmen seinen Fokus weg vom Neukundengeschäft und hin zu einer verstärkten Umsatzgenerierung bei der beste-henden Kundenbasis durch die Verbreiterung der Kundeninteraktionen mit neuen Produkten und vermehrten Serviceverträgen.55 In diese Konsolidierungsphase hin-ein platzte die rasante Entwicklung des WWW, welche Microsoft zu Beginn weit-gehend ignorierte. So schaffte es Microsoft erst in buchstäblich letzter Minute einen rudimentären Internet Browser in sein neues Betriebssystem Windows 95 zu integ-rieren, welches im August 1995 auf den Markt kam.56 Der Netscape Navigator von der Firma Netscape war zu diesem Zeitpunkt der de-facto Standard für den Zugang zum WWW. Microsoft erkannte erst spät, dass das Internet ein wichtiges Geschäfts-feld würde und dass es sogar das bestehende Geschäftsmodell von Microsoft bedro-hen konnte. Das Internet ist faktisch nichts anderes als eine neue Softwareplattform, welche das Potenzial besitzt, die bestehenden, computerbasierten Betriebssystem-Plattformen zu marginalisieren. Übersteigt die Beliebtheit des Internets diejenige des Betriebssystems, so ist für den Nutzer der Zugang zur Plattform des Internets entscheidend – welches Betriebssystem er dabei benutzt ist für ihn sekundär. Somit ist es entscheidend, wer den Zugang zum Internet kontrolliert, da derjenige Stan-

54 Vgl. Ghemawat et al. (1999), S. 7-8ff. 55 Vgl. Ghemawat et al. (1999), S. 7-11ff. 56 Vgl. Bank (2001), S. 59.

Page 40: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 22

dards setzen und diese kontrollieren kann.57 Diese Erkenntnis brachte Microsoft dazu, alles daran zu setzen, um Netscape als Zugangssoftware zum Internet zu ver-drängen. Noch im Jahre 1997 hielt der Netscape Browser einen Marktanteil von 72% gegenüber 18% von Internet Explorer. Nach geschätzten milliardenschweren Investitionen von Microsoft erreichte der Internet Explorer im Jahre 2001 einen Marktanteil von rund 96%, was es dem Unternehmen wieder ermöglichte, die Kon-trolle über die weitere Entwicklung des Internetzuganges zu übernehmen.

Fallstudie 2: Browserkrieg II

Das Zusammenspiel von einfacher Skalierbarkeit, Netzwerkeffekten und diskonti-nuierlichen, technologischen Innovationen führen zu einem so genannten temporä-ren winner-take-all (bzw. winner-take-most) Markt in der Standard-Softwarein-dustrie.58 Dies bedeutet, dass das marktführende Unternehmen während eines Inno-vationszyklus aufgrund der vorhandenen Netzwerkeffekte und der einfachen Ska-lierbarkeit von Standard-Software innert kürzester Zeit monopolähnliche Marktan-teile erreichen kann. Diese Konstellation besteht jedoch nur temporär, da sie immer wieder durch umwälzende Innovationen durchbrochen wird, welche die Marktme-chanismen kurzfristig stören und dadurch eine neue Wettbewerbssituation schaffen.

2.4. Bedeutung von Wachstum

Die (Standard-)Softwarebranche ist trotz der Krisenjahre 2001/2002 eine ausge-sprochene Wachstumsindustrie und profitiert von der ständig steigenden Bedeutung von Software in den globalen Wertschöpfungsprozessen, wie die folgende Abbil-dung zeigt:

57 Vgl. Bank (2001), S. 60. 58 Vgl. Liebowitz (2002), S. 16; Di Maria/Köttl (2002), S. 1.; Evans et al. (2002), S. 43.

Page 41: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 23

Wachstum der weltweiten Softwareindustrie

-2%

0%

2%

4%

6%

8%

10%

12%

1999 2000 2001 2002 2003* 2004* 2005* 2006* 2007*Jahr

* = Hochrechnung

Abbildung 7: Jährliches Wachstum der Softwareindustrie59

Das im Vergleich zu anderen industriellen Branchen stetig starke Wachstum reflek-tiert sich jedoch höchst unterschiedlich in der Entwicklung der einzelnen Akteure, was auf die speziellen Marktbedingungen zurückzuführen ist. So weisen junge Un-ternehmen, welche aufgrund von technologischen Innovationen neue Marktfelder besetzen können zumeist ein hohes Wachstumstempo auf. Mit Reifung des Marktes verstärkt sich die positive Rückkoppelung durch Netzwerkeffekte, was zu einer Monopolisierung führt und dem etablierten Marktführer (leader) weiteres starkes Wachstum ermöglicht, während die Konkurrenten (follower) stetig Marktanteile verlieren und meist ein Nischendasein führen. Im Unterschied zu anderen Industrien weisen daher in der Standard-Softwarebranche nicht nur Jungunternehmen, sondern auch etablierte Marktführer hohe Wachstumsraten auf. Entsprechend ist Wachstum ein immanentes Charakteristikum bei Standard-Softwareunternehmen und kaum abhängig vom unternehmensspezifischen Lebenszyklus. Empirische Analysen zum Beispiel des Standard-Softwareunternehmens Microsoft60 zeigen, dass auch Stan-dard-Softwareunternehmen, die sich nach klassischer Lebenszyklus-Definition be-reits in der Stagnationsphase befinden, zumeist immer noch stark wachsen.

59 Quelle: SIIA (2005), S. 1. 60 Vgl. Cusumano (1996).

Page 42: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 24

2.5. Exkurs: Open Source Software61

Bei Open Source Software handelt es sich um Software, bei welcher der Quellcode der Software frei eingesehen und beliebig verändert werden darf. Die Verbreitung ist nicht beschränkt und die Software darf lizenzkostenfrei vervielfältigt werden. Software, die auf Open Source Software beruht, muss jedoch meist wiederum als Open Source Software vertrieben werden.62 Aufgrund des grossen Erfolges von Open Source Software wie der Webserversoftware Apache63 oder auch des Be-triebssystems Linux wird intensiv diskutiert, welche Auswirkungen diese Art von Software auf die Standard-Softwareindustrie hat bzw. haben wird.64 Vieles deutet dabei daraufhin, dass Open Source Software nicht eine Veränderung, sondern viel mehr eine noch konsequentere Nutzung der Marktmechanismen in der Standard-Softwareindustrie herbeiführt. Da beim Erwerb von Open Source Software ein An-wender weder unmittelbare finanzielle noch distributive Hürden zu gewärtigen hat, verfügt Open Source Software in der Eroberung von neuen Märkten über einen starken Wettbewerbsvorteil und kann daher schneller von Netzwerkeffekten profi-tieren als ihre klassische, lizenzkostenbasierte Konkurrenz. Hinzu kommen Vorzüge bei der Wartung. Da der Quellcode offen einsehbar ist, sind Änderungen und Fehlerbehebungen durch den Anwender selbst problemlos und schnell möglich. Damit ist eine gewisse Unabhängigkeit gegenüber dem Softwarehersteller gewähr-leistet. Open Source Software weist aber auch Nachteile gegenüber der klassischen Lizenzsoftware auf. So reicht es meist nicht aus, ein Standard-Softwareprodukt als Open Source Software zu veröffentlichen. Es ist notwendig, dass sich eine Kern-gruppe findet, welche die Entwicklung koordiniert und Aufgaben verteilt.65

61 Zum Teil wird im Deutschen auch der Ausdruck „freie Software“ verwendet. Da diese Bezeichnung aber auch kostenlose, aber nicht quelloffene Software umfassen kann, wird aus begrifflichen Gründen im Weiteren der englische Begriff Open Source Software verwendet.

62 Die Verwendungsrechte sind durch entsprechende Lizenzen gesichert, welche jedoch dem Nutzer durchaus unterschiedliche Rechte einräumen. Die bekannteste Open Source-Lizenz ist die General Pub-lic License (GPL), welche als wichtigstes Merkmal bestimmt, dass auf der GPL beruhende Software wiederum unter GPL vertrieben werden muss. Vgl. Hars (2002), S. 543 zu den unterschiedlichen Vari-anten von Open Source Software Lizenzierungsmodellen.

63 Nach Netcraft beträgt der Markanteil von Apache am weltweiten Webserversoftwaremarkt im März 2005 rund 69%. Vgl. o.V. (2005a).

64 Vgl. z. B. Wayner (2000); Raymond (1999). 65 Vgl. Hars (2002), S. 544.

Page 43: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 25

Daneben kämpft Open Source Software mit den Nachteilen einer schlechten Plan-barkeit und einer generellen Unsicherheit bezüglich zukünftiger Weiterentwicklun-gen.

Während Open Source Software also nicht die eigentlichen Marktmechanismen der Standard-Softwareindustrie verändert, so zeichnen sich Standard-Softwareunter-nehmen, welche Open Source Software in ihre Wertschöpfungskette einbauen doch durch neuartige Geschäftsmodelle66 aus. Dabei unterscheiden sich die neuen Ge-schäftsmodelle von den klassischen, lizenzkostenbasierten Typen vor allem in zwei Bereichen: Der Softwareentwicklung und der Umsatzrealisierung. Open Source Software wird im Gegensatz zu klassischer Software häufig nicht mehr isoliert im Unternehmen, sondern in einer offenen Entwicklungsgemeinschaft entwickelt. Die-ser Bereich soll in Abschnitt II 3.1.1 genauer beleuchtet werden. Bei der Umsatzrea-lisierung löst sich Open Source Software vom klassischen Ertragsmodell der Li-zenzkosten und versucht mit alternativen Ertragsmodellen die fehlenden Lizenzkos-ten zu ersetzen. Dieser Aspekt wird ausführlich in Abschnitt II 3.3.3 untersucht.

2.6. Fazit

Bei einer statischen Wettbewerbssituation konkurrenziert sich zumeist eine identifi-zierbare Gruppe von Unternehmen hauptsächlich über den Preis. Im Gegensatz dazu zeichnet sich der Standard-Softwaremarkt durch einen dynamischen Wettbewerb aus. Häufige Innovationen von zum Teil neu in den Markt eintretenden Wettbewer-bern führen zu einem sich ständig verändernden Wettbewerbsumfeld. Dies bedingt von etablierten Unternehmen eine ständige Innovationsbereitschaft, um neue Ent-wicklungen nicht zu verpassen. Dies ist auf dem Standard-Softwaremarkt auch ins-besondere deshalb wichtig, weil er in vielen Bereichen einen winner-take-all Cha-rakter annimmt. Ein Wettbewerber, der sich frühzeitig einen Vorsprung auf die Konkurrenz herausarbeiten kann, profitiert dabei stark von Netzwerkeffekten und kann somit leicht seinen Marktvorsprung noch vergrössern. Die leichte Skalierbar-keit von Software ermöglicht zudem das schnelle Ausdehnen der Marktanteile ohne grossen zusätzlichen finanziellen Aufwand.

66 Ein Geschäftsmodell lässt sich folgendermassen definieren: „An architecture for product, service and information flows […] and a description of the sources of revenue.” Vgl. Timmers (2000), S. 32.

Page 44: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 26

Die beschriebenen Marktmechanismen führen dazu, dass sich Standard-Software-unternehmen durch ganz bestimmte Charakteristika auszeichnen:

3. Charakteristika von Standard-Softwareunternehmen

Die im vorherigen Kapitel beschriebenen, speziellen Marktmechanismen des Stan-dard-Softwaremarktes stellen ganz bestimmte Anforderungen an die beteiligten Un-ternehmen. Diese spiegeln sich in einer Reihe typischer Eigenschaften wider, auf die im Folgenden näher eingegangen werden soll.

In diesem Kapitel werden die Grundlagen für die spätere Beantwortung der Frage gelegt, welche Informationen für einen externen Investor gerade bei Standard-Softwareunternehmen von besonderer Bedeutung sind. Um eine möglichst vollstän-dige Erfassung aller relevanten Dimensionen zu erreichen, sollen insbesondere auch solche Aspekte mit berücksichtigt werden, die in der gegenwärtigen Finanzbericht-erstattung nicht oder nur unzureichend abgebildet werden. Die einzelnen Elemente sind jedoch nicht als zwingend erforderliche Eigenschaften eines Standard-Softwareunternehmens anzusehen. Vielmehr ist der Gesamteindruck entscheidend, der sich aus einer Kombination der dargelegten Einzelaspekte ergibt. Damit wird bewusst auf das Untersuchungskonzept von MÜLLER verzichtet, welcher die Cha-rakteristika und die daraus resultierenden Strategien von Standard-Software-unternehmen nach dem Unternehmenslebenszykluskonzept zu analysieren sucht.67 Das Lebenszykluskonzept ist immer wieder mit genereller Kritik konfrontiert, wie einer zu starken Verallgemeinerungstendenz, welche den Einfluss von Industriespe-zifika, Technologiespezifika und anderen situativen Variablen aus dem Kontext des Unternehmens vernachlässige.68 Gerade die Standard-Softwareindustrie zeichnet sich zum Beispiel durch das Industriespezifikum der Netzwerkeffekte aus, welches dazu führt, dass selbst im Markt etablierte Unternehmen ein mit jungen Unterneh-men vergleichbares Wachstum aufweisen können.69 Eine Anwendung des Lebens-zykluskonzepts ist daher für Standard-Softwareunternehmen aufgrund der speziel-len Industriespezifika nicht sinnvoll. Deshalb wird eine Analyse unterteilt nach ak-

67 Vgl. Müller (1999), S. 185. 68 Vgl. Kazanjian (1988), S. 258. 69 Vgl. Abschnitt II 2.4.

Page 45: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 27

tivitätsbezogenen Einzelaspekten in den Globalbereichen geschäftstätigkeitsbezoge-ne, organisationsbezogene und finanzbezogene Charakteristika vorgenommen:

3.1. Geschäftstätigkeitsbezogene Charakteristika

3.1.1.

Forschung und Entwicklung

Siebzig Prozent der Umsätze in der Computerindustrie (beinhaltet die Softwarein-dustrie) stammen von Produkten, die vor zwei Jahren noch gar nicht existierten, schrieb die Zeitung The Economist 1996.70 Die obige Aussage zeigt eindrucksvoll auf, welch enorm hohe (technologische) Innovationsgeschwindigkeit in der Soft-wareindustrie herrscht. Sie bedingt eine schnelle technische Wandlungs- und An-passungsfähigkeit der im Markt tätigen Unternehmen. Entsprechend kommt den Forschungs- und Entwicklungsaktivitäten der Unternehmen eine hohe Bedeutung zu. Hinzu kommt, dass Softwareanwendungen eine überaus hohe Komplexität auf-weisen und entsprechend intensiver Entwicklungsarbeit bedürfen, während Auf-wendungen für die Produktion, anders als in der klassischen Industrie, im Verhältnis zur Forschung und Entwicklung vernachlässigbar sind. Alle diese Faktoren setzen für Standard-Softwareunternehmen ein Geschäftsmodell voraus, welches den For-schungs- und Entwicklungsaktivitäten höchste Bedeutung beimisst.

Die zentralen Tätigkeiten der Forschung und Entwicklung bei Standard-Software-unternehmen bestehen hauptsächlich aus der Neu- und Weiterentwicklung von Softwareprogrammen. Trotz intensiver Bemühungen im Rahmen der Entwicklung von CASE71-Werkzeugen72 zur (Teil-)Automatisierung der Softwareprogram-mierung bleibt die Entwicklung von Softwareprogrammen noch immer ein sehr humanintensiver Prozess. Dies nicht zuletzt auch deshalb, weil neben der Entwick-lung des eigentlichen Softwareprodukts (der Anwendungsentwicklung) noch weite-re Aufgabenbereiche hinzukommen, die unabdingbare Bestandteile jeder professio-

70 Vgl. Hoch et al. (2000), S. 11. 71 Die Terminologie CASE (computer aided software engineering) umschreibt allgemein Softwarewerk-

zeuge, welche den Prozess der Analyse, des Designs und der Kodierung von Softwaresystemen unter-stützen und automatisieren. Vgl. Aube/Newberry (2005).

72 Nicht zuletzt die andauernden technologischen Innovationen, die frühere Programmiersprachen obsolet werden liessen, waren lange Zeit ein Hindernis für die Entwicklung von Automatisierungslösungen.

Page 46: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 28

nellen Softwareentwicklung darstellen: Produktdokumentation, Beschreibung des Entwicklungsumfelds, Beschreibung des Anwendungsumfelds, Qualitätssicherung, Projektmanagement, Schulung und Produktmanagement.73 HOCH ET AL. nennen Software plakativ, “nichts anderes als Wissen in kodifizierter Form“74 und deuten damit die beinahe untrennbare Symbiose von Softwareentwicklung und Humanka-pital an. Aus diesen Gründen sind für ein Standard-Softwareunternehmen die Orga-nisation der Software-Entwicklungsprozesse und das Management von Humankapi-tal entscheidend. Deshalb werden diese beiden Faktoren im weiteren Verlauf dieses Kapitels vertieft.

Das Aufkommen von Open Source Entwicklungsgemeinschaften hat viele Unter-nehmen dazu gebracht, einen Teil ihrer Forschungs- und Entwicklungsarbeit an sol-che Gemeinschaften auszulagern. Besonders dafür geeignet sind Weiterentwick-lungsprojekte und Softwaretestaufgaben. Die Vorteile für die Unternehmen ergeben sich insbesondere aus einem schnelleren Nutzer-Feedbackzyklus und Kosteneinspa-rungen durch die kostenlose Mitarbeit von unternehmensexternen Entwicklern. Um die Leistungen der Entwicklergemeinschaften in Anspruch nehmen zu können, muss die Software jedoch zumeist mit einer Open Source Lizenz vertrieben und damit kostenlos zur Verfügung gestellt werden.

3.1.2.

Vertrieb

Die besonderen Eigenschaften Netzwerkeffekte und einfache Skalierbarkeit von Standard-Software lassen dem Vertriebsmodell bei Standard-Softwareunternehmen besondere Bedeutung zukommen. Da diese beiden Effekte zu einem winner-take-all Markt führen, ist eine schnelle und hohe Marktdurchdringung erfolgsentscheidend für jeden Marktteilnehmer. So kann der Marktführer meist seine Spezifikationen als Standard durchsetzen, was aufgrund der hohen Interoperabilitätsanforderungen und dem technologischen Vorsprung einen enormen Wettbewerbsvorteil in der Stan-dard-Softwareindustrie bedeutet.75 Es ist für Standard-Softwareunternehmen somit unabdingbar, starke Vertriebsaktivitäten zu entwickeln und innovative Vertriebs-

73 Vgl. Wiesinger (1996), S. 11. 74 Hoch et al. (2000), S. 6. 75 Vgl. Cusumano (1996), S. 69.

Page 47: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 29

modelle einzusetzen. Insbesondere muss aufgrund der diskontinuierlichen Innovati-onen versucht werden, die eigenen Produkte frühzeitig durch Neuentwicklungen abzulösen, um den Innovationsrhythmus bzw. die Innovationsrichtung aktiv mitbe-stimmen zu können.

Mit den Vertriebsaktivitäten einher geht der Aufbau einer starken Marke, um die führende Stellung des Unternehmens zu verdeutlichen. Da die Konsumenten (insbe-sondere Unternehmen) wissen, dass es sich beim Standard-Softwaremarkt um einen winner-take-all Markt handelt, sind sie meist nur bereit in die Lösungen von markt-führenden Anbietern zu investieren. Ihre Markstellung bürgt aufgrund der vorhan-denen Netzwerkeffekte am ehesten für eine zukunftsfähige Lösung.76 Das vorlie-gende Praxisbeispiel von Microsoft stützt die theoretischen Erkenntnisse, dass die Marketingaktivitäten bei Standard-Softwareunternehmen zu den wichtigsten Aus-gabenposten gehören. So gab Microsoft im Jahr 2005 für Verkauf und Marketing beinahe 8.7 Mia. US$ aus bei einem Umsatz von rund 40 Mia. US$. Dies ist mehr als die gesamten F&E-Ausgaben des Jahres 2005 und entspricht rund 22 Prozent des Umsatzes. Damit liegt Microsoft im branchenüblichen Rahmen, der auf dem Niveau von marketingintensiven Industrien liegt.77 Zudem hat die Marke Microsoft einen geschätzten Wert von rund 60 Mia. US$ und ist somit die zweitwertvollste Marke der Welt.78

Während die klassischen Marketinginstrumente durchaus auch ihre Daseinsberech-tigung im Standard-Softwaremarketing haben, so sind sie für die besonderen Anfor-derungen dieser Industrie dennoch nicht ausreichend.79 Insbesondere der zentrale Marktmechanismus Netzwerkeffekt fordert andere Marketing- und Vertriebsmass-nahmen. Viele Standard-Softwareunternehmen versuchen deshalb mit neuartigen Vertriebsmodellen, die Netzwerkeffekte stärker zu nutzen. Dabei zeichnen sich ins-besondere nicht lizenzkostenbasierte Strategien als erfolgreich aus. Die lizenzkos-tenfreie Software hat meist eine „Lockmittel“-Funktion, um zum Umsatz klassi-scher, lizenzkostenbasierter Software beizutragen.

76 Vgl. Hoch et al. (2000), S. 124. 77 Vgl. Müller (1999), S. 395. 78 Vgl. o.V. (2005c), S. 3. 79 Vgl. Baaken/Launen (1993), S. 163.

Page 48: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 30

Folgende Praxisbeispiele sollen zwei solcher Vermarktungsstrategien aufzeigen:

Fallstudie 3

Das Grafiksoftware-Unternehmen Adobe vertreibt das Programm Acrobat Reader gratis, während die Verwendung der dazu vorhandenen Komplementärprogramme kostenpflichtig ist. Beim Programm Acrobat Reader handelt es sich um ein Produkt, welches das Betrachten und Drucken von speziellen Dokumenten, so genannten Portable Document Files (PDF) ermöglicht. Das PDF-Format garantiert dabei die uneingeschränkte Portabilität eines solchen Dokuments auf jeden beliebigen Com-puter, der ein Adobe Acrobat Reader Programm installiert hat. Dabei bleibt das Layout genau in seiner ursprünglichen Form erhalten. Dokumente dieses Typs wer-den vor allem im Internet verwendet, da die Inhalte im Originallayout praktisch je-dem Nutzer zugänglich gemacht werden können. Er muss einzig das kostenlose Programm Adobe Acrobat Reader auf seinem Computer installieren. Um ein Do-kument in einem solchen PDF-Format zu erstellen, ist nun ein kostenpflichtiges Komplementärprogramm wie zum Beispiel der Adobe Acrobat Writer notwendig. Mit diesem Vertriebsmodell versucht Adobe konsequent die Netzwerkeffekte von Software auszunutzen. Durch die kostenlose Verbreitung von Adobe Acrobat Rea-der hat das Unternehmen einen de facto Standard für den Austausch von Dokumen-ten geschaffen und dabei Microsoft, welches mit seinem Office-Paket prädestiniert dafür gewesen wäre, wohl hauptsächlich durch den Preis ausgestochen. Die Netz-werkeffekte von Adobe Acrobat Reader führten dazu, dass der Verkauf komple-mentärer Programme möglich wurde.

Fallstudie 3: Adobe Acrobat

Fallstudie 4

Der Standard-Softwareproduzent Pinnacle stellt die Videosoftware Pinnacle Studio her. Um neue Kunden zu gewinnen, hat Pinnacle eine „abgespeckte“ Version der Software Pinnacle Studio entwickelt, welche als so genannte Lean Edition vertrie-ben wird. Die Software Pinnacle Studio Lean Edition zeichnet sich durch einen ge-ringeren Funktionsumfang aus und wird meist in einem kostenfreien Softwarepaket (software bundle) zusammen mit einem neuen Computersystem angeboten. Da-

Page 49: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 31

durch lernt der Benutzer die Software kennen und kann bei Gefallen die Vollversion kaufen.

Fallstudie 4: Lean Edition

3.1.3.

Partnerschaften

Partnerschaften stellen einen Haupterfolgsfaktor von Standard-Softwareunter-nehmen dar und die Standard-Softwareindustrie unterscheidet sich in diesem Punkt massiv von anderen Industrien. So meinte Steve Ballmer, heutiger CEO von Micro-soft, auf die Frage nach der Besonderheit der Softwareindustrie: „In unserer Bran-che überlebt man ohne Partner nicht. […] Wir alle brauchen einander. Das zu verin-nerlichen, es wirklich zu begreifen, dafür habe ich zehn Jahre gebraucht.“80 Diese Aussage stützt auch eine der umfassendsten Untersuchungen der Softwareindustrie von HOCH ET AL, dass erfolgreiche Unternehmen die Wichtigkeit von Partnern für ihr Erfolgsprodukt beinahe 30 Prozent höher einschätzten als weniger erfolgreiche Unternehmen.81 Der „Zwang“ zu Partnerschaften in der Standard-Softwareindustrie ergibt sich wiederum aufgrund der speziellen Marktmechanismen. Insbesondere die Netzwerkeffekte und hohen Innovationsrhythmen (Unsicherheiten) in der Standard-Softwareindustrie lassen den Partnerschaften hohe strategische Relevanz zu kom-men, denn sie ermöglichen technologische Rückstände aufzuholen, schneller den Markt zu bedienen und die Marktdurchdringung zu erhöhen.

Dabei haben sich in der Standard-Softwareindustrie folgende vier Arten von Part-nerschaften etabliert:82

a. Vertriebspartnerschaften

Die wohl wichtigste Form der Partnerschaft findet sich bei Standard-Software-unternehmen in Vertriebspartnerschaften. Die Vertriebspartner wirken als Multi-plikatoren und helfen im winner-take-all Markt schnell eine kritische Anzahl an Installationen zu erreichen. Die richtigen Vertriebspartner können der entschei-dende Erfolgsfaktor bei einem Standard-Softwareunternehmen sein. Die Er-

80 Zitiert nach Interview der Zeitschrift „Manager Magazin“ mit Steve Ballmer. Vgl. o.V. (1998), S. 162. 81 Vgl. Hoch et al. (2000), S. 181. 82 Vgl. Müller (1999), S. 306.

Page 50: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 32

folgsgeschichte des nicht börsenkotierten Schweizer Standard-Softwareunter-nehmens Abacus AG zeigt, dass die richtige Partnerstrategie entscheidend für den Erfolg des Unternehmens sein kann:

Fallstudie 5

Die nicht kotierte Abacus AG stellt seit 1985 betriebswirtschaftliche Standard-Software für kleine und mittlere Unternehmen (KMU) her. Am Anfang ihrer Tä-tigkeit wurde eine Buchhaltungssoftware für KMU entwickelt. Hinzu kamen Lösungen für Lohnabrechnungen, Kostenrechnung, Finanzwesen und Anlage-buchhaltung, die in die Finanzbuchhaltung integriert wurden. Heute nimmt die Abacus Suite eine führende Stellung im KMU-Bereich in der Schweiz ein. Die-ser Erfolg ist vor allem dadurch bedingt, dass das Unternehmen schon früh er-kannt hat, dass der entscheidende Hebel für den Einsatz von betriebswirtschaft-licher Software in der Zusammenarbeit mit den richtigen Vertriebspartnern liegt. Da der Buchhaltungsbereich von Wirtschaftsprüfungsunternehmen überprüft werden muss, bot sich eine Zusammenarbeit mit diesen Unternehmen an: Zum einen verfügen die Wirtschaftsprüfer aufgrund ihres spezifischen Know-hows über einen starken Einfluss auf ihre Kunden; zum anderen haben sie ein starkes Interesse daran, bei den verschiedenen Mandanten dieselbe Software einzuset-zen, was Effizienzgewinne bei der aufwendigen Revisionstätigkeit nach sich zieht, da die Daten überall nach dem gleichen System aufbereitet werden. Die enge Kooperation mit führenden Wirtschaftsprüfungsunternehmen in der Schweiz, welche zum Teil sogar als Wiederverkäufer der Software agieren, er-möglichte es Abacus von enormen Multiplikatoreffekten zu profitieren und da-durch in kürzester Zeit zum Marktführer aufzusteigen.

Fallstudie 5: Vertriebspartnerschaften bei Abacus

b. Entwicklungspartnerschaften

Entwicklungspartnerschaften verfolgen hauptsächlich das Ziel, Kooperationen im technologischen Bereich einzugehen. Dabei handelt es sich in der Regel um eine Zusammenarbeit mit einem anderen Softwareunternehmen, welches ein be-stimmtes Teilmodul entwickelt. Solche Partnerschaften machen dann Sinn, wenn ein Unternehmen entweder keine eigenen Kapazitäten investieren will

Page 51: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 33

oder nicht über das entsprechende Know-how verfügt. Ein Beispiel ist Micro-soft, welches für die Rechtschreibungs- und Trennungshilfen bei seinen Office-Softwarelösungen auf die Entwicklungen des Unternehmens Inso zurückgreift.83

c. Integrationspartnerschaften

Ein weiterer sehr wichtiger Bereich sind Integrationspartnerschaften. Sie zeich-nen sich dadurch aus, dass das Standard-Softwareunternehmen mit einem spezi-alisierten Partner zusammenarbeitet, welcher die Anpassung der Standard-Software in die Architektur und Gegebenheiten des Kundenunternehmens vor-nimmt. Diese Art der Partnerschaft spielt beinahe ausschliesslich bei Unterneh-men eine Rolle, welche variable Standard-Software herstellen, da bei fixer Stan-dard-Software die durch den Integrator zu leistende Wertschöpfung zu gering ist. Der Vorteil liegt darin, dass sich das Standard-Softwareunternehmen auf sei-ne Kernkompetenz konzentrieren kann und die häufig komplexe und teure Integ-ration der Software, welche vielfach betriebwirtschaftliches Know-how erfor-dert, an spezialisierte Unternehmen auslagern kann. Zudem fördern Integrati-onspartner aus Eigeninteresse den Verkauf der Software. Ein Beispiel ist das Unternehmen SAP, welches die Integration seiner komplexen ERP-Software zumeist grossen Systemintegratoren wie Accenture überlässt. Um die Qualität und die Exklusivität der Partnerschaft sicherzustellen, durchlaufen die Integrati-onspartner meist Trainings- und Zertifizierungsprozesse beim Softwareherstel-ler.

d. Komplementärproduktpartnerschaften

Komplementärproduktpartnerschaften zeichnen sich durch ihren informellen Charakter aus. Sie entstehen aufgrund der Innovationsgeschwindigkeit sowie der zunehmenden Komplexität in der Standard-Softwareindustrie. Einem einzigen Standard-Softwareunternehmen ist es nicht mehr möglich, selbst eine Komplett-lösung herzustellen. Stattdessen findet eine Spezialisierung auf Einzelkompo-nenten statt. Die vom Kunden gewünschte Lösung wird somit nicht von einem einzelnen Unternehmen, sondern in einem Netzwerk erbracht. Dazu ist es jedoch notwendig, dass die Produkte der einzelnen Anbieter zueinander komplementär

83 Vgl. Müller (1999), S. 313.

Page 52: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 34

sind, damit solche Partnerschaften entstehen können. Als sehr erfolgreiches Bei-spiel für funktionierende Komplementärpartnerschaften wird häufig die Win-dows-Betriebssystemplattform aufgeführt. Microsoft bietet anderen Unterneh-men eine attraktive Plattform für Drittsoftware an, welche wiederum die Attrak-tivität von Windows steigern und in ihrer Vielzahl einen Multiplikatoreffekt be-wirken.

3.2. Organisatorische Charakteristika

Die organisatorischen Strukturen spielen in allen Standard-Softwareunternehmen eine entscheidende Rolle – insbesondere für den wichtigen Entwicklungs- und Pro-duktionsbereich. Dies ist insbesondere darauf zurückzuführen, dass es sich bei der Softwareentwicklung um einen äusserst komplexen und humanintensiven Prozess-ablauf handelt, wo quasi die Köpfe der Mitarbeiter der zentrale Produktionsfaktor sind. Wenige Wirtschaftszweige sind derart stark von der Qualifikation ihrer Mitar-beiter abhängig wie die Softwarebranche.84 Entsprechend muss das Know-how der Mitarbeiter optimal im Unternehmen verteilt und genutzt werden, womit den Orga-nisationsstrukturen in einem Standard-Softwareunternehmen zentrale Bedeutung zukommt. Hinzu kommt der hohe Innovationsrhythmus in der Forschung und Ent-wicklung, welcher ständige Anpassungen und Fortentwicklungen der Produkte, aber auch der Entwicklungsverfahren fordert. Der Softwareentwicklungsprozess als zent-rale Unternehmensaufgabe ist somit in höchstem Masse von der Denkleistung der Mitarbeiter beeinflusst. Dabei ist bei der Gestaltung der Prozessorganisation grund-sätzlich ein Weg zwischen der Schaffung von individuellen kreativen Freiräumen und einer effizienten und planbaren Arbeitsteilung zu finden.

Die Komplexität, aber auch die Wichtigkeit, die der Organisation der Entwick-lungsprozesse in einem Standard-Softwareunternehmen zufällt, mag wohl ein Grund dafür sein, dass sich bereits zahlreiche Publikationen mit den Erfolgsfaktoren der Software-Entwicklung beschäftigt haben.85 Es zeigt sich, dass sowohl in Theo-rie als auch Praxis eine Unmenge von Vorgehens- und Organisationsmodellen vor-geschlagen und angewendet werden. Ein optimales Vorgehens- und Organisations-

84 Vgl. Müller (1999), S. 377. 85 Für eine Übersicht der Arbeiten vgl. Müller (1999), S. 385.

Page 53: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 35

modell für die Softwareentwicklung hat sich jedoch (noch) nicht herauskristallisiert. Dennoch können zentrale Ergebnisstufen – unabhängig vom verwendeten Vorge-hensmodell – identifiziert werden, welche wesentliche Bestandteile einer professio-nellen Softwareentwicklung ausmachen:86

• Anforderungsanalyse: Zu Beginn jedes Softwareentwicklungsprojektes müs-sen die zu erfüllenden Anforderungen des Systems genau bestimmt sein. Da-bei sind Aussagen hinsichtlich der gewünschten Funktionalität, der Leis-tungsfähigkeit, der Rahmenbedingungen wie z. B. Schnittstellen zu anderen Systemen oder auch des finanziellen Rahmens notwendig.

• Fachlicher Entwurf: Der Fachliche Entwurf ist eine Konkretisierung der An-forderungsanalyse, indem die fachlichen Funktionen des Softwareproduktes bestimmt werden. Es handelt sich somit um die Analyse bzw. Beschreibung der durch die Software abgedeckten Prozesse aus Sicht des Anwenders. Da sich der Fachliche Entwurf schlussendlich an den Gegebenheiten der Praxis orientiert und seine Inhalte in der Entwicklung auch umsetzbar sein müssen, erfolgt in der Realität meist eine pragmatische Trennung zwischen den Er-gebnistypen des Fachlichen und Technischen Entwurfs. So bedingen gewisse fachliche Anforderungen häufig bereits technische Lösungsvarianten oder Einschränkungen. Eine Lösung zur Abstimmung von fachlichen Inhalten mit der Anwenderseite bietet daher vermehrt die Verwendung von Prototypen, welche der Erprobung gewisser Funktionalitäten in einem frühen Entwick-lungsstadium dienen.

• Technischer Entwurf: Der Technische Entwurf hat zum Ziel, die Ergebnisse des Fachlichen Entwurfs in technische Komponenten umzusetzen. Dabei werden als wesentliche Aufgaben alle benötigten Systemkomponenten defi-niert, die logischen Zusammenhänge zwischen den Komponenten, der Da-tenverwaltung und den Verarbeitungsalgorithmen bestimmt, oder auch tech-nische Abhängigkeiten von bestehenden Produkten analysiert. Im Endeffekt resultiert ein Systementwurf, welcher eine vollständige und strukturierte De-

86 Vgl. Wiesinger (1996), S. 78ff.

Page 54: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 36

finition der Funktionsweise aller Module und Programmsteuerungen um-fasst.

• Implementierung: Bei der Implementierung wird im Wesentlichen der Sys-tementwurf in Code umgewandelt. Dies umfasst die Umsetzung der Ergeb-nisse des Systementwurfs in durch den Computer ausführbare Komponenten wie z. B. Programme und Module. Dabei werden die einzelnen Komponen-ten getestet und danach zur eigentlichen Applikation zusammengeführt.

• Abnahme: Ein abschliessender Systemtest gewinnt in der Praxis immer mehr an Bedeutung aufgrund der steigenden Menge der eingesetzten Produkte und der dadurch wachsenden Komplexität der „Produktelandschaft“, in welche die Software integriert werden muss. Dabei überlassen die Unternehmen ver-mehrt einen Grossteil der Softwaretests den Endanwendern, indem sie so ge-nannte Public Beta-Versionen ihrer Software zur probeweisen Verwendung bereitstellen.

Die oben aufgeführten Faktoren spielen auch in Modellen zur Beurteilung der Soft-wareentwicklungsqualität wie dem CMMI (oder der ISO Norm 15504) eine wesent-liche Rolle, auf welches ausführlich in Abschnitt V 3.2.1 eingegangen wird.

3.3. Finanzbezogene Charakteristika

3.3.1.

Kapitalfluss

Die Besonderheiten des Standard-Softwaregeschäfts zeigen insbesondere auch Aus-wirkungen auf die finanziellen Erfordernisse der Unternehmen wie in Abbildung 8 ersichtlich ist. So zeichnen sich Standard-Softwareunternehmen durch einen hohen Kapitalbedarf in der Produktentwicklungs- und Markteinführungsphase der Stan-dard-Softwareprodukte aus. Dieser ist dadurch begründet, dass die Entwicklung von Standard-Software äusserst komplex87 und sehr humanintensiv ist. Die Netzwerkef-fekte von Standard-Software zwingen zudem die Hersteller, ihre Produkte bei

87 Nach BROOKS ist der Aufwand zu Entwicklung eines mehrmals einsetzbaren Softwareprodukts rund neunmal so hoch wie der Aufwand für die Entwicklung eines für einen einzigen Einsatz entwickelten Produkts. Vgl. Brooks (1995), S. 230.

Page 55: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 37

Markteinführung aggressiv zu vermarkten, um schnell eine kritische Masse errei-chen zu können, welche eine Netzwerkbildung erlaubt.88 Nach dieser Initialphase sinkt der finanzielle Aufwand jedoch rapide, weil die Grenzkosten für die Erstel-lung von Kopien der Software sehr gering sind. Vielmehr führen die Lizenzeinnah-men nun zu einem starken Kapitalzufluss. Der hohe Innovationsrhythmus führt je-doch zu einem schnellen Veralten der Software und entsprechend sinkenden Li-zenzeinnahmen. Die meisten Unternehmen versuchen dieser Entwicklung entge-genzutreten, indem aktualisierte Versionen als kostenpflichtige Upgrades angeboten werden. Durch die Wiederverwendung eines Grossteils des Quellcodes bei der Ak-tualisierung ist der Kostenaufwand gering bei gleichzeitig neuen Lizenzeinnahmen. Zudem kann ein bereits bestehender Kundenstamm bedient werden. Die hohe tech-nologische, durch Diskontinuitäten geprägte Innovationsrate führt jedoch dazu, dass immer wieder bestehende Softwareprodukte obsolet werden und durch vollständige Neuentwicklungen ersetzt werden müssen. Dabei wiederholt sich das beschriebene Kapitalflussschema wieder.

Der Kapitalfluss bei einem Standard-Softwareunternehmen lässt sich für einen Pro-duktlebenszyklus folgendermassen grafisch darstellen:

88 So hat beispielsweise die Firma Microsoft für die Auslieferung von Windows 95 Versionen fünfhundert Lastwagen angemietet, um eine zeitgleiche Verfügbarkeit zu gewährleisten und damit eine möglichst schnelle Marktdurchdringung zu erreichen. Vgl. Hoch et al. (1999), S. 140.

Page 56: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 38

Marktein-führungsphase

Wachstums-phase

Sättigungs-phase

Softwareent-wicklungsphase

Kapi

talz

uflu

ssKa

pita

labf

luss

Zeit

Abbildung 8: Kapitalflussdiagramm

Der beschriebene hohe initiale Kapitalbedarf bei Standard-Softwareunternehmen führt dazu, dass viele Unternehmen versuchen, ihre Geschäftstätigkeit im Software-Dienstleistungsgeschäft zu beginnen, wo die finanziellen Erfordernisse nicht so hoch und die Risiken daher kleiner sind.89

Aufgrund des hohen initialen Finanzbedarfs kommt der im nächsten Unterkapitel näher zu betrachtenden Finanzierung von Standard-Softwareunternehmen eine hohe Bedeutung zu – und zwar nicht nur für neu gegründete Unternehmen. Die hohen Wachstumsraten und der schnelle technologische Fortschritt führen dazu, dass auch etablierte Unternehmen in hohem Tempo wachsen müssen, wollen sie nicht an Markanteil verlieren und somit auf Netzwerkeffekte für ihre Produkte verzichten. Dies bedeutet häufig, dass die Unternehmen trotz erfolgreicher Produkte ihre weite-ren Produktentwicklungen extern finanzieren müssen. Der Finanzbedarf zeigt sich auch darin, dass Dividendenzahlungen in der Standard-Softwarebranche völlig un-üblich sind.90

89 Vgl. Müller (1999), S. 36. 90 Microsoft hat im Jahr 2003 erstmals in seiner Geschichte und als eines der wenigen Standard-Software-

unternehmen damit begonnen, Dividenden an die Aktionäre auszuzahlen.

Page 57: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 39

3.3.2.

3.3.3.

Finanzierung

Die Standard-Softwareindustrie ist noch immer eine ausgesprochene Wachstums-branche. Dies widerspiegelt sich in den Finanzierungsmodellen der Unternehmen besonders. Viele Standard-Softwareunternehmen können ihr rasantes Wachstum91 nicht selbst finanzieren und sind deshalb auf den Zufluss externer finanzieller Mittel angewiesen. Dabei ist die klassische Fremdfinanzierung zumeist ausgeschlossen, denn die hauptsächlich in immaterielle Werte getätigten Investitionen können nicht als Sicherheiten für die Finanzierung dienen. Entsprechend finanziert sich die Mehrzahl der Standard-Softwareunternehmen über den freien Kapitalmarkt. Es ist dabei nicht unüblich, dass die Unternehmen immer wieder frisches Kapital aufneh-men. Dies ist insbesondere in Phasen der Fall, in denen neue Produktentwicklungen anstehen, die meist hoher Investitionen bedürfen. So kam zum Beispiel die Firma Apple während der Entwicklungsphase ihres neuen Betriebssystems MacOSX in arge finanzielle Bedrängnis. Das Unternehmen konnte den Mitbewerber Microsoft überzeugen, bedeutende finanzielle Mittel in das Unternehmen einzuschiessen. Im Gegenzug wurde der Browser Internet Explorer von Microsoft auf dem Apple Be-triebssystem vorinstalliert.

Ertragsmodell

Die technologisch sehr innovative Standard-Softwareindustrie hat lange Zeit bei den Ertragsmodellen keine allzu fortschrittlichen Ansätze verfolgt. Auch heute noch stammt der überwiegende Umsatzanteil in der Standard-Softwareindustrie vom klassischen Lizenzverkauf. Dabei wird eine maschinenlesbare Version92 des Pro-gramms, deren Verwendung durch Lizenzbestimmungen strikt geregelt und be-schränkt ist, dem Kunden zugeführt. Gerade das immaterielle Gut Software eignet sich jedoch bestens für neue Formen der Ertragsgenerierung. Vor allem das Auf-kommen von Open Source Software hat nun in den letzten Jahren dazu geführt, dass

91 Hinzu kommt der im letzten Unterkapitel beschriebene hohe initiale Kapitalbedarf bei neuen Produkt-entwicklungen.

92 Aus Wettbewerbsgründen wird in der Standard-Softwareindustrie grundsätzlich nie die originale Pro-grammversion verkauft, sondern immer nur eine Lizenz zur Nutzung dieser Software erteilt. Dabei wird dem Käufer eine kompilierte (maschinenlesbare) Version dieser Software angeboten, welche es nicht ermöglicht, Rückschlüsse auf den originären Programmcode zu ziehen.

Page 58: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 40

neuartige Ertragsmodelle entwickelt wurden, die häufig nicht nur auf Open Source Software beschränkt blieben. Diesen Ertragsmodellen ist dabei der Grundsatz ge-meinsam, dass für das (Haupt-)Produkt keine Lizenzgebühren verlangt werden. Somit müssen andere Ertragsquellen gefunden werden, die folgende Formen an-nehmen können:93

3.3.3.1. Support Seller Ertragsmodell

Das Support Seller Modell ist das wohl am meisten verbreitete Ertragsmodell. Die-ses Modell generiert die Erträge nicht durch den Lizenzverkauf des Produkts selbst, sondern durch mit dem Produkt verbundene Nebenprodukte oder Dienstleistungen (support). Dabei handelt es sich zum Beispiel um Distributionen, das heisst der Verkauf von ausgewählten und getesteten Programmen, welche zu einem kunden-freundlichen Gesamtpaket zusammengefasst und verkauft werden. Beim „Bran-ding“ versucht ein Unternehmen den Markennamen einer Open Source Software zu schützen und von der Verbreitung zu profitieren. So hat zum Beispiel das Unter-nehmen Sun ihr Bürosoftwarepaket unter dem geschützten Markennamen StarOf-fice als Open Source Software zur Verfügung gestellt. So muss für die Verwendung des Markennamens StarOffice eine (kostenpflichtige) Lizenz bei Sun beantragt werden. Training, Beratung und Support zu den Produkten sind weitere Möglichkei-ten mit Zusatzleistungen Erträge zu generieren. Das wertvolle Produkt selbst wird also kostenlos weitergegeben, während darum herum komplementäre, aber kosten-pflichtige Dienstleistungen bzw. Produkte kreiert werden.

Fallstudie 6

Das Softwareunternehmen Suse Linux (kürzlich von der Firma Novell übernom-men) verkauft hauptsächlich das eigentlich kostenlos erhältliche Betriebssystem Linux. Das Softwarepaket von Suse Linux umfasst jedoch nicht nur den Betriebs-systemkern von Linux, sondern zusätzlich integrierte Softwareprodukte, Dokumen-tationen und Dienstleistungen in Form von technischem Support und Service. Das Ziel des Unternehmens ist es, dem Kunden eine umfassende und benutzerfreundli-che Softwarelösung mit entsprechender Hilfe bei Problemen anzubieten. Von gros-

93 Vgl. Raymond (1999), S. 135ff.

Page 59: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 41

ser Wichtigkeit ist dabei auch, den Namen Suse Linux als Marke aufzubauen, wel-che als Qualitätsmerkmal für eine gute und funktionierende Linux Betriebssystem-lösung dienen soll.

Fallstudie 6: Suse Linux

3.3.3.2. Loss Leader Ertragsmodell

Bei diesem Modell wird ein kostenloses Softwareprodukt, welches meist keine oder nur geringe Einnahmen generiert als Zugpferd für traditionelle kommerzielle Soft-ware benutzt. Dieses Ertragsmodell versucht bewusst Marktanteile durch ein ver-lustbringendes Produkt zu „erkaufen“, welches als Umsatzbringer für komplementä-re kommerzielle Produkte fungiert. RAYMOND verwendet dafür auch den Namen „market positioner”, da diesem Modell die Idee zugrunde liegt, durch den Vertrieb von kostenloser Software Marktanteile für kostenpflichtige Produkte zu gewinnen bzw. zu verteidigen.94 Durch das kostenlose Angebot der Software soll eine mög-lichst grosse Nutzerbasis geschaffen werden. Auf Basis dieser Marktpräsenz sollen die bestehenden Kundenkontakte genutzt werden, um komplementäre, kommerziel-le Software zu vertreiben:

Fallstudie 7

Der Quicktime Player ist eine Abspielsoftware für verschiedenste Medien wie Vi-deo und Musik. Es wird vom Unternehmen Apple kostenlos vertrieben. Will der Nutzer jedoch komplementäre Aufgaben vornehmen und Aufzeichnungs-, Schnitt-, Konvertierungs- und Export-Funktionen zur Medienverarbeitung nutzen, so muss das kostenpflichtige Programm Quicktime Pro erworben werden. Um die Schwelle zum Kauf von Quicktime Pro möglichst tief zu halten, sind die erweiterten Funktio-nen bereits im kostenlosen Quicktime Player integriert. Durch den Kauf von Quick-time Pro werden nur die entsprechenden Funktionen freigeschaltet, wodurch ein kompliziertes Beziehen und Installieren der Software entfällt.

Fallstudie 7: Quicktime Player

94 Vgl. Raymond (1999), S. 136ff.

Page 60: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 42

3.3.3.3. Widget Frosting Ertragsmodell

Dieses Modell ist vor allem für Hardware-(widget) Hersteller von Interesse. Von Hardwareherstellern wird erwartet, dass neben der Hardware eine entsprechende Software95 installiert wird, welche die Ansteuerung der Hardware ermöglicht. Meist müssen die Unternehmen diese Software selbst erstellen. Durch das Benutzen des Open Source Softwaremodells können die Unternehmen jedoch zu meist besserem und billigerem Treiber- oder Schnittstellencode (frosting) gelangen, indem sie ex-terne Spezialisten in die Entwicklung einbinden können. Software stellt bei diesen Unternehmen einen notwendigen Bestandteil in Form eines Kosten- und nicht eines Gewinnblocks dar. Entsprechend führt die Freigabe des Softwarecode nicht zu ei-nem Umsatzrückgang.

Fallstudie 8

Der Computerchip-Hersteller Intel ist Marktführer für Hardwarearchitekturen auf dem Markt für Personalcomputer. Während das Unternehmen früher nur den Haupt-prozessor herstellte, so bietet es heute ganze Hardwarearchitekturen wie Mainboard mit Hauptprozessor, Grafikprozessor und WLAN-Komponente an. Das Unterneh-men konzentrierte sich dabei historisch immer auf das Betriebssystem Windows von Microsoft („Wintel“-Fraktion). Mit dem Aufkommen von Linux versucht Intel auch Treiber für dieses Betriebssystem zur Verfügung zu stellen, um nicht gegen-über einem allfälligen Konkurrenten wie AMD ins Hintertreffen zu geraten. Dabei werden viele Treiber als Open Source zur Verfügung gestellt. Dies hat den Vorteil, dass das Know-How von externen Linux-Spezialisten einfliessen kann, was eine bessere Qualität der Treiber bewirkt und zudem die Entwicklungskosten senkt.

Fallstudie 8: Intel

95 Dabei handelt es sich vor allem um Treibersoftware, d. h. Software, die die Hardware direkt anspricht. Es kann sich aber auch um Konfigurationswerkzeuge oder ganze Betriebssysteme handeln.

Page 61: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 43

3.3.3.4. Accessorizing Ertragsmodell

Dieses Ertragsmodell zielt darauf ab, den Verkauf von diversen Accessoires, also Zubehör für Open Source Software zu fördern. Die Palette reicht dabei von Büchern über Dokumentationen bis hin zu kompatibler Hardware.

Fallstudie 9

Das Verlagshaus O’Reilly produziert professionelle Dokumentationen und Fachbü-cher zu verschiedensten Open Source Softwareprodukten. Um im Markt eine mög-lichst hohe Kompetenz und Reputation aufzubauen beschäftigt und unterstützt der Verlag sogar bekannte Open Source Softwarespezialisten, welche ihr Wissen in die Bücher einfliessen lassen.

Fallstudie 9: O'Reilly

4. Zusammenfassung: Besonderheiten von Standard-Softwareunternehmen

Die besonderen Marktmechanismen führen dazu, dass sich Standard-Softwareunter-nehmen in vielen Bereichen durch eine Vielzahl an branchenspezifischen Eigenhei-ten auszeichnen, welche in diesem Kapitel nach den Bereichen geschäftstätigkeits-bezogene, organisatorische und finanzbezogene Charakteristika eingeordnet wur-den:

Bei den geschäftstätigkeitsbezogenen Besonderheiten finden sich zum einen die Forschung und Entwicklung, welche in der wissensbasierten Softwareindustrie eine überragende Bedeutung besitzt. Im Gegensatz zu klassischen Industrien, wo die Hauptaktivitäten auf der Produktion liegen und F&E-Ausgaben meist im einstelli-gen Prozentbereich des Umsatzes liegen, hat die Produktion in der Softwareindust-rie eine vernachlässigbare Stellung, während die Softwareentwicklung den zentralen Erfolgs- und Kostenfaktor darstellt. Als weitere Besonderheit zeichnet sich in der Softwareindustrie der Vertrieb aus. Netzwerkeffekte und einfache Skalierbarkeit bei Standard-Software führen dazu, dass besondere Vertriebsmethoden zum Einsatz kommen, die meist auf eine schnelle Marktdurchdringung zielen. So ist die kosten-lose Abgabe von Software – auch unter dem Einfluss von Open Source Software –

Page 62: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL II: CHARAKTERISTIKA VON STANDARD-SOFTWAREUNTERNEHMEN 44

in gewissen Bereichen zu einem wichtigen Vertriebsinstrument geworden. Die Ein-nahmen werden dabei über mit dem Produkt verknüpfte Dienstleistungen oder komplementären Produkten erzielt. Entsprechend handelt es sich bei den Ver-triebsmodellen in der Softwareindustrie um zumeist komplexe Konstrukte. Eine weitere Besonderheit ist die wichtige Rolle von Partnerschaften in der Softwarein-dustrie. Insbesondere die vorhandenen Netzwerkeffekte sorgen dafür, dass eine ge-schickte Zusammenarbeit mit anderen Unternehmen dem eigenen Geschäft zu wich-tigem Wachstum verhilft.

Die organisatorischen Besonderheiten sind weitgehend auf die Tatsache zurückzu-führen, dass es sich bei der Softwarebranche um eine äusserst humanintensive und wissensbasierte Industrie handelt. Entsprechend komplex zeichnet sich insbesonde-re die Organisation der wichtigen Softwareentwicklungsprozesse aus.

Die finanzbezogenen Charakteristika beruhen auf dem eher ungewöhnlichen Kapi-talzyklus bei Softwareunternehmen und den vor allem durch Open Source Software getriebenen ausgefallenen Ertragsmodellen. So ist der initiale Kapitalbedarf in der Standard-Softwareindustrie aufgrund der hohen Aufwendungen bei der Produkt-entwicklung und der Markteinführungsphase sehr hoch. Aufgrund der niedrigen Grenzkosten von Standard-Software sind bei einer erfolgreichen Durchdringung des Marktes jedoch hohe Kapitalzuflüsse und Renditen zu erwarten. Diese können je-doch im Zuge technologischer Veränderungen, welche Softwareprodukte obsolet werden lassen, drastisch abnehmen. Die Finanzierung findet bei Standard-Softwareunternehmen im Gegensatz zu anderen Branchen in der Regel aufgrund der fehlenden Sicherheiten kaum über Fremdkapital statt, sondern erfolgt meist über die Aufnahme von Risikokapital. Die Ertragsmodelle basierten lange Zeit auf Lizenz-zahlungen, welche jedoch aufgrund von Open Source Software immer stärker unter Druck kommen. Daher zeichnen sich die neueren Modelle durch exotische Lösun-gen aus, welche auf Lizenzkosten verzichten und dafür Leistungspakete in ver-schiedenster Ausprägung anbieten.

Page 63: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 45

Teil III: Anforderungen der externen Analyse

Das Ziel dieser Dissertation ist es, ein Rahmenkonzept für die Rechnungslegung von Standard-Softwareunternehmen zu entwickeln, welches die Informationsbe-dürfnisse externer Investoren optimal befriedigt. Im Rahmen der Fundamentalana-lyse ist der Investor auf möglichst entscheidungsnützliche Informationen angewie-sen, welche er zu grossen Teilen von der Rechnungslegung bezieht. So nimmt die Rechnungslegung mindestens drei bedeutsame Rollen im Analyseprozess ein:

1. Sie stellt eine Sprache zur Prognose bereit.

2. Die Rechnungslegung stellt hilfreiche Informationen für zukünftig zu erwar-tende Geschäftserfolge zur Verfügung.

3. Sie liefert eine Ex-Post Kontrolle von Bewertungen.

Die Rechnungslegung stellt somit eine wichtige Datenbasis für die externe Analyse dar. In diesem Teil ist deshalb zu untersuchen, welche Anforderungen die externe Analyse an die Rechnungslegung stellt, damit diese dem Investor die geforderten Informationen liefern kann. Im ersten Kapitel sollen daher die Anforderungen der externen Analyse im Sinne von allgemeinen Qualitätskriterien definiert werden. Im zweiten Kapitel wird darauf eingegangen, welche speziellen Ansprüche sich auf-grund der in Teil II identifizierten Charakteristika von Standard-Softwareunter-nehmen aus Sicht der externen Analyse an die Rechnungslegung ergeben. Erst die Entwicklung eines solchen Beurteilungsrahmens erlaubt es, im weiteren Verlaufe dieser Arbeit fundierte, wertende Aussagen über die Rechnungslegung zu machen.

1. Definition der Qualitätskriterien

Die externe Analyse dient dazu, dem Investor entscheidungsrelevante Informatio-nen zu liefern und bildet damit die Grundlage zur Beurteilung eines Unternehmens. Hauptanforderung der externen Analyse an die Rechnungslegung ist somit generell formuliert, dass die Informationen einen Nutzen für die Entscheidungsfindung des Investors haben. Ziel dieses Kapitels ist es daher, auf Basis des IASB Rahmenkon-zepts und der FASB Concepts Statements allgemeine Qualitätskriterien für die

Page 64: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 46

Rechnungslegung zu definieren.96 Diese sollen als Anforderungskatalog der exter-nen Analyse dienen und den Informationsbedarf, definiert als Entscheidungsnutzen (decision usefulness) des externen Investors, gegenüber der Rechnungslegung von Standard-Softwareunternehmen widerspiegeln.

Die Qualitätskriterien der Rechnungslegung lassen sich grob in zwei Hauptgruppen einteilen:

Auf der einen Seite findet sich der Forderungskreis der Relevanz (relevance), wel-cher sicherstellt, dass dem Investor entscheidungsrelevante Informationen zur Ver-fügung gestellt werden. Informationen gelten dann als relevant, wenn sie die wirt-schaftlichen Entscheidungen der Adressaten beeinflussen, indem sie ihnen bei der Beurteilung der Ergebnisse vergangener, gegenwärtiger und zukünftiger Ereignisse helfen oder ihre Beurteilungen aus der Vergangenheit bestätigen oder korrigieren.97 Die Kriterien der Kategorie relevance sollen somit nicht zuletzt dafür sorgen, dass die im Rahmen der Bilanzskandale der letzten Jahre verstärkte Forderung nach Of-fenlegung von finanziellen Informationen gegenüber dem externen Investor nicht mit einer beinahe unendlichen, aber nichts sagenden Informationsflut einhergeht.

Auf der anderen Seite finden sich die Kriterien im Rahmen der Verlässlichkeit (re-liability), welche dafür sorgen, dass die im Abschluss enthaltenen Informationen auch tatsächlich als Entscheidungsgrundlage für den Investor geeignet sind. Der Investor muss also davon ausgehen können, dass die bereit gestellten Informationen die tatsächlichen Verhältnisse des Rechnungslegenden reflektieren.

Vielfach besteht jedoch zwischen den beiden Ansatzkriterien relevance und reliabi-lity ein Zielkonflikt.98 So werden zwar die Anforderungen der relevance generell schnell erfüllt, jedoch nicht diejenigen des Kriteriums reliability, weil die ersten verfügbaren Informationen häufig zu unsicher sind, um dessen Ansprüchen zu ge-nügen. Die mit dem Zeitablauf zusätzlich verfügbaren Informationen erhöhen dann zwar die Zuverlässigkeit (reliability), doch verliert die Information bis dahin meist

96 Dies ist dadurch begründet, dass es explizit der Fokus der beiden Regelwerke IFRS und US-GAAP ist, Investoren entscheidungsrelevante Informationen über Unternehmen zu vermitteln. Vgl. KPMG (2003), S. 15 und Achleitner/Behr (2002), S. 97.

97 Vgl. IASB F.26; SFAC 2 Summary. 98 Vgl. SFAC 5.76-77.

Page 65: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 47

ihre Relevanz (relevance).99 Dieser Zielkonflikt wird daher bei Vermögenswerten meist so gelöst, dass die Aktivierung an einem „Zwischenpunkt“ vorgenommen wird, wenn die Unsicherheit auf ein tolerierbares Mass reduziert ist – also noch kei-ne vollständige Verlässlichkeit erfüllt ist, die Information jedoch noch genügend relevant ist.100

In folgender Abbildung sind die einzelnen Qualitätskriterien der Forderungskreise relevance und reliability grafisch zusammengefasst. Dabei werden die englischen Originalbegriffe verwendet, um die zwangsläufig auftretenden Ungenauigkeiten bei einer Übersetzung ins Deutsche auszuschliessen:

DECISION USEFULNESS

RELEVANCE RELIABILITY

Comparability

Consistency

Materiality

Timeliness

Predictive Value

Feedback Value

Neutrality

Conservatism Completeness

Representational Faithfulness Understandability

Abbildung 9: Qualitätskriterien der Rechnungslegung101

In den folgenden Unterkapiteln zu den Forderungskreisen relevance und reliability werden die oben dargestellten Kriterien jeweils einzeln behandelt:

1.1. Anforderungen im Rahmen der relevance

Die sieben Einzelanforderungen des Forderungskreises relevance werden im Fol-genden erläutert: Das Element understandability fordert, dass der Empfänger fi-nanzwirtschaftlicher Informationen in der Lage sein soll, deren Inhalt zu verstehen und so deren Bedeutung für seine eigene Entscheidungssituation einzuschätzen.102 Dabei wird von einem abstrakten idealtypischen Investorenbild ausgegangen, wel-chem angemessene Grundkenntnisse in der Rechnungslegung sowie ein normales

99 Vgl. SFAC 5.77 und Schreiber (2002), S. 78f. 100 Vgl. SFAC 5.77, welches in diesem Zusammenhang von „at some intermediate point“ spricht. 101 In Anlehnung an Leibfried (2002), S. 52 102 Vgl. IASB F.25 und SFAC 2.40ff.

Page 66: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 48

Mass an Bereitschaft, sich ausreichend mit den vorliegenden Informationen zu be-schäftigen, zugeschrieben wird. Die mangelnde Verständnisfähigkeit einzelner darf somit nicht als Argument für einen Angabeverzicht von Informationen genommen werden.

Das Element materiality beschäftigt sich mit der Frage, ob Informationen wichtig genug sind, um wirtschaftliche Entscheidungen der externen Investoren zu beein-flussen.103 Zur Beurteilung der Wichtigkeit wird dabei hauptsächlich auf das Krite-rium der Quantität abgestellt. Dennoch kann für die materiality Bedingung auch die Natur des zu beurteilenden Objekts entscheidend sein. So kann die quantitative Schwelle für eine Offenlegung durch die qualitative Aussagekraft eines Sachver-halts gesenkt werden.104 Demgemäss kann zum Beispiel ein Sachverhalt aus dem normalen Geschäftsgang als nicht materiell eingestuft werden, wenn er jedoch un-gewöhnlichen Umständen entspringt, durchaus als materiell bedeutsam beurteilt werden.

Der Zeitfaktor (timeliness) ist ein zentrales Element für die Relevanz von Infor-mationen. Nur wenn Informationen „rechtzeitig“ vorliegen, sind sie relevant und können dem Empfänger als Entscheidungshilfe dienen.105 Häufig ergibt sich jedoch aus der Forderung nach zeitnaher Berichterstattung ein Konflikt mit der Forderung nach Bereitstellung von verlässlichen Informationen. Die zeitgerechte Bereitstel-lung von Informationen kann dazu führen, dass aufgrund noch nicht abgeschlosse-ner Sachverhalte noch keine endgültigen, verlässlichen Daten vorliegen. In diesem Fall muss unter Umständen auf Schätzungen zurückgegriffen werden. Um eine an-gemessene Balance zwischen Relevanz und Verlässlichkeit zu erreichen, ist immer die Grundidee zu berücksichtigen, wie den Informationsbedürfnissen des externen Investors am besten entsprochen werden kann.

103 Vgl. IASB F.29f. und SFAC 2.123ff. 104 So nennt das SFAC 2.128 unter anderem folgendes Beispiel: „A failure to disclose separately a nonre-

current item of revenue may be material at a lower threshold than would otherwise be the case if the revenue turns a loss into a profit or reverses the trend of earnings from a downward to an upward trend.” Zitiert nach SFAC 2.128b).

105 Vgl. IASB F.39ff. und SFAC 2.111ff., wobei der Begriff comparability sich im Deutschen auf die sach-liche Vergleichbarkeit bezieht, während consistency der zeitlichen Vergleichbarkeit (Stetigkeit) ent-spricht.

Page 67: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 49

Die sachliche wie zeitliche Vergleichbarkeit von Informationen (comparabili-ty/consistency)106 stellt ein wichtiges Element der Entscheidungsrelevanz dar. Der externe Investor muss in der Lage sein, Informationen innerhalb des Unternehmens über die Zeit hinweg vergleichen zu können und ist somit auf Stetigkeit in der Be-richterstattung angewiesen (consistency). Nur dadurch ist es ihm möglich, wirt-schaftliche Veränderungen im Unternehmen zu erkennen und Trends abzuleiten. Investoren muss es zudem möglich sein, die Abschlüsse verschiedener Unterneh-men miteinander zu vergleichen, um die vorteilhafteste Option zu ermitteln. Die Berichterstattung muss also auch aussagekräftige Informationen für einen Unter-nehmensvergleich bereitstellen (comparability).

Die Anforderungen im Rahmen der Kriterien des predictive value sowie des feed-back value verlangen, dass die unternehmerische Berichterstattung Prognosen über die Zukunft ermöglichen soll und dass deren Eintreffen oder Ausbleiben in einem späteren Zeitpunkt überprüfbar sein soll.107 Beide Kriterien sind eng miteinander verknüpft und bilden einen Kernbereich der Entscheidungsrelevanz. Sie implizie-ren, dass Investoren in der Rechnungslegung ein Instrument zur Entscheidungsfin-dung im Rahmen zukünftiger Entwicklungen sehen. Somit darf die Berichterstat-tung nicht nur auf die Darstellung der Vergangenheit ausgerichtet sein, sondern muss für den Investor einen Prognosewert entfalten.108

1.2. Anforderungen im Rahmen der reliability

Die vier Elemente der reliability stellen sich folgendermassen dar: Das Element representational faithfulness fordert, dass eine möglichst grosse inhaltliche Über-einstimmung zwischen einem Phänomen der realen Welt und dessen Bewertung oder Abbildung im Rahmen der Rechnungslegung bestehen muss.109 Sie fordert, dass ein einheitliches Wertungssystem zur Anwendung kommt. Es soll also sicher-stellen, dass die Rechnungslegungsmassgaben auch wirklich das repräsentieren, was

106 Vgl. IASB F.25 und SFAC 2.40ff. 107 Vgl. IASB F.26ff. und SFAC 2.51ff. 108 Vgl. SFAC 2.53ff. 109 Vgl. IASB F.33ff. und SFAC 2.63ff. In den US-GAAP wird zusätzlich das Kriterium verifiability ver-

wendet, welches jedoch inhaltlich dem Kriterium representational faithfulness weitgehend entspricht, weshalb auf eine separate Erläuterung an dieser Stelle verzichtet wird (vgl. SFAC 2.81ff.).

Page 68: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 50

sie zu messen vorgeben.110 Die Angaben sollen daher keine wesentlichen Fehler enthalten. So können Informationen zwar relevant, jedoch in ihrer Art oder Darstel-lung so unzuverlässig sein, dass ihre Berichterstattung möglicherweise irreführend ist. Ist zum Beispiel die Rechtsgültigkeit oder die Höhe eines Schadenersatzanspru-ches im Rahmen eines Gerichtsverfahrens strittig, so kann es für das Unternehmen unangebracht sein, den vollen Umfang des Anspruches in der Bilanz anzusetzen. Allerdings kann es sinnvoll sein, den Forderungsbetrag sowie die Umstände des Anspruches anzugeben.111

Die Möglichkeit ein angemessenes Urteil über die wirtschaftliche Lage eines Un-ternehmens fällen zu können, basiert entscheidend darauf, dass alle entscheidungs-relevanten Informationen zur Verfügung stehen (completeness).112 Dabei ist natür-lich die Forderung der Verhältnismässigkeit zu beachten, um nicht zu einer nahezu unbegrenzten Informationsflut zu gelangen.

Das Kriterium der neutrality gilt sowohl für das bilanzierende Unternehmen als auch für den Standardsetter und fordert, dass Informationen, die im Rahmen der Rechnungslegung erhoben und publiziert werden, alleine dem Zweck einer optima-len Entscheidungsfindung des Investors dienen sollen und nicht zur Erfüllung wei-terer Ziele verwendet werden dürfen.113 Die Informationen müssen also neutral, das heisst frei von verzerrenden Einflüssen sein. Abschlüsse sind demnach nicht neut-ral, wenn sie durch Auswahl oder Darstellung der Informationen eine Entscheidung oder Beurteilung beeinflussen, um ein vorher festgelegtes Resultat oder Ergebnis zu erzielen. Für die Standardsetter gilt somit, dass zum Beispiel keinen politischen oder steuerlichen Interessen nachgegeben werden darf.114

Die Bereitstellung von Informationen in der Rechnungslegung erfolgt in aller Regel unter dem Eindruck der Ungewissheit, ob alle getätigten Annahmen zutreffend sind oder ob sich in Zukunft mögliche Korrekturen als notwendig erweisen. Das Kriteri-um conservatism trägt dem Umstand Rechnung, dass mögliche, nachträgliche Kor-

110 Vgl. SFAC 2.81ff. 111 Vgl. IASB F.32. 112 Vgl. IASB F.38 und SFAC 2.79f. 113 Vgl. IASB F.36 und SFAC 2.98ff.. 114 Vgl. SFAC 2.104.

Page 69: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 51

rekturen Wertverluste für Investoren nach sich ziehen können.115 Um dieses Risiko möglichst gering zu halten, wird daher gefordert, bei Bilanzierung und Bewertung grundsätzlich Vorsicht walten zu lassen. Dies bedeutet, dass auch bei Ermessens-spielräumen ein hohes Mass an Sorgfalt gewahrt werden soll, so dass Vermögens-werte oder Erträge nicht zu hoch und Schulden oder Aufwendungen nicht zu tief angesetzt werden. Eine vorsichtige Vorgehensweise erlaubt jedoch beispielsweise nicht, systematisch Aktiven zu tief und Passiven zu hoch auszuweisen und dadurch stille Reserven anzulegen, da dann die Neutralität nicht gewährleistet wäre.

2. Problembereiche der Rechnungslegung

Die Geschäftstätigkeit eines Standard-Softwareunternehmens kann vereinfacht als Erzeugung und Distribution von Standard-Software beschrieben werden. Die Hauptaktivitäten eines Standard-Softwareunternehmens können somit folgender-massen definiert werden: Entwicklung einer Standard-Software (zumeist eine Wei-terentwicklung eines bestehenden Produkts), „Produktion“ 116 einer lauffähigen Ver-sion der Software und der Vertrieb der Software, wobei die Vertriebsvereinbarun-gen in den meisten Fällen neben der Softwarelizenz weitergehende, postvertragliche Leistungen umfassen. Bei fixer Standard-Software beinhalten diese Leistungen meist Fehlerbehebungen (bug fixes), Verbesserungen (updates), Recht auf Weiter-entwicklungen (upgrades) oder Supportgarantien. Bei variabler Standard-Software hingegen handelt es sich dabei schwerpunktmässig um Anpassungs- oder auch Schulungsleistungen. Die gesamte Aktivitätskette wird durch generelle Support-funktionen wie Personal, Finanzen, Rechnungslegung und Marketing unterstützt. Grafisch können diese Aktivitäten in der folgenden Wertschöpfungskette für Stan-dard-Softwareunternehmen zusammengefasst werden:

115 Vgl. IASB F.37 und SFAC 2.91ff. 116 Die Produktionsaufwand ist allerdings sehr gering, da der Quellcode durch geeignete Programme (com-

piler) automatisiert in maschinenlesbaren Code umgewandelt werden kann. Einzig bei der Distribution der Softwareprodukte auf physischen Medien (wie CD) kommt der Produktion eine grössere Bedeutung zu.

Page 70: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 52

Software-

entwicklung Vertrieb Post-Vertrags-

leistungen Produktion

Supportfunktionen

Abbildung 10: Wertschöpfungskette von Standard-Softwareunternehmen

Wie in Teil II der Dissertation dargelegt und durch die Wertschöpfungskette illust-riert, kommt bei Standard-Softwareunternehmen insbesondere der Softwareentwick-lung sowie den Vertriebsaktivitäten mit den postvertraglichen Leistungen eine sehr wichtige Rolle zu.

Um die im vorhergehenden Kapitel dargestellten, allgemeinen Anforderungen der investororientierten Rechnungslegung zu erfüllen, können sich aus den Charakteris-tika einer Branche, aus der Wertschöpfungskette von Unternehmen oder aus Verän-derungen des wirtschaftlichen Umfelds besonders bedeutsame Problembereiche der Rechnungslegung ergeben. Für Standard-Softwareunternehmen sollen diese nach-folgend identifiziert werden:

2.1. Umsatzerfassung

Die Umsatzerfassung von Standard-Softwareunternehmen ist durch die hohe Kom-plexität der verwendeten Vertriebsmodelle geprägt. Dies ist vor allem dadurch be-dingt, dass Standard-Software nicht nur als over the counter-Produkt vermarktet, sondern häufig mit Dienstleistungen kombiniert wird, welche je nach Kundenbe-dürfnis zu einem Leistungspaket zusammengestellt werden. Zum heutigen Zeit-punkt dominieren Lizenzvereinbarungen, welche die Kosten des Lizenzerwerbs auf Zeit- oder Installations- bzw. Nutzerbasis regeln und zudem Abmachungen über zusätzliche Dienstleistungen in Form von Installation, Ausbildung oder Support festhalten. Es werden jedoch fortlaufend neue Vertriebsmodelle entwickelt, um den Kundenbedürfnissen besser Rechnung zu tragen. So setzt sich bei Unternehmens-kunden vermehrt das subscription Modell durch, welches kurze Lizenzlaufzeiten mit Dienstleistungen zu einem Paket kombiniert und zu einem einheitlichen, zum

Page 71: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 53

Beispiel monatlich fälligen Preis angeboten wird.117 Ein weiteres Vertriebsmodell ist das application service provider-Modell, welches dem Kunden die Standard-Software in einem reinen Mietmodell zur Verfügung stellt. Dabei wird der Vertrieb auf eine reine Dienstleistungstransaktion reduziert, indem die Software an einem zentralen Ort bereitgehalten wird und der Kunde im Bedarfsfall über das Internet darauf zugreifen kann.

Das Aufkommen von Open Source Software führt zudem zu einer teilweisen Sub-stitution der lizenzkostenbasierten Vertriebsmodelle durch neuartige, meist dienst-leistungsbasierte Vertriebskonzepte. Zum einen sind Unternehmen, welche Open Source Software vertreiben gezwungen, neue nicht lizenzkostenbasierte Vertriebs-modelle zu entwickeln, um finanziell erfolgreich zu sein. Zum anderen übt Open Source Software aufgrund der tieferen direkten Kosten (keine Lizenzgebühren) ei-nen hohen Druck auf die klassischen lizenzkostenbasierten Vertriebsmodelle aus.

Wie an obigen Beispielen erläutert, zeichnen sich die Vertriebsmodelle in der Stan-dard-Softwareindustrie allgemein durch eine komplexe Kombination von Produkten und/oder Dienstleistungen aus, welche sich zudem in einem dauernden Verände-rungsprozess befinden. Insbesondere der vermehrte Einsatz von Open Source Soft-ware führt zu einem starken Druck, dauernd neue innovative Vertriebsmodelle zu entwickeln. Der Umsatzerfassung kommt dabei die schwierige Aufgabe zu, diese Vertriebsmodelle exakt festzuhalten und ein akkurates Bild der tatsächlichen Ein-nahmen von Standard-Softwareunternehmen abzugeben.

2.2. Berichterstattung über Standard-Software

Der Standard-Software als endgültigem Ergebnis von Forschung und Entwicklung, aber auch als eigentlichem Kernelement des „Wertschöpfungsprozesses“ in einem Standard-Softwareunternehmen kommt per se hohe Bedeutung in der Berichterstat-tung eines Unternehmens der Standard-Softwareindustrie zu. Hinzu kommen be-sondere Eigenschaften von Standard-Software, welche grossen Einfluss auf die Re-chungslegung haben. So vereint insbesondere Standard-Software in den meisten Fällen immaterielle wie materielle Elemente in sich. Die Problematik ergibt sich aus

117 Aberdeen Group (2002), S. 1-6.

Page 72: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 54

der Tatsache, dass es sich hierbei um einen Gegenstand handelt, der sowohl imma-terielle (das Programm) als auch materielle (Datenträger: Beispielsweise eine CD oder DVD) Bestandteile aufweisen kann.118 Ob diesem Vermögenswert nun imma-terieller oder materieller Charakter zugebilligt wird, ist entscheidend für seine Be-handlung durch die Rechnungslegung. Diese Beurteilung hängt dabei davon ab, welches Element wesentlicher ist, wie es die IFRS explizit formulieren.119 So ist für die IFRS eine Software für eine computergesteuerte Werkzeugmaschine, die ohne diese bestimmte Software nicht betriebsfähig ist, integraler Bestandteil der zugehö-rigen Hardware und daher als Sachanlage zu behandeln.120 Gleiches soll nach IFRS auch für das Betriebssystem eines Computers gelten.121 Dieser Vorstellung kann aufgrund der heutigen Entwicklung bei Betriebssystemen nicht mehr zugestimmt werden. Das Aufkommen des freien Betriebssystems Linux neben dem marktbe-herrschenden, kostenpflichtigen Betriebssystem Windows von Microsoft, welche beide auf verschiedenste Hardware aufgespielt werden können, zeigt auf, dass das Betriebssystem keinesfalls mehr einen integralen Bestandteil einer zugehörigen Hardware bildet.122 So ist wohl KESSLER zuzustimmen, welcher einerseits zwischen dem Quellcode (welcher zumeist beim Hersteller verbleibt) und dem zum Verkauf bestimmten Programmträger andererseits unterscheidet. Er argumentiert, dass die Entwicklung des Softwareprogramms einen „geistigen Schöpfungsprozess“ darstel-le, welcher zum immateriellen Vermögensgegenstand Standard-Software in Form des Quellcodes führe. Werden später auf Basis dieses Quellcodes Programmkopien hergestellt, so stellen diese eigene Vermögensgegenstände dar, welchen aufgrund ihres rein physischen Gehaltes materieller Charakter zukommt.123 Entsprechend muss diesem Unterschied in der Rechnungslegung Rechnung getragen werden, in-dem der Quellcode grundsätzlich als immaterieller Wert und die Programmkopien als materielle Werte behandelt werden.

118 Vgl. Pirker (1997), S. 42. 119 Vgl. IAS 38.3. 120 Vgl. IAS 38.3. 121 Vgl. IAS 38.3. 122 Integraler Bestandteil der Hardware bilden heute nur noch die Treiber, welche dem Betriebssystem die

notwendige Kommunikation mit der Hardware ermöglichen. 123 Vgl. Kessler (1994), S. 9.

Page 73: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 55

Bei der Berichterstattung von Standard-Software ist die weitere Besonderheit zu berücksichtigen, dass dem Herstellungsprozess von Software (wie auch den For-schungs- und Entwicklungsaktivitäten allgemein) eine grosse Ähnlichkeit zu der Herstellung von materiellen Werten attestiert wird.124 Entsprechend unterscheiden sich daher die Anforderungen an die Berichterstattung von Software zum Teil stark von anderen immateriellen Werten. So erfolgt die Softwareentwicklung in (geplan-ter) Projektform, während sich andere immaterielle Werte (z. B. Marken) zumeist aus der operativen Tätigkeit ergeben. Dadurch sind die klassischen Probleme imma-terieller Werte bezüglich Abgrenzbarkeit der Aufwendungen, Identifizierbarkeit und Bewertung des Vermögenswertes sowie die Realisierbarkeit des zukünftigen Nutzenzuflusses bei Software viel weniger akut und erfordern daher eine andere Behandlung in der Berichterstattung.125

2.3. Berichterstattung über immaterielle Werte

Unternehmerischer Erfolg von Standard-Softwareunternehmen ist ganz wesentlich mit dem Vorhandensein geeigneter immaterieller Werte verknüpft. Dies zeigen die Erläuterungen in Teil II und eine Analyse der Wertschöpfungskette126 deutlich: Auf jeder Stufe des Wertschöpfungsprozesses sind an zentraler Stelle immaterielle Wer-te involviert wie der Quellcode der Software, die Mitarbeiter, die Kundenlisten oder das Entwicklungsprozess-Know-how.

Trotz der ständig steigenden Bedeutung von immateriellen Werten in der Wert-schöpfung von Unternehmen und somit auch in der Rechnungslegung, hat sich bis-her keine allgemein anerkannte Definition für immaterielle Werte etabliert. Bereits die Bezeichnung für “immaterielle Werte” (intangible assets) ist nicht einheitlich, denn es werden verschiedene Begriffe wie “immaterielle Güter“, „immaterielle Vermögensgegenstände“, „Wissenskapital“ (knowledge assets) oder „Humankapi-tal“ (intellectual capital) häufig als Synonyme bzw. als inhaltsähnliche Begriffe verwendet.127 Nach LEV wird der Begriff intangible assets vor allem in der Rech-

124 Vgl. z. B. Upton (2001), S. 69f. und von Keitz (1997), S. 247ff. 125 Vgl. dazu die Ausführungen im nächsten Unterkapitel. 126 Vgl. Abbildung 10. 127 Vgl. Arbeitskreis Immaterielle Werte der Schmalenbach-Gesellschaft (2001), S. 990.

Page 74: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 56

nungslegungsliteratur verwendet, während Ökonomen den Begriff knowledge assets gebrauchen und intellectual capital in der Management- und Rechtsliteratur verbrei-tet ist – doch alle verweisen grundsätzlich auf dasselbe: Eine nicht physische Quelle eines zukünftigen finanziellen Nutzens.128

Das Intangibles Research Center an der New York University bietet eine Definition für „immaterielle Werte“ im weiteren Sinn an:129

„Intangibles are nonphysical sources of probable future economic bene-fits to an entity or alternatively all the elements of a business enterprise that exist in addition to monetary and tangible assets.”

Die Definition des SFAS 142 Goodwill and Other Intangible Assets ist ähnlich breit gefasst:130

“Intangible assets are noncurrent assets (not including financial instru-ments) that lack physical substance.”

Die zitierten Definitionen basieren auf der negativen Abgrenzung der immateriellen Werte:131 Die immateriellen Werte werden negativ als all diejenigen Werte defi-niert, welche weder physischer noch monetärer Natur sind. Durch dieses Vorgehen ist gewährleistet, dass alle in der heutigen Rechnungslegung nicht erfassten Kom-ponenten zumindest theoretisch inkludiert und somit geortet sind. Die Problematik zeigt sich jedoch meist darin, dass negative Definitionen für die praktische Arbeit zu wenig Substanz und definitorisches Potenzial aufweisen, um als konkrete Ab-grenzungskriterien dienen zu können.

Nicht zuletzt aufgrund der unklaren definitorischen Abgrenzung immaterieller Wer-te ist auch deren Erfassung in der Rechnungslegung grundsätzlich ein Thema an-dauernder Aktualität. Bereits in den 1970er Jahren bezeichnete MOXTER immate-

128 Vgl. Lev (2001), S. 5. 129 Zitiert nach Upton (2001), S. 68. 130 SFAS 142. 131 Dieses Vorgehen ist im internationalen Rechnungslegungsschrifttum für immaterielle Werte weitgehend

üblich. Vgl. dazu von Keitz (1997), S. 5f.

Page 75: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 57

rielle Werte als „ewige Sorgenkinder der Rechnungslegung“132. Insbesondere der oftmals grosse Unterschied zwischen Buch- und Marktwert eines Unternehmens wird regelmässig mit dem Vorhandensein von bilanziell nicht erfassten im-materiellen Werten erklärt.133 Dabei weisen Softwareunternehmen im Branchenver-gleich eine der höchsten Markt- zu Buchwertverhältnisse auf.134 Während dieses Phänomen schon in früheren Jahren nachgewiesen werden konnte, so herrscht je-doch weitgehender Konsens darüber, dass eine Verschärfung der Problematik statt-findet.135 So unterscheidet sich die Situation seit Ende der 1990er Jahre von den vorangegangenen Jahrzehnten dadurch, dass „today a firm’s intangible assets are often the key element in its competitiveness“136. So meinen LABHART/VOLKART, wenn die Rechnungslegung in der Bilanz alle Wertpotenziale in einem Unterneh-men umfassend widerspiegeln würde, so wäre im Mittel aller in einem grossen Ka-pitalmarkt vertretenen Publikumsgesellschaften ein Verhältnis von Buch- zu Marktwert von eins zu eins zu erwarten.137 UPTON entgegnet dieser Forderung mit dem Hinweis auf SFAC 1 Objectives of Financial Reporting by Business Enterpri-ses, dass es nur die Aufgabe der Rechnungslegung sei, Informationen über die ver-lässlich bewertbaren ökonomischen Ressourcen eines Unternehmens zur Verfügung zu stellen, womit sie dem Kapitalmarkt helfe, seine Erwartungen zu bestätigen oder zu korrigieren.138 Dieser Ansicht von UPTON ist grundsätzlich zuzustimmen, wobei dennoch unbestritten ist, dass das Auseinanderdriften von Markt- und Buchwert eine unbefriedigende Situation für die investororientierte Rechnungslegung dar-stellt.

Die Schwierigkeiten hinsichtlich der Erfassung von immateriellen Werten in der klassischen Rechnungslegung beruhen unter anderem darauf, dass hohe Anforde-rungen an die Messbarkeit, Verlässlichkeit, Zeitnähe und Abgrenzbarkeit der In-

132 Moxter (1979), S. 1102. 133 Vgl. z. B. Lev (2001), S. 8., Labhart/Volkart (2001b), S. 1155. 134 Bei den zehn grössten Unternehmen der Softwarebranche betrug im Jahr 1997 das Verhältnis zwischen

Markt- und Buchwert im Schnitt 16 zu 1. Vgl. Hoch et al. (2000), S. 8. 135 Vgl. z. B. Achleitner/Behr (2002), S. 125f., Lev (2001), S. 7ff. 136 Eustace (2000), S. 6. 137 Vgl. Labhart/Volkart (2001b), S. 1155f. Diesem Urteil ist in dieser Absolutheit jedoch nicht zuzustim-

men, da die Wertpotenziale dauernden Veränderungen unterworfen sind. 138 Vgl. Upton (2001), S. 63.

Page 76: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 58

formationen gelegt werden.139 Die Werthaltigkeit ist jedoch bei vielen immateriel-len Vermögenswerten aufgrund ihrer fehlenden physischen Substanz und der daraus resultierenden – im Vergleich zu materiellen Gütern – fehlenden Sicherheit regel-mässig kaum oder erst spät verifizierbar. Zudem ergeben sich insbesondere aus For-schungs- und Entwicklungsanstrengungen zum Teil keine unmittelbar verwertbaren Ergebnisse, welche als abgrenzbare Vermögenswerte in Erscheinung treten.

Ausserdem ist eine einheitliche Behandlung der verschiedenen Arten von immate-riellen Werten aufgrund ihrer grossen Unterschiede äusserst schwierig. So werden gewisse immaterielle Werte, welche in Form von Projekten organisiert sind (wie F&E und Software) in sehr ähnlicher Weise wie materielle Werte (Entwicklung ei-ner Maschine) erstellt: Das Management beurteilt ein Projekt, akzeptiert einen Aus-führungsplan und setzt Ressourcen ein in der Hoffnung, dass das Resultat dem Un-ternehmen einen zukünftigen wirtschaftlichen Nutzen zuführt. Für materielle wie immaterielle Güter besteht zu Beginn die Unsicherheit eines möglichen technischen Misserfolgs. Bei weiterem Fortschreiten des Projekts ist hingegen für beide Güter hinreichend sicher, dass ein verwertbarer Vermögenswert entsteht. Ob eine Verwer-tung des Vermögenswertes (ökonomischer Erfolg) möglich ist, bleibt jedoch bei beiden Gütern bis zum Ende unsicher. Aus einer reinen Buchhaltungsperspektive stellt die Erfassung der Kosten dieser immateriellen Werte kein unüberwindbares Hindernis für die Rechnungslegung dar. Andere immaterielle Werte hingegen (wie Kundenlisten, Markennamen und Datenbanken) entspringen häufig dem täglichen, operativen Geschäft. Wieder andere Werte (wie Wert einer Versicherung) existieren nur mit einer Relation zu einem anderen Aktivum oder einer Schuld. Werte aus der zweiten oder dritten Gruppe schaffen beträchtliche Herausforderungen in Bezug auf Identifikation, Realisierung und Bewertung.140 Die folgende Grafik veranschaulicht nochmals die drei unterschiedlichen Formen von immateriellen Werten und ihre Ausprägungen:

139 Vgl. Upton (2001), S. 60f. 140 Vgl. Upton (2001), S. 69f.

Page 77: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 59

Typ des immateriellen Wertes: Beispiele:

Entstehung in Projektform F&E Software

Entstehung in operativer Tätigkeit Marken Kundenlisten

Entstehung als abhängige Werte

Versicherung

Abbildung 11: Typen von immateriellen Werten141

Aufgrund der aus Sicht der Rechnungslegung unterschiedlichen Anforderungen an die Erfassung von immateriellen Werten soll die in Projektform generierte (Stan-dard-)Software im Rahmen dieser Dissertation unabhängig von den übrigen imma-teriellen Werten, welche der operativen Kategorie bzw. den abhängigen Werten zu-zurechnen sind, behandelt werden. Wie oben erläutert, basiert diese Überlegung darauf, dass Standard-Software in ähnlicher Weise wie materielle Werte erstellt wird. Entsprechend wird in der Literatur immer wieder eine ähnliche Bilanzie-rungspraxis für Standard-Software bzw. für Forschung und Entwicklung im Allge-meinen wie für materielle Werte als sinnvoll erachtet.142 Somit unterscheidet sich die Rechnungslegungsproblematik von (Standard-)Software stark von den Frage-stellungen der anderen immateriellen Werte, womit sich eine getrennte Behandlung dieser beiden Themenbereiche in dieser Dissertation aufdrängt.143

2.4. Zukunftsbezogene Berichterstattung

Die hohe, diskontinuierliche Innovationsrate in der Standard-Softwareindustrie führt dazu, dass zur Beurteilung dieser Unternehmen nicht so sehr der aktuelle oder vergangene, sondern vielmehr der zukünftig zu erwartende Erfolg interessiert. Fol-gende Fallstudie aus der Standard-Softwareindustrie zeigt die Problematik exempla-risch auf:

141 Eigene Darstellung. 142 Vgl. z. B. Upton (2001), S. 69f., von Keitz (1997), S. 247ff. 143 Vgl. dazu Abschnitt IV 2.2 und Abschnitt IV.2.3.

Page 78: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 60

Fallstudie 10

Mitte der 1980er Jahre führte zuerst der Hardware- und Softwarehersteller Apple, bald darauf Microsoft die grafische Oberfläche für den Computer-Massenmarkt ein. Diese Entwicklung weg von einer kommandozeilengesteuerten Bedienung von Software hin zu einer grafischen Benutzerschnittstelle stellte eine für die (Standard-)Softwareindustrie typische, diskontinuierliche Innovation dar.

Die 1982 gegründete Firma Lotus Development Corporation war zu jener Zeit mit ihrer Software Lotus 1-2-3 der unangefochten führende Anbieter im Bereich von Tabellenkalkulationsprogrammen für das kommandozeilengesteuerte Betriebssys-tem MS-DOS. Aufgrund seiner überlegenen Fähigkeiten nahm das Softwarepaket Lotus 1-2-3 sogar die Rolle einer „Killerapplikation“ ein, welche entscheidend zum Siegeszug von MS-DOS beitrug.144 Die Software Lotus 1-2-3 war ein Softwarepaket aus Tabellenkalkulations-, Datenbank- und Graphikprogramm, welche eine eigene Graphikoberfläche implementiert hatte, da das Betriebssystem MS-DOS ja keine zur Verfügung stellte.145 Bereits 1985 führte Microsoft mit Windows ein Betriebs-system mit grafischer Oberfläche ein – vermarktet als separates, kostenpflichtiges Upgrade für MS-DOS. Das kommandozeilengesteuerte Betriebssystem MS-DOS bildete jedoch die Grundlage von Windows. Die unzureichende Leistungsfähigkeit von Windows und fehlende Programme führten dazu, dass die DOS-basierten Pro-gramme weiterhin favorisiert wurden. So war das populäre Programmpaket Lotus 1-2-3 weiterhin nur auf DOS-Basis erhältlich und eine Entwicklung für Windows wurde als nicht prioritär angesehen.146 Microsoft lieferte jedoch bereits früh sein Tabellenkalkulationsprogramm Excel für Windows aus. Mit der laufenden Weiter-entwicklung von Windows wurden die Vorzüge der grafischen Oberfläche von im-mer grösseren Kreisen von Anwendern anerkannt. Diese beinhalteten insbesondere die dank Graphikoberfläche benutzerfreundliche Verwaltung von Dateien und das einheitliche Erscheinungsbild der Programmoberflächen, da diese nun einheitlich vom Betriebssystem bestimmt wurden. Die träge Reaktion von Lotus auf Windows führte dazu, dass mit der steigenden Verbreitung von Windows auch laufend Markt-

144 Vgl. o.V. (2004b). 145 Vgl. Williams (1982), S. 182-198. 146 Vgl. Ghemawat et al. (1999), S. 7-6.

Page 79: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 61

anteile an Microsoft Excel verloren gingen. Mitte der 90er Jahre verkaufte sich Ex-cel bereits doppelt so häufig wie Lotus 1-2-3. Durch die Bündelung der Programme Excel, Word und Powerpoint zu „Microsoft Office“ und das Gewähren von hohen Wechselrabatten für Kunden von Lotus 1-2-3 steigerte Microsoft den Marktanteil weiter und liess Lotus 1-2-3 zu einem Nischenprodukt werden.

Fallstudie 10: Lotus 1-2-3

Das Fallbeispiel zeigt exemplarisch wie diskontinuierliche technische Innovationen und deren falsche Einschätzung einen Marktführer in der Softwareindustrie innert kürzester Zeit in die Bedeutungslosigkeit drängen kann. Während also die Beurtei-lung des wirtschaftlichen Erfolgs eines Standard-Softwareunternehmens im höchs-ten Masse in den Zukunftsaussichten liegt, beschäftigt sich die Rechnungslegung traditionell mit der Vergangenheit. Diese ist jedoch bei Standard-Softwareunter-nehmen aufgrund der diskontinuierlichen Entwicklung sehr eingeschränkt für den weiteren Fortgang repräsentativ und kann daher nur begrenzt als Basis für Progno-seentscheidungen dienen.

Um das Ziel einer zukunftsbezogenen Berichterstattung zu erreichen, wird es not-wendig sein, konkrete Aussagen über voraussichtlich eintretende Ereignisse zu ma-chen. Dies führt dazu, dass zu erwartende Entwicklungen oder beabsichtigte Mass-nahmen offen gelegt werden müssen. Besondere Bedeutung besitzt dabei die Ein-schätzung des technologischen Entwicklungspfades und die eigene Positionierung in demselben. Es sind dem Investor also keinesfalls nur geplante quantitative Ziele, sondern vor allem die zugrunde liegenden Annahmen zugänglich zu machen, damit er sich ein eigenes Bild der Angemessenheit der Darstellungen machen kann. Hinzu kommt die Forderung, dass der Eintritt der Vorhersagen gezielt überprüfbar sein soll.

3. Zusammenfassung: Informationsbedürfnisse der Investoren

Die Rechnungslegung hat die Aufgabe, Investoren entscheidungsrelevante Informa-tionen bereitzustellen. Dabei ist festzulegen, welche Informationen in welcher Form zur Verfügung zu stellen sind. Die Beantwortung dieser Fragen ist dabei keine ge-nerelle Aufgabe, sondern ist entscheidend von der Art des Unternehmens abhängig,

Page 80: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL III: ANFORDERUNGEN DER EXTERNEN ANALYSE 62

über das berichtet werden soll. Zu berücksichtigen sind dabei Besonderheiten hin-sichtlich der Geschäftstätigkeit, der Organisation und der Finanzierung des Unter-nehmens, welche spezifische Problembereiche der Rechnungslegung offenbaren. Im Rahmen der im vorherigen Kapitel vorgestellten Überlegungen wurden die folgen-den Bereiche bei der Berichterstattung von Standard-Softwareunternehmen als be-sonders entscheidungsrelevant für den Investor erkannt:

Zukunftsbezogenheit Standard-Software

Anforderungsschwerpunkte an die Berichterstattung von Standard-

Softwareunternehmen

Immaterielle Werte

Umsatzerfassung

Abbildung 12: Anforderungen an die Berichterstattung

Page 81: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 63

Teil IV: Analyse der Rechnungslegung von Standard-Softwareunternehmen

In Abschnitt III 2 wurden die besonderen Schwierigkeiten der Berichterstattung von Standard-Softwareunternehmen hinsichtlich der Erfüllung der Informationsbedürf-nisse von Investoren beleuchtet. In diesem Teil ist nun zu untersuchen, inwiefern die bestehenden Regelungen der Standardsetter diese Besonderheiten von Standard-Softwareunternehmen bereits berücksichtigen. Dabei sind zunächst die relevanten Normen zu identifizieren und dann auf ihre Eignung zur Erfüllung der in Teil III identifizierten Anforderungen der externen Analyse hin zu beurteilen.

1. Relevante Rechnungslegungssysteme

Nach vorherrschender Meinung stellen die IFRS und die US-GAAP die zwei domi-nierenden Systeme der Rechnungslegung dar, insbesondere bei Standard-Software-unternehmen. Dies ist nicht zuletzt darauf zurückzuführen, dass in den typischen Börsensegmenten von Standard-Softwareunternehmen in Europa (z. B. Swiss New Market (SNM), ehemaliger Neuer Markt in Deutschland (NEMAX)147), aber auch in den USA (z. B. NASDAQ) IFRS bzw. US-GAAP für Emittenten vorgeschrieben sind. Im Hinblick auf die prozentuale Verteilung zeigte eine Untersuchung des NEMAX Software-Index in Deutschland aus dem Jahr 2001, dass sich IFRS und US-GAAP die Waage halten: 53 Prozent der Unternehmen wenden die IFRS an, 47 Prozent die US-GAAP.148 Die weltweite Vormachtstellung149 amerikanischer Un-ternehmen im Standard-Softwarebereich mit entsprechender Kotierung in den USA dürfte jedoch global ein deutliches Übergewicht der US-GAAP in der Rechnungs-legung von Standard-Softwareunternehmen begründen.

147 Auf den 1. Januar 2003 wurde eine Neusegmentierung des deutschen Aktienmarkts vorgenommen, infolge dessen das Marktsegment Neuer Markt (NEMAX) abgeschafft wurde.

148 Vgl. Küting et al. (2001), S. 347. 149 Nach Hoch et al. finden sich unter den 10 grössten Softwareunternehmen (nach Umsatz) der Welt im

Softwaremassenmarkt ausschliesslich amerikanische und im Unternehmenssoftwaremarkt 7 amerikani-sche. Vgl. Hoch et al. (2000), S. 27.

Page 82: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 64

1.1. IFRS

Das International Accounting Standards Board (IASB) ist ein privater Zusammen-schluss von Wirtschaftsprüferorganisationen aus verschiedenen Ländern. Die Grün-dung des IASB150 erfolgte 1973, um einen Gegenpol zu der damals stark durch das deutsche Bilanzrecht beeinflussten Entwicklung der europäischen Harmonisie-rungsbestrebungen in der Rechnungslegung zu bilden.151

Das IASB hat sich dabei selbst folgende Ziele gesetzt:

• Formulierung und Veröffentlichung sowie Förderung der weltweiten Akzep-tanz und Einhaltung von Rechnungslegungsgrundsätzen und -normen für die Aufstellung von Jahresabschlüssen

• Verbesserung und Harmonisierung von Rechnungslegungsnormen und -grundsätzen für die Aufstellung von Jahresabschlüssen

Zur Erreichung dieser Ziele hat das IASB ein „Rahmenkonzept“ (conceptional fra-mework) und zahlreiche International Financial Reporting Standards (IFRS)152 he-rausgegeben. Die IFRS regeln einzelne, spezielle Bilanzierungsproblematiken und ähneln somit stark den SFAS der US-amerikanischen Rechnungslegungsvorschrif-ten.

Das Rahmenkonzept (conceptional framework) dient primär dem IASB selbst als konzeptionelle Grundlage für die Entwicklung neuer IFRS. Darüber hinaus kann das Rahmenkonzept zur Interpretation der bereits erlassenen IFRS herangezogen werden, falls Probleme nicht eindeutig geklärt sind. Falls jedoch gewisse IFRS mit dem Rahmenkonzept nicht konform sind, so gehen die einzelnen Standards dem Rahmenkonzept vor.153 Schlussendlich dient das Rahmenkonzept dem Anwender auch als Deduktionsbasis für die Ableitung von Vorschriften für Rechnungsle-

150 Damals noch unter dem alten Namen International Accounting Standards Comittee (IASC), welcher jedoch im Jahre 2001 in International Accounting Standards Board (IASB) geändert wurde.

151 Vgl. von Keitz (1997), S. 173. 152 Im Jahre 2001 wurde die Bezeichnung der Standards von International Accounting Standards (IAS) in

International Financial Reporting Standards (IFRS) geändert. Die bis dahin veröffentlichten Standards werden jedoch weiterhin unter der Bezeichnung IAS geführt, während alle neuen die Bezeichnung IFRS erhalten.

153 Vgl. IASB F.2f.

Page 83: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 65

gungsfragen, welche nicht explizit durch einen IFRS geregelt sind. Allerdings wei-sen die aus dem Rahmenkonzept abgeleiteten Bilanzierungsgrundsätze nur Empfeh-lungscharakter auf.154 Trotzdem unterscheiden sich die IFRS und die US-GAAP an dieser Stelle zentral voneinander. Während die US-GAAP kasuistisch aufgebaut sind, weisen die IFRS mit dem Rahmenkonzept ein prinzipientheoretisches Funda-ment auf.

Das IASB hat keine Möglichkeit, die Einhaltung der IFRS von den Mitgliedslän-dern zu erzwingen. Es besitzt also keine direkten Durchsetzungsmöglichkeiten. Die Mitgliedorganisationen haben sich zwar verpflichtet, die Umsetzung der IFRS in ihren Ländern zu unterstützen, allerdings sind die im IASB vertretenen Organisatio-nen der verschiedenen Mitgliedsländer in der Regel nicht die nationalen Gesetzge-ber. Somit ist die tatsächliche Umsetzung vom Einfluss der Berufsverbände abhän-gig.

1.2. US-GAAP

Die Rechnungslegungsgrundsätze der US-amerikanischen Generally Accepted Ac-counting Principles (US-GAAP) sind über die Grenzen der einzelnen Bundesstaaten hinweg USA-weit anerkannt. Da die US-GAAP von verschiedenen Institutionen entwickelt wurden, existieren sie nicht als kodifiziertes Set von Standards, sondern setzen sich aus verschiedenen Quellen von Anweisungen (statements), Prinzipien (principles) und Richtlinien (guidelines) zusammen.155 Die erlassenen Verlautba-rungen, die kasuistisch einzelne Bilanzierungsprobleme regeln, sind dabei unterein-ander nicht immer konsistent.156 Im Bewusstsein der vorhandenen Kasuistik dieses Systems waren die Organisationen deshalb bestrebt, ein konsistentes System an Rechnungslegungsgrundsätzen zu schaffen. Dies führte schliesslich zu dem aus sechs Statements on Financial Accounting Concepts (SFAC) bestehenden concepti-onal framework des Financial Accounting Standards Board (FASB).157

154 Vgl. IASB F.2f. 155 Vgl. Kieso et al. (2004), S. 9f. und KPMG (2003), S. 2f. 156 Vgl. Schoenfeld (1981), S. 290. 157 Vgl. von Keitz (1997), S. 98.

Page 84: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 66

Von entscheidendem Interesse ist nun, wie und in welcher hierarchischen Abfolge diese zahlreichen Verlautbarungen bei einem Jahresabschluss zur Anwendung kom-men. Es ist zu beachten, dass in den USA erst durch den Sarbanes-Oxley Act of 2002 eine gesetzliche Prüfungspflicht für Unternehmen, deren Wertpapiere bei der SEC registriert sind, eingeführt wurde. Zuvor ergab sich nur aus institutionellen An-forderungen eine Prüfungspflicht: Die Börsenaufsichtsbehörde SEC verlangte von allen börsennotierten Unternehmen158 einen von einem Wirtschaftsprüfer (Certified Public Accountant, CPA) geprüften und testierten Abschluss. Das Fehlen eines mit uneingeschränktem Testat versehenen Abschlusses wurde von Kapitalgebern und sonstigen Interessenten negativ beurteilt, wodurch die meisten Unternehmen bereits vor dem Sarbanes-Oxley Act of 2002 faktisch zur Aufstellung eines Jahresabschlus-ses gezwungen waren.159

Die Frage der zu beachtenden Verlautbarungen bei der Erstellung eines Abschlusses konzentriert sich somit darauf, welche Verlautbarungen in welcher Rangfolge ein Unternehmen anzuwenden hat, damit ihm ein CPA ein uneingeschränktes Testat erteilt. Diese Verlautbarungen werden in summa als GAAP bezeichnet.160

Im Statement on Auditing Standards (SAS) 69 hat das American Institute of Certi-fied Public Accountants (AICPA) den Umfang und die Hierarchie der für eine Tes-taterteilung zu beachtenden GAAP festgelegt. Alle Wirtschaftsprüfer, die Mitglied der AICPA sind, werden dazu verpflichtet, diesen SAS 69 zu beachten. Der in SAS 69 festgelegte Inhalt und die dort angegebene Hierarchie der GAAP für er-werbswirtschaftlich orientierte Unternehmen lassen sich anschaulich mit dem in folgender Abbildung dargestellten „House of GAAP“ verdeutlichen:161

158 Ausgenommen sind diejenigen Unternehmen, die weniger als 500 Aktionäre und weniger als 1 Mio. $ Eigenkapital haben.

159 Vgl. KPMG (2003), S. 2. 160 Vgl. Nikolai/Bazley (1996), S. 6. 161 Vgl. Schreiber (2002), S. 34ff.

Page 85: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 67

“House of GAAP“

APB Opinions

AICPA Industry Audit &

Accounting Guides

AICPA Statements of

Position

FASB Technical Bulletins

FASB Standards and Interpretations

AICPA Accounting

Research Bulletins

FASB Emerging Issues Task Force

AICPA Accounting Interpretations

FASB Implementation Guides (Q&A)

Widely recognized and prevalent

industry practices

AICPA AcSEC Practice Bulletins

Für Sachverhalte auf die SAS 69 und ET Section 203 nicht zutreffen, sind auch andere Literaturquellen wie z. B. SFAC, AICPA Issue Papers, IFRS etc. anwendbar

Abne

hmen

de

Verp

flich

tung

sebe

ne

Category (A)

Category (B)

Category (C)

Category (D)

Other Acc. Literature

Abbildung 13: House of GAAP162

Zu den US-GAAP im engeren Sinn (Category A) werden neben den Standards (SFAS) und Interpretations (FIN) des FASB die Accounting Principles Board Opi-nions (APB) und die Accounting Research Bulletins (ARB) des AICPA gezählt. Alle diese Vorschriften verpflichten die Unternehmen direkt, das heisst sie sind von den Unternehmen unbedingt zu befolgen und eine Missachtung muss gegebenen-falls vom Abschlussprüfer sanktioniert werden.

Hinzu kommen die US-GAAP im weiteren Sinn, welche wie folgt gebildet werden:

• Empfehlungen der Fachgremien der AICPA und des Standardsetters in Be-zug auf die Rechnungslegung in Form eines Exposure Drafts zur öffentli-chen Kommentierung. Sie haben faktisch einen ähnlichen Stellenwert wie die verpflichtenden Vorschriften; dazu zählen die Industry Audit and Ac-counting Guides des AICPA, die Statements of Position (SOP) des AICPA und die Technical Bulletins des FASB (Category B).

162 KPMG (2003), S. 3.

Page 86: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 68

• Empfehlungen der Fachgremien der AICPA und des Standardsetters in Be-zug auf die Rechnungslegung ohne öffentliche Kommentierung. Ihre Bedeu-tung erlangen sie hauptsächlich durch die Anerkennung vom FASB oder der SEC; zu ihnen zählen die AICPA Accounting Standards Executive Comittee (AcSEC) Practice Bulletins und die FASB Emerging Issues Task Force (EITF) Consensus Positions (Category C).

• Vorherrschende Bilanzierungspraxis (Prevalent Industry Practice) einzelner Branchen und die Branchenrichtlinien der AICPA (AICPA Accounting In-terpretations), sowie die Umsetzungsrichtlinien (Implementation Guides) (Category D).

• Auf konzeptioneller Ebene die Issues Papers des AICPA, die Statements of Financial Accounting Concepts (SFAC) des FASB, die Statements des APB sowie mögliche weitere Verlautbarungen des Berufsstands (Other Accoun-ting Literature).

• Für Unternehmen, die bei der SEC registriert sind, kommen ausserdem die Financial Reporting Releases (FRR) und die Staff Accounting Bulletins (SAB) der SEC zur Anwendung, welche die gleiche Bedeutung wie die US-GAAP der Category A haben.163

Der Verbindlichkeitsgrad der Vorschriften in Category A ist dabei am höchsten und nimmt kontinuierlich über die Gruppen B, C und D bis hin zur Category Other Ac-counting Literature ab. Somit ist bei einem Bilanzierungsproblem sicherzustellen, dass Veröffentlichungen aus der Category A gegenüber denjenigen der Category B (bzw. B gegenüber C und C gegenüber D) Vorrang erhalten. Falls sich Vorschriften aus unterschiedlichen Kategorien widersprechen, so ist generell der Vorschrift aus der übergeordneten Gruppe Folge zu leisten. Gelingt jedoch der Beweis, dass durch die Anwendung einer Verlautbarung aus einer niedrigeren Rangstufe ein bestimmter Sachverhalt „besser“ abgebildet wird, so darf diese Vorschrift gegenüber der höher-

163 Vgl. KPMG (2003), S. 3f.

Page 87: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 69

rangigen vorgezogen werden. Wie die Beurteilung vorzunehmen ist, welche Vor-schrift einen Geschäftsvorfall „besser“ beschreibt, ist jedoch nicht konkretisiert.164

2. Beurteilung der Rechnungslegungsvorschriften

2.1. Einleitung

Das Ziel dieses Kapitels ist es, sowohl die Rechnungslegungsstandards als auch die aktuelle Rechnungslegungspraxis von Standard-Softwareunternehmen aus der Per-spektive der externen Analyse zu vergleichen und zu evaluieren. Der Fokus liegt dabei auf den in Abschnitt III 2 als Problembereiche der Rechnungslegung von Standard-Softwareunternehmen identifizierten Kategorien: Umsatzerfassung, Stan-dard-Software, Immaterielle Werte und zukunftsbezogene Berichterstattung.

Jedes dieser Themengebiete wird in einem eigenen Unterkapitel behandelt. Dabei wird jeweils die Bilanzierung und Bewertung nach den Vorschriften von IFRS und US-GAAP dargestellt, welche mit Beispielen aus der Rechnungslegungspraxis un-terlegt werden. Danach wird die aktuelle Rechnungslegung an den Anforderungen der externen Analyse bemessen. Das Ziel ist dabei, Verbesserungspotenziale der Rechnungslegung für den Entscheidungsnutzen externer Investoren zu identifizie-ren. Es muss jedoch einschränkend angemerkt werden, dass diese Schlussfolgerun-gen nicht detailliert, sondern nur in Form allgemein gehaltener Aussagen vorge-nommen werden können.

2.2. Berichterstattung zur Umsatzerfassung

Die Berichterstattung zur Umsatzerfassung beschränkt sich bei IFRS und US-GAAP auf die beiden Themenbereiche Darstellung von Umsätzen und Regelungen zur Umsatzrealisierung. Die beiden Rechnungslegungssysteme unterscheiden sich dabei kaum in konzeptioneller Hinsicht, sondern vor allem durch eine unterschiedli-che Regelungstiefe. Die IFRS regeln die Umsatzerfassung hauptsächlich durch den Standard IAS 18 Erträge und beschränken sich dabei auf Grundsatzregelungen. Die

164 Vgl. AICPA (2000), AU Section 411.07.

Page 88: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 70

US-GAAP weisen hingegen detaillierte Branchenregelungen165 für die Softwarein-dustrie auf, die jedoch nicht im Widerspruch zu den Vorgaben der IFRS stehen. Vielmehr können die Detailregelungen der US-GAAP in einem gewissen Masse eine ergänzende Funktion zu den Grundsatzregelungen der IFRS wahrnehmen.166 Entsprechend erfolgt die Analyse nicht durch ein Gegenüberstellen der Einzelrege-lungen der beiden Rechnungslegungssysteme, sondern folgt inhaltlichen Kriterien, welche durch die Unterkapitel Definition, Realisierung, Bewertung und Offenlegung abgedeckt werden.

2.2.1.

Definition

Umsatzerträge werden sowohl von den IFRS als auch von den US-GAAP definiert als (Brutto-)Zuflüsse oder Erhöhungen der Vermögenswerte und/oder (Brutto-)-Abnahme der Verpflichtungen, welche durch die gewöhnliche bzw. typische Ge-schäftstätigkeit des Unternehmens bedingt sind (und nicht auf Einlagen von An-teilseignern beruhen).167 Die Umsatzdefinition geht somit von einer Veränderung der Vermögenswerte aus und beruht daher auf dem assets-and-liabilities Ansatz.168

Operative Erträge, welche auf nicht-typischen Geschäftstätigkeiten beruhen, werden als sonstige betriebliche Erträge und üblicherweise auf Nettobasis erfasst.169 Darun-ter fallen Erträge aus untypischen Geschäftsvorfällen (z. B. Verkauf von Anlage-vermögen) oder Erträge aus Wertsteigerungen von Aktiven bzw. Wertminderung von Passiven, die nicht auf einem Austauschprozess basieren (z. B. Auflösung von Rückstellungen). Zusätzlich erfolgt eine Abgrenzung von Finanzerträgen und aus-serordentlichen Erträgen, welche für in hohem Masse ungewöhnliche und selten anfallende Beträge gelten.

165 Bei den Branchenregelungen für die Softwareindustrie handelt es sich um den SOP 97-2 Software Re-venue Recognition und die Ergänzungsregelungen SOP 98-4 und SOP 98-9 des AICPA. Wesentliche Teile dieser Regelungen wurden später mit dem SAB 101 (aktualisiert durch SAB 104) verallgemeinert und auf andere Branchen übertragen.

166 Vgl. IAS 1.22c. 167 Vgl. IAS 18.7 und SFAC 6.78. 168 Vgl. zu Ausführungen zum assets-and-liabilities Ansatz beispielsweise FASB (2002), S. 3. 169 Vgl. Delaney et al. (2004), S. 66.

Page 89: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 71

Aufgrund der klar definierten operativen Tätigkeit von Standard-Software-unternehmen ist in der Regel die Klassifikation von Umsätzen unproblematisch.

2.2.2.

Realisierung

Die Umsatzrealisierung, also die Bestimmung des Erfassungszeitpunktes der Um-satzerträge, ist von zentraler Bedeutung für die Abbildung von Umsatzerträgen im Jahresabschluss. Mit der Festlegung des Erfassungszeitpunktes von Umsatzerträgen werden Erträge einer bestimmten zeitlichen Periode zugeordnet und über das mat-ching principle sachlich und zeitlich entsprechenden Aufwendungen gegenüberge-stellt. Damit liefert die Umsatzrealisation einen wichtigen Beitrag für die perioden-gerechte Erfolgsermittlung (accrual principle). Das accrual principle postuliert eine Erfassung von Geschäftsvorfällen zum Zeitpunkt der wirtschaftlichen Verursa-chung, unabhängig vom tatsächlichen Zahlungsfluss. Die periodengerechte Erfolgs-ermittlung soll den Investoren eine bessere Informationsbasis liefern als die reine Betrachtung von Zahlungsflüssen, welche einer gewissen Willkürlichkeit unterlie-gen.170

Das Realisationsprinzip der Standardsetter beruht auf der Identifikation eines Zeit-punktes im Umsatzprozess, bei welchem die Unsicherheit hinsichtlich des zukünfti-gen Nutzenzuflusses auf ein akzeptables Niveau abgesenkt ist.171 Es basiert auf der Vorstellung, dass ein auslösendes Ereignis bestimmt werden kann, das die einmali-ge Realisierung von Umsatz und Gewinn in voller Höhe auslöst, wenn die wesentli-chen Geschäftsrisiken genügend reduziert sind und daher ein Zahlungseingang rela-tiv sicher ist. Dieser Grundsatz entspricht jedoch nur einer Näherungslösung an die Realität, denn es findet somit keine sukzessive Realisierung in Übereinstimmung mit der im Umsatzprozess erzielten Wertschöpfung statt,172 obwohl dies unter öko-nomischen Gesichtspunkten und hinsichtlich der Forderung der relevance sinnvoll wäre. Der Vorzug der Zeitpunktrealisierung des Umsatzes gegenüber einer kontinu-ierlichen Realisierungslösung wird mit deren Abgrenzungsproblematik begrün-

170 Vgl. SFAC 1.44. Nach IFRS folgt dies im Gesamtkontext von F.69. 171 Vgl. Chasteen et al. (1995), S. 310. 172 In der Realität entwickelt sich der Wert eines Gutes kontinuierlich im Erstellungsprozess und nicht zu

irgendeinem definierten Zeitpunkt. Vgl. dazu z. B. Pilhofer (2002), S. 142.

Page 90: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 72

det.173 So wäre der Ermessensspielraum bei Zwischengewinnen aufgrund von schwer abgrenzbaren Zeitpunkten und bei Zwischenprodukten wegen illiquiden Märkten sehr gross und damit die verifiability nicht gewährleistet.

Die Voraussetzungen für eine hinreichende Unsicherheitsreduktion eines Ereignis-ses werden von den Standardsettern durch die folgenden zwei Kriterien genauer bestimmt:174 Die Erträge müssen (1) hinreichend sicher bestimmt bzw. bestimmbar sein175 und (2) hinreichend wahrscheinlich dem Unternehmen zufliessen. Für das erste Kriterium gilt, dass grundsätzlich die Höhe der Erträge mit Abschluss einer Leistungsvereinbarung hinreichend sicher bestimmt ist (realized). Sind jedoch Zweifel an der Einbringlichkeit der Leistung gegeben, so muss die Umsatzrealisati-on bis zu deren Beseitigung zurückgestellt werden. Die hinreichende Wahrschein-lichkeit des Nutzenzuflusses ist hingegen dann gegeben, wenn die zugesicherte Leistung im Wesentlichen erbracht worden ist (earned). Zur Bestimmung der We-sentlichkeit wird üblicherweise auf den Übergang von Nutzen und Gefahren auf den Kunden abgestellt, was häufig mit der Lieferung des Gutes stattfindet.176

Die vorgestellten Realisationsprinzipien von IFRS und US-GAAP zeigen jedoch Schwächen bei der Erfassung von den in der Standard-Softwarebranche weit ver-breiteten Vereinbarungen mit mehreren Komponenten. Durch diese Vereinbarungen wird eine Bündelung von Produkten und Dienstleistungen angestrebt, um Kunden integrierte Lösungen anbieten zu können. Diese Konstrukte zeichnen sich generell durch eine Hauptleistung (z. B. Kauf eines Gutes) und mindestens eine Nebenleis-tung (z. B. Kauf einer Dienstleistung) aus.177 Die Problematik bei der Umsatzreali-sierung von Vereinbarungen mit mehreren Komponenten lässt sich am alltäglichen Verkauf einer Standard-Software mit entsprechender Implementierungsverpflich-tung des Verkäufers aufzeigen. Dabei ergeben sich je nach Art der Vereinbarung zwei Realisierungsalternativen:178

173 Vgl. Delaney et al. (2004), S. 62f. 174 Vgl. SFAC 5.83 sowie ähnlich IAS 18.14, IAS 18.20 und IAS 18.29. 175 Die US-GAAP verwenden dazu die Begriffe being realized or realizable, was mit sicher bestimmt bzw.

bestimmbar zu übersetzen ist (und daher nicht mit „realisiert“ gleichzusetzen ist). Vgl. SFAC 6.143). 176 Vgl. IAS 18.14a) und SFAC 5.84a) sowie die darauf folgenden Abschnitte. 177 Vgl. Küting et al. (2001), S. 306. 178 Vgl. Pilhofer (2002), S. 367ff.

Page 91: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 73

Handelt es sich erstens bei der Implementierung um eine unwesentliche Nebenleis-tung, so ist der Umsatz zum Zeitpunkt der Lieferung (Normalfall) in voller Höhe zu realisieren und es ist lediglich eine Rückstellung für die noch zu erbringenden Imp-lementierungsleistungen erforderlich (Konzept der Kostenabgrenzung). Unter die Alternative 1 fällt typischerweise der Verkauf fixer Standard-Software mit der Ser-viceleistung der Installation der Standard-Software. Zum Zweiten kann die Imple-mentierung eine wesentliche Nebenleistung darstellen. Dann ist der auf diese Dienstleistung entfallende Umsatzanteil einschliesslich eines Gewinnanteils zum Zeitpunkt der Lieferung abzugrenzen und über die I Implementierungsdauer zu rea-lisieren (Konzept der Umsatzaufgliederung).179 Die Alternative 2 deckt üblicher-weise den Verkauf variabler Standard-Software mit der Dienstleistung des Custo-mizing ab. Folgende Fallstudie soll die unterschiedlichen Auswirkungen der beiden Alternativen in der Erfolgsrechnung aufzeigen:180

Fallstudie 11

Ein Standard-Softwareunternehmen verkauft einem Kunden eine Standard-Software zum Fixpreis von 1000 und liefert sie am 01.12.2004. Die Implementierung ist als Serviceleistung (Marktpreis: 100) im Preis inbegriffen und soll die produktive Ar-beit mit der Software ermöglichen. Sie wird Anfang 2005 durchgeführt und abge-schlossen. Die Herstellungskosten für die Standard-Software betragen 50 und die Installation kostet 25.181

Alternative 1: Implementierung als unwesentliche Nebenleistung (Konzept der Kostenabgrenzung)

Erfolgsrechnung 2004 (1.1. - 31.12.) Erfolgsrechnung 2005 (1.1. - 31.12.)

Herstellungskosten 50 Umsatz 1000

Rückstellung 25

Gewinn 925 Gewinn 0

179 Vgl. IAS 18.A11 zu Erträgen aus Dienstleistungen, die im Verkaufspreis von Gütern enthalten sind und generell SOP 97-2.63ff. zu Softwarevereinbarungen mit Dienstleistungskomponenten.

180 Angepasste Fallstudie basierend auf Küting et al. (2001), S. 307f. 181 Die grössten Kostenträger bei Standard-Softwareunternehmen sind F&E und Marketing, welche jedoch

nicht berücksichtigt sind, um die Komplexität der Fallstudie zu reduzieren.

Page 92: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 74

Alternative 2: Implementierung als wesentliche Nebenleistung (Konzept der Um-satzaufgliederung)

Erfolgsrechnung 2004 (1.1. - 31.12.) Erfolgsrechnung 2005 (1.1. - 31.12.)

Herstellungskosten 50 Umsatz 900 Herstellungskosten 25 Umsatz 100

Gewinn 850 Gewinn 75

Fallstudie 11: Realisationsalternativen bei Standard-Software-Vereinbarungen

Die Fallstudie zeigt, dass die Art der vereinbarten Implementierungsleistungen ei-nen wesentlichen Einfluss auf die Umsatzrealisation hat. Während die Alternative 1 der Behandlung eines Vertrags mit nur einer Komponente entspricht, weil der Ver-trag als eine buchhalterische Einheit betrachtet wird, handelt es sich bei der Alterna-tive 2 um einen typischen Fall einer Vereinbarung mit mehreren Komponenten, da die Vereinbarung buchhalterisch in einzelne Vertragskomponenten zerlegt wird. Aus Sicht der Rechnungslegung sind deshalb zwei grundsätzlich unterschiedliche Arten der Umsatzrealisierung zu differenzieren: Standard-Software-Vereinbarungen mit einer Komponente und Standard-Software-Vereinbarungen mit mehreren Kom-ponenten.

2.2.2.1. Standard-Software-Vereinbarungen mit einer Komponente

Unter Standard-Software-Vereinbarungen mit einer Komponente fallen Lizenzver-träge, die auf ein einzelnes Standard-Softwareprodukt182 ohne weitere (wesentliche) Verpflichtungen des Anbieters beschränkt sind. Dabei wird die rechtliche Form des Lizenzvertrags nur deswegen einer Kaufvereinbarung vorgezogen, um die Duplika-tion oder Weitergabe der Standard-Software vertraglich zu verbieten.183 Doch han-delt es sich in solchen Fällen unabhängig von der rechtlichen Form um einen Ver-äusserungsakt, da Nutzungsrechte an der Standard-Software gegen eine fixe Vergü-tung im Rahmen einer nicht kündbaren Vereinbarung für eine unbeschränkte Nut-

182 In der Regel handelt es sich dabei um fixe Standard-Software, da sich diese im Unterschied zu variabler Standard-Software dadurch auszeichnet, dass in keiner Weise wesentliche kundenspezifische Anpas-sungen der Software vorgenommen werden.

183 Vgl. AICPA (2001), S. 37.

Page 93: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 75

zungsdauer übertragen werden und dem Lizenzgeber keine Verpflichtungen verbleiben.184

Nach IFRS kommen in diesen Fällen die allgemeinen Grundsätze der Umsatzreali-sierung durch den Verkauf von Gütern nach IAS 18 Erträge zur Geltung.185 Liegt jedoch eine wesentliche Einschränkung der Nutzungsrechte vor oder existieren Rechte zur Kündigung innerhalb der Laufzeit, so handelt es sich nach wirtschaftli-cher Betrachtungsweise um einen Nutzungsüberlassungsvertrag, welcher grundsätz-lich linear über die Vertragslaufzeit zu erfassen ist.186

Die US-GAAP wählen einen anderen Ansatz als die IFRS und weisen mit dem SOP 97-2 Software Revenue Recognition eine umfangreiche Spezialregelung für Soft-ware-Vereinbarungen auf.187 Die Umsatzerfassung der Lizenzierung eines Stan-dard-Softwareprodukts ohne zusätzliche Leistungskomponenten bestimmt sich nach SOP 97-2.8, welches folgende vier Ansatzkriterien enthält:

• Es existieren Beweise, dass eine Vereinbarung besteht,

• die Lieferung ist erfolgt,

• der Verkaufspreis ist fest oder bestimmbar,

• der Zahlungseingang ist wahrscheinlich.

2.2.2.2. Standard-Software-Vereinbarungen mit mehreren Komponenten

Sehr oft umfassen Standard-Software-Vereinbarungen neben dem Nutzungsrecht der Standard-Software weitere Elemente wie postvertragliche Supportleistungen (postcontract customer support, PCS), das Recht auf (zukünftige) Softwareentwick-lungen (wie Updates oder Upgrades) oder weitere Dienstleistungen wie Ausbildung und Installation.

184 Vgl. IAS 18.A20 sowie SOP 97-2.94. 185 Vgl. zur Einordnung von Software ausführlich IAS 18.A20. 186 Vgl. IAS 18.A20. Wobei die Erfüllung der übrigen Ansatzkriterien wie der hinreichenden Wahrschein-

lichkeit des zukünftigen wirtschaftlichen Nutzens und die verlässliche Bemessung der Erträge voraus-gesetzt werden. Vgl. IAS 18.29.

187 Die Änderungen von SOP 97-2 durch SOP 98-9 Modification of SOP 97-2, “Software Revenue Re-cognition“ with Respect to Certain Transactions werden bei der Analyse mitberücksichtigt.

Page 94: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 76

Unter IFRS werden solche Konstellationen weiterhin im Rahmen der allgemeinen Bestimmungen von IAS 18 Erträge behandelt. Im Falle von mehreren Komponen-ten soll die Vereinbarung nach dem Grundsatz der wirtschaftlichen Betrachtungs-weise in separat identifizierbare Elemente unterteilt bzw. zusammengefasst werden. Diese sind dann entsprechend ihrer Natur den von IAS 18 Erträge definierten drei Ansatzkriterien Verkauf von Gütern, Erbringung von Dienstleistungen und Nutzung von Vermögenswerten des Unternehmens durch Dritte zuzuordnen und entspre-chend zu behandeln.188 Nachfolgend erbrachte Dienstleistungen sind einschliesslich eines Gewinnanteils abzugrenzen und über die Laufzeit der Leistungserbringung als Umsatz zu erfassen.189 Folgendes Beispiel zeigt exemplarisch das Vorgehen bei der Umsatzerfassung nach IFRS bei einer Standard-Software-Vereinbarung mit mehre-ren Komponenten auf:

Fallstudie 12

Unternehmen A verkauft eine Lizenz für eine Standard-Software mit einer Service-garantie an einen Kunden. Der Verkaufspreis beinhaltet dabei einen separat identifi-zierbaren Anteil, welcher der Servicegarantie zugeordnet werden kann. In einem solchen Fall verlangt IAS 18, dass der Verkaufspreis der Standard-Software in die zwei separierbaren Komponenten Veräusserung der Software und Erbringung der Servicedienstleistung aufgeteilt und jede nach dem entsprechenden Ansatzkriterium angesetzt werden soll. Demnach soll derjenige Anteil des Verkaufspreises, welcher der Servicegarantie entspricht, zurückgestellt und über den Zeitraum, welche die Servicegarantie umfasst, realisiert werden. Der übrige Verkaufspreis soll unverzüg-lich realisiert werden falls die Ansatzkriterien190 für die Umsatzrealisierung durch den Verkauf von Gütern191 befriedigt sind.

Fallstudie 12: Standard-Softwarelizenzverkauf bei Unternehmen A192

188 Vgl. ausführlich zu den einzelnen Kategorien IAS 18.14, IAS 18.20 und IAS 18.29. 189 Vgl. IAS 18.13 und IAS 18.A11. 190 Vgl. IAS 18.14. 191 Software-Nutzungsrechte gegen fixe Vergütung, die dem Lizenznehmer eine unbeschränkte Nutzung

gewährt und keine weiteren Verpflichtungen des Lizenzgebers nach sich zieht, ist unabhängig von der rechtlichen Form als Veräusserungsvorgang zu bewerten. Vgl. IAS 18.A20.

192 In Anlehnung an Epstein/Mirza (2002), S. 237.

Page 95: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 77

Die generellen Rechnungslegungsvorschriften von IFRS führen dazu, dass bei komplexen und speziellen Fällen in der Praxis immer wieder Konstellationen auf-treten, denen die Standards zu wenig Rechnung tragen wie folgendes Beispiel auf-zeigt:

Fallstudie 13

Esmertec ist ein Schweizer Standard-Softwareunternehmen, welches seit Ende Sep-tember 2005 an der Schweizer Börse kotiert ist und nach IFRS Bericht erstattet. Das Unternehmen entwickelt insbesondere Java-Softwarelösungen für Mobiltelefone, welche hauptsächlich direkt an Mobiltelefonhersteller lizenziert werden. Esmertec verwendet dabei ein spezielles Verrechnungsmodell mit dem Ziel, die Kunden lang-fristig zu binden. So verkauft das Unternehmen volumenbasierte Softwarelizenzen für einzelne Modelllinien an die Mobiltelefon-Hersteller und realisiert den gesamten Umsatz aus dem Lizenzabkommen bei der Lieferung der so genannten master copy an den Kunden, was typischerweise drei bis sechs Monate nach dem Vertragsab-schluss erfolgt. Die Hersteller liefern ihre Modelle mit der Software von Esmertec jedoch häufig viel später aus und müssen die Lizenzgebühren erst pro rata der ver-kauften Mobiltelefone bezahlen.193 Im schlechtesten Fall laufen daher Debitoren-rückstände von zwei bis drei Jahren auf bis der Lizenzvertrag ausläuft und die ge-samte Zahlung fällig wird. Der rasche technologische Wandel in der Branche kann jedoch dazu führen, dass Mobiltelefone zum Zeitpunkt ihrer Lancierung nicht mehr den Marktbedürfnissen entsprechen und die Verkaufszahlen die Erwartungen nicht erfüllen. Kleine Hersteller sind deshalb oft nicht bereit, eine Art Straflizenz für Ge-räte zu zahlen, die nie produziert wurden. Entsprechend wurde das Verrechnungs-modell schon im Vorfeld des Börsenganges kritisiert und seine Schwächen durch die im Januar 2006 angekündigten Debitorenverluste von 7.9 Mio. $ (entspricht 20% des Umsatzes) bestätigt.194

Fallstudie 13: Umsatzrealisierung bei Esmertec

Nach IFRS gibt es keine Vorschriften, welche eine sofortige Umsatzerfassung bei Lizenzvereinbarungen mit ausserordentlich langen Debitorenfristen verbieten. Im

193 Vgl. o.V. (2005d), S. 11. 194 Vgl. Hebeisen (2006), S. 23.

Page 96: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 78

Gegensatz dazu ist nach US-GAAP dieser Fall in SOP 97-2.28 eindeutig geregelt, indem die Lizenzgebühr als nicht fixiert bzw. nicht bestimmbar betrachtet werden muss, falls die Zahlung eines signifikanten Anteils der Lizenzgebühr erst am Ende der Lizenzdauer oder nach mehr als zwölf Monaten nach der Lieferung erfolgen muss.

Nach US-GAAP werden Vereinbarungen, die dem in Fallstudie 12 erläuterten Sach-verhalt entsprechen als Mehrkomponentenverträge (multiple element arrangements) bezeichnet und im Rahmen von SOP 97-2 ausführlich behandelt. Bei Erfüllung der vier Ansatzkriterien von SOP 97-2.8 ist der Kaufpreis grundsätzlich auf die einzel-nen Komponenten der Standard-Software-Vereinbarung aufzuteilen und jeweils getrennt als Umsatz zu erfassen. Dabei ist wie bei den IFRS auf die wirtschaftliche Betrachtungsweise abzustellen, welche unter Umständen auch eine Zusammenfas-sung vertraglich getrennt vereinbarter Leistungen bedingen kann. Standard-Soft-ware-Vereinbarungen unterliegen dem SOP 97-2 falls folgende Bedingungen erfüllt sind:

• Die Standard-Softwarekomponenten dürfen nicht nebensächlich (incidental), sondern müssen zentraler Bestandteil der Vereinbarung sein,195 und

• die Vereinbarung darf keine wesentliche196 Neuentwicklung, Veränderung oder Anpassung (significant production, modification, or customization) der Standard-Software vorsehen.197

195 Vgl. SOP 97-2.2. 196 Der Begriff „wesentlich“ wird in der Literatur unterschiedlich ausgelegt. So existieren quantitative

Ansätze, welche Barrierewerte verwenden, wie z. B. dass die anpassungsbezogenen Arbeiten mehr als 20% am Gesamtumsatz ausmachen müssen. Qualitative Ansätze sehen einen engen funktionalen Zu-sammenhang zwischen Softwareverkauf und Modifikation der Software als Hinweis für einen Vertrag mit Fertigungscharakter. Vgl. Yates (1997), S. 16.

197 Vgl. SOP 97-2.7. Bei einer wesentlichen Neuentwicklung, Veränderung oder Anpassung der Software muss die Vereinbarung als Vertrag mit Fertigungscharakter nach ARB 45 Long-Term Construction-Type Contracts und SOP 81-1 Accounting for Performance of Construction-Type and Certain Produc-tion-Type Contracts behandelt werden. Software, welche die Anforderungen von SOP 97-2 nicht erfüllt, weist Merkmale von Individualsoftware auf und fällt deshalb definitionsgemäss nicht in den Themenbe-reich dieser Dissertation.

Page 97: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 79

Standard-Software-Vereinbarungen mit mehreren Komponenten beinhalten neben der Hauptkomponente – dem Standard-Softwareprodukt – Nebenkomponenten, welche nach SOP 97-2 in folgende drei Kategorien unterteilt werden:

Zusätzliche Softwarekomponenten(additional software deliverables)

Allgemeine Dienstleistungen (ausser PCS)

Postvertragliche Supportleistungen (PCS)

• Leistungen wie Telefonsupport und Fehlerbehebung

• Nicht spezifizierte Upgrades / Erweiterungen

• Installation • Training • Beratung • usw.

• Zusätzliche Softwareprodukte • Spezifizierte Upgrades /

Erweiterungen

Abbildung 14: Kategorien von Nebenkomponenten nach SOP 97-2

Da für jede dieser Kategorien voneinander im Detail abweichende Rechnungsle-gungsvorschriften gelten, ist eine exakte Zuordnung der einzelnen Komponenten wichtig. So werden beispielsweise Verpflichtungen zu Softwareaktualisierungen und -erweiterungen mit genau definierten Funktionalitäten als spezifizierte Upgra-des/Erweiterungen (specified upgrades/enhancements) behandelt und von nicht spe-zifizierten Upgrades/Erweiterungen (unspecified upgrades/enhancements) unter-schieden, welche nur bei Verfügbarkeit (when-and-if-available) dem Kunden gelie-fert werden.198

Bei der Umsatzrealisierung von Vereinbarungen mit mehreren Komponenten stellt sich die zentrale Frage, ob der Umsatz der einzelnen Komponenten im Gesamtkon-text der Vereinbarung oder separat zu erfassen ist. Das SOP 97-2 stellt folgende Kriterien zur Entscheidungsfindung auf, ob eine separate Umsatzerfassung für Ein-zelkomponenten möglich ist:

• Die Komponenten dürfen nicht von wesentlicher funktionaler Bedeutung (essential-to-the-functionality) für die Vereinbarung sein, so dass der An-wender auch ohne diese Komponenten den vollen Nutzen aus den anderen Komponenten ziehen kann.199 Handelt es sich bei diesen Komponenten um Dienstleistungen, so ist folgendes Indikatorenschema zur Beurteilung der Wesentlichkeit hinzuzuziehen:200

198 Vgl. SOP 97-2.36 und SOP 97-2.56. 199 Vgl. SOP 97-2.13. 200 Vgl. SOP 97-2.70 und SOP 97-2.71.

Page 98: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 80

Keine Wesentlichkeit der Dienstleistungen für die Funktionalität anderer Elemente ist indiziert, falls…

Die Wesentlichkeit der Dienstleistungen für die Funktionalität anderer Elemente ist indiziert, falls…

• der Bezug gleichwertiger Dienstleistungen von einem Drittanbieter möglich ist, oder

• die Dienstleistungen kein signifikantes Risiko oder Einmaligkeit mit sich bringen, oder

• der Softwareanbieter über Erfahrung in der Erbringung der Dienstleistungen verfügt, oder

• der Anbieter hauptsächlich Dienstleistungen für die Implementation anbietet, oder

• die Käuferseite an der Erbringung der Dienst-leistungen mitwirkt.

• es sich um keine Standard-Software handelt, oder

• wesentliche Änderungen der Software-Funktionalität vorgenommen wird, oder

• die Nutzung der Standard-Software eine komplexe Schnittstellenprogrammierung vor-aussetzt, oder

• die Zahlungen für die Software auf den Fort-schrittsgrad der Dienstleistungen abgestimmt sind, oder

• Meilensteine oder kundenspezifische Abnah-mekriterien die Realisierbarkeit der Software-lizenzgebühren beeinflussen.

Abbildung 15: Indikatoren zur Wesentlichkeit von Dienstleistungen

• Auch bei Nichtlieferung ausstehender Elemente der Vereinbarung muss der Umsatzanteil der bereits gelieferten Komponenten nicht zurückerstattet oder teilweise erlassen werden.

• Eine Aufteilung des Gesamtumsatzes auf die einzelnen Komponenten muss möglich sein. Diese richtet sich nach dem so genannten verkäufer-spezifischen fairen Wert (vendor-specific objective evidence of fair value - VSOE) 201 der Komponenten.

Werden diese Anforderungen nicht erfüllt, so ist eine separate Umsatzerfassung nicht möglich und die Umsatzrealisation muss zurückgestellt werden bis alle aus-stehenden Komponenten geliefert bzw. die Dienstleistungen erbracht wurden. Eine Ausnahme dazu bilden Verträge mit PCS-Komponenten, welche unter bestimmten Voraussetzungen202 nach dem Konzept der Kostenabgrenzung erfasst und deren Gesamtwert bereits bei Lizenzvergabe voll realisiert werden kann.

Nach SOP 97-2 muss bei Vereinbarungen mit mehreren Komponenten der gesamte vereinbarte Zahlungsbetrag nach dem VSOE auf die einzelnen Elemente verteilt

201 Siehe dazu die Erläuterung des VSOE in diesem Unterkapitel. 202 Vgl. SOP 97-2.59 für die ausführlichen Bestimmungen zu den Voraussetzungen.

Page 99: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 81

werden – unabhängig davon, ob in dieser Vereinbarung den einzelnen Elementen ein separater Preis zugeordnet wurde.203

Der VSOE ist folgendermassen bestimmt:204

• Marktpreis bei separater Veräusserung des gleichen Elements oder

• der durch das Management bestimmte Preis, zu dem die Markteinführung ei-nes bisher nicht separat verkauften Elements wahrscheinlich erscheint.

Derjenige Umsatzanteil, der den nicht gelieferten Komponenten zugeordnet wird, kann im Nachhinein nicht abgeändert werden. Davon ausgenommen ist der Fall, dass der Betrag, der dem nicht gelieferten Element zugeordnet ist, dem Unterneh-men wahrscheinlich einen Verlust hinsichtlich dieses Elements verursachen würde. Ein solcher Verlust muss unverzüglich verbucht werden.205 Wird auf der Gesamt-summe einer Vereinbarung ein Rabatt gegenüber der Summe der VSOE der einzel-nen Komponenten gewährt, so muss der Preisnachlass proportional zu den VSOE der Vertragselemente auf diese aufgeteilt werden. Ausgeschlossen von einer sol-chen Rabattzuteilung sind jedoch Upgraderechte und noch nicht ausgelieferte Ele-mente, falls die residuale Methode206 zur Anwendung kommt.207

Der VSOE wird Wertansätzen, die auf einer vertraglich vorgenommenen Preisallo-kation oder auf Wettbewerbspreisen beruhen aus folgenden Gründen vorgezogen: Nach AcSEC wäre bei vertraglich festgelegten Preisen keine Übereinstimmung mit dem fair value208 gegeben, während auf Branchendurchschnitten oder Konkurrenz-analysen beruhende Wettbewerbspreise den Besonderheiten des Anbieters zu wenig Rechnung tragen würden.209

203 Vgl. SOP 97-2.99 und Keller et al. (1999), S. 62. 204 Vgl. SOP 97-2.10. 205 Vgl. Delaney et al. (2004), S. 997. 206 Siehe dazu die Erläuterung der residualen Methode im weiteren Verlauf dieses Unterkapitels. 207 Vgl. SOP 97-2.11 und SOP 98-9.6a. 208 Der Begriff fair value wird synonym zu den Begriffen fairer Wert, (beizulegender) Zeitwert und

Marktwert bzw. Markpreis verwendet. Er ist definiert als der Betrag, zu welchem ein Vermögenswert oder eine Verbindlichkeit zwischen vertragswilligen, informierten und voneinander unabhängigen Par-teien getauscht bzw. beglichen werden könnte. Vgl. zur Definition z. B. IAS 18.7.

209 Vgl. dazu die Ausführungen in SOP 97-2.99f.

Page 100: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 82

Falls in Ausnahmefällen ein VSOE für alle ausstehenden, aber nicht für die geliefer-ten Komponenten nachgewiesen werden kann und alle anderen Ansatzkriterien er-füllt sind, so tritt die ergänzende Regelung SOP 98-9 Modification of SOP 97-2 with Respect to Certain Transactions in Kraft. Sie bestimmt, dass in diesen Fällen die neu definierte residuale Methode (residual method) für die Allokation des Ver-kaufspreises angewandt werden muss. Dies resultiert in einer Verzögerung der Um-satzrealisation für die nicht gelieferten Vertragselemente zum aggregierten VSOE (welche später bei der Lieferung verbucht werden), während der zur Gesamtvergü-tung resultierende Differenzbetrag unmittelbar realisiert wird.210 Die residuale Me-thode ermöglicht es insbesondere, die übliche Geschäftspraxis, Softwareprodukte mit einem Jahr „kostenlosen“ Support zu verkaufen, in Einklang mit den fixen Ge-bühren für den Softwaresupport für weitere Jahre zu bringen. In diesem Fall wird der faire Wert des kostenlosen Supports zurückgestellt (und über das eine Jahr reali-siert), während der Software selbst ein Umsatzbetrag von der Differenz zwischen der Gesamtvergütung der Softwarevereinbarung und dem bekannten Preis für ein Supportjahr zugeschrieben wird. Ohne residuale Methode wäre eine Umsatzalloka-tion aufgrund des fehlenden VSOE des Softwareprodukts nicht möglich und die gesamte Umsatzrealisierung müsste zurückgestellt werden.211 Das folgende Beispiel soll die Auswirkungen der Verwendung der residualen Methode für die Verteilung von Rabatten aufzeigen:

Fallstudie 14

Das Softwareunternehmen Z verkauft Ende 2005 ein Standard-Softwarepaket zum Verkaufspreis von 120'000 (=VSOE). In diesem Paket sind zusätzlich zur Standard-Softwarelizenz die postvertraglichen Leistungen (PCS) eines Telefonsupports und die Bereitstellung von Updates für ein Jahr inbegriffen. Die Verlängerung dieser PCS-Leistungen ist für den Preis (=VSOE) von 30'000 pro Jahr möglich.

210 Vgl. Delaney et al. (2004), S. 997. 211 Vgl. Delaney et al. (2004), S. 997 und SOP 97-2.2.

Page 101: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 83

Welcher Betrag ist Ende 2005 als Umsatz zu realisieren, falls (Fall A) der VSOE von beiden Komponenten bekannt ist? (Fall B) der VSOE nur für die PCS-Leistungen verfügbar ist?

Fallstudie 14: Aufteilung von Rabatten auf die Einzelkomponenten nach SOP 97-2212

Im Fall A sieht die Aufteilung folgendermassen aus, wobei der fett hervorgehobene Betrag als Umsatz zu realisieren ist:

Fall A VSOE % des gesamten Marktwertes

Zuordnung des Rabatts

Umsatzallokation

Lizenzbetrag 120’000 80 24’000 96’000

PCS 30’000 20 6’000 24’000

150’000 100 30’000 120’000

Im Fall B findet die residuale Methode Anwendung, da der VSOE der Standard-Software nicht bestimmbar ist, was zur folgenden Umsatzrealisierung (fett hervor-gehobener Betrag) führt:

Fall B VSOE % des gesamten Marktwertes

Zuordnung des Rabatts

Umsatzallokation

Lizenzbetrag ? 90’000

PCS 30’000 Residuale Methode 30’000

120’000

Falls es nicht möglich ist, den VSOE für jedes der Elemente eines Mehrkomponen-tenvertrages zu ermitteln bzw. alternativ die residuale Methode anzuwenden, so muss die Realisierung des gesamten Umsatzes zurückgestellt werden, bis eine der vorliegenden Bedingungen erfüllt ist:213

212 In Anlehnung an Bender (2005), S. 103. 213 Vgl. SOP 97-2.12. Es sei denn, es greife eine der Ausnahmeregeln nach SOP 97-2.49, SOP 97-2.58

oder SOP 97-2.67 (weiter unten in diesem Unterkapitel erläutert).

Page 102: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 84

• Es kann ein VSOE für jedes Element ermittelt werden.

• Alle Elemente der Vereinbarung wurden geliefert.

Die Umsatzrealisation nach SOP 97-2 hängt in starkem Masse von der Bestimmung des VSOE ab, an dessen Nachweis sehr hohe Anforderungen gestellt werden. So ist bei Softwarepaketen die sofortige Umsatzrealisierung des auf die Softwarelizenz entfallenden Betrages nicht möglich, wenn mit dem Softwareprodukt verknüpfte Leistungen nicht separat vertrieben werden und dies auch nicht geplant ist.

Diesen restriktiven Bedingungen für den Nachweis des VSOE, welche eine hohe Rate an aufgeschobenen Umsatzrealisationen nach sich ziehen, stehen jedoch einige weit reichende Ausnahmeregeln entgegen:

• Wenn Supportleistungen (PCS) das einzige noch nicht gelieferte Vertrags-element sind, dann soll die gesamte Vertragssumme in Raten über die ver-traglich fixierte oder ökonomisch zu erwartende Dauer der Leistungserbrin-gung verbucht werden.214

• Wenn das einzige nicht gelieferte Element Dienstleistungen umfasst, die kei-ne signifikante Produktion, Modifikation oder Customizing der Software ver-langen, so soll die gesamte Vertragssumme in Raten über den Zeitraum ver-bucht werden, in dem die Dienstleistungen erbracht werden.215

• Falls die Vereinbarung Abonnementcharakter216 besitzt, so soll die gesamte Vertragssumme beginnend mit der Lieferung des ersten Softwareprodukts in Raten verbucht werden.217

Diese Ausnahmeregeln führen in der Praxis zu einigem Spielraum für die Unter-nehmen bei der Umsatzrealisierung wie folgendes Beispiel zeigt:

214 Vgl. SOP 97-2.58 215 Vgl. SOP 97-2.67. 216 Nach SOP 97-2.48f. ist der Abonnementcharakter gegeben, wenn der Vertrag die laufende Lieferung

von Software und von zukünftigen nicht spezifizierten Softwareprodukten (unspecified additional soft-ware products) vorsieht.

217 Vgl. SOP 97-2.49.

Page 103: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 85

Fallstudie 15

Das Standard-Softwareunternehmen Computer Associates ist ein führender Anbie-ter von Managementsoftware-Produkten und Dienstleistungen für IT-Umgebungen. Das Unternehmen führte im Jahr 2000 ein neues Geschäftsmodell ein, welches auf Verträgen mit Abonnementcharakter (subscription model) basiert. Nach diesem Modell können Kunden Software und entsprechende Dienstleistungen in einem Pa-ket mit monatlichen fixen Zahlungen erwerben, anstatt langjährige Lizenzverträge in Kombination mit jährlich zu erneuernden Dienstleistungsverträgen abschliessen zu müssen. Für SOP 97-2 ist entscheidend, dass das neue Abonnementmodell dem Käufer während der Vertragsdauer auch das Recht auf den Bezug von neu entwi-ckelter Software ohne weitere Kostenfolge einräumt. SOP 97-2.48f. sprechen in diesem Zusammenhang von unspezifizierten zusätzlichen Softwareprodukten (unspecified additional software products) als Teil der Vertragsvereinbarung und fordern eine Umsatzrealisierung der gesamten Vereinbarung in Raten. Dies steht im Gegensatz zum alten Geschäftsmodell, welches eine Verbuchung aller Erträge „upfront“ bei Vertragsabschluss und Produktlieferung erfordert. Entsprechend führ-te der Wechsel von Computer Associates von einem klassischen lizenzbasierten Modell zu einem Abonnementmodell dazu, dass die Umsätze neu in Raten gleich-mässig über die Jahre und nicht mehr einmalig zu Vertragsbeginn zu verbuchen sind. Dieses neue Modell widerspiegelt damit das moderne Standard-Software-geschäft, welches vermehrt durch Abonnementverträge gekennzeichnet ist.218 Zu-dem sinkt der Druck, Verträge auf gewisse Termine hin abschliessen zu müssen, um (Quartals-)Umsatzziele zu erfüllen.

Von Investorenseite wurde jedoch kritisiert, dass das neue Geschäftsmodell von Computer Associates weniger dazu diene, die Geschäftsrealität besser abzubilden, als vielmehr einen anderen (für das Management vorteilhafteren) Umsatzausweis vorzunehmen.219 Viele Kunden scheinen nämlich nicht mehr bereit gewesen zu sein, langjährige Lizenzvereinbarungen abzuschliessen. Durch den Wechsel des Geschäftsmodells war es möglich, diesen (faktischen) Umsatzrückgang zu kaschie-ren, indem die alten Umsätze laufender Verträge nun nach dem neuen Geschäfts-

218 Siehe exemplarisch das software assurance Lizenzierungsmodell von Microsoft. Vgl. o.V. (2005b). 219 Vgl. Vijayan (2000).

Page 104: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 86

modell in jährliche Raten über die Gesamtvertragsdauer verbucht werden konn-ten.220

Fallstudie 15: Computer Associates

Die obige Diskussion zeigt unabhängig vom Vorteil eines Abonnementmodells die Gestaltungsfreiräume von Unternehmen aufgrund der vielfältigen Ausnahme-regelungen von SOP 97-2. So ist es möglich durch minimale Vertragsvariationen eine völlig andere Umsatzrealisation herbeizuführen.

2.2.3.

Bilanzierung und Bewertung

Die Bilanzierung der zu erfassenden Umsatzerträge erfolgt in der Erfolgsrechnung im Realisierungszeitpunkt und die Bewertung richtet sich nach dem beizulegenden Zeitwert der erhaltenen oder geforderten Leistungen abzüglich aller vom Verkäufer gewährten Preisnachlässe oder Mengenrabatte. Die Umsätze werden dabei nach den vertraglich vereinbarten Netto-Beträgen, d. h. mit Abzug der Nachlässe ausge-wiesen.221 Nach IAS 18.7 ist der beizulegende Zeitwert derjenige Betrag, zu wel-chem ein Vermögenswert zwischen sachverständigen, vertragswilligen und vonein-ander unabhängigen Parteien getauscht oder eine Schuld beglichen werden könnte. Liegt ein Tauschgeschäft vor, so bemisst sich der Ertrag nach dem beizulegenden Zeitwert der erhaltenen Leistung bzw. bei mangelnder Bestimmbarkeit nach dem beizulegenden Zeitwert der erbrachten Eigenleistung.222 Sind für beide Leistungen die beizulegenden Zeitwerte nicht objektiv bestimmbar, so sind bei Gütern lediglich der Buchwert und bei Dienstleistungen die erstattungsfähigen Kosten anzusetzen.223 Es liegt bei Tauschgeschäften jedoch nur dann ein umsatzrelevanter Vorgang vor, wenn keine gleichartigen oder gleichwertigen Güter bzw. Dienstleistungen ge-tauscht werden.224

Preisnachlässe oder Mengenrabatte sind in der Standard-Softwareindustrie aufgrund der kaum vorhandenen Grenzkosten von Standard-Software ein wichtiges und häu-

220 Vgl. o.V. (2002a). 221 Vgl. Delaney et al. (2004), S. 68. 222 Vgl. IAS 18.12 sowie APB 29.18. 223 Vgl. IAS 18.26 und APB 29.25-26. 224 Vgl. IAS 18.12 und APB 29.21.

Page 105: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 87

fig eingesetztes Mittel der Verkaufsförderung. Solche Ertragsminderungen können dabei unmittelbar im Realisationszeitpunkt oder nachträglich eingeräumt werden.

Bei offensichtlichen Preisnachlässen im Realisationszeitpunkt wie zum Beispiel Listenpreisabschlägen wird direkt eine Umsatzminderung um den gewährten Nach-lassbetrag vorgenommen (Netto-Beträge). Bei der ebenfalls verbreiteten Praxis von Standard-Softwareunternehmen, Naturalrabatte im Realisationszeitpunkt in Form von freiwilligen Zusatzleistungen (z. B. Gratissupport oder kostenlose zukünftige Updates für eine bestimmte Zeit) zu erbringen, kommen nach US-GAAP die Rege-lungen zu Mehrkomponentenverträgen zur Anwendung falls der Verkäufer die Leis-tungen in Zukunft selbst erbringen will.225 Ansonsten werden diese Leistungen als Aufwand erfasst. Die IFRS stellen keine spezifischen Regelungen zu Naturalrabat-ten zur Verfügung, womit nach den allgemeinen Vorschriften eine Ertragsminde-rung auszuweisen ist.

Die nachträglich eingeräumten Ertragsminderungen umfassen Positionen wie Rück-zahlungsgewähr sowie Skonti und Boni:226

Im Rahmen von Rücktrittsrechten bietet der Verkäufer zumeist eine Rückzahlungs-gewähr für bereits getätigte Überweisungen des Käufers. Die Rückzahlungsgewähr unterscheidet sich dabei stark von anderen Ertragsminderungen, da für den Verkäu-fer eine viel höhere Unsicherheit besteht, indem die gesamte Transaktionsvereinba-rung dem Risiko der einseitigen Auflösung von Seiten des Kunden unterliegt. Grundsätzlich wird die Umsatzrealisierung trotz eingeräumten Rücktrittsrechts von den Standardsettern zugelassen, sofern die Wahrscheinlichkeit eines Rücktritts zu-verlässig227 bestimmbar ist.228 Nach IAS 37.36 ist dabei die Rückstellung so anzu-setzen, dass die gegenwärtigen Verpflichtungen erfüllt werden können, was im Fall der Rückzahlungsgewähr der Differenz zwischen der Forderung und dem Wert der zurückerhaltenen Ware (also der Gewinnmarge) entspricht. Die US-GAAP fordern

225 Vgl. dazu explizit FASB (2002a), S. 1352. 226 Vgl. Bender (2005), S. 74ff. 227 Für eine mangelnde Zuverlässigkeit sprechen nach SFAS 48.8 unüblich lange Rücktrittsfristen und

hoher technischer Fortschritt im Markt, sowie nach SAB 104 unter anderem, signifikante Erhöhungen im Lagerbestand der Abnehmer, die sich auf die Praxis des Vorziehens von Umsätzen bezieht.

228 Vgl. IAS 18.16-17 und SFAS 48.8.

Page 106: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 88

eine Korrektur des Umsatzes um die volle Höhe der zur Rückzahlung zu gewähren-den Erträge und zusätzlich eine Reduktion der Verkaufskosten (cost of goods sold).

Beim Skonto wird dem Kunden das Recht eingeräumt, bei fristgerechter Bezahlung einen bestimmten Abzug auf den Rechnungsbetrag vornehmen zu dürfen. Üblicher-weise erfolgt die Umsatzerfassung nach der so genannten Bruttomethode, bei der die Umsatzerträge zunächst ungekürzt erfasst werden; bei Eingang der Zahlung des Kunden innert der Skontofrist wird der resultierende Differenzbetrag zur ursprüng-lichen Forderung als finanzieller Aufwand gebucht und zum Periodenabschluss auf das Umsatzkonto übertragen.229

Bei Boni handelt es sich in der Regel um gewährte Ertragsminderungen, die sich nach dem Umsatzvolumen eines Kunden in einer bestimmten Zeitperiode richten. Die voraussichtliche Ertragsminderung ist dabei grundsätzlich im Realisierungs-zeitpunkt zu schätzen und als Rückstellung zu erfassen, da es sich um längere Zeit-räume und höhere Beträge als bei Skonti handelt. Nach IFRS ist die Höhe der Rück-stellung durch die Schätzung der erwarteten Kosten für die Boni zu bestimmen.230 Die US-GAAP bestimmen für den Fall von geldwerten Boni, dass bei der Schät-zung der Kosten die Gesamtzahl der Kunden mit voraussichtlichem Bonusanspruch zu Grunde zu legen ist. Ist eine zuverlässige Schätzung nicht möglich, so ist die maximale Umsatzkorrektur und Rückstellungsbewertung vorzunehmen.231

2.2.4.

Offenlegung

Die in diesem Kapitel aufgezeigten umfangreichen Ermessensspielräume bei der Umsatzrealisierung, aber auch bei der Bewertung können zu erheblichen Differen-zen im Umsatzausweis führen, womit der Offenlegung eine wichtige Rolle zu-kommt.

In der Erfolgsrechnung sind nur die Nettoumsätze zwingend auszuweisen, wobei eine separate Offenlegung von Bruttoumsätzen und Ertragsminderungen befürwor-tet wird.232 Zudem ist eine Aufgliederung von wesentlichen Erträgen getrennt nach

229 Vgl. Kieso et al. (2004), S. 320f. 230 Vgl. IAS 18.10 und IAS 37.36-41. 231 Vgl. FASB (2002a), S. 1358. 232 Vgl. Delaney et al. (2004), S. 68; Epstein/Mirza (2002), S. 113.

Page 107: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 89

Warenverkäufen, Dienstleistungen, Zinsen, Nutzungsentgelten und Dividenden ent-weder in der Erfolgsrechnung nach US-GAAP oder im Anhang nach IFRS erforder-lich.233 IAS 18.35c) fordert zudem die Offenlegung des Betragsanteils von Tausch-geschäften in den Erträgen.

Für Investoren von hoher Bedeutung ist die Segmentberichterstattung, welche das Ziel einer Differenzierung der Erträge nach einzelnen Geschäftsbereichen und nach geografischen Aspekten verfolgt, um die unterschiedlichen Rahmenbedingungen der Segmente für den Investor sichtbar und damit besser einschätzbar zu machen.234 Gemäss IAS 14.9 sind vom Unternehmen sowohl Geschäftssegmente als auch geo-grafische Segmente aufzuführen. Nach SFAS 131 Disclosures about Segments of an Enterprise and Related Information bestehen Ausweispflichten zu den operating segments und zusätzlich für wesentliche Produkte, geografische Gebiete und Haupt-kunden.235

Die Anhangangaben zur Umsatzerfassung dienen hauptsächlich zur Erläuterung der wesentlichen Bilanzierungs- und Bewertungsmethoden. Insbesondere die Rege-lungslücke der IFRS im Bereich von Vereinbarungen mit mehreren Komponenten erfordert die Entwicklung von eigenständigen Lösungen durch die Unternehmen, welche ausführlich im Anhang erläutert werden müssen.236 Auch SAB 104 Revenue Recognition beurteilt die hohen Ermessensspielräume bei den Bilanzierungs- und Bewertungsmethoden zur Umsatzerfassung als wesentlich und damit als im Anhang erläuterungswürdig.

Auch Transaktionen mit nahe stehenden Personen (related pary disclosure) sind aufgrund ihres Beeinflussungspotenzials auf die Neutralität in der Umsatzbewer-tung im Anhang zu erfassen. Als nahe stehende Person bzw. nahe stehendes Unter-nehmen wird eine Partei definiert, die über die Möglichkeit verfügt, eine andere Partei zu beherrschen (control) oder einen massgeblichen Einfluss (significant in-fluence) auf deren Finanz- und Geschäftspolitik auszuüben.237 Daher sind die Ge-

233 Vgl. IAS 18.35b) und SEC Regulation SX, Rule 5-03. 234 Vgl. Achleitner/Behr (2002), S.232. Die Segmentberichterstattung ist nur für börsenkotierte Unterneh-

men obligatorisch, vgl. IAS 14.3 und SFAS 131.49. 235 Vgl. SFAS 131.37-39. 236 Vgl. IAS 1.101. 237 Vgl. IAS 24.5

Page 108: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 90

schäftsbeziehungen sowohl nach Art als auch nach Umfang mit nahe stehenden Per-sonen und Unternehmen offen zu legen.238

2.2.5.

Beurteilung aus Sicht der externen Analyse

Die im Standard-Softwarebereich anwendbaren Vorschriften zeichnen sich unter IFRS durch allgemeine, branchenübergreifende Regelungen aus, während die US-GAAP einen branchenspezifischen Regulierungsansatz mit detaillierten Vorschrif-ten zu Verträgen mit mehreren Komponenten entwickelt haben. Grundsätzlich be-wirkt die grosse Diskrepanz zwischen den IFRS und den US-GAAP hinsichtlich ihrer Behandlung der Umsatzrealisierungsproblematik für den Investor eine schlechte Vergleichbarkeit (comparability/consistency) der erstellten Jahresab-schlüsse zwischen den Rechnungslegungswerken.

Wie bereits erwähnt, besteht der Ansatz der IFRS in einem global gehaltenen und nicht sonderlich detaillierten Standard. Dabei werden insbesondere Vereinbarungen mit mehreren Komponenten weitgehend ausgeblendet. Wie in der Fallstudie 13 ex-emplarisch aufgezeigt, kann dies bei ausgefallenen Ertragsmodellen sogar zu Rege-lungslücken führen. Dadurch ist die representational faithfulness, also die Abbil-dung der Realität in der Rechnungslegung, nur sehr bedingt gegeben.

Die amerikanischen Rechnungslegungsorganisationen haben frühzeitig versucht, auf die fortlaufenden Entwicklungen bei den Ertragsmodellen der Standard-Softwareunternehmen zu reagieren und haben entsprechend immer wieder neue, angepasste Regelungen in Kraft gesetzt.239 Für die Erfassung von Vereinbarungen mit mehreren Komponenten wurde mit SOP 97-2 ein umfangreiches und kohärentes Modell entwickelt, welches die Komponenten einzeln betrachtet und separat als Umsatz erfasst. Als Beurteilungsmassstab für die Aufteilung der Komponenten wurde die funktionale Wesentlichkeit definiert und die Umsatzallokation auf die einzelnen Komponenten erfolgt nach per VSOE ermittelten Marktpreisen. Dadurch stellt das Modell eine intersubjektive Überprüfbarkeit und eine hohe Transparenz

238 Vgl. IAS 24.22f. und ähnlich SFAS 57.2. 239 So wurde mit SOP 91-1 ein Grundmodell für die Umsatzrealisierung von Standard-Software entwickelt.

Dieses wurde durch das weitergehende Grundmodell von SOP 97-2 ersetzt, welches wiederum durch SOP 98-9 modifiziert und durch SOP 98-4 ergänzt wurde. Vgl. ausführlich Keller (1999), S. 3ff.

Page 109: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 91

der Umsatzrealisierung für den Investor sicher. Sie entspricht damit im weitesten Sinne den Anforderungen der understandability. Dieses Grundmodell wird jedoch durch viele Zusatzbestimmungen stark relativiert und zum Teil sogar ins Gegenteil verkehrt. Durch die hohen Hürden bei der Anerkennung der funktionalen Wesent-lichkeit und dem Nachweis der Marktpreise (VSOE) ist häufig eine Zurückstellung der Umsatzerfassung erforderlich, welche in bestimmten Fällen durch eine Umsatz-realisation in Raten gemildert wird. Während die Ausnahmeregelungen zu einer aus Investorensicht unerwünschten, weil intransparenten Methodenvielfalt führen, leis-ten die restriktiven Bestimmungen einer übermässig konservativen Rechnungsle-gung Vorschub, welche sich in hohen zurückgestellten Umsätzen niederschlägt. Problematisch an der Bilanzposition „zurückgestellte Umsätze“ (deferred revenues) ist die Tatsache, dass dazu keine Reglementierungen existieren. Entsprechend frei sind die Unternehmen bei der Ausgestaltung dieser Position.

Mit dem Grundmodell von SOP 97-2 haben die US-GAAP ein umfassendes, trans-parentes Modell für die in der Standard-Softwareindustrie weit verbreiteten Verein-barungen mit mehreren Komponenten entwickelt und erfüllen die Forderung der representational faithfulness weit besser als die IFRS, die solche Vereinbarungen gänzlich ausblenden. Problematisch sind jedoch die zahlreichen Ausnahmeregeln, welche schon bei geringen Änderungen des Sachverhalts oder der Begriffsverwen-dung nicht dem Grundmodell entsprechende Auslegungen ermöglichen und dem Anwender ein faktisches Wahlrecht einräumen wie die Fallstudie 15 exemplarisch aufgezeigt hat. Dadurch ist die Vergleichbarkeit der Unternehmensabschlüsse wie sie die comparability/consistency verlangt, stark beeinträchtigt, da rein formale Dif-ferenzen zu unterschiedlichen Erfolgsausweisen führen. Zudem ist fraglich, ob die Auslegungsfreiheit der representational faithfulness zuträglich ist.

Ein weiteres Manko der Regelungen der US-GAAP besteht darin, dass sie ihre Gül-tigkeit nur für Software entfalten und somit auf die (Standard-)Softwarebranche limitiert sind. Zum einen ergeben sich Abgrenzungsschwierigkeiten für den An-wendungsbereich der Regelungen wie im Fall von SOP 97-2 bei den Bestimmungen zur Wesentlichkeit der Softwarekomponente bei Verträgen mit unterschiedlichen Komponenten oder die Abgrenzung zu Fertigungsaufträgen. Zum anderen können branchenspezifische Regelungen zu einem Auseinanderdriften der Vorschriften zwischen einzelnen Branchen führen und bergen die Gefahr, dass grundsätzlich

Page 110: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 92

gleich gelagerte Sachverhalte nur aufgrund einer anderen Branchenzugehörigkeit unterschiedlich behandelt werden.240 Der Autor lehnt jedoch eine generelle Kritik an branchenspezifischen Rechnungslegungsvorschriften ab, solange diese keine konkurrenzierenden Regelungsmodelle schaffen, sondern eine branchenorientierte Konkretisierung allgemeiner Regelungsprinzipien zum Ziel haben.

2.3. Berichterstattung über (selbsterstellte) Standard-Software

Die Berichterstattung über Standard-Software nimmt bei Standard-Softwareunter-nehmen offensichtlich eine besondere Stellung ein, da der Wertschöpfungsprozess von Standard-Softwareunternehmen definitionsgemäss auf der Erstellung von Stan-dard-Software zum Zweck des Verkaufs auf dem anonymen Massenmarkt beruht. Regelungen zur Bilanzierung von entgeltlich erworbener Software, zur Bilanzierung von Software zur internen Verwendung und zur Bilanzierung von Software im Auf-trage Dritter (bzw. Bilanzierung von Individualsoftware) bilden somit Ausnahmeer-scheinungen, die von untergeordnetem Interesse für die Rechnungslegung bei Stan-dard-Softwareunternehmen sind. Auf die für diese Fälle relevanten Rechnungs-legungsvorschriften wird daher im Folgenden nur an denjenigen Stellen verwiesen, wo es als zweckmässig erachtet wird.241 Folgende Darstellung zeigt im Überblick die verschiedenen Verwendungsarten von Software und ihre Bilanzierung beim Hersteller mit den entsprechenden Rechnungslegungsvorschriften:

240 So wurden die von SOP 97-2.8 definierten Grundsatzkriterien für eine Umsatzrealisierung erst zwei Jahre später mit dem SAB 101 generalisiert und auf alle Branchen übertragen. Die Regelungen zu Ver-einbarungen mit mehreren Komponenten wurden sogar erst Mitte 2003 mit dem EITF 00-21 verallge-meinert.

241 Für eine Übersicht der verschiedenen Rechnungslegungsregeln im Bereich Software und deren Diffe-renzierung, vgl. z. B. Küting et al. (2002) oder Pirker (1997).

Page 111: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 93

Erstellung von Software ohne externen Auftrag (Standard-Software)

Erstellung von Software mit externem Auftrag (Individual-Software)

IAS 38 Immaterielle Werte

SFAS 86 Accounting of Software to Be Sold, Leased or Otherwise Marketed

Erstellung von Software zur Fremdnutzung

Erstellung von Software zur Eigennutzung

IAS 11 Fertigungsaufträge ARB 45 Long-Term Construction

Type Contracts

IAS 18 Erträge ARB 43 Inventory Pricing

Arten von Software (nach Verwendungsart)

IAS 38 Immaterielle Werte

SFAS 2 Accounting for R&D Costs FIN 6 Applicability of SFAS 2 to Software

SFAS 86 Accounting of Software to Be Sold,Leased or Otherwise Marketed

Fokus der Dissertation

> 1 Jahr

< 1 Jahr

Abbildung 16: Behandlung von Software nach IFRS und US-GAAP

Für Standard-Softwareunternehmen sind somit IAS 38 Immaterielle Vermögenswer-te und SFAS 86 Accounting of Software to Be Sold, Leased or Otherwise Marketed relevant, welche die Berichterstattung zur Erstellung von Standard-Software zur anonymen Massenvermarktung behandeln. Während die IFRS keine expliziten Re-gelungen zur Standard-Software in der Berichterstattung kennen, sondern diese im Rahmen der allgemeinen Regelungen zu den immateriellen Werten nach IAS 38 behandeln, weisen die US-GAAP mit SFAS 86 einen spezifischen und äusserst de-taillierten Standard auf.

2.3.1.

Bilanzierung und Bewertung

Die Bilanzierung von selbst erstellter Standard-Software zum Weiterverkauf fällt nach IFRS wie die übrigen immateriellen Werte unter die Vorschriften von IAS 38 Immaterielle Werte und ähnelt weitestgehend den vergleichbaren Rechnungsle-gungs- und Bewertungsvorschriften von SFAS 86. Standard-Software ist somit bei Erfüllung der entsprechenden allgemeinen Ansatzbedingungen für immaterielle Werte aktivierungspflichtig.242 Unter anderem muss der Nachweis eines wahr-scheinlichen zukünftigen Nutzenzuflusses erfolgen, welcher im Allgemeinen ab einem bestimmten Fertigstellungsgrad der Standard-Software erbracht werden kann.

242 Vgl. IAS 38.45 und Abschnitt IV 2.4.1.

Page 112: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 94

Da die Software nicht zur Eigennutzung, sondern zum Weiterverkauf bestimmt ist und daher dem Unternehmen – unter der Voraussetzung eines existierenden Mark-tes – durch den Umsatzprozess entsprechende Vermögenswerte zufliessen wer-den.243 Von noch zentralerer Bedeutung für die Aktivierung von Standard-Software ist die Erfüllung der technischen Realisierbarkeit (technological feasibility). Analog zu den US-amerikanischen Vorschriften wird nach IAS 38.40 der Standard-Softwareherstellungsprozess in eine Forschungs- und eine Entwicklungsphase un-terteilt. Unter Forschung versteht IAS 38.7 die eigenständige und planmässige Su-che mit der Aussicht, zu neuen wissenschaftlichen oder technischen Erkenntnissen zu kommen. Als Entwicklung wird hingegen vor allem die Anwendung von For-schungsergebnissen auf den Plan oder den Entwurf einer Produktion von neuen oder verbesserten Produkten, Verfahren, Dienstleistungen und anderem verstanden.244 Während die Kosten in der Forschungsphase gemäss IAS 38.42 direkt als Perioden-aufwand in der Erfolgsrechnung zu verbuchen sind, können die Kosten der Ent-wicklungsphase bei Erfüllung der Ansatzbedingungen aktiviert werden. Da diese beiden Definitionen keine trennscharfe Abgrenzung erlauben, wurde von den IFRS die den US-GAAP ähnliche Konzeption der technischen Realisierbarkeit einge-führt. Während jedoch die SFAS 86 den Zeitpunkt der technischen Realisierbarkeit mittels der Verpflichtung zum Nachweis eines detailed program design bzw. wor-king model zu konkretisieren versuchen,245 mangelt es den IFRS an solchen detail-lierten Vorschriften für die Standard-Softwarebranche. Es gelten nur die allgemei-nen, für alle selbst geschaffenen immateriellen Werte wirksamen Kriterien von IAS 38.45. Um den unscharfen Begriff der technischen Realisierbarkeit fassbarer zu ma-chen, schlägt die Fachliteratur mehrheitlich vor, die Konkretisierungen von US-GAAP zur Bestimmung des Zeitpunkts der technischen Realisierbarkeit analog in den IFRS anzuwenden.246 Die Unschärfe des Abgrenzungskriteriums der techni-schen Realisierbarkeit stellt dem Bilanzierenden einen erheblichen Ermessensspiel-raum zur Verfügung, was zu einer höchst unterschiedlichen Bilanzierung von Stan-

243 Vgl. Küting et al. (2002), S. 82. 244 Vgl. IAS 38.7. 245 Vgl. dazu die Ausführungen zu den US-GAAP weiter unten in diesem Unterkapitel. 246 Stellvertretend Epstein/Mirza (2002), S. 344f.

Page 113: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 95

dard-Software nach IFRS in der Praxis führt, wie folgende zwei Fallstudien aufzei-gen:

Fallstudie 16

Das deutsche Unternehmen Brainpower ist ein Standard-Softwareunternehmen, welches im Finanzsektor tätig ist und mit ihren Softwareprodukten den Investment Management Bereich bedient. Das Unternehmen entwickelt analytische Produkte und Datenmanagement-Lösungen, welche zu einer Verbesserung der Investment-analyse beitragen. Zentrales Produkt des Unternehmens ist die Brainpower Suite, welche ein auf den Arbeitsprozess des Investment Managers abgestütztes modular aufgebautes Entscheidungsunterstützungs- und Analysesystem darstellt. Es unter-stützt Investment Manager mit einem umfassenden Set an Analysewerkzeugen und Datenbanken. Das Unternehmen wendet die IFRS an und aktiviert daher regelmäs-sig die Aufwendungen für die Softwareentwicklung sobald die technische Reali-sierbarkeit erreicht ist. Brainpower schreibt im Anhang des Geschäftsberichts daher folgendes zur Behandlung von selbsterstellter Software:247

Capitalized Software Capitalized software development costs include personnel costs of the software development team, directly related third-party expenditures and an appropriate portion of relevant overhead. Capitalization of such costs begins upon establishment of technological feasibility and ends when the resulting product is available for general release in accordance with International Accounting Standard (IAS) No. 38, Intangible Assets. All costs incurred to establish the technological feasibility of software products are classified as research and are expensed as incurred. Expenditures that enhance and extend the benefits of computer software available for sale beyond their original specifications and lives are recognized as a capital improvement and added to the original costs of the software. Capitalized costs are amortized over a 3-year period and reported at the lower of non-amortized cost or net realizable value.

Fallstudie 16: Aktivierung von selbsterstellter Software nach IFRS

Im Gegensatz zum Standard-Softwareunternehmen Brainpower stellt das ebenfalls in der Standard-Softwareentwicklung tätige Unternehmen Day seine Softwareent-wicklungsaufwendungen vollkommen anders dar:

247 Brainpower, Geschäftsbericht 2003, S. 15.

Page 114: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 96

Fallstudie 17

Das Schweizer Unternehmen Day entwickelt und vertreibt Standard-Software-produkte rund um den Bereich Content Management. Diese sind mehrheitlich als Softwareprodukte-Set im integrierten Content Management System Communiqué zusammengefasst. Die Communiqué Suite bietet Lösungen für das Dokumentenma-nagement, das Management multimedialer Daten, das Management von Geschäfts-prozessen sowie das jeweilige Zugriffsmanagement und Unterstützung für die elekt-ronische Gruppenzusammenarbeit und Kommunikation an. Day bilanziert nach IFRS und ist daher verpflichtet, Aufwendungen für die Softwareentwicklung bei Erreichen der technischen Realisierbarkeit zu aktivieren. Das Unternehmen argu-mentiert jedoch, dass die Entwicklungskosten nach Erreichen der technischen Rea-lisierbarkeit vernachlässigbar seien und daher keine Aufwendungen der Software-entwicklung zu aktivieren sind:248

Development costs incurred in the research and development of new software products to be sold or otherwise marketed are expensed as incurred until technological feasibility in the form of a working model has been established at which time such costs are capitalized, subject to recoverability.Products are made available for limited release, concurrent with the achievement of technological feasibility. Accordingly, software development costs incurred subsequent to the establishment of technological feasibility have not been significant, and the Company has not capitalized any software development costs to date.

Diese Aussage ist insofern bemerkenswert als die Communiqué Suite bereits in der vierten Version vermarktet wird und daher Indizien für eine intensive Weiterent-wicklung der technisch erfolgreichen Erstversion bestehen.

Fallstudie 17: Keine Aktivierung von selbsterstellter Software nach IFRS

Die beiden Praxisfälle zeigen exemplarisch den eröffneten Ermessensspielraum der geltenden Regelung der IFRS bei der Aktivierung von Softwareentwicklungskosten auf. Eine für den Investor nachvollziehbare, konsistente Systematik bei der Festle-gung der Aktivierungshürden ist nicht zu erkennen.

Die zu aktivierenden Herstellungskosten umfassen nach IAS 38.54 die Material- und Personalkosten, soweit sie dem Softwareprodukt direkt belastet werden können oder indirekt zurechenbar sind, während Vertriebs- und Verwaltungskosten sowie Ausgaben für die Schulung der Mitarbeiter und Anlaufverluste gemäss IAS 38.55

248 Day, Geschäftsbericht 2004, S. 35.

Page 115: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 97

nicht aktiviert werden dürfen. Die bei Standard-Software häufig nachträglich anfal-lenden Erstellungskosten in Form von Verbesserungen und Erweiterungen (Updates bzw. Upgrades) oder auch Anpassungen (z. B. Customizing) sind nur dann aktivier-bar, wenn der voraussichtliche wirtschaftliche Nutzenzufluss aufgrund des Vermö-genswertes über den ursprünglichen Umfang hinaus erweitert wird und dies zuver-lässig gemessen und dem Vermögenswert zugeordnet werden kann.249 Nach SIC 6.4 Costs of Modifying Existing Software sind Aufwendungen aus Systemanpassungen, die den ursprünglichen Leistungsumfang der Software nur wiederherstellen oder bewahren (z. B. Aufwendungen im Zusammenhang mit der „Jahr 2000“- oder „Eu-ro“-Umstellung) als Aufwand zu erfassen. Die allgemeine Aussage der IFRS, dass nur Aufwendungen zur Umfangerweiterung aktivierungsfähig sind, ist für Standard-Software wohl so zu interpretieren, dass generell Ausgaben für die Entwicklung von Updates250 nicht, diejenigen für Upgrades251 jedoch aktivierungsfähig sind.

Die Folgebewertung der Standard-Software erfolgt bei IFRS im Rahmen der Bench-mark-Methode nach den fortgeführten Herstellungskosten. Im Unterschied zu den US-GAAP ist als Alternative auch die Neubewertungsmethode zugelassen.252

Im Rahmen der US-GAAP befasst sich das 1986253 eingeführte SFAS 86 Accoun-ting for Costs of Computer Software to Be Sold, Leased or Otherwise Marketed ex-plizit mit der Bilanzierung von Software, die entweder intern entwickelt oder extern eingekauft wird und auf dem anonymen Massenmarkt vermarktet wird. Dabei sind alle Aufwendungen zur Erstellung von Standard-Software zu aktivieren, die nach dem Erreichen des Zeitpunktes der technischen Realisierbarkeit anfallen.254 Die vor diesem Zeitpunkt aufgewendeten Forschungs- und Entwicklungskosten sind hinge-gen aufwandswirksam zu verbuchen.255 Diese Vorschrift entspricht somit ziemlich

249 Vgl. IAS 38.60. 250 Der Begriff Update meint ursprünglich „up-to-date“, also auf dem Laufenden halten und ist damit kon-

gruent mit der Aussage aus SIC 6, den „ursprünglichen Leistungsumfang der Software wiederherstel-len“. Entsprechend sind Updates generell nicht aktivierungsfähig.

251 Der Begriff Upgrade umschreibt eine Verbesserung bzw. eine Erweiterung des Leistungsumfangs der Software.

252 Vgl. IAS 38.64. 253 Der SFAS 86 trat für Jahresabschlüsse in Kraft, deren Berichtsperiode nach dem 15. Dezember 1985

begann. Vgl. SFAS 86.16. 254 Vgl. SFAS 86.3ff. 255 Vgl. SFAS 86 Summary.

Page 116: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 98

genau den Regelungen von IAS 38 Immaterielle Vermögenswerte. Das SFAS 86 ist jedoch auf Software beschränkt und umfasst eine Konkretisierung des Zeitpunkts der technischen Realisierbarkeit.

Vom Standardsetter werden als Mindestanforderung für den Beweis der technischen Realisierbarkeit konkret folgende Aktivitäten verlangt:

Falls der Prozess der Softwareerstellung ein detailliertes Programmdesign (detailed program design)256 beinhaltet, so wird verlangt, dass

• das Produktdesign und das detaillierte Programmdesign fertig gestellt wur-den und das Unternehmen Vorsorge getroffen hat, dass die notwendigen Fä-higkeiten, sowie Hardware und Software zur Verfügung stehen, um das Pro-dukt erstellen zu können,

• und die Vollständigkeit des detaillierten Programmdesigns und seine Konsis-tenz mit dem Produktdesign durch Dokumentierung und Überprüfung bestä-tigt sind,

• und das detaillierte Programmdesign im Hinblick auf hohe Risikofaktoren (wie technische Innovationen oder neue, noch nicht getestete Programmfunk-tionen) überprüft wurde und etwaige bei diesem Vorgang festgestellte Unsi-cherheiten durch Implementierung und Testen beseitigt wurden.257

Falls der Prozess der Softwareerstellung kein detailliertes Programmdesign vorsieht, so muss

• das Produktdesign und ein Prototyp258 des Softwareprogramms (working model) fertig gestellt vorliegen,

256 Das detaillierte Programmdesign definiert sich als detailliertes Design einer Computersoftware, welche die Produktfunktion, Merkmale und technischen Anforderungen zur ihrer maximalen detaillierten und logischen Form bringt und bereit für die Codierung ist. Vgl. SFAS 86.52.

257 Vgl. SFAS 86.4a. 258 Ein Prototyp wird als operative Version einer Computersoftware verstanden, welcher in der gleichen

Softwaresprache wie das finale Produkt fertig gestellt wurde und alle wichtigen Funktionen erfüllt und somit bereit für erste Nutzertests ist. Vgl. SFAS 86.52.

Page 117: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 99

• und die Vollständigkeit des Prototyps und seine Konsistenz mit dem Pro-duktdesign durch Tests überprüft sein.259

Trotz der Konkretisierung des Zeitpunktes der technologischen Realisierbarkeit ge-genüber den Regelungen der IFRS deckt die Zeitspanne zwischen der Fertigstellung des detail program design und des working model einen Grossteil des kompletten Softwareherstellungsprozesses ab.260 Entsprechend gross ist der verbleibende Er-messensspielraum für den Bilanzierenden, was – wie bei den IFRS – eine völlig konträre bilanzielle Behandlung von Softwareentwicklungskosten bei gleicher Aus-gangslage erlaubt. So kann ein Unternehmen, das einen möglichst hohen Anteil der Softwareentwicklungskosten aktivieren möchte, ein detailliertes Programmdesign zügig entwickeln und dadurch den Aktivierungsbeginn in die Anfangsphase des Herstellungsprozesses legen. Möchte ein Unternehmen hingegen einen hohen Anteil der Entwicklungskosten direkt erfolgswirksam verrechnen, so zögert es die Fertig-stellung eines detaillierten Programmdesigns hinaus bzw. verzichtet ganz darauf.

Fallstudie 18

Microsoft hat seit Einführung des SFAS 86 auf eine Bilanzierung von Aufwendun-gen für die Softwareentwicklung verzichtet. Damit befindet sich dieses Unterneh-men im Einklang mit praktisch allen namhaften Standard-Softwareunternehmen. Microsoft behauptet in seinen Jahresberichten konsequent, dass es keine Software-projekte gäbe, welche die technische Realisierbarkeit vor der Marktreife261 erfüllen würden. In Hinblick auf die jahrelange Erfolgsgeschichte von Microsoft ist es nur sehr schwer vorstellbar, dass dieses Unternehmen alle seine Softwareprojekte fak-tisch bis zur Marktreife entwickelt hat, ohne zuvor die technische Realisierbarkeit im Sinne von SFAS 86 erreicht zu haben. Dies würde eine äusserst chaotische Soft-wareentwicklung voraussetzen, die sich sehr schlecht mit der Erfolgsgeschichte des Unternehmens und dessen Grösse vereinbaren liesse. Es ist daher zu vermuten, dass Microsoft im Zusammenhang mit der Anwendung von SFAS 86 eine äusserst re-

259 Vgl. SFAS 86.4b. 260 Vgl. Küting et al. (2002), S. 81. 261 Microsoft spricht in diesem Zusammenhang zwar von Produktionsreife (released to manufacturing),

doch aufgrund der vernachlässigbaren Stellung der Produktion bei der Standard-Softwareerstellung kommt dies aus Rechnungslegungssicht faktisch einer Marktreife gleich.

Page 118: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 100

striktive Haltung einnimmt und die Erfordernisse der technischen Realisierbarkeit nach SFAS 86 absichtlich als hohe Hürde betrachtet. Entsprechend präsentiert sich die Bilanz von Microsoft ohne aktivierte selbsterstellte Standard-Software:262

BALANCE SHEETS (In millions) June 30 2004 2005 Assets Current assets:

Cash and equivalents $ 14,304 $ 4,851Short-term investments 46,288 32,900

Total cash and short-term investments 60,592 37,751Accounts receivable, net 5,890 7,180Inventories 421 491Deferred income taxes 2,097 1,701Other 1,566 1,614

Total current assets 70,566 48,737Property and equipment, net 2,326 2,346Equity and other investments 12,210 11,004Goodwill 3,155 3,309Intangible assets, net 569 499Deferred income taxes 3,808 3,621Other long-term assets 1,774 1,299

Total assets $94,368 $70,815

Im Anhang finden sich die folgenden Angaben zu den Softwareaufwendungen:263

Research and Development Research and development expenses include payroll, employee benefits, stock-based compensation, and other headcount-related costs associated with product development. We have determined that technological feasibility for our software products is reached shortly before the products are releasedto manufacturing. Costs incurred after technological feasibility is established are not material, andaccordingly, we expense all research and development costs when incurred.

Fallstudie 18: Standard-Softwarebilanzierung bei Microsoft

Die Aktivierung von Softwarekosten ist zu beenden, wenn das Produkt generell für die Kunden zum Verkauf freigegeben ist (general release). Somit ist die verbreitete Freigabe von Software an interessierte Anwender zum Testen (Public Beta) bzw. die Installation bei so genannten Testkunden grundsätzlich immer noch als Soft-wareentwicklungsphase einzustufen. Die Kosten für Unterhalt und Kundenunter-stützung sollen nicht aktiviert werden.264

Nach IFRS beginnt die planmässige Abschreibung der aktivierten Aufwendungen mit der Bereitstellung der Software zur Vermarktung und ist unabhängig von der

262 Microsoft, Form 10K 2005, S. 42. 263 Anhangangaben, Form 10K 2005, S. 46. 264 Vgl. SFAS 86.6.

Page 119: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 101

Bewertungsmethode und unabhängig davon ob intern erstellt oder von Dritten er-worben, planmässig über die voraussichtliche wirtschaftliche Nutzungsdauer abzu-schreiben.265 IAS 38.79 stellt dabei die widerlegbare Vermutung auf, dass die wirt-schaftliche Nutzungsdauer nicht mehr als 20 Jahre beträgt. Aufgrund der besonde-ren Branchencharakteristika dürfte bei Software die durchschnittliche Abschrei-bungsdauer jedoch unter fünf Jahren liegen. Die planmässige Abschreibung hat li-near zu erfolgen, wenn keine andere Methode besser geeignet ist, den tatsächlichen Nutzenverlauf zu erfassen, oder die zeitliche Verteilung des Verbrauchs nicht ver-lässlich geschätzt werden kann.266 Am Ende des Geschäftsjahres ist nach IAS 38.94 sowohl die Abschreibungsmethode als auch die Nutzungsdauer zu überprüfen.

Die aktivierten Softwareaufwendungen sind nach IAS 36.8f. am Bilanzstichtag auf ihre Werthaltigkeit zu überprüfen. Dabei ist der Buchwert dem höheren der beiden erzielbaren Beträge aus dem Nettoverkaufswert und dem Nutzungswert gegenüber-zustellen. Der Nettoverkaufswert entspricht dabei im Wesentlichen dem Marktwert der Software nach Abzug allfälliger Verkaufskosten. Der Nutzungswert definiert sich hingegen als der Barwert der geschätzten künftigen Cashflows aus der fortge-setzten Nutzung des Wertes und seinem Abgang am Ende der Nutzungsdauer.267 Wenn der erzielbare Betrag den Buchwert des Vermögenswertes unterschreitet, so ist nach IAS 36.58f. eine ausserordentliche, ergebniswirksame Abschreibung auf den erzielbaren Betrag vorzunehmen.

Bei den US-GAAP hat die Abschreibung auf einer product-by-product basis zu er-folgen, welche nach SFAS 86.8 auf dem höheren der aus der linearen Methode oder der „umsatzabhängigen“ Methode (revenue curve method) ermittelten Beträge ba-siert. Nach der revenue curve method bestimmt sich die Abschreibung nach dem Verhältnis der jährlichen Umsatzerträge zu den gesamten mit der Software erzielba-ren Umsätzen. Das SFAS 86 schreibt keine bestimmte Abschreibungsdauer vor.

Neben der planmässigen kann es bei den US-GAAP analog zu den IFRS auch zu einer ausserplanmässigen Abschreibung kommen. Liegt der Buchwert der Software zum Bilanzstichtag über dem net realizable value, so ist in der Höhe des Differenz-

265 Vgl. IAS 38.79. 266 Vgl. IAS 38.88. 267 Vgl. IAS 36.5.

Page 120: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 102

betrages eine ausserplanmässige Abschreibung vorzunehmen. Der net realizable value ergibt sich aus den geschätzten zukünftig erzielbaren Erträgen, unter Abzug der geschätzten noch anfallenden Kosten. Zu diesen Kosten zählen noch anfallende Herstellungskosten und Vertriebskosten, einschliesslich der Kosten der Wartung und des Kundenservices.268 Hinzu können auch Kosten für vertraglich zugesicherte Updates oder Erweiterungen kommen.

2.3.2.

2.3.3.

Offenlegung

Die IFRS geben vor, dass im Anhang die Restbuchwerte der einzelnen aktivierten Softwareprojekte, der Gesamtbetrag der in der Erfolgsrechnung enthaltenen Ab-schreibungen auf aktivierte Softwareaufwendungen sowie allenfalls Aufwendungen aufgrund von Wertminderungen der Software anzugeben sind. Zusätzlich werden Angaben bezüglich der zu Grunde gelegten Nutzungsdauern und angewandten Ab-schreibungssätze sowie der verwendeten planmässigen Abschreibungsmethoden verlangt.269

Bei den US-GAAP sind nach SFAS 86.11 im Anhang ebenfalls die Restbuchwerte der einzelnen aktivierten Softwareprojekte und der Gesamtbetrag der in der Erfolgs-rechnung enthaltenen Abschreibungen auf aktivierte Softwarekosten anzugeben sowie gegebenenfalls die Abschreibungsbeträge auf den net realizable value.

Beurteilung aus Sicht der externen Analyse

Aus Sicht der externen Analyse270 muss festgestellt werden, dass die bestehenden Regelungen sowohl der IFRS als auch der US-GAAP zur Berichterstattung über Standard-Software zu unbefriedigenden Resultaten führen. Dabei scheint das von beiden Standardsettern verwendete Kriterium technische Realisierbarkeit zur Unter-scheidung von Forschung und Entwicklung problematisch. So meinen KIESO ET AL., dass die alleinige Orientierung der bilanziellen Behandlung an dem Zeitpunkt der technischen Realisierbarkeit dazu führe, dass der Bilanzierende durch bewusste Sachverhaltsgestaltung die Bilanzierungsweise beeinflusst (bzw. beeinflussen

268 Vgl. Pirker (1997), S. 98. 269 Vgl. IAS 38.107. 270 Vgl. zu den Anforderungskriterien der externen Analyse Teil III dieser Dissertation.

Page 121: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 103

kann).271 Damit wird insbesondere die Anforderung der representational faithful-ness unterlaufen, die fordert, dass die Bilanzierung nicht irreführend sein darf.

Wie in den Fallstudien in diesem Kapitel erläutert, sind in der Praxis Indizien zu beobachten, dass die ungenügende Bestimmung des Abgrenzungszeitpunktes durch das Kriterium technische Realisierbarkeit zu divergierenden Bilanzierungs-methoden der Unternehmen geführt hat. Dabei haben sich zwei völlig unterschiedli-che Rechnungslegungspraktiken durchgesetzt. Während die eine Gruppe von Un-ternehmen ihre Ausgaben für die Entwicklung von Software konsequent aktiviert, stellen sich andere Unternehmen auf den Standpunkt, dass die technische Realisier-barkeit in keinem Stadium der Entwicklungsphase von Software als gegeben be-trachtet werden könne und entsprechend keine Aktivierung der Entwicklungskosten möglich sei. Diese divergierende Praxis, die aus externer Investorenperspektive als materiell unbegründet betrachtet werden muss, entspricht nicht der Anforderung der comparability/consistency, welche eine Vergleichbarkeit der Informationen auch im Inter-Unternehmensvergleich fordert. Die folgende Abbildung zeigt auf, inwiefern die beiden konkurrenzierenden Auslegungen der Rechnungslegungsvorschriften eine (insbesondere zeitliche) Diskrepanz bei den Gewinnausweisen und damit in der Erfolgsrechnung (bzw. der Bilanz) von Standard-Softwareunternehmen ergeben:

Keine Aktivierung von

Software-aufwendungen

Verbuchung der Aufwendungen über die Erfolgsrechnung

Aktivierung von Software-

aufwendungen

Jahr 1 Jahr 2 Jahr 3

Verkaufszeitpunkt des Softwareprodukts

Jahr 4 Jahr 5 Jahr 6

100

Abschreibungenüber die Erfolgsrechnung

Verä

nder

unge

n in

der

Erfo

lgsr

echn

ung

100 100

100100 100

Aktivierung der Aufwendungen von 300 in der Bilanz

Abbildung 17: Unterschiedliche Verbuchung von Softwareaufwendungen

271 Vgl. Kieso et al. (2004), S. 596f.

Page 122: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 104

Wie in obiger Abbildung erkennbar, fallen bei Unternehmen, welche keine Aktivie-rung ihrer Softwareaufwendungen vornehmen, in der Phase der Software-entwicklung Aufwendungen an, die der Erfolgsrechnung belastet werden müssen und somit den Gewinn schmälern. Unternehmen, welche ihre Aufwendungen akti-vieren, belasten ihren Gewinnausweis erst ab dem Zeitpunkt der Markteinführung des Produkts durch jährliche Abschreibungen, die sich meist über drei bis fünf Jahre erstrecken. Je nach gewählter Rechnungslegungspraxis ist es also möglich, die Be-lastung des Gewinnausweises über einen anderen Zeitraum vorzunehmen und somit zu steuern. Dabei zeigt sich in der Praxis, dass junge Unternehmen ohne starken finanziellen Rückhalt und um ein stabiles Bilanzbild bemüht, vielfach eine Aktivie-rung der Softwareaufwendungen vornehmen. Im Idealfall stehen damit dem nach der Produkteinführung anfallenden Abschreibungsaufwand entsprechende Lizenz-einnahmen gegenüber. Alle etablierten Standard-Softwareunternehmen belasten die Entwicklungsaufwendungen hingegen direkt der Erfolgrechnung, was ihnen einen grösseren Handlungsspielraum in der Gestaltung des Abschlusses beschert. So kön-nen erfolglose Projekte ohne grosse Öffentlichkeitswirksamkeit eingestellt werden, weil keine Bewertungskorrektur eines Aktivums notwendig ist. Zudem wird der Gewinnausweis bei der Produktlancierung nicht übermässig durch hohe und meist über einen sehr kurzen Zeitraum zu tätigende Abschreibungen belastet. Zusammen-gefasst ermöglicht die Nicht-Aktivierung einen geringeren Informationsfluss an die Investoren und somit einen grösseren Handlungsspielraum für das Management.

2.4. Berichterstattung über immaterielle Werte (ohne Software)

Immaterielle Werte272 stellen bei Standard-Softwareunternehmen einen zentralen Erfolgsfaktor und Werttreiber dar. Die Standardsetter des FASB und des IASB ge-hen dabei von einer sehr ähnlichen Vorstellung aus, was unter immateriellen Wer-ten verstanden werden soll. Als essenzielle Charakteristik für einen (immateriellen) Vermögenswert im bilanziellen Sinn wird gefordert, dass dem Unternehmen aus dem Aktivum voraussichtlich ein künftiger wirtschaftlicher Nutzen zufliesst, der das Ergebnis von Ereignissen aus der Vergangenheit ist, in der Verfügungsmacht

272 Wie bereits in Teil III 2.3 erläutert, wird Standard-Software separat von den übrigen immateriellen Werten behandelt.

Page 123: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 105

des Bilanzierenden steht und verlässlich bewertet werden kann.273 Die Definition des Aktivums ist somit dynamisch geprägt und stellt auf den zukünftigen ökonomi-schen Nutzen in Form von Einzahlungsströmen auf Unternehmensebene ab.274

Im SFAC 6 Elements of Financial Statements wird ein Vermögenswert folgender-massen definiert:275

“Assets are probable future economic benefits obtained or controlled by a particular entity as a result of past transactions or events.”

Die IFRS arbeiten mit einer ähnlichen Definition:276

“An asset is a resource controlled by the enterprise as a result of past events and from which future economic benefits are expected to flow to the enterprise.”

Beide Definitionen fordern somit folgende essenziellen Charakteristiken für einen Vermögenswert: Er muss einen zukünftigen wirtschaftlichen Nutzen repräsentieren, eine Folge einer Transaktion oder eines Ereignisses aus der Vergangenheit sein und der Kontrolle des Bilanzierenden unterliegen.

Finanzinstrumente werden sowohl von IFRS als auch von US-GAAP nicht den im-materiellen Werten zugerechnet. Auch Goodwill, der im Zuge eines Unternehmens-kaufs erworbene, jedoch nicht separat identifizierbare immaterielle Werte repräsen-tiert, fällt aufgrund seiner mangelnden Identifizierbarkeit nicht unter die Definition der immateriellen Werte.277 Entsprechend wird auf die Regelungen zu Finanzin-strumenten und Goodwill in der Dissertation nicht weiter eingegangen.

273 Vgl. IASB F.49. 274 Vgl. Fülbier et al. (2000), S. 835. 275 SFAC 6.25. 276 IASB F.49a. 277 Vgl. IAS 38.1f. und SFAS 142.4.

Page 124: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 106

2.4.1.

Bilanzierung und Bewertung

Ein Unternehmen kann über zwei Wege in den Besitz von immateriellen Werten gelangen: Zum einen hat es die Möglichkeit, immaterielle Werte selbst zu erstellen, zum anderen kann es (schon vorhandene) immaterielle Werte von Dritten erwerben.

Nach IFRS wird die Bilanzierung und Bewertung immaterieller Werte durch einen eigenen Standard, IAS 38 Immaterielle Vermögenswerte geregelt. Gemäss IAS 38 sind immaterielle Werte zu aktivieren, wenn sie die Definition eines immateriellen Vermögenswertes des IASB Rahmenkonzepts278 sowie weitere, spezifische An-satzkriterien279 erfüllen. Der erstmalige Bilanzansatz beläuft sich auf die angefalle-nen Herstellkosten280, die über die voraussichtliche Nutzungsdauer abzuschreiben sind.281 Die Folgebewertung zum fairen Wert ist für solche immateriellen Werte möglich, für die ein aktiver Markt besteht.282

Aufgrund der strengen Bilanzansatzbedingungen der IFRS kommen nur die im Rahmen der Forschung und Entwicklung283 getätigten Aufwendungen für eine Ak-tivierung als immaterielle Werte in Frage. Dem Forschungsbereich zuzuordnende Aufwendungen sind jedoch in der Periode, in der sie anfallen als Aufwand zu erfas-sen. Der Standardsetter folgt dabei der Überlegung, dass ein Unternehmen in der Forschungsphase eines Projekts nicht nachweisen kann, dass ein immaterieller Vermögenswert existiert, der einen voraussichtlichen künftigen wirtschaftlichen Nutzen erzeugen wird.284 Somit sind nur die Entwicklungsaufwendungen einer Ak-tivierung zugänglich.285 Dabei müssen jedoch zusätzlich zur Vermögenswert-

278 Vgl. IASB F.49a, wonach die Aktivierbarkeit eines Vermögenswertes erfordert, dass dem Unternehmen voraussichtlich ein künftiger wirtschaftlicher Nutzen zufliesst, der das Ergebnis einer Transaktion oder eines Ereignisses aus der Vergangenheit ist, in der Verfügungsmacht des Bilanzierenden steht und ver-lässlich bewertet werden kann.

279 Vgl. IAS 38.18. 280 Vgl. IAS 38.22. 281 Vgl. IAS 38.63. 282 Vgl. IAS 38.64. 283 Im Folgenden soll der Bereich „Forschung und Entwicklung“ ausschliesslich Forschung für eigene

Zwecke und nicht Auftragsforschung für Dritte umfassen. 284 Vgl. IAS 38.43. 285 Da aus prozessualer Perspektive die Entwicklungsphase der Forschungsphase nachgelagert ist, kann

angenommen werden, dass häufig erst in der Entwicklungsphase ein immaterieller Vermögenswert i-dentifiziert werden kann,

Page 125: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 107

definition und der Zuordnung zu den Entwicklungsaktivitäten folgende sechs Be-dingungen kumulativ erfüllt sein:286

• Technische Realisierbarkeit der Fertigstellung des immateriellen Vermö-genswertes,

• Absicht, den Vermögenswert fertig zu stellen,

• Fähigkeit den immateriellen Vermögenswert zu nutzen,

• Nachweis eines zukünftigen wirtschaftlichen Nutzens (intern oder durch Verkauf),

• Verfügbarkeit ausreichender technischer, finanzieller und sonstiger Ressour-cen zur Fertigstellung des Vermögensgegenstandes,

• Zuverlässige Bewertbarkeit der zurechenbaren Entwicklungskosten.

Herstellungskosten, welche die vorgenannten Bedingungen kumulativ erfüllen, sind pflichtgemäss zu aktivieren. Eine rückwirkende Aktivierung von zuvor als Aufwand verbuchten Kosten ist jedoch nicht zulässig.287 Von einer Aktivierung gänzlich aus-geschlossen sind Ausgaben für Gründung und Anlauf eines Geschäftsbetriebs, Aus- und Weiterbildung, Werbeaktionen und Reorganisationen.288 Zudem werden selbst geschaffener Goodwill289 sowie selbst geschaffene Markennamen, Drucktitel, Ver-lagsrechte, Kundenlisten und ihrem Wesen nach ähnliche Werte nicht als immate-rielle Vermögenswerte anerkannt und unterliegen somit einem Aktivierungsver-bot.290 Werden immaterielle Werte von Dritten erworben, so ist der Wert zu seinen Anschaffungskosten anzusetzen, welche üblicherweise zuverlässig bemessen wer-den können. Zu den Anschaffungskosten zählen dabei der Kaufpreis sowie direkt zurechenbare Kosten.291

286 Vgl. IAS 38.45. 287 Vgl. IAS 38.59. 288 Vgl. IAS 38.57. 289 Vgl. IAS 38.36. 290 Vgl. IAS 38.51f. 291 Vgl. IAS 38.23f.

Page 126: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 108

Bei den US-GAAP wird die Bilanzierung und Bewertung sowohl von selbst erstell-ten als auch von derivativ erworbenen immateriellen Werten grundsätzlich durch SFAS 142 Goodwill and Other Intangible Assets abgedeckt.292 So ist bestimmt, dass selbst geschaffene immaterielle Werte mit ihren Aufwendungen zu aktivieren sind, sofern sie eindeutig identifizierbar293 sind, eine begrenzte Nutzungsdauer ha-ben und die Vermögenswertdefinition der SFAC erfüllen.294 Diese generelle Be-stimmung ist auf alle immateriellen Werte anzuwenden, doch es bestehen in zahl-reichen Bereichen Spezialvorschriften, welche Vorrang geniessen. Die wesentlichs-te Einschränkung bei der Aktivierung von intern generierten immateriellen Werten ergibt sich durch SFAS 2 Accounting for Research and Development Costs, wonach Aufwendungen für Forschung und Entwicklung grundsätzlich in der Anfallperiode aufwandswirksam zu berücksichtigen sind.295 Diese Haltung basiert im Wesentli-chen auf der Argumentation, dass die zukünftigen wirtschaftlichen Nutzenzuflüsse unsicher seien, ein kausaler Zusammenhang zwischen den Ausgaben und dem zu-künftigen Nutzen fehle, die Bewertbarkeit (measurability) der zukünftigen Nutzen-zuflüsse nicht möglich sei und es den Informationen an Relevanz mangle, um das Ertragspotenzial des Unternehmens wiederzugeben.296 Diese Argumente waren und sind in der Wissenschaft stark umstritten. Insbesondere BIERMAN/DUKES haben die Argumente des FASB hinterfragt und stellen in ihrem Artikel Accounting for Re-search and Development Costs verschiedene Studien vor, welche bezüglich der Un-sicherheit des zukünftigen Nutzens, dem fehlenden kausalen Zusammenhang und der mangelnden Relevanz, zu anderen Ergebnissen als das FASB kommen.297 Nicht zuletzt unternahm das FASB selbst eine teilweise faktische Kehrtwende mit der

292 Der SFAS 142 ersetzt seit dem Juni 2001 den APB 17 Intangible Assets, wobei jedoch alle Regelungen bezüglich selbst erstellter immaterieller Werte von APB 17 ohne Änderungen weiter verwendet wurden. Vgl. SFAS 142.2.

293 Die Identifizierbarkeit wird von APB 17 jedoch nicht definiert. Es werden lediglich Beispiele wie Pa-tente, Konzessionen und Warenzeichen genannt. Vgl. ausführlich von Keitz (1997), S. 117f.

294 Vgl. SFAC 6.25, wonach dann ein Vermögenswert vorliegt, wenn dem bilanzierenden Unternehmen aus einem Ereignis in der Vergangenheit ein zukünftiger wirtschaftlicher Nutzen zufliesst, der in der Verfügungsmacht des Unternehmens steht. Gemäss SFAC 5.63 ist zusätzlich erforderlich, dass der Wert des Vermögenswertes verlässlich messbar ist und dessen Bilanzierung einen zusätzlichen Erkenntnis-gewinn bringt (relevance).

295 Vgl. SFAS 2.12. 296 Vgl. Upton (2001), S. 65. 297 Vgl. Bierman/Dukes (1975), S. 48-55.

Page 127: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 109

Einführung von SFAS 86, welches eine Konkretisierung von SFAS 2 für Software sein sollte. Beim SFAS 86 nahm das FASB die Unterscheidung von erfolgswirksa-men Software-Forschungsausgaben bzw. erfolgsneutralen Software-Entwicklungs-ausgaben nach dem Kriterium der technischen Realisierbarkeit vor. Dieses Kriteri-um diskutierte das FASB bereits bei der Erarbeitung von SFAS 2. Damals lehnte das FASB jedoch die selektive Aktivierung von Ausgaben, die bestimmte Kriterien erfüllen, mit der Begründung ab, dass kein Kriterium zu objektiven und vergleich-baren Bilanzierungsmethoden führen würde.298 Insofern kann nicht von einer inhalt-lichen Konkretisierung von SFAS 2 durch SFAS 86 gesprochen werden. Vielmehr wird im Schrifttum häufig SFAS 86 als Ausnahmeregelung von SFAS 2 aufge-fasst.299

Für immaterielle Werte, die von Dritten erworben worden sind, besteht daher eine Aktivierungspflicht nach dem fair value.300 So dient der Erwerb als solcher bereits als ein deutliches Zeichen für das Vorliegen eines wahrscheinlichen zukünftigen wirtschaftlichen Nutzens. Durch den Erwerbsakt kommt zusätzlich ein zuverlässig ermittelter Wert des jeweiligen Vermögenswertes zum Ausdruck, wodurch bei ei-nem derartigen Erwerb die Information über die Existenz und die Bewertung des immateriellen Wertes in der Regel als verlässlich einzustufen ist.301

Sowohl US-GAAP als auch IFRS unterscheiden immaterielle Werte mit bestimmter und unbestimmter Nutzungsdauer. Immaterielle Werte mit bestimmter Nutzungs-dauer sind über ihre Nutzungsdauer abzuschreiben und haben den Nutzungsverlauf wiederzugeben bzw. falls nicht möglich, sind sie linear abzuschreiben.302 Der Ver-mögenswert ist darüber hinaus regelmässig einem Werthaltigkeitstest (impairment test) nach IAS 36 bzw. SFAS 121 Accounting for the Impairment of Long-Lived Assets and for Long-Lived Assets to Be Disposed Of zu unterziehen. Liegt dabei der Buchwert des Wertes zum Bilanzstichtag über dem net realizable value, so ist eine ausserordentliche Abschreibung in der Höhe des Differenzbetrages vorzunehmen. Der net realizable value ist bestimmt als die geschätzten zukünftigen erzielbaren

298 Vgl. SFAS 2.53f. 299 Vgl. zur Übersicht von Keitz (1997), S. 147. 300 Vgl. SFAS 142.9. 301 Vgl. Diamond/Nicolaisen (1997), S. 14-14. 302 Vgl. IAS 38.97 und SFAS 142.12.

Page 128: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 110

Erträge unter Abzug der geschätzten noch anfallenden Kosten. Immaterielle Werte mit unbestimmter Nutzungsdauer sind nicht planmässig abzuschreiben und in jeder Berichtsperiode ist erneut zu prüfen, ob die Ereignisse und Gegebenheiten weiterhin die Einschätzung einer unbestimmten Nutzungsdauer stützen.303 Ist eine Änderung der Nutzungsdauer angezeigt, so ist der Vermögenswert darüber hinaus auf Wert-minderung zu prüfen. Wie bei Software sind ausserplanmässige Abschreibungen nach IAS 36.58f. dann vorzunehmen, wenn bei der Werthaltigkeitsüberprüfung der aktivierten immateriellen Werte, der höhere der beiden erzielbaren Beträge aus dem Nettoverkaufswert oder dem Nutzungswert den Buchwert des Vermögenswertes unterschreitet.304

2.4.2.

Offenlegung

IAS 38.107ff. regelt die umfangreichen Offenlegungserfordernisse bei immateriel-len Werten im Rahmen der IFRS. Danach sind für selbst geschaffene immaterielle Werte die angewandten Abschreibungsmethoden und ihre Dauern anzugeben sowie die Positionen in der Erfolgsrechnung, welche Abschreibungen enthalten. Hinzu kommen Angaben zu den Anfangsbeständen, Zu- und Abgängen sowie Endbestän-den der historischen Kosten und der kumulierten Abschreibungen.305 Nach IAS 38.113a) ist zudem bei einer Neubewertung immaterieller Werte auch der alternati-ve Buchwert nach historischen Kosten anzugeben. Die Höhe der Forschungs- und Entwicklungsausgaben, welche als Aufwand verbucht werden, ist für jedes Jahr of-fen zu legen.306 Zudem empfiehlt IAS 38.117 den Unternehmen Informationen so-wohl über immaterielle Werte, die in der Verfügungsmacht des Unternehmens ste-hen, aber den Anforderungen der Aktivierbarkeit nicht genügen, als auch über abge-schriebene, aber noch immer genutzte immaterielle Vermögenswerte zu vermitteln.

Die Offenlegungsvorschriften für selbst geschaffene immaterielle Werte ergeben sich in den US-GAAP aus zahlreichen Sonderbestimmungen. Für den Bereich F&E schreibt SFAS 2 vor, dass für jede dargestellte Abschlussperiode die gesamten For-

303 Vgl. IAS 38.109 und SFAS 142.16. 304 Vgl. dazu die ausführlichen Erläuterungen in Abschnitt IV 2.2.3. 305 Vgl. IAS 38.107. 306 Vgl. IAS 38.115.

Page 129: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 111

schungs- und Entwicklungsaufwendungen anzugeben sind.307 Bei Ausgaben für Marketing und Werbung sind nach SOP 93-7.49 Reporting on Advertising Costs die Bilanzierungsgrundsätze zu erläutern und bei aktivierten Aufwendungen Angaben über deren Art sowie die Bewertungs- und Abschreibungsmethoden zu machen. Für alle immateriellen Werte gelten zudem grundsätzlich die Regelungen des APB 12 Omnibus Opinion über die Offenlegung einer aussagekräftigen Klassifikation aller Aktiva mit beschränkter Nutzungsdauer, die Angabe von deren historischen Kosten, der Höhe der akkumulierten und der im Geschäftsjahr aufgelaufenen Abschreibun-gen sowie eine Beschreibung der angewandten Abschreibungsmethoden.

2.4.3. Beurteilung aus Sicht der externen Analyse

Wie in Teil III dieser Dissertation erläutert wurde, sind für die externe Analyse die grundlegenden Dimensionen Relevanz (relevance) und Reliabilität (reliability) zentral für die Beurteilung, ob Informationen entscheidungsrelevant und somit nütz-lich für den externen Investor sind. Die folgende Analyse basiert somit auf diesem Kriterienkatalog.

In der heutigen Rechnungslegung lässt sich eine Inkonsistenz in der Behandlung von immateriellen Werten feststellen – und zwar sowohl innerhalb der jeweiligen Rechnungslegungssysteme als auch zwischen ihnen. So können viele von Dritten erworbene immaterielle Werte in der Bilanz angesetzt werden, während dies der gleichen Art von immateriellen Werten, die jedoch intern entwickelt werden meist aufgrund des fehlenden Nachweises ihrer Existenz bzw. des zukünftigen wirtschaft-lichen Nutzens verweigert wird:

Fallstudie 19

Nach einer Erhebung von INTERBRAND wird der Wert der Marke Microsoft auf rund 60 Mia. US$ geschätzt. Sie ist somit nach Coca-Cola die zweitwertvollste Marke der Welt.308 Dennoch ist die Marke nicht als Aktivum in der Bilanz von Microsoft vorzufinden. Dies ist darauf zurückzuführen, dass es sich bei der Marke

307 Vgl. SFAS 2.13. 308 Vgl. o.V. (2005c), S. 3.

Page 130: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 112

Microsoft um einen intern entwickelten Wert handelt, welchem sowohl nach IFRS als auch nach US-GAAP eine Aktivierung verweigert wird.

Demgegenüber hat das Grafiksoftwareunternehmen Adobe mit dem im Jahre 2005 erfolgten Aufkauf des Konkurrenten Macromedia (mit den bekannten Produkten Dreamweaver und Flash) grundsätzlich die Möglichkeit, die ebenfalls erworbene Marke Macromedia bzw. Dreamweaver und Flash in der Bilanz anzusetzen, weil ein zuverlässig ermittelbarer Kaufpreis aufgewendet wurde.

Fallstudie 19: Aktivierung von Marken

Die Tatsache, dass alleine die Art des Zugangs eines immateriellen Wertes eine völ-lig unterschiedliche Behandlung durch die Rechnungslegung begründet, ist insbe-sondere unter dem Gesichtspunkt der Forderung der comparability/consistency kri-tisch zu betrachten. Ebenfalls ist eine Einschränkung der comparability/consistency zwischen den Geschäftsabschlüssen nach IFRS und US-GAAP festzustellen. So wird von den IFRS für Entwicklungsaufwendungen grundsätzlich ein Ansatzge-bot309 vorgeschrieben, während dieses die US-GAAP ablehnen und nur für Einzel-fälle eine Aktivierung bei Erfüllung der Ansatzkriterien erlauben wie zum Beispiel bei eigenen Aufwendungen für die Softwareentwicklung.

2.5. Zukunftsbezogene Berichterstattung

In allen Teilen der Rechnungslegung sind implizite Vorhersagen über die Zukunft vorhanden. Sie reichen von grundsätzlichen Aspekten wie der Bilanzierung unter der Annahme der Unternehmensfortführung bis hin zu Bewertungsfragen wie zum Beispiel der Bestimmung von wirtschaftlich korrekten Abschreibungsdauern. Es ist jedoch übertrieben, alle diese Aspekte als Elemente einer zukunftsbezogenen Be-richterstattung zu bezeichnen. Es kann bei Ausweis- und Bewertungsfragen im Zu-sammenhang mit einer zutreffenden Darstellung der aktuellen wirtschaftlichen Lage höchstens von einer impliziten Zukunftsbezogenheit gesprochen werden. Diese muss von der expliziten zukunftsbezogenen Berichterstattung unterschieden werden, welche die Vorhersage zukünftiger Ereignisse als zentrales Anliegen hat.

309 Bei Erfüllung der entsprechenden Ansatzkriterien. Vgl. Abschnitt IV 2.4.1.

Page 131: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 113

2.5.1.

2.5.2.

Regelungen von IFRS und US-GAAP

Es ist festzustellen, dass sowohl die IFRS als auch die US-GAAP kaum Regelungen bereitstellen, die sich explizit mit Fragen zukunftsbezogener Berichterstattung aus-einandersetzen.310 Es finden sich bei beiden Regelwerken einzig Anforderungen bezüglich der Offenlegung von zukünftigen finanziellen Verpflichtungen, sofern diese am Bilanzstichtag aufgrund bestehender Verträge bereits begründet sind. Dies trifft insbesondere auf Leasingverhältnisse zu. So müssen Leasingnehmer gemäss IFRS die Summe der zukünftigen Mindestleasingzahlungen zum Bilanzstichtag und deren Barwert für die Perioden bis zu einem Jahr, der vier darauf folgenden Jahre und der gesamten Jahre danach angeben.311 Nach den US-GAAP ist es erforderlich, für financial leases die Offenlegung der Zahlungen der nächsten fünf Jahre auf Jah-resbasis und für operating leases zusätzlich die Angabe der danach anfallenden Zahlungen offen zu legen.312 Die US-GAAP kennen zudem branchenspezifische Sonderregelungen im Bereich der Medienindustrie sowie für rohstoffabbauende Unternehmen – jedoch nicht für (Standard-)Softwareunternehmen.

Es ist somit zusammenfassend festzustellen, dass abgesehen von einigen branchen-spezifischen Besonderheiten der US-GAAP und sehr allgemeinen Bedingungen im Rahmen der IFRS bislang praktisch keine verpflichtenden Anforderungen existie-ren, die der besonderen „Zukunftsbezogenheit“ von (Standard-)Softwareunter-nehmen Rechnung tragen.

Beurteilung aus Sicht der externen Analyse

Im Rahmen der Kriterien predictive value und in vermindertem Masse auch des feedback value wird gefordert, dass die unternehmerische Berichterstattung Progno-sen über die Zukunft sowie deren späteres Eintreten oder Ausbleiben ermöglichen soll. Weder die IFRS noch die US-GAAP haben explizite Standards entwickelt, welche diese Forderungen erfüllen. Dieser Umstand ist insbesondere für die externe Analyse von Standard-Softwareunternehmen äusserst unbefriedigend, weil der Er-

310 IAS 1.8 empfiehlt Unternehmen, ausserhalb des Abschlusses einen Bericht über die Unternehmenslage durch das Management zu veröffentlichen.

311 Vgl. IAS 17.23 für financial leases und IAS 17.25 für operating leases. 312 Vgl. SFAS 13.16.

Page 132: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 114

folg von Standard-Softwareunternehmen in grossem Masse von zukünftigen Ent-wicklungen abhängig ist.

3. Zusammenfassung: Nutzen der bestehenden Rechnungsle-gung für Investoren

Am Ende von Teil III wurde gefolgert, dass die Informationsbedürfnisse von Inves-toren bei der externen Analyse am besten durch diejenigen Rechnungslegungssys-teme erfüllt werden, welche die Anforderungen der Maxime des Entscheidungsnut-zens (decision usefulness) befolgen. Die in diesem Teil vorgenommene Analyse der Rechnungslegung von Standard-Softwareunternehmen hat nun untersucht, inwie-weit die bestehenden Rechnungslegungsnormen diese Forderung bereits erfüllen.

Zusammenfassend kann gefolgert werden, dass die aktuellen Rechnungslegungs-vorschriften, die Standard-Softwareunternehmen betreffen, einige Schwächen im Hinblick auf die Erfüllung der Anforderungen der Maxime des Entscheidungsnut-zens (decision usefulness) aufweisen und entsprechend keinen optimalen Nutzen für den externen Investor bieten. Diese Schwächen können unter den Stichworten un-genügende comparability/consistency und mangelhafte representational faithfulness zusammengefasst werden. Die comparability ist sowohl innerhalb als auch zwi-schen den Rechnungslegungssystemen kaum gegeben. Typisches Beispiel für eine ungenügende innere comparability ist die Behandlung von immateriellen Werten wie Marken, welche bei interner Generierung nicht aktiviert werden dürfen, wohl aber, wenn sie erworben werden. Mangelnde comparability zwischen den Rech-nungslegungswerken ergibt sich ebenso bei immateriellen Werten wie Forschung & Entwicklung, wo eine Aktivierung unter bestimmten Bedingungen gefordert oder vollkommen abgelehnt wird. Die mangelhafte representational faithfulness ist bei den Regelungen zur Umsatzrealisierung gegeben, wo die IFRS von einer Regelung der populären Vereinbarungen mit mehreren Komponenten absehen und die US-GAAP aufgrund von weitgehenden Ausnahmeregelungen den Anbietern ein fakti-sches Wahlrecht zugestehen. Dies kann soweit führen, dass die Rechnungslegung die Transaktionsgestaltung bestimmt und somit die Realität nach dem Modell kon-struiert wird.

Page 133: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL IV: ANALYSE DER RECHNUNGSLEGUNG VON STANDARD-SOFTWAREUNTERNEHMEN 115

Vor diesem Hintergrund soll der nächste Teil dieser Dissertation der Entwicklung eines Rahmenkonzepts für die Rechnungslegung von Standard-Softwareunter-nehmen gewidmet sein, welches die Informationsbedürfnisse von externen Investo-ren im Rahmen der externen Analyse erfüllt.

Page 134: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 116

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen

1. Einleitung

1.1. Ziel des Rahmenkonzeptes

In Teil III dieser Dissertation wurden die Anforderungen an die Rechnungslegungs-informationen im Rahmen der externen Analyse von Investoren identifiziert, wobei in Abschnitt III 2 auf besondere Schwierigkeiten der Berichterstattung von Stan-dard-Softwareunternehmen eingegangen wurde. In Teil IV wurden die gegenwärtige Standardsetzung für Standard-Softwareunternehmen untersucht und teilweise Lü-cken und Mängel hinsichtlich der Befriedigung der Informationsbedürfnisse von Investoren identifiziert. Das Ziel dieses Teils der Dissertation ist es nun, ein Rah-menkonzept für die Rechnungslegung von Standard-Softwareunternehmen zu ent-wickeln, welches die in Teil III identifizierten Informationsbedürfnisse der externen Investoren optimal befriedigen kann.

1.2. Methodologie

Im Hinblick auf die Methodologie soll jeder Problembereich der Rechnungslegung (Umsatzerfassung, Immaterielle Werte (ohne Software), Standard-Software, und Zukunftsbezogene Berichterstattung) in einem separaten Kapitel behandelt werden. In den jeweiligen Kapiteln soll die folgende Struktur angewendet werden: Im ersten Unterkapitel (Einleitung) werden die bestehenden Rechnungslegungspraktiken nach IFRS und US-GAAP kurz zusammengefasst und ihre Eignung für den externen In-vestor dargestellt werden. In einem zweiten Unterkapitel (Optionen) werden mögli-che Rechnungslegungsoptionen zu diesem Themenkreis identifiziert. Im dritten Subkapitel (Entscheidungsnutzenanalyse) werden die Optionen anhand der in Teil III bestimmten Anforderungen evaluiert. Das Ziel dabei ist es, diejenige Option zu identifizieren, welche den grössten Nutzen für ein investororientiertes Rahmen-konzept der Rechnungslegung bietet. Letztendlich fasst das vierte Unterkapitel (Fa-

Page 135: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 117

zit) die Resultate zusammen und beleuchtet diejenige Option, welche am besten die Informationsbedürfnisse der Investoren erfüllt.

1.3. Übersicht

Die folgende Übersicht zeigt eine Zusammenfassung der Zielsetzung und der Struk-tur von Teil V dieser Dissertation. Dabei werden die vier in Abschnitt III 2 identifi-zierten Problembereiche der Rechnungslegung von Standard-Softwareunternehmen jeweils in separaten Kapiteln behandelt:

1. Umsatzerfassung 1.1. Einleitung 1.2. Optionen 1.3. Entscheidungsnutzenanalyse 1.4. Fazit

2. Standard-Software 2.1. Einleitung 2.2. Optionen 2.3. Entscheidungsnutzenanalyse 2.4. Fazit

3. Immaterielle Werte (ohne Software)3.1. Einleitung 3.2. Optionen 3.3. Entscheidungsnutzenanalyse 3.4. Fazit

4. Zukunftsbezogene Berichterstattung 4.1. Einleitung 4.2. Optionen 4.3. Entscheidungsnutzenanalyse 4.4. Fazit

Entscheidungsnutzenanalyse

Investorenorientiertes Rahmenkonzept für die Rechnungslegung von Standard-Softwareunternehmen

Abbildung 18: Ziel und Struktur von Teil V

2. Umsatzerfassung

2.1. Einleitung

Bei der Erfassung von Erträgen können grundsätzlich zwei Modelle, der realizati-on-and-earnings Ansatz und der asset-and-liability Ansatz, voneinander unter-schieden werden. Der realization-and-earnings Ansatz orientiert sich an einem dy-

Page 136: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 118

namischen Bilanzbegriff, der die primäre Aufgabe der Rechnungslegung in der pe-riodengerechten Gewinnermittlung sieht, indem die Erträge und Aufwendungen nach dem accrual principle auf die laufende und die zukünftigen Perioden verteilt werden. Dadurch ist die Abgrenzung von Leistungserstellungsprozessen notwendig, was entsprechend zur Bilanzierung von Abgrenzungsposten aus nicht abgeschlosse-nen Transaktionen (wie zurückgestellten Umsätzen313) führt. Unter diesem Ansatz wird der Wert eines Unternehmens durch seine Ertragskraft widerspiegelt und dem-entsprechend stellt die Erfolgsrechnung das wichtigste Instrument der Rechnungs-legung dar. Im Gegensatz zum realization-and-earnings Ansatz nimmt der asset-and-liability Ansatz eine statische Bilanzauffassung ein und zielt auf die korrekte Ermittlung des Vermögens und der Schulden eines Unternehmens zum Bilanzstich-tag ab.314 Die Umsatzerfassung beruht somit im Grundsatz auf Veränderungen von zu beizulegenden Zeitwerten bewerteten Vermögenswerten und Verpflichtungen während einer Periode.

In den Rechnungslegungssystemen von IFRS und US-GAAP finden sich sowohl Einflüsse des realization-and-earnings Ansatzes als auch des asset-and-liability Ansatzes. Insbesondere in den Regelungen zur Umsatzerfassung zeigen sich Ein-flüsse von beiden Ansätzen und die daraus resultierenden Widersprüche. So besteht bei IFRS und US-GAAP ein Gegensatz zwischen der Definition von Umsatz, wel-che auf den Veränderungen von Vermögenswerten und Verpflichtungen beruht und den zugehörigen Vorschriften zur Umsatzrealisierung, welche im Wesentlichen auf die Abgrenzung von Leistungserstellungsprozessen abstellen. Beim IAS 18 Erträge findet sich eine Hinwendung zum realization-and-earnings Ansatz.315 Ertrag wird definiert als „aus der gewöhnlichen Tätigkeit eines Unternehmens resultierender Bruttozufluss wirtschaftlichen Nutzens während der Berichtsperiode, wenn die je-weiligen Zuflüsse das Eigenkapital unabhängig von Einlagen der Anteilseigner er-höhen.“316 Diese Definition ist nicht konsistent mit dem asset-and-liability Ansatz des IASB Rahmenkonzepts, welches Ertrag folgendermassen definiert:317

313 Vgl. Abschnitt IV 2.2.2.3. 314 Vgl. Pilhofer (2002), S. 26. 315 Vgl. dazu die Fallstudie 12. 316 IAS 18.7 317 Vgl. IASB F.70a.

Page 137: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 119

“Income is increases in economic benefits during the accounting period in the form of inflows or enhancements of assets or decreases of liabili-ties that result in increases in equity, other than those relating to contri-butions from equity participants.”

Bei den US-GAAP zeichnet sich das grundlegende SFAC 5 Recognition and Mea-surement in Financial Statements of Business Enterprises durch die Anwendung des realization-and-earnings Ansatzes aus.318 Auch das im November 2002 in Kraft ge-tretene EITF 00-21 Accounting for Revenue Arrangements with Multiple Delive-rables, welches eine Verbesserung der Bestimmungen zu Vereinbarungen mit meh-reren Komponenten (multiple element arrangements) zum Ziel hat, zeichnet sich durch die Hinwendung zum realization-and-earnings Ansatz aus.319 Das für Soft-wareunternehmen massgebliche SOP 97-2 Software Revenue Recognition folgt hin-gegen im Grundsatz dem asset-and-liability Ansatz.

2.2. Optionen

2.2.1.

Vorschläge der Standardsetter

Die im vorherigen Unterkapitel aufgezeigten unterschiedlichen und teilweise inkon-sistenten Rechnungslegungsvorschriften im Bereich der Umsatzerfassung wurden von den Standardsettern erkannt. Aus diesem Grund riefen im Juni 2002 das IASB und das FASB ein gemeinsames Projekt (joint project) zum Thema Umsatzerfas-sung (revenue recognition) ins Leben. Die Ziele dieses Projekts sind folgendermas-sen umschrieben:320

• Eliminierung von Inkonsistenzen in der existierenden Rechnungslegungs-literatur und den akzeptierten Praktiken,

• Beseitigung der Lücken, welche in den Vorschriften zur Umsatzrealisierung in den letzten Jahren aufgetaucht sind,

• Aufbau einer konzeptionellen Basis.

318 Vgl. FASB (2006). 319 Vgl. FASB (2000). 320 Vgl. FASB (2006).

Page 138: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 120

Im Fall der IFRS soll zudem IAS 18 hinsichtlich seiner mangelhaften Behandlung von Vereinbarungen mit mehreren Komponenten (multiple element arrangements) verbessert werden.

Die gemeinsame Arbeitsgruppe von FASB und IASB unterscheidet in der Frage der Umsatzerfassung grundsätzlich die zwei Ansätze, welche bereits im vorherigen Un-terkapitel vorgestellt wurden: Der realization-and-earnings Ansatz und der asset-and-liability Ansatz.321 Wie bereits erwähnt, nimmt der realization-and-earnings Ansatz eine dynamische Perspektive ein und fokussiert auf die periodengerechte Bemessung des Umsatzes und des Gewinns eines Unternehmens, während der as-set-and-liability Ansatz eine statische Perspektive einnimmt und auf die korrekte Bemessung der Veränderungen der Aktiven und Passiven eines Unternehmens ab-zielt. Die praktischen Unterschiede der beiden Modelle lassen sich am besten an folgender Fallstudie illustrieren:322

Fallstudie 20

Das Softwareunternehmen X verkauft Standard-Software mit einem einjährigen Gratis-Telefonsupport zu einem Preis von 1000. Zusätzlich bietet das Unternehmen einen erweiterten Telefonsupport für 100 an, welcher zum einjährigen Gratis-Support weitere zwei Jahre Telefonsupport gewährt. Der bezahlte Preis kann nicht zurückerstattet werden. Das Unternehmen X kann den Telefonsupport selbst zur Verfügung stellen oder bezahlt einen zuverlässigen Drittanbieter, um diese Aufgabe zu übernehmen. Statistische Berechnungen zeigen, dass nur 80% der Kunden den Telefonsupport in Anspruch nehmen und dies mit einer Kostenfolge von rund 110 pro Kunde zu Buche schlägt. Zuverlässige Drittanbieter sind bereit, den Telefon-support für 90 pro Vertragsabschluss zu übernehmen. Am 1. Juni 2005 verkauft das Softwareunternehmen X zehn Softwarelizenzen mit erweitertem Telefonsupport und erhält dafür den vollen Verkaufspreis in bar.

321 Vgl. FASB (2006). 322 Abgewandelte Fallstudie auf der Grundlage von FASB Case in Point: Consumer Electronics Retailer.

Vgl. FASB (2004).

Page 139: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 121

Welchen Umsatz soll das Unternehmen X nun am 1. Juni 2005 verbuchen, falls (Fall A) das Unternehmen X sofort den Drittanbieter beauftragt, um den Telefon-support zu übernehmen? (Fall B) das Unternehmen X den Telefonsupport selber übernimmt?

Fallstudie 20: Standard-Softwareunternehmen X

Dieses Beispiel kann anhand der involvierten Aktivitäten analysiert werden: (1) Verkauf der Softwarelizenz, (2) Lieferung der Software, (3) Verkauf des Telefon-supports, (4) Erbringung des Telefonsupports. Am 1. Juni 2005 hat das Softwareun-ternehmen X die ersten drei dieser Aktivitäten erfüllt und nur die Erbringung des Telefonsupports steht aus. Der Unterschied zwischen dem assets-and-liabilities An-satz und dem realization-and-earnings process Ansatz kann durch die Unterschiede bei der Umsatzerfassung am 1. Juni 2005 illustriert werden. Die Differenzen sind darauf zurückzuführen, wie der Telefonsupport erbracht wird.

Der realization-and-earnings process Ansatz stützt sich nach dem Realisationsprin-zip auf den Zeitpunkt ab, zu dem die Leistung im Wesentlichen erbracht wurde. In diesem Beispiel hängt der Realisationszeitpunkt des Umsatzes einzig davon ab, ob der Leistungserstellungsprozess abgeschlossen ist. Im Fall A wird die Leistungs-erbringung hinsichtlich der Softwareverkäufe und des Telefonsupports im Ver-kaufszeitpunkt als abgeschlossen betrachtet, da das Softwareunternehmen X einen Drittanbieter für die Erbringung des Telefonsupports beauftragt hat. Entsprechend verbucht das Unternehmen X 11000 [10*(1000 + 100)] oder, falls es nur als Ver-mittler für den Drittanbieter tätig ist, 10100 [10*(1000 + 100 - 90)]. Im Fall B wird die Umsatzrealisierung hinsichtlich der Softwareverkäufe am 1. Juni 2005 als abge-schlossen betrachtet, während der Telefonsupport noch nicht komplettiert ist, da das Unternehmen den Telefonsupport selber erbringt. Das Unternehmen X realisiert den Umsatz von 10000 (für die Software) und stellt den Umsatz von 1000 (für den Tele-fonsupport) als deferred revenues zurück. Wichtig ist zu beachten, dass das Unter-nehmen X in beiden Fällen A und B die gleichen Aktivitäten vollbracht hat, also den Verkauf der Software und des Telefonsupports. Trotzdem wird unter dem reali-zation-and-earnings process Ansatz am 1. Juni ein Umsatz von 11000 bzw. 10100 im Fall A und ein Umsatz von 10000 im Fall B realisiert.

Page 140: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 122

Der assets-and-liabilities Ansatz fokussiert auf stattgefundene Veränderungen in den Aktiven und Passiven in der Bilanz und misst die erhaltenen Vermögenswerte und eingegangenen Verbindlichkeiten zu ihrem fairen Wert (bzw. customer based value - CBV)323. Das Unternehmen X erhält am 1. Juni 2005 11000 in bar und geht gleichzeitig eine Verpflichtung für die Erbringung des Telefonsupports ein, welche einen fairen Wert (bzw. CBV) von 900 (den Preis, welchen ein verlässlicher Dritt-anbieter verlangen würde) hat. Die dadurch resultierende Erhöhung des Eigenkapi-tals um 10100 ist als Umsatz einzuordnen. Die Übernahme des Telefonsupports durch einen Drittanbieter bewirkt keine Eigenkapitalveränderung, wodurch der zu realisierende Umsatz in Fall A und Fall B derselbe ist – unabhängig von der Ent-scheidung des Softwareunternehmens X im Hinblick auf die Ausgestaltung des Te-lefonsupports.

Der Umsatzausweis des Unternehmens X am 1. Juni 2005 basiert auf den bereits abgeschlossenen Softwareverkäufen und der Erbringungsart des ausstehenden Tele-fonsupports:

Umsatzausweis Unternehmen X am 1. Juni 2005

realization-and-earnings process Ansatz assets-and-liabilities Ansatz

Fall A 11000 (bzw. 10100) 10100

Fall B 10000 10100

Die Fallstudie zeigt typische Unterschiede des assets-and-liabilities Ansatzes ge-genüber dem realization-and-earning process Ansatz bei der Umsatzerfassung auf:

• Der Umsatznachweis beruht auf der Identifizierung von Vermögenswerten und Verpflichtungen zum Marktwert (bzw. CBV) und nicht auf der perio-dengerechten Abgrenzung von Leistungsprozessen und Erträgen.

• Die Umsatzerfassung benötigt keine bilanziellen Abgrenzungspositionen wie z. B. zurückgestellte Umsätze (deferred revenues). So handelt es sich bei Po-sition deferred revenues zwar um Verpflichtungen des Unternehmens, wel-che jedoch zumeist nicht akkurat abgebildet sind, da sie nicht – wie die Fall-

323 Siehe Abschnitt V 2.2.2.3 zur Erläuterung des customer based value (CBV).

Page 141: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 123

studie zeigt – dem Marktwert (bzw. CBV) der jeweiligen Leistungsverpflich-tung entsprechen.

• Umsätze werden unter Umständen früher als beim derzeitigen Ansatz erfasst, wo sie aufgrund von strengen Informationsanforderungen teilweise zu spät realisiert werden.

• Der erfolgte Umsatzausweis ist unabhängig von der Absicht des Manage-ments über die zukünftige Art der Leistungserbringung.

• Die Umsatzerfassung bei Verträgen mit mehreren Komponenten erfolgt nicht mehr nach komplexen Spezialregelungen, welche auf die Abgrenzung ver-schiedener Leistungsprozesse fokussiert sind, sondern basiert generell auf der Erfassung und Bewertung aller noch ausstehenden Leistungsverpflich-tungen zum Marktwert (bzw. CBV).

Der assets-and-liabilities Ansatz erscheint aus den obigen Gründen als interessanter Lösungsansatz und soll deshalb im nächsten Unterkapitel vertieft analysiert werden.

2.2.2.

Der assets-and-liabilities Ansatz

Der assets-and-liabilities Ansatz bildet sowohl bei den IFRS als auch bei den US-GAAP die Basis für die allgemeine Ertragsdefinition. Erträge werden als Zufluss wirtschaftlichen Nutzens definiert, welche als Folge einer Zunahme von Vermö-genswerten bzw. einer Abnahme von Verpflichtungen eine Erhöhung des Eigenka-pitals bewirken.

2.2.2.1. Umsatzabgrenzung

Um Umsätze von anderen Erträgen abzugrenzen, beschränken die heutigen Stan-dards den Umsatzausweis auf Erträge aus der ordentlichen und für das Unterneh-men typischen Geschäftstätigkeit.324 Nach dem joint project Vorschlag von IFRS und US-GAAP soll diese Abgrenzung aufgrund ihrer mangelhaften Trennschärfe ersetzt werden, wobei die zwei alternativen Ansätze des liability extinguishment

324 Vgl. SFAC 6.78 bzw. implizit IASB F.74ff.

Page 142: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 124

view und des broad performance view oder deren Kombination325 zur Diskussion stehen:326

Die liability extinguishment view wird folgendermassen beschrieben:

“Revenues are decreases in the reporting entity’s liabilities to customers resulting from the extinguishment of its performance obligations for which it is primarily liable. Those obligations are extinguished by pro-viding goods and services to customers, either directly by the reporting entity itself or indirectly by having third parties provide them on its be-half.”327

Aus Sicht des liability extinguishment view resultieren Erträge aus der Erfüllung von vertraglichen Verpflichtungen. Entsprechend setzt dieser Ansatz implizit die Existenz eines Vertrages mit einem Kunden voraus. Für das Outsourcing gewisser Vertragsleistungen an Dritte (subcontracting) gilt folgendes: Falls der Anbieter Dritte zur Erbringung der Vertragsleistung einbezieht und rechtlich für die Leis-tungserbringung verantwortlich bleibt, so erzielt er dann Umsätze, wenn der Dritte die Leistung erbracht hat und somit seine eigene Leistungsverpflichtung erfüllt ist.

Die broad performance view ist so definiert:

“Revenues are increases in the reporting entity’s assets (including in-flows of assets or enhancements of assets) or decreases in its liabilities resulting from activities that are integral to the provision of products (goods and services) by the entity itself that are ultimately destined for customers.”328

Der broad performance view zeichnet sich durch die Konzentration auf den Vollzug der eigenen Aktivitäten gegenüber dem Kunden aus. Entsprechend ist das Vorhan-

325 Darauf soll in der Dissertation nicht weiter eingegangen werden. Vgl. IASB (2003a), S. 4. 326 Vgl. IASB (2003g), S. 9. 327 IASB (2003a), S. 2. Die Definition beschränkt sich auf Fälle, bei denen die Kundenzahlung zu einer

Verbindlichkeit führt, welche durch die spätere Leistungserbringung des Anbieters getilgt wird. Diese Formulierung scheint damit enger als eigentlich beabsichtigt ausgelegt zu sein. Vgl. ausführlich Ab-schnitt V 2.3.2.

328 IASB (2003a), S. 3.

Page 143: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 125

densein eines Vertrages im Gegensatz zum liability extinguishment view nicht not-wendig. Beim Outsourcing von Vertragsleistungen an Dritte liegt unter dem broad performance view kein Umsatzvorgang vor, da der Anbieter keine eigenen Aktivitä-ten erbracht hat.

Beide Ansätze führen in der überwiegenden Mehrzahl der Fälle zu den gleichen Resultaten. Sie klassifizieren Umsatz als die Erbringung von Leistungen, welche für den Kunden bestimmt sind. Dadurch wird die heutige Differenzierung nach unter-nehmenstypischen Geschäftstätigkeiten obsolet und die Abgrenzungsschwierigkei-ten zu sonstigen betrieblichen Erträgen entfallen. Fundamentale Unterschiede zwi-schen den beiden Ansätzen sind beim Outsourcing von Vertragsleistungen an Dritte zu finden, bei denen keine rechtskräftige Übertragung stattfindet.329 So fordert der liability extinguishment view, dass der beim Outsourcing durch Dritte generierte Umsatz beim ursprünglichen Vertragspartner einen Umsatzvorgang auslöst, wäh-rend der broad performance view dies verneint. Entsprechend stellt sich in der Dis-kussion der beiden Ansätze die Frage, ob Umsätze aus Outsourcing für den ur-sprünglichen Vertragspartner eine andere Qualität haben als selbst generierte Erträ-ge.330 Der liability extinguishment view liefert zudem dem Investor durch den Um-satzrealisierungszwang eine bessere Informationsbasis zu Outsourcing-Aktivitäten als der broad performance view.

2.2.2.2. Umsatzrealisation

Umsätze beruhen beim assets-and-liabilities Ansatz auf Veränderungen von Ver-mögenswerten bzw. Schulden, welche durch die Erfüllung von Leistungspflichten ausgelöst werden. Entsprechend hängt die Umsatzrealisation davon ab, zu welchen Zeitpunkten bestimmte vertragliche Rechte und Pflichten die Anforderungen für den Ansatz als Vermögenswerte oder Schulden erfüllen. Damit ist für die Umsatz-realisation nicht mehr der Zeitpunkt des Abschlusses des Leistungsprozesses wie beim realization-and-earnings process entscheidend. Wie die Erfassung von Leis-tungspflichten und -rechten über die Vertragslaufzeit zu erfolgen hat, haben die

329 Findet jedoch beim Outsourcing ein vollständiger Rechtsübergang statt, so kommen beide Ansätze zum gleichen Schluss: Es findet kein Umsatzvorgang beim ursprünglichen Vertragspartner statt.

330 Vgl. zur Diskussion FASB (2003a), S. 2ff.

Page 144: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 126

Standardsetter in einem konzeptionellen Modell dargelegt, welches kurz erläutert werden soll:

In einem ersten Schritt legt dieses Modell fest, welche vertraglichen Rechte und Pflichten die Anforderungen für den Ansatz als Vermögenswert oder Schuld über-haupt erfüllen. Es existieren drei verschiedene Arten von vertraglichen Rechten und Pflichten:331

• Bedingte Rechte und Pflichten: Die Leistungspflicht bedingt den Eintritt ei-nes unsicheren Ereignisses, beispielsweise der Vertragserfüllung durch die Gegenpartei.

• Unbedingte Rechte und Pflichten: Die Fälligkeit der Leistung ist einzig von der Zeitkomponente abhängig.

• Fällige Rechte und Pflichten: Die Leistung steht unter keinem weiteren Vor-behalt und ist umgehend zu erbringen.

Entscheidend ist die Abgrenzung zwischen bedingten und unbedingten Rechten, welche an folgendem Beispiel aufgezeigt werden soll: Eine Partei übernimmt die Garantie für den Fall des Eintritts eines bestimmten ungünstigen Ereignisses (z. B. Software-Implementierung erfolgt nicht termingerecht). Der Garantiegeber hat nun ab Vertragsschluss die folgenden Verpflichtungen: (1) Die unbedingte Pflicht für den ökonomischen Schaden des Garantienehmers gerade zu stehen, falls das defi-nierte Ereignis eintritt (so genannte stand-ready obligation) und (2) die bedingte Pflicht, die Ansprüche des Garantienehmers zu erfüllen. Nach dem Vorschlag der Standardsetter sind nur unbedingte bzw. fällige Rechte und Pflichten in der Bilanz anzusetzen.332

In einem zweiten Schritt definiert das Modell die drei Phasen, welche ein Vertrag bis zu seiner Erfüllung durchläuft:333

331 Vgl. hierzu auch IASB (2003e), S. 2. 332 Sofern diese rechtlich durchsetzbar und dem Unternehmen einen bewertbaren, zukünftigen Nutzenzu-

fluss garantieren bzw. ihm einen zwingenden Nutzenabfluss bescheren. Vgl. IASB (2003b), S. 7. 333 Vgl. IASB (2003d), S. 2.

Page 145: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 127

1. Der Vertrag ist nicht erfüllt (schwebend): Keine der Parteien hat ihre vertrag-lichen Zusicherungen erfüllt.

2. Der Vertrag ist einseitig erfüllt: Eine Partei hat ihre Leistung erbracht, wäh-rend die (oder mehrere) Gegenpartei(en) ihre Zusicherungen nicht vollstän-dig erbracht hat (haben).

3. Der Vertrag ist beidseitig erfüllt: Beide bzw. alle Parteien haben ihre Zusi-cherungen vollständig erbracht und die Abwicklung des Vertrages ist abge-schlossen.

Diese Einteilung ermöglicht es, die in den einzelnen Phasen der Vertragsabwick-lung anzusetzenden Vermögenswerte und Verbindlichkeiten zu identifizieren. Die-ses Konzept soll durch ein Beispiel anhand eines Kaufvertrags einer einzelnen Ware illustriert werden. Solange der Vertrag schwebend (also nicht erfüllt) ist, steht die Leistungspflicht des Anbieters unter der Bedingung der Zahlung des Kaufpreises durch den Käufer und umgekehrt. Der Verkäufer besitzt also ein bedingtes Recht auf den Kaufpreis und eine bedingte Verpflichtung zur Lieferung der Ware, womit ein Bilanzansatz nicht möglich ist.334 Mit der Leistungserbringung einer Partei wer-den die Rechte und Pflichten beider Parteien unbedingt. Entsprechend ist ein Ansatz der Vermögenswerte und Schulden erforderlich, die im Modell als post-performance assets und liabilities bezeichnet werden. So führt die Vorauszahlung eines Kunden zu einer Vermögenszunahme beim Verkäufer (flüssige Mittelzunah-me) und zu einer gleichzeitigen Verpflichtung (Warenlieferung) gegenüber dem Käufer.

Die pre-performance assets und liabilities werden demgegenüber als unbedingte Rechte und Pflichten definiert, die existieren, bis eine Partei ihre definierte bedingte Pflicht erfüllt.335 Unter die unbedingten Rechte und Pflichten fallen in dieser Phase die optionsähnlichen stand-ready obligations. Der Verkäufer geht dabei die unbe-dingte Pflicht ein, dem Käufer eine Ware zu einem bestimmten Preis zu liefern, wenn dieser die Gegenleistung erbracht hat. Die unbedingte Verpflichtung zu einem

334 Dieser Beispielfall betrachtet alleine die Umsatz erzielende Verkäuferseite. Dieselben Bedingungen gelten jedoch analog für die Käuferpartei.

335 Vgl. IASB (2003d), S. 2.

Page 146: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 128

bestimmten Preis zu liefern, entspricht dabei einer vom Verkäufer geschriebenen Kaufoption (call option) und bewirkt, dass der Käufer gegen zukünftige Preiserhö-hungen abgesichert ist. Auf der anderen Seite entspricht das unbedingte Recht des Verkäufers, bei der Auslieferung der Ware, den festgelegten Preis zu fordern, einer erhaltenen Verkaufsoption (put option). Sie schützt den Verkäufer vor Preissenkun-gen im Markt. Sowohl das Recht aus der Verkaufsoption als auch die Pflicht aus der Kaufoption sind rechtlich durchsetzbar und erfüllen damit grundsätzlich die An-satzkriterien für einen Vermögenswert bzw. eine Schuld. Da sich der Rechtsan-spruch bei schwebenden Verträgen auf monetäre Ausgleichszahlungen beschränkt, werden pre-performance assets und liabilities aus dem gleichen Vertrag gegenein-ander aufsaldiert. Entsprechend verfügt bei schwebenden Verträgen der eine Ver-tragspartner über ein pre-performance asset und der andere über eine pre-performance liability.

Die folgende Übersicht soll zum einen pre-performance und post-performance as-sets und liabilities mit den resultierenden Rechten und Pflichten für die Vertragspar-teien veranschaulichen und zum anderen deren bilanzielle Behandlung aufzeigen:

Page 147: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 129

Erfüllung durch eine Partei (Lieferung bzw. Zahlung)

Zeitleiste:

Rechnungs-legung:

Erfüllung durch andere Partei (Zahlung bzw. Lieferung)

Vertragsabschluss

Rechte und Pflichten:

PRE-Performance Schwebender Vertrag

POST-Performance Einseitig erfüllter Vertrag

• Bedingtes Recht auf Zahlung • Bedingte Pflicht zur Lieferung

• Unbedingtes Recht auf Zahlung bei vorheriger Lieferung

• Unbedingte Pflicht zur Lieferung bei vorheriger Zahlung

• Unbedingtes Recht auf Zahlung (da Lieferung erfolgt ist)

• Unbedingte Pflicht zur Lieferung (da Zahlung erfolgt ist)

pre-performance assets and liabilities(Nettoausweis)

post-performance assets and liabilities (Bruttoausweis)

Bilanz Bilanz

Pre-perform.

asset Post-

perform. asset

Post-perform. liability

Sicht des Verkäufers

z.B. flüssige Mittel

z.B. Verpflichtung gegenüber Kunden (erlischt nach Erfüllung)

Abbildung 19: Bilanzieller Ansatz von pre-und post-performance assets und liabilities336

In einem dritten Schritt legt das Modell fest, zu welchen Zeitpunkten Veränderun-gen der pre- und post-performance assets und liabilities als Umsatz zu realisieren sind. Die Standardsetter haben dazu das fundamental revenue recognition principle definiert, welches festlegt, dass die Umsätze grundsätzlich zum Marktwert (bzw. CBV) in der Periode ihrer Entstehung auszuweisen sind.337 Beim fair value Ansatz legen die weiteren Realisationsprinzipien zudem drei Zeitpunkte fest, zu welchen eine Umsatzrealisation möglich ist:338 Bei Vertragsbeginn, bei Erbringung der Leis-tung und bei Abschluss der Vertragsabwicklung. Eine Umsatzrealisation zur Ver-tragsbeginn hat zu erfolgen, wenn die vertraglich erhaltenen Vermögenswerte die eingegangenen Verbindlichkeiten übersteigen. Während der Vertragszeit sollen Umsätze analog und in dem Umfang erfasst werden wie die Erbringung der Leis-

336 In Anlehnung an Bender (2005), S. 172. 337 IASB (2004a), S. 3. 338 Dazu kommen weitere untergeordnete Realisationsprinzipien wie zum Beispiel der Nachweis und die

Bewertbarkeit einer Zunahme der Forderungen bzw. eine Abnahme der Verpflichtungen gegenüber dem Kunden. Vgl. IASB (2004a), S. 4.

Page 148: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 130

tungsverpflichtungen durch das Unternehmen erfolgt. Bei der vollständigen gegen-seitigen Vertragserfüllung sollen Umsätze realisiert werden, sofern sich eine ab-schliessende Zunahme von Vermögenswerten aus dem Vertrag bzw. Abnahme von vertraglichen Verpflichtungen ergibt. Die verlässliche Bewertbarkeit der Verände-rungen der den Umsätzen zugrunde liegenden vertraglichen Verbindlichkeiten und Vermögenswerte ist in allen drei Zeitpunkten vorausgesetzt. Beim CBV-Ansatz er-folgt die Umsatzrealisierung nur nach Erfüllung der Leistungspflichten.

Der assets-and-liabilities Ansatz unterscheidet sich dadurch stark vom bisherigen realization-and-earnings process Ansatz: Die Umsatzrealisation kann beim fair va-lue Ansatz auch bei Kaufverträgen eines einzelnen Gutes über mehrere Zeitpunkte hinweg erfolgen, wenn Vertragsbeginn, Leistungserbringung und Abschluss der Vertragsabwicklung nicht gleichzeitig stattfinden. Diese Umsatzaufgliederung steht dem realization-and-earnings process Ansatz entgegen, welcher auf einen einzigen Realisierungszeitpunkt, den Abschluss des Leistungsprozesses fokussiert.

2.2.2.3. Bewertung

Die Umsatzbemessung beruht beim assets-and-libilities Ansatz im Endeffekt auf der verlässlichen Bewertung von Vermögenswerten und Verbindlichkeiten aus Kundengeschäften. Die joint working group von IASB und FASB sprach sich dabei bis Mitte 2005 für eine Erstbewertung aller pre- und post-performance assets und liabilities zum beizulegenden Zeitwert aus.339 Der fair value Ansatz ist aus rein the-oretischer Sicht sicherlich der am besten geeignete Bewertungsansatz, er stösst je-doch in der Praxis dort an seine Grenzen, wo Leistungsverpflichtungen einzigartig sind und nicht gehandelt werden (zum Beispiel Garantieverpflichtungen) und somit kein Wertansatz gefunden werden kann. Diese Problematik hat den amerikanischen Standardsetter bereits bei der Regelung von SOP 97-2 für Software-Vereinbarungen mit mehreren Komponenten dazu gebracht, vom Zeitwert-Ansatz teilweise abzu-weichen und den Ansatz des vendor-specific objective evidence (VSOE) einzufüh-ren.340 Aus diesen Gründen wurde von der joint working group für die Bewertung

339 Vgl. FASB (2003b), S. 3f. und IASB (2003c), S. 7. 340 Vgl. Abschnitt IV 2.2.2.2.

Page 149: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 131

von Leistungsverpflichtungen (post-performance liabilities) eine Evaluation von alternativen Ansätzen wie dem CBV341 vorgeschlagen.342

Im Folgenden werden daher der fair value Ansatz und der CBV Ansatz vorgestellt und ihre Unterschiede bei der Umsatzerfassung von Leistungsverpflichtungen erläu-tert:

Der fair value Ansatz basiert auf der Ermittlung des Betrags, zu welchem ein Ver-mögenswert oder eine Verbindlichkeit zwischen voneinander unabhängigen Partei-en getauscht werden könnte. Dabei ist die Wahl eines geeigneten Referenzwertes zur Ermittlung des beizulegenden Zeitwertes von zentraler Bedeutung. In der Dis-kussion als Referenzwert stehen dabei der legal layoff amount oder der customer consideration amount:343 Der legal layoff amount entspricht demjenigen Betrag, den das Unternehmen einem Dritten für die Übernahme einer Leistungsverpflichtung gegenüber dem Kunden zu bezahlen hätte und stellt damit auf den business-to-business Markt ab. Der customer consideration amount bezieht sich hingegen auf den Absatzmarkt und damit auf den Preis, zu dem das Unternehmen die Leistung an einen Endkunden verkauft hat oder verkaufen könnte. Das FASB wie das IASB ha-ben entschieden, dass ein Unternehmen – falls es einen akzeptablen Zugang zu mehreren Märkten hat – denjenigen Markt mit dem tiefsten Preis als Referenz für den beizulegenden Zeitwert hinzuziehen muss. Nach Untersuchungen der Standard-setter trifft dies in der überwiegenden Zahl der Fälle auf den business-to-business Markt und somit auf den legal layoff amount zu.344 Dadurch werden die nach dem legal layoff amount bewerteten unbedingten Leistungsverpflichtungen gegenüber dem Kunden generell tiefer angesetzt als die vom Kunden im Voraus auf dem Ab-satzmarkt getätigten Zahlungen. Wie in Abschnitt V 2.2.2.2 aufgezeigt, muss der

341 Vor der Einführung des Begriffs CBV wurde von der joint working group der Begriff performance value verwendet. FASB und IASB diskutieren zurzeit den Ersatz des Begriffs CBV durch den Begriff allocated consideration amount. Vgl. FASB (2005), S. 7.

342 Vgl. IASB (2005a), S. 1. Ob die Behandlung von pre-performance liabilities wie stand-ready obligati-ons nach dem Ansatz des CBV oder des fair value erfolgen soll, ist noch umstritten. Vgl. zur Diskussi-on FASB (2005), S. 9ff.

343 Vgl. IASB (2003f), S. 7. Unklarheiten bei der Verwendung der ursprünglichen Begriffe wholesale fair value und retail fair value führten zur Entscheidung, diese durch die Begriffe legal layoff amount und customer consideration amount zu ersetzen. Vgl. dazu IASB (2004d), S. 2f.

344 Vgl. FASB (2003b), S. 3. Das IASB hat in seinem Projekt zu financial instruments and business combi-nation eine ähnliche Sichtweise eingenommen. Vgl. IASB (2004c), S. 5.

Page 150: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 132

resultierende Differenzbetrag zu Vertragsbeginn als Umsatz ausgewiesen werden. Dadurch ergibt sich jedoch die Gefahr, dass bei einer unvollständigen Abbildung der Leistungspflichten eine überhöhte Umsatzerfassung erfolgt.345 Im Gegensatz dazu muss beim Ansatz des customer consideration amount die erhaltene Gegen-leistung bis zum Zeitpunkt der Leistungserbringung als Verbindlichkeit ausgewie-sen werden. Der customer consideration amount folgt damit der bisherigen Konzep-tion, dass Umsätze erst mit der Leistungserbringung gegenüber dem Kunden erfasst werden. Das Accounting Standards Board in Grossbritannien (ASB) hat sich des-halb im Gegensatz zum FASB für den Ansatz des customer consideration amount ausgesprochen.346

Folgende Fallstudie zeigt jedoch, dass die Verwendung des customer consideration amount Ansatzes ebenfalls nicht unproblematisch ist. Die Bemessung der Leis-tungsverpflichtungen erfolgt bei diesem Ansatz nach der Kundenperspektive. Daher entsprechen die Leistungsverpflichtungen des Anbieters exakt den Leistungsansprü-chen des Kunden (mirror accounting):347

Fallstudie 21

Das Softwareunternehmen X verkauft Standard-Software mit einem einjährigen Gratis-Telefonsupport zu einem Preis von 1000. Zusätzlich bietet das Unternehmen einen erweiterten Telefonsupport für 100 an, welcher zum einjährigen Gratis-Support weitere zwei Jahre Telefonsupport gewährt. Der bezahlte Preis kann nicht zurückerstattet werden. Das Unternehmen X kann den Telefonsupport selbst zur Verfügung stellen oder bezahlt einen zuverlässigen Dienstleister D, um diese Auf-gabe zu übernehmen. Statistische Berechnungen zeigen, dass nur 80% der Kunden den Telefonsupport in Anspruch nehmen und dies mit einer Kostenfolge von rund 110 pro Kunde zu Buche schlägt. Zuverlässige Drittanbieter sind bereit, den Tele-fonsupport für 90 pro Vertragsabschluss zu übernehmen.

Am 1. Juni 2005 verkauft der Unternehmen X zehn Softwarelizenzen mit erweiter-tem Telefonsupport und erhält dafür den vollen Verkaufspreis in bar.

345 So können z. B. infolge nicht erfasster Garantie- oder Rücktrittsrechten des Kunden oder bei Fehlbe-wertungen Umsätze bei Vertragsbeginn zu hoch ausgewiesen werden.

346 Vgl. IASB (2003f), S. 7. 347 In Anlehnung an IASB (2004e), S.1ff.

Page 151: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 133

(Fall A) Welche Verbindlichkeiten muss das Unternehmen X im Jahr 2005 auswei-sen, falls es den Telefonsupport selber übernimmt?

(Fall B) Welche Verbindlichkeiten muss der Dienstleister D im Jahr 2005 auswei-sen, falls es den Telefonsupport von Unternehmen X übernimmt?

(Fall C) Welche Verbindlichkeiten muss das Unternehmen X im Jahr 2005 auswei-sen, falls Unternehmen Y (ein Konkurrent von X) die gleiche Anzahl und Art Tele-fonsupportleistungen zum gleichen Zeitpunkt wie Unternehmen X verkauft und so-fort Unternehmen X beauftragt, diese Telefonsupportleistungen für Y zu überneh-men und es diese auch sofort bezahlt?

Fallstudie 21: Standard-Softwareunternehmen X fortgesetzt

(Um die Komplexität zu reduzieren wird nur das Jahr 2005 wiedergegeben)

Fall A: Aus Kundenperspektive muss Unternehmen X im 1. Jahr die Telefonsup-port-Verbindlichkeiten von 1000 (10*100) verbuchen, welche über die nächsten zwei Jahre abgetragen werden.

Bilanzansatz Unternehmen X Jahr 2005

Kasse 1000 Telefonsupport-Verbindlichkeiten 1000

Verlust 0

Fall B: Aus Sicht der Endkunden muss der Dienstleister D als neuer Vertrags-schuldner die Verpflichtung von 1000 (welche den Kundenforderungen von 1000 entspricht) verbuchen. Da er nur 900 (10*90) für die Verpflichtungsübernahme er-hält, bleibt ihm ein Verlust von 100 im Jahr 1.

Bilanzansatz Dienstleister D Jahr 2005

Kasse 900 Telefonsupport-Verbindlichkeiten 1000

Verlust 100

Fall C: Die Endkunden besitzen 20 „Telefonsupport-Rechte“ zu einem Wert von 2000. Das Unternehmen X muss als Vertragsschuldner die Verpflichtung von 2000 (welche den Kundenforderungen von 2000 entspricht) bei sich verbuchen. Es muss

Page 152: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 134

zudem einen Verlust von 100 für die Verpflichtungsübernahme von Unternehmen Y übernehmen.

Bilanzansatz Unternehmen X Jahr 2005

Kasse 1900 Telefonsupport-Verbindlichkeiten 2000

Verlust 100

Aus Kundenperspektive müssen der Dienstleister D (in Fall B) und das Unterneh-men X (in Fall C) ihre Telefonsupport-Verpflichtungen mit 1000 ansetzen und je-weils einen Verlust von 100 ausweisen, welcher sich aus der Differenz von der Verpflichtung im Wert von 1000 und einer Zahlung von 900 ergeben. Diese Lösung ist jedoch unbefriedigend, weil das Unternehmen bei solchen Transaktionen in der Bilanz einen Verlust ausweisen muss, obwohl das Unternehmen in der Realität ei-nen ökonomischen Gewinn erwirtschaftet.

Eine alternative Möglichkeit besteht darin, dass der Dienstleister D und das Unter-nehmen X ihre Telefonsupport-Verpflichtungen zum Kaufpreis von 900 ansetzen. In Fall C würde dies jedoch bedeuten, dass Unternehmen X die Verpflichtung von Unternehmen Y zu einem Wert von 900 und damit anders bewerten würde wie die identische Verpflichtung vom Kunden zu einem Wert von 1000. Unter einer fair value Betrachtung ist diese Lösung nicht akzeptabel.

Das IASB hatte sich deshalb zwischenzeitlich wie das FASB im Grundsatz für den Ansatz des legal layoff amount entschieden, jedoch Bedenken hinsichtlich seiner Anwendbarkeit in der Praxis geäussert.348 Der fair value Ansatz nach dem legal layoff amount zeigt seine Schwächen insbesondere bei den in der Softwareindustrie häufig anzutreffenden Leistungsverpflichtungen mit einzigartigem Charakter, weil der für die Bewertung notwendige aktive Referenzmarkt fehlt. Dadurch ist eine Bewertung nach dem fair value nicht möglich. Die joint working group schlug da-her die Evaluation des alternativen CBV vor.

Der Ansatz des CBV basiert darauf, dass ein Vertrag aus Kundensicht in seine Ein-zelkomponenten aufgeteilt werden soll. Dabei sollen Leistungsverpflichtungen als

348 Vgl. IASB (2004c), S. 5.

Page 153: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 135

separate Komponenten identifiziert werden, wenn sie dem Kunden einen Nutzen stiften. Einen Nutzen für den Kunden begründen Leistungsverpflichtungen, deren zugrunde liegenden Produkte oder Dienstleistungen dem Kunden einem Zweck die-nen. Der CBV entspricht dabei dem Betrag, zu welchem ein Produkt (oder eine Dienstleistung) bei separater Veräusserung einem Kunden verkauft wird (werden könnte).349 Eine allfällige Differenz zwischen den aggregierten CBV der Einzelleis-tungen und der gesamten Vertragssumme soll auf einer pro rata Basis auf die Ver-pflichtungen verteilt werden. Für die Ermittlung des CBV kommen – im Unter-schied zum fair value Ansatz350 – grundsätzlich mehrere Bemessungsmethoden in Frage. Dabei gilt, dass der CBV nach der je nach Verfügbarkeit der Informationen zuverlässigsten Bemessungsmethode zu bestimmen ist. Dazu sind die Bewertungs-methoden in einem Stufenmodell angeordnet:351

Stufe 1: Der CBV soll auf den bestehenden Verkaufspreisen von eigenen aktuellen Transaktionen von identischen Produkten/Dienstleistungen in einem aktiven Markt basieren.

Stufe 2: Falls die für Stufe 1 notwendigen Informationen nicht vorhanden sind, so soll der CBV auf den Verkaufsinformationen anderer Unternehmen (also Wettbe-werber) in einem aktiven Markt basieren.

Stufe 3: Falls die für Stufe 1 und Stufe 2 erforderlichen Informationen nicht zu be-schaffen sind, so soll der CBV nach den Verkaufsinformationen von eigenen getä-tigten Verkäufen geschätzt werden.

Stufe 4: Falls die für Stufe 1, Stufe 2 und Stufe 3 nötigen Informationen fehlen, so soll der CBV auf den internen Berechnungen des Unternehmens basieren.

Der folgende Vergleich soll die Unterschiede der zur Diskussion stehenden Alterna-tiven bei Leistungsverpflichtungen aufzeigen:

349 Diese Definition ist als (provisorische) Arbeitsdefinition zu verstehen. Zusätzlich umfasst die Definition die Bedingung, dass das Produkt dem Kunden einen Nutzen stiften soll. Vgl. IASB (2005b), S. 2.

350 Vgl. jedoch die aktuelle Diskussion zur Bemessung von fair values und die Bemühungen zur Etablie-rung einer fair value hierarchy, welche Ähnlichkeiten zum CBV-Ansatz aufweist. Vgl. FASB (2005a).

351 Vgl. FASB (2005b), S. 10.

Page 154: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 136

Alternative 1 Alternative 2 Alternative 3 Bisher entwickeltes

konzeptionelles Modell Neu mehrheitlich Heutiger Ansatz

unterstütztes Modell

Realisationsbasis Erhöhung der Nettoaktiven aus Kundentransaktionen

Erhöhung der Nettoaktiven aus Kundentransaktionen

Umsatz verdient und realisiert bzw. realisier-bar

Messgrösse für Leistungsverpflichtungen

Zeitwert (fair value) = legal layoff amount

Kundenbasierter Wert (CBV) = Betrag, zu welchem Produkt oder DL bei separater Veräusserung dem Kunden verkauft werden könnte (nach dem CBV Stufenmodell)

VSOE = Marktpreis bei separater Veräusserung oder der durch das Management bestimmter Preis

Möglichkeit einer Neubewertung

Aufgrund der Verwendung des Zeitwerts eher ja, aber nicht entschieden.

Nein Nein

Umsatzrealisierung über die Zeit

• Wenn bei Vertragsab-schluss die Netto-aktiven steigen

• Wenn der Zeitwert sich ändert

• Wenn die Leistungsver-pflichtungen erfüllt sind

Wenn die Leistungsver-pflichtungen erfüllt sind

Wenn verdient und realisiert

Praktische Auswirkungen

Profitabilität der verschiedenen Vertragselemente erkennbar

Messung der Effizienz des Unternehmens bezüglich Vertragsabschlüssen und Verpflichtungs-befriedigung im Vergleich zum Markt

Profitabilität der verschiedenen Vertragselemente erkennbar

Profitabilität gemessen als Vergleich von Kundenentgelt zu Unternehmenskosten

Je nach Ausgestaltung ähnlich wie Alternative 2

Abbildung 20: Vergleich der Alternativen zur Bewertung von Leistungspflichten352

Die Thematik der Folgebewertung wurde von der joint working group bisher weit-gehend ausgeblendet. Für den CBV scheint jedoch die Möglichkeit einer Neubewer-tung wie nach dem heutigen Ansatz ausgeschlossen. Für die Folgebewertung von pre- und post-performance assets und liabilities zum fair value stehen grundsätzlich folgende Möglichkeiten zur Erfassung von marktbedingten Zeitwertschwankungen zur Auswahl: (1) die Nichterfassung, (2) die ergebnisneutrale Verbuchung der Wertanpassung im Eigenkapital und deren spätere Rückführung in die Erfolgsrech-

352 In Anlehnung an IASB (2005a), S. 4.

Page 155: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 137

nung, (3) die sofortige, ergebniswirksame Erfassung der Bewertungsänderung als Ertrag oder Aufwand. Das IASB scheint sowohl für pre-performance assets und liabilities als auch für post-performance assets und liabilities die sofortige Erfas-sung von Bewertungsänderungen als Umsatz oder Aufwand zu favorisieren.353 Die-se Lösung würde jedoch dazu führen, dass nicht mehr nur Kundenleistungen, son-dern auch Wertänderungen von Vermögenswerten und Verpflichtungen in die Um-satzerfassung einfliessen würden, was einem erheblichen erweiterten Umsatzkon-zept gleichkäme.

2.2.2.4. Offenlegung

Der vorgeschlagene asset-and-liabilities Ansatz basiert im Unterschied zum heuti-gen Ansatz vermehrt (je nach gewählter Alternative) auf marktbezogenen Bewer-tungsmethoden. Die Erfassung von pre-performance assets oder die Zeitbewertung bzw. die Bewertung nach CBV von Leistungsverpflichtungen erfordern eine Selek-tion des Bewertungsverfahrens und die Wahl von Messgrössen. Aufgrund dieser Vielfalt müssen die Offenlegungsvorschriften erweitert werden, um die notwendige Transparenz für den Investor zu wahren.

Die wichtigsten Änderungen der Offenlegungsvorschriften sind in der Erfolgsrech-nung angezeigt, um dem Investor eine hohe Verlässlichkeit und Voraussagekraft von (Teil-)Umsätzen zu garantieren. Dabei ist eine Aufteilung der Umsätze nach Herkunft aus pre-performance assets oder post-performance assets und liabilities ins Auge zu fassen. Zudem sollen beim fair value Ansatz für beide Klassen Bewer-tungsänderungen separat erfasst werden. Diese Angaben erlauben es dem Investor, bei gewichtigen Anpassungen auf Veränderungen im Markt oder Fehleinschätzun-gen des Managements zu schliessen. Wird ein pre-performance asset (z. B. aus ab-geschlossenen Garantievereinbarungen) überhöht ausgewiesen, um Umsätze vorzu-ziehen, so führt dies in der Folgeperiode zu Wertberichtigungen. Auch Bewertungs-anpassungen bei separatem Ausweis von post-performance assets und liabilities (sofern sie nach dem beizulegenden Zeitwert erfasst werden) liefern dem Investor nützliche Informationen. Eine negative Bewertungsanpassung bei Forderungen deu-

353 Vgl. IASB (2003b), S. 7.

Page 156: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 138

tet zum Beispiel auf eine zu optimistische Werteinschätzung des Managements in früheren Perioden hin.

In der Bilanz sollen pre-performance assets und liabilities separat ausgewiesen werden. Dabei ist auf der Aktivseite bzw. Passivseite eine Position im Sinne von „Netto-Vermögenswerten bzw. Netto-Verbindlichkeiten aus schwebenden Verträ-gen“ zu schaffen.

Im Anhang sind ausführliche Erläuterungen zu den verschiedenen verwendeten Be-wertungsmethoden anzuführen. Erweiterter Angaben bedürfen dabei insbesondere die verwendeten Optionspreisverfahren bei der Bemessung von pre-performance assets oder die Bewertung von Leistungspflichten bei Verwendung des beizulegen-den Zeitwertes.

2.3. Entscheidungsnutzenanalyse

Ziel dieser Analyse ist es, die vorgestellten Umsatzkonzeptionen auf ihre Eignung zur Verbesserung des Entscheidungsnutzens für den Investor zu untersuchen. In einem ersten Schritt werden die zwei konkurrenzierenden Modelle zur Umsatzreali-sierung gegenübergestellt. In einem zweiten Schritt sollen die vorgeschlagenen An-sätze zur Umsatzabgrenzung dem bisherigen Ansatz gegenübergestellt und danach die beiden neuen Ansätze miteinander verglichen werden. Im dritten Unterkapitel wird die Umsatzrealisierung analysiert. Viertens werden die neuen Bewertungsme-thoden fair value und CBV dem bisherigen Ansatz gegenübergestellt. Zuletzt wer-den die neuen Offenlegungsvorschläge analysiert.

2.3.1.

Wahl des Ansatzes

Bei der Umsatzrealisierung stehen insbesondere der assets-and-liabilities Ansatz und der realization-and-earnings process Ansatz zur Diskussion. Die gemeinsame Arbeitsgruppe von FASB und IASB zum Thema Umsatzrealisierung gibt dabei dem assets-and-liabilities Ansatz basierend auf folgenden drei Argumenten den Vor-zug:354 Erstens wird betont, dass die Anwendung des realization-and-earnings pro-cess Modells bei der Umsatzrealisierung in gewissen Fällen zu einer Anerkennung

354 Vgl. FASB (2006).

Page 157: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 139

von zurückgestellten Guthaben und Schulden führen würde, welche nicht der Defi-nition von Vermögenswerten und Verbindlichkeiten des SFAC 6 bzw. des IASB Rahmenkonzepts entspräche.355 Zweitens ist die Arbeitsgruppe überzeugt, dass Er-trag und Umsatzrealisierung durch das realization-and-earnings process Modell weder präzise genug, noch in einer Art und Weise definiert werden können, dass eine widerspruchsfreie Anwendung über verschiedene Industrien und Transaktions-typen hinweg möglich ist. Drittens ist es schwierig, bei Vereinbarungen mit mehre-ren Komponenten (multiple element arrangements) eine eindeutige Identifikation von Ertrag und Umsatzrealisierung gewährleisten zu können.

Diese Dissertation favorisiert wie die Arbeitsgruppe den assets-and-liabilities An-satz gegenüber dem realization-and-earnings process Ansatz. Diese Schlussfolge-rung basiert auf folgender Überlegung: Die Etablierung von eigenen Standards auf Seiten des FASB bezüglich der Umsatzrealisierung bei Softwareunternehmen, wel-che verschiedentlich erweitert und konkretisiert wurden, zeigt auf, dass es dem Standardsetter nur schwerlich gelingt, die in der Praxis immer weiter entwickelten Umsatzerfassungsformen auch regeltechnisch abzudecken. Demgegenüber verhält sich das IASB mit neuen detaillierten Regelungen sehr zurückhaltend, was zu ei-genwilligen Ansätzen in der Praxis führen kann.356 Aufgrund dieser Erfahrungen und der Forderung der representational faithfulness ist ein Ansatz zu fordern, wel-cher eine möglichst lange Zukunftsbeständigkeit aufweist. Dies ist aber nur gewähr-leistet, wenn ein solcher Standard auf einer konsistenten und auf den fundamentalen Rahmenkonzepten der Standardsetter basierenden Argumentationslogik beruht. Dies kann nur der assets-and-liabilities Ansatz gewährleisten, welcher nahtlos auf der Definition der Standardsetter bezüglich Vermögenswerten und Schulden auf-baut. Als weiteres verfolgt der realization-and-earnings Ansatz ein Umsatzrealisa-tionsprinzip, welches auf einem Ereignis basiert, das eine einmalige Erfassung des Umsatzes beim Abschluss des Leistungserstellungsprozesses auslöst. Aufgrund der komplexen Vertragskonstruktionen im Standard-Softwarebereich (Verträge mit mehreren Komponenten) ist eine zutreffende Identifizierung eines solchen Zeit-

355 Die Umsatzdefinition beruht bei beiden Standardsettern auf der Veränderung von Vermögenswerten und Verpflichtungen und entspricht damit dem assets-and-liabilities Ansatz. Vgl. zu den Unterschieden zwischen den beiden Ansätzen die Fallstudie 20.

356 Vgl. Fallstudie 13.

Page 158: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 140

punktes kaum möglich. Im Gegensatz dazu bietet der assets-and-liabilities Ansatz mit dem Kriterium der Veränderungen von Aktiven und Passiven ein konzeptionell einfaches Instrument zur Abgrenzung. Daher vereinfacht der assets-and-liabilities Ansatz die Abbildung von Verträgen mit mehreren Komponenten erheblich, da er ohne Spezialregelungen für Mehrkomponentenverträge auskommt. Zudem garan-tiert dies als drittes, dass auch bei verschiedenen, jedoch materiell identischen Transaktionskonstellationen ein einheitlicher Umsatzausweis gewährleistet ist.357 Dadurch wird zum einen die understandability erheblich gefördert und zum anderen die Forderung der comparability/consistency besser befriedigt.

2.3.2.

Umsatzabgrenzung

Zur Umsatzabgrenzung stehen drei Ansätze zur Auswahl: Der aktuelle Ansatz der ordentlichen Geschäftstätigkeit, der liability extinguishment view und der broad performance view. Die beiden Alternativansätze weichen in zwei Punkten entschei-dend vom gegenwärtigen Ansatz der ordentlichen Geschäftstätigkeit ab: Die Um-satzerfassung beruht ausschliesslich auf Leistungen gegenüber dem Kunden. So fällt zum Beispiel die rechtliche Übertragung von Leistungspflichten an Dritte ge-gen Bezahlung nicht mehr unter die Umsatzdefinition. Zudem wird die bisherige Differenzierung von Umsätzen nach ordentlicher Geschäftstätigkeit und sonstigen Erträgen (other revenues) aufgehoben. Aus Investorensicht ist die Abkehr vom An-satz der ordentlichen Geschäftstätigkeit und die Hinwendung zu den alternativen Ansätzen aus folgenden Gründen angebracht: Für Investoren ist nur ein Umsatz-ausweis relevant, welcher die Leistungen des Unternehmens und die damit verbun-denen Risiken gegenüber dem Kunden reflektiert. Geht nun ein Drittanbieter die rechtliche Verpflichtung einer Leistungsübernahme gegenüber dem Kunden ein, so ist das Unternehmen bezüglich dieser Leistung keinem Risiko mehr ausgesetzt. So-mit ist aufgrund der Forderung der materiality der Netto-Umsatzausweis der Alter-nativansätze dem bisherigen Ansatz mit der Hinwendung zum Brutto-Umsatz-ausweis vorzuziehen. Denn nur wenn der Umsatz in einem angemessenen Verhält-nis zu den eingegangenen Risiken steht, können zum Beispiel Renditekennzahlen zeitlich und unternehmensübergreifend vergleichbare Aussagen zu den Nutzen-

357 Vgl. Fallstudie 20.

Page 159: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 141

Risiko-Verhältnissen machen. Bezogen auf den zweiten Punkt führen die Alterna-tivansätze zu einer Eliminierung der Abgrenzungsspielräume zwischen geschäftsty-pischen Umsätzen und sonstigen betrieblichen Erträgen und erhöhen dadurch ten-denziell die Vergleichbarkeit der Informationen (comparability/consistency). Die-sem positiven Effekt steht jedoch die Einführung des neuen Abgrenzungskriteriums Kunde entgegen, welches wiederum Interpretationsspielräume eröffnet. IASB und FASB haben diese Problematik erkannt, indem sie betonen, dass „this customer cri-terion might not be sufficiently robust“358. Das IASB erwägt deshalb die Möglich-keit, den Kundenbegriff sehr breit zu fassen und gleichzeitig bestimmte Transaktio-nen auszuschliessen.359 So würde zum Beispiel der Verkauf von Anlagevermögen eines Unternehmens nicht in den Umsatz einfliessen. Trotz der daraus folgenden Gefahr von fallbasierten Ausnahmeregelungen, welche Raum bieten für Transakti-onskonstruktionen nach dem Prinzip „was nicht verboten ist, ist erlaubt“, scheint dieser Ansatz einen grossen Fortschritt hinsichtlich der Vergleichbarkeit der Infor-mationen für den Investor zu bringen. So wird die schwierige Differenzierung von ordentlicher Geschäftstätigkeit und sonstigen Erträgen durch den besser fassbaren Kundenbegriff ersetzt. Zudem werden aussergewöhnliche Faktoren wie der Verkauf von Anlagevermögen explizit aus dem Umsatzausweis ausgeschlossen.

In einem nächsten Schritt soll ein Vergleich der beiden Alternativansätze vorge-nommen werden. Der Ansatz des liability extinguishment view beruht darauf, dass Umsätze aus dem Erlöschen von Leistungsverpflichtungen resultieren, welche zu einer Reduktion der Verbindlichkeiten des Unternehmens führen. Wie jedoch BEN-

DER darlegt, werden zum Beispiel bei Zielverkäufen keine Verbindlichkeiten ange-setzt, da die Leistungspflicht des Verkäufers durch die Zahlung des Kunden bedingt ist – entsprechend bewirkt die Lieferung des Verkaufsgegenstandes zwar die Been-digung der Leistungspflicht, jedoch keine Reduktion der Verbindlichkeiten, sondern die Entstehung einer Forderung.360 Entsprechend sollte die Definition um diesen Aspekt angepasst und korrekterweise von einem obligation extinguishment view

358 IASB (2004b), S. 8. 359 Vgl. IASB (2004b), S. 8. 360 Vgl. Bender (2005), S. 166f.

Page 160: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 142

gesprochen werden.361 Dieser aus Investorensicht einzige gewichtige Schwachpunkt des liability extinguishment view ist somit durch eine angepasste Definition leicht zu beheben. Die Vorteile des obligation extinguishment view bestehen in einer implizi-ten Anknüpfung der Umsatzabgrenzung an ein rechtliches Abgrenzungskriterium, der Existenz eines gerichtlich durchsetzbaren Vertrages.362 Dadurch ist eine objek-tive Abgrenzung der als Umsatz bezeichneten Leistungsprozesse insbesondere im Gegensatz zum vagen broad performance view363 möglich, was einen entscheiden-den Nutzen für den Investor sowohl hinsichtlich der representational faithfulness als auch der comparability/consistency mit sich bringt. Eine weitere Stärke des ob-ligation extinguishment view gegenüber dem broad performance view besteht in der Behandlung von Umsätzen aus an Dritte ausgelagerten Vertragsleistungen (sub-contracting). Der broad performance view beschränkt den Umsatz auf vom Unter-nehmen selbst erbrachte Leistungen und schliesst damit Leistungen von Sub-Unternehmen kategorisch aus. Aus Gründen der materiality ist diese Abgrenzung aus Investorensicht abzulehnen, weil die Risiken beim subcontracting unverändert beim Hauptvertragspartner verbleiben. Die Aussagekraft der Umsatzgrösse wäre dadurch vermindert als sie von den Entscheidungen des Managements (make or buy) abhängig wäre. Im Gegensatz dazu differenziert der obligation extinguishment view zwischen dem blossen Outsourcing der Auftragsdurchführung und der rechtli-chen Übertragung aller ausstehenden Risiken und bildet dadurch den unterschiedli-chen wirtschaftlichen Gehalt dieser Vorgänge ab.364 Die fehlenden Informationen zum Outsourcing-Anteil der erbrachten Leistungen können über Offenlegungs-pflichten erbracht werden.

Als Fazit der Entscheidungsnutzenanalyse ist deshalb eine Umsatzabgrenzung auf der Basis des obligation extinguishment view anzustreben. Der entscheidende Vor-teil des Ansatzes liegt in seiner Anknüpfung an rechtliche und objektiv überprüfbare

361 Die Definition (vgl. Abschnitt V 2.2.2.1) müsste von „Revenues are decreases in […] liabilities…“ all-gemein in „Revenues are changes in […] liabilities and assets related to customer transactions…” abge-ändert warden. Vgl. Bender (2005), S. 167.

362 Vgl. dazu Abschnitt V 2.2.2.2. 363 Der Umsatz wird relativ ungenau definiert als „activities that are integral to the provision of products

(goods and services) by the entity itself that are ultimately destined for customers”. 364 Der obligation extinguishment view bietet dabei ein Mittelmass zwischen dem heutigen Umsatzausweis,

welcher zum Teil zu stark zum Bruttoausweis tendiert und dem zu einem Nettoausweis neigenden broad performance view.

Page 161: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 143

Kriterien bei der Umsatzklassifikation. Zusätzlich ist gewährleistet, dass der Um-satzbetrag durch eine zutreffende Analyse der vorhandenen Leistungsrisiken ermit-telt wird, womit insgesamt ein hohes Mass an Relevanz (comparability/consistency) erreicht ist. Ebenso wird die Zuverlässigkeit des Umsatzes als wichtige Ausgangs-grösse für Analysemethoden (wie Rendite-Risiko-Analyse) der Investoren gestärkt.

2.3.3. Umsatzrealisation

Der gegenwärtige realization-and-earnings Ansatz verfolgt im Prinzip das Ziel, für Vertragskonstrukte einen einzigen Realisationszeitpunkt zu bestimmen, welcher durch den Abschluss des earnings process und den damit erfolgten Übergang der massgeblichen Risiken bestimmt ist. Viele Vereinbarungen wie die Verträge mit mehreren Komponenten in der Standard-Softwareindustrie weisen jedoch komplexe Zahlungs- und Lieferungsmodalitäten auf (z. B. Terminkontrakte) oder zusätzliche Vereinbarungen (z. B. Rücktrittsrechte), welche eine präzise Festlegung eines sol-chen Realisationszeitpunkts erschweren. Der asset-and-liabilities Ansatz verfolgt einen vollkommen anderen Weg, indem er die einzelnen Verpflichtungen eines Un-ternehmens voneinander getrennt zum fair value oder zum CBV (je nach Alternati-ve) bewertet.

Die Anknüpfung der Umsatzrealisation an die Veränderung von einzelnen, rechtlich durchsetzbaren Rechten und Pflichten ist unter dem Gesichtspunkt der representati-onal faithfulness zu begrüssen. So führt die Fokussierung auf eine separate Erfas-sung ausstehender Leistungspflichten grundsätzlich zu einer exakteren Aufteilung des Umsatzes auf die Perioden ihrer Entstehung. Die Auswirkungen der Neukon-zeption bezüglich der Forderung der comparability/consistency sind weniger ein-deutig zu beantworten. Ein gewichtiger Vorteil des neuen Modells besteht darin, dass es einen umfassenden Bezugsrahmen zur Verfügung stellt, welcher für unter-schiedliche Geschäftstypen wie z. B. Verkaufs- und Servicegeschäfte einheitliche Realisationskriterien vorsieht. Die heutige, fragmentierte Regelungslandschaft im Umsatzbereich wird somit durch ein einheitliches Grundkonzept ersetzt. Der neue Ansatz führt zu einer Reduktion der Ermessensspielräume des Managements.

Page 162: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 144

2.3.4. Bewertung

Als entscheidende Neuerung des asset-and-liabilities Ansatzes wurde von der joint working group der fair value Ansatz für Leistungsverpflichtungen angedacht. Zwei-fel an seiner Anwendbarkeit in der Praxis lassen die Arbeitsgruppe heute jedoch den CBV vorziehen. Entsprechend sollen diese zwei neuen Ansätze auf ihre Verbesse-rung für den Entscheidungsnutzen von Investoren überprüft werden.

Das Konzept der fair value Bemessung von Leistungspflichten weist aus konzeptio-neller Perspektive das Potenzial auf, die Relevanz der Rechnungslegung entschei-dend zu verbessern. Die Bewertung von Leistungspflichten zum beizulegenden Zeitwert ist aus folgenden Gründen einem intern geschätzten Wert vorzuziehen: Erstens senkt die Verwendung des beizulegenden Zeitwertes die Willkürlichkeit und steigert damit die neutrality des Umsatzausweises, weil die Bemessung auf ob-jektiv nachprüfbaren Marktinformationen basiert. Dadurch erhöht sich die Ver-gleichbarkeit des Umsatzausweises im Unternehmensvergleich, womit die Forde-rung comparability/consistency besser erfüllt wird. Zweitens wird der Umsatz zum Zeitpunkt der Leistungserbringung zu Marktbedingungen bewertet und damit der Kostenstruktur des Unternehmens gegenübergestellt, was die Effizienz des Unter-nehmens gegenüber der Konkurrenz aufzeigt.

Bei der Wahl des Referenzwertes für den beizulegenden Zeitwert ist aus folgenden Gründen auf den legal layoff amount abzustützen: Erstens entspricht er am ehesten der definitorischen Vorgabe des beizulegenden Zeitwertes, welcher als Betrag defi-niert ist, zu dem eine bestehende Leistungsverpflichtung bei einer unabhängigen Partei beglichen werden könnte. Die Definition basiert daher implizit auf einer hypothetischen Markttransaktion mit einem Dritten, welcher nicht Empfänger der Leistung ist. Entsprechend ist der teilweise kolportierten Kritik nicht zu folgen, dass der legal layoff amount aufgrund seiner Abstützung auf rein theoretischen Konstel-lationen dem customer consideration amount unterlegen sei, welcher die tatsächli-chen Leistungstransaktionen mit dem Kunden bemisst. Zum anderen führt der alter-native Ansatz des customer consideration amount aufgrund seiner Nähe zu den ak-tuellen Umsatzerfassungsprinzipien dazu, dass die Vorteile des asset-and-liabilities Ansatzes nur teilweise umgesetzt werden. So ist die Aufteilung einer Rahmenver-einbarung in einzelne, bewertbare Leistungspflichten über den legal layoff amount

Page 163: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 145

leichter zu bewerkstelligen als über den customer consideration amount. Dies liegt daran, dass Leistungspakete dem Kunden üblicherweise mit einem Rabatt gegen-über den Einzelpreisen angeboten werden; und daraus entsteht das Problem, diesen Rabatt auf die einzelnen Leistungen umzulegen.365 Zudem ergibt sich bei gewissen Vertragskonstellationen mit Leistungserbringung durch Dritte die Schwierigkeit, nach dem customer consideration amount einen einheitlichen Marktpreis zu identi-fizieren.366

Während daher die konzeptionellen Gründe eindeutig für eine Bewertung von Leis-tungspflichten zum legal layoff amount sprechen, so existieren gewichtige Probleme bei der Anwendung in der Praxis. Als Erstes muss der zum legal layoff amount be-wertete Umsatz kongruent mit der vom Kunden erhaltenen Gegenleistung sein, da auch die Neukonzeption den Umsatz letztlich mit den durch die Leistungserbrin-gung erhaltenen Mittelzuflüssen gleichsetzt. Die Differenz zwischen dem (geschätz-ten) legal layoff amount und der tatsächlich vereinbarten Gegenleistung soll nach heutigem Stand zu Vertragsbeginn realisiert werden. Dieser Ansatz lässt sich mit dem obligation extinguishment view367 jedoch nur dann vereinbaren, wenn man den Vertragsschluss bereits als Leistungsbestandteil betrachtet. Zum Zweiten zwingt ein fair value Ansatz aufgrund der Veränderung der Werte über die Zeit zu einer Erfas-sung von Bewertungsänderungen. Dies führt jedoch zum Problem, dass bei Ver-wendung des obligation extinguishment view die Umsatzdefinition erweitert werden muss. Als entscheidende Hürde für eine Verwendung des beizulegenden Zeitwert-Ansatzes in der Praxis muss jedoch die Voraussetzung der Existenz eines fair value für Leistungsverpflichtungen gesehen werden. Insbesondere in der Standard-Softwareindustrie kann dieser Forderung kaum Folge geleistet werden. Die einzel-nen Softwarevereinbarungen sind häufig auf die individuellen Kundenprobleme zugeschnitten und haben damit einmaligen Charakter. Zudem führen die kurzen Produktzyklen in der Standard-Softwareindustrie zu einer kaum vergleichbaren Produktvielfalt. Aber auch die generelle Tendenz zur Spezialisierung und Differen-zierung der Leistungen lässt die fair value Voraussetzung als kaum erfüllbar er-

365 Vgl. dazu Bender (2005), S. 191. 366 Vgl. Fallstudie 21. 367 Dieser Ansatz betrachtet Umsätze als das Erlöschen von Leistungsverpflichtungen. Vgl. Abschnitt V

2.3.2.

Page 164: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 146

scheinen. Die teilweise mangelnde Bewertbarkeit des beizulegenden Zeitwertes stellt jedoch die Vorteile des gesamten Neuansatzes in Frage, da kein objektiv über-prüfbarer Wertmassstab für Leistungsverpflichtungen zur Verfügung steht.

Diese Problematik hat die joint working group offensichtlich erkannt und die Eva-luation des alternativen CBV vorgeschlagen, welcher ein erweitertes Ansatzkonzept verfolgt. Dieser hat das Potenzial für die Entwicklung einer ausgewogenen Lösung, indem er ähnlich dem bereits existierenden VSOE der Situation entsprechende Be-wertungsansätze zur Verfügung stellt. So bestimmt der VSOE, dass die Bewertung nach folgenden zwei Varianten zu erfolgen hat: Entweder nach dem Marktpreis bei separater Veräusserung des gleichen Elements; oder den durch das Management bestimmten Preis zu dem die Markteinführung eines bisher nicht separat verkauften Elements als wahrscheinlich erscheint. Entsprechend sieht der CBV vor, dass die Bewertung nach dem Betrag, zu welchem Produkte oder Dienstleistungen dem Kunden verkauft werden könnten, erfolgen soll. Die Bewertung erfolgt dabei nach einem Stufenmodell: Je nach Informationsverfügbarkeit kann der CBV entweder über den Marktpreis ermittelt werden (Stufe 1) oder bei gänzlich fehlenden Markt-informationen nur aufgrund von internen Managementinformationen bestimmt wer-den (Stufe 4).368

2.3.5.

Offenlegung

Die vorgeschlagenen Offenlegungsvorschriften umfassen einige Neuerungen in der Rechnungslegung, welche insgesamt den Entscheidungsnutzen für den Investor er-höhen. So soll in der Erfolgsrechnung eine Aufteilung der Umsätze nach Herkunft aus pre-performance assets oder post-performance assets und liabilities erfolgen. In der Bilanz ist die Schaffung neuer Bilanzpositionen für pre-performance assets und liabilities vorgesehen. Im Anhang sollen insbesondere erweiterte Angaben zu den verwendeten Bewertungsmethoden und deren Berechnungsgrundlagen zur Verfü-gung gestellt werden.

368 Vgl. Abschnitt V 2.2.2.3.

Page 165: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 147

2.4. Fazit

Basierend auf der Entscheidungsnutzenanalyse stellt diese Dissertation die Empfeh-lung auf, für die Umsatzrealisierung auf den assets-and-liabilities Ansatz abzustel-len. Der Grundansatz besteht dabei darin, aus Vereinbarungen einzelne, zum CBV bewertete Leistungsverpflichtungen zu identifizieren. Dadurch ergeben sich gegen-über dem heutigen realization-and-earnings process Ansatz folgende Vorteile: Die Konzentration auf einzelne Leistungspflichten führt zu einer Aufteilung von Ver-einbarungen und dadurch zu einem detaillierteren Umsatzausweis. Entsprechend können auf die komplexen Spezialvorschriften für die in der Standard-Software-industrie verbreiteten Mehrkomponentenverträge verzichtet werden, weil jeder Ver-trag gewissermassen als Vereinbarung mit mehreren Komponenten betrachtet wird. Denn es wird nicht mehr auf die gestaltungsanfällige Abgrenzung von einzelnen Vertragselementen fokussiert, sondern auf einzeln bewertbare Leistungspflichten.

Die Umsatzabgrenzung soll nach dem obligation extinguishment view erfolgen, welcher die Umsatzerfassung als Leistungen gegenüber dem Kunden definiert. Da-bei wird das Abgrenzungskriterium implizit an das einfach überprüfbare Kriterium des Vorhandenseins eines Vertrags geknüpft. Dadurch findet ein Ersatz des heuti-gen nicht trennungsscharfen Ansatzes der typischen Geschäftstätigkeit statt. Nach dem obligation extinguishment view löst zudem das Outsourcing ohne Rechtsüber-trag einen Umsatzvorgang beim ursprünglichen Vertragspartner aus. Dadurch unter-liegen diese Outsourcing-Geschäfte erhöhten Offenlegungspflichten und die Um-satzerfassung wird nicht von Entscheidungen des Managements (make or buy) be-einflusst.

Die Umsatzbewertung ist nach dem CBV vorzunehmen und wird damit dem fair value Ansatz vorgezogen. Der fair value Ansatz stellt aus konzeptioneller Sicht un-bestritten eine sehr sinnvolle Lösung dar, weil er auf Marktwerte abstellt, welche grundsätzlich zeitnah und objektiv sind. In der Praxis zeigen sich jedoch bei der Ermittlung dieser Werte grosse Schwierigkeiten. In der Standard-Softwareindustrie führen zum einen die individuellen, spezialisierten Leistungspflichten in Vereinba-rungen und zum anderen die schnellen Produktzyklen von Standard-Software viel-fach zu Leistungspflichten, welche einmaligen Charakter aufweisen. Dadurch ist jedoch die Ermittlung eines Marktwertes in vielen Fällen nicht möglich. Diesem

Page 166: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 148

Umstand trägt der CBV Rechnung, indem er ein mehrstufiges Bewertungsmodell zur Verfügung stellt. Der CBV verwendet aktuelle Transaktionspreise in einem ak-tiven Markt (Stufe 1), kann jedoch über mehrere Stufen bis auf interne Berechnun-gen des Unternehmens (Stufe 4) zurückgreifen. Er gewährleistet damit, dass jeder-zeit eine verlässliche Bewertung der Leistungspflichten möglich ist.

Die Offenlegungspflichten sind auf die Neuerungen des assets-and-liabilities An-satzes zurückzuführen. So sollen die Umsätze aus den neu eingeführten pre-performance assets und liabilities getrennt von den post-performance assets und liabilities erfasst und in der Bilanz eine eigene Kategorie pre-performance assets und liabilities eingeführt werden. Zusätzlich sind die Bewertungsmethoden und -grundlagen des CBV detailliert im Anhang anzugeben.

3. (Selbsterstellte) Standard-Software

3.1. Einleitung

In den IFRS und US-GAAP ist die Aktivierung selbsterstellter Standard-Software grundsätzlich ähnlich geregelt. Während die IFRS selbsterstellte Software als For-schungs- und Entwicklungskosten unter dem IAS 38 Immaterielle Vermögenswerte behandeln, hat das FASB einen spezifischen Standard (SFAS 86) für die Bilanzie-rung von selbsterstellter Software entwickelt. Beide Standardsetter verfolgen jedoch denselben Ansatz der Unterteilung der Softwareentstehung in zwei Phasen: Einem ersten Teil der Softwareaufwendungen (in den IFRS als Forschungsphase betitelt), dem keine eindeutige Zweckbindung zugestanden wird, wird eine Bilanzierung verweigert. Ab einem gewissen Punkt, der als technische Realisierbarkeit bezeich-net wird und den Beginn der zweiten Phase bewirkt, sollen alle anfallenden Kosten der Erstellung (in den IFRS als Entwicklungsphase) aktiviert werden. Der Herstel-lungszeitraum des Quellcodes gilt als beendet, wenn er für die Kunden, d. h. für die Vervielfältigung freigegeben wird. Die Kosten für Wartungsausgaben des Quellco-des sind daher als Aufwand zu erfassen.

Die Entstehungsphasen von (Standard-)Software werden von der aktuellen Rech-nungslegung folgendermassen dargestellt:

Page 167: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 149

1. Phase: 2. Phase:

Technische Realisierbarkeit ist

erreicht

Absatzreife ist erreicht

„Forschungsphase“ des Quellprogramms

„Entwicklungsphase“ des Quellprogramms

Zeit

Abbildung 21: Entstehungsphasen von (Standard-)Software aus Rechnungslegungssicht

Somit handelt es sich bei Software um eines der wenigen immateriellen Werte, de-nen von den Standardsettern auch bei einer originären Erstellung eine Bilanzierung zugebilligt wird.369

Die Verwendung des Abgrenzungskriteriums technische Realisierbarkeit hat in der Praxis jedoch zu zwei Problemen geführt:

• Die unterschiedlichen Interpretationen (Cafeteria-Prinzip) des Kriteriums technische Realisierbarkeit haben dazu geführt, dass in der Praxis Kapitali-sierungen von Softwareentwicklungen nicht einheitlich vorgenommen wur-den. Die Forderungen der comparability/consistency, wonach Informationen im Inter-Unternehmensvergleich aussagekräftig sein müssen, werden damit nicht erfüllt.

• Die aufgrund des Kriteriums technische Realisierbarkeit mögliche Nicht-An-setzung von Aufwendungen für die Softwareentwicklung, welche viele Un-ternehmen in der Praxis vornehmen, führt dazu, dass der Anforderung der materiality in ungenügender Weise Folge geleistet wird, da dem Investor wichtige Informationen vorenthalten werden.

369 Diese Überlegung basiert auf der Ähnlichkeit des Softwareerstellungsprozesses mit der Erstellung von materiellen Gütern. Vgl. Abschnitt III 2.2.

Page 168: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 150

3.2. Optionen

Die restriktive Haltung der Standardsetter gegenüber der Bilanzierung von selbster-stellten immateriellen Werten basiert hauptsächlich auf dem Vorsichtsprinzip (con-servatism). Die Aktivierung von diesen Vermögenswerten birgt nämlich die Gefahr, dass so genannte Nonvaleurs willkürlich aktiviert werden, die tatsächlich nicht ver-wertbar sind. Unter anderem mit dem grundsätzlichen Ansatzverbot der US-GAAP für Aufwendungen im Rahmen der Forschung und Entwicklung oder dem Ansatz-verbot der IFRS für zum Beispiel selbst geschaffene Markennamen soll erreicht werden, dass nur solche Güter aktiviert werden, deren Existenz und Werthaltigkeit entweder durch einen entgeltlichen Erwerb oder durch restriktive Ansatzkriterien objektiviert werden. Allerdings ist fraglich, ob die Unsicherheit, dass es sich bei einem immateriellen Gut wirklich um einen Nonvaleur handelt, im gleichen Masse für alle immateriellen Werte gilt. Daher wird im Folgenden untersucht, ob für (Standard-)Software im Vergleich zu den materiellen Werten eine besondere Unsi-cherheit besteht, die dementsprechend eine besondere Bilanzierungsmethode recht-fertigt.

Aus diesem Grund werden zunächst der Entstehungsprozess eines materiellen Gutes (gezeigt am Beispiel einer Maschine) und derjenige des immateriellen Gutes (Stan-dard-)Software verglichen. Dabei kann die Entstehung einer Maschine in folgende Phasen eingeteilt werden: Zu Beginn muss die Maschine entwickelt werden. Das Ergebnis dieser ersten Phase, der Forschungsphase370, wird in Form von Entwürfen, Konstruktionszeichnungen oder Arbeitsmodellen festgehalten. Am Anfang dieser Phase ist noch unsicher, ob überhaupt, wann und mit welchem Mitteleinsatz ein Ar-beitsmodell für eine Maschine entsteht. Die Unsicherheit dieser Phase besteht nicht zuletzt in einem möglichen technischen Misserfolg. In der Entwicklungsphase wird dann auf der Grundlage der Entwürfe, Konstruktionszeichnungen oder Arbeitsmo-delle ein Prototyp gefertigt. Soll nur eine einzelne Maschine erstellt werden, also ein Einzelgut, so endet der Entstehungsprozess mit der Fertigstellung des Prototyps. Ist hingegen eine Serienfertigung vorgesehen, so werden die Maschinen im Wege der Vervielfältigung des Prototyps erzeugt.

370 Dieser Begriff wird an dieser Stelle verwendet, um in Übereinstimmung mit den IFRS zu sein.

Page 169: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 151

Die Softwareerstellung kann grundsätzlich grob in zwei Phasen eingeteilt wer-den.371 In der ersten Phase, der Entwicklungsphase, wird die Software entwickelt. Als Ergebnis wird das Programmdesign zum Beispiel in Diagrammform dargestellt. Wie im Fall der Entwicklung einer Maschine ist auch bei der Softwareerstellung am Anfang unsicher, ob, wann und mit welchem Mitteleinsatz ein Output, also ein Ent-wurf einer Software entsteht. In einer zweiten Phase, der Entwicklungsphase, wird auf der Grundlage des Entwurfs die eigentliche Programmierarbeit erledigt und der Quellcode erstellt.

Die Ausführungen haben gezeigt, dass die Herstellung von Software grundsätzlich keine im Vergleich zu einer Maschine besonderen Unsicherheiten aufweist.372 Kon-sequenterweise sollten diese Sachverhalte auch bilanziell ähnlich behandelt werden. Diesen Schritt haben sowohl das FASB als auch das IASB gemacht. Die Bilanzie-rung von selbsterstellter Software erfolgt analog zur Herstellung einer Maschine, indem die zurechenbaren Kosten aktiviert werden können. Die Standardsetter legen der Aktivierung von Software einzig das Kriterium der technischen Realisierbarkeit vor, um sicherzustellen, dass die Werthaltigkeit gegeben ist. Am Ansatzkriterium technische Realisierbarkeit wird jedoch stark bemängelt, dass es nicht hinreichend operational und somit nicht intersubjektiv nachprüfbar sei. In Abschnitt IV 2.3 wur-de aufgezeigt, dass diese Ungenauigkeiten dazu führen, dass sich in der Praxis un-terschiedlichste Formen der Behandlung von selbsterstellter Software entwickelt haben. In einem Brief an den damaligen FASB-Vorsitzenden Dennis Beresford führte 1996 die Software Publishers Association folgende Argumente gegen eine Verwendung des Kriteriums der technischen Realisierbarkeit ins Feld:373

“As a result of the dynamic nature of today’s software industry and con-tinual generation of high risk development issues, an increasing number of software companies believe that technological feasibility is not reached until very late in the development cycle. Subsequent costs are

371 Diese Einteilung wird verschiedentlich mit synonymen Begriffen und unterschiedlicher Extensität vari-iert; die Abweichungen bleiben jedoch unwesentlich. Vgl. von Keitz (1997), S. 143, ähnlich Sauer (1988), S. 5-10.

372 Vgl. dazu von Keitz (1997), S. 247f. 373 Brief von Ken Wasch, Präsident, Software Publishers Association, an Dennis Beresford, Vorsitzender,

Financial Accounting Standards Board vom 14. März 1996; zitiert nach Utpon (2001), S. 66.

Page 170: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 152

inherently immaterial so most companies charge all software develop-ment costs to research and development expense.”

Und weiter:

“Greater consistency in financial reporting would result if all software development costs were charged to expense as incurred. Given the diffi-culties in determining when technological feasibility is established, as noted above, financial reporting and financial statements would be more reliable and consistent if all software development costs were required to be charged to expense.”

Aufgrund der unbefriedigenden aktuellen Situation sollen im Folgenden verschie-dene alternative Rechnungslegungsansätze vorgestellt werden, welche der Ähnlich-keit des Erstellungsprozesses von Standard-Software mit materiellen Gütern Rech-nung tragen sollen, jedoch eine bessere praktische Umsetzung ermöglichen:

3.2.1.

„Identifikation“ als Ansatzkriterium

Eines der drei zentralen Charakteristika eines Vermögenswertes ist, dass er auf „ei-ner Transaktion oder einem Ereignis in der Vergangenheit“ beruht. Ein üblicher Weg, um in den Besitz eines solchen Aktivums zu gelangen, besteht in einer Tauschaktion jedweder Art. So wird der Kaufakt bei Marken, Software und ande-rem (also der Tausch von Geld gegen einen immateriellen Wert) allgemein als ge-nügendes Ereignis (neben den Kriterien des zukünftigen wirtschaftlichen Nutzens und der Kontrolle) für die Anerkennung des immateriellen Gutes als Aktivum be-trachtet.374

Mit dem Ansatzkriterium der „Identifikation“ ergibt sich die Möglichkeit eines al-ternativen Ansatzes zur bilanziellen Anerkennung von Vermögenswerten. Dieser Ansatz ermöglicht, dass generell auch intern generierte immaterielle Werte ange-setzt werden können. Dadurch schwindet die oft kritisierte Diskriminierung von derivativ erworbenen und somit in der Bilanz ansetzbaren Gütern und intern entwi-ckelten Werten, die aufgrund der fehlenden Transaktion bzw. des fehlenden Ereig-

374 Vgl. Dawo (2003), S. 133.

Page 171: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 153

nisses in der Vergangenheit nicht aktivierbar sind. Dieser Ansatz wird sowohl von den IFRS allgemein für F&E-Ausgaben (inklusive Software) als auch von den US-GAAP nur für gewisse immaterielle Werte (z. B. Software, Filme, Tonträger) be-reits angewandt. Für Software kommt nach beiden Standardsettern die technische Realisierbarkeit als „Identifikationskriterium“ zur Anwendung. Dies bedeutet, dass intern entwickelte Software in der Bilanz angesetzt werden kann, falls sie die An-satzkriterien der technischen Realisierbarkeit erfüllt.

Während eine externe Transaktion ein relativ verlässliches Instrument zur Be-stimmung der Werthaltigkeit eines solchen Wertes darstellt, ist hingegen fraglich, ob ein Identifikationskriterium dasselbe leisten kann. Grundsätzlich kann es als ver-lässlich angenommen werden, wenn es intersubjektiv überprüfbar ist. Genau diese Eigenschaft wird dem Ansatzkriterium technische Realisierbarkeit jedoch nicht zu-gesprochen. Es wird also nicht so sehr das Prinzip der Identifikation als unzurei-chend bemängelt als vielmehr die Verwendung eines untauglichen Kriteriums. Der Einsatz eines praktikableren Identifikationskriteriums könnte daher die aktuelle Si-tuation möglicherweise verbessern. Die Forderungen an ein solches Kriterium müs-sen seine gute intersubjektive Überprüfbarkeit (reliability) und seine zeitnahe Wirk-samkeit sein (timeliness).

In Frage kommt daher nur ein Identifikationskriterium, welches nicht auf das ein-zelne Produkt fokussiert und aufgrund der Individualität von Software weder wirk-lich zeitnah noch überprüfbar sein kann, sondern welches auf breiter Basis ansetzt und sich auf das ganze System der Standard-Softwareentwicklung bezieht. Ein sol-ches kann zum Beispiel ein Kriteriensystem sein, welches die Qualität des Stan-dard-Softwareerstellungsprozesses sicherstellt. Dieses erlaubt antizipativ Aussagen zur technischen Realisierbarkeit von Standard-Softwareprodukten zu machen, wel-che diesen qualitativ gesicherten Entwicklungsprozess durchlaufen. Damit ist ge-währleistet, dass das derzeitige Problem der beschränkten Aussagekraft eines akti-vierten Vermögenswertes aufgrund der späten Erfüllung der Voraussetzungen der technischen Realisierbarkeit nicht eintrifft, da die Prozessqualität vor der eigentli-chen Herstellung feststeht und beurteilt werden kann. Hinsichtlich der intersubjekti-ven Überprüfbarkeit der Prozessqualität stellen sich jedoch generell ähnliche Prob-leme wie bei der technischen Realisierbarkeit. Entsprechend muss hier auf ein Kri-teriensystem abgestellt werden, welches diese Objektivierung ermöglicht. Dafür in

Page 172: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 154

Frage kommen Modelle, welche die Bewertung der Prozessreife in der Software-entwicklung anstreben, wie die capability maturity model integration (CMMI)375 oder die ISO Norm 15504 (bzw. SPICE). Aufgrund ihrer inhaltlichen Ähnlichkeit soll nur das auf einer längeren Entwicklungsgeschichte beruhende CMMI (bzw. CMM) näher vorgestellt werden. Das CMMI ist ein allgemeines Prozessmodell zur Beurteilung und Verbesserung der Qualität ("Reife") von Produkt-Entwicklungs-prozessen in Organisationen. Es hat sich aus dem älteren CMM für Software heraus entwickelt und ist deshalb auf die Beurteilung von Softwareentwicklungsprozessen optimiert. Das primäre Ziel des CMMI ist es, die Produktentwicklung zu verbes-sern. Sekundär dient die offizielle Überprüfung eines Reifegrades des CMMI (ap-praisal) als eine de facto anerkannte Auszeichnung in der Industrie. Es sind zurzeit vier Anwendungsgebiete für das CMMI definiert, wobei an dieser Stelle nur auf die Softwareentwicklung eingegangen wird.376 Zentrales Element aller Modelle wie CMM, CMMI (bei der stufenförmigen Darstellung) oder SPICE ist das Vorhanden-sein eines Stufensystems, welches den Grad der Institutionalisierung der Prozesse misst und einordnet. Das CMMI adressiert dabei die Verbesserung durch so ge-nannte Reifegrade (maturity levels). Das Modell377 besteht aus fünf Stufen von Rei-fegraden:378

375 Das ursprüngliche capability maturity model (CMM) für Software wurde 2003 durch das allgemeine Prozessmodell CMMI erweitert und ersetzt. Strukturell haben sich für den Softwarebereich jedoch keine wesentlichen Änderungen ergeben. Das CMM entspricht nun weitestgehend einem Modul des CMMI.

376 Die vier Anwendungsgebiete bestehen aus Projektmanagement, Entwicklung, Unterstützung und Pro-zessmanagement, wobei hier nur auf das Anwendungsgebiet Entwicklung (von Software) eingegangen wird.

377 Aufgrund des integrativen Anspruchs des CMMI ist jedem dieser Reifegrade (ausgenommen Reifegrad 1) eine Reihe von Prozessgebieten (z. B. Projektplanung, Anforderungsentwicklung, organisationsweite Prozessdefinition) mit konkreten Anforderungen zugeordnet. Diese Prozessgebiete werden in der konti-nuierlichen Darstellung wiederum einzeln nach so genannten Fähigkeitsgraden (capability levels) be-wertet. Dieser Aspekt des CMMI soll in der Dissertation jedoch nicht weiter verfolgt werden.

378 Vgl. o.V. (2002b), S. 20.

Page 173: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 155

initial

managed

defined

quanitativelymanaged

optimizing

Keine Anforderungen, diesen Reifegrad hat jede Organisation automatisch (Fokus: Kompetente Leute und „Heros“)

Die Projekte werden gesteuert und ein ähnliches Projekt kann erfolgreich wiederholt werden (Fokus: Einfaches Projektmanagement)

Alle Projekte werden nach einem angepassten Standard-Prozess durchgeführt, und es gibt eine kontinuierliche Prozessverbesserung (Fokus: Prozessstandardisierung)

11

22

33

Es wird eine statistische Prozesskontrolle durchgeführt (Fokus: Quantitatives Management)

44

55 Die Prozesse werden mit den Daten aus der statistischen Prozesskontrolle verbessert (Fokus: Kontinuierliche Prozessverbesserung)

Abbildung 22: Stufendarstellung der Reifegrade des CMMI379

Auf jeder Stufe des Modells sind bestimmte Praktiken im Unternehmen einzufüh-ren, welche sich im Softwareerstellungsprozess auch widerspiegeln müssen:380

Die Stufe 1 des CMMI verwendet den eher unzureichenden Begriff initial, denn die Prozesse sind als ad hoc oder sogar chaotisch zu charakterisieren. Die Prozesse sind wenig oder nicht definiert und der Erfolg eines Projektes hängt in erster Linie vom Einsatz und der Kompetenz einzelner Mitarbeiter ab ("Helden"). Die Stufe 2 mana-ged fordert, dass die wesentlichen Managementprozesse zu etablieren sind, um Kos-ten, Zeitplan und Funktionalität von Projekten zu planen und zu steuern. Mit Reife-grad 2 ist also im Wesentlichen ein detailliertes Projektmanagement einzuführen. Die Stufe 3, als defined betitelt, verlagert den Schwerpunkt von den einzelnen Pro-jekten auf die Organisation als Ganzes und von den Management-Aktivitäten zu den Entwicklungsaktivitäten. Die meisten Anforderungen beziehen sich darauf, einheit-liche Prozesse für die gesamte Organisation einzuführen, während auf Reifegrad 2 noch jedes Projekt weitgehend eigene, individuelle Prozesse nutzte. Beim Übergang von Stufe 3 auf Stufe 4 quantitatively managed kommt die intensive Nutzung von Metriken und Kennzahlen hinzu, um eine bessere Entscheidungsgrundlage für Ver-besserungsaktivitäten zu bekommen. Die Stufe 5 optimizing konzentriert sich auf

379 In Anlehnung an Ahern et al. (2004), S. 93. 380 Vgl. o.V. (2002b), S. 9ff.

Page 174: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 156

die kontinuierliche Verbesserung mit der systematischen Auswahl und Einführung von Verbesserungen sowie der systematischen Analyse von noch auftretenden Feh-lern und Problemen.

Das CMMI bzw. die ähnliche ISO Norm 15504 (SPICE) haben somit offensichtlich das Potenzial, den Softwareentwicklungsprozess zu bewerten und damit auch indi-rekt Aussagen über die Wahrscheinlichkeit der technischen Realisierbarkeit der re-sultierenden Softwareprodukte zu machen. Durch das appraisal-Verfahren steht zudem eine externe Überprüfungsmethode zur Verfügung, welche den Umsetzungs-grad der Anforderungen des Prozessmodells bewertet. Während die Modelle mit fünf Stufen operieren, steht der Rechnungslegung jedoch nur ein zweistufiges Ver-fahren zur Verfügung. Es muss somit bestimmt werden, welche Stufe eine genü-gend hohe Wahrscheinlichkeit des (technischen) Erfolgs verspricht, um eine Akti-vierung der Ausgaben zu rechtfertigen. Dabei ist die Aktivierungshürde auf Stufe 3 ins Auge zu fassen, denn der standardisierte Prozess erlaubt, mit grosser Wahr-scheinlichkeit ein technisch erfolgreiches Standard-Softwareprodukt zu kreieren.381 Grundsätzlich ist auch zu überlegen, ob eine modellähnliche fünfstufige Differen-zierung der Aktivierung der Ausgaben in der Rechnungslegung vorgenommen wer-den soll. Dabei müsste der zu aktivierende Betrag die der Fähigkeitsstufe entspre-chende Erfolgswahrscheinlichkeit der Entwicklung eines (technisch) einwandfreien Softwareprodukts reflektieren. Dies bedeutet, dass zum Beispiel ein Unternehmen mit Reifegrad 1 durchaus zehn Prozent seiner gesamten Aufwendungen aktivieren könnte, wenn die statistisch nachweisbare Erfolgswahrscheinlichkeit auf dieser Stu-fe auch zehn Prozent beträgt. Eine solche Rechnungslegungspraxis verändert jedoch die Qualität von aktivierten Beträgen fundamental. In der Bilanz aktivierte Werte sind daher nicht mehr als werthaltig im hergebrachten Sinne zu taxieren; vielmehr reflektieren sie eine statistisch berechnete Wahrscheinlichkeit und unterliegen damit auch diesen (Ausfall-)Gesetzmässigkeiten. Diesen Paradigmenwechsel scheinen die Standardsetter jedoch nicht unterstützen zu wollen, da bisher keine Vorstösse zu einer nach Erfolgswahrscheinlichkeiten abgestuften Aktivierung vorzufinden sind.

381 Die US Air Force untersuchte die Kosten- und Terminverlässlichkeit bei 31 Softwareprojekten von 11 Softwareunternehmen, welche die CMMI-Stufen zwischen 1 und 3 erfüllten. Dabei zeigten sich signifi-kante Verbesserungen von Stufe 2 zu 3, wobei sich insbesondere das Streumass bei der Kostenzuverläs-sigkeit stark reduzierte. Vgl. zu Resultaten der Studie Lawlis et al. (1995).

Page 175: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 157

Dieses Verhalten ist sicherlich durch den Einfluss der Forderung nach conservatism begründet, welche nachträgliche Wertkorrekturen und Ausfälle weitgehend aus-schliessen will.

3.2.2.

Rückwirkende Aktivierung

Um die Nachteile der bisherigen Vorschläge zu vermeiden, wäre es notwendig, dass aufgrund der Erfolgsunsicherheit eine Aktivierungsentscheidung erst am Ende des Produktionsprozesses von immateriellen Werten zu treffen und erst dann eine Akti-vierung vorzunehmen ist.382 Die rückwirkende Aktivierung basiert deshalb darauf, dass Ausgaben für die interne Entwicklung von Standard-Software (aber auch für F&E Projekte) als Aufwand in der Erfolgsrechnung verbucht werden bis der Beweis gelungen ist, dass entweder die technische Realisierbarkeit des Produkts erfüllt (bei Variante 1) oder seine Umsatzwirksamkeit bewiesen ist (bei Variante 2). Von die-sem Zeitpunkt an werden alle für das Projekt bereits getätigten Ausgaben rückwir-kend aktiviert und über die Nutzungsdauer abgeschrieben. Folgende Abbildung soll diesen Vorgang mit den Varianten 1 und 2 illustrieren:

382 Vgl. allgemein Høegh-Krohn/Knivsflå (2000), S. 259ff.; in Bezug auf US-GAAP Lev/Zarowin (1999), S. 35ff.

Page 176: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 158

1. Phase:„Forschungsphase“ des Quellprogramms

2. Phase:„Entwicklungsphase“ des Quellprogramms

3. Phase:„Wartungsphase“ des Quellprogramms

4. Phase:„Vervielfältigungsphase“ des Quellprogramms

Technische Realisierbarkeit

ist erreicht

Umsatzwirksamkeitist erreicht

Zeitleiste:

Phasen:

Rechnungs-legung:

Aktivierung aller

Ausgaben

Ausgaben werden als Aufwand

verbucht

Abschreibung über die Nutzungsdauer

Rückwirkende Aktivierung der

Ausgaben aus 1. Phase

Variante 1

Variante 2Ausgaben werden

als Aufwand verbucht

Abschreibung über die Nutzungsdauer

Rückwirkende Aktivierung der

Ausgaben aus 1. + 2. Phase

Abbildung 23: Vorgang der rückwirkenden Aktivierung

Hinsichtlich der konkreten Umsetzung dieses Konzepts sind zwei Fragestellungen zu beantworten: Zum einen zu welchem Zeitpunkt die Aktivierung vorgenommen werden soll und zum zweiten, ob die Aktivierung erfolgsneutral oder erfolgswirk-sam zu erfolgen hat.

Der Zeitpunkt, zu welchem die Erfüllung der Kriterien eines Vermögenswertes vor-ausgesetzt werden kann, ist grundsätzlich nicht exakt bestimmbar. Es stehen jedoch vor allem zwei Kriterien im Vordergrund: Die technische Realisierbarkeit und die Umsatzwirksamkeit. Auf die technische Realisierbarkeit wird hauptsächlich im Um-feld der US-GAAP abgestellt, da dieses Kriterium bereits in SFAS 86 verwendet wird. Im Gegensatz zu SFAS 86 wird jedoch bei Erreichen der technischen Reali-sierbarkeit keine Unterscheidung gemacht von Aufwendungen, welche vor und nach dem Eintritt der technischen Realisierbarkeit anfallen.383 Es sollen demnach sowohl die nach dem Zeitpunkt der Feststellung der technischen Realisierbarkeit anfallenden Aufwendungen als auch alle bereits in den vorangegangenen Perioden erfolgten Ausgaben, welche sich auf den Vermögenswert beziehen, aktiviert wer-

383 Vgl. Lev/Zarowin (1999), S. 36; Lev (2001), S. 125.

Page 177: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 159

den. Der Vorteil der rückwirkenden Aktivierung liegt darin, dass dem Bilanzieren-den ermöglicht wird, in einer bestimmten Periode dem Investor wichtige Informati-onen über den Erfolg der eigenen Entwicklungsarbeiten zu vermitteln.384 Durch die rückwirkende Aktivierung zum Zeitpunkt der technischen Realisierbarkeit wird dem Investor nämlich eine Reduktion des mit der Investition verbundenen Risikos kommuniziert. Das Kriterium der technischen Realisierbarkeit leidet jedoch – wie in Abschnitt IV 2.3.3 dargelegt – unter seiner mangelnden Operationalisierbarkeit, welche sich durch eine fehlende intersubjektive Überprüfbarkeit auszeichnet. Mit der Beibehaltung des Abgrenzungskriteriums der technischen Realisierbarkeit wird ein Hauptproblembereich der heute gültigen Rechnungslegungsstandards auf den neuen Ansatz übertragen, womit seine Lösungsfähigkeit stark eingeschränkt ist.

Eine Verbesserung verspricht daher die Verwendung eines alternativen, besser ob-jektivierbaren Ansatzkriteriums wie das von CHRISTOFFERS vorgeschlagene Krite-rium der Umsatzwirksamkeit.385 Dieses Kriterium weist gegenüber dem Kriterium der technischen Realisierbarkeit zwei Vorteile aus: Erstens setzt das Kriterium erst zu einem Zeitpunkt an, zu dem das zu aktivierende Objekt einen Vermögenswert darstellt, da nicht nur der technische, sondern auch der wirtschaftliche Gehalt über-prüft wird. Sofern eine selbsterstellte Standard-Software keine Verwendung findet, erfolgt auch keine Aktivierung, da in diesem Fall kein Umsatz generiert wird. Zwei-tens ist die Erfüllung des Umsatzkriteriums grundsätzlich einfacher objektivier- und damit überprüfbar. Die Validität des Umsatzkriteriums wird allerdings in der Stan-dard-Softwareindustrie durch die verbreitete Praxis eingeschränkt, neue Standard-Softwareprodukte zuerst bei Testkunden zu lancieren. Dieses Vorgehen entspricht jedoch nur bedingt einem Markttest des Produkts, weil die risikobehaftete (Test-)Einführung zumeist durch stark reduzierte Preise und einem weitgehenden Gewährleistungsausschluss gegenüber dem Testkunden „erkauft“ wird. Dadurch kann der Beginn der Umsatzgenerierung und damit der Zeitpunkt der Aktivierung der Standard-Software durch das Management teilweise beeinflusst werden. Hinzu kommt, dass das wirtschaftliche Potenzial des Produkts durch Testkunden nicht un-bedingt bestätigt wird, da diese das Produkt zu marktfremden Sonderkonditionen

384 Vgl. Lev (2001), S. 125. 385 Vgl. Christoffers (1970), S. 170.

Page 178: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 160

beziehen. Es ist deshalb in diesem Zusammenhang zu überlegen, ob Umsätze basie-rend auf Vereinbarungen mit Testcharakter als ungenügend für die Aktivierung von Softwareprodukten zu taxieren sind.

Eine rückwirkende Aktivierung kann in der Erfolgsrechnung sowohl erfolgsneutral als auch erfolgswirksam behandelt werden. In beiden Fällen werden die Aufwen-dungen bis zum Erreichen der Aktivierungskriterien als Aufwand über die Erfolgs-rechnung verbucht. Dies entspricht dem erhöhten Risiko bei der Entwicklung von immateriellen Werten, da noch nicht absehbar ist, welche Aufwendungen später zu abgrenzbaren Vermögenswerten führen. Im Zeitpunkt der technischen Realisierbar-keit oder der Umsatzwirksamkeit wird dann entweder eine erfolgsneutrale oder eine erfolgswirksame Aktivierung der für die Schaffung des Vermögenswertes angefal-lenen Aufwendungen vorgenommen.

Bei einer erfolgsneutralen Aktivierung erfolgt daraufhin ein korrekter Ausweis von Erträgen und zugehörigem Aufwand, womit dem matching principle Folge geleistet wird. Die Problematik der erfolgsneutralen Aktivierung liegt jedoch darin, dass durch die erfolgswirksamen Abschreibungen die rückwirkend aktivierten Beträge für immaterielle Werte zweimal als Aufwand durch die Erfolgsrechnung laufen. Dadurch entspricht die Summe der Periodenerfolge nicht dem Totalgewinn der Ge-samtperiode, was zu einer Beeinträchtigung der Vergleichbarkeit der Ergebnisse über die Zeit (comparability/consistency) führt.386 Falls ein Unternehmen Standard-Software über mehrere Jahre entwickelt und die Software erst nach einigen Jahren die Merkmale eines Vermögenswertes erfüllt, so sind bei einer erfolgsneutralen rückwirkenden Aktivierung (erneut) erfolgswirksame Aufwendungen (Abschrei-bungen) vorzunehmen. Aufgrund der dabei resultierenden zweimaligen Verrech-nung des Aufwands in der Erfolgsrechnung wird die Ertragslage jedoch tendenziell zu schlecht ausgewiesen. Aus diesen Gründen ist eine nachträgliche Neudarstellung (restatement) aller durch die rückwirkende Aktivierung betroffenen Perioden un-umgänglich. Dies führt jedoch zwangsläufig zu einer unerwünschten Praxis der vor-läufigen Geschäftsabschlüsse mit entsprechender Komplexität und Unübersichtlich-keit.

386 Vgl. Dawo (2003), S. 311.

Page 179: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 161

Diesen Nachteilen kann durch eine erfolgswirksame, rückwirkende Aktivierung des Vermögenswertes begegnet werden. Dabei wird jedoch das Realisationsprinzip ver-letzt, welches verlangt, dass dem Erfolgsausweis prinzipiell eine Umsatzrealisation zugrunde liegen muss. DAWO argumentiert, dass durch diese Behandlung das Reali-sationsprinzip im Grunde nicht verletzt werde, da dieses nur zum Ziel habe, das Vorgreifen auf noch nicht zugegangene Vermögenszuwächse zu verhindern. Die rückwirkende Aktivierung ist auf den zuvor als Aufwand verrechneten Betrag be-grenzt, womit das erwartete Nutzenpotenzial nicht aktiviert und daher auch nicht als Erfolg ausgewiesen wird.387 Diese Beurteilung ist jedoch hinsichtlich mehrerer As-pekte kritisch zu betrachten. So widerspricht sie der bestehenden Ertragsauffassung der IFRS und der US-GAAP und unterläuft zudem die Bestrebungen der Standard-setter zur Entwicklung einer konsistenten prinzipienbasierten Umsatzrealisierung und Ertragserfassung, um die bestehende Abgrenzungsproblematik zu entschär-fen.388 Zudem wird das matching principle nur ungenügend eingehalten, da in der Aktivierungsperiode ein Ertrag ausgewiesen wird, welchem nicht der entsprechende Aufwand der vorherigen Jahre gegenübersteht. Dies führt zu einer hohen Volatilität der Erträge über die Zeit, welche die Forderung der comparability/consistency kaum erfüllt.

3.2.3.

Vermögenswerte in Entstehung

Dieser Ansatz geht davon aus, dass jegliches Ansatzkriterium am falschen Punkt ansetzt. Ein Standard-Software-Projekt beginnt mit der Intention, ein werthaltiges Aktivum wie ein Softwareprogramm zu entwickeln. Das Projekt wird dabei entwe-der in einem Erfolg oder in einem Misserfolg enden, doch das tatsächliche Resultat wird bis fast am Schluss unsicher bleiben. Bis dahin ergibt sich im Unternehmen eine Ansammlung von Kosten, die jedoch aufgrund der fraglichen Werthaltigkeit kein Aktivum konstituieren.

Die klassische Rechnungslegung behandelt gewisse (materielle) Vermögenswerte in Entwicklung so, dass ihre Kosten in der Bilanz unter Positionen wie Projekte in Ar-

387 Vgl. Dawo (2003), S. 312. 388 Vgl. Abschnitt V 2.2.2.1.

Page 180: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 162

beit, Bohrungen in Arbeit oder Bauten in Arbeit verbucht werden können. Dabei gibt es zwei Arten die Position „Vermögenswert in Entstehung“ zu betrachten:389

Die traditionelle Sichtweise sieht die Position „Vermögenswert in Entstehung“ als eine Art Sammelkonto für auflaufende Kosten. Die Position entspricht somit nicht einem eigentlichen Aktivum, sondern ist ein Instrument, um die Kosten von etwas zu akkumulieren, was schlussendlich ein Aktivum werden soll. Falls jedoch starke Unsicherheit darüber besteht, ob die Aufwendungen wirklich zu einem Aktivum führen, so müssen die Kosten als laufende Ausgaben behandelt werden. Bei den meisten materiellen Werten wie z. B. Gebäuden ist eine solche Sichtweise durchaus sinnvoll. So ist unbestritten, dass der Bau eines Gebäudes grundsätzlich sehr wahr-scheinlich zu einem Aktivum führt und entsprechend die Aufwendungen über Posi-tionen wie Bauten in Arbeit zu aktivieren sind. Bereits beim Fall von Bohrung in Arbeit ist die Situation jedoch weniger eindeutig. Es handelt sich dabei nicht um eine Akkumulierung von Aufwendungen, welche am Ende in Summe den Vermö-genswert konstituieren. Vielmehr handelt es sich um ein stochastisches Vorgehen. Aufgrund der bekannten Erfolgswahrscheinlichkeiten bei Bohrungsversuchen kön-nen diese Aufwendungen jedoch in Summe als sichere Investition hinsichtlich eines zukünftigen wirtschaftlichen Nutzens beurteilt werden. Diese Betrachtung ist für eine Aktivierung von Software jedoch nicht zielführend, denn solche Erfolgswahr-scheinlichkeiten sind der Softwareentwicklung nicht per se zuzuordnen. Der Erfolg hängt entscheidend von der individuellen Beherrschung des Softwareentwicklungs-prozesses ab.

Eine andere Sichtweise besteht darin, dass immaterielle Vermögenswerte in Entste-hung wie Standard-Software Aktiva eigener Art sind. Standard-Softwareentwick-lung führt nicht plötzlich in einem „magischen Moment“ zu einem Aktivum, son-dern ist zumeist ein kumulativer und iterativer Prozess, welcher sich in die Richtung eines vordefinierten Ziels entwickelt. Dabei hat zu jedem Zeitpunkt in der Entwick-lung die bereits vollbrachte Arbeit einen Wert, welche von anderen bezahlt wird. Der Aufwand kann sich im Endeffekt als erfolglos entpuppen, doch es beeinflusst nicht das Faktum, dass der Vermögenswert in Entstehung heute einen Wert hat. Dieses Phänomen kann mit einer finanziellen Option verglichen werden, welche an

389 Vgl. Upton (2001), S. 80.

Page 181: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 163

ihrem Laufzeitende einen Wert von Null haben kann, heute aber durchaus einen Wert von mehr als Null besitzt. Die Problematik dieses Ansatzes liegt jedoch darin, dass Standard-Software nicht den Standardisierungsgrad von finanziellen Optionen aufweist und deshalb keine Marktbewertung möglich ist.

3.3. Entscheidungsnutzenanalyse

Als Hauptargument für eine Aktivierung von Standard-Softwareaufwendungen als Bilanzierungshilfe wird angeführt, dass dadurch dem Rechenschaftszweck besser Rechnung getragen wird als bei direkter Aufwandsverrechnung. Denn im Sinne ei-ner periodengerechten Erfolgsermittlung wird die Ertragslage „korrekter“ darge-stellt, wenn die Aufwendungen verursachergerecht auf die zukünftigen Ertragsperi-oden verteilt werden (matching principle).390 Entsprechend wurden in diesem Kapi-tel drei Konzepte zur Aktivierung von Standard-Software vorgestellt, welche nun auf ihren Entscheidungsnutzen für den Investor überprüft werden sollen.

Das Konzept Vermögenswerte in Entstehung scheint auf den ersten Blick die aussa-gekräftigste Lösung zu sein. Es ermöglicht eine der risikobehafteten und nicht stan-dardisierten Natur der Standard-Softwareentwicklung angepasste Bilanzierung, in-dem keine besonderen Einschränkungen für eine Aktivierung bestehen Dadurch werden die Forderungen der relevance insgesamt gut erfüllt. Diesen Vorteilen ste-hen jedoch gewichtige Nachteile im Bereich der reliability gegenüber. Die fehlen-den konkreten Ansatzbedingungen führen dazu, dass es faktisch keine Beschrän-kung für die Aktivierung von Aufwendungen unter der Position „Software in Ent-wicklung“ gibt. Dem hohen potenziellen (Verlust-)Risiko von immateriellen Werten wie Softwareprojekten wird damit zu wenig Rechnung getragen. Dadurch wird ins-besondere das Vorsichtsprinzip (conservatism) in übermässigem Masse vernachläs-sigt. Der postulierten Begründung, dass Standard-Software in Entstehung eine ähn-liche Qualität habe wie materielle Werte in Entstehung, welche keinen speziellen Ansatzkriterien unterliegen, ist nicht zuzustimmen. Denn auch materielle Werte in Entstehung mit potenziell unsicherem Ausgang wie z. B. Bohrungen in Arbeit wei-sen bestimmbare Erfolgswahrscheinlichkeiten auf, welche durch ein mehrheitlich standardisiertes Bohrverfahren determiniert sind. Bei der Erstellung von Standard-

390 Vgl. von Keitz (1997), S. 243.

Page 182: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 164

Software ist hingegen der Erfolg hauptsächlich von der Art des Erstellungsprozes-ses abhängig. Des Weiteren ist die Informationsqualität der aktivierten Aufwendun-gen gering, da keine Differenzierung nach wahrscheinlich erfolgreichen Erstel-lungsprozessen stattfindet. Entsprechend kann der Investor einzig herauslesen, wie hoch die Investitionen in die Standard-Softwareentwicklung sind – über deren Qua-lität und damit über ihre Erfolgswahrscheinlichkeit erfährt er jedoch nichts.

Die rückwirkende Aktivierung begegnet dem Problem der ungenügenden reliability bei der anforderungsfreien Aktivierung von Standard-Software, indem diese erst bei Sicherstellung gewichtiger Faktoren vorgenommen wird. Diese Faktoren können entweder die technische Realisierbarkeit oder die Umsatzwirksamkeit sein. Wäh-rend die technische Realisierbarkeit gegenüber dem Kriterium der Umsatzwirksam-keit durch seine zumindest theoretisch frühere Erreichbarkeit dem Investor Vorteile im Bereich timeliness bietet, ist die neutrality und comparability/consistency auf-grund ihrer mangelnden intersubjektiven Überprüfbarkeit eingeschränkt. Das An-satzkriterium der Umsatzwirksamkeit bietet deshalb hinsichtlich der Entschei-dungsnützlichkeit eine bessere Lösung an. Durch die spätere Erfüllbarkeit des Krite-riums ist eine leicht verschlechterte timeliness zu erwarten, welcher jedoch eine stark verbesserte reliability gegenübersteht. Das Kriterium der Umsatzwirksamkeit ist grundsätzlich einfach intersubjektiv überprüfbar und bietet somit dem Investor eine gute Informationsqualität. Als gewichtigstes Argument gegen die rückwirkende Aktivierung spricht, dass das Prinzip verletzt wird, dass Beträge nur einmal durch die Erfolgsrechnung laufen dürfen. Dies impliziert, dass bei einer erfolgsneutralen rückwirkenden Aktivierung eine nachträgliche Neudarstellung der betroffenen Peri-oden erfolgen muss, um die Erfolgsrechnung nicht zweimal zu belasten und damit Gewinne zu tief auszuweisen. Eine nachträgliche Neudarstellung führt jedoch zu einer starken Einschränkung der comparability/consistency. Diesem Problem schafft eine erfolgswirksame rückwirkende Aktivierung Abhilfe. Dieses Konzept leidet jedoch darunter, dass der erfolgswirksamen Aktivierung kein Umsatzvorgang zugrunde liegt. Daher hat nach den Regelungen der Standardsetter kein regulärer Periodenerfolg stattgefunden und somit wird die Forderung der representational faithfulness verletzt. Zudem führt dieses Vorgehen zu starken Ertragsschwankungen über die Zeit, welche nur durch die Verrechnungstechnik und nicht durch die

Page 183: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 165

zugrunde liegende Geschäftstätigkeit verursacht wird, womit wiederum die repre-sentational faithfulness verletzt wird.

Als Alternative bietet sich die weitere Verwendung eines Identifikationskriteriums an – wie dies von den Standardsettern mit dem Kriterium der technischen Realisier-barkeit bereits mit allerdings beschränktem Erfolg gemacht wird. Der Erfolg des Identifikationskriteriums basiert jedoch entscheidend auf der Qualität des eingesetz-ten Kriteriums. So soll neu das Kriterium des Nachweises eines definierten Stan-dard-Softwareentwicklungsprozesses eingeführt werden, wobei zur Beurteilung be-reits etablierte Modelle wie das CMMI verwendet werden sollen. Ein solches Krite-rium erhöht den Entscheidungsnutzen für den Investor gegenüber dem aktuellen Kriterium hinsichtlich zweier Forderungen, der reliability und der timeliness. Die reliability wird entscheidend durch die intersubjektive Überprüfbarkeit der verwen-deten Nachweismethoden der Modelle gewährleistet. So handelt es sich zum Bei-spiel bei CMMI um ein Modell, bei dem die Voraussetzungen für die Erreichung gewisser Reifegrade genau definiert und durch eine externe Prüfroutine unterlegt sind. Die timeliness ist dadurch gegeben als das Ansatzkriterium des Nachweises eines definierten Standard-Softwareentwicklungsprozesses dem eigentlichen Pro-duktentwicklungsprozess zeitlich vorgelagert ist. Dadurch kann bei Erfüllung der Ansatzkriterien die Aktivierung der Aufwendungen bereits zu Beginn der Produkt-entwicklung und somit zeitnah vorgenommen werden. Die Nachteile dieser Lösung liegen darin, dass die reliability bezüglich eines wahrscheinlichen zukünftigen wirt-schaftlichen Nutzenzuflusses aus dem Produkt nur bedingt gegeben ist. So wird mit diesem Kriterium nur ein definierter Standard-Softwareentwicklungsprozess ge-währleistet, welcher zwar eine unabdingbare, aber keine abschliessende Vorausset-zung für den wirtschaftlichen Nutzenzufluss aus dem Produkt ist.391 Zudem wird der (technische) Erfolg des Standard-Softwareprodukts nur indirekt über den Nach-weis eines definierten Entwicklungsprozesses belegt. Es sind somit nur statistische Aussagen über die technische Erfolgswahrscheinlichkeit von Produkten aus solchen

391 Es ist in diesem Zusammenhang jedoch anzumerken, dass für materielle Werte auch keine spezifischen Kriterien an den Beweis des wahrscheinlichen zukünftigen wirtschaftlichen Nutzenzufluss gestellt wer-den. Ob Standard-Software aus einem definierten Entwicklungsprozess generell eine geringere Erfolgs-wahrscheinlichkeit eines zukünftigen wirtschaftlichen Nutzenzuflusses als materielle Werte aufweist und daher strengerer Ansatzkriterien bedarf, wurde bisher nicht untersucht und ist daher grundsätzlich nicht anzunehmen.

Page 184: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 166

definierten Prozessen möglich. Der technische Erfolg eines spezifischen Standard-Softwareprodukts ist daher nicht absolut gewährleistet. Diese Schwierigkeiten schlagen sich negativ auf die representational faithfulness nieder.

3.4. Fazit

Aus der vorhergehenden Untersuchung kann gefolgert werden, dass der beste Kom-promiss hinsichtlich relevance und reliability durch ein zeitnahes und intersubjektiv überprüfbares Identifikationskriterium erfüllt wird. Das Kriterium des Nachweises eines definierten Standard-Softwareentwicklungsprozesses mit Hilfe des CMMI erfüllt diese Forderung am besten und soll daher vorgeschlagen werden. Da das CMMI eine Bewertung der Qualität des Entwicklungsprozesses vornimmt und da-mit das Ansatzkriterium vor bzw. zu Beginn der Erstellung des immateriellen Wer-tes festsetzt, wird die Forderung der timeliness optimal erfüllt. Aufgrund der dem eigentlichen Erstellungsprozess vorgezogenen Aktivierung bestehen jedoch Risiken hinsichtlich der reliability. Studien zum CMMI zeigen, dass eine Korrelation zwi-schen der gemessenen Qualität des Entwicklungsprozesses und dem (technischen) Erfolg des Produkts besteht. Dennoch können diese Modelle nur statistische Wahr-scheinlichkeiten voraussagen, was zu einer Einschränkung der Verlässlichkeit der Informationen führt.

Die rückwirkende Aktivierung verfolgt den Ansatz, aufgrund der hohen Erfolgsun-sicherheit bei immateriellen Werten die Aktivierungsentscheidung erst am Ende des Produktionsprozesses zu treffen. Während diese Lösung aufgrund des abgeschlos-senen Erstellungsprozess des immateriellen Wertes unbestritten die Forderung der reliability in höchstem Masse erfüllt, ist die relevance (insbesondere die timeliness) nur bedingt gegeben, weil eine Aktivierung zeitlich erst nach den Aufwandsperio-den und damit nach der Erstellung stattfindet. Dieses ex-post Verfahren führt zudem zu einer nachträglichen Aktivierung von bereits verbuchten Aufwendungen, wobei zwangsläufig eine Verletzung bestehender Rechnungslegungsprinzipien resultieren würde. Im Falle einer erfolgsneutralen rückwirkenden Aktivierung würden die Auf-wendungen zweimal in der Erfolgsrechnung verbucht, zuerst als Periodenaufwand und nach der Aktivierung als Abschreibung. Dadurch würde jedoch der Unterneh-mensgewinn systematisch zu tief ausgewiesen. Einzig eine Neudarstellung der ver-gangenen Abschlüsse könnte dies beheben, was jedoch eine grosse Unübersicht-

Page 185: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 167

lichkeit mit sich brächte. Wird hingegen die rückwirkende Aktivierung erfolgswirk-sam verbucht, so wird das Realisationsprinzip verletzt, da ein Erfolgsausweis ohne zugrunde liegenden Ertragsvorgang vorgenommen wird.

Der Vorschlag Vermögenswerte als „in Entstehung“ zu klassifizieren, zielt darauf ab, grundsätzlich alle Aufwendungen in immaterielle Werte in die Bilanz aufzu-nehmen, da sie einen potenziellen Wert besitzen. Während diese Lösung die timeli-ness zweifellos erfüllt, wird der Forderung conservatism nicht entsprochen, da kei-nerlei Überprüfung der zukünftigen „Erfolgsfähigkeit“ der angesetzten Werte statt-findet. Durch die fehlende Differenzierung der immateriellen Werte in Entstehung nach ihrer Erfolgswahrscheinlichkeit wird eine solche Bilanzposition zu einem rei-nen Sammelposten ohne entscheidende Aussagekraft für die Investoren. Ein Ver-gleich mit materiellen Werten in Entstehung, welche ebenfalls keine Ansatzkriterien für die Bilanzierung erfüllen müssen, greift dabei zu kurz, da diese prinzipiell eine höhere Erfolgswahrscheinlichkeit aufweisen. Entsprechend ist die Werthaltigkeit und damit die Aussagekraft einer solchen Bilanzposition nicht gegeben, womit ein Bilanzansatz immaterieller Wert „in Entstehung“ keinen Informationsgewinn für den Investor bedeutet.

4. Immaterielle Werte (ohne Software)

4.1. Einleitung

Wie in Abschnitt IV 2.4 erläutert, basiert der Ansatz der Standardsetter bei der Rechnungslegung von immateriellen Vermögenswerten grundlegend auf der allge-meinen Vermögenswert-Definition (asset definition)392.

Daraus lassen sich drei essenzielle Charakteristika für einen Vermögenswert ablei-ten, der in der Bilanz angesetzt werden kann:393

392 Ein Vermögenswert ist eine Ressource (asset), über die ein Unternehmen aufgrund einer Transaktion oder eines Ereignisses in der Vergangenheit verfügen kann, sofern daraus ein wahrscheinlicher zukünf-tiger Nutzen für das Unternehmen entsteht und dessen Wert mit hinreichender Verlässlichkeit geschätzt werden kann. Vgl. Behr (2002), S. 474.

393 Vgl. Upton (2001), S. 71.

Page 186: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 168

• Zukünftiger wirtschaftlicher Nutzenzufluss, beschrieben als die Fähigkeit, einzeln oder in Kombination mit anderen Vermögenswerten direkt oder indi-rekt zu einem zukünftigen Geldzufluss beizutragen.

• Kontrolle, welche sowohl die Fähigkeit zukünftigen wirtschaftlichen Nutzen zu generieren als auch die Fähigkeit diesen Nutzen anderen zu verweigern beinhaltet.

• Eine Transaktion oder ein Ereignis in der Vergangenheit, welches dem Un-ternehmen Kontrolle über zukünftige Geldzuflüsse gibt.

Während obige Vermögenswert-Definition nützlich für die Identifikation, Erfassung und Bewertung klassischer Vermögenswerte ist, so ergeben sich doch erhebliche Schwierigkeiten bei der Ermittlung (zumindest eines Teils) von immateriellen Wer-ten. Im Folgenden wird erläutert, inwiefern die bestehende Vermögenswert-Definition für die Erfassung immaterieller Werte unzureichend ist:

4.1.1.

Kontrolle / Partieller Ausschluss

Im Hinblick auf die Diskussion der Rechnungslegung von immateriellen Werten spielt insbesondere das Kriterium der Kontrolle eine wichtige Rolle. Nach IAS 38 Immaterielle Vermögenswerte kontrolliert ein Unternehmen einen Vermögenswert, wenn das Unternehmen die Macht hat, sich den zukünftigen ökonomischen Nutzen, der aus einer zugrunde liegenden Ressource zufliesst, zu verschaffen und Dritten den Zugriff auf diesen Nutzen zu verwehren.394 In der Wirtschaftsprüfungsliteratur wurde bisher klar gestellt, dass Kundenzufriedenheit, gut ausgebildete Mitarbeiter und ähnliches dem Kriterium der Kontrolle nicht genügen.395 Es ist zwar unbestrit-ten, dass ein Unternehmen einen wirtschaftlichen Nutzen aus zufriedenen Kunden oder guten Mitarbeitern zieht; aber es kann anderen ein Abwerben von Kunden oder von Mitarbeitern nicht verunmöglichen – womit ein Bilanzansatz solcher Werte unter der klassischen Vermögenswertdefinition der Standardsetter nicht möglich ist. Dennoch sind mit den Kunden oder Mitarbeitern auch Werte verbunden, welche die Vermögenswert-Definition erfüllen. So kann zwar die Kundenzufriedenheit die An-

394 Vgl. IAS 38.13. 395 Vgl. dazu Upton (2001), S. 71.

Page 187: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 169

forderungen des Kontrollkriteriums verfehlen, doch eine Kundenliste tut dies nicht.396

4.1.2.

4.1.3.

Finanzielle Messgrössen

Informationen, welche durch die klassische Rechnungslegung bereitgestellt werden, sind primär finanzieller Natur. Dabei müssen Angaben, welche in die Bilanz, Er-folgsrechnung und Cash Flow-Rechnung einfliessen, grundsätzlich quantifiziert und in monetären Einheiten ausgedrückt werden. Quantifizierte, nicht finanzielle Infor-mationen (wie die Mitarbeiterzahl) und nicht quantifizierte Informationen (wie die Beschreibung von Prozessen) können als Ergänzungen zu den finanziellen Informa-tionen zum Beispiel im Anhang offen gelegt werden.397 Während die Darstellung von finanziellen Informationen durch detaillierte Bestimmungen geregelt ist, fehlen solche zumeist für nicht finanzielle Informationen. Entsprechend unübersichtlich, unvollständig und unstrukturiert stellt sich die Präsentation von nicht finanziellen Informationen in Geschäftsberichten dar. Da ein Grossteil der immateriellen Werte nicht bzw. nicht genügend verlässlich durch finanzielle Messgrössen erfassbar ist, werden diese nicht oder nach dem Gutdünken des bilanzierenden Unternehmens im Anhang offen gelegt.

Interner oder externer Zugang

Ein Ziel der Forderung der Vermögenswert-Definition nach einer Transaktion oder einem Ereignis in der Vergangenheit liegt in der Objektivierung bzw. der intersub-jektiven Überprüfbarkeit der Werthaltigkeit eines Vermögenswertes. So sind durch den Transaktionsvorgang in aller Regel die Bewertungsfähigkeit, die Abgrenzbar-keit und die Möglichkeit der alleinigen Kontrollausübung durch das Unternehmen sichergestellt. Entsprechend sind sowohl materielle als auch immaterielle Werte, die extern durch einen Transaktionsvorgang beschafft wurden, generell zu aktivieren. Intern generierte Werte bedingen hingegen ein Ereignis in der Vergangenheit, um für eine Aktivierung in Frage zu kommen. Bei materiellen Werten stellt der Herstel-

396 Vgl. Upton (2001), S. 72f. 397 Vgl. SFAC 1.18.

Page 188: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 170

lungsvorgang ein solches Ereignis dar.398 Für intern erstellte immaterielle Vermö-genswerte existieren hingegen zusätzliche Aktivierungskriterien, welche dem ver-gleichsweise erhöhten Risiko immaterieller Werte gegenüber materiellen Werten Rechnung tragen.399 Das erhöhte Risiko ist dadurch bedingt, dass immaterielle Wer-te nur bedingt marktfähig und damit vielfach kaum objektiv bewertbar sind. Diese Zusatzbedingungen führen weitestgehend zu einer Behandlung von intern generier-ten immateriellen Werten als Aufwand, was zwar die objektive Nachprüfbarkeit des ausgewiesenen Vermögens sicherstellt, gleichzeitig jedoch einen zu tiefen Auswei-sung des Vermögensbestandes und eine Verfälschung des Erfolgsausweises be-wirkt. Zudem führt dies zu einer Ungleichbehandlung zwischen intern generierten und extern erworbenen immateriellen Vermögenswerten. Denn die Aktivierungsan-forderungen können von extern zugegangenen immateriellen Werten bedeutend leichter erfüllt werden, da sie durch den Transaktionsvorgang einen Marktwert zu-geordnet bekommen.

So repräsentiert zum Beispiel der Markenname Windows von Microsoft unzweifel-haft einen hohen finanziellen Wert. Hätte das Unternehmen den Markennamen durch Kauf erworben, so bestände kein Zweifel daran, dass die Marke als Aktivum in der Bilanz angegeben werden sollte. Doch die Entwicklung des Markennamens wurde durch jahrelange, interne Anstrengungen vorangetrieben. Die fehlende Ab-grenzbarkeit der Aufwendungen für die Markenentwicklung von den allgemeinen Ausgaben für die Unternehmensentwicklung führt daher dazu, dass der Markenwert in der Bilanz nicht ausgewiesen wird.

4.2. Optionen

Der aktuelle quantitativ-monetäre Rechnungslegungsansatz, welcher auf der klassi-schen Vermögenswert-Definition basiert, stellt insbesondere für intern erstellte im-materielle Vermögenswerte hohe Aktivierungshürden auf. Diese scharfen Bedin-gungen sind zwar unter dem Eindruck des Vorsichtsprinzips grundsätzlich durch das erhöhte Risiko von immateriellen Werten gerechtfertigt, führen jedoch wie die Praxisbeispiele zeigten, zu einer mangelhaften Erfassung dieser Werte. Aufgrund

398 Vgl. Dawo (2003), S. 132. 399 Vgl. Dawo (2003), S. 297.

Page 189: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 171

der beschriebenen Unzulänglichkeiten der bestehenden Rechnungslegungsregeln bezüglich der Erfassung intern erstellter immaterieller Werte sollen Alternativen wie angepasste und erweiterte quantitativ-monetäre Ansätze oder Konzepte einer nicht-monetären Berichterstattung vorgestellt und danach auf ihre Tauglichkeit für die investororientierte Berichterstattung geprüft werden. Aufgrund der Vielzahl der zu diesem Thema lancierten Diskussionsbeiträge können im Folgenden nur die wichtigsten Modelle als Vertreter der jeweiligen Strömungen vorgestellt werden. Die zu betrachtenden Modelle können dabei nach folgenden Dimensionen differen-ziert werden: Betrachtung der immateriellen Werte in ihrer Gesamtheit oder nach Einzelwerten und monetäre oder nicht monetäre Erfassung. Folgendes Schema zeigt dies auf:

Einzelbewertungs-Ebene

Gesamtbewertungs-Ebene

Monetäre Bewertung

Nicht monetäre Bewertung

Marktwert-Buchwert Relation

Cash FlowBewertung

SkandiaNavigator

Jenkins Report

Abbildung 24: Kategorisierung der Modelle zur Bemessung von immateriellen Werten

4.2.1. Monetäre Bewertung von immateriellen Werten

4.2.1.1. Marktwert-Buchwert Relation

Als einfache Messverfahren zeichnet sich die Marktwert-Buchwert Relation aus, da sie die immateriellen Werte undifferenziert als Einheit betrachtet. Wie der Name bereits sagt, wird das Verhältnis von Markt- und Buchwert des Eigenkapitals als

Page 190: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 172

Indikator für den Wert der immateriellen Vermögenswerte verwendet. Diese Me-thode weist jedoch reinen Indiziencharakter auf, da die Differenz zwischen Markt- und Buchwert des Eigenkapitals nicht ausschliesslich auf das Vorhandensein imma-terieller Werte zurückzuführen ist. So wird der Marktwert insbesondere bei börsen-kotierten Unternehmen durch eine Vielzahl weiterer Faktoren mitbestimmt und der Buchwert wird durch die angewandten Bilanzierungsvorschriften beeinflusst.

4.2.1.2. Cash Flow Bewertung

Eine angemessene Bewertung von identifizierbaren selbst geschaffenen immateriel-len Werten scheint unter gewissen Bedingungen durchaus möglich zu sein. So um-fasst die Unternehmensbewertung nach der klassischen DCF-Methode400 pauschal auch den Wert der immateriellen Werte, da die Free Cash Flows sämtliche Investi-tionen sowie deren Rückflüsse umfassend berücksichtigen.401 Diese finanztheore-tisch korrekte Sichtweise kann auch der isolierten Bewertung einzelner Aktiven zugrunde gelegt werden. Der finanzielle Wert eines immateriellen Vermögens-gegenstandes liegt nach der DCF-Methode in seinen zukünftigen Free Cash Flow-Potenzialen begründet. Dementsprechend sind den Investitionen in immaterielle Werte in Form von Cash Outflows bei einer konsequenten Nutzenorientierung sämt-liche erwarteten Cash Inflows der Aktiven gegenüberzustellen. Diese werden dann mit einem risikogerechten Diskontierungsfaktor abgezinst. Die Summe dieser Bar-werte bildet den Gegenwartswert der Investitionen und wird in der Bilanz aktiviert. Dieser finanztheoretische Gedanke befindet sich im Einklang mit der asset/liability theory, welche die Ermittlung des Vermögens und der Schulden eines Unterneh-mens als primäre Aufgabe der Rechnungslegung versteht. Entsprechend werden Vermögenswerte als expected future economic benefits definiert.402 Somit sollte einer Bilanzierung von immateriellen Werten nichts im Wege stehen, solange sie sich mittels Cash Flows bewerten lassen.

Diese Methode ist nur dann erfolgreich, wenn der Beweis erbracht werden kann, dass ein Kausalzusammenhang zwischen Cash Outflows und Cash Inflows besteht.

400 Nach der DCF-Methode wird der Unternehmenswert durch Diskontierung der projektierten Free Cash Flows bestimmt.

401 Vgl. Labhart/Volkart (2001a), S. 196. 402 Vgl. Sprouse/Moonitz (1962), S. 20.

Page 191: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 173

So wies das FASB bei der Begründung für eine Verweigerung der Aktivierung von F&E Ausgaben im Rahmen des SFAS 2 Accounting for Research and Development Costs explizit darauf hin, dass Studien „generally failed to find a significant correla-tion between research and development expenditures and increased future benefits as measured by subsequent sales, earnings, or share of industry sales“403. Es wurden deshalb bereits einige Projekte lanciert, um diesen Kausalzusammenhang für im-materielle Werte mit quantitativen Studien nachzuweisen. Einen gewichtigen An-fang haben LEV/SOUGIANNIS für F&E Investitionen gemacht, in dem sie empirisch die Cash Flow Relevanz solcher Investitionen bewiesen.404 Darauf folgten verschie-dene ähnliche Forschungsarbeiten zu weiteren immateriellen Werten. So haben ABOODY/LEV in einer Studie nachgewiesen, dass Unternehmen, welche ihre Soft-wareinvestitionen aktivierten eine höhere Marktkapitalisierung aufwiesen als dieje-nigen Unternehmen, die dies nicht taten.405 BRYNJOLFSSON/YANG haben diesen Beweis für Investitionen in die Informationstechnologie und den immateriellen Werten, welche durch diese begründet werden, geführt.406

4.2.2.

Nicht-monetäre Berichterstattung

Grundsätzlich steht hinter der Idee der nicht-monetären Berichterstattung die Über-legung, dass mit den Mitteln der traditionellen Finanzberichterstattung nicht (mehr) alle Werttreiber eines Unternehmens erfasst werden können. Somit hat die nicht-monetäre Berichterstattung das Ziel, der klassischen, finanziellen Berichterstattung neue Werkzeuge zur Seite zu stellen, welche die bisher nicht erfassten Werte eines Unternehmens anzeigen und somit eine vollständigere Darstellung eines Unterneh-mens erlauben.

Die Entwicklung der nicht-monetären Berichterstattung ist in den 1980er Jahren insbesondere in Skandinavien initiiert und zu Beginn hauptsächlich von privater Seite vorangetrieben worden.407 Zumeist waren die Unternehmen unzufrieden mit der von den Standardsettern vorgegebenen klassischen Finanzberichterstattung,

403 SFAS 2.41. 404 Vgl. Lev/Sougiannis (1996), S. 107-138. 405 Vgl. Aboody/Lev (1998). 406 Vgl. Brynjolfsson/Yang (1999). 407 Vgl. Dawo (2003), S. 328f.

Page 192: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 174

welche es ihnen nur ungenügend ermöglichte, den Investoren Unternehmenswert-steigerungen umfassend zu präsentieren und zu erläutern. Entsprechend suchten sie nach Möglichkeiten, diese Informationen in einem geeigneten Format zu vermitteln. Seit Mitte der 1990er Jahre findet die intensivste Auseinandersetzung mit der erwei-terten (nicht monetären) Berichterstattung in den USA statt, welche ihren Ursprung im Bericht des Special Committee on Financial Reporting des AICPA hat. In die-sem so genannten Jenkins Report wurde die Weiterentwicklung des financial repor-ting zu einem umfassenden business reporting vorgeschlagen.

4.2.2.1. Skandia Navigator

Eines der Pioniere bei der Entwicklung einer nicht monetären Berichterstattung ist das schwedische Finanzdienstleistungsunternehmen Skandia. In einem heute viel beachteten und zitierten Projekt wurde Anfang der 90er Jahre der so genannte Skandia IC-Navigator entwickelt, welcher sowohl für die interne Steuerung als auch für die externe Berichterstattung gedacht ist.408 Neben dem Konzept stiess insbe-sondere die Verwendung des Begriffs intellectual capital (IC) auf grosse Aufmerk-samkeit und diente in den 1990er Jahren als Obergriff für neuere Berichtsansätze.409 Der IC-Navigator fokussiert auf fünf Bereiche (Finanzfokus, Kundenfokus, Pro-zessfokus, Fokus Erneuerung und Entwicklung sowie Humanfokus), welche als we-sentlich für die Wertgenerierung eines Unternehmens betrachtet werden:

408 Vgl. ausführlich Edvinsson/Brünig (2000). 409 Vgl. Dawo (2003), S. 334.

Page 193: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 175

Finanzfokus

Kundenfokus Prozessfokus

Fokus Erneuerung und Entwicklung

Human-fokus

IC

Operatives Umfeld

Morgen

Heute

Gestern

Abbildung 25: IC-Navigator von Skandia410

Durch die Berichterstattung auf Basis des IC-Navigators soll eine systematische und übersichtliche Informationsvermittlung zu den einzelnen „Fokusbereichen“ und ih-ren Indikatoren ermöglicht werden. Diese Strukturierung ist notwendig, weil sich nicht monetäre Indikatoren im Gegensatz zu finanziellen Grössen kaum aggregieren lassen und daher eine sinnvolle Strukturierung zur Erhöhung der Übersichtlichkeit sinnvoll ist. Im Folgenden werden die einzelnen Fokusbereiche und ihre Aufgaben dargestellt:

• Finanzieller Fokus: Die Finanzen werden im IC-Navigator als Rückmelde-system zur Messung der Effizienz des jeweiligen Fokus betrachtet. Denn IC muss sich letztlich wieder in finanzielle Ergebnis- und Wertsteigerungen um-setzen lassen.411 Entsprechend lässt sich die finanzielle Analyse nicht vom IC trennen. Es sollen daher finanzielle Daten vermittelt werden, die die Wert-schaffung durch IC abbilden.

• Kundenfokus: Die Qualität der Kundenbeziehung ist von entscheidender Be-deutung für ein Unternehmen. In den letzten Jahren haben sich durch neuar-tige Dienstleistungen und Produkte die Kundentypen und -beziehungen je-doch verändert. Nach Auffassung von Skandia sind in vielen Bereichen die Märkte kundengetrieben geworden, was eine starke Kundenorientierung bei

410 Edvinsson/Brünig (2000), S. 58. 411 Vgl. Edvinsson/Brünig (2000), S. 64.

Page 194: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 176

der Leistungserstellung erzwingt.412 Aus diesem Grund sind Informationen zum Kundenstamm wie dessen Zusammensetzung, Bindung und Zufrieden-heit von hoher Bedeutung für den Unternehmenserfolg.

• Prozessfokus: Diese Perspektive konzentriert sich auf die optimale und effi-ziente Ausrichtung der gesamten Wertschöpfung eines Unternehmens auf die Kundenbedürfnisse. Dabei werden neue Technologien als Schlüsselwerkzeug zur Erfüllung dieser Ansprüche gesehen.413 Aufgrund der Erfolgsrisiken beim Einsatz neuer Technologien muss deren Effizienz jedoch mit Kenn-zahlen gemessen und damit ihr Wertbeitrag sichtbar gemacht werden. Da-durch kann die Effizienz der internen Prozesse laufend überwacht und ver-bessert werden.

• Fokus Erneuerung und Entwicklung: Die Perspektive Erneuerung und Ent-wicklung konzentriert sich auf die Zukunftsfähigkeit des Unternehmens. Durch die Messung bestimmter Faktoren wie der Veränderung der Kunden-ansprüche, der Attraktivität von Märkten oder der Entwicklungsrate von Neuprodukten können wertvolle Informationen hinsichtlich zukünftiger Er-folgspotenziale des Unternehmens gewonnen werden.

• Humanfokus: Der Faktor Humankapital steht mit allen anderen Dimensionen in enger Beziehung und befindet sich deshalb im Mittelpunkt des IC-Navigators. Nach Auffassung von Skandia ist Erfolg in diesem Bereich Vor-aussetzung für den Erfolg der anderen Perspektiven. Die Humanfaktoren sind jedoch am schwierigsten zu messen, weil insbesondere die Fähigkeiten und Qualitäten der Mitarbeiter nicht einfach zu erfassen sind.414

Auf Basis des beschriebenen IC-Navigators wird ein Set von Indikatoren abgeleitet, welches die Entwicklung in den einzelnen Bereichen transparent macht. Dabei um-fasst der IC-Navigator in seiner ursprünglichen Form insgesamt 91 Kennzahlen aus den Dimensionen Finanzen, Kunden, Prozesse, Erneuerung und Entwicklung sowie Humankapital, um die gesamte Werteentwicklung eines Unternehmens abzubilden

412 Vgl. Edvinsson/Brünig (2000), S. 75ff. 413 Vgl. Edvinsson/Brünig (2000), S. 84. 414 Vgl. Edvinsson/Brünig (2000), S. 101f.

Page 195: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 177

und somit das vorhandene immaterielle Kapital zu erfassen. Dabei wird auch deren Bewertung mit einbezogen.415

4.2.2.2. Jenkins Report

Nicht zuletzt als Reaktion auf die durch den Skandia IC-Navigator angestossenen Aktivitäten von Unternehmensseite wurde vom AICPA 1994 ein Komitee unter der Leitung von Edmund L. Jenkins ins Leben gerufen, welches sich eingehend mit der Verbesserung der finanziellen Berichterstattung befasste. In Zusammenarbeit mit dem FASB und dem SEC sowie Verfassern und Anspruchsgruppen der Berichter-stattung wurden die Bedürfnisse evaluiert und Verbesserungsvorschläge im Jenkins Report von 1994 vorgestellt. Zentrales Element des Reports ist dabei die Forderung, ein aus zehn Elementen bestehendes model of business reporting zu verwenden:416

Financial and non-financial data • Financial statements and related disclosures

• High-level operating data and performance measurements that management uses to manage the business

Management’s analysis of the financial and non-financial data

• Reasons for changes in the financial, operating, and performance-related data and the identity and past effect of key trends

Forward-looking information • Opportunities and risks, including those resulting from key trends

• Management’s plans, including critical success factors

• Comparison of actual business performance to previously disclosed opportunities, risks, and management’s plan

Information about management and shareholders

• Directors, management, compensation, major shareholders, and transactions and relationships among related parties

Background about the company • Broad objectives and strategies • Scope and description of business and

properties • Impact of industry structure on the company

Abbildung 26: Model of business reporting (Jenkins)

415 Vgl. Edvinsson/Brünig (2000), S. 119. 416 Vgl. AICPA (1994).

Page 196: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 178

Der Umfang der Vorschläge und Erläuterungen des Jenkins Report bezüglich dieser zehn Komponenten ist jedoch sehr unterschiedlich. Während die Funktion der fi-nanziellen Rechnungslegung vergleichsweise detailliert erläutert wird, fällt die Dis-kussion zu den non-financial data eher bescheiden aus. Dies ist insofern als negativ zu betrachten als dadurch der bereits vorhandenen Tendenz zur Informationsflut im Bereich nicht-finanzieller Daten weiteren Vorschub geleistet wird. Das Fehlen de-taillierter Vorschläge zu diesem Bereich lässt sich jedoch weitestgehend auf die mehrheitlich negativen Stellungnahmen der Unternehmen zu Regelungen im Be-reich nicht-finanzieller Daten zurückführen. Die Kritik bezieht sich dabei vor allem auf den hohen Aufwand zur Erfüllung der Regelungen, aber auch auf die Kosten zu Bereitstellung zusätzlicher Informationen, rechtliche Risiken und mögliche Einbli-cke für Wettbewerber.

4.3. Entscheidungsnutzenanalyse

Die Entscheidungsnutzenanalyse soll prüfen, ob die im letzten Unterkapitel vorge-stellten Alternativen dem externen Investor tatsächlich eine Verbesserung seiner Entscheidungsgrundlage gegenüber dem aktuellen Stand ermöglichen.

Die Marktwert-Buchwert Relation findet ihren sinnvollen Einsatz hauptsächlich als simples Analyseinstrument für den Investor. Sie dient dabei als erster Indikator zur Abschätzung des Wertes immaterieller Güter im Rahmen der externen Analyse. Aufgrund der pauschalen Gesamtbetrachtung der immateriellen Werte eignet sich das Modell jedoch nicht als Berichterstattungsinstrument für die Rechnungslegung. So wird zum einen das Prinzip der Einzelwertdarstellung verletzt und damit die Forderung der materiality nicht erfüllt. Zum anderen können die Resultate des gro-ben Schätzverfahrens dem allgemeinen Anspruch der reliability nicht standhalten.

Die monetäre Bewertung von immateriellen Werten aufgrund eines Cash Flow Mo-dells führt insofern zu einer Verbesserung des Entscheidungsnutzens als es von sei-ner Konzeption her auf eine konsistente Behandlung von immateriellen Werten ausgelegt ist und somit die Forderung nach der comparability/consistency erfüllen kann. Die Erfassung und Gleichbehandlung von intern generierten wie derivativ erworbenen immateriellen Werten ist durch das Cash Flow Modell gewährleistet. Es merzt damit eine wichtige Schwäche des heutigen vermögenswertbasierten Modells

Page 197: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 179

aus. Das Modell steht und fällt jedoch mit der Fähigkeit des Beweises eines Kausal-zusammenhangs zwischen dem Cash Outflow und einem entsprechendem Cash Inflow. Problematisch sind in diesem Zusammenhang vor allem zwei Aspekte: Ers-tens muss gewährleistet sein, dass eine klare Identifikation und Zuordnung sowohl der Cash Inflows als auch der Cash Outflows zum jeweiligen immateriellen Wert verbürgt ist. Dies ist jedoch insofern mit Schwierigkeiten verbunden als gewisse immaterielle Werte kaum identifizierbar bzw. separierbar sind. So ist zum Beispiel unklar, welche Zahlungsabflüsse bzw. -zuflüsse für das Markenimage oder die Kun-denzufriedenheit verbucht werden sollen. Zweitens muss der Kausalzusammenhang zwischen Cash Inflow und Cash Outflow bewiesen werden können. Obwohl bereits einige Forschungsarbeiten publiziert worden sind, wurde der Beweis bei weitem noch nicht bei allen potenziellen immateriellen Werten geführt. Zudem wird diesen Beweisführungen durchaus auch kritisch begegnet. Da äusserst komplexe quantita-tive Methoden verwendet werden müssen, die vielfach durch verschiedenste Kor-rekturberechnungen beeinflusst sind, können die Resultate nicht einfach unbesehen übernommen werden. Hinzu kommen die typischen Problembereiche der klassi-schen Discounted Cash Flow Methode wie die Bestimmung eines sinnvollen Dis-kontierungssatzes, die Notwendigkeit der monetären Bezifferbarkeit der Zu- und Abflüsse oder der Erfassung von Wahrscheinlichkeiten417. Diese Faktoren führen dazu, dass die representational faithfulness, das heisst eine möglichst grosse inhalt-liche Übereinstimmung von Realität und Abbildung nicht unbedingt gegeben ist. Zudem ist die Erfüllung der completeness nur dann möglich, wenn für alle immate-riellen Werte der Kausalzusammenhang von Cash Inflow und Cash Outflow bewie-sen werden kann und somit eine Bilanzierung möglich ist.

Diese Effekte fliessen negativ in die reliability-Bewertung ein. Somit kann verein-facht festgestellt werden, dass aus Sicht des Investors durch die monetäre Bewer-tung von immateriellen Werten mittels eines Cash Flow Modells eine Verbesserung der relevance erfolgt, welche jedoch zumindest teilweise mit einer Verschlechte-rung der reliability erkauft wird.

417 Investitionen in immaterielle Werte weisen gegenüber materiellen Werten ein viel höheres Risiko eines Totalverlusts bzw. eine breitere Streuung der Cash Inflows aus. Die Wahrscheinlichkeitsverteilung ist somit viel breiter und muss entsprechend in den Kalkulationen berücksichtigt werden.

Page 198: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 180

Die nicht monetäre Berichterstattung geht vom Paradigma aus, dass eine monetäre Erfassung aller immateriellen Werte per se nicht möglich sei. Sie widerspricht da-mit der Cash Flow These, die für die einzelnen immateriellen Werte ein entspre-chendes Cash Flow Modell bereithält. Insbesondere die ungenügende Abgrenzung der einzelnen Werte erlaubt es nicht, den Vermögensgegenständen eindeutige mo-netäre Werte zuzuordnen. Aus diesem Grunde wird versucht mit einer ergänzenden Berichterstattung diese immateriellen Werte trotzdem sichtbar und auf eine gewisse Art und Weise vergleichbar zu machen.

Da die nicht monetäre Berichterstattung nicht finanzielle Werte verwendet, ist die comparability der Abschlüsse im Interunternehmensvergleich nur bedingt gewähr-leistet. Während finanzielle Werte wie Umsatz einfach zu definieren und dazu aner-kannte Berechnungsmethoden vorhanden sind, sind immaterielle Werte wie Kun-denzufriedenheit nicht eindeutig zu bestimmen und vor allem sind keine allgemei-nen Bewertungsverfahren etabliert. Entsprechend zeichnen sich heutzutage freiwil-lig vorgenommene nicht monetäre Informationen von Unternehmen durch eine grosse Heterogenität und Komplexität aus. Da jedes Unternehmen seine eigenen Verfahren verwendet, müssen diese dem Interessenten umständlich erklärt und er-läutert werden. Nicht zuletzt sind die Anforderungen der materiality sehr bedeu-tend, welche grundsätzlich fordert, dass die bereitgestellten Informationen den ex-ternen Investoren einen Nutzen für ihre wirtschaftlichen Entscheidungen bringen sollen. Entsprechend müssen die zusätzlichen Informationen mit den monetären Daten konsistent sein und diese erläutern. Angaben, welche keine Anknüpfungs-punkte zu den finanziellen Daten aufweisen, können kaum eine nützliche Funktion für den Investor ausüben.

4.4. Fazit

Es kann festgestellt werden, dass die in diesem Kapitel für immaterielle Werte be-trachteten Optionen aus der entscheidungsnutzenorientierten Investorensicht durch-aus Alternativ- bzw. Ergänzungscharakter gegenüber der klassischen finanziellen Berichterstattung besitzen. Die typischen Probleme der herkömmlichen Rechnungs-legung finden sich zusammengefasst in der fehlenden Anerkennung nicht monetär-quantitativ erfassbarer Werte, der unzureichenden Erfassung selbst generierter im-

Page 199: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 181

materieller Werte und die daraus folgende Ungleichbehandlung intern erstellter ge-genüber extern zugegangener Werte.

Das Konzept des Cash Flow Modells für die Wertbestimmung von immateriellen Werten ist im Prinzip eine bestechende Lösung. Zum einen nimmt dieses Modell die Bemessung immaterieller Werte auf monetärer Basis vor, was seine problemlose Integration in die bestehende, klassische Rechnungslegungsform ermöglicht. Zum anderen überwindet das Modell die bilanzielle Ungleichbehandlung von derivativ erworbenen und selbst erstellten immateriellen Werten, indem beide nach dem An-satz des Cash Outflows und Cash Inflows bemessen werden. Dadurch wird die An-forderung der comparability/consistency entscheidend verbessert. Die grössten Nachteile sind in der praktischen Umsetzung des Ansatzes zu finden. So muss eine plausible Zuteilung der Cash Flows auf die einzelnen immateriellen Werte vorge-nommen werden. Die dazu erfolgten empirischen Studien weisen zurzeit eher Indi-ziencharakter auf und sind erst für wenige immaterielle Werte vorgenommen wor-den. Eine Ansatzpflicht von immateriellen Werten nach dem Cash Flow-Modell kann daher nach heutigem Kenntnisstand nicht gefordert werden. Die durchgeführ-ten Interviews haben jedoch gezeigt, dass in der Praxis durchaus Interesse an die-sem Modell besteht. Es ist deshalb zu empfehlen, den Unternehmen im Sinne einer zusätzlichen Informationsquelle zumindest die Möglichkeit einzuräumen, im An-hang solche Cash Flow-Angaben für einzelne immaterielle Werte offen zu legen.

Eine standardisierte erweiterte Berichterstattung auf Basis von nicht monetären Be-wertungsmodellen scheint hingegen auf Akzeptanzprobleme zu stossen. Es zeigt sich weder von Seiten der bilanzierenden Unternehmen eine Entwicklung hin zu einem allgemein akzeptierten Modell, noch ist zurzeit eine Tätigkeit der Standard-setter in diesem Gebiet ersichtlich. Dies ist darauf zurückzuführen, dass die Ansprü-che an eine solche Berichterstattung je nach Unternehmen bzw. Industrie höchst unterschiedlich ausfallen. Zudem fürchten viele Unternehmen, dass der Aufwand für eine erweiterte Berichterstattung den resultierenden Nutzen bei weitem überstei-gen würde.

Page 200: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 182

5. Zukunftsbezogene Berichterstattung

5.1. Einleitung

Obwohl sowohl nach IFRS als auch nach US-GAAP die Schaffung einer Basis für die Vorhersage zukünftiger Entwicklungen eines der grundlegenden Ziele der Be-richterstattung ist, finden sich bisher kaum konkrete Ausgestaltungen in den Stan-dards. Insbesondere die derzeitige Entwicklung in den USA hin zu einer vermehrten Haftbarkeit des Managements bei falscher Berichterstattung hat zudem dazu ge-führt, dass auch freiwillige Informationen des Managements zur zukünftigen Ent-wicklungseinschätzung aus Angst vor möglichen rechtlichen Konsequenzen ver-stärkt aus der Berichterstattung herausgenommen werden bzw. ihre Aussagekraft abgeschwächt wird. Diese Informationen werden somit vermehrt auf „inoffiziellem“ Wege im persönlichen Kontakt mit einzelnen Analysten weitergegeben, was aus Sicht der investororientierten Rechnungslegung nicht erstrebenswert ist.

5.2. Optionen

5.2.1.

Generelle Vorschriften

Eine Möglichkeit dem heutigen Trend zur Reduzierung der Offenlegung von Mana-gementinformationen in der Berichterstattung entgegenzuwirken, liegt darin, gene-relle Vorgaben zur Publikation von zukunftsbezogenen Informationen zu erlassen. In Kombination mit einer Beschränkung der rechtlichen Konsequenzen für das Un-ternehmen bei Nichterfüllung dieser Zukunftsdaten könnte dies eine stimulierende Wirkung haben. In den USA wurde diese Idee bereits 1995 mit dem Private Securi-ties Litigation Reform Act (PSLRA) teilweise aufgegriffen. Dabei sollte durch einen weitgehenden rechtlichen Schutz (safe harbor) auf freiwilliger Basis eine umfang-reiche zukunftsorientierte Berichterstattung ermöglicht werden.418 Im Jahre 2001 wurden von der SEC die Auswirkungen dieser Vorschrift untersucht und als Zwi-schenergebnisse publiziert. Dabei wurde konstatiert, dass die Mehrzahl der Unter-nehmen von dieser (freiwilligen) Möglichkeit in begrenztem Umfang Gebrauch

418 Vgl. Andrews/Simonetti (1996), S. 53ff.

Page 201: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 183

machten und nicht signifikant mehr zukunftsorientierte Informationen publizierten als zuvor. 419

Alternativ lässt sich mit Hilfe von obligatorischen Vorschriften eine verstärkte Of-fenlegung zukunftsbezogener Informationen erreichen. Diese Forderung wird am besten durch die Einführung eines neuen Teils in der Berichterstattung erfüllt, der unter dem Titel wie „Einschätzungen des Managements“ oder „Zukunfts-perspektiven des Unternehmens“ eingefügt werden soll. Dabei ist eine Kategorisie-rung in Bereiche wie „Markttrends“, „Wettbewerb“, „Innovation“, „Prozessent-wicklung“ und „Umweltrisiken“ vorzuschlagen, um eine einheitliche Strukturierung der Informationen zu erreichen. Die Aussagen in diesem Teil sollen dabei vor recht-lichen Ansprüchen geschützt werden, um die Unternehmen zu einer möglichst of-fensiven Informationspraxis zu ermuntern. Bei einer zu weit gehenden Reglemen-tierung besteht jedoch die Gefahr einer „Alibiübung“. Durch den unerwünschten Zwang zur Informationsoffenlegung können Unternehmen dazu gebracht werden, den Pflichten mit der Publikation von belanglosen Allgemeininformationen nachzu-kommen, welche dem Investor keinen zusätzlichen Erkenntnisnutzen bringen, son-dern ihn nur mit einer Informationsflut überlasten. Dieser Problematik lässt sich am ehesten mit gezielten und detaillierten Offenlegungsvorschriften im Sinne von bran-chenspezifischen Sonderregelungen begegnen, welche auf die Industrieeigenheiten Rücksicht nehmen und die Informationserfordernisse konkret benennen.

5.2.2.

Branchenspezifische Sonderregelungen

Die Nachteile einer generell formulierten Offenlegungspflicht für zukunftsbezogene Informationen bestehen darin, dass keine detaillierten Anforderungen gestellt wer-den können und daher Umfang und Qualität der Informationen weitgehend der Ein-schätzung des publizierenden Unternehmens überlassen ist. Der Vorteil von bran-chenspezifischen Regelungen ist daher, dass besser und detaillierter auf die Eigen-heiten der Branche und die entsprechenden Informationsbedürfnisse bezüglich zu-kunftsbezogener Daten eingegangen werden kann. In Einzelfällen haben dies die Standardsetter bereits erkannt und solche Regelungen eingeführt. Ein Beispiel einer branchenspezifischen Sonderregelung für Medienunternehmen ist in den US-GAAP

419 Vgl. SEC (1997), S. 2.

Page 202: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 184

zu finden. So ist für selbst produzierte Filme anzugeben, welcher Anteil der hierfür aktivierten Aufwendungen innerhalb der nächsten drei Jahre aufgrund erhaltener Lizenzzahlungen abzuschreiben ist.420 Falls der Anteil unter 80 Prozent des gegen-wärtigen Buchwerts der Lizenzen liegt, so ist anzugeben bis zu welchem Zeitpunkt ein entsprechender Verwertungsstand erwartet wird. Für die Standard-Software-industrie könnten ähnliche, an die Branchensituation angepasste Regelungen durch-aus Sinn machen. Insbesondere der Aussagekraft von branchenspezifischen Be-stimmungen zu Abschreibungen wird dabei noch zu wenig Rechnung getragen. Während Abschreibungen auf materielle Werte relativ einfach aufgrund ihres Wert-verlusts meist durch die einfach zu erfassende Abnutzung zu bestimmen sind, ver-lieren immaterielle Werte durch den einfachen Gebrauch zumeist nicht an Wert.421 Vielmehr ist der Wertverlust bei immateriellen Werten durch zukünftig eintretende externe Faktoren wie Wertminderung aufgrund des technischen Fortschritts oder wegen Nachfrageverschiebungen bestimmt. Eine Koppelung der Abschreibungs-dauer an diese Faktoren würde die Unternehmen daher indirekt zur Publikation von zukunftsbezogenen Informationen bewegen. So könnte eine Flexibilisierung der Abschreibungsdauer für selbsterstellte Standard-Software vorgenommen werden, die auf den vom Unternehmen begründeten zukünftigen Marktaussichten für das Produkt beruht. Diese Verbindung ermöglicht es, vom Management wichtige In-formationen bezüglich der Einschätzung zukünftiger Marktaussichten und damit von diskontinuierlichen technologischen Innovationen zu erhalten.

5.3. Entscheidungsnutzenanalyse

Der Nutzen einer generellen Vorschrift zur Offenlegung zukunftsorientierter Infor-mationen ist für die externe Analyse unbestritten, da der predictive value verbessert wird. Der Kern des Problems liegt jedoch in der ungenügenden Fähigkeit der Stan-dardsetter, Unternehmen allgemein zur Publikation aussagekräftiger Informationen zu verpflichten. Diese Problematik wird derzeit durch die Anstrengungen verschie-dener Aufsichtsbehörden zur verstärkten Haftbarkeit von Unternehmensexponenten

420 Vgl. SOP 00-2.53. 421 Diesem Umstand trägt im Englischen die Verwendung von unterschiedlichen Begriffen Rechnung:

Depreciation für Abschreibungen auf materielle Werte und amortization für Abschreibungen auf imma-terielle Werte.

Page 203: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 185

im Zusammenhang mit fehlerhaften Berichterstattungen verschärft. Durch diese Voraussetzungen besteht die Gefahr der Überflutung des Investors mit irrelevanten Informationen, die die Forderung der materiality nicht erfüllen. Mit Grundsatzrege-lungen können daher aussagekräftige, zukunftsgerichtete Informationen nur auf weitgehend unerzwungener Basis und mit einer Freistellung von rechtlichen An-sprüchen von den Unternehmen eingefordert werden.

Aus Investorensicht stellen branchenspezifische Sonderregelungen einen interessan-ten Ansatz für eine Verbesserung zukunftsgerichteter Berichterstattung dar. Auf-grund der detaillierten und konkreten Vorschriften ist die materiality der gelieferten Informationen weitgehend gewährleistet. Die Schwierigkeit besteht jedoch darin, Vorschriften zu entwickeln, welche dem Investor auch wirklich entscheidungsrele-vante zukunftsgerichtete Informationen zuführen, die insbesondere die representa-tional faithfulness erfüllen. Eine Möglichkeit einer solchen entscheidungsnützlichen Vorschrift ist der Vorschlag, die Abschreibungsdauer für selbst erstellte Standard-Software von den begründeten zukünftigen Marktaussichten für das Produkt abhän-gig zu machen. Zum ersten erhält der Investor durch die eindeutige Regelung eine klare und handfeste Information bezüglich der Abschreibungspraxis des Unterneh-mens. Zum zweiten ist die Abschreibungsdauer mit einer Markteinschätzung zu begründen, wodurch der Investor relevante zukunftsbezogene Informationen erhält.

5.4. Fazit

Die Dissertation schlägt für die Verbesserung der zukunftsgerichteten Berichter-stattung von Standard-Softwareunternehmen zwei Ansätze vor. Zum einen sollen generelle Bestimmungen eingeführt werden, welche gewährleisten, dass die Be-richterstattung durch zukunftsbezogene Aspekte erweitert wird. Diese Forderung wird am besten durch die Einführung eines neuen Teils in der Berichterstattung er-füllt, welcher verschiedene Unterkategorien umfasst, um eine einheitliche Struktu-rierung der Informationen zu erreichen. Die Aussagen in diesem Teil sollen dabei vor rechtlichen Ansprüchen geschützt werden, um die Unternehmen zu einer mög-lichst offensiven Informationspraxis zu ermuntern. Diese Vorschriften stellen je-doch im Vergleich zur heutigen Praxis keine Revolution dar. Durch eine klare Strukturierung und Einordnung von zukunftsorientierten Informationen in der Be-richterstattung soll vielmehr deren Zugänglichkeit und Vergleichbarkeit verbessert

Page 204: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 186

werden. Zudem wird der Stellenwert zukunftsorientierter Informationen in der Rechnungslegung erhöht. Schlussendlich ist die Qualität der Daten durch den Stan-dardsetter jedoch kaum beeinfluss- und überprüfbar. Deshalb sollen zum zweiten detaillierte branchenspezifische Regelungen eingeführt werden. So soll die Ab-schreibungsdauer für selbsterstellte Standard-Software von den begründeten zu-künftigen Marktaussichten für das Produkt abhängig sein. Dabei soll wegen des Vorsichtsprinzips eine maximale Abschreibungsdauer vorgeschrieben sein. Auf-grund der beschränkten Reichweite dieser Regelungen ist die Aussagekraft für das Gesamtunternehmen eingeschränkt, was jedoch durch eine erhöhte Zuverlässigkeit der Daten aufgewogen wird.

5.5. Zusammenfassung: Rechnungslegungskonzept für Standard-Softwareunternehmen

Das Ziel dieses Teils der Dissertation war die Entwicklung eines investororientier-tes Rechnungslegungskonzepts für Standard-Softwareunternehmen. Daher wurden für jedes der als wichtig identifizierten Rechnungslegungsgebiete (Umsatzerfas-sung, Standard-Software, immaterielle Werte, zukunftsbezogene Berichterstattung) Alternativen präsentiert und bezüglich ihrer Entscheidungsnützlichkeit für den In-vestor (Entscheidungsnutzenanalyse) evaluiert. In einem Fazit wurden jeweils die präferierten Vorschläge vorgestellt und ihre Vor- und Nachteile aufgezeigt.

Die wichtigsten Punkte der neuen Ansätze werden in folgender Übersicht als inves-tororientiertes Rechnungslegungskonzept für Standard-Softwareunternehmen noch-mals zusammengefasst:

Page 205: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL V: RECHNUNGSLEGUNGSKONZEPT FÜR STANDARD-SOFTWAREUNTERNEHMEN 187

Investororientiertes Rechnungslegungskonzept für Standardsoftwareunternehmen

Umsatzerfassung

1. Die Umsatzerfassung soll nach dem assets-and-liabilities Ansatz erfolgen.

2. Die Umsatzabgrenzung ist nach dem obligation extinguishment view vorzunehmen.

3. Die Bemessung der ausstehenden Leistungspflichten hat auf dem customer based value (CBV) zu basieren.

4. Die Umsätze sollen in der Erfolgsrechnung nach Herkunft aus pre- und post-performance assets und liabilities aufgeteilt werden und in der Bilanz die Positionen pre-performance assets und liabilities geschaffen werden.

5. Im Anhang sind die verwendeten Bewertungsmethoden und die deren Kalkulationen anzugeben.

(Selbsterstellte) Standard-Software

6. Alle Entwicklungskosten bei selbsterstellter Standard-Software sind bei Erfüllung des Ansatzkriteriums des definierten Entwicklungsprozesses zu aktivieren.

7. Zur Bestimmung des definierten Entwicklungsprozesses ist ein etabliertes Modell wie das CMMI anzuwenden.

Immaterielle Werte (ohne Software)

8. Für immaterielle Werte sollen Cash Flow Bewertungen vorgenommen werden, falls empirisch ein Kausalzusammenhang zwischen dem Cash Outflow und dem resultierenden Cash Inflow aufgezeigt werden kann.

9. Aufgrund des neuartigen Charakters des Lösungsansatzes sind die Angaben freiwillig und nur im Anhang zu tätigen.

Zukunftsbezogene Berichterstattung

10. Einführung eines allgemeinen, vor rechtlichen Ansprüchen geschützten Teils in der Berichterstattung, welche die Einschätzungen des Managements in Kategorien wie „Markttrends“, „Wettbewerb“, „Innovation“, „Prozessentwicklung“ und „Umweltrisiken“ enthält.

11. Detaillierte branchenspezifische Regelungen zur Abschreibungspraxis, welche die Offenlegung der Marktaussichten durch das Management erfordert.

Abbildung 27: Rechnungslegungskonzept für Standard-Softwareunternehmen

Page 206: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 188

Teil VI: Schlussfolgerungen und Ausblick

1. Zusammenfassung der Ergebnisse

Das Ziel dieser Dissertation war es, ein Rahmenkonzept für die Rechnungslegung von Standard-Softwareunternehmen aus der Perspektive der externen Analyse zu entwickeln. In Übereinstimmung mit der Struktur der Dissertation fasst die folgende Abbildung die Hauptergebnisse zusammen:

• Marktmechanismen in der Standard-Softwareindustrie • Charakteristika von Standard-Softwareunternehmen

• In allen vier Bereichen (Umsatzerfassung, Standard-Software, immaterielle Werte, zukunftsbezogene Berichterstattung) sind von US-GAAP oder IFRS entweder keine Standards entwickelt worden oder diese reflektieren ungenügend die Brancheneigen-schaften der Standard-Softwareindustrie

• Gewisse Standard-Softwarespezifische Standards werden in der Praxis ungenügend umgesetzt

Teil II: Analyse der Standard-Softwarebranche

Teil III: Informationsbedürfnisse des Investors

Teil V: Rechnungslegungskonzept für Standard-Softwareunternehmen

Teil IV: Analyse der Rechnungslegung

Limitierte Fähigkeit der bestehenden Rechnungslegung die Informationsbe-

dürfnisse des Investors zu erfüllen

Informationsbedarf desexternen Investors:

Entscheidungsnützliche Informationen

STAND

ARD

PRAXIS

• Anwendung des assets-and-liabilities Ansatzes

• Bewertung von aus-stehenden Leistungsverpflich-tungen zum CBV

• Die allgemeinen Entscheidungsnutzen-bedürfnisse von Investoren wurden in den Gebieten reliability und relevance identifiziert

• Spezielle Bedürfnisse von Investoren bei Standard-Standardsoftwareunternehmen wurden für die Bereiche Umsatzerfassung, Standard-Software, immaterielle Werte und zukunftsbezogene Berichterstattung ermittelt

Umsatz-erfassung

Standard-Software

Immaterielle Werte

Zukunftbezogene Berichterstattung

• Aktivierung von Standard-Software nach dem Ansatzkriterium des definierten Ent-wicklungsprozesses

• Cash Flow Bewertung von immateriellen Werten, bei denen empirisch ein Zusam-menhang von Cash-Inflow und -Outflow nachgewiesen wird

• Nicht-monetäre Berichterstattung für die übrigen immate-riellen Werte

• Allgemeine, rechtlich geschützte Bericht-erstattung

• Branchenspezifische Sonderregelungen für die Standard-Softwareindustrie

Abbildung 28: Zusammenfassung der Hauptergebnisse dieser Dissertation

Page 207: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 189

Das als Ergebnis der Untersuchung vorgeschlagene Rahmenkonzept für die Rech-nungslegung von Standard-Softwareunternehmen würde im Vergleich zu heute sig-nifikante Änderungen in der Berichterstattung bewirken. So würde zum Beispiel die Umsatzerfassung nach einem ganz neuen Ansatz, dem assets-and-liabilities Ansatz erfolgen. Des Weiteren würden die Aktivierungsbedingungen bei selbsterstellter Software neu an den Erstellungsprozess und nicht an das Softwareprodukt selbst gekoppelt. Verschiedenste immaterielle Werte würden über Cash Flow Bewertun-gen zumindest im Anhang aufgeführt werden und zukunftsbezogene Informationen veröffentlicht.

Entsprechend kann das vorgeschlagene Rahmenkonzept nur als ein erster Schritt in die entsprechende Richtung betrachtet werden. Eine Reihe von Schwierigkeiten be-züglich der Anwendung und Umsetzung dieser Vorschläge erfordern eine weitere fachliche Diskussion und erfordern zum Teil auch weitere Forschungsanstrengun-gen.

2. Evaluation und Schlussfolgerungen

In den folgenden Unterkapiteln werden das vorgeschlagene Rahmenkonzept für die Rechnungslegung von Standard-Softwareunternehmen und seine voraussichtlichen Implikationen analysiert. In einem ersten Schritt wird dies aus der Perspektive der Stakeholder getan, in einem zweiten aus der Sicht der Probleme, die mit einer Imp-lementierung verbunden sind. Der letzte Teil dieser Dissertation beinhaltet die Schlussfolgerungen im Sinne eines Ausblicks.

2.1. Evaluation

2.1.1. Evaluation aus Stakeholdersicht

2.1.1.1. Investoren

Die Entwicklung des Rahmenkonzepts zur Rechnungslegung von Standard-Softwareunternehmen hatte zum Ziel, die Informationsbedürfnisse von externen Investoren besser zu erfüllen. Die entwickelten Ansäte sollen daher den Investoren verbesserte Informationsgrundlagen für ihre externen Analysen liefern. Den Aus-

Page 208: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 190

gangspunkt dieser Beurteilung bilden die in Teil III definierten Informationsanfor-derungen der Investoren, welche im Folgenden den Ansätzen der vier für Standard-Softwareunternehmen bedeutenden Rechnungslegungsbereichen gegenübergestellt werden.

Die vorgeschlagene Umsatzerfassung, welche auf dem assets-and-liabilities Ansatz beruht, wird diesen Anforderungen in folgender Hinsicht gerecht:

• Die Fokussierung auf einzelne Leistungspflichten führt zu einem umfangreichen und detaillierten Umsatzausweis. Dadurch stehen dem Investor mehr Informatio-nen zur vertieften Analyse zur Verfügung.

• Der Ansatz ermöglicht den Ersatz der komplexen Bestimmungen zu Mehrkom-ponentenverträgen durch den konzeptionell einfachen und stringenten asset-and-liabilities Ansatzes. Dadurch wird zum einen allgemein die Verständlichkeit der Umsatzerfassung für Investoren erhöht, zum anderen schwindet die Gefahr, dass Unternehmen ihren Umsatzausweis den Sonderregelungen angepasst „gestalten“.

Die Verwendung des neuartigen Aktivierungskriteriums des definierten Entwick-lungsprozesses bei selbst entwickelter Standard-Software weist folgende Vorteile gegenüber dem bisherigen Kriterium der technischen Realisierbarkeit auf:

• Die Verwendung eines objektiv überprüfbaren Aktivierungskriteriums führt zu einer einheitlichen Kapitalisierungspraxis von selbsterstellter Software bei Standard-Softwareunternehmen. Die Bestimmung von definierten Entwick-lungsprozessen mittels etablierter Modelle wie dem CMMI erlaubt dem Inves-tor eine sichere Beurteilung der Qualität des Entwicklungsprozesses. Dem Kri-terium der technischen Realisierbarkeit fehlt diese Objektivierungseigenschaft.

• Das Kriterium des definierten Entwicklungsprozesses erlaubt eine zeitnahe Aktivierung von selbsterstellter Software. Der Kapitalisierungsansatz ist prin-zipiell früher möglich, da das Ansatzkriterium bereits vor der eigentlichen Produktentwicklung greift, womit der Investor wertvolle, da zeitnahe Informa-tionen erhält.

Die Lösungsansätze bezüglich der immateriellen Werte führen zu folgender Verbes-serung für den Investor:

Page 209: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 191

• Die freiwillige Bewertung von immateriellen Werten nach dem Cash Flow-Modell als Anhangangaben ermöglicht es den Unternehmen, Zusatzinformati-onen in Form von finanziellen Kennzahlen zu liefern. Dies ermöglicht es dem Investor grundsätzlich, immaterielle Werte unkompliziert in bestehende finan-zielle Bewertungsmodelle einzubinden. Eine gewichtige Beeinträchtigung be-steht in der (noch) mangelnden Verlässlichkeit der Informationen aufgrund fehlender empirischer Erfahrungen.

• Die nicht monetäre Berichterstattung ausserhalb der klassischen Rechnungsle-gung dient dem Investor als wertvolle Informationsbasis bei immateriellen Werten, die nicht finanziell erfasst werden können.

Die Regelungsvorschläge zur zukunftsbezogenen Berichterstattung führen zu fol-gendem Nutzen:

• Durch den rechtlichen Schutz für das Management erhalten Unternehmen An-reize, Informationen in offener und transparenter Art und Weise an die gesam-te Investorengemeinschaft weiterzugeben.

• Durch spezifische Detailregelungen für die Standard-Softwarebranche erhält der Investor verstärkte Hinweise zu besonders kritischen Erfolgsfaktoren. So ist die Verknüpfung der Abschreibungsdauer von Software mit vom Manage-ment geschätzten, zukünftigen Marktaussichten eine Möglichkeit, dem Inves-tor indirekt Informationen zu den Einschätzungen des Managements zukom-men zu lassen.

Alle diese Verbesserungen können jedoch nur greifen, wenn die Investoren die neu-artigen Darstellungsformen und die veränderte Bedeutung von einzelnen Rech-nungslegungspositionen verstehen. Entsprechend sind die Unternehmen gefordert, diese Neuerungen in der Berichterstattung aktiv zu kommunizieren und ihre Vortei-le für die Investoren zu erläutern.

2.1.1.2. Standard-Softwareunternehmen

Die Implementierung der Vorschläge stellt für die Standard-Softwareunternehmen eine grosse Herausforderung dar. So müssen die Unternehmen ihre Rechnungsle-gungspraxis zum Teil erheblich anpassen, was mit grossem Aufwand verbunden ist:

Page 210: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 192

Im Rahmen der Umsatzerfassung führt die Einführung des neuen assets-and-liabilities Ansatzes zu einer weit reichenden Umstellung der etablierten Praxis. Da-bei verlangen insbesondere die Mehrkomponentenverträge und der CBV die Etab-lierung neuer Anwendungsgrundsätze.

Bei der Aktivierung selbst entwickelter Standard-Software verlangt das neue An-satzkriterium einen umfangreichen Nachweis der Beherrschung des Softwareent-wicklungsprozesses. Für die meisten Unternehmen ist das Erbringen eines solchen Nachweises, insbesondere bei Verwendung einer externen Zertifizierungslösung mit hohen Kosten und internen Prozessanpassungen verbunden.

Die vorgeschlagene Berichterstattung für immaterielle Werte stellt für Standard-Softwareunternehmen den wohl grössten Aufwand dar. So erfordert das Cash Flow Modell das Vorhandensein von detaillierten Berechnungsgrundlagen und ausführli-chen Erläuterungen, um die kalkulierten Cash Flows gegenüber dem Investor plau-sibel nachweisen zu können.

2.1.1.3. Externe Wirtschaftsprüfer

Die wichtigste Herausforderung für die Wirtschaftsprüfer liegt in der Evaluation und der Verifikation der verwendeten Annahmen und Techniken, welche die Stan-dard-Softwareunternehmen benutzen, um zum Beispiel den CBV, die korrekte Ab-schreibungsdauer von Standard-Software oder die Cash Flow Kalkulationen der immateriellen Werte zu bestimmen. Dies führt zu neuen Ansprüchen an das Know-how von Wirtschaftsprüfern.

2.1.1.4. Standardsetter

Die Standardsetter sind gehalten, die zum Teil radikalen Vorschläge in konkrete Standards umzusetzen. Diese sind so auszugestalten, dass eine möglichst breite Ak-zeptanz bei allen Beteiligten erreicht wird. Nur so ist gewährleistet, dass die Ziel-setzungen dieser Vorschläge auch in der Praxis erreicht werden. Als letztes muss ein optimaler Weg für die Einführung dieser Bestimmungen gefunden werden. Dies kann über eine Übergangsperiode geschehen, in der die Standard-Softwareunter-nehmen die Informationen sowohl nach alten als auch nach neuen Standards bereit gestellt müssen, indem sie die eine Variante im Anhang offen legen. Dadurch kön-

Page 211: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 193

nen sich die Anspruchsgruppen langsam an die neuen Rechnungslegungsprinzipien gewöhnen.

2.1.2.

Evaluation aus Implementierungssicht

Das vorgeschlagene Rechnungslegungskonzept für Standard-Softwareunternehmen wird in einigen Bereichen zu signifikanten Änderungen in der Darstellung und dem Ausweis der bestehenden Rechnungslegung führen. Dabei sind in allen Bereichen Widerstände und Kritikpunkte zu identifizieren, welche es zu lösen und argumenta-tiv zu begegnen gilt:422

Im Bereich der Umsatzerfassung beziehen sich die Kritikpunkte auf die möglichen Auswirkungen des assets-and-libilities Ansatzes und der Bewertung nach dem CBV. Die erste Kritik bezieht sich auf die Gefahr, dass Umsätze verfrüht ausgewie-sen werden können, wenn die sich aus einem Vertrag ergebenden Leistungsver-pflichtungen unvollständig abgebildet werden. Diese Missbrauchsgefahr ist nicht vollkommen zu verneinen, sie kann jedoch durch die vorgeschlagenen Offenle-gungspflichten geschmälert werden. So führt der Zwang zum separaten Ausweis von Umsätzen aus schwebenden Geschäften in der Erfolgsrechnung dazu, dass ein ausserordentlicher Anstieg sofort auffällt und auf mögliche Gestaltungsversuche des Managements hinweist. Ein zweiter Kritikpunkt greift die Verlässlichkeit des CBV für Leistungsverpflichtungen an. Aufgrund des fünfstufigen Bewertungsansatzes steht dem Unternehmen eine Art „Auswahlsendung“ zur Verfügung. Dieser Kritik ist grundsätzlich zuzustimmen, wobei sich das Problem jedoch durch die Fülle an Fallsituationen ergibt, die abzudecken ist. So hat sich der ursprünglich verfolgte reine fair value Ansatz insbesondere für Leistungsverpflichtungen in der Standard-Softwarebranche als untauglich erwiesen, weil diesen aufgrund ihres singulären Charakters kaum Marktpreise zugeordnet werden können. Daher ist der komplexe CBV dem nur scheinbar exakten fair value Ansatz vorzuziehen, da zumindest die verwendeten Berechnungsgrundlagen besser offen gelegt werden und damit nach-vollziehbar sind. Dennoch sind nicht zuletzt die externen Wirtschaftsprüfer gefor-

422 Die folgende Auflistung diskutiert wichtige Einwände, die im Rahmen einer Fachdiskussion zu erwar-ten sind bzw. von Interviewpartnern angesprochen wurden.

Page 212: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 194

dert eine möglichst einheitliche Beurteilungspraxis für die Verwendung des CBV zu schaffen.

Bei der Verwendung des neuartigen Aktivierungskriteriums des definierten Ent-wicklungsprozesses bei selbst entwickelter Standard-Software stehen folgende Kri-tiken im Raum: Erstens besteht die Gefahr einer verfrühten Aktivierung von Stan-dard-Software aufgrund des Einsatzes eines Ansatzkriteriums, welches auf die Pro-zessqualität und damit auf den der eigentlichen Produktentwicklung vorgelagerten Bereich fokussiert. In der Tat besteht in diesem Bereich Missbrauchspotenzial, wel-ches jedoch aufgrund der folgenden Umstände begrenzt ist: Durch die Verwendung eines etablierten Modells wie dem CMMI wird sichergestellt, dass die entscheiden-den Erfolgsfaktoren für die Produktentwicklung bereits im Prozessmodell identifi-ziert und überprüft werden. Die damit verbundenen Offenlegungspflichten schrän-ken zudem das Gestaltungspotenzial stark ein. Der zweite Kritikpunkt fokussiert auf das Problem, dass – ähnlich zum SFAS 86 – das Aktivierungskriterium in der Pra-xis als zu wenig operabel betrachtet und daher als untauglich abgelehnt werden könnte. Diese Möglichkeit ist wiederum durch den Einsatz des etablierten CMMI-Modells beschränkt. Dieses bietet ein erprobtes Verfahren zur Operationalisierung an und ermöglicht daher eine einheitliche Bewertung der Softwareentwicklungspro-zesse bei Unternehmen.

Der Cash Flow Ansatz im Rahmen der Erfassung von immateriellen Werten ist mit folgender Hauptkritik konfrontiert: Der Kausalzusammenhang von Cash Inflow und Cash Outflow sind beim Cash Flow Ansatz empirisch zu wenig gesichert, um die allgemeinen Qualitätsanforderungen der Rechnungslegung zu erfüllen. Diese Kritik ist ernst zu nehmen und wurde bei der Ausgestaltung des Vorschlages berücksich-tigt. So sind die Berechnungsgrundlagen für die Kalkulationen mitzuteilen und zu erläutern. Ebenso darf der Cash Flow Ansatz nur im Anhang angegeben werden, um damit seine Hilfsfunktion als zusätzliche Informationsquelle mit eingeschränkter Verlässlichkeit zu unterstreichen.

Bei den Regelungsvorschlägen zur zukunftsbezogenen Berichterstattung ist bei der Implementierung zu beachten, dass die geschaffenen rechtlichen Freiräume in der Berichterstattung für zukunftsbezogene Informationen nicht dazu führen, dass diese Plattform von Seiten des Managements ohne Konsequenzen für übertriebene und

Page 213: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 195

unrealistische Zukunftsaussichten genutzt wird. Dieses Risiko wird jedoch zum ei-nen dadurch beschränkt, dass für das Management nicht nur rechtliche Sanktionen eine Rolle spielen, sondern ebenfalls der erlittene Vertrauensverlust bei den Investo-ren, wenn übertriebene oder unrealistische Zukunftsaussichten angestellt wurden.

2.2. Schlussfolgerungen

Das Ziel dieser Dissertation war die Entwicklung eines Rechnungslegungskonzepts für die Berichterstattung von Standard-Softwareunternehmen, welches auf die In-formationsbedürfnisse von externen Investoren fokussiert ist. Dabei zeigten sich in vielen zentralen, da erfolgskritischen Bereichen von Standard-Softwareunternehmen Problembereiche der bestehenden Rechnungslegung: So bei der Umsatzerfassung, der Bilanzierung von Standard-Software, der Berichterstattung von immateriellen Werten und der zukunftsbezogenen Berichterstattung. Da sich die Probleme jedoch in höchst unterschiedlicher Weise darstellen, sind entsprechend verschiedene Lö-sungsansätze zu entwickeln: So lassen sich die Probleme bei der Umsatzerfassung insbesondere auf die komplexe und hohe Regelungsdichte mit gleichwohl auftre-tenden Regelungslücken sowie auf das Fehlen von einfachen, allgemeingültigen Grundprinzipien zurückführen. Entsprechend sind zur Beseitigung dieser funda-mentalen Unzulänglichkeiten kleine Korrekturschritte abzulehnen, da sie zu einer weiteren Zunahme der Komplexität führen. Vielmehr ist auf eine prinzipienorien-tierte Neukonzeption hinzuarbeiten wie sie das IASB und das FASB mit dem as-sets-and-liabilities Ansatz tun. Die Problemstellung bei der Aktivierung von selbst-erstellter Standard-Software stellt sich hingegen so dar, dass die konkreten Ansatz-bestimmungen einer konzeptionell sinnvollen Regelung in der Praxis zu wenig ope-rationalisierbar sind. Entsprechend ist kein umfangreicher konzeptioneller Entwurf notwendig, sondern die Ansatzbestimmungen sind so neu zu formulieren, dass die konzeptionellen Anforderungen in der Alltagspraxis erfüllt werden. Der Vorschlag, das Ansatzkriterium des definierten Entwicklungsprozesses zu verwenden, welches durch ein etabliertes, praxiserprobtes Modell (CMMI) überprüfbar ist, scheint eine Möglichkeit zu sein, diese Praxistauglichkeit herzustellen. Die Bilanzierungsprob-lematik von immateriellen Werten ist wiederum ein seit langem intensiv diskutiertes Thema. Dabei wurden bereits unzählige Modelle entwickelt, wobei sich bisher kei-nes in breiter Form durchgesetzt hat. Entsprechend ist es notwendig, neue konzepti-

Page 214: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

TEIL VI: SCHLUSSFOLGERUNGEN UND AUSBLICK 196

onelle Vorschläge zu formulieren, welche einen Anstoss für weitere Forschungsar-beiten bilden. Mit dem Cash Flow-Modell soll ein monetärer Ansatz zur Diskussion gestellt werden, der interessante Zukunftsperspektiven aufweist, jedoch weiteren Forschungsbedarf erfordert. Der Problembereich der zukunftsorientierten Berichter-stattung ist ein weites Feld und daher gibt es verschiedenste mögliche Herange-hensweisen. In dieser Dissertation wurde versucht, möglichst kleine und einfach umzusetzende Lösungsansätze aufzuzeigen und auf grosse, neuartige Modellkon-zeptionen zu verzichten. Dies im Hinblick darauf, dass komplexe Modelle zumeist auf grossen Umsetzungswiderstand stossen und nicht in jedem Fall eine bessere Lösungsfähigkeit besitzen wie sich zum Beispiel bei den Modellen zu den immate-riellen Werten zeigt.

Wie aufgezeigt, führen die sehr unterschiedlichen Problemstellungen auch zu viel-fältigen Lösungsansätzen. So sind gewisse Vorschläge relativ schnell und einfach umsetzbar, während bei anderen umfangreiche Anpassungen in der Rechnungsle-gung von Nöten sind. Einzelne Lösungen sind bereits weit entwickelt während bei anderen noch weiterer Forschungsbedarf vorhanden ist. Um insgesamt eine erfolg-reiche Verbesserung der Rechnungslegung von Standard-Softwareunternehmen zu erreichen ist es jedoch notwendig, in allen Problembereichen Fortschritte zu erzie-len. Entsprechend sind unabhängig vom Entwicklungsstadium der einzelnen Lösun-gen überall die notwendigen Anstrengungen vorzunehmen. So erfordern einzelne Lösungsvorschläge weitere Forschungsanstrengungen, während bei anderen die Umsetzung in konkrete Rechnungslegungsstandards zu erfolgen hat. Eine Verbesse-rung der investororientierten Rechnungslegung von Standard-Softwareunternehmen ist deshalb dringend notwendig, da die meisten aktuellen Rechnungsproblematiken akzentuiert bei Standard-Softwareunternehmen auftreten und daher eine externe Analyse dieser Unternehmen auf Grundlage der aktuellen Rechnungslegungsstan-dards äusserst schwierig ist.

Page 215: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 1: UNTERSUCHUNG VON GESCHÄFTSBERICHTEN I

Anhang 1: Untersuchung von Geschäftsberichten

Es wurden folgende Unternehmen in die Untersuchung einbezogen, welche unter die Definition423 von Standard-Softwareunternehmen dieser Dissertation fallen und im NASDAQ-100 (Dezember 2005), an der Deutschen Börse und/oder an der SWX gelistet sind:

Unternehmen Standard Börse Untersuchte Quellen

Adobe US-GAAP NASDAQ Form 10-K (2004)

ATOSS US-GAAP Deutsche Börse Geschäftsbericht (2004)

b.i.s US-GAAP Deutsche Börse Geschäftsbericht (2004)

BEA Systems US-GAAP NASDAQ Form 10-K (2004)

BetaSystems Software US-GAAP Deutsche Börse Geschäftsbericht (2004)

Brainpower* US-GAAP Deutsche Börse Geschäftsbericht (2003)

Check Point Software Technologies US-GAAP NASDAQ Form 20-F (2004)

Computer Associates* US-GAAP NASDAQ Form 10-K (2004/2005)**

COR IFRS Deutsche Börse Geschäftsbericht (2004)

Crealogix IFRS SWX Geschäftsbericht (2004/2005)

Day Software* US-GAAP SWX Geschäftsbericht (2004)

DICOM Group IFRS Deutsche Börse Geschäftsbericht (2004)

Easy Software IFRS Deutsche Börse Geschäftsbericht (2004)

Esmertec* IFRS SWX Emissionsprospekt, Fachpresse

Fabasoft IFRS Deutsche Börse Geschäftsbericht (2004)

GROUP Technologies IFRS Deutsche Börse Geschäftsbericht (2004)

Mensch und Maschine Software IFRS Deutsche Börse Geschäftsbericht (2004)

Microsoft* US-GAAP NASDAQ Form 10-K (2004/2005)

Oracle US-GAAP NASDAQ Form 10-K (2004/2005)

Orad Hi-Tec US-GAAP Deutsche Börse Geschäftsbericht (2004)

(Fortsetzung)

423 Vgl. Abschnitt I 3.2.

Page 216: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 1: UNTERSUCHUNG VON GESCHÄFTSBERICHTEN II

Unternehmen Standard Börse Untersuchte Quellen

P&I US-GAAP Deutsche Börse Geschäftsbericht (2004)

Parsytec US-GAAP Deutsche Börse Geschäftsbericht (2004)

PSI US-GAAP Deutsche Börse Geschäftsbericht (2004)

Red Hat US-GAAP NASDAQ Form 10-K (2004)

SAP US-GAAP Deutsche Börse Form 20-F (2004)

Siebel Systems*** US-GAAP NASDAQ Form 10-K (2004)

Sun US-GAAP NASDAQ Form 10-K (2004/2005)

Symantec US-GAAP NASDAQ Form 10-K (2004/2005)

Update US-GAAP Deutsche Börse Geschäftsbericht (2004)

USU Software AG US-GAAP Deutsche Börse Geschäftsbericht (2004)

Utimaco Safeware IFRS Deutsche Börse Geschäftsbericht (2004/2005)

* Vertiefte Analyse von Besonderheiten** Berichtsjahr weicht vom Kalenderjahr ab*** Oracle übernimmt Siebel Systems auf den 1. Juni 2006

Page 217: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE III

Anhang 2: Expertengespräche

2.1. Gesprächsleitfaden Analysten

- HERZLICHEN DANK FÜR IHRE TEILNAHME -

1. Umsatzerfassung

Manipulationsvorwürfe bei der Umsatzerfassung werden seit geraumer Zeit auch gegen Unterneh-men in der Standard-Softwareindustrie (z. B. Miracle, Computer Associates) vorgebracht.

1.1. Halten Sie Mängel in den aktuellen Umsatzstandards von IFRS und US-GAAP für die diver-sen Umsatzmanipulationsfälle mitverantwortlich?

1.2. In einem gemeinsamen Projekt von IASB und FASB wird zurzeit diskutiert, das aktuelle Modell basierend auf dem Realisationsprinzip (realization-and-earnings process approach) durch ein bilanzorientiertes Modell (assets-and-liabilities approach) zu ersetzen. Dabei sol-len ausstehende, rechtlich durchsetzbare Leistungsverpflichtungen bilanziell zum beizule-genden Zeitwert (fair value) oder zum kundenbasierten Wert (customer based value) erfasst werden. Dabei wird der kundenbasierte Wert präferiert, weil Bemessungsschwierigkeiten beim beizulegenden Zeitwert befürchtet werden.

- Teilen Sie die Bedenken der Standardsetter gegenüber dem beizulegenden Zeitwertansatz und ziehen Sie auch den kundenbasierten Wertansatz vor?

- Halten Sie die kundenbasierte Bewertung von ausstehenden Leistungsverpflichtungen für aussagekräftiger als die heutige Abgrenzung von (rein intern geschätzten) Rückstellungs-beträgen?

2. Erfassung von Standard-Software

Die überwiegende Mehrheit der Standard-Softwareunternehmen lehnt eine Bilanzierung von selbst erstellter Standard-Software trotz bestehender Standards von IFRS und US-GAAP ab. Begründet wird diese Entscheidung damit, dass die Ansatzvoraussetzung der technischen Realisierbarkeit der Software bis kurz vor Marktreife nicht erfüllbar sei und deshalb ein Bilanzansatz nicht möglich ist.

2.1. Erwarten Sie eine qualitative Verbesserung für Ihre Analyse durch den Bilanzansatz von Standard-Software? Bitte begründen Sie Ihre Antwort.

2.2. Eine Abänderung der bestehenden Standards könnte zu einer vermehrten Bilanzierung von selbst erstellter Standard-Software führen. Welche der folgenden Alternativen halten Sie für Erfolg versprechend?

a) Identifikation: Selbst erstellte Standard-Software soll sich ähnlich dem heutigen Ansatz der technischen Realisierbarkeit durch Erfüllung bestimmter Bedingungen für den Bilanzan-satz qualifizieren. Als Ansatzkriterium dient zum Beispiel der Nachweis standardisierter Entwicklungsprozesse.

Page 218: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE IV

b) Rückwirkende Aktivierung: Die Ausgaben werden in der Erfolgsrechnung verbucht bis die Ansatzvoraussetzung der technischen Realisierbarkeit oder der Umsatzwirksamkeit erfüllt ist. Ab diesem Zeitpunkt werden rückwirkend die getätigten Ausgaben aktiviert.

c) Vermögenswerte in Entstehung: In Entwicklung stehende Software soll ähnlich wie bestehende Bilanzpositionen Bauten in Arbeit oder Bohrungen in Arbeit als eigene Position „Software in Entwicklung“ behandelt werden.

2.3. Halten Sie die Abschreibungspraxis bei aktivierter Standard-Software für sinnvoll oder zie-hen Sie ein Impairmentverfahren vor?

2.4. Software(-quellcode) ist zwar per Definition ein immaterieller Wert, wird aber ähnlich wie materielle Werte (Projektorganisation) geschaffen. Sind Sie der Meinung, dass Software des-halb ähnlich wie materielle und anders als „klassische“ immaterielle Werte (Kundenlisten, Marken) im Geschäftsbericht behandelt werden soll?

3. Erfassung von Immateriellen Werten

Bei Standard-Softwareunternehmen sind immaterielle Werte wie Kundenlisten oder Marken von hoher Bedeutung für den Unternehmenserfolg. Diese werden trotz zahlreicher Vorstösse heute nur ungenügend und vor allem nicht standardisiert im Geschäftsbericht publiziert. Grundsätzlich sind zwei verschiedene Ansätze denkbar: Eine monetäre Bewertung einzelner immaterieller Werte ba-sierend auf empirischen Modellen, welche das Verhältnis von Cash Inflow in den immateriellen Vermögenswert und den daraus resultierenden Cash Outflow zu messen versuchen oder eine erwei-terte Berichterstattung, welche zusätzliche nicht-monetäre Informationen zu den immateriellen Werten liefert.

3.1. Halten Sie eine monetäre Bewertung von immateriellen Werten anhand von empirischen Cash Flow Modellen für sinnvoll?

3.2. Sprechen Sie sich für eine erweiterte Berichterstattung aus? Soll diese standardisiert erfol-gen?

4. Zukunftsbezogene Berichterstattung

In der Standard-Softwareindustrie führen die diskontinuierlichen technologischen Innovationen und die besonderen Marktmechanismen zu immer wieder stark veränderten Wettbewerbssituationen.

4.1. Sind Sie der Meinung, dass die Offenlegung der Einschätzungen des Managements zur Marktentwicklung und zu Schlüsseltrends hilfreich für die Analyse ist?

4.2. Sollten weitere zukunftsbezogene Informationen offen gelegt werden?

5. Allgemeine Frage

Sind Sie der Meinung, dass diese vier Bereiche die Hauptprobleme der heutigen Rechnungslegung bei Standard-Softwareunternehmen adressieren?

Page 219: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE V

2.2. Gesprächsleitfaden Ersteller/Wirtschaftsprüfer

- HERZLICHEN DANK FÜR IHRE TEILNAHME -

1. Umsatzerfassung

Manipulationsvorwürfe bei der Umsatzerfassung werden seit geraumer Zeit auch gegen Unterneh-men in der Standard-Softwareindustrie (z. B. Miracle, Computer Associates) vorgebracht.

1.1. Halten Sie Mängel in den aktuellen Umsatzstandards von IFRS und US-GAAP für die diver-sen Umsatzmanipulationsfälle mitverantwortlich?

1.2. In einem gemeinsamen Projekt von IASB und FASB wird zurzeit diskutiert, das aktuelle Modell basierend auf dem Realisationsprinzip (realization-and-earnings process approach) durch ein bilanzorientiertes Modell (assets-and-liabilities approach) zu ersetzen. Dabei sol-len ausstehende, rechtlich durchsetzbare Leistungsverpflichtungen bilanziell zum beizule-genden Zeitwert (fair value) oder zum (zur Zeit mehrheitlich präferierten) kundenbasierten Wert (customer based value) erfasst werden.

- Welchen Ansatz würden Sie aus konzeptioneller Sicht vorziehen?

- Welchen Ansatz halten Sie aus Kosten/Nutzen-Überlegungen für vorteilhafter?

- Teilen Sie die Bedenken der Standardsetter, dass eine verlässliche Bemessung des beizule-genden Zeitwerts vielfach nicht möglich ist?

2. Erfassung von Standard-Software

Die überwiegende Mehrheit der Standard-Softwareunternehmen lehnt eine Bilanzierung von selbst erstellter Standard-Software trotz bestehender Standards ab. Begründet wird diese Entscheidung damit, dass die Ansatzvoraussetzung der technischen Realisierbarkeit der Software bis kurz vor Marktreife nicht erfüllbar sei und deshalb ein Bilanzansatz nicht möglich ist.

2.1. Stimmen Sie dieser Argumentation zu?

2.2. Wie beurteilen Sie folgende Alternativen im Hinblick auf ihre Anwendbarkeit?

a) Identifikation: Selbst erstellte Standard-Software soll sich ähnlich dem heutigen Ansatz der technischen Realisierbarkeit durch Erfüllung bestimmter Bedingungen für den Bilanzan-satz qualifizieren. Als Ansatzkriterium dient zum Beispiel der Nachweis standardisierter Entwicklungsprozesse.

b) Rückwirkende Aktivierung: Die Ausgaben werden in der Erfolgsrechnung verbucht bis die Ansatzvoraussetzung der technischen Realisierbarkeit oder der Umsatzwirksamkeit erfüllt ist. Ab diesem Zeitpunkt werden rückwirkend die getätigten Ausgaben aktiviert.

c) Vermögenswerte in Entstehung: In Entwicklung stehende Software soll ähnlich wie bestehende Bilanzpositionen „Bauten in Arbeit“ oder „Bohrungen in Arbeit“ als eigene Posi-tion „Software in Entwicklung“ behandelt werden.

2.3. Halten Sie die Abschreibungspraxis bei aktivierter Standard-Software für sinnvoll oder zie-hen Sie ein Impairmentverfahren vor?

Page 220: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE VI

2.4. Software(-quellcode) ist zwar per Definition ein immaterieller Wert, wird aber ähnlich wie materielle Werte (Projektform) geschaffen. Sind Sie der Meinung, dass Software deshalb ähnlich wie materielle und anders als „klassische“ immaterielle Werte (Kundenlisten, Mar-ken) im Geschäftsbericht behandelt werden soll?

3. Erfassung von Immateriellen Werte

Bei Standard-Softwareunternehmen sind immaterielle Werte wie Kundenlisten oder Marken von hoher Bedeutung für den Unternehmenserfolg. Diese werden trotz zahlreicher Vorstösse heute nur ungenügend und vor allem nicht standardisiert im Geschäftsbericht publiziert. Grundsätzlich sind zwei verschiedene Ansätze denkbar: Eine monetäre Bewertung einzelner immaterieller Werte ba-sierend auf empirischen Modellen, welche das Verhältnis von Cash Inflow in den immateriellen Vermögenswert und den daraus resultierenden Cash Outflow zu messen versuchen oder eine erwei-terte Berichterstattung, welche zusätzliche nicht-monetäre Informationen zu den immateriellen Werten liefert.

3.1. Halten Sie eine monetäre Bewertung von immateriellen Werten anhand von empirischen Cash Flow Modellen für praktikabel?

3.2. Halten Sie eine standardisierte, erweiterte Berichterstattung aus einer Kosten/Nutzen-Perspektive für erstrebenswert?

4. Zukunftsbezogene Berichterstattung

In der Standard-Softwareindustrie führen die diskontinuierlichen technologischen Innovationen und die besonderen Marktmechanismen zu immer wieder stark veränderten Wettbewerbssituationen. Die Einschätzungen des Managements zur Marktentwicklung und zu Schlüsseltrends könnten des-halb dem Investor von Nutzen sein.

4.1. Halten Sie eine Offenlegung der Einschätzungen des Managements zur Marktentwicklung und zu Schlüsseltrends (auch unter Vertraulichkeitsaspekten) für durchsetzbar?

4.2. Sehen Sie weitere Offenlegungsnotwendigkeiten in diesem Bereich?

5. Allgemeine Frage

Sind Sie der Meinung, dass diese vier Bereiche die Hauptprobleme der heutigen Rechnungslegung bei Standard-Softwareunternehmen adressieren?

Page 221: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE VII

2.3. Übersicht der Gesprächspartner

Greg Beams Partner Software Industry Assurance & Advisory Business Services Ernst&Young, Seattle Schriftliche Antwort auf Fragebogen vom 30. September 2005 Claudia Benz Manager PricewaterhouseCoopers, Zürich Telefonisches Interview vom 17. Oktober 2005 Dr. Sonja Brakensiek Konzernbereich Research & Techniques SAP, Walldorf Schriftliche Antwort auf Fragebogen vom 4. November 2005 Deborah Chaote CFO Esmertec, Dübendorf Telefonisches Interview vom 24. Oktober 2005 Florence Furler Manager/Vizedirektorin KPMG Fides Peat, Basel Telefonisches Interview vom 27. September 2005 Chris Harano CFO Day, Basel/Irvine Telefonisches Interview vom 11. Oktober 2005 Renton Leversedge Senior Manager KPMG Fides Peat, Zürich Telefonisches Interview vom 18. Oktober 2005

Page 222: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

ANHANG 2: EXPERTENGESPRÄCHE VIII

Christoph Ladner Brokerage Research, Technologie-/Industriesektor Bank Sarasin, Basel Telefonisches Interview vom 13. Oktober 2005 Roger Meister Equity Research, Technologiesektor swissfirst Bank, Zürich Telefonisches Interview vom 10. Oktober 2005 Dr. Jürg Neck CFO Crealogix, Zürich Telefonisches Interview vom 12. Oktober 2005 Travis Randolph Senior Manager PricewaterhouseCoopers, Genève Telefonisches Interview vom 11. November 2005 Panagiotis Spiliopoulos Equity Research, Telecom Equipment & Services, Hardware und Software Vontobel, Zürich Telefonisches Interview vom 22. September 2005 Mehrdad Torbati Equity Analyst Deutsche Bank, Zürich Telefonisches Interview vom 18. November 2005 Leng Stricker-Wong Investor Relations Esmertec, Dübendorf Telefonisches Interview vom 7. Oktober 2005

Page 223: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS IX

Quellenverzeichnis

Literaturverzeichnis

Aberdeen Group (2002) CA's Revolutionary Software Model http://www3.ca.com/Files/WhitePapers/aberdeen_software_model2.pdf [Zugriff: 11.12.2005]

Aboody, David / Lev, Baruch (1998) The Value-Relevance of Intangibles: The Case of Software Capitalization In: Journal of Accounting Research, Volume 36 Supplement, 1998, S. 161-191

Achleitner, Ann-Kristin / Behr, Giorgio (2002) International Accounting Standards, Ein Lehrbuch zur Internationalen Rech-nungslegung München: Vahlen, 2002, 3. Auflage

Ahern, Dennis M. / Clouse, Aaron / Turner, Richard (2004) CMI Distilled - A Practical Introduction to Integrated Process Improvement Boston: Pearson Education, 2004

AICPA (Hrsg.) (1994) Improving Business Reporting - A Customer Focus (The Jenkins Report) http://www.aicpa.org/members/div/acctstd/ibr/index.htm [Zugriff: 27. 11. 2005]

AICPA (Hrsg.) (2000) Codification of Statements on Auditing Standards New York: 2000

AICPA (Hrsg.) (2001) AICPA Audit Guide - Auditing Revenues in Certain Industries New York: 2001

Page 224: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS X

Andrews, Andrea R. / Simonetti, Gilbert (1996) Tort Reform Revolution In: Journal of Accountancy, September 1996, S. 53-55

Arbeitskreis immaterielle Werte im Rechnungswesen der Schmalenbach-Gesellschaft für Betriebswirtschaft e. V. (2001) Kategorisierung und bilanzielle Erfassung immaterieller Werte In: Der Betrieb, 54 Jg., Nr. 19/2001, S. 989-995

Aube, Mike / Newberry, Leslie (1996) Glossary of Object-Oriented Terminology for Business http://sunsite.uakom.sk/sunworldonline/swol-04-1996/swol-04-oobook.glossary.html [Zugriff: 23.11.2005]

Baaken, Thomas / Launen, Michael (1993) Software-Marketing München: Vahlen, 1993

Baetge, Jörg (Hrsg.) et al. (1997) Rechnungslegung nach International Accounting Standards (IAS), Kommentar auf der Grundlage des deutschen Bilanzrechts Stuttgart: Schäffer-Poeschel, 1997

Bank, David (2001) Breaking Windows New York: The Free Press, 2001

Behr, Giorgio (2002) Financial Reporting In: Einführung in die Managementlehre, 1. Auflage, Bern 2002, S. 549-584

Bender, Christian (2005) Umsatzerfassung - Entwicklung eines Rahmenkonzepts für eine investororien-tierte Neugestaltung der Standardsetzung Wiesbaden: Dissertation an der Universität St. Gallen, 2005

Page 225: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XI

Bierman, Harold / Dukes, Roland (1975) Accounting for Research and Accounting Costs In: Journal of Accounctancy, April 1975, S. 48-55

Brealey, Richard A. / Myers, Stewart C. (1996) Principles of Corporate Finance New York et al.: McGraw-Hill, 1996, 6. Auflage

Brooks, Frederick P. (1995) The Mythical Man-Month; Essays on Software Engineering Reading: Addison-Wesley, 1995

Brynjolfsson, Erik / Yang, Shinkyu (1999) The Intangible Costs and Benefits of Computer Investments: Evidence from the Financial Markets - Revised http://ebusiness.mit.edu/erik/ITQ00-11-25.pdf [Zugriff: 11.09.2005]

Buxmann, Peter (2002) Strategien von Standard-Software-Anbietern: Eine Analyse auf der Basis von Netzeffekten In: Zeitschrift für betriebswirtschaftliche Forschung (zfbf) 54, August 2002, S. 442-457

Christoffers, Rudi (1970) Die Problematik des § 153 Abs. 3 AktG aus betriebswirtschaftlicher Sicht In: Der Betrieb, Jg. 23, Nr. 51/1970, S. 165-170

Coggan, Philip (2005) Google leaps up FT Global 500 ranks In: Financial Times, 3. Juli 2005

Cohen, Jerome B. / Zinbarg, Edward D. / Zeikel, Arthur (1987) Investment Analysis and Portfolio Management Irwin: Burr Ridge et al., 1987, 5. Auflage

Page 226: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XII

Cusumano, Michael A. (1996) Die Microsoft-Methode: Sieben Prinzipien, wie man ein Unternehmen an die Weltspitze bringt Freiburg: Haufe Verlag, 1996

Dawo, Sascha (2003) Immaterielle Güter in der Rechnungslegung nach HGB, IAS/IFRS und US-GAAP Herne/Berlin: Verlag Neue Wirtschafts-Briefe, 2003

Delaney, Patrick R. et al. (2004) GAAP 2005; Interpretation and Application of Generally Accepted Account-ing Principles New York et al.: Wiley, 2004

Di Maria, Corrado / Köttl, Johannes (2002) Lagged Network Exernalities and Rationing in a Software Monopoly In: Reihe Ökonomie/Institut für Höhere Studien 120, Wien 2002

Diamond, Michael A. / Nicolaisen, Donald T. (1997) Intangibles In: International Accounting and Finance Handbook, New York et al. 1997, Kapitel 14

Edvinsson, Leif / Brünig, Gisela (2000) Aktivposten Wissenskapital Wiesbaden: Gabler, 2000

Epstein, Barry J. / Mirza, Abbas Ali (2002) IAS 2002; Interpretation and Application of International Accounting Stan-dards Somerset: Wiley, 2002

Eustace, Clark (2000) The Intangible Economy Impact and Policy Issues; Report of the European High Level Expert Group on the Intangible Economy Luxemburg: European Commission, 2000

Page 227: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XIII

Evans, David S. (Hrsg.) et al. (2002) Microsoft, Antitrust and the New Economy: Selected Essays Norwell: Kluwer Academic Publishers, 2002

FASB (2000) EITF 00-21: Revenue Arrangements with Multiple Deliverables http://www.fasb.org/pdf/abs00-21.pdf [Zugriff: 27.01.2005]

FASB (2002) The Revenue Recognition Project http://www.fasb.org/project/tfr_article_dec_2002.pdf [Zugriff: 27.01.2005]

FASB (2004) Consumer Point in Case http://www.fasb.org/project/case_in_point.pdf [Zugriff: 10.09.2005]

FASB (2005a) Minutes of the June 29, 2005 FVM Board Meeting http://www.fasb.org/board_meeting_minutes/06-29-05_fvm.pdf [Zugriff: 20.12.2005]

FASB (2005b) FASB/IASB Joint Meeting Minute - October 24, 2005 http://www.fasb.org/board_meeting_minutes/10-24-05_rev_rec.pdf [Zugriff: 20.12.2005]

FASB (2006) Revenue Recognition - Project Updates http://www.fasb.org/project/revenue_recognition.shtml [Zugriff: 20.04.2006]

Fülbier, Rolf U. et al. (2000) Bilanzierung immaterieller Vermögenswerte In: Recht der internationalen Wirtschaft, 11/2000, S. 833-844

Page 228: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XIV

Gallaugher, John M. / Wang, Yu-Ming (2002) Understanding Network Effects in Software Markets: Evidence from Web Server Pricing In: MIS Quarterly Vol. 26 No. 4, December 2002, S. 303-327

Ghemawat, Pankay et al. (1999) Strategy and the Business Landscape, Text and Cases Reading New York et al.: Addison-Wesley, 1999

Hansen, Hans R. / Neumann, Gustaf (2001) Wirtschafsinformatik I Stuttgart: Lucius&Lucius, 2001

Hars, Alexander (2002) Open Source Software: Revolution auf dem Softwaremarkt? In: WISU - Das Wirtschaftsstudium 4/02, S. 542-552

Hebeisen, Beat (2006) Viele haben Lehren aus dem Fall Esmertec zu ziehen In: Finanz und Wirtschaft, 28. Januar 2006, S. 23

Hess, Thomas (2000) Netzeffekte - Verändern neue Informations- und Kommunikationstechnologien das klassische Marktmodell? In: Wirtschaftsstudium (WiSt), Heft 2, Februar 2000, S. 96-98

Hoch et al. (2000) Secrets of Software Success Boston: Harvard Business School Press, 2000

Høegh-Krohn, Nils E. / Knivsflå, Kjell H. (2000) Accounting for Intangible Assets in Scandinavia, the UK, and by the IASC: Challenges and a Solution In: The International Journal of Accounting, Vol. 35, 2000, S. 243-265

Page 229: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XV

Hoppenheit, Christoph (1993) Controlling in Softwareunternehmen: Konzeption für Entwicklungsbereiche Wiesbaden: Deutscher Universitätsverlag, 1993

IASB (2003a) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_445_0305ob06.pdf [Zugriff: 26.04.2005]

IASB (2003b) IASB Update June 2003 http://www.iasb.org/uploaded_files/documents/8_133_0603bdc.pdf [Zugriff: 26.04.2005]

IASB (2003c) IASB Update June 2003 http://www.iasb.org/uploaded_files/documents/8_133_0603bdc.pdf [Zugriff: 26.04.2005]

IASB (2003d) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_442_0306ob07.pdf [Zugriff: 26.04.2005]

IASB (2003e) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_441_0307ob15.pdf [Zugriff: 26.04.2005]

IASB (2003f) IASB Update September 2003 http://www.iasb.org/uploaded_files/documents/8_133_0903bdc.pdf [Zugriff: 26.04.2005]

Page 230: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XVI

IASB (2003g) IASB Update December 2003 http://www.iasb.org/uploaded_files/documents/8_133_0312bdc.pdf [Zugriff: 26.04.2005]

IASB (2004a) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_721_0402ob09.pdf [Zugriff: 10.08.2005]

IASB (2004b) IASB Update March 2004 http://www.iasb.org/uploaded_files/documents/8_133_upd0403.pdf [Zugriff: 26.04.2005]

IASB (2004c) IASB Update May 2004 http://www.iasb.org/uploaded_files/documents/8_133_upd0405.pdf [Zugriff: 26.04.2005]

IASB (2004d) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_865_0405ob04.pdf [Zugriff: 10.08.2005]

IASB (2004e) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_892_0407ob06.pdf [Zugriff: 26.04.2005]

IASB (2005a) INFORMATION FOR OBSERVERS http://www.iasb.org/uploaded_files/documents/8_1058_0506ob07.pdf [Zugriff: 10.08.2005]

Page 231: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XVII

IASB (2005b) IASB Update September 2005 http://www.iasb.org/uploaded_files/documents/8_133_upd0509.pdf [Zugriff: 11.11.2005]

Katz, Michael L. / Shapiro, Carl (1985) Network Externalities, Competition, and Compatibility In: American Economic Review 75, 1985, S. 424-440

Kazanjian, Robert K. (1988) Operationalizing Stage of Growth: An Empirical Assessment of Dominant Problems In: Hornaday, John A. et al. (Hrsg.): Frontiers of Entrepreneurship Research, Wellesley 1988, S. 144-158

Keller, Donald P. et al. (1999) The User-Friendly Guide to Understanding Software Revenue Recognition New York: PricewaterhouseCoopers (Eigenverlag), 1999

Kessler, Harald (1994) Entwicklungskosten für Software in der Bilanz des Herstellers In: Betriebsberater (BB) Nr. 19, 1994, Beilage 12.

Kieso, Donald E. / Warfield, Terry D. / Weygandt, Jerry J. (2004) Intermediate Accounting New York et al.: Wiley, 2004, 11. Auflage

KPMG (Hrsg.) (2003) Rechnungslegung nach US-amerikanischen Grundsätzen. Grundlagen der US-GAAP und SEC-Vorschriften Berlin: IDW-Verlag, 2003, 3. Auflage

Kromrey, Helmut (1998) Empirische Sozialforschung Opladen: Leske + Budrich, 1998, 8. Auflage

Page 232: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XVIII

Küting, Karlheinz (2001) Bilanzierung und Bilanzanalyse am Neuen Markt Stuttgart: Schäffer-Poeschel, 2001

Küting, Karlheinz / Pilhofer, Jochen / Kirchhof, Jürgen (2002) Die Bilanzierung von Software aus Sicht des Herstellers nach US-GAAP und IAS In: Die Wirtschaftsprüfung, 55. Jg., Nr. 3/2002, S. 73-85

Küting, Karlheinz / Turowski, Philipp / Pilhofer, Jochen (2001) Umsatzrealisation im Zusammenhang mit Mehrkomponentenverträgen - Aktu-elle Entwicklungstendenzen in der US-amerikanischen Rechnungslegung In: Die Wirtschaftsprüfung, 54. Jg., Nr. 6/2001, S. 305-317

Labhart, Peter A. / Volkart, Rudolf (2001a) Wie das investierte Kapital bewerten? In: Der Schweizer Treuhänder, 03/01, S. 194-200

Labhart, Peter A. / Volkart, Rudolf (2001b) Reflektierung von immateriellen Aktiven in der Rechnungslegung: Relevanz von Intangibles als Bewertungsgrössen In: Der Schweizer Treuhänder, 11/01, S. 1155-1162

Lawlis, Patricia K. / Flowe, Robert M. / Thordahl, James B. (1995) A Correlational Study of the CMM and Software Development Performance http://www.stsc.hill.af.mil/crosstalk/1995/09/Correlat.asp [Zugriff: 21.12.2005]

Lee, Charles M.C. (1999) Accounting-Based Valuation: Impact on Business Practices and Research In: Accounting Horizons, Vol. 13, Nr. 4, Dezember 1999, S. 413-425

Leibfried, Peter (2002) Rechnungslegung von Wachstumsunternehmen Bamberg: Dissertation an der Universität St. Gallen, 2002

Page 233: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XIX

Lev, Baruch (2001) Intangibles: Management, Measurement, and Reporting Washington: Brookings Institution Press, 2001

Lev, Baruch / Sougiannis, Theodore (1996) The Capitalization, Amortization, and Value Relevance of R&D In: Journal of Accounting and Economics, Vol. 21, 1996, S. 107-138

Lev, Baruch / Zarowin, Paul (1999) The Boundaries of Financial Reporting and How to Extend Them http://www.stern.nyu.edu/~blev/boundaries.doc [Zugriff: 26.07.2004]

Liebowitz, Stan J. (2002) Re-Thinking the Network Economy - The True Forces That Drive the Digital Marketplace New York: AMACOM, 2002

Mertens, Peter et al. (2001) Grundzüge der Wirtschaftsinformatik Berlin: Springer, 2001, 7. Auflage

Moxter, Adolf (1979) Immaterielle Werte im neuen Bilanzrecht In: Betriebs-Berater (BB) Nr. 22, 1979, S. 1102-1109

Müller, Michael (1990) Software-Unternehmen am deutschen Software-Markt. Leistungswirtschaftl-che Besonderheiten, Wettbewerbsbedingungen und Gestaltungsmassnahmen Düsseldorf: VDI Verlag, 1990

Müller, Ralph (1999) Erfolgsfaktoren schnell wachsender Software-Startups: eine lebenszyklusori-entierte Untersuchung von Softwareunternehmen des Produktgeschäfts Frankfurt am Main: Peter Lang, 1999

Page 234: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XX

Neugebauer, Ursula (1986) Das Software-Unternehmen: eine empirische Untersuchung des Unterneh-mensverhaltens und der Faktoren des Unternehmenserfolgs München/Wien: Oldenbourg, 1986

Nikolai, Loren A. / Bazley, John D. (1996) Intermediate Accounting Cincinnati: South-Western Educational Publishing, 1996, 7. Auflage

o.V. (1998) "Ich bin Optimist" In: Manager Magazin 12/98, S. 162

o.V. (2002a) Cases: Computer Associates International, Inc. http://www.whafh.com/modules/case/index.php?action=view&id=161 [Zugriff: 26.03.2005]

o.V. (2002b) Capability Maturity Model Integration for Software Engineering, Version 1.1 - Staged Representation http://www.sei.cmu.edu/cmmi/models/sw-staged.doc [Zugriff: 10.09.2005]

o.V. (2004a) SIIA: Software Industry Statistics Page - Q1 2005 http://www.siia.net/software/pubs/statpage_Q105.pdf [Zugriff: 10.09.2004]

o.V. (2004b) Timeline der Softwareentwicklung http://www.computermuseum-muenchen.de/dictionary/history/software_timeline.html [Zugriff: 11.11.2004]

Page 235: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXI

o.V. (2005a) March 2005 - Web Server Survey Finds 60 Million Sites http://news.netcraft.com/archives/web_server_survey.html [Zugriff: 10.03.2005]

o.V. (2005b) Microsoft Software Assurance http://www.microsoft.com/licensing/programs/sa/default.mspx [Zugriff: 25.03.2005]

o.V. (2005c) Press Release: BusinessWeek/Interbrand Annual Ranking of the 100 Top Global Brands http://www.ourfishbowl.com/images/press_releases/pressrelease_bgb2005.pdf[Zugriff: 14.09.2005]

o.V. (2005d) Esmertec - Offering Memorandum 2005

OECD (1998) The Software Sector: A Statistical Profile for Selected OECD Countries http://www.oecd.org/dataoecd/33/33/2094588.pdf [Zugriff: 11.07.2004]

OECD (2001) National Accounts - International Trade Statistics - The Treatment of e-commerce and software in german foreign trade statistics http://www.oecd.org/dataoecd/31/1/2668854.pdf [Zugriff: 14.11.2005]

Österle, Hubert (Hrsg.) (1990) Integrierte Standard-Software: Entscheidungshilfen für den Einsatz von Soft-warepaketen Hallbgermoos: Angewandte Informationstechnik, 1990

Page 236: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXII

Palepu, Kirshna G. / Healy, Paul M. / Bernard, Victor L. (2004) Business Analysis & Valuation: Using Financial Statements Mason: Thomson/South-Western, 2004, 3. Auflage

Parr, Russell L. / Smith, Gordon V. (2003) Valuation of Intellectual Property and Intangible Assets Somerset: Wiley, 2003, 3. Auflage, Cumulative Supplement

Pilhofer, Jochen (2002) Umsatz- und Gewinnrealisierung im internationalen Vergleich : bilanzpoliti-sche Gestaltungsmöglichkeiten nach HGB, US-GAAP und IFRS Herne/Berlin: Verlag Neue Wirtschafts-Briefe, 2002

Pirker, Sabine (1997) Bilanzierung von Software Wien: Linde, 1997

Raymond, Eric S. (1999) The Cathedral and the Bazaar Sebastopol: O'Reilly & Associates, 1999

Sauer, Klaus P. (1988) Bilanzierung von Software Wiesbaden: Gabler, 1988

Schoenfeld, Hanns-Martin (1981) Grundsätze der Rechnungslegung in den USA In: Zeitschrift für Betriebswirtschaft (ZfB), 1981, S. 290-311

Schreiber, Susanne (2002) Der Ansatz von Intangible Assets nach US-GAAP Wiesbaden: Deutscher Universitätsverlag, 2002

Schumann, Jochen (1992) Grundzüge der mikroökonomischen Theorie Berlin et al.: Springer, 1992, 6. Auflage

Page 237: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXIII

SEC (1997) Report to the President and the Congress on the First Year of Practice under the Private Securities Litigation Reform Act of 1995 http://www.sec.gov/news/studies/lreform.txt [Zugriff: 20.12.2005]

Spremann, Klaus (2002) Finanzanalyse und Unternehmensbewertung München/Wien: Oldenbourg, 2002

Stier, Winfried (1996) Empirische Forschungsmethoden Heidelberg: Springer, 1996

Timmers, Paul (2000) Electronic Commerce - Strategies and Models for Business-to-Business Trad-ing Chichester: Wiley, 2000

Ulrich, Hans (1984) Management Herausgegeben von Dyllick, Thomas / Probst, Gilbert J., Bern/Stuttgart: Haupt, 1984

Upton, Wayne S. Junior (2001) Financial Accounting Series, Special Report: Business and Financial Report-ing, Challenges from the New Economy Internet http://www.fasb.org/articles&reports/sr_new_economy.pdf [Zugriff: 05/04/2005]

Vijayan, Jaikumar (2000) CA pricing goes subscription http://www.computerworld.com/industrytopics/retail/story/0,10801,53037,00.html [Zugriff: 25.03.2005]

Page 238: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXIV

von Keitz, Isabel (1997) Immaterielle Güter in der internationalen Rechnungslegung: Grundsätze für den Ansatz von immateriellen Gütern in Deutschland im Vergleich zu den Grundsätzen in den USA und nach IASC Düsseldorf: IDW-Verlag, 1997

Wayner, Peter (2000) Free For All. How Linux and the Free Software Movement Undercut the High-Tech Titans New York: HarperCollins, 2000

Wiesinger, Christian (1996) Quantitatives Projektcontrolling als entscheidende Grundlage einer professi-onellen Softwareentwicklung Wien: Dissertation, 1996

Williams, Gregg (1982) Lotus Development Corporation’s 1-2-3 In: Byte, 12/1982, S. 182-198

Yates, John C. (1997) New Guidelines for Software Revenue Recognition - Pointers for Providing Guidance to Clients (Teil I) In: Computer & Internet Lawyer, Vol. 14, Nr. 12, Dezember 1997

Zerdick, Axel et al. (1999) Die Internet-Ökonomie: Strategien für die digitale Wirtschaft Berlin: Springer, 1999

Page 239: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXV

Normenverzeichnis

IFRS

IAS 14 Segmentberichterstattung (Segment Reporting)

IAS 17 Leasing (Leases)

IAS 18 Erträge (Revenue)

IAS 24 Angaben zu Beziehungen zu nahe stehenden Unternehmen und Perso-nen (Related Party Disclosures)

IAS 36 Wertminderung von Vermögenswerten (Impairment of Assets)

IAS 37 Rückstellungen, Eventualschulden und Eventualforderungen (Provisi-ons, Contingent Liabilities and Contingent Assets)

IAS 38 Immaterielle Vermögenswerte (Intangible Assets)

SIC 6 Kosten der Anpassung vorhandener Software (Costs of Modifying E-xisting Software)

Page 240: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXVI

US-GAAP

Category A424:

SFAS 2 Accounting for Research and Development Costs

SFAS 13 Accounting for Leases

SFAS 48 Revenue Recognition When Right of Return Exists

SFAS 57 Related Party Disclosures

SFAS 86 Accounting for Costs of Computer Software to Be Sold, Leased or Otherwise Marketed

SFAS 121 Accounting for the Impairment of Long-Lived Assets and for Long-Lived Assets to Be Disposed Of

SFAS 131 Disclosures about Segments of an Enterprise and Related Information

SFAS 142 Goodwill and Other Intangible Assets

APB 12 Omnibus Opinion

APB 17 Intangible Assets

SAB 101 Revenue Recognition in Financial Statements

SAB 104 Revenue Recognition

Category B:

SOP 93-7 Reporting on Advertising Costs

SOP 97-2 Software Revenue Recognition

SOP 98-4 Deferral of the Effective Date of a Provision of SOP 97-2

SOP 98-9 Modification of SOP 97-2 with Respect to Certain Transactions

424 Vgl. Abbildung 13 in dieser Dissertation zur Kategorisierung der Normen im Rahmen des House of GAAP.

Page 241: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

QUELLENVERZEICHNIS XXVII

Category C:

EITF 00-21 Accounting for Revenue Arrangements with Multiple Deliverables

Weitere, nicht verpflichtende Literatur:

SFAC 1 Objectives of Financial Reporting by Business Enterprises

SFAC 5 Recognition and Measurement in Financial Statements of Business Enterprises

SFAC 6 Elements of Financial Statements

Page 242: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability
Page 243: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability

Curriculum Vitae

Michael Studer, geboren am 6. August 1977 in St. Gallen / Schweiz

Akademische Ausbildung

2001 - 2006 Doktorandenstudium an der Universität St. Gallen

1999 - 2002 CEMS-Studium mit Abschluss als Master in International Management (MIM CEMS)

1997 - 2001 Lizenziatsstudium an der Universität St. Gallen

2000 Studium am Rensselaer Polytechnic Institute, New York

1999 Studium an der Università L. Bocconi, Mailand

Berufserfahrung

Seit 2007 Deloitte Consulting GmbH, Zürich

2003 - 2005 Immobilenunternehmung Bautaria AG

2001 - 2002 Lehrstuhl für Rechnungslegung von Prof. Dr. Giorgio Behr an der Universität St. Gallen

2001 Arthur D. Little, Palo Alto

2000 Schweizerische Post AG, Bern

1999 Pallas AG, Olten

Page 244: Rechnungslegung von SoftwareunternehmenFILE/dis3280.pdfCASE Computer Aided Software Engineering CBV Customer Based Value CD Compact Disk CEO Chief Executive Officer CMM Capability