Thema dieser Bachelorarbeit ist eine kritische Analyse der Bilanzierung von Implementierungskosten und Customizing-Aufwänden aus handelsrechtlicher Sicht und aus Sicht der IFRS. Durch die im Unternehmensalltag voranschreitende Digitalisierung, wird auch das Cloud Computing immer präsenter. Software as a Service als eine Form des Cloud Computing stellt Unternehmen über das Internet den Zugriff auf eine Anwendung zur Verfügung. Da diese Anwendungen nicht dediziert für ein Unternehmen entwickelt wurden, basieren diese auf allgemeinen Best-Practices. Dies kann dazu führen, dass Unternehmensspezifische Anforderungen zusätzlich in die Anwendung implementiert werden müssen. Dies geschieht im Rahmen von Implementierungs- und Customizing Projekten. Diese Projekte verursachen häufig hohe Kosten und Aufwände. Wie die entstehenden Kosten zu bilanzieren sind, entscheidet sich unter anderem danach ob ein immaterieller Vermögensgegenstand für das anwendende Unternehmen durch den Software-as-a-Service-Vertrag entsteht, ob das Produkt des Customizings das Entstehen eines immateriellen Vermögensgegenstandes begründet oder ob die entstehenden Aufwände, da keiner der beiden genannten Umstände eintritt, lediglich als Aufwand in der Gewinn- und Verlustrechnung verbucht werden können. In der Praxis kann es hierbei zu Transferleistungen aus eigentlich artfremden Themen wie der Zurechnung eines Customizings als sogenannte Mietereinbaute bzw. dem Ausweichen auf einen anderen Standardsetter kommen.
Die Arbeit basiert auf der kritischen Betrachtung der aktuellen Gesetzeslage, Grundsatzentscheidungen des International Financial Reporting Standards Interpretations Committee und einer Analyse einschlägiger Fachliteratur.
Inhaltsverzeichnis
Abstract
Inhaltsverzeichnis
Abbildungsverzeichnis
Abkürzungsverzeichnis
1 Einleitung
2 Grundlagen
2.1 Cloud-Computing
2.2 Software
2.3 Software as a Service
2.3.1 Definition
2.3.2 Abgrenzung
2.3.3 Implementierung
2.3.4 Customizing
2.4 Bilanzierung
2.4.1 Grundlagen Bilanzierung IFRS
2.4.2 Grundlagen Bilanzierung nach HGB
2.4.3 Immaterieller Vermögensgegenstand und immaterielle Vermögenswerte
3 Bilanzielle Würdigung von Software as a Service
3.1 Software as a Service im Kontext der IFRS
3.1.1 Generelle Betrachtung Software as a Service nach IFRS
3.1.2 Immaterieller Vermögenswert nach dem IAS 38
3.1.3 Leasing nach dem IFRS 16
3.1.4 Dienstleistungsvertrag
3.2 Software as a Service im Kontext des HGB
3.2.1 Generelle Betrachtung Software as a Service nach Handelsrecht
3.2.2 Identifizierung von Software-as-a-Service-Vertragstypen
3.2.3 Immaterieller Vermögensgegenstand nach dem HGB
4 Analyse der Bilanzierung im Einzelfall
4.1 IFRS
4.1.1 Aktivierung von Implementierungskosten- und Customizing-Aufwänden
4.1.2 Bilanzierung der Höhe nach
4.2 HGB
4.2.1 Aktivierung von Implementierungskosten und Customizing-Aufwänden
4.2.2 Bilanzierung der Höhe nach
5 Fazit
Literaturverzeichnis
Abstract
Thema dieser Bachelorarbeit ist eine kritische Analyse der Bilanzierung von Implementierungskosten und Customizing-Aufwänden aus handelsrechtlicher Sicht und aus Sicht der IFRS. Durch die im Unternehmensalltag voranschreitende Digitalisierung, wird auch das Cloud Computing immer präsenter. Software as a Service als eine Form des Cloud Computing stellt Unternehmen über das Internet den Zugriff auf eine Anwendung zur Verfügung. Da diese Anwendungen nicht dediziert für ein Unternehmen entwickelt wurden, basieren diese auf allgemeinen Best-Practices. Dies kann dazu führen, dass Unternehmensspezifische Anforderungen zusätzlich in die Anwendung implementiert werden müssen. Dies geschieht im Rahmen von Implementierungs- und Customizing Projekten. Diese Projekte verursachen häufig hohe Kosten und Aufwände. Wie die entstehenden Kosten zu bilanzieren sind, entscheidet sich unter anderem danach ob ein immaterieller Vermögensgegenstand für das anwendende Unternehmen durch den Software-as-a-Service-Vertrag entsteht, ob das Produkt des Customizings das Entstehen eines immateriellen Vermögensgegenstandes begründet oder ob die entstehenden Aufwände, da keiner der beiden genannten Umstände eintritt, lediglich als Aufwand in der Gewinn- und Verlustrechnung verbucht werden können. In der Praxis kann es hierbei zu Transferleistungen aus eigentlich artfremden Themen wie der Zurechnung eines Customizings als sogenannte Mietereinbaute bzw. dem Ausweichen auf einen anderen Standardsetter kommen.
Die Arbeit basiert auf der kritischen Betrachtung der aktuellen Gesetzeslage, Grundsatzentscheidungen des International Financial Reporting Standards Interpretations Committee und einer Analyse einschlägiger Fachliteratur.
Schlüsselwörter: Cloud-Computing, Software as a Service, Bilanzierung, immaterieller Vermögensgegenstand, IFRS, HGB, Customizing
Abbildungsverzeichnis
Abb. 1: Cloud-Modelle
Abb. 2: Klassifizierung von Software
Abb. 3: Pizza as a Service
Abb. 4: Vertragsarten im Software-as-a-Service-Kontext
Abb. 5: Dokumentation Ansatzkriterien
Abb. 6: Kosten Entwicklungsprozess immaterieller Vermögenswert
Abb. 7: Customizing als immaterieller Vermögenswert
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Als ein Schlagwort im Bereich des Fortschritts und der Technologie wird in den letzten Jahren immer wieder die Digitalisierung genannt (Fink & Kunath, 2019, S. 17). Diese ist allerdings nicht nur ein Schlagwort, sondern auch eines der bedeutsamsten Instrumente und ein strategisches Thema von Unternehmen sowie Unternehmensführungen (Becker et al., 2019, S. 41; Frank et al., 2019, S. 16). Auch wenn der Begriff der Digitalisierung nicht normiert ist (Becker et al., 2019, S. 10), herrscht Konsens darüber, dass das Cloud-Computing ein elementarer Bestandteil der Digitalisierung ist (Frank et al., 2019, S. 278). Kaum ein Thema beeinflusst die Arbeitswelt so nachhaltig wie jenes der Digitalisierung (Wolff & Göbel, 2018, S. 13), wovon allerdings nicht nur direkt beteiligte Fachbereiche wie die IT-Abteilung eines Unternehmens betroffen sind (Wolff & Göbel, 2018, S. 4). Auch solche, die nicht unmittelbar der Digitalisierung unterliegen, sehen sich mit neuen Herausforderungen und Fragestellungen konfrontiert (Fink & Kunath, 2019, S. 117). Neben den großen technischen Herausforderungen, die durch den vermehrten Einsatz von Cloud-Technologien entstehen (Frank et al., 2019, S. 230), ergeben sich auch neue Fragestellungen für den Bereich des Finanz- und Rechnungswesens, z.B. wie mit Cloud-Angeboten aus bilanzieller Sicht umzugehen ist. So kennt z. B. das Handelsgesetzbuch (HGB) in Verbindung mit dem Deutschen Rechnungslegungsstandard 24 (DRS) und den Grundsätzen ordnungsgemäßer Buchführung (GoB) die Begriffe ‚Cloud‘ oder ‚Service‘ nicht. Trotzdem müssen diese selbstverständlich, wie alle Geschäftsvorfälle, bilanziell berücksichtigt werden.
Die Implementierung von Cloud-Services stellt oftmals ganze Unternehmen vor große Schwierigkeiten, da es sich hierbei anders als in der Vergangenheit nicht um die bloße Einführung eines neuen Produktes handelt. Denn häufig muss ein Paradigmenwechsel im Hinblick auf den Umgang mit der IT und den dazugehörigen Prozessen stattfinden. Was früher in der Kontrolle des nutzenden Unternehmens war, liegt bei Cloud-Technologien teilweise oder vollständig in der Verantwortung eines Dritten, des Anbieters der Cloud-Plattform (Brassel & Gadatsch, 2020, S. 952; Hentschel & Leyh, 2018, S. 14–17). Durch die Cloud sind z. B. im Software-as-a-Service-Kontext hoch standardisierte nach Best-Practice-Erfahrungen entwickelte Services verfügbar. Dies ermöglicht zum einen zwar eine meist schnellere und häufig kostengünstigere Bereitstellung von Services, erfordert aber zum anderen oftmals ein Anpassen der unternehmensinternen Prozesse (Bär & Krug, 2018, S. 44–45). In vielen Fällen ist dieser Paradigmenwechsel technologisch unproblematischer als die hiermit verbundene psychologische Komponente, die häufig im Rahmen von sogenannten „Management-of-Change-Projekten“ begleitet wird (Ziebell et al., 2018, S. 128). Es gibt allerdings auch technische oder prozessuale Anforderungen, die nicht im Standard von Cloud-Anwendungen abgebildet sind. Hierbei kann es sich um technische Herausforderungen wie eine fehlende Programmschnittstelle, eine nicht verfügbare erforderliche Funktionalität der Anwendung oder die notwendige programmseitige Abbildung eines Prozesses handeln (Wei Sun et al., 2008, S. 18).
Obwohl Software-as-a-Service-Anwendungen häufig nicht alle Anforderungen des Kunden abdecken, kann es trotzdem sinnvoll oder zwingend notwendig sein, auf sie zurückzugreifen. Ein Grund hierfür kann neben einer zu geringen eigenen Fertigungstiefe der Unternehmen sein, dass bestimmte Anwendungen nur aus der Cloud beziehbar sind. Um die Software-as-a-Service-Anwendung dennoch nutzen zu können, ist es dann nötig, dass im Rahmen der Implementierung begleitende Maßnahmen die ein Anpassen, das sogenannte Customizing, der Software-as-a-Service-Anwendung an die vom Unternehmen definierten Anforderungen mit sich bringen. Durch dieses Customizing sehen sich Unternehmen häufig mit einem hohen planerischen und technischen Aufwand für die Umsetzung konfrontiert, der oftmals zu hohen Kosten führt (Heyd et al., 2019, S. 3; Wei Sun et al., 2008, S. 18–19). Da Customizing-Aufwände und Implementierungskosten inzwischen häufig bei der Einführung einer Software-as-a-Service-Anwendung entstehen, streben es viele Unternehmen an, diese Kosten nach Möglichkeit nicht nur als reinen Aufwand in der Gewinn- und Verlustrechnung zu verbuchen (Deubert & Lewe, 2019, S. 813–815). Stattdessen sollen sie so erfasst werden, wie sie vom Unternehmen im Alltag wahrgenommen werden, nämlich dass es sich beim Ergebnis des Customizings um ein eigenes bilanzielles Wirtschaftsgut, also einen immateriellen Vermögenswert nach den International Financial Reporting Standards (IFRS) bzw. handelsrechtlich um einen immateriellen Vermögensgegenstand handelt.
Den Schwerpunkt dieser Arbeit bildet die bilanzielle Betrachtung von Implementierungskosten und Customizing-Aufwänden sowohl aus handelsrechtlicher als auch aus IFRS-Sicht. Hierfür sind zunächst die vertraglichen Grundlagen eines Software-as-a-Service-Modells und mögliche unterschiedliche bilanzielle Betrachtungsweisen im Hinblick auf die Behandlung der erwähnten Kosten, die sich hieraus je nach Bilanzierungsansatz ergeben können, zu prüfen.
Diese Bachelorarbeit basiert auf einer qualitativen Literaturrecherche, durch die eine objektive Beurteilung sichergestellt werden kann. Die Recherche erfolgte in Form von Fachbüchern zu den Themen ‚Bilanzierung‘‚ Cloud-Computing‘ sowie ‚Digitalisierung‘ und von Veröffentlichungen des IFRS-Komitees.
In Kapitel 2 wird zunächst ein einheitliches Verständnis der grundlegenden Termini ‚Cloud-Computing‘ und ‚Bilanzierung‘ geschaffen. Auch werden diese jeweils abgegrenzt. Dies ist notwendig, um zu verstehen, wie die in Kapitel 3 beschriebenen Themen und Problemstellungen im Hinblick auf die bilanzielle Würdigung von Software-as-a-Service-Angeboten nach den IFRS und dem HGB sowie die jeweiligen Unterscheidungen in der Bilanzierung als Leasing, immaterieller Vermögensgegenstand bzw. Dauerschuldverhältnis entstehen. In Kapitel 4 wird anhand der getroffenen bilanziellen Einordnungen die Bilanzierung von Implementierungs- und Customizing-Aufwänden für die IFRS und das HGB analysiert und anhand eines Beispiels verdeutlicht. In Kapitel 5 werden im Rahmen des Fazits die in dieser Arbeit getroffenen Feststellungen zusammengefasst und Handlungsempfehlungen bzw. zukünftige Herausforderungen aufgezeigt.
2 Grundlagen
In diesem Kapitel sollen die Grundlagen zu den einzelnen technischen Themen ‚Cloud-Computing‘ sowie ‚Software‘ im Allgemeinen und ‚Software as a Service‘ im Speziellen erklärt werden. Des Weiteren werden die kaufmännischen Grundlagen zum Thema ‚Bilanzierung‘ generell und spezielle Ausprägungen in den IFRS und dem HGB in der Bilanzierung erläutert.
2.1 Cloud-Computing
Die Nutzung von Cloud-Diensten ist in Deutschland weitverbreitet. Nach Untersuchungen des Statistischen Bundesamtes verwendet ca. jedes dritte Unternehmen in Deutschland Cloud-Dienste;1 somit ist deren Einsatz inzwischen keine Ausnahme mehr im Unternehmensalltag. Trotz dieses hohen Nutzungsgrades ist der Begriff ‚Cloud‘ bzw. ‚Cloud-Computing‘ nicht normiert, es gibt stattdessen eine Vielzahl von Definitionen (Frank et al., 2019, S. 98; Lisdorf, 2021, S. 4–6). In der Fachwelt hat sich allerdings die Definition des National Institute of Standards and Technology (NIST) durchgesetzt, nach der das Cloud-Computing ein Modell ist, mit dem ein flexibler und bedarfsorientierter Zugriff auf einen gemeinsam genutzten Pool konfigurierbarer IT-Ressourcen über das Internet zur Verfügung gestellt wird (Krcmar et al., 2018, S. 8). Generell lässt sich der Begriff des Cloud-Computings in drei Betreibermodelle unterteilen (Hentschel & Leyh, 2018, S. 7–8):
1. Public Cloud
2. Private Cloud
3. Hybrid Cloud
Die Public Cloud ist durch die gemeinsame Nutzung derselben externen IT-Ressourcen durch mehrere Anwendenden charakterisiert, z. B. der Basisinfrastruktur wie der Prozessoren, des Arbeitsspeichers oder der Festplattenspeicher eines IT-Service-Providers, beispielweise von Microsoft oder Amazon. Im Fall der Nutzung einer Public Cloud profitiert das einsetzende Unternehmen aufgrund der Vermeidung der eigenen IT-Infrastruktur von einer Kostenersparnis, allerdings hat er keinen Einfluss auf die zugrunde liegenden Prozesse bzw. die verwendeten Infrastrukturkomponenten (Brassel & Gadatsch, 2020, S. 950). Dieser Nachteil erweist sich für das Betreiben sicherheitskritischer Anwendungen als problematisch, weswegen in einem solchen Fall die Nutzung einer Private Cloud eine Alternative sein kann (Hentschel & Leyh, 2018, S. 8). Eine solche ist dadurch gekennzeichnet, dass lediglich ein definierter Kreis von Anwendenden Zugriff auf die eigene IT-Infrastruktur bzw. die Prozesse und Anwendungen hat. Der Zugriff auf eine Private Cloud erfolgt für gewöhnlich über das Intranet bzw. eine VPN-Verbindung. Die Vorteile einer höheren Sicherheit und Kontrolle bedingen jedoch einen Nachteil der Private Cloud: Durch den Einsatz der eigenen IT-Infrastruktur kann nicht so flexibel auf Lastspitzen reagiert werden wie beim Einsatz einer Public-Cloud-Lösung. Denn IT-Ressourcen wie Prozessoren und Arbeitsspeicher sind nur begrenzt vorhanden (Hentschel & Leyh, 2018, S. 8).
Die Stärken der Public Cloud als flexible und skalierbare sowie der Private Cloud als sichere und unternehmensspezifische Lösung beinhaltet die Hybrid Cloud. Als eine Mischung aus Public und Private Cloud bietet sie die Vorteile beider, wobei viele der jeweiligen Nachteile eliminiert werden. Betrieben wird eine Hybrid Cloud wie eine Private Cloud, allerdings werden definierte IT-Workloads bei Lastspitzen in die Public Cloud verlagert und dort bearbeitet. Durch den hohen Implementierungsaufwand sowohl im Hinblick auf Sicherheitsaspekte als auch auf die Serviceintegration eines Hybrid-Cloud-Ansatzes werden vor allem nicht kritische Geschäftsprozesse in einem Hybrid-Szenario abgebildet (Hentschel & Leyh, 2018, S. 8).
Zusammenfassend kann die Definition des Fraunhofer-Instituts (2019) zur Unterscheidung von Public- und Private-Cloud-Angeboten genutzt werden, wonach eine Public Cloud von einem frei zugänglichen Service-Provider angeboten wird. Hingegen ist eine Private Cloud nur den vom Unternehmen ausgewählten Mitarbeitenden zugänglich. Ob eine Private Cloud durch das Unternehmen selbst bzw. von einem beauftragten Service-Provider betrieben wird, ist hierfür unbedeutend (Hentschel & Leyh, 2018, S. 8) Zur Verdeutlichung der einzelnen Charakteristika siehe Abb.1.
Abb. 1: Cloud-Modelle
Abbildung in dieser Leseprobe nicht enthalten
Quelle: eigene Darstellung
2.2 Software
Auch wenn es keine einheitliche normierte Definition von Software gibt, lässt sich eine Definition durch eine klare Abgrenzung zur Hardware vornehmen. Bei Hardware handelt es sich um sämtliche greifbare Objekte, z. B. die Tastatur oder die Festplatte einer Datenverarbeitungsanlage wie eines Notebooks oder eines Servers. Im Gegensatz hierzu bildet Software die nicht greifbaren Objekte einer Datenverarbeitungsanlage ab, z. B. das Betriebssystem. Mit ihr werden Benutzerprobleme wie das Verfassen von Texten mittels Microsoft Word gelöst. Software ist also jede nicht greifbare Komponente, durch die unter Zuhilfenahme von Hardware Benutzerprobleme behoben werden (Ludewig & Lichter, 2013, S. 34–35).
Software wird zur bilanziellen Behandlung regelmäßig in die folgenden drei funktionalen Arten unterschieden: Firmware, Systemsoftware und Anwendungssoftware (Fink & Kunath, 2019, S. 118; Heyd et al., 2019, S. 2).
Unter Firmware wird Software verstanden, die fest mit dem elektronischen Gerät verbunden ist, sodass sie sich diesem zuordnen lässt, z. B. das BIOS eines Notebooks. Aufgrund der Unselbstständigkeit wird Firmware als Teil der Hardware aktiviert und wird im Rahmen dieser Arbeit nicht betrachtet. Mit Systemsoftware wird die grundsätzliche Betriebsbereitschaft der Hardware hergestellt, z. B. durch ein Betriebssystem wie Windows. Bei Anwendungssoftware handelt es sich um Programme, die Benutzerprobleme lösen bzw. Benutzer unterstützen sollen, aber nicht systemseitig erforderlich sind. Anwendungssoftware wird in Individual- und Standardsoftware unterschieden, wobei anhand ersterer ein spezifisches Benutzerproblem gelöst wird, beispielweise anhand der konkret für das Unternehmen erstellten Lagerverwaltungssoftware. Im Gegensatz hierzu werden mit Standardsoftware Probleme behoben, die bei einer Vielzahl von Usern auftreten und nicht speziell für ein Benutzerproblem entwickelt wurde, z. B. Microsoft Word (Heyd et al., 2019, S. 2–3). Zur Veranschaulichung der Ausführungen siehe Abb. 2
Abb. 2: Klassifizierung von Software
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung in Anlehnung an: Heyd et al., 2019, S. 3
2.3 Software as a Service
Im folgenden Kapitel wird erläutert worum es sich bei Software as a Service handelt und wie sich diese von anderen Cloud-as-a-Service-Geschäftsmodellen abgrenzt.
2.3.1 Definition
Das generelle As-a-Service-Geschäftsmodell bedeutet, dass ein Kunde von seinem Lieferanten keine Produkte mehr kauft, sondern diese als Gesamtprodukt für eine bestimmte Laufzeit, häufig in Verbindung mit Services, z. B. mietet. Auch wenn dieses Geschäftsmodell in der jüngeren Vergangenheit vor allem durch den IT-Service bekannter geworden ist, handelt es sich hierbei um kein neues (Seebacher, 2021, S. 2). Es wurde bereits in den Siebzigerjahren durch Rolls-Royce für die leistungsbezogene Abrechnung von Turbinen genutzt, das sogenannte Pay-per-Use (Seebacher, 2021, S. 25). Die Vorteile des As-a-Service-Geschäftsmodells bestehen für das nutzende Unternehmen vor allem aus einem optimierten Cashflow und einer höheren Flexibilität in der Auslastungssteuerung. Allerdings profitiert auch das bereitstellende Unternehmen von den konstanten Geldflüssen mit einer planbareren Umsatz- und Erlösprognose (Seebacher, 2021, S. 9–10).
Als Abstraktionsebene zur Einteilung von Cloud-Angeboten hat sich das Everything-as-a-Service-Paradigma durchgesetzt (Hentschel & Leyh, 2018, S. 9–10). Die Abstraktion nach Servicemodellen erfolgt auf diesen Ebenen:
1. Infrastructure as a Service
2. Platform as a Service
3. Software as a Service
Die oberste Abstraktionsebene bildet das Servicemodell ‚Software as a Service‘. In diesem erfolgt die standardisierte und automatisierte Bereitstellung von Anwendungen. Hierbei wird die Anwendung für den Endnutzer über das Internet verfügbar gemacht, wodurch die lokale Installation einer Software entfällt. Auf diese Weise wird ein Teil der notwendigen Rechenkapazitäten der lokalen Endgeräte, z. B. von Notebooks, in die Cloud des Service-Providers verlagert. Bekannte Beispiele hierfür sind die Microsoft-365-Produktpalette und Salesforce (Hentschel & Leyh, 2018, S. 11). Durch die standardisierte Bereitstellung sind die Integrations- und die Customizing-Möglichkeiten der genutzten Anwendung häufig eingeschränkt, weswegen meistens hoch standardisierbare Prozesse im Rahmen eines Software-as-a-Service-Modells abgebildet werden.
2.3.2 Abgrenzung
Als oberste Abstraktionsebene lässt sich Software as a Service vor allem durch die vom Cloud-Provider bereitgestellten und verwalteten Komponenten abgrenzen. Während im Rahmen eines Software-as-a-Service-Konzeptes für gewöhnlich alle Komponenten vom Anbieter dargeboten werden, werden im Gegensatz hierzu bei einem Infrastructure-as-a-Service-Modell lediglich die Basisinfrastruktur wie die Rechenleistung und der Festplattenspeicher durch den Anbieter zur Verfügung gestellt. Diese Ressourcen können vom Kunden für die Installation und den Betrieb seiner Anwendungen genutzt werden (Krcmar et al., 2018, S. 9–10). Hierbei erfolgen nur der Betrieb, die Verwaltung und die Wartung der eingesetzten Infrastruktur durch den Anbieter. Für den Betrieb der Anwendung und z. B. die Anwendungsverwaltung ist das nutzende Unternehmen verantwortlich (Hentschel & Leyh, 2018, S. 10).
Die mittlere Abstraktionsschicht ‚Platform as a Service‘ ist eng am Software-as-a-Service-Modell ausgerichtet, allerdings wird hier eine Plattform zum Entwickeln, Testen sowie Ausführen und keine fertige Software zur Verfügung gestellt (Hentschel & Leyh, 2018, S. 10; Lisdorf, 2021, S. 8). Diese Plattform wird in Form von Programming- und Execution-Environments angeboten, in denen Software in verschiedenen Programmiersprachen entwickelt werden kann. Die Unterscheidung wird in Abb. 3 unter Zuhilfenahme eines ‚Pizza-as-a-Service‘-Modells verdeutlicht:
Abb. 3: Pizza as a Service
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung in Anlehnung an: Barron, 2014
Eigene Infrastruktur: Der Kunde kauft selbstständig alle Zutaten und Getränke ein, bereitet die Pizza zu Hause in seiner eigenen Küche zu und serviert diese an seinem eigenen Esstisch.
Infrastructure as a Service: Der Kunde kauft im Supermarkt eine Tiefkühlpizza. Deren Zutaten sind in diesem Fall bereits enthalten, sodass der Kunde die Pizza im eigenen Ofen nur erwärmen muss. Die Getränke zur Pizza sowie den Esstisch, an dem diese serviert wird, stellt der Kunde bereit.
Platform as a Service: Dem Kunden wird die Pizza durch einen Lieferdienst nach Hause geliefert. Sie ist vollständig erwärmt und belegt, sodass der Kunde lediglich die Getränke zur Pizza und den Esstisch organisieren muss.
Software as a Service: Der Kunde geht in ein Restaurant, wo ihm die vollständig belegte und erwärmte Pizza am Tisch mit Getränken serviert wird. Alle Komponenten werden durch das Restaurant zur Verfügung gestellt.
Das oben genannte Beispiel verdeutlicht, dass der Kunde auf allen Abstraktionsebenen eine Pizza erhält. Allerdings je höher er im Abstraktionsmodell kommt, er jeweils weniger Beistellleistungen für das Endergebnis Pizza hat.
2.3.3 Implementierung
Auch wenn Software-as-a-Service-Modelle nicht durch den Kunden, sondern durch einen Cloud-Anbieter zur Verfügung gestellt werden, womit die zugrunde liegende Technologie nicht in der Verantwortung des Kunden liegt, muss dieser die sichere und funktionale Implementierung der Lösung in die eigene IT-Umgebung gewährleisten (Hentschel & Leyh, 2018, S. 11). Dieser Implementierungsprozess fängt bereits bei der Auswahl des richtigen Tools an und endet mit einer technischen und organisatorischen Implementierung (Brassel & Gadatsch, 2019, S. 91–93). Er kann trotz der standardisierten Software zu hohen Aufwänden und zu dementsprechend hohen Kosten aufseiten des Kunden führen, da unter anderem Aufwendungen für Testläufe, Datenmigrationen bzw. das Aufbereiten von Daten und Schulungen entstehen können (EY, 2021, S. 13).
2.3.4 Customizing
Wie bei der Implementierung einer Software-as-a-Service-Lösung kann es für den Kunden notwendig sein, die ausgewählte Lösung z. B. an die eigenen Prozesse und den eigenen Bedarf anzupassen. Letzterer entsteht häufig daraus, dass eine Software-as-a-Service-Lösung genutzt wird, um eine vorhandene Lösung zu ersetzen, oder eine Software-as-a-Service-Anwendung ein Update bzw. ein Upgrade benötigt (Brassel & Gadatsch, 2019, S. 91–92; Lisdorf, 2021, S. 159). Durch die Ablösung historischer Anwendungen, die über den Einsatzzeitraum häufig wiederholt an die Unternehmensanforderungen angepasst wurden, ergibt sich nach positiver Prüfung der zukünftigen Notwendigkeit des Customizings ein Bedarf, diese Funktionalität wie z.B. ein umfangreicheres Stammdatenmanagement in einer ERP (Enterprise Ressource Planning) Software – auch wenn nicht nativ vorhanden – in der Software-as-a-Service-Anwendung abzubilden. Beispielhaft kann hier die Umstellung einer Human-Resources-Anwendung genannt werden (Brassel & Gadatsch, 2019, S. 92). An einer solchen wie SAP HCM werden häufig unternehmensspezifische Anpassungen vorgenommen, die nach dem Wechsel zu einer Software-as-a-Service-Anwendung erhalten bleiben müssen. Sie sind aber aufgrund der hohen Standardisierung von Software-as-a-Service-Angeboten nicht im Standard enthalten und dementsprechend vom Kunden selbst zu implementieren (Reinheimer, 2018, S. 121).
Customizing kann nicht nur während der initialen Implementierung notwendig sein, sondern auch im weiteren Lebenszyklus einer Software-as-a-Service-Anwendung. Hier wird für gewöhnlich zwischen der Implementierungs- und der Betriebsphase unterschieden (Zach & Munkvold, 2012, 469). In der Implementierungsphase wird die Anwendung in die Infrastruktur des Unternehmens integriert und hier findet das hierfür notwendige Customizing statt. In der Betriebsphase, die sich an die Implementierungsphase anschließt, findet der eigentliche Betrieb, also das tägliche Arbeiten mit der Anwendung statt. Nach der Implementierungsphase handelt es sich üblicherweise bei Änderungen an der Anwendung nicht mehr um Customizing, sondern um Wartungsarbeiten und Change-Projekte (Kurbel, 2013, S. 167). Je nach Unternehmensgröße und -anforderungen kann ein solches Customizing mehrere Jahren dauern, für das die Kosten die Lizenzkosten regelmäßig um ein Vielfaches übersteigen, weswegen immer kritisch überprüft werden sollte, ob das Ergebnis des Customizings auch zukünftig notwendig ist oder unter Umständen der zugrundliegende Bedarf bzw. Prozess angepasst werden sollte (Heyd et al., 2019, S. 3).
2.4 Bilanzierung
Eine Bilanz ist eine Stichtagsbetrachtung, aus der hervorgeht, an welchen Stellen ein Unternehmen Mittel investiert hat, sogenannte Aktiva, und woher diese Mittel stammen, sogenannte Passiva. Sie bildet neben der Gewinn- und Verlustrechnung den Hauptbestandteil eines Jahresabschlusses (Eitzen & Zimmermann, 2020, S. 1–3). Eine Bilanz kann nach nationalem Recht, also dem HGB oder nach internationalen Standards wie den IFRS erfolgen (Coenenberg et al., 2016, S. 22). Sie ergibt sich unter anderem aus dem Bilanzansatz bzw. der Bilanzierung dem Grunde nach (Coenenberg et al., 2016, S. 332) und der Bilanzbewertung bzw. der Bilanzierung der Höhe nach (Coenenberg et al., 2016, S. 338). Bei ersterer wird die allgemeine Bilanzierungsfähigkeit eines Sachverhaltes als Aktivposten, die sogenannte Aktivierungsfähigkeit, oder als Passivposten geprüft, die sogenannte Passivierungsfähigkeit (Coenenberg et al., 2016, S. 332). Gemäß § 246 Abs. 1 HGB werden alle dem Unternehmen zuzuordnenden Vermögensgegenstände wie Schulden als bilanzierungsfähig und somit bilanzierungspflichtig angesehen, sofern kein Bilanzierungsverbot z. B. gem. § 248 HGB bzw. ein Bilanzierungswahlrecht z. B. gem. § 274 Abs. 1 Satz 2 HGB besteht. Bei der Bilanzierung der Höhe nach wird, nachdem ein Vermögensgegenstand als bilanzierungsfähig identifiziert wurde, über die Höhe des bilanziellen Ansatzes entschieden. Hier wird bei der ersten Erfassung eines Vermögensgegenstandes eine Zugangsbewertung durchgeführt, die sich aus den Herstellungs- bzw. Anschaffungskosten ergibt. In den anschließenden Perioden findet eine Folgebewertung statt. Diese resultiert aus den Ausgangswerten, die am Ende einer Periode speziellen Korrekturwerten wie Abschreibungen auf Basis des sogenannten Niederst- und Höchstwertprinzips zum Zwecke der Überprüfung der Werthaltigkeit gegenübergestellt werden (Coenenberg et al., 2016, S. 338).
2.4.1 Grundlagen Bilanzierung IFRS
Die IFRS sind internationale Rechnungslegungsvorschriften, die das Ziel beinhalten, Investoren und Gläubiger mit entscheidungsnützlichen Informationen zu versorgen (Coenenberg et al., 2016, S. 475). Sie wurden aus den International Accounting Standards (IAS) entwickelt, die heute noch Bestandteil der IFRS sind. Die Intention bei der Einführung der IFRS war es, die immer weiter voranschreitende Globalisierung und Internationalisierung von Unternehmen zu berücksichtigen sowie ein einheitliches Regelwerk hochwertiger, durchsetzbarer und weltweit anerkannter Rechnungslegungsstandards, die auf klar formulierten Grundsätzen basieren, zu entwerfen (IFRS, 2020, S. 4). Inzwischen wird der IFRS-Standard an 88 Aktienmärkten und von 27 000 kapitalmarktorientierten Unternehmen genutzt (IFRS, 2018, S. 7). Auch in Deutschland finden die IFRS zunehmend Anwendung. So ist es für kapitalmarktorientierte Unternehmen gem. § 264d HGB und § 315e HGB verpflichtend, ihren Konzernabschluss nach den Normen der IFRS zu erstellen.
Das Rahmenkonzept der IFRS beruht zwar im Grundsatz auf den Rechnungslegungsprinzipien des HGB, beinhaltet allerdings andere Schwerpunkte. Die genannten entscheidungsnützlichen Informationen stehen in den IFRS im Vordergrund, wohingegen das im HGB vorherrschende Vorsichtsprinzip gem. § 252 Abs. 1 Nr. 4 HGB nur eine untergeordnete Rolle spielt (Freidank, 2019, S. 138). Die Primär- und Sekundärprinzipien der IFRS wie die erwähnte Entscheidungsrelevanz, die glaubwürdige Darstellung sowie die Vergleichbarkeit und Nachprüfbarkeit bilden das Fundament der Basisgrundsätze ‚Unternehmensfortführung‘ und ‚periodengerechte Erfolgsermittlung‘ der IFRS (Freidank, 2019, S. 138).
Die unterschiedliche Betrachtung von Vermögensgegenständen in Hinsicht auf das im HGB vorherrschende Vorsichtsprinzip zeigt sich insbesondere im IAS 1.15, laut dem sämtliche Vermögensgegenstände nach deren tatsächlichen Werten, dem sogenannten Fair-Presentation-Grundsatz abzubilden sind. Auch der Umstand, dass in den IFRS eine bestehende Spezialnorm eine Generalnorm nicht ‚verdrängt‘, ist anders als z. B. im deutschen Recht (Eitzen & Zimmermann, 2020, S. 199–201). Da die IFRS nur international relevante Bilanzierungsthemen adressieren, erlauben die IFRS gem. IAS 8.12 die Anwendung eines zusätzlichen Bilanzierungs- bzw. Rechnungslegungsstandards, des sogenannten Standardsetter, wie z.B. der United States Generally Accepted Accounting Principles (US-GAAP) (Eitzen & Zimmermann, 2020, S. 199). Voraussetzung für die Anwendung eines Standardsetters ist, dass für den fraglichen Geschäftsvorfall keine Regelungen nach den IFRS vorherrschen bzw. nach Ansicht des bilanzierenden Unternehmens keine tatsachengemäße Abbildung des Geschäftsvorfalls nach den IFRS möglich ist und dieser nicht zu in IAS 8.11 genannten Regelungen in Widerspruch steht (Jendreck, 2022, S. 70).
Im Rahmen dieser Arbeit werden aus den IFRS vor allem der Dienstleistungs- und der Leasingvertrag als Vertragstypen erarbeitet. Denn diese haben neben der Betrachtung als immaterieller Vermögenwert nach IAS 38 für die spätere bilanzielle Behandlung von Customizing-Aufwänden und Implementierungskosten die größte Relevanz.
[...]
1 Statistisches Bundesamt (2021)
- Citation du texte
- Carlo Clemens (Auteur), 2022, Bilanzierung der Kosten für die Implementierung und das Customizing bei Software as a Service Angeboten nach HGB und IFRS, Munich, GRIN Verlag, https://www.grin.com/document/1224065
-
-
-
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.