Bilanzierung von Cloud-Computing-Vereinbarungen nach IFRS. Abschlusspolitik und Abschlussanalyse

Tesis de Máster , 2021 , 75 Páginas , Calificación: 1.7

Economía de las empresas - Contabilidad e impuestos

In der Arbeit wird zunächst auf die allgemeinen Grundlagen von Cloud- Computing sowie auf die unterschiedlichen Service- und Bereitstellungsmodellen eingegangen. Dadurch soll ein solides Verständnis der Termini und der verfolgten Zielsetzung der dahinterstehenden Technologie ermöglicht werden. Das primäre Ziel dieser Arbeit besteht unter anderem darin, auf Basis der Entscheidung des IFRS IC und den bestehenden IFRS ein grundlegendes Verständnis für die bilanzielle Abbildung von Cloud-Computing-Vereinbarungen zu schaffen und unter den Gesichtspunkten möglicher abschlusspolitischer und -analytischer Fragestellungen auf die Auswirkungen ausgewählter Kennzahlen einzugehen.

In den letzten Jahren hat kein anderes Thema branchenübergreifend und global einen so hohen Stellenwert in den Unternehmen eingenommen, wie die Industrie 4.0 und die Digitalisierung. Dabei rückt vor allem Cloud-Computing immer weiter in den Fokus der Öffentlichkeit und führt bei großen und kleinen Unternehmen zu einer Ausweitung der IT-Planung. Laut Gartner werden die weltweiten Endnutzerausgaben für Public-Cloud- Services im Jahr 2021 voraussichtlich um 18,4 % auf insgesamt 304,9 Mrd. US-Dollar steigen.

Das größte Marktsegment soll das Servicemodell ‚Software as a Service‘ (SaaS) mit einem prognostizierten Volumen von 117,7 Mrd. US-Dollar einnehmen. Auch Softwareanbieter erkennen immer weiter das Potenzial der Cloud. So schreibt das deutsche Softwareunternehmen SAP in seinem zusammengefassten Konzernlagebericht des Geschäftsjahres 2020, dass bis zum Jahr 2025 Clouderlöse von über 22 Mrd. € erwartet wer- den. Diese Prognose entspricht aus der heutigen Sicht der SAP fast einer Verdreifachung der Erlöse im Cloudbereich. Aus Anwendersicht stellt sich damit zunehmend auch im Bereich der internationalen Rechnungslegung die Frage nach der bilanziellen Behandlung von Cloudvereinbarungen.

Derzeit bieten die IFRS (International Financial Reporting Standards) keine expliziten Regelungen hierfür. Erst im September und November 2018 wurde das IFRS IC (International Financial Reporting Standards Interpretations Committee) zum ersten Mal mit einer externen Anfrage konfrontiert. Diese betraf die bilanzielle Behandlung des Zugriffsrechts und die anfallenden Gebühren eines Softwarenutzers, der auf die in der Cloud-Infrastruktur des Anbieters befindliche Anwendungssoftware zugreift. Der finale Beschluss der Agenda erfolgte schließlich im März 2019.

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1. Einleitung und Zielsetzung

2. Allgemeine Grundlagen
2.1 Hintergründe von Cloud-Computing
2.2 Definition von Cloud-Computing
2.3 Servicemodelle der Cloud-Computing-Vereinbarungen
2.3.1 Everything as a Service (XaaS)
2.3.2 Infrastructure as a Service (IaaS)
2.3.3 PlatformasaService(PaaS)
2.3.4 Software as a Service (SaaS)
2.4 Bereitstellungsmodelle der Cloud-Computing-Vereinbarungen
2.5 Vor- und Nachteile von Cloud-Computing

3. Bilanzierung von Cloud-Computing-Vereinbarungen nach den IFRS
3.1 Allgemeines
3.2 BilanzierungdemGrundenach
3.2.1 Softwareleasing nach IFRS 16
3.2.2 Immaterielle Vermögenswerte nach IAS 38
3.2.3 Dauerschuldverhältnis nach IFRS
3.2.4 Behandlung von Implementierungskosten
3.3 Bilanzierung der Höhe nach
3.3.1 Immaterieller Vermögenswert nach IAS 38- Zugangsbewertung
3.3.2 Immaterieller Vermögenswert nach IAS 38- Folgebewertung
3.4 Fallbeispiel einer Cloud-Computing-Vereinbarung in einem Unternehmen..

4. Abschlusspolitik und Abschlussanalyse nach den IFRS
4.1 Grundlagen
4.1.1 Abschlusspolitik nach den IFRS
4.1.1.1 Definition der Abschlusspolitik
4.1.1.2 Ziele der Abschlusspolitik
4.1.1.3 Abschlusspolitische Instrumente
4.1.2 Abschlussanalyse nach den IFRS
4.1.2.1 Definition der Abschlussanalyse
4.1.2.2 Ziele der Abschlussanalyse
4.1.2.3 Kennzahlen in der Abschlussanalyse
4.1.2.4 Strukturbilanz nach IFRS als Ausgangspunkt
4.2 Abschlusspolitische und abschlussanalytische Maßnahmen im Kontext der Bilanzierung von Cloud-Computing-Vereinbarungen
4.2.1 Bilanzierung als Dauerschuldverhältnis
4.2.2 Bilanzierung als immaterieller Vermögenswert
4.2.3 Gesamturteil der Abschlussanalyse

5. Fazit

Anhang A
A. l. Berechnungsbeispiel zu 4.2.1 - Cloudvereinbarung als Dauerschuldverhältnis
A.l.l Vor der Bilanzierung der Cloudvereinbarung
A. 1.2 Nach der Bilanzierung der Cloudvereinbarung

Anhang B
B. l. Berechnungsbeispiel zu 4.2.2 - Cloudvereinbarung als immaterieller Vermögenswert
B. l.l. Szenario 1: SaaS-Vereinbarung auf einer Public Cloud
B.l.1.1 Vor Bilanzierung der Cloudvereinbarung
B.l.1.2 Nach Bilanzierung der Cloudvereinbarung
B.1.2. Szenario 2: SaaS-Vereinbarung auf einer Private Cloud
B.l.2.1 Vor Bilanzierung der Cloudvereinbarung
B.l.2.1 Nach Bilanzierung der Cloudvereinbarung

Anhang C

Literaturverzeichnis

Rechtsquellenverzeichnis

Intemetquellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Pizza as a Service (in Anlehnung anMissbach et al., 2016, S. 5)

Abbildung 2: Cloud-Computing-Übersicht (inAnlehnunganHerzwurm etal, 2011) ...

Abbildung 3: Infrastructure as a Service (IaaS)

Abbildung 4: Platform as a Service (PaaS)

Abbildung 5: Software as a Service (SaaS)

Tabellenverzeichnis

Tabelle 1: Übersicht der Cloud-Zahlungen über die Geschäftsjahre xl-x5

Tabelle 2: Bilanzierung als Dauerschuldverhältnis

Tabelle 3: Bilanzierung als SaaS-Vereinbarung auf einer Public Cloud

Tabelle 4: Bilanzierung als SaaS-Vereinbarung auf einer Private Cloud

Tabelle 5: Gegenüberstellung der Veränderungen

1. Einleitung und Zielsetzung

In den letzten Jahren hat kein anderes Thema branchenübergreifend und global einen so hohen Stellenwert in den Unternehmen eingenommen, wie die Industrie 4.0 und die Di­gitalisierung. Dabei rückt vor allem Cloud-Computing immer weiter in den Fokus der Öffentlichkeit und führt bei großen und kleinen Unternehmen zu einer Ausweitung der IT-Planung. Laut Gartner werden die weltweiten Endnutzerausgaben für Public-Cloud- Services im Jahr 2021 voraussichtlich um 18,4 % auf insgesamt 304,9 Mrd. US-Dollar steigen. Das größte Marktsegment soll das Servicemodell ,Software as a Service‘ (SaaS) mit einem prognostizierten Volumen von 117,7 Mrd. US-Dollar einnehmen.¹ Auch Soft­wareanbieter erkennen immer weiter das Potenzial der Cloud. So schreibt das deutsche Softwareunternehmen SAP in seinem zusammengefassten Konzernlagebericht des Ge­schäftsjahres 2020, dass bis zum Jahr 2025 Clouderlöse von über 22 Mrd. € erwartet wer­den.² Diese Prognose entspricht aus der heutigen Sicht der SAP fast einer Verdreifachung der Erlöse im Cloudbereich. Aus Anwendersicht stellt sich damit zunehmend auch im Bereich der internationalen Rechnungslegung die Frage nach der bilanziellen Behandlung von Cloudvereinbarungen. Derzeit bieten die IFRS (International Financial Reporting Standards) keine expliziten Regelungen hierfür. Erst im September und November 2018 wurde das IFRS IC (International Financial Reporting Standards Interpretations Commit­tee) zum ersten Mal mit einer externen Anfrage konfrontiert. Diese betraf die bilanzielle Behandlung des Zugriffsrechts und die anfallenden Gebühren eines Softwarenutzers, der auf die in der Cloud-Infrastruktur des Anbieters befindliche Anwendungssoftware zu­greift. Der finale Beschluss der Agenda erfolgte schließlich im März 2019.

In der vorliegenden Arbeit wird zunächst auf die allgemeinen Grundlagen von Cloud­Computing sowie auf die unterschiedlichen Service- und Bereitstellungsmodellen einge­gangen. Dadurch soll ein solides Verständnis der Termini und der verfolgten Zielsetzung der dahinterstehenden Technologie ermöglicht werden. Das primäre Ziel dieser Arbeit besteht u. a. darin, auf Basis der Entscheidung des IFRS IC und den bestehenden IFRS ein grundlegendes Verständnis für die bilanzielle Abbildung von Cloud-Computing-Ver- einbarungen zu schaffen und unter den Gesichtspunkten möglicher abschlusspolitischer und -analytischer Fragestellungen auf die Auswirkungen ausgewählter Kennzahlen ein­zugehen.

2. Allgemeine Grundlagen

2.1 Hintergründe von Cloud-Computing

Die Technologien, die das heutige Cloud-Computing ermöglichen sind zum einen die Virtualisierung und das Internet,³ Der Begriff ,Cloud‘ (dt. Wolke) wurde in der Vergan­genheit verwendet, um das Internet metaphorisch zu beschreiben. Es leitete sich aus der Darstellung von Netzwerkdiagrammen ab. Wissenschaftler und Informatiker versuchten so in der Theorie, bildlich den Transport von Daten von einem Start- zu einem Endpunkt in der ,Wolke‘ darzustellen.⁴ Die zweite relevante Komponente für die Erbringung von cloudbasierten Services ist die Virtualisierung.⁵ Dabei handelt es sich um die Abstraktion von physischer IT-Infrastruktur wie Hardware, Software, Speicher und Netzwerkkompo­nenten. Der Zweck dieser Technologie ist es, die IT-Ressourcen virtuell bereitzustellen und flexibel sowie effektiv an die Endkunden zu verteilen.⁶ Neben technischen Vorteilen wie Effizienz und eine hohe Verfügbarkeit, bietet die Virtualisierung auch wirtschaftliche Vorzüge wie u. a. eine verbesserte Auslastung der IT-Ressourcen.⁷ Die Zeit vor der Er­findung des Internets und der Virtualisierung ist aus heutiger Sicht kaum noch vorstellbar. Dabei stand der Zugang zu Rechenleistung noch vor wenigen Jahren nur einer Minderheit von privilegierten und kommerziell erfolgreichen Unternehmen zur Verfügung.⁸

Die Geschichte der Cloud lässt sich bis in die 1960er zurückverfolgen. Das zugrundelie­gende Konzept für Cloud-Computing wurde im Jahr 1961 durch den amerikanischen In­formatiker und Professor John McCarthy auf der Zentenarfeier des Massachusetts Insti­tute of Technology (MIT) vorgestellt. McCarthy stellte dabei die These auf, dass die Ver­teilung von Rechenleistung eines Tages als öffentliches Versorgungsunternehmen orga­nisiert werden könnte und dass jeder Nutzer nur für die tatsächlich genutzte Kapazität bezahlen müsste.⁹ In den späten 1960er Jahren gelang es im Rahmen des ARPANET (Advanced Research Projects Agency Network), den ersten Großrechner mit einer Ma­schine zu verbinden. Dies wird heute als die Geburtsstunde des Internets und gleichzeitig als die spätere Basis für Cloud-Computing angesehen.¹⁰ Die Idee von John McCarthy verblasste Mitte der 1970er, als zunehmend klar wurde, dass die damalige IT- Technologie nicht in der Lage war, dieses futuristische Konzept zu unterstützen.¹¹ In den 1990er Jahren entstanden innovative Erfindungen, die zu der ,Cloudbewegung‘ beigetra­gen haben. Eine dieser nennenswerten Innovationen war ein Internetdienst zur Verwal­tung von E-Mails, heute bekannt als Webmail, oder in der Cloudsprache ausgedrückt Mail User Agent Software as a Service.¹² Diese führte dazu, dass Cloud-Computing zur Jahrtausendwende wieder an Bedeutung gewann.¹³ Zugleich spielte Amazon eine wesent­liche Rolle für den kommerziellen Erfolg von Cloud-Computing. Durch die Gründung von AWS (Amazon Web Services) im Jahr 2006 konnten Applikationsentwickler On- Demand-Infrastrukturdienstleistungen wie Speicher- und Rechenkapazitäten erwerben.¹⁴ Dies hatte einen globalen Einfluss auf das Cloud-Computing-Business, da sich multina­tionale IT-Dienstleister und Produkthersteller wie Microsoft, Oracle oder IBM gezwun­gen sahen, ebenfalls in diesem neuartigen Geschäftsbereich tätig zu werden.¹⁵ Microsoft startete im Jahr 2010 seine eigene Cloud-Computing-Plattform namens Microsoft Azure. Bereits im Jahr 2019 belegte diese im weltweiten IaaS-Public-Cloud-Markt den zweiten Platz mit einem Marktanteil von 18% hinter dem Marktführer AWS mit 33 %.¹⁶

2.2 Definition von Cloud-Computing

Um in der internationalen Rechnungslegung eine Cloud-Computing-Vereinbarung zu er­kennen und korrekt einordnen zu können, sollte der Bilanzierende die Eigenschaften und Merkmale, die hinter dem Begriff des Cloud-Computing stecken, verstehen. Eine stan­dardisierte und einheitliche Definition gibt esjedoch nicht. Der Ausdruck wurde im Jahr 1997 auf einer Konferenz in Dallas durch Ramnath K. Chellappa, einen Professor für Informationstechnologie der Goizueta Business School, geprägt.¹⁷ Seitdem ist der Termi­nus in der Softwarewelt omnipräsent.¹⁸

Das deutsche Rechtschreibwörterbuch Duden beschreibt Cloud-Computing als eine Nut­zung von IT-Infrastrukturen und IT-Dienstleistungen, die nicht vor Ort auf lokalen Rech­nern genutzt, sondern als ein Dienst angemietet werden. Der Zugriff erfolgt dabei über ein Netzwerk wie bspw. das Internet.¹⁹ In der Literatur werden häufig zusätzliche Eigen­schaften und Merkmale diskutiert, die den Begriff deutlicher umschreiben. Armbruster et al. beschreiben Cloud-Computing nicht nur als die Anwendung, die als Dienst über das Internet bereitgestellt wird, sondern auch als die Hard- und Software in den Rechenzen­tren, die diese Dienste ermöglichen. Darüber hinaus ist einer der im Vordergrund stehen­den Aspekte von Cloud-Computing, dass es sich um eine Illusion von unendlicher Re­chenressourcen handelt, die auf Abruf zur Verfügung stehen.²⁰ Zudem können dieseje nach Bedarf angepasst werden, was auf eine Skalierbarkeit hindeutet.²¹ Die US-ameri­kanische Standardisierungstelle National Institute of Standards and Technology (NIST) hat im September 2011 einen Defmitionsrahmen gesetzt, der weithin akzeptiert wird.²² Darin definiert das NIST Cloud-Computing als ein Modell zur Förderung eines allgegen­wärtigen, komfortablen und bedarfsorientierten Netzwerkzugriffs auf einen gemein­schaftlichen Pool von konfigurierbaren Rechenressourcen wie bspw. Netzwerke, Server, Speicher, Applikationen und Dienste, die mit geringem Verwaltungsaufwand und ohne die Beteiligung des Dienstanbieters schnell bereitgestellt und freigegeben wer­den können.²³ Darüber hinaus hat das NIST fünf wesentliche Merkmale für seine Defini­tion von Cloud-Computing zusammengestellt:

- Bedarfsgerechte Selbstverwaltung (On-demand Self-Service): Der Kunde kann je nach Bedarf selbstständig auf Rechen-, Netzwerk- oder Speicherkapazitäten zugreifen, ohne dass eine menschliche Interaktion mit demjeweiligen Servicpro- vider erforderlich ist.
- Umfassender Netzwerkzugang (Broad Network Access): Die Services des Dienstanbieters werden über ein Netzwerk (i. d. R. das Internet) in Echtzeit be­reitgestellt. Die Nutzung erfolgt über Kommunikationsschnittstellen wie Tablets, Smartphones, Laptops oder andere Endgeräte.
- Ressourcenpooling (Resource Pooling): Die bereitgestellten Ressourcen des Serviceproviders werden in einem sog. Multi-Mandanten-Modell gebündelt, mit der Zielsetzung, mehrere Kunden gleichzeitig zu bedienen. Je nach Bedarf werden die physischen und virtuellen Ressourcen den entsprechenden Endkunden zuge­teilt. Diese haben in der Regel keine Kontrolle oder Kenntnis über den exakten Standort der bereitgestellten Ressource. Jedoch besteht auf einer höheren Abs­traktionsebene in manchen Fällen das Recht, ein Land, ein Bundesland oder ein Rechenzentrum festzulegen.
- Skalierbarkeit (RapidElasticity): Die vorhandenen Ressourcen können flexibel bereitgestellt und freigeschaltet werden. Demnach können die Ressourcen ent­sprechend der Nachfrage des Kunden optimiert werden. In Einzelfällen erfolgt dieser Prozess automatisch. Aus diesem Grund entsteht für den Kunden der Ein­druck, dass die Ressourcen unlimitiert sind undjederzeit in beliebiger Anzahl ab­gerufen werden können.
- Gemessener Dienst (Measured Service): Ein Cloudsystem kontrolliert und opti­miert automatisch die Ressourcennutzung, indem es eine Messfunktion nutzt. Die Ressourcennutzung kann somit überwacht, gesteuert und dokumentiert werden. Dieses Merkmal schafft Transparenz sowohl für den Kunden als auch für den Ser­viceprovider.²⁴

2.3 Servicemodelle der Cloud-Computing-Vereinbarungen

2.3.1 Everything as a Service (XaaS)

Die Technologie des Cloud-Computing hat sich über die Jahre zu einem Everything-as- a-Service-Modell (XaaS-Modell) entwickelt. Das XaaS-Paradigma dient dazu, die Dienstleistungsangebote einzustufen und zu bestimmen. Zugleich erleichtert es das Ver­ständnis der Komplexität von Clouddiensten.²⁵ Die Variable ,X‘ steht zudem für einen Ansatz, der umschreibt, dass alle Services zur Verfügung gestellt und vom Endkunden am Markt konsumiert werden können.²⁶ Das umfassende Angebot von Clouddiensten er­streckt sich von Geschäftsanwendungen, die als Dienste angeboten werden, bis hin zu virtualisierten Infrastrukturen. In der Praxis haben sich dabei drei Service-Ebenen etab­liert.²⁷ Für das Grundverständnis können die verschiedene Servicemodelle mit Hilfe eines ,Pizza-as-a-Service‘-Modells visualisiert werden (vgl. Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Pizza as a Service (inAnlehnung anMissbach etal., 2016, S. 5)

1.On-Premises: Eine Pizza kann zuhause zubereitet werden. Dazu muss der Konsument eigenständig alle Zutaten einkaufen und den Teig eigenverantwortlich hersteilen. Der ganze Prozess erfolgt ohne die Dienstleistung eines Dritten.
2.Infrastructure as a Service (IaaS): Der Konsument kann einen Teil der benötigten Zutaten selbst einkaufen. Im Idealfall liegen die Zutaten bereits zuhause vor. Die Komponenten für die Pizza, wie den Pizzateig inkl. der Tomatensoße und den Belägen, erhält er vorgepackt im Supermarkt.
3.Platform as a Service (PaaS): Die Pizza kann zu dem Konsumenten durch einen Lieferdienst nach Hause geliefert werden. Der Konsument ist damit nur für das Eindecken des Esstisches und für die Getränke verantwortlich. Die komplette Herstellung der Pizza erfolgt durch den Pizzabäcker bzw. den Verkäufer.
4.Software as a Service (SaaS): Der Konsument kann sich die Pizza in einer lokalen Pizzeria bestellen und vor Ort verspeisen. Dementsprechend muss er sich weder um die Zutaten kümmern noch den Esstisch decken. Alle Faktoren werden durch den Verkäufer bereitgestellt und organisiert.

Zusammenfassend bedeutet dies für die einzelnen Servicemodelle, dass der Konsument in allen drei Fällen eine Pizza erhältjedoch werden bei steigender Abstraktionsebene -beginnend bei IaaS bis hin zu SaaS - immer mehr der benötigten Komponenten für die Pizza as a Service durch den Verkäufer verwaltet bzw. organisiert. Dieses Gedankenmodell lässt sich ebenfalls auf das Cloud-Computing-Geschäft übertragen.

Im technologischen Kontext kann die Einordnung der einzelnen Cloudservices anhand der Abbildung 2 illustriert werden (sog. Cloudstacks). Je höher dabei die Abstraktionse­bene ist, desto technisch komplexer sind die angebotenen Dienste.²⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung2: Cloud-Computing-Übersicht(inAnlehnunganHerzwurm etal., 2011)

Resümierend lässt sich verzeichnen, dass die Nutzung einer On-Premise-Lösung mit ei­nem hohen Verwaltungsaufwand einhergeht. Für Unternehmen, die ihre IT-Infrastruktur auslagern und den Verwaltungsaufwand minimieren möchten, bieten sich die oben ge­nannten Servicemodelle in Form von IaaS, PaaS und SaaS an.²⁹ In den nachfolgenden Unterabschnitten wird detaillierter auf die einzelnen Servicemodelle eingegangen.

2.3.2 Infrastructure as a Service (IaaS)

Auf der untersten Abstraktionsebene befindet sich das Servicemodell Infrastructure as a Service (IaaS). Dieses kann als Grundstein für die cloudbasierten Dienste PaaS und SaaS angesehen werden (vgl. Abbildung 2):³⁰ Bei dieser Art des Clouddienstes handelt es sich um ein virtuelles Rechenzentrum, das auf die Bereitstellung von technischer, Service­Hosting-Infrastruktur wie Netzwerke oder Server spezialisiert ist (vgl. Abbildung 3):³¹ Im Mittelpunkt steht hierbei die Zuordnung von Rechenressourcen wie Speicher-, Rechen­oder Netzwerkkapazitäten, die durch die Virtualisierung unterteilt und zugeordnet wer­den können. Somit können die Kapazitäten bzw. Ressourcen an die Anwendungsanforderungen des Kunden angepasst werden (sog. dynamische Skalie­rung),³² und zwar automatisiert.³³ Der Kunde hat dabei die Möglichkeit, jede beliebige Software, z. B. Betriebssysteme und Anwendungen, einzusetzen und auszuführen.³⁴ Zu beachten ist jedoch, dass der Endkunde die Cloud-Infrastruktur weder verwaltet noch kontrolliert. Seine Kontrolle erstreckt sich nur auf die Anwendungen in der Cloud.³⁵ Zu­dem werden IaaS-Infrastrukturen grundsätzlich erst dann verwendet, wenn komplexe An­wendungslandschaften vorliegen, die eine klassische IT-Hardware nicht mehr bewerk­stelligen kann.³⁶ Ein Global Player im IaaS-Bereich ist AWS mit einem aktuellen Pro­duktportfolio von mehr als zwanzig verschiedenen Angeboten, u. a. in den Bereichen Rechenleistung, Datenspeicherung und Messaging. Die virtuelle Rechenumgebung wird dabei in Amazons Produkt ,Elastic Compute Cloud‘ (EC2) bereitgestellt.³⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Infrastructure as a Service (IaaS)

2.3.3 Platform as a Service (PaaS)

Bei dem Servicemodell Platform as a Service (PaaS) wird neben der virtuellen Infrastruk­tur auch Software in Form von Entwicklungsumgebungen (ProgrammingEnvironments) und Laufzeitumgebungen (Execution Environments) angeboten.³⁸ Die Plattform kann so­mit für die Entwicklung oder Ausführung von Software oder Anwendungsdiensten ge­nutzt werden (vgl. Abbildung 4) ,³⁹ Jeder Teilaspekt der Softwareentwicklung von der Ent­wurfsphase bis zur Bereitstellung findet in dieser Cloud-Umgebung statt.⁴⁰ Aus diesem Grund richtet sich PaaS vor allem an System-Architekten und Anwendungsentwickler.⁴¹ Zu beachten ist hierbei, dass der Nutzer weder Zugriff noch Kontrolle auf bzw. über die unterhalb befindlichen Schichten des Betriebssystems oder der Hardware hat. Die Ent­wicklung von Anwendungen auf der PaaS-Implementierung erfolgt durch die vom Cloud-Solution-Provider (CSP) bereitgestellten Werkzeuge.⁴² Bekannte Unternehmen wie Google mit der ,Google App Engine‘ oder Microsoft mit ,Azure‘ bieten das PaaS- Modell auf dem Markt an.⁴³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Platform as a Service (PaaS)

2.3.4 Software as a Service (SaaS)

Auf der höchsten Abstraktionsebene der Clouddienste befindet sich das Servicemodell Software as a Service (SaaS). Es handelt sich bei einem SaaS-Modell um eine Standard­softwarelösung, die über das Internet als Dienstleistung zur Verfügung gestellt wird. Der Serviceprovider hat dabei die Pflicht, für den Betrieb und die Wartung der Software zu sorgen, daher greift der Endnutzer jederzeit auf die aktuellste Softwareversion in der Cloud-Infrastruktur zu.⁴⁴ Dies geschieht durch ein Endgerät mit einer entsprechenden Thin-Client-Schnittstelle, bspw. einem Webbrowser oder einer Programmschnittstelle (vgl. Abbildung 5):⁴⁵ Das SaaS-Modell eignet sich dabei vor allem für Funktionen und Prozesse in Untemehmensbereichen, die sich in einem hohen Maße standardisieren las­sen.⁴⁶ Eine Vielzahl von Anwendungen liegt u. a. in Form einer Enterprise-Resource­Planning-Software (ERP-Software) in den Bereichen Finanz- und Rechnungswesen, Controlling, Personalwesen oder im Customer-Relationship-Management (CRM) vor.⁴⁷ Wichtig ist hierbei anzumerken, dass der Kunde - wie bei IaaS und PaaS - keine Kon­trolle über die gegebene Cloud-Infrastruktur hat.⁴⁸ Aus diesem Grund sind die Anpas- sungs- und Integrationsmöglichkeiten zum Teil begrenzt.⁴⁹ Ein weiterer Aspekt bei diesem Servicemodell ist, dass die Anforderungen an die lokalen Rechnerkapazitäten, z. B. Festplattenspeicher oder CPU-Geschwindigkeit, deutlich reduziert werden. Ein Grund hierfür ist die Rechenleistung, die nicht mehr am lokalen Arbeitsplatz erfolgt, son­dern in den untergeordneten Abstraktionsebenen des Cloudstacks.⁵⁰ Als ein bekanntes Beispiel für einen erfolgreichen SaaS-Anbieter am Markt, dient der amerikanische Soft­wareanbieter Salesforce mit seiner CRM-Lösung ,Sales Cloud‘.⁵¹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Software as a Service (SaaS)

2.4 Bereitstellungsmodelle der Cloud-Computing-Vereinbarungen

Die cloudbasierten Services, die im Abschnitt 2.3 näher beleuchtet wurden, können dem Kunden in unterschiedlichen Bereitstellungsmodellen zur Verfügung gestellt werden. Unterschieden wird hierbei zwischen der Private Cloud, derPublic Cloud und der Com­munity Cloud. Werden zwei oder mehrere der gegebenen Bereitstellungsmodelle kombi­niert, erhält der Endnutzer eine Form der Hybrid Cloud.⁵²

Bei einer Public Cloud nutzen unzählige unterschiedliche User die gleiche IT-Infrastruk- tur des Dienstleisters in Form von Servern, Netzwerken oder Speichersystemen.⁵³ Die Public Cloud ist somit öffentlich zugänglich und wird durch einen externen Dienstleister verwaltet.⁵⁴ Problematisch erscheint dieses Bereitstellungsmodell bei sicherheitskriti­schen Anwendungen oder Daten, da ein nicht begrenzter Kundenkreis Zugriff auf die Cloud hat.⁵⁵ In Anbetracht dessen sollte ein Nutzer cloudbasierter Dienste die IT-Sicher- heitsrisiken bei der Nutzung einer Public Cloud stets im Blick behalten.⁵⁶ Die bedeutendste Eigenschaft einer Private Cloud ist die Exklusivität des Nutzungsrechts für den Endkunden.⁵⁷ Das Konzept einer Private Cloud basiert darauf, dass ein vorab definierter Nutzerkreis (z. B. unterschiedliche Geschäftsbereiche in einem Unternehmen) die vollständige Kontrolle über den Zugriff und die dahinterstehende IT-Infrastruktur hat. Der Zugang wird dabei über ein Intranet oder einem Virtual Private Network (VPN) ge­währleistet. Den Betrieb bzw. die Administration einer Private Cloud übernimmt übli­cherweise das Unternehmen selbst. Es istjedoch auch denkbar, dass ein externer Dienst­leister die Private Cloud administriert.⁵⁸

Die Infrastruktur einer Community Cloud ist darauf ausgelegt, einer spezifischen Kun­dengemeinschaft - mit gleichen Anforderungen an die Cloud - ein exklusives Nutzungs­recht einzuräumen.⁵⁹ Die Verantwortlichkeit für den Betrieb und die Verwaltung dieser Bereitstellungsform liegt entweder bei einem Kunden dieser Gemeinschaft oder einem Dritten.⁶⁰

Das letzte Bereitstellungsmodell ist die Hybrid Cloud. Bei diesem hybriden Konzept wird der traditionelle IT-Betrieb einer Organisation in Form der Private Cloud mit der indivi­duell skalierbaren Public Cloud verknüpft. Dies bietet dem Unternehmen die Möglich­keit, bei Normalbetrieb die eigenen IT-Ressourcen verwenden zu können. Sollten Last­spitzen bzw. Kapazitätsengpässen auftreten, kann die Rechenleistung dann an den Cloud- provider ausgelagert werden (sog. Cloudbursting).⁶¹

2.5 Vor- und Nachteile von Cloud-Computing

Cloud-Computing schafft bei großen und kleinen Unternehmen durch seine speziellen Eigenschaften, bspw. die dynamische Verfügbarkeit, neue Möglichkeiten.⁶² Wie beijeder neuen Technologie, die in einem Unternehmen genutzt wird, existieren auch beim Cloud­Computing Vor- und Nachteile, mit denen sich Anwender intensiv beschäftigen sollten.

Aus finanzieller Sicht spiegelt sich einer der größten Vorteile in der Kostenreduktion. Durch die Nutzung der Cloudservices entfällt beim Kunden die kostspielige Anschaffung von Hard- und Software (z. B. Server, Stellflächen und Lizenzen), was zu einer niedrige­ren Kapitalbindung führt als bei einer On-Premise-Lösung.⁶³ Der Endkunde bezahlt im Rahmen eines variablen Kostenmodells (sog. Pay-per-Use-Prinzip) lediglich für die Leis­tungen, die tatsächlich beansprucht wurden, so dass die vorab getätigten Investitionskosten für die IT-Infrastruktur deutlich sinken. Zugleich ermöglicht das Pay- per-Use-Prinzip eine höhere Kostentransparenz, da eindeutig dokumentiert wird, wie viele Ressourcen des Cloudproviders tatsächlich verbraucht wurden.⁶⁴ Von diesem Vor­teil profitieren vor allem kleinere Unternehmen, bspw. Start-ups oder Mittelständer, die oftmals nur begrenzte finanzielle Ressourcen zur Verfügung haben, um in eine eigene IT- Infrastruktur zu investieren. Durch Cloud-Computing wird diesen Betrieben der Zugang zu Technologien gewährt, die in der Vergangenheit meist nur großen Unternehmen zur Verfügung standen.⁶⁵ Zudem ermöglicht es die Nutzung von Cloud-Computing den Fir­men, unabhängig davon, ob sie groß oder klein sind, die freiwerdenden liquiden Mittel in ihr Kerngeschäft zu investieren.⁶⁶

Aus der operativen Sicht stehen die Skalierbarkeit und die Elastizität von Cloudservices im Vordergrund.⁶⁷ Dieser Vorteil gestattet den Unternehmen die benötigten Ressourcen flexibel an die individuellen Unternehmensbedürfnisse anzupassen.⁶⁸ Ein Unternehmen kann demnach bei saisonbedingten Lastspitzen (z. B. Vertriebskapazitäten für das Weih­nachtsgeschäft oder die Lohnabrechnungen zum Monatsende) seine Rechen- und Spei­cherkapazitäten temporär für einen begrenzten Zeitraum erhöhen, ohne hierfür zusätzli­che vertragliche Bindungen einzugehen.⁶⁹ Durch diese gebotene Flexibilität kann das Un­ternehmen sich ohne komplexe Beschaffungsprozesse an Marktveränderungen anpas­sen.⁷⁰ Herkömmliche IT-Lösungen unterstützen im Vergleich zum Cloud-Computing eine solche Skalierbarkeit nicht. Zugleich ermöglicht es Cloud-Computing den Anwen­dern aufgrund seiner flexiblen Verarbeitungsleistung, große Datenmengen viel schneller zu analysieren als ein herkömmliches IT-System.⁷¹

Cloud-Computing bietet auch nennenswerte strategische Vorteile. Es verbessert u. a. die Produkteinführungszeit (sog. Time-to-Market) für Unternehmen, die Produkte schnellst­möglich auf den Markt bringen möchten.⁷² Dieser Vorteil resultiert im Wesentlichen aus dem Management des Clouddienstes durch den Cloudprovider (z.B. durch automatische Software-Updates). Hierdurch wird der Administrations- und Wartungsaufwand beim Endkunden reduziert und die personellen Ressourcen können letztlich für die Produkt­entwicklung eingesetzt werden.⁷³

Dennoch gibt es auch negative Aspekte, die gegen die Cloud-Computing-Technologie sprechen und berücksichtigt werden müssen. Einer dieser Nachteile betrifft Sicherheits­aspekten und den möglichen Verlust wichtiger Daten von Kunden oder auch von Um­satzberichten.⁷⁴ Durch die Verlagerung von Daten und Programmen in die Cloud entsteht mit Abschluss der Vereinbarung ein Verlust an Kontrollmöglichkeiten des Anwenders, da die zuständige IT-Governance und -Compliance dem Cloudprovider obliegen.⁷⁵ Zu­dem könnten durch eine mangelhafte IT-Sicherheit Unternehmensgeheimnisse verloren gehen oder Endkundendaten missbraucht werden.⁷⁶ Aufgrund dessen sollten die Anwen­der von Cloudservices sorgfältig untersuchen, welche Sicherheitsmechanismen der Cloudprovider implementiert hat, um die benötigte Sicherheit und den Datenschutz in der Cloud zu gewährleisten.⁷⁷ Ferner sollten Service-Level-Agreements (SLAs) vereinbart werden, um ein Verständnis bzgl. Sicherheit, Verantwortlichkeit oder Garantien zu erhal­ten.⁷⁸ Ein SLA fungiert dabei als ein rechtlich bindender Vertrag, der alle Erwartungen und Verpflichtungen in der Geschäftsbeziehung zwischen Cloudprovider und Kunde de­finiert.⁷⁹

Ein weiterer Nachteil für das Unternehmen ist die mit Vertragsabschluss eintretende Ab­hängigkeit gegenüber dem Cloudprovider. Diese stellt ein organisatorisches Risiko dar, da das Unternehmen keinen Einfluss auf die Qualität der gebotenen IT-Infrastruktur und die entsprechenden Ressourcen in Form von Rechen- oder Speicherkapazität hat.⁸⁰ Da­neben besteht auch eine Abhängigkeit vom Netzwerk bzw. dem Internet. Eine Cloud funktioniert nur dann, wenn der Nutzer eine Netzwerkkonnektivität innehat, wie bereits in Abschnitt 2.1 beschrieben. Das Unternehmen sollte aus diesem Grunde eine Cloud nur in dem Fall nutzen, dass eine schnelle und sichere Internetverbindung zur Verfügung steht.⁸¹

3. Bilanzierung von Cloud-Computing-Vereinbarungen nach den IFRS

3.1 Allgemeines

Es stellt sich aus Sicht eines Cloudnutzers, der seinen Jahresabschluss nach den IFRS aufstellt, zunehmend die Frage, wie eine Cloud-Computing-Vereinbarungen bilanziell zu würdigen ist. Hierbei sind vor allem die SaaS-Modelle von höchstem Interesse, da deren Anwender auf die Software und die darunterliegenden Infrastrukturen des Cloudprovi- ders zugreifen. Die Standards selbst enthalten bezüglich dieser Problematik keine präzi­sen Regelungen oder Antworten. Erst im September und November 2018 sah sich das IFRS Interpretations Committee (IFRS IC) aufgrund einer Anfrage gezwungen, sich mit dieser Thematik auseinanderzusetzen. Eine finale und zusammenfassende Entscheidung durch das IFRS IC erfolgte in einer Sitzung im März 2019.

In der Entscheidung des IFRS IC schlägt sich die grundlegende Frage nieder, ob es sich bei der abgeschlossenen Cloudvereinbarung um einen aktivierungsfähigen Vermögens­wert (Software Asset) oder einen nicht aktivierungsfähigen Dienstleistungsvertrag (Ser­vice Contract) handelt.⁸² Wird die Frage nach einem aktivierungsfähigen Vermögenswert bejaht, sollten die Standards für Immaterielle Vermögenswerte (IAS 38) und Leasing­verhältnisse (IFRS 16) in Betracht gezogen werden.⁸³ Hinsichtlich der Frage, ob es sich um einen Dienstleistungsvertrag handelt, sollte das bilanzierende Unternehmen in Erwä­gung ziehen, diesen als Dauerschuldverhältnis anzusetzen.⁸⁴ Die getätigten Zahlungen müssten damit periodisiert und als laufender Aufwand erfasst werden.⁸⁵ Aufgrund der hohen Praxisrelevanz⁸⁶ von ,Software-as-a-Service‘-Vereinbarungen wird in den nach­folgenden Ausführungen ausschließlich auf dieses Servicemodell in einer Public Cloud eingegangen.

3.2 Bilanzierung dem Grunde nach

3.2.1 Softwareleasing nach IFRS 16

Der Ausschuss hat in seiner Entscheidung festgestellt, dass der Softwarenutzer einen Softwarevermögenswert erst dann zu bilanzieren hat, wenn die zugrunde gelegte Cloud- vereinbarung ein Softwareleasing (Software Lease) enthält oder das Unternehmen auf eine andere Weise die Verfügungsgewalt über die Anwendungssoftware bzw. ein darauf gerichtetes Nutzungsrecht zum Zeitpunkt des Vertragsabschlusses erlangt.⁸⁷

Im Hinblick auf ein Softwareleasing müsste zunächst geprüft werden, ob für das entgelt­liche Nutzungsrecht an der Software der IFRS 16 zur Anwendung kommt. Dafür ist die Leasingdefinition des IFRS 16.9 entscheidend. Demnach liegt ein Leasingverhältnis nur vor, wenn eine vertragliche Vereinbarung den Leasingnehmer dazu berechtigt, einen identifizierten Vermögenswert gegen Zahlung eines Entgelts für einen bestimmten Zeitraum zu kontrollieren.⁸⁸ Für die Beurteilung, ob die Definition des Leasings zutrifft, müssen nach IFRS 16.B9 folgende Kriterien kumulativ über die vertraglich vereinbarte Laufzeit vorliegen:

- Der Leasingnehmer hat aufgrund des Vertrages das Recht, über die Nutzung des zugrunde liegenden Vermögenswertes zu verfügen, und
- im Wesentlichen alle ökonomischen Vorteile aus der Nutzung des identifizierten Vermögenswertes zu erhalten.⁸⁹

Zur Beurteilung des ersten Kriteriums ist der IFRS 16.B25 heranzuziehen. Ein Kunde bzw. Softwareanwender hat demnach das Recht, über die Nutzung des Vermögenswertes zu bestimmen, wenn er im Rahmen seines vertraglich festgelegten Nutzungsrechts die Art und den Zweck der Nutzung des Vermögenswertes während der gesamten Laufzeit verändern kann.⁹⁰ Im vorliegenden Fall müsste der Softwarenutzer aufgrund der abge­schlossenen SaaS-Vereinbarung somit die Möglichkeit haben, innerhalb der Vertrags­laufzeit die Anwendungssoftware derart zu modifizieren, dass die Art und der Zweck nicht mehr demselben Ursprung entspricht wie beim Erwerb vom Cloudprovider.⁹¹

Im Hinblick auf die Charakteristika und das Wesen einer SaaS-Vereinbarung ist dieser Punkt äußerst fragwürdig. Zum einen wird eine SaaS-Lösung auf einer Public Cloud ge­rade deshalb erworben, weil der Endnutzer von der Art und dem Zweck der Anwendungs­software und der dahinterstehenden Infrastruktur als Endprodukt überzeugt ist. Ein Bei­spiel hierfür ist das Flaggschiffprodukt S/4HANA von dem Softwarekonzern SAP. Eine Modifikation bzw. das Customizing dieser ERP-Software ist in der On-Premise-Version möglichjedoch kaum, wenn S/4HANA ausschließlich über eine Public Cloud - also die Infrastruktur des Cloudproviders - zur Verfügung gestellt wird. Gerade im Hinblick auf die Standardisierung von Geschäftsprozessen erscheint dies für eine SaaS-Lösung sinn­voll und logisch, da ein Unternehmen, das auf dieses Servicemodell setzt, durch die weg­fallende Möglichkeit von Customizing personelle und finanzielle Ressourcen einsparen möchte.⁹²

Darüber hinaus erwirbt der Softwarenutzer bei einer SaaS-Vereinbarung lediglich ein Zugriffsrecht auf die betreffende Software. Dieses ist von einem Nutzungsrecht, wie es in den IFRS 16.B24 -16.B30 definiert ist, klar zu differenzieren. Nach Maßgabe des Stan­dards gehen mit dem Nutzungsrecht die Entscheidungsbefugnisse bezüglich Art und Zweck der Nutzung des Vermögenswertes auf den Kunden über. Der Bilanzierende kommt hier - in Übereinstimmung mit dem IFRS IC - zu dem Entschluss, dass ein bloßes Zugriffsrecht in Form des Zugangs zur Software und der darunterliegenden Infrastruktur des Anbieters dem Softwarenutzer keine Entscheidungsrechte verschafft, die einen Ein­fluss darauf haben, zu welchem Zweck die Software letztendlich genutzt wird. Vielmehr obliegt dieses Recht dem Anbieter, da dieser u. a. entscheiden kann, welcher Nutzer einen Zugriff auf die Software hat und wann diese aktualisiert oder neu konfiguriert wird. Hin­zukommend hat der Softwareanbieter das Recht darüber zu bestimmen, auf welcher Hardware bzw. Infrastruktur die Software bereitgestellt wird.⁹³

Zudem ist das zweite Kriterium für die Beurteilung der Leasingdefinition ebenfalls nicht auf den Sachverhalt einer SaaS-Vereinbarung übertragbar. Gemäß den IFRS 16.B21- 16.B23 müsste der Nutzer das Recht innehaben, während der gesamten Laufzeit alle öko­nomischen Vorteile aus der Verwendung der Software zu ziehen. Vielmehr ist es aber bei einem SaaS-Geschäftsmodell üblich und durch den Cloudprovider so gewollt, dass un­terschiedliche Nutzer bzw. Organisationen einen Zugang zu der Software haben und sie auch entsprechend nutzen. Dieses Geschäftsmodell schließt somit per se eine Exklusivität des Nutzungsrechts aus.⁹⁴ Im Ergebnis lässt sich demnach feststellen, dass kein Kriterium der Leasingdefmition nach IFRS 16 erfüllt ist.⁹⁵

Daneben ist es fraglich, wie die aufgeführten Lizenzvereinbarungen in IFRS 16.3 (e) zu interpretieren sind. Entweder beschränkt sich die Auswahl nur auf die im Standard auf­gezählten Lizenzvereinbarungen, z. B. Kinofilme, Videoaufzeichnungen, Theaterstücke, Manuskripte, Patente und Urheberrechte, oder die Aufzählung kann aufjegliche Lizenz­vereinbarungen einschließlich Softwarelizenzen ausgebreitet werden. Im Standard selbst ist keine Definition der Begrifflichkeit auffindbar.⁹⁶ Dies hat jedoch vor allem im Hin­blick auf die Beurteilung von Lizenzvereinbarungen über immaterielle Vermögenswerte eine hohe Relevanz. Demnach hätte gemäß IAS 38.6 und IFRS 16.3 (e) bei Vorliegen einer Lizenzvereinbarung über immaterielle Vermögenswerte der Anwendungsbereich der immateriellen Vermögenswerte (IAS 38) Vorrang. Kommtjedoch das bilanzierende Unternehmen zu dem Entschluss, dass die Softwarelizenz der Cloudvereinbarung in den Anwendungsbereich des IFRS 16 fällt, so würde nach IFRS 16.4 ein Wahlrecht zur Bi­lanzierung als Leasingverhältnis bestehen.⁹⁷ Das IFRS IC hat sich in der Novembersit­zung 2019 der Beantwortung dieser Fragestellung gewidmet. Dabei soll zum einen die Lizenz-Definition des IFRS 15.B52 eine Abhilfe schaffen. Der Standard definiert eine Lizenz als ein Recht des Kunden auf Nutzung des geistigen Eigentums eines Unterneh­mens.⁹⁸ Im Cloud-Computing-Kontext müsste somit der Kunde ein Nutzungsrecht an der Software haben, um eine Lizenzvereinbarung in Form eines Softwareleasings zu bejahen und in den Anwendungsbereich des IAS 38 zu gelangen.⁹⁹ Wie aber bereits oben be­schrieben, handelt es sich bei SaaS-Vereinbarungen auf einer Public Cloud typischer­weise um bloße Zugriffsrechte auf die Software, die regelmäßig nicht das Recht umfas­sen, im Wesentlichen alle wirtschaftlichen Vorteile aus der Nutzung der Software zu zie­hen sowie Entscheidungen über die Art der Nutzung zu fällen. Der Softwareanwender gelangt deshalb ein weiteres Mal zu dem Ergebnis, dass diese dargestellte Rechnungsle­gungsmethode nicht zu dem gewünschten Resultat und zum Ansatz in der Bilanz führt.¹⁰⁰

[...]

---

¹ Vgl. im Internet: Gartner (2020a).

² Vgl. SAP (2021), S. 137.

³ Vgl. Missbach et al. (2016), S. 9.

⁴ Vgl. Rittinghouse/Ransome (2010), S. xxvi.

⁵ Vgl. Hentschel/Leyh (2018), S. 12.

⁶ Vgl. im Internet: IONOS (2021).

⁷ Vgl. Hentschel/Leyh (2018), S. 12.

⁸ Vgl. Dempsey/Kelliher (2018), S.9f.

⁹ Vgl. im Internet: Garfinkei (2011); Rittinghouse/Ransome (2010), S. xxvi.

¹⁰ Vgl. Decker (2019), S. 10; Missbach et al. (2016), S. 10.

¹¹ Vgl. Rittinghouse/Ransome (2010), S. xxvi.

¹² Vgl. Missbachetal. (2016), S. 10.

¹³ Vgl. Rittinghouse/Ransome (2010), S. xxvi.

¹⁴ Vgl. im Internet: Hofmann (2011).

¹⁵ Vgl. Huber (2016), S. 63.

¹⁶ Vgl. im Internet: Gartner (2020b); im Internet: Brandt (2020).

¹⁷ Vgl. Chellappa (1997), S. 26 ff.

¹⁸ Vgl. Hentschel/Leyh (2018), S. 4.

¹⁹ Vgl. im Internet: Duden (2021).

²⁰ Vgl. Armbruster et al. (2010), S.51.

²¹ Vgl. Baunetal. (2011), S. 4; Rittinghouse/Ransome (2010), S. xxvi; Armbrusteretal. (2010), S. 51; Vaquero et al. (2008), S. 50.

²² Gl.A. Fink (2019a), S. 196; Roos (2019), S. 95 f.; Hentschel/Leyh(2018), S. 5; Dempsey/Kelliher(2018), S. 11 ff.; Schneider/Sunyaev (2015), S. 5; Baunetal. (2011), S. 5 f; BITKOM (2010), S. 15.

²³ Vgl. Mell/Grance (2011), S. 2.

²⁴ Vgl. Mell/Grance (2011), S. 2.

²⁵ Vgl. Hentschel/Leyh (2018), S. 12.

²⁶ Vgl im Internet: Bigelow (2017), 1. Absatz.

²⁷ Vgl. Lenk et al. (2009), S. 23.

²⁸ Vgl. Sirtl (2010), S. 6.

²⁹ Vgl. Lindner et al. (2020), S.21.

³⁰ Vgl. Dempsey/Kelliher (2018), S. 17.

³¹ Vgl. Lindneretal. (2020), S. 10; Dempsey/Kelliher(2018), S. 15.

³² Vgl. Vaquero et al. (2008), S. 51.

³³ Vgl. Hurwitz et al. (2010), S. 19.

³⁴ Vgl. Fink (2019a), S. 197.

³⁵ Vgl. Mell/Grance (2011), S. 3.

³⁶ Vgl. Hentschel/Leyh (2018), S. 10.

³⁷ Vgl. Repschläger et al. (2010), S. 9.

³⁸ Vgl. Kranawetter (2018), S. 433 f.; Baun et al. (2011), S. 35.

³⁹ Vgl. Hentschel/Leyh (2018), S. 10.

⁴⁰ Vgl. Hurwitz et al. (2010), S. 20.

⁴¹ Vgl. BITKOM (2010), S. 16.

⁴² Vgl.Roos (2019), S. 96.

⁴³ Vgl. Xue/Xin (2016), S. 3.

⁴⁴ Vgl. Buxmann et al. (2008), S. 500; Fink (2019a), S. 197.

⁴⁵ Vgl. Mell/Grance (2011), S. 2.

⁴⁶ Vgl. Buxmann et al. (2008), S. 500.

⁴⁷ Vgl. Rittinghouse/Ransome (2010), S. 51.

⁴⁸ Vgl. Schneider/Sunyaev (2015), S. 7.

⁴⁹ Vgl. Fink (2019a), S. 197.

⁵⁰ Vgl. Hentschel/Leyh (2018), S. 11.

⁵¹ Vgl. Repschläger et al. (2010), S. 12.

⁵² Vgl. Missbach et al. (2016), S. 7; Mell/Grance (2011), S. 3.

⁵³ Vgl. Furht (2010), S. 7.

⁵⁴ Vgl. Lindner et al. (2020), S. 38.

⁵⁵ Vgl. Hentschel/Leyh (2018), S. 8.

⁵⁶ Vgl. hierzu Gonzalez et al. (2012), S. 1 ff.

⁵⁷ Vgl. Mell/Grance (2011), S. 3.

⁵⁸ Vgl. Hentschel/Leyh (2018), S. 8.

⁵⁹ Vgl. Mell/Grance (2011), S. 3.

⁶⁰ Vgl.Roos (2019), S. 96.

⁶¹ Vgl. Lissenetal. (2014), S. 20.

⁶² Vgl. Münzl et al. (2015), S. 17.

⁶³ Vgl. Hentschel/Leyh (2018), S. 15; Vehlow/Thier (2015), S. 28.

⁶⁴ Vgl. Xue/Xin (2016), S. 5; Vehlow/Thier (2015), S. 28; Giebichenstein (2011), S. 2218; Repschläger et al. (2010), S. 14.

⁶⁵ Vgl. Hentschel/Leyh (2018), S. 15.

⁶⁶ Vgl. Vehlow/Thier (2015), S. 28.

⁶⁷ Vgl. Vehlow/Thier (2015), S. 28.

⁶⁸ Vgl. Fink (2019a), S. 197; Xue/Xin (2016), S. 7; Münzl et al. (2015), S. 19; Repschläger et al. (2010), S. 14.

⁶⁹ Vgl. Hentschel/Leyh (2018), S. 15; Missbach et al. (2016), S. 3.

⁷⁰ Vgl. Hurwitz et al. (2010), S. 15.

⁷¹ Vgl. Xue/Xin (2016), S. 7.

⁷² Vgl. Hentschel/Leyh (2018), S. 16; Münzl et al. (2015), S. 19; Vehlow/Thier (2015), S. 28.

⁷³ Vgl. Münzl et al. (2015), S. 19.

⁷⁴ Vgl. Xue/Xin (2016), S. 7.

⁷⁵ Vgl. Burg/Klüber/Langenbrink/Pott, S. 126.

⁷⁶ Vgl. Fink (2019a), S. 197; Münzl et al. (2015), S. 20.

⁷⁷ Vgl. Sirtl (2010), S. 7.

⁷⁸ Vgl. Baun et al. (2011), S. 74.

⁷⁹ Vgl. Baun et al. (2011), S. 74; Oliveira/Pfreundt (2010), S. 2.

⁸⁰ Vgl. Fink (2019a), S. 197; Schneider/Sunyaev (2015), S. 11.

⁸¹ Vgl. Szer (2013), S. 78.

⁸² Vgl. Fink (2019a), S. 197; IFRS IC (2019), S. 2.

⁸³ Vgl. IFRS IC (2018a), S. 8 ff.

⁸⁴ Vgl. Berger/Fischer (2018), S. 2288 f.

⁸⁵ Vgl. Roos (2019), S. 99.

⁸⁶ Vgl. im Internet: Gartner (2020a): bezogen auf die Prognosen der weltweiten Ausgaben für SaaS­Dienste für Endanwender.

⁸⁷ Vgl. IFRS IC (2019), S.llf.

⁸⁸ Vgl. Baetge/Kirsch/Thiele (2019), S. 659.

⁸⁹ Vgl. Lüdenbach/Hoffmann/Freiberg (2019), § 15a, Rz. 45.

⁹⁰ Vgl. Pellens/Fülbier/Gassen/Sellhom (2017), S. 781.

⁹¹ Vgl. Fink (2019a), S. 198.

⁹² Vgl. im Internet: Golla (2020).

⁹³ Vgl. IFRS IC (2019), S. 12.

⁹⁴ Vgl. Roos (2019), S. 98; Berger/Fischer (2018), S. 2289.

⁹⁵ Vgl. Freiberg (2018), S. 304; im Internet: Mujkanovic (2020), 4. Absatz.

⁹⁶ Vgl. Roos (2019), S. 97.

⁹⁷ Vgl. im Internet: EY (2020), S. 13.

⁹⁸ Vgl. IFRS IC (2018b), S. 8 f.

⁹⁹ "Vgl. Fink (2019a), S. 198.

¹⁰⁰ Vgl. Fink (2019a), S. 198.

• Universidad: Wiesbaden University of Applied Sciences (Wiesbaden Business School)
• Curso: Business & Law (in Accounting and Taxation)
• Calificación: 1.7
• Autor: Ruben Fernandes (Autor)
• Año de publicación: 2021
• Páginas: 75
• No. de catálogo: V1032027
• ISBN (Ebook): 9783346419545
• ISBN (Libro): 9783346419552
• Idioma: Alemán
• Etiqueta: Cloud Computing, IFRS, Software as a Service, Platform as a Service, infrastructure as a Service, Everything as a Service, SaaS, PaaS, IaaS, XaaS, Softwareleasing IFRS 16, Immaterieller Vermögenswert IAS 38, Dauerschuldverhältnis IFRS, Implementierungskosten, IFRS IC, S/4HANA, SAP, AWS, Azure, Public Cloud, Private Cloud, Hybride Cloud, Abschlusspolitik, Abschlussanalyse