DIPLOMARBEIT Anforderungen, Potentiale und technische ... · Fachbereich Mathematik und Informatik,...

JUSTUS-LIEBIG-UNIVERSITÄT GIESSEN

Fachbereich Mathematik und Informatik, Physik und Geographie Fachgebiet Mathematik, Schwerpunkt Informatik

Institut für Informatik

Professur für Software-Engineering

DIPLOMARBEIT

Anforderungen, Potentiale und technische

Umsetzungsmöglichkeiten der elektronischen Rechnungsstellung

über das Internet unter Einsatz elektronischer Signaturen

gemäß § 14 Umsatzsteuergesetz

gestellt von: Prof. Dr. Dr. h.c. M. G. Zilahi-Szabó

vorgelegt von: Steffen Erkel

Braunfels-Tiefenbach, im Juni 2003

Inhaltsverzeichnis II

Inhaltsverzeichnis

Abbildungsverzeichnis..................................................................................................VI

Tabellenverzeichnis ...................................................................................................VIII

Abkürzungsverzeichnis ................................................................................................IX

1 Einleitung.................................................................................................................. 1

1.1 Problemstellung....................................................................................................... 1

1.2 Vorgehensweise....................................................................................................... 2

2 Geschäftsprozessmanagement................................................................................. 4

2.1 Grundlegende Begriffe ............................................................................................ 4

2.2 Das Konzept des Geschäftprozessmanagements..................................................... 7

2.3 Geschäftsprozessmodellierung................................................................................ 9

2.3.1 Einleitung......................................................................................................... 9

2.3.2 Graphenbasierte Modellierungssprachen....................................................... 10

2.4 Geschäftsprozessanalyse und -optimierung .......................................................... 12

2.4.1 Einleitung....................................................................................................... 12

2.4.2 Ablauf der Geschäftsprozessanalyse ............................................................. 13

2.4.3 Geschäftsprozessoptimierung ........................................................................ 14

3 Ereignisgesteuerte Prozessketten (EPK).............................................................. 17

3.1 Elemente und Verknüpfungen............................................................................... 17

3.2 Erweiterte Ereignisgesteuerte Prozessketten......................................................... 20

4 Die elektronische Signatur..................................................................................... 22

4.1 Aufgabe der elektronischen Signatur .................................................................... 22

4.2 Kryptographische Grundlagen .............................................................................. 23

4.3 Rechtliche Grundlagen .......................................................................................... 25

4.3.1 Einleitung....................................................................................................... 25

4.3.2 Einfache elektronische Signaturen................................................................. 25

4.3.3 Fortgeschrittene elektronische Signaturen..................................................... 26

4.3.4 Qualifizierte elektronische Signaturen........................................................... 26

4.3.5 Qualifizierte Zertifikate ................................................................................. 27

4.3.6 Sichere Signaturerstellungseinheiten............................................................. 28

4.3.7 Zertifizierungsdiensteanbieter ....................................................................... 28

Inhaltsverzeichnis III

4.3.8 Akkreditierte Zertifizierungsdiensteanbieter ................................................. 29

4.4 Das Signatur-Verfahren aus Sicht des Anwenders................................................ 30

5 Gesetzliche Rahmenbedingungen der elektronischen Rechnungsstellung ....... 34

5.1 Die Rechnung im deutschen Umsatzsteuerrecht ................................................... 34

5.1.1 Einleitung....................................................................................................... 34

5.1.2 Das Prinzip des Vorsteuerabzugs .................................................................. 35

5.1.3 Inhaltliche Anforderungen an eine Rechnung ............................................... 37

5.1.4 Rechnungen in Schriftform............................................................................ 38

5.1.5 Die elektronische Rechnung .......................................................................... 39

5.2 Zugang und Wirksamwerden elektronischer Rechnungen.................................... 40

5.3 Anforderungen der Finanzbehörden...................................................................... 41

5.3.1 Umgang und Aufbewahrung elektronischer Rechnungen ............................. 41

5.3.2 Datenzugriff durch das Finanzamt................................................................. 43

5.3.3 Anmerkungen zu den Anforderungen............................................................ 44

5.4 Internationaler Einsatz elektronischer Rechnungen .............................................. 45

6 Geschäftsprozessanalyse der papierbasierten Rechnungsstellung....................47

6.1 Funktionen und Anforderungen der Rechnungsstellung....................................... 47

6.2 Grundlagen und Ziele der Geschäftsprozessanalyse ............................................. 49

6.3 Modellierung des IST-Modells ............................................................................. 49

6.3.1 Modellgrundlagen.......................................................................................... 49

6.3.2 Prozessablauf Rechnungssteller..................................................................... 51

6.3.3 Prozessablauf Rechnungsempfänger ............................................................. 54

6.4 Prozessbewertung.................................................................................................. 57

6.5 Optimierungspotentiale durch elektronische Rechnungsstellung ......................... 57

7 Elektronischer Datenaustausch (EDI) mit EDIFACT........................................ 59

7.1 Grundlagen des elektronischen Datenaustauschs (EDI) ....................................... 59

7.2 EDI Standards........................................................................................................ 60

7.3 Die EDIFACT–Nachricht...................................................................................... 62

7.3.1 EDIFACT–Syntax–Regeln ............................................................................ 62

7.3.2 Aufbau einer EDIFACT – Übertragungsdatei ............................................... 63

7.3.3 Eine EDIFACT Beispielrechnung ................................................................. 67

7.4 Übertragungswege für EDI ................................................................................... 69

7.5 Elektronische Rechnungsübermittlung mit EDI.................................................... 70

7.6 EDI in der Praxis ................................................................................................... 71

Inhaltsverzeichnis IV

8 Elektronischer Datenaustausch über das Internet.............................................. 74

8.1 Einleitung .............................................................................................................. 74

8.2 XML-basierter Datenaustausch............................................................................. 77

8.2.1 Entwicklung und Motivation von XML ........................................................ 77

8.2.2 XML-Grundlagen .......................................................................................... 80

8.2.3 Wohlgeformte XML-Dokumente .................................................................. 83

8.2.4 Document Type Definition (DTD) ................................................................ 85

8.2.5 XML-Schemata.............................................................................................. 89

8.2.6 Präsentation von XML-Dokumenten............................................................. 92

8.2.7 Elektronische Signaturen mit XML............................................................... 94

8.3 EDI mit XML (XML/EDI).................................................................................... 96

8.3.1 Vorteile von XML ......................................................................................... 96

8.3.2 XML/EDI-Standardisierung .......................................................................... 98

8.4 Fazit ..................................................................................................................... 101

9 Electronic Billing mit elektronischen Signaturen ............................................. 103

9.1 Einleitung ............................................................................................................ 103

9.2 eBilling-Modelle ................................................................................................. 104

9.2.1 Direktes eBilling .......................................................................................... 104

9.2.2 Indirektes eBilling........................................................................................ 105

9.3 Angewandte eBilling-Lösungen.......................................................................... 107

9.3.1 Web-Billing ................................................................................................. 107

9.3.2 E-Mail-Billing.............................................................................................. 109

9.3.3 Kombination von Web- und E-Mail-Billing................................................ 110

9.4 Integration des Signatur-Verfahrens ................................................................... 111

9.4.1 Einleitung..................................................................................................... 111

9.4.2 Dezentrale Signatur-Lösung ........................................................................ 111

9.4.3 Zentrale Signatur-Lösung ............................................................................ 112

10 Geschäftsprozessoptimierung durch E-Mail-Billing......................................... 115

10.1 Grundlagen und Ziele.......................................................................................... 115

10.2 Analyse des SOLL-Modells ................................................................................ 115

10.2.1 Modellgrundlagen........................................................................................ 115

10.2.2 Prozessablauf Rechnungssteller................................................................... 116

10.2.3 Prozessablauf Rechnungsempfänger ........................................................... 119

10.2.4 Kostenvergleich IST/SOLL-Modell ............................................................ 122

10.3 Ergebnis der Optimierung ................................................................................... 123

Inhaltsverzeichnis V

11 eBilling in der Praxis............................................................................................ 126

11.1 Einleitung ............................................................................................................ 126

11.2 AuthentiDate eBilling-Signatur-Lösungen.......................................................... 126

11.3 T-Mobile RechnungOnline.................................................................................. 130

11.4 TietoEnator Sealsnet............................................................................................ 133

12 Schlussbetrachtung .............................................................................................. 136

12.1 Ergebnis der Arbeit ............................................................................................. 136

12.2 Ausblick............................................................................................................... 137

13 Literaturverzeichnis............................................................................................. 139

Anhang......................................................................................................................... 149

A 1 Umsatzsteuergesetz § 14 und § 15 Abs. 1 ............................................................. 149

A 2 Erklärungen zum V-Modell ................................................................................... 152

A 3 Übersicht der EPK-Verknüpfungsarten ................................................................. 153

A 4 Erklärung der EDIFACT Beispiel-Rechnung........................................................ 154

Abbildungsverzeichnis VI

Abbildungsverzeichnis

Abbildung 2.1: Vom Ziel zum Ergebnis eines Geschäftsprozesses ................................. 5

Abbildung 2.2: Hierarchische Unterteilung eines Geschäftsprozesses ............................ 6

Abbildung 2.3: Konzept des Geschäftsprozessmanagements........................................... 8

Abbildung 2.4: Gestaltung von Geschäftsprozessen nach dem V-Modell ....................... 8

Abbildung 2.5: Beispiel graphenbasiertes Geschäftsprozessmodell in UML-Notation . 11

Abbildung 2.6: Dach und Säulen des Geschäftsprozessmanagements........................... 12

Abbildung 3.1: Modell der Rechnungserstellung in EPK-Notation ............................... 19

Abbildung 3.2: Darstellung einer Rechnungserstellung durch eEPK............................. 21

Abbildung 4.1: Erstellen einer qualifizierten elektronischen Signatur........................... 31

Abbildung 4.2: Lokale Signaturprüfung mit einer Signatur-Prüfsoftware ..................... 33

Abbildung 5.1: Das Umsatzsteuersystem aus der Perspektive eines Unternehmens ..... 36

Abbildung 6.1: Vereinfachter Rechnungsprozess .......................................................... 50

Abbildung 6.2: Rechnungserstellung und -versand in Papierform................................. 52

Abbildung 6.3: Eingang und Weiterverarbeitung einer Papierrechnung........................ 55

Abbildung 7.1: Electronic Data Interchange (EDI) ........................................................ 59

Abbildung 7.2: Darstellung der EDIFACT–Hierarchie.................................................. 64

Abbildung 7.3: Aufbau des Nutzdatenrahmens einer EDIFACT - Übertragungsdatei.. 66

Abbildung 7.4: EDIFACT-Beispielrechnung................................................................. 67

Abbildung 7.5: EDIFACT-Übertragungsdatei ............................................................... 68

Abbildung 8.1: Dienste und Protokolle für EDI über das Internet ................................. 75

Abbildung 8.2: Abgrenzung HTML, XML und SGML ................................................. 80

Abbildung 8.3: XML-Sprachkonzept ............................................................................. 81

Abbildung 8.4: XML-Tree zum XML-Dokument in Tabelle 8.1................................... 83

Abbildung 8.5: Beispiel für ein wohlgeformtes XML-Dokument (Rechnung.xml) ...... 84

Abbildung 8.6: Beispiel einer Document Type Definition (Rechnung.dtd)................... 86

Abbildung 8.7: DTD zum XML-Dokument in Abbildung 8.5 (rechnung2.dtd) ............ 88

Abbildung 8.8: Beispiel für ein gültiges XML-Dokument (rechnung2.xml) ................. 89

Abbildung 8.9: DTD (adresse.dtd) zu XML-Dokument in Tabelle 8.1 ......................... 91

Abbildung 8.10: XML-Schema (Adresse.xsd) zu XML-Dokument in Tabelle 8.1 ....... 91

Abbildungsverzeichnis VII

Abbildung 8.11: XML-Dokument mit einfachem CSS.................................................. 93

Abbildung 8.12: Drei Arten von XML-Signaturen ........................................................ 95

Abbildung 8.13: XML-Signatur Beispiel ....................................................................... 95

Abbildung 8.14: Ablauf XML/EDI-Kommunikation..................................................... 98

Abbildung 9.1: Vergleich Rechnungsstellung auf Papier bzw. per eBilling ................ 104

Abbildung 9.2: Direktes eBilling.................................................................................. 105

Abbildung 9.3: Indirektes eBilling ............................................................................... 106

Abbildung 9.4: Elektronische Rechnungsstellung mit Web-Billing ............................ 108

Abbildung 9.5: Elektronische Rechnungsstellung mit E-Mail-Billing......................... 109

Abbildung 9.6: Dezentrale Signatur-Lösung................................................................ 111

Abbildung 9.7: Zentrale Signatur-Lösung.................................................................... 113

Abbildung 10.1: Rechnungserstellung und -versand mit E-Mail-Billing..................... 117

Abbildung 10.2: Eingang und Weiterverarbeitung einer E-Mail-Rechnung................ 120

Abbildung 11.1: AuthentiDate eBilling-Inhouse-Lösung ............................................ 127

Abbildung 11.2: AuthentiDate eBilling-Lösung über Trust Center ............................. 129

Abbildung 11.3: Einzelverbindungsnachweis T-Mobile RechnungOnline.................. 132

Abbildung 11.4: TietoEnator Lösungsvorschlag .......................................................... 135

Tabellenverzeichnis VIII

Tabellenverzeichnis

Tabelle 3.1: EPK-Verknüpfungsoperatoren ................................................................... 18

Tabelle 5.1: Vierstufige Warenweg mit Vorsteuerabzug ............................................... 37

Tabelle 6.1: Übersicht Anforderungen an eine Rechnungsstellung im B2B-Bereich.... 48

Tabelle 6.2: Prozessbeschreibung IST-Modell Rechnungssteller .................................. 53

Tabelle 6.3: Prozessbeschreibung IST-Modell Rechnungsempfänger ........................... 56

Tabelle 8.1: Vergleich HTML-/XML-Dokument........................................................... 82

Tabelle 10.1: Prozessbeschreibung SOLL-Modell Rechnungssteller .......................... 118

Tabelle 10.2: Prozessbeschreibung SOLL-Modell Rechnungsempfänger ................... 121

Tabelle 10.3: Kostenvergleich Rechungsübermittlung................................................. 122

Tabelle 10.4: Kostenvergleich Rechnungsbearbeitung ................................................ 122

Abkürzungsverzeichnis IX

Abkürzungsverzeichnis

Abb. Abbildung

Abs. Absatz

AO Abgabenordnung

ASP Application Service Provider

B2B Business-to-Business

B2C Business-to-Customer

BGB Bürgerliches Gesetzbuch

BMF Bundesministerium für Finanzen

bzgl. Bezüglich

bzw. beziehungsweise

ca. circa

CDATA Character Data

CD-ROM Compact Disk – Read Only Memory

CSS Cascading Style Sheets

d.h. das heißt

DEDIG Deutsche EDI/EC Gesellschaft

DFÜ Datenfernübertragung

DIN Deutsches Institut für Normung

DMS Dokumenten-Management-System

DOM Document Object Model

DTD Document Type Definition

DV Datenverarbeitung

DVD Digital Versatile Disc

eBilling Electronic Billing

EBPP Electronic Bill Presentment and Payment

eBusiness Electronic Business

ebXML Electronic Business XML

ECE Economic Commision for Europe

EDI Electronic Data Interchange

EDV Elektronische Datenverarbeitung

eEPK erweiterte Ereignisgesteuerte Prozessketten

E-Mail Electronic Mail

EPK Ereignisgesteuerte Prozessketten

Abkürzungsverzeichnis X

ERM Entity Relationship Modell

etc. et cetera

EU Europäische Union

FTP File Transfer Protocol

GDPdU Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen

ggf. gegebenenfalls

GoBS Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

ISO International Standardisation Organisation

IT Informations- und Telekommunikationstechnik

MB Megabyte

MIME Multi-purpose Internet Mail Extensions

MwSt Mehrwertsteuer

Nr. Nummer

PCDATA Parsed Character Data

PI Processing Instruction

PIN Personal Identity Number

PKI Public Key Infrastruktur

RegTP Regulierungsbehörde für Telekommunikation und Post

ROI Return-on-Investment

s.o. siehe oben

SGML Standard Generalized Markup Language

SigG01 Signaturgesetz 2001

SigG97 Signaturgesetz 1997

SMTP Simple Mail Transfer Protocol

sog. sogenannte/es/en

StÄndG2001 Steueränderungsgesetz 2001

Tab. Tabelle

u. und

u.a. unter anderem

UML Unified Modelling Language

UN United Nations

USt Umsatzsteuer

Abkürzungsverzeichnis XI

UStG Umsatzsteuergesetz

USt-ID-Nr Umsatzsteuer-Identifikationsnummer

usw. und so weiter

VAN Value Added Network

VANS Value Added Network Services

Vgl. Vergleiche

W3C World Wide Web Consortium

WWW World Wide Web

XML Extensible Markup Language

XSL Extensible Stylesheet Language

XSLT XSL Transformations

z.B. zum Beispiel

ZPO Zivilprozessordnung

1.1 Problemstellung 1

1 Einleitung

1.1 Problemstellung

Das Internet hat das Wirtschaftsleben in den letzten Jahren maßgeblich verändert. Vor

allem im Bereich der Kommunikations- und Transaktionswege haben Internet-basierte

Technologien traditionelle Strukturen und Beziehungen abgelöst. Heutzutage bieten

sich Unternehmen ihre Waren und Dienstleistungen gegenseitig über das Internet an

und auch Privatkonsumenten nutzen vermehrt Online-Angebote anstatt durch überfüllte

Kaufhäuser zu ziehen. In vielen Fällen besteht für Unternehmen die Möglichkeit einen

kompletten Einkaufsprozess über das Internet abzuwickeln. Eine Ausnahme dabei

bildete bis Ende 2001 die zwischenbetriebliche Rechnungsstellung. Aufgrund der bis

dahin geltenden Regelungen des Umsatzsteuergesetzes waren steuerrechtlich anzuer-

kennende Rechnungen fest an die Papierform gebunden. Rein elektronisch übermittelte

Rechnungen konnten demnach nicht durch den Rechnungsempfänger zu einem Vor-

steuerabzug gegenüber den Finanzbehörden geltend gemacht werden. Im Rahmen einer

von der Seals GmbH (Frankfurt a. M.) im Jahre 2001 durchgeführten Befragung von

über 130 Managern deutscher Unternehmen wurde festgestellt, dass aufgrund dieser

Tatsache über 90% der Firmen, trotz der fortgeschrittenen technischen Entwicklungen,

ihre Rechnungen ausschließlich auf dem traditionellen Postweg versenden.1

Seit dem 01.01.2002 hat sich die Rechtslage entscheidend verändert. Elektronische

Rechnungen sind im Umsatzsteuergesetz den Rechnungen in Papierform gleichgestellt,

sofern sie die inhaltlichen Anforderungen an eine Rechnung erfüllen und mit einer e-

lektronischen Signatur versehen sind. Die elektronische Signatur bestätigt, analog zu

einer handschriftlichen Unterschrift, eindeutig die Identität des Unterzeichners und des-

sen Einverständnis mit den signierten Daten und bildet somit die Grundlage für eine

steuerrechtliche Anerkennung der elektronischen Rechnung.

Für die Unternehmen bedeutet die Neuregelung des Umsatzsteuergesetzes, dass sie die

Prozesse zur Rechnungsstellung bezüglich der neu geschaffenen Möglichkeiten über-

denken und umstrukturieren können, um diese effizienter zu gestalten und damit Kosten

einzusparen. Gerade vor dem Hintergrund der angespannten wirtschaftlichen Lage und

dem steigenden Kosten- und Konkurrenzdruck können innerbetriebliche Kostensenkun-

gen zu einer nachhaltigen Steigerung des Gewinns und der Wettbewerbsfähigkeit eines

Unternehmens beitragen.

1 Vgl. http://www.e-business.de/texte/4844.asp, abgerufen am 02.06.03

1.2 Vorgehensweise 2

Ziel dieser Arbeit ist es, die elektronische Rechnungsstellung über das Internet im zwi-

schenbetrieblichen Rechnungsaustausch auf mögliche Optimierungspotentiale gegen-

über der papierbasierten Rechnungsstellung zu überprüfen. Dabei werden die gesetzli-

chen Rahmenbedingen der elektronischen Rechnungsstellung erläutert und Ansätze für

eine technische Umsetzung aufgezeigt.

In der Vorgehensweise wird dabei nicht allein auf die elektronische Rechnungsstellung,

sondern auch allgemein auf die elektronische Datenübertragung per EDI bzw. über das

Internet eingegangen.

1.2 Vorgehensweise

Im zweiten Kapitel wird die elektronische Signatur näher beschrieben. Neben den kryp-

tographischen Grundlagen soll dabei vor allem auf das aktuelle Signaturgesetz und auf

das Ausstellen und Überprüfen einer elektronischen Signatur aus Sicht eines Anwenders

eingegangen werden. Das darauf folgende dritte Kapitel befasst sich mit den rechtlichen

Rahmenbedingungen der elektronischen Rechnungsstellung. Zunächst wird das Um-

satzsteuersystem erklärt, sowie inhaltliche und formale Anforderungen an eine Rech-

nung im Sinne des Umsatzsteuergesetz aufgeführt. Dabei wird insbesondere die neu

geschaffene Möglichkeit der elektronischen Rechnungsstellung unter Einsatz elektroni-

scher Signaturen beschrieben. Im Anschluss an Bemerkungen zum Zugang und Wirk-

samwerden elektronischer Rechnungen sollen die Anforderungen seitens der Finanzbe-

hörden bezüglich Umgang und Aufbewahrung derselben betrachtet werden. In diesem

Zusammenhang wird auch auf die Berechtigung der Finanzbehörden zum elektroni-

schen Datenzugriff im Rahmen einer betrieblichen Außenprüfung eingegangen. Abge-

schlossen wird das Kapitel mit Ausführungen zu den innerhalb der EU geltenden Rege-

lungen bezüglich des elektronischen Rechnungsaustauschs und der steuerrechtlichen

Anerkennung.

Kapitel vier befasst sich mit dem Konzept des Geschäftsprozessmanagements als Mittel

zur Optimierung betrieblicher Abläufe. Dabei werden insbesondere die Begriffe Ge-

schäftsprozess, Geschäftsprozessmodellierung sowie Geschäftsprozessanalyse und

-optimierung behandelt. Kapitel fünf stellt mit den "Ereignisgesteuerten Prozessketten"

eine geeignete Methode zur Geschäftsprozessmodellierung vor, die in den folgenden

Kapiteln angewendet wird. Im sechsten Kapitel wird der Geschäftsprozess der papierba-

sierten Rechnungsstellung modelliert, analysiert und bewertet. Dafür werden zunächst

1.2 Vorgehensweise 3

allgemeine Funktionen und Anforderungen der zwischenbetrieblichen Rechnungsstel-

lung beschrieben, anhand derer anschließend die Analyse und Bewertung durchgeführt

wird. Basierend auf den Ergebnissen werden mögliche Optimierungspotentiale durch

eine Rechnungsstellung in elektronischer Form aufgezeigt. Das siebte Kapitel betrachtet

die Ansätze und Ziele des traditionellen elektronischen Datenaustauschs per EDI. Insbe-

sondere wird der EDIFACT-Standard näher erläutert und am Beispiel einer Rechnung

verdeutlicht. Zum Abschluss des Kapitels wird die Situation von EDI in der Praxis be-

schrieben und Gründe für die Zurückhaltung der Unternehmen gegenüber EDI-

Verfahren angegeben. In Kapitel acht werden die neuen Möglichkeiten des elektroni-

schen Datenaustauschs über das Internet vorgestellt. Schwerpunkt dabei ist die Exten-

sible Markup Language (XML), die sich als universell einsetzbare Internet-Sprache

etabliert hat. In Kapitel neun werden die im achten Kapitel aufgezeigten Möglichkeiten

der Internet-Datenübertragung gezielt auf die elektronische Rechnungsstellung (eBil-

ling) überführt. Dazu werden zwei eBilling-Lösungen und deren Vor- und Nachteile

vorgestellt, sowie zwei Varianten zur Integration des Signatur-Verfahrens betrachtet. Im

zehnten Kapitel wird die zwischenbetriebliche Rechnungsstellung über das Internet,

basierend auf dem im neunten Kapitel beschriebenen E-Mail-Billing-Verfahren, model-

liert, analysiert und bewertet. Dabei soll insbesondere geprüft werden, inwieweit diese

Form der Rechnungsstellung den in Kapitel sechs aufgestellten Anforderungen gerecht

wird und welche Optimierungspotentiale gegenüber dem papierbasierten Prozessablauf

erfüllt bzw. nicht erfüllt werden können. Des Weiteren wird ein Kostenvergleich mit der

papierbasierten Rechnungsstellung vorgenommen, um mögliche Einsparungspotentiale

monetär aufzuzeigen. In Kapitel elf werden drei Beispiele für praktizierte eBilling-

Lösungen beschrieben. Im abschließenden Kapitel werden die Ergebnisse dieser Arbeit

diskutiert und ein Ausblick über mögliche praktische Einsatzchancen der elektronischen

Rechnungsstellung über das Internet gegeben.

2.1 Grundlegende Begriffe 4

2 Geschäftsprozessmanagement

2.1 Grundlegende Begriffe

In Unternehmen werden verschiedene Produktionsprozesse unterschieden, die zusam-

menwirkend zu einem Produktionsziel führen. Zur besseren Kontrolle des gesamten

Produktionsablaufs werden sie getrennt betrachtet und anschließend über ihre Interakti-

onen verknüpft. Diese Prozesse werden Geschäftsprozesse genannt und sind z.B. fol-

gendermaßen ausgeprägt:

• Beschaffung,

• Verwaltung,

• Produktion,

• Lagerung,

• Verkauf.

Beispielsweise betrifft die Fertigung und der Verkauf eines von einem Kunden angefor-

derten Ersatzteils u.a. Geschäftsprozesse der Auftragserfassung, der Verwaltung, des

Lagers, der Produktion und des Vertriebes eines beauftragten Produktionsunterneh-

mens. Im Vertrieb stellt insbesondere die Rechnungsstellung einen im Rahmen eines

Verkaufs unverzichtbaren Geschäftsprozess dar.

Für den Begriff "Geschäftsprozess" finden sich in der Literatur zahlreiche Definitionen.

Nach ZILAHI -SZABÓ beschreibt ein Geschäftsprozess "...welche Funktionen/Prozesse in

welcher Folge aneinander gereiht werden müssen, damit durch ihre Ausführung ein

vorgegebenes Ziel erreicht werden kann."2 Ein Geschäftsprozess kann demnach als Re-

aktionen eines Unternehmens (in Form von Prozessen) auf eine von außen gestellte An-

forderung betrachtet werden.3

Ausgangspunkt eines Geschäftsprozesses nach ZILAHI -SZABÓ ist das angestrebte Pro-

duktionsziel, der Endpunkt ist das erreichte Ergebnis. Das Ziel wird von außen (z.B.

durch Kunden, Geschäftspartner, Lieferanten) an das Unternehmen gestellt und be-

schreibt beispielsweise die Produktion einer Ware oder die Verrichtung einer Dienst-

leistung. Um von dem Ziel zu dem Ergebnis zu gelangen, werden eine oder in der Regel

mehrere Prozessketten durchlaufen.

2 ZILAHI -SZABÓ, (2002), S. 6ff.

3 Vgl. ZILAHI -SZABÓ, (2002), S. 5


Vertrieb derDienstleistungen/Produkte

Dienstleistungen/Produkte erstelltund verkauft

Prozesskette

Unternehmen

Geschäftsprozess

Allgemein:

Beispiel:

Bereitstellung/Lagerung vonRessourcen

Beschaffung vonRessourcen

Einsatz derRessourcen/Produktion

Erstellung/Verkauf vonDienstleistungen/Produkten

Prozesskette ErgebnisProzessketteZiel

Abbildung 2.1: Vom Ziel zum Ergebnis eines Geschäftsprozesses4

Prozessketten stellen in sich abgeschlossene Bestandteile eines Geschäftsprozesses dar.

Sie untergliedern den Geschäftsprozess in mehrere Teilprozesse, deren Abarbeitung

jeweils von einem Teilziel zu einem Teilergebnis führt. Prozessketten werden weiter

unterteilt in verschiedene Arbeitsprozesse.

Ein Arbeitsprozess definiert eine zu verrichtende Aufgabe zur Erbringung einer Leis-

tung (z.B. Rechnung schreiben, Rechnung prüfen). Die Durchführung eines Arbeitspro-

zesses obliegt einem Aufgabenträger und beinhaltet die Abarbeitung eines oder in der

Regel mehrerer Vorgänge in einer bestimmten Ablauffolge. Aufgabenträger können

sowohl Personen als auch Maschinen oder Softwaresysteme sein.

Die Vorgänge repräsentieren die physischen und geistigen Tätigkeiten der Aufgaben-

träger. Ihre Durchführung stützt sich auf Unternehmensressourcen/Sachmittel (z.B. Te-

lefon, Fax, IT-Systeme) und betrifft Informationsobjekte (z.B. Daten, Dokumente,

usw.), die dabei gelesen, bearbeitet oder erzeugt werden können.

Nach ZILAHI -SZABÓ lassen sich Geschäftsprozesse anhand der Begriffe Prozesskette,

Arbeitsprozess und Vorgang im Top-Down-Vefahren unterteilen und hierarchisieren.

Diese Form der Unterteilung wird als Verfeinerung bezeichnet.5 Die Anzahl der ver-

schiedenen Ausprägungen der einzelnen Ebenen kann dabei je nach Geschäftsprozess

stark variieren.

4 Vgl. ZILAHI -SZABÓ (2002), S. 13

5 Vgl. ZILAHI -SZABÓ (2001), S. 111


Die folgende Abbildung verdeutlicht die Verfeinerung des Geschäftsprozesses "Rech-

nungseingang".

Geschäftsprozess Prozessketten Arbeitsprozesse Vorgänge

Rechnungs-eingang

Rechnungsgs-daten erfassen

Rechnung prüfen

Rechnungverbuchen

Rechnungarchivieren

Rechnungs-eingang

registrieren

Rechnungskopf-Daten erfassen

Rechnungs-positionenerfassen

Einzelbetragerfassen

Steuersatzerfassen

Menge erfassen

Gesamtbetragerfassen

Abbildung 2.2: Hierarchische Unterteilung eines Geschäftsprozesses6

Die Reihenfolge, in der Vorgänge innerhalb eines Arbeitsprozesses und Arbeitsprozesse

untereinander verknüpft sind, wird durch Ereignisse bestimmt. Ein Ereignis ist das Er-

gebnis eines Vorgangs oder Arbeitsprozesses und beschreibt das Eingetretensein eines

bestimmten Zustandes. Bedingt durch diesen wird/werden ein oder mehrere Folgepro-

zess/e ausgelöst. Vorgänge und Arbeitsprozesse besitzen demnach jeweils ein (auslö-

sendes) Vor- und ein (erzeugtes) Nachereignis.

Die einzelnen Prozessketten eines Geschäftsprozesses können unabhängig voneinander

ablaufen oder in einem geregelten Ablauf stehen. Auch Interaktionen zwischen Pro-

zessketten sind möglich, d.h. ein eingetretenes Ereignis kann mehrere Folgeprozesse in

anderen Prozessketten auslösen. Die Reihenfolge der Prozessketten und Arbeitsprozesse

wird als Geschäftsprozessablauf bezeichnet. Der Geschäftsprozessablauf beschreibt

demnach einen bestimmten zeitlich-logischen Vorgehensplan, der abgearbeitet das

durch den Geschäftsprozess angestrebte Ziel liefert.

6Vgl. ZILAHI -SZABÓ (2001), S. 113

2.2 Das Konzept des Geschäftprozessmanagements 7

2.2 Das Konzept des Geschäftprozessmanagements

Die zunehmende Globalisierung der Märkte und die Entwicklung neuer Informations-

und Kommunikationstechnologien (z.B. E-Mail, Internet) stellen Unternehmen heutzu-

tage vor veränderte Marktsituationen. Die neuen Informationsmedien und verkürzte

Informationswege machen es dem Konsumenten leicht, sich umfassend zu informieren

und Produkte zu vergleichen. Diese Erhöhung der Markttransparenz führt dazu, dass

Unternehmen einer immer größer werdenden Konkurrenz und steigendem Kostendruck

ausgesetzt sind. Um wettbewerbsfähig zu bleiben, stellen sich deshalb, gerade in Bezug

auf Effizienz, Kosten und Qualität der Geschäftsprozesse und Produkte, gehobene An-

forderungen an die Unternehmen und deren interne Struktur. Wettbewerbsvorteile erzie-

len vor allem die Unternehmen, die schnell und flexibel auf Veränderungen von Märk-

ten, Kunden und Technologien reagieren können.

Anfang der 90er Jahre entwickelte sich das Konzept des Geschäftsprozessmanage-

ments als Reaktion der Unternehmen auf die steigenden Anforderungen. Zielsetzung

dabei ist eine Steigerung der Effizienz entlang der Wertschöpfungskette eines Unter-

nehmens sowie eine kontinuierliche Optimierung von Geschäftsprozessen, um damit

eine Stärkung der Wettbewerbsfähigkeit des Unternehmens in einem wirtschaftlichen

Umfeld zu erreichen, das von steigender Wettbewerbsintensität und kürzeren Produkt-

lebenszyklen geprägt ist.7 Angestrebte Optimierungsmaßnahmen sind beispielsweise:

• Senkung der Produktionskosten,

• Verkürzung der Produktions-/Durchlaufzeiten,

• Steigerung der Kundenzufriedenheit,

• Verbesserung der Produktqualität oder

• effizientere Nutzung der zur Verfügung stehenden Ressourcen.

Insbesondere durch eine Senkung von Prozesskosten lässt sich im Unternehmen eine

Gewinnsteigerung auch ohne zusätzliches Umsatzwachstum realisieren.

Das Konzept des Geschäftsprozessmanagements beinhaltet mehrere bestimmte Vorgän-

ge: Es umfasst eine markt- und kundenorientierte Definition der Unternehmensziele,

sowie die Gestaltung, Umsetzung, Ausführung und Analyse der an deren Umsetzung

beteiligten Geschäftsprozesse. Diese Vorgänge stehen innerhalb eines Unternehmens

in der in Abbildung 2.3 aufgezeigten Beziehung zueinander und bilden somit einen Ge-

samtprozess, der sich (im Idealfall) laufend wiederholt.

7 Vgl. SCHEER ET AL (1995)

2.2 Das Konzept des Geschäftprozessmanagements 8

StrategischerEntscheidungsprozess

Festlegung der strategischen Vorgaben

Gestaltungsprozess(Modellbasierte) Gestaltung von

Geschäftsprozessen, Organisation undProdukten

AusführungsprozessDurchführung der Geschäftsprozesse

(und „EDV-Betrieb“)

EvaluationsprozessEvaluation von Geschäftsprozessen,

Organisation und Produkten

Umsetzungsprozess

OrganisationInformations-technologie

OperativeDaten

liefert

führt wieder zu

Abbildung 2.3: Konzept des Geschäftsprozessmanagements8

Zunächst werden, ausgerichtet an Unternehmensstruktur, Marktsituation und Kunden-

wünschen, die Unternehmensziele, -strategie und das Produktportfolio festgelegt. Die

Produkte entstehen durch Geschäftsprozesse, deren Gestaltungsprozess wie folgt an-

hand eines Vorgehensmodells (basierend auf dem Konzept des V-Modells9) beschrieben

werden kann:

Festlegung derZielsetzung

Anforderungs-definition

Geschäftsprozess-modellierung/

Prozessentwurf

Teilprozess-modellierung/

Teilprozessentwurf

Betrieb

Einführung

Testlauf

Einzeltest

Testfälle

Validierung der Zielsetzung

Testfälle

Testfälle

Testfälle

Anforderungsvalidierung

Restrukturierung

t

Abbildung 2.4: Gestaltung von Geschäftsprozessen nach dem V-Modell

8 Vgl. Business Process Management System (BPMS) –Paradigma nach KARAGIANNIS ET AL (1996)

9 Nähere Informationen zum V-Modell siehe Anhang A 2 Erklärungen zum V-Modell

2.3 Geschäftsprozessmodellierung 9

Die Geschäftsprozessmodellierung (siehe Kapitel 2.3) ist ein Teil dieses Gestaltungs-

prozesses. Anhand von Modellen werden hier Ziele, Abläufe und Organisation von Ge-

schäftsprozessen festgelegt und dargestellt. Die anschließende Umsetzung (vgl.

Abbildung 2.3) der Geschäftsprozesse stützt sich auf die im Unternehmen gegebenen

organisatorischen Strukturen unter Einbindung der vorhandenen Informations- und Te-

lekommunikationstechnologien. Die Aufgabe der IT-Systeme liegt in der optimalen

Unterstützung der Geschäftsprozesse zur Erreichung der definierten Unternehmensziele.

Nach der Prozessausführung (vgl. Abbildung 2.3) erfolgt eine Analyse und Bewertung

der erzielten Produkte und der durchlaufenen Arbeitsprozesse nach zuvor festgelegten

Schwerpunkten. Dieser Vorgang wird als Geschäftsprozessanalyse (vgl. Abbildung

2.3) bezeichnet. Die Ergebnisse der Geschäftsprozessanalyse können dann zu einer ver-

änderten Zielsetzung des Unternehmens und/oder zu einer Neuentwicklung bzw. zu

einem Re-Design der bestehenden Geschäftsprozesse führen, um somit auf eine verän-

derte Marktsituation und evtl. Kundenwünsche reagieren und Arbeitsabläufe und Pro-

duktqualität optimieren zu können. Anschließend erfolgt erneut die Umsetzung, Aus-

führung und Analyse der Geschäftsprozesse. Das Konzept des Geschäftsprozessmana-

gement stellt also keine statische, einmal durchzuführende Optimierungsmaßnahme dar,

sondern beschreibt vielmehr einen dynamischen Prozess, mit dem Ziel die Unterneh-

menseffizienz, Kundenzufriedenheit und Wettbewerbsfähigkeit kontinuierlich hoch zu

halten bzw. weiter zu steigern.

2.3 Geschäftsprozessmodellierung

2.3.1 Einleitung

Von zentraler Bedeutung im Rahmen des Geschäftsprozessmanagements ist die Ge-

schäftsprozessmodellierung. Als Teil des Gestaltungsprozesses (siehe Abbildung 2.4)

beschreibt dieser Begriff die Gestaltung von Zielen, Aufbau, Ablauf und Organisation

von Geschäftsprozessen durch sog. Geschäftsprozessmodelle.

Geschäftsprozessmodelle versuchen Abbilder der betrieblichen Realität oder idealtypi-

sche Geschäftsprozessabläufe transparent und leicht verständlich darzustellen. Ihre Er-

stellung verfolgt stets ein konkretes Ziel, wie beispielsweise10

10

Vgl. KÜHN, KARAGIANNIS (2001), S. 5, vgl. JUNGINGER (2000), S. 11-12


• die Dokumentation von Geschäftsprozessen (z.B. für Mitarbeiterschulungen,

Zertifizierungen im Rahmen eines Qualitätsmanagements),

• die Optimierung oder Reorganisation bestehender Geschäftsprozessabläufe

oder die Anpassung an sich ändernde Rahmenbedingungen (z.B. bei Gesetzes-

änderungen),

• die Definition fachlicher Vorgaben zur Qualitätssicherung (z.B. Referenzab-

läufe, Pflichtenheft),

• die Analyse und Bewertung eines Geschäftsprozesses (z.B. Zeit-/Kosten-/

Kapazitätsanalysen durch Simulation mit reellen oder hypothetischen Daten).

Geschäftsprozessmodelle können des Weiteren auch als Grundlage für eine Software-

Entwicklung dienen. In diesem Zusammenhang wird aber allgemeiner von einer Pro-

zessmodellierung gesprochen.

2.3.2 Graphenbasierte Modellierungssprachen

Es gibt verschiedene Techniken und Methoden Geschäftprozessmodelle zu erstellen.11

Allen Methoden gemeinsam ist aber, dass sich ein Modell aus einer Menge zur Verfü-

gung stehender Modellierungselemente, die nach festgelegten Modellierungsregeln an-

geordnet sind, zusammensetzt.

Eine weit verbreitete Modellierungsmethode stellen die graphenbasierten Sprachen

(oder Diagrammsprachen) dar. Deren Modelle beschreiben Geschäftsprozessabläufe

durch gerichtete Graphen (im mathematischen Sinne) auf einer (in der Regel) zweidi-

mensionalen Zeichenfläche.12 Die Knoten der Graphen repräsentieren die einzelnen Er-

eignisse und Prozesse/Vorgänge. Spezifische Modellierungsregeln geben Darstellungs-

weise und Verknüpfungsmöglichkeiten dieser Elemente vor. In der Praxis vielfach ein-

gesetzte graphenbasierte Sprachen sind beispielsweise die Ereignisgesteuerten Pro-

zessketten (EPK) (siehe Kapitel 3) oder UML Activity Diagrams 13 (letztere insbeson-

dere im Rahmen einer Software-Entwicklung).

Die folgende Abbildung stellt den Prozessablauf einer vollständigen elektronischen

Signaturprüfung (vgl. Kapitel 4.4) graphenbasiert durch ein UML-Activity-Diagram

(modelliert in Microsoft-Visio) dar.

11

Siehe JUNGINGER (2000), S. 12 12

Vgl. JUNGINGER (2000), S. 6 13

Siehe Unified Modelling Language Specification 1.3 (1999), abrufbar unter http://www.omg.org


Signatur prüfen

Startzustand: Elektronisch signierte Datei empfangen

Aktivität

Datei ablehnen

Datei akzeptieren Datei als geprüftmarkieren

Entscheidung

Endzustand: Datei akzeptiert

Endzustand: Datei abgelehnt

Zertifikate prüfen

Datei ablehnen

Endzustand: Datei abgelehnt

[fehlerhaft][korrekt]

[fehlerhaft][korrekt]

Aufspaltung

Zusammenführung

Abbildung 2.5: Beispiel graphenbasiertes Geschäftsprozessmodell in UML-Notation

Vorteil der graphenbasierten Geschäftsprozessmodelle ist ihre hohe Übersichtlichkeit

und Verständlichkeit. Selbst ohne Vorkenntnisse ist ein Geschäftsprozessablauf inklusi-

ve aller Entscheidungsstränge intuitiv lesbar. Aus diesem Grund eignet sich diese Me-

thode vor allem für die Entwicklung und Dokumentation von Geschäftsprozessen.

Seit Mitte der 90er Jahre existieren zahlreiche Modellierungswerkzeuge zur computer-

gestützten Erstellung und (zum Teil) Simulation und Bewertung graphenbasierter Ge-

schäftsprozessmodelle. Beispiele hierfür sind im deutschsprachigen Raum ADONIS�14,

ARIS�-Toolset15, Bonapart�16und Microsoft-Visio.

14

Siehe http://www.boc-eu.com/german, JUNGINGER ET AL (2000) 15

Siehe http://www.ids-scheer.com 16

Siehe http://www.intraware.de

2.4 Geschäftsprozessanalyse und -optimierung 12

2.4 Geschäftsprozessanalyse und -optimierung

2.4.1 Einleitung

Unter dem Begriff Geschäftsprozessanalyse wird die Analyse und Evaluation von Ge-

schäftsprozessen anhand von Geschäftsprozessmodellen (siehe Kapitel 2.3) verstanden.

Zielsetzung ist zum einen die Geschäftsprozessoptimierung, d.h. eventuell bestehende

Schwachstellen und Verbesserungspotentiale (z.B. Einsparungs- und Gewinnsteige-

rungspotentiale) zu erkennen, um diese durch eine Neuentwicklung bzw. durch ein Re-

Design des untersuchten Geschäftsprozesses beseitigen bzw. umsetzen zu können.17

Zum anderen ermöglicht die Analyse und Bewertung einen Vergleich zwischen alterna-

tiven Geschäftsprozessen. Dies ist vor allem bei der Entscheidungsfindung für oder ge-

gen die Einführung neuer Arbeitstechniken oder die Umstrukturierung bestehender Ge-

schäftsprozesse von entscheidender Bedeutung.

Die Geschäftsprozessanalyse bildet somit im Konzept des Geschäftsprozessmanage-

ments die Grundlage für optimierte Geschäftsprozesse. Denn nur eine sorgfältige Ana-

lyse der Geschäftsprozesse lässt Schwachstellen im Ablauf erkennen und verbessern

bzw. hilft Kosten und Nutzen einer Prozessumstellung richtig abzuschätzen.

Besonders relevant für eine Geschäftsprozessanalyse sind die Faktoren Zeit, Kosten und

Qualität. Sie werden als die Säulen des Geschäftsprozessmanagements bezeichnet.18

Abbildung 2.6: Dach und Säulen des Geschäftsprozessmanagements19

17

Vgl. Merzenich (2002), S. 38 18

Vgl. Merzenich (2002), S. 33 19

Merzenich (2002), S. 33, nach GAITANIDES ET AL (1994), S. 16


Zeitoptimierte Geschäftsprozesse sparen Personalkosten, steigern die Unternehmensef-

fizienz und gewährleisten kurze Produktlieferzeiten. Durch kostenoptimierte Unterneh-

mensabläufe lassen sich Produkte unter dem allgemeinen Marktpreisniveau anbieten

und dadurch einen Wettbewerbsvorteil gegenüber der Konkurrenz erzielen. Eine hohe

Prozessqualität reduziert Fehler im Arbeitsablauf und verbessert die Produktqualität.

Insgesamt führen die Optimierungsmaßnahmen zu einer Steigerung der Kundenzufrie-

denheit.

2.4.2 Ablauf der Geschäftsprozessanalyse

2.4.2.1 Zielvereinbarungen festlegen

Eine Geschäftsprozessanalyse dient stets einem bestimmten Zweck. Bevor die Ge-

schäftsprozessanalyse beginnt werden deshalb ein Schwerpunkt und die damit verbun-

denen angestrebten Ziele festgelegt. Zielvereinbarungen sind im Regelfall die Auswer-

tung bzw. der Vergleich von Geschäftsprozessmerkmalen, wie beispielsweise:20

• Bearbeitungszeiten,

• Liegezeiten,

• Transportzeiten,

• Durchlaufzeiten,

• Bearbeitungskosten,

• Sachkosten,

• Transportkosten,

• Prozesssicherheit/Prozessqualität,

• Medienbrüche,

• Doppelarbeiten,

• Personal- und Ressourcenauslastung,

• Produktqualität.

Anhand der Auswertung der untersuchten Merkmale lassen sich mögliche Optimie-

rungspotentiale erfassen. Bezogen auf den Prozess der Rechnungsstellung ist z.B. eine

Analyse der Bearbeitungszeit, Bearbeitungskosten, Prozesssicherheit oder der Anzahl

der Medienbrüche denkbar, um eventuelle Möglichkeiten der Optimierung aufzuzeigen.

20

Vgl. MERZENICH (2002), S. 49


2.4.2.2 Analyse und Bewertung

Die Geschäftsprozessanalyse erfolgt an einem Modell des derzeitigen Geschäftsprozes-

ses, dem sogenannten IST-Modell .21 Um das Modell auswerten zu können, werden die

gemäß des festgelegten Schwerpunktes zu analysierenden Prozessdaten erfasst. Dies

kann beispielsweise durch eine direkte Befragung der an der Durchführung beteiligten

Mitarbeiter (Interviews) oder durch eine Beobachtung des Prozessablaufs in der Praxis

geschehen. Basierend auf den Prozessdaten lassen sich spezifische Kennzahlen und

Messgrößen ermitteln, anhand derer der betrachtete Geschäftsprozess bewertet und mit

alternativen Modellen verglichen werden kann. In Frage kommende Kennzah-

len/Messgrößen sind beispielsweise:22

• Mittlere Durchlauf-/Bearbeitungszeit,

• Mittlere Auslastung,

• Durchschnittlich anfallende Kosten,

• Fehler-/Ausschussquoten,

• Verhältnis von Bearbeitungszeit zu Liege- und Transportzeiten.

Die Auswertung der Kennzahlen/Messgrößen kann auf unterschiedlichen Ebenen erfol-

gen. Maßstäbe sind beispielsweise Kunden- und Qualitätsanforderungen oder unter-

nehmensinterne Vorgaben wie z.B. Preisstrategie, Personal- und Ressourcenauslastung.

Liegen auch für ein alternatives Geschäftsprozessmodell die entsprechenden Kennzah-

len vor, kann ein schwerpunktbezogener Vergleich der beiden Modelle erfolgen.

2.4.3 Geschäftsprozessoptimierung

Dem Konzept des Geschäftsprozessmanagements (vgl. Abbildung 2.3) folgend, können

die Ergebnisse der Geschäftsprozessanalyse zu einer Neudefinition der Unternehmens-

strategie oder zu einem Re-Design des untersuchten Geschäftsprozesses führen. Letzte-

res hat die Zielsetzung eventuell ermittelte Schwachstellen zu beheben und den Ge-

schäftsprozess zu optimieren.

Die für eine mögliche Optimierung relevanten Prozesse lassen sich anhand der folgen-

den Fragestellungen identifizieren:23

21

Vgl. MERZENICH (2002), S. 48 22

Vgl. MERZENICH (2002), S. 51 23

Vgl. MERZENICH (2002), S. 45, nach HAMMER/CHAMPY (1994), S. 159-166


• Welche Prozesse fallen (besonders) negativ auf?

• Welche Prozesse haben die höchste Bedeutung für den Kunden?

• Welche Prozesse eignen sich für eine erfolgreiche Neugestaltung? (Machbar-

keit/Erfolgschancen)?

• Welche Prozesse können bei mindestens gleicher Qualität beschleunigt wer-

den?

• Welche Prozesse können zusammengefasst werden?

Die Durchführung der Optimierungsmaßnahmen erfolgt vorerst auf der Ebene der Pro-

zessmodellierung. Ein sogenanntes SOLL-Modell beschreibt den vermeintlich opti-

mierten Geschäftsprozesses. Um die beiden Modelle (IST/SOLL-Modelle) gegenüber-

stellen zu können, müssen für das SOLL-Modell die gleichen Kennzahlen/Messgrößen

wie bei der Bewertung des IST-Modells ermittelt werden. Dies kann auf unterschiedli-

che Weise geschehen, u. a. durch:

• Computergestützte Modellierung, Simulation und Analyse (basierend auf reel-

len oder hypothetischen Daten) des SOLL-Modells durch Anwendung eines

Modellierungswerkzeugs (z.B. ADONIS®, ARIS-Toolset®, Bonapart®).

• Simulation und Analyse des SOLL-Modells in der betrieblichen Praxis.

• Theoretische Auswertung des SOLL-Modells anhand reell zu erwartender Da-

ten, basierend beispielsweise auf Herstellerangaben (bei der Einführung neuer

Arbeitsgeräte/Software).

Anhand der ermittelten Kennzahlen/Messgrößen erfolgt ein SOLL/IST-Vergleich der

beiden Modelle, um festzustellen, ob der neu entwickelte bzw. neu organisierte Ge-

schäftsprozess die angestrebte Optimierung vollständig, teilweise oder überhaupt nicht

realisieren kann. Stellt der Geschäftsprozess die an ihn gestellten Anforderungen mit

einem positiven Kosten-Nutzen-Effekt sicher, kann die Umsetzung des Modells in die

betriebliche Praxis folgen. Dazu wird das SOLL-Modell auf eine Übertragbarkeit in die

Praxis untersucht (Machbarkeitsanalyse). Gegebenenfalls müssen Anpassungen vorge-

nommen werden, um das Modell auf die betrieblichen Gegebenheiten abzustimmen.

Nach Einführung des neuen (verbesserten) Geschäftsprozessablaufs wird das SOLL-

Modell zu einem IST-Modell und bildet damit die Grundlage für eine erneute Ge-

schäftsprozessanalyse.24

24

Vgl. MERZENICH (2002), S. 52-53


Typische Beispiele für eine Geschäftsprozessoptimierung sind die zunehmende Digita-

lisierung von Geschäftsprozessen im Bereich der Verwaltung, Buchhaltung oder der

betrieblichen Kommunikation. Hierzu zählt u.a. die Einführung eines Dokumenten-

Management-Systems (DMS) zur elektronischen Dokumentenverwaltung und -

archivierung, der Einsatz elektronischer Buchungsmaschinen in der Finanzbuchhaltung

sowie die Umstellung vom papierbasiertem auf elektronischen Geschäftsverkehr z.B.

mit EDI (siehe Kapitel 7).

3.1 Elemente und Verknüpfungen 17

3 Ereignisgesteuerte Prozessketten (EPK)

3.1 Elemente und Verknüpfungen

Ereignisgesteuerte Prozessketten (EPK)25 stellen die im deutschsprachigen Raum

bekannteste graphenbasierte Modellierungssprache (siehe Kapitel 2.3.2) dar.26 Entwi-

ckelt wurden sie von KELLER ET AL. am Institut für Wirtschaftsinformatik der Universi-

tät Saarbrücken.

Die Modellierung eines Geschäftsprozessablaufs mit EPK stützt sich auf zwei Basis-

elemente:27

• Funktionen repräsentieren die Durchführung betrieblicher Vorgänge, die einen

Beitrag zur Erfüllung eines Unternehmensziels leisten. Sie sind aktive Kom-

ponenten im Unternehmen, d.h. ihre Abarbeitung verbraucht Zeit, verursacht

Kosten und hat Zustandsänderungen zur Folge. Sie lesen, bearbeiten, löschen

oder erzeugen Objekte und transformieren so Input- zu Outputdaten. Funktio-

nen besitzen außerdem Entscheidungskompetenz über nachfolgende Funktio-

nen. Beispiele für Funktionen sind: "Kundenstammblatt anlegen", "Auftrag

annehmen", "Rechnungsdaten überprüfen", "Ware abschicken". Graphisch

werden Funktionen durch Sechsecke repräsentiert.

• Ereignisse beschreiben eingetretene Zustände oder spezifizieren Bedingungen

von am Geschäftsprozess beteiligten Objekten. Zum einen dienen sie als Aus-

lösemechanismus für Funktionen und zum anderen sind sie selbst wieder das

Ergebnis einer oder mehrerer verknüpfter Funktionen. Ereignisse sind zeit-

punktbezogene, passive Komponenten und besitzen keine Entscheidungskom-

petenz über den weiteren Prozessverlauf. Grundsätzlich lässt sich ein Ereignis

einem der folgenden vier Ereignistypen zuordnen:28

§ Das Ereignis beschreibt ein neu erzeugtes Informationsobjekt (z.B.

"Kundenstammblatt ist angelegt", "Bestellung ist erzeugt") bzw. ein

abgeschlossenes bestehendes Informationsobjekt (z.B. "Auftrag ist

abgelehnt", "Auftrag ist abgeschlossen"). Diese Art von Ereignissen

stehen oftmals am Beginn bzw. Ende einer Prozesskette.

25

Siehe KELLER ET AL (1992), LANGNER ET AL (1997), RUMP (1999), RITTGEN (2000) 26

Z.B. werden SAP R/3 Referenzmodelle in EPK dargestellt, vgl. KELLER, TEUFEL (1997) 27

Vgl. KELLER ET AL (1992), S. 8-15 28

Vgl. ROSEMANN, SCHWEGMANN (2002), S. 66


§ Das Ereignis kennzeichnet eine Statusänderung eines Informations-

objekts (z.B. "Rechnung ist gebucht", "Ware ist eingetroffen").

§ Das Ereignis signalisiert das Eintreffen eines definierten Zeitpunkts

(z.B. "Zahlungstermin ist überschritten", "Auftragsfrist ist abgelau-

fen").

§ Das Ereignis dokumentiert eine Bestandsveränderung (z.B. "Kredit-

limit ist überschritten").

• Die graphische Darstellung von Ereignissen erfolgt durch abgerundete Recht-

ecke.

Anhand der beiden Basiselemente (Funktionen, Ereignisse) lassen sich Geschäftspro-

zesse durch EPK-Modelle darstellen. Sie beschreiben für einen Geschäftsprozessablauf,

welche Ereignisse welche Funktionen auslösen und welche Ereignisse von welchen

Funktionen erzeugt werden. Ereignisse und Funktionen treten dabei stets alternierend

auf. Gerichtete Pfeile stellen die Verbindungen zwischen ihnen her. Der Wechsel von

Ereignissen und Funktionen ohne Verzweigungen wird als Sequenz bezeichnet.

Nichtsequenzielle Prozessabläufe (Parallelitäten, Verzweigungen) lassen sich in EPKs

durch die Anwendung von Verknüpfungsoperatoren zwischen Ereignissen und Funk-

tionen darstellen. Folgende Verknüpfungen sind möglich:29

Name Bedingung Grafisches Symbol

Konjunktion (UND-Verknüpfung)

a und b

Disjunktion (ENTWEDER/ODER-Verknüpfung)

Entweder a oder b

Adjunktion (ODER-Verknüpfung)

[a oder b] oder [a und b]

Tabelle 3.1: EPK-Verknüpfungsoperatoren

Unabhängig vom Verknüpfungsoperator lassen sich die folgenden vier Verknüpfungsar-

ten unterscheiden:30

• Ein oder mehrere verknüpfte Ereignis/se löst/en eine Funktion aus,

• Ein Ereignis löst mehrere verknüpfte Funktionen aus,

• Eine oder mehrere verknüpfte Funktion/en erzeugt/en ein Ereignis,

• Eine Funktion erzeugt mehrere verknüpfte Ereignisse.

29

Vgl. KELLER ET AL (1992), S. 13 30

Eine grafische Übersicht über alle Verknüpfungsarten befindet sich im Anhang, siehe A 3 Übersicht der EPK-Verknüpfungsarten


Bei der Modellierung ist zu beachten, dass einem Ereignis weder eine disjunktive (Ent-

weder/oder-) noch eine adjunktive (Oder-) Verknüpfung von Funktionen folgen darf.

Denn in diesen Fällen ist die notwendige Entscheidungskompetenz über den weiteren

Prozessablauf nicht ohne nähere Informationen gegeben.

Weiterhin gilt, dass jede Prozesskette mit einem oder mehreren Ereignis/sen beginnt

und endet (Start- bzw. Endereignis/se). Anfangs- und Endbedingungen müssen dem-

nach für jeden Prozess festgelegt sein. Dies entspricht dem realen Sachverhalt insofern,

dass jeder betrieblichen Tätigkeit ein auslösendes Ereignis vorausgeht und eine Status-

veränderung folgt. Werden einzelne Prozessketten eines Geschäftsprozessmodells ge-

trennt betrachtet, lassen sich durch Prozesswegweiser die Verbindungen zu den vor-

bzw. nachgelagerten Prozessketten herstellen. Prozesswegweiser ermöglichen es also,

einen Geschäftsprozess, in übersichtliche Teile zerlegt, modellieren zu können, ohne

dass der Gesamtzusammenhang verloren geht.

Abbildung 3.1 verdeutlicht am Beispiel einer Rechnungsstellung die Modellierung von

Geschäftsprozessen durch ereignisgesteuerte Prozessketten.

Rechnungsdatenerfassen

Rechnungs-erstellung

erforderlich

Rechnungsdatenprüfen

Rechnungsdatenvollständig

RechnungsdatenOK

RechnungsdatenNICHT OK

Rechnungsdatenüberarbeiten

Rechnungsdatenüberarbeitet

Ereignis

Prozess/Funktion

Prozessweg-weiser

Kontrollfluß

Legende:

Rechnungsformularerstellen

Rechnungsformularerstellt

Abbildung 3.1: Modell der Rechnungserstellung in EPK-Notation31

31

Vgl. ZILAHI -SZABÓ (2002), S. 35

3.2 Erweiterte Ereignisgesteuerte Prozessketten 20

3.2 Erweiterte Ereignisgesteuerte Prozessketten

Die Ereignisgesteuerten Prozessketten sind über die Basiselemente (Funktionen und

Ereignisse) hinaus durch eine Vielzahl zusätzlicher Modellierungselemente erweiterbar.

Es entstehen sogenannte erweiterte Ereignisgesteuerte Prozessketten (eEPK)32. Be-

sonders relevant sind dabei Erweiterungen durch Daten, Organisationseinheiten, IT-

Ressourcen und Leistungen:33

• Daten können durch Input- bzw. Output- Beziehungen (z.B. lesen, bearbeiten,

erzeugen, löschen, etc.) mit zugehörigen Funktionen verknüpft werden. Ver-

knüpfungen zu Ereignissen liefern nähere Informationen über den vorliegen-

den Zustand.

• Organisationseinheiten (z.B. Aufgabenträger, Abteilung, usw.) können Funk-

tionen zugeordnet werden, um die jeweilige Zuständigkeit für die Funktions-

ausführung deutlich zu machen.

• Die Verknüpfung von IT-Ressourcen zeigt für vollständig oder teilweise au-

tomatisierbare Funktionen an, welches Anwendungssystem die Ausführung

unterstützt.

• Input- und Outputleistungen können für einzelne Funktionen oder gesamte

Prozessketten aufgezeigt werden, um die einzelnen Teilbeiträge transparent zu

machen.

Lassen sich Geschäftsprozesse durch EPKs nur beschränkt auf Ereignisse und Prozesse

modellieren, erlauben eEPK eine ganzheitliche Modellierung von Geschäftsprozessen

(inkl. aller daran beteiligten Daten und Objekte).

Vorteile der EPKs bzw. eEPKs sind ihre einfache graphische Darstellung, ihr großer

Verbreitungsgrad sowie ihre starke Unterstützung durch Modellierungswerkzeuge.34

Nachteilig wirkt sich dagegen aus, dass aufgrund einer fehlenden semantischen Präzi-

sierung keine automatisierte Simulation und Auswertung von Geschäftsprozessmodel-

len möglich ist.35

32

Vgl. KELLER ET AL (1992), S. 15 33

Vgl. ROSEMANN, SCHWEGMANN (2002), S. 68 34

Z.B. ARIS-Toolset, Microsoft-Visio 35

Ein Ansatz zur Beschreibung einer Semantik für EPKs findet sich in NÜTTGENS, RUMP (2002)

3.2 Erweiterte Ereignisgesteuerte Prozessketten 21

Die folgende Abbildung modelliert den bereits dargestellten Prozess der Rechnungser-

stellung durch eEPK:


Rechnungsstellungerforderlich

Rechnungsdatenprüfen

Rechnungsdatenvollständig

RechnungsdatenOK

RechnungsdatenNICHT OK

Rechnungsdatenüberarbeiten

Rechnungsdatenüberarbeitet

Abteilung

Mit-arbeiter

EDV-Anwendung(z.B. Exel)

InterneDatenbank

AuftragBestellung

...

Rechnungs-daten

Rechnungs-daten

Datenbank Datensatz Papier-Dokument

Anwendungs-system

Organisations-einheit

(Papier-)Ordner

Abteilung

Mit-arbeiter

EDV-Anwendung(z.B. Exel)

Datei

Datenfluß,Ressourcen

Legende:

Rechnungsformularerstellen

Rechnungsformularerstellt

Rechnungs-formular

Abbildung 3.2: Darstellung einer Rechnungserstellung durch eEPK

4.1 Aufgabe der elektronischen Signatur 22

4 Die elektronische Signatur

4.1 Aufgabe der elektronischen Signatur

In vielen Bereichen der geschäftlichen und privaten Kommunikation haben Dokumente

in elektronischer Form die traditionell verwendeten Dokumente in Papierform abgelöst.

Elektronische Daten lassen jedoch nicht wie Papierdokumente handschriftlich unter-

schreiben. Das Leisten einer Unterschrift ist aber gerade im Geschäftsverkehr von gro-

ßer Bedeutung, da sie die Grundlage für eine rechtliche Anerkennung der unterschrie-

benen Dokumente bildet. Beispielsweise wird zum Abschluss eines rechtsgültigen

schriftlichen Vertrages eine Unterschrift beider Vertragspartner benötigt. Ihre besondere

Bedeutung kommt der Unterschrift aufgrund ihrer Eigenschaften zu: Eine Unterschrift

• ist einmalig und untrennbar mit der Person verbunden, die sie leistet, d.h. an-

hand der Unterschrift lässt sich die ausstellende Person eindeutig identifizieren

• und sie bestätigt das Einverständnis des Unterzeichnenden mit dem vorliegen-

den Dokumenteninhalt.36

Eine geeignete Möglichkeit, die Eigenschaften der handschriftlichen Unterschrift auf

den elektronischen Dokumentenaustausch zu übertragen, ist die Anwendung elektroni-

scher Signaturen. Eine elektronische Signatur stellt eine Art Siegel zu elektronischen

Daten dar. Anhand dieses Siegels kann zuverlässig festgestellt werden, dass die elektro-

nischen Daten

• von einer bestimmten Person signiert wurden (Nachweis der Authentizität des

Urhebers der Daten)

• und nach erfolgter Signatur nicht mehr verändert wurden (Nachweis der Integ-

rität der Daten).37

Nicht sichergestellt durch die Anwendung einer elektronischen Signatur ist (analog zur

eigenhändigen Unterschrift) die Vertraulichkeit des Inhalts. Um die Daten vor unbefug-

ter oder unerwünschter Kenntnisnahme durch Dritte zu schützen, können aber (ggf. zu-

sätzlich zu der elektronischen Signatur) elektronische Verschlüsselungsverfahren einge-

setzt werden. Zusammen mit der Verschlüsselung ist die elektronische Signatur somit

entscheidend für die Sicherheit und Authentizität bei einem elektronischen Dokumen-

tenaustausch.

36

Vgl. TC TRUSTCENTER (2001), S. 1 37

ebenda

4.2 Kryptographische Grundlagen 23

4.2 Kryptographische Grundlagen

Die kryptographischen Grundlagen der elektronischen Signaturen (im Sinne von fortge-

schrittenen bzw. qualifizierten elektronischen Signaturen, siehe Kapitel 4.3.3 bzw.

4.3.4) bildet ein sogenanntes asymmetrisches Verschlüsselungsverfahren in Verbindung

mit einer Hashfunktion.38

Eine Hashfunktion beschreibt eine mathematische Einwegfunktion die aus einer belie-

bigen Nachricht einen eindeutigen Hashwert fester Länge berechnet. Einwegfunktion

bedeutet, dass aus dem ermittelten Hashwert nicht mehr auf die der Funktion zugrunde-

liegende Nachricht geschlossen werden kann. Weiterhin haben Hashfunktionen die Ei-

genschaft, dass es praktisch unmöglich, ist andere Nachrichten zu finden, die denselben

Hashwert ergeben. Schon bei minimalen Abweichungen der Nachricht (z.B. durch Ein-

fügen eines Leerzeichens oder Kommas) entsteht ein völlig anderer Hashwert.39

Asymmetrische Verschlüsselungsverfahren (oder Public-Key-Verfahren) basieren

auf der Anwendung eines mathematischen Schlüsselpaares, bestehend aus einem priva-

ten Schlüssel (Private Key) und einem öffentlichen Schlüssel (Public Key). Die beiden

Schlüssel stehen in einer eindeutigen kryptographischen Abhängigkeit zueinander und

zwar derart, dass Signaturen, die mit dem privaten Schlüssel erstellt werden, ausschließ-

lich mit dem zugehörigen öffentlichen Schlüssel erfolgreich verifiziert werden können.

Des weiteren ist es nicht möglich, aus dem öffentlichen Schlüssel den privaten Schlüs-

sel bestimmen zu können. Ein derartiges Signatur-Schlüsselpaar ist einem Inhaber ein-

deutig zugeordnet. Der private Schlüssel dient zur Erstellung der elektronischen Signa-

turen und muss deshalb von dem Inhaber immer geheim gehalten werden. Der Besitz

und der Wert des zur Verifikation der Signatur benötigten öffentlichen Schlüssels hin-

gegen kann jedermann bekannt (publik) gemacht werden. Auf diese Weise ermöglichen

asymmetrische Verfahren, dass jedermann in den Besitz des öffentlichen Schlüssels

gelangen kann, um die vom Inhaber des Signatur-Schlüsselpaares erstellten Signaturen

überprüfen zu können.40

Das Erstellen und Verifizieren einer elektronischen Signatur erfolgt in den nachfolgend

vorgestellten Schritten:41

38

Ziel der Kryptographie ist die Entwicklung von Algorithmen zur Verheimlichung von Nachrichten 39

Nähere Informationen siehe STACH (2003), Kapitel 3.3 40

Nähere Informationen siehe STACH (2003), Kapitel 3.2.2, Kapitel 3.3 41

Vgl. RegTP (1998), S. 7-8

4.2 Kryptographische Grundlagen 24

1. Zunächst berechnet der Absender durch Anwendung einer Hashfunktion den

Hashwert über die zu signierenden Daten.

2. Der Hashwert wird nun mit dem privaten Schlüssel des Absenders verschlüs-

selt - das Ergebnis stellt die elektronische Signatur dar.

3. Die elektronische Signatur wird nun mit den Originaldaten verknüpft und an

den Empfänger übermittelt.

4. Der Empfänger entschlüsselt (gemäß dem Prinzip der asymmetrischen Ver-

schlüsselung) mit Hilfe des öffentlichen Schlüssels des Absenders die elektro-

nische Signatur und macht somit den Hashwert wieder lesbar.

5. Anschließend berechnet er (mit der gleichen Hashfunktion wie sie der Absen-

der angewandt hat) den Hashwert über die ihm vorliegenden Daten und ver-

gleicht diesen mit dem zuvor entschlüsselten Hashwert. Sind beide Werte i-

dentisch, kann der Empfänger sichergehen, dass die Daten nach Ausstellen der

Signatur nicht mehr verändert wurden (Nachweis der Integrität der Daten),

und dass die Signatur von dem Inhaber des zur Verifikation eingesetzten öf-

fentlichen Schlüssels erzeugt wurde, denn nur dieser besitzt den, der Ver-

schlüsselung des Hashwertes zugrundeliegenden, privaten Schlüssel (Nach-

weis der Authentizität des Urhebers der Signatur).

Die Vertrauenswürdigkeit einer auf diese Weise erstellten elektronischen Signatur ba-

siert zum einen auf der Geheimhaltung des privaten Schlüssels und zum anderen auf der

Voraussetzung, dass es nicht möglich ist, aus dem bekannten öffentlichen Schlüssel auf

den korrespondierenden privaten Schlüssel zu schließen. Um Letzteres sicherzustellen

wird bei der Erstellung des Schlüsselpaares der sog. RSA-Algorithmus42 (benannt nach

seinen Erfindern Rivest, Shamir, Adleman) eingesetzt. Das RSA-Verfahren erzeugt für

eine Anwendung in einem asymmetrischen Verschlüsselungsverfahren geeignete

Schlüsselpaare mit einer bestimmten Länge. Nach dem heutigen Stand der Technik gel-

ten Schlüssel mit einer Länge von 1024 Bit (das entspricht etwa einer 300stelligen De-

zimalzahl) als sicher. Selbst bei einem gemeinsamen Einsatz aller derzeit weltweit zur

Verfügung stehenden Computersysteme würde es bei dieser Schlüssellänge mehrere

Jahre dauern, einen einzelnen privaten Schlüssel zu errechnen.43 Um aber auch zukünf-

tig maximale Sicherheit zu gewährleisten, kann die Schlüssellänge variabel erhöht wer-

den.

42

Nähere Informationen siehe STACH(2003), Kapitel 3.2.2.1 43

Vgl. Deutsche Post Signtrust, abrufbar unter http://www.signtrust.de/index.php?.menu=pki_grundlagen&menu2=elektronische _signatur&menu3=funtionsweise, abgerufen am 02.06.03

4.3 Rechtliche Grundlagen 25

4.3 Rechtliche Grundlagen

4.3.1 Einleitung

Das in Deutschland am 1. August 1997 als weltweit erstes nationales Gesetz dieser Art

in Kraft getretene Signaturgesetz (SigG97)44 sieht Regelungen für den Einsatz digitaler

Signaturen vor. Unter einer digitalen Signatur wird gemäß § 2 Abs. 1 SigG97 ein mit

einem privaten Schlüssel erzeugtes Siegel zu digitalen Daten verstanden, durch das sich

mit Hilfe eines zugehörigen öffentlichen Schlüssels der Inhaber des Schlüsselpaares und

die Unverfälschtheit der Daten feststellen lassen.

Am 1. Juni 2001 wurde das deutsche Signaturgesetz von 1997 durch Inkrafttreten des

neuen Signaturgesetz 2001 (SigG01)45 abgelöst. Das SigG01 erfüllt zum einen die recht-

lichen Ausführungen der 1999 verabschiedeten EU-Richtlinie über gemeinschaftliche

Rahmenbedingungen für elektronische Signaturen (EU-Richtlinie 1999/93/E)46 und ver-

arbeitet zum anderen die im Umgang mit dem ersten Signaturgesetz laut gewordene

Kritik. 47

In der Neufassung wird gegenüber dem alten Signaturgesetz von 1997 nicht mehr von

einer digitalen sondern allgemeiner von einer elektronischen Signatur gesprochen, bei

der drei hierarchisch gegliederte Sicherheitsstufen unterschieden werden (siehe Kapitel

4.3.2- 4.3.4). Des weiteren werden die im Zusammenhang mit einer elektronischen Sig-

natur stehenden Begriffe wie Zertifikat, Zertifizierungsdiensteanbieter, Signaturerstel-

lungseinheit, etc. definiert und Anforderungen an diese festgelegt (siehe Kapitel 4.3.5 -

4.3.8).

4.3.2 Einfache elektronische Signaturen

Eine elektronische Signatur beschreibt gemäß § 2 Nr. 1 SigG01 elektronische Daten,

die anderen elektronischen Daten beigefügt oder logisch mit diesen verknüpft sind und

die zur Authentifizierung dienen. Beispielsweise handelt es sich bereits bei einer hand-

schriftlichen Unterschrift, die eingescannt und mit elektronischen Daten verknüpft wird,

um eine elektronische Signatur.48

44

SIGNATURGESETZ (1997) 45

SIGNATURGESETZ (2001) 46

EU-RICHTLINIE (1999/93/E) 47

Nähere Informationen siehe STACH (2003), Kapitel 2.4.1 48

Vgl. HOERETH, ROISCH, SCHIEGL (2001), S. 5


4.3.3 Fortgeschrittene elektronische Signaturen

Bei einer fortgeschrittenen elektronischen Signatur handelt es sich gemäß § 2 Nr. 2

SigG01 um eine elektronische Signatur, deren Erstellung auf der Anwendung eines Sig-

naturschlüssels beruht und die zusätzlich folgende Voraussetzungen erfüllt:

• Die Signatur wird ausschließlich dem Signaturschlüssel-Inhaber zugeordnet.

• Anhand der Signatur muss eine Identifizierung des Signaturschlüssel-Inhabers

möglich sein.

• Die Signatur muss mit Mitteln erzeugt werden, die der Signaturschlüssel-

Inhaber unter seiner alleinigen Kontrolle halten kann.

• Die Signatur muss derart mit den Daten auf die sie sich bezieht verknüpft sein,

dass eine nachträgliche Veränderung der Daten erkannt werden kann.

Die geforderten Voraussetzungen erlauben, dass die der Erstellung und Verifikation

einer fortgeschrittenen elektronischen Signatur zugrundeliegenden elektronischen

Schlüssel (Signaturschlüssel und Signaturprüfschlüssel) von dem Nutzer selbst erzeugt

werden können (z.B. mittels einer geeigneten Software49). Der Nutzer signiert die Daten

mit seinem Signaturschlüssel (privaten Schlüssel) und stellt den eindeutig zugehörigen

Signaturprüfschlüssel (öffentlichen Schlüssel) in seinem Namen öffentlich bereit. Der

Empfänger der signierten Daten hat somit die Möglichkeit durch Prüfung der fortge-

schrittenen elektronischen Signatur verbindlich feststellen zu können, dass die Daten

von dem angegebenen Inhaber des Signaturprüfschlüssels stammen und unverfälscht

sind. Es ist ihm aber nicht möglich die tatsächliche Identität des Signaturprüfschlüssel-

Inhabers vertrauenswürdig zu überprüfen.

Fortgeschrittene elektronische Signaturen sind nach den derzeit in Deutschland und in

der EU geltenden Gesetzen im Rechtsverkehr nicht anerkannt.

4.3.4 Qualifizierte elektronische Signaturen

Eine qualifizierte elektronische Signatur gemäß § 2 Nr. 3 SigG01 liegt vor, wenn die

Voraussetzungen der fortgeschrittenen elektronischen Signatur und darüber hinaus noch

folgende Anforderungen erfüllt sind:

• Die Signatur muss auf einem zum Zeitpunkt ihrer Erzeugung gültigen qualifi-

zierten Zertifikat beruhen.

49

Bekanntestes Beispiel dafür ist die kostenlose Software PGP, siehe dazu http://www.pgpi.org/


• Die Signatur muss mit einer sicheren Signaturerstellungseinheit erzeugt wer-

den.

Anhand des zu ihrer Erzeugung notwendigen qualifizierten Zertifikates (siehe Kapitel

4.3.5) ist es möglich, eine vertrauenswürdige Überprüfung der Identität des Urhebers

der qualifizierten elektronischen Signatur vorzunehmen.

Qualifizierte elektronische Signaturen sind EU-weit der handschriftlichen Unterschrift

gleichgestellt. Ein mit einer qualifizierten elektronischen Signatur versehenes elektroni-

sches Dokument bietet somit die gleiche rechtliche Anerkennung wie ein handschrift-

lich unterschriebenes Papierdokument. Dies wurde im Zuge der EU-Richtlinie über ge-

meinschaftliche Rahmenbedingungen für elektronische Signaturen von 1999 für alle

Mitgliedsstaaten festgelegt und musste bis zum 19. Juli 2001 in die nationalen Gesetze

übernommen werden.

4.3.5 Qualifizierte Zertifikate

Unter einem Zertifikat versteht § 2 Nr. 7 Sig01 eine elektronische Bescheinigung, an-

hand derer der öffentlich zugängliche Signaturprüfschlüssel einer Person eindeutig zu-

geordnet wird und die Identität dieser Person überprüft werden kann.

Ein qualifiziertes Zertifikat beschreibt ein Zertifikat, welches von einem Zertifizie-

rungsdiensteanbieter (siehe Kapitel 4.3.7) ausgestellt wird. Der Zertifizierungs-

diensteanbieter bescheinigt (als vertrauenswürdige Instanz) anhand des qualifizierten

Zertifikates, die eindeutige Zuordnung eines Signaturprüfschlüssels zu einer bestimmten

Person. Qualifizierte Zertifikate können ausschließlich an natürliche Personen ausge-

stellt werden und enthalten gemäß § 7 SigG01 u.a. die folgenden Daten:

• den Namen des Signaturschlüsselinhabers,

• den zugeordneten Signaturprüfschlüssel,

• eine laufende Nummer des Zertifikates,

• Beginn und Ende der Gültigkeit des Zertifikates,

• den Namen des Zertifizierungsdiensteanbieter,

• nach Bedarf Attribute des Signaturschlüsselinhabers.

Die Gültigkeit eines qualifizierten Zertifikates ist auf höchstens 5 Jahre begrenzt. Es

kann aber auch auf Verlangen des Inhabers vor Ablauf der Gültigkeit gesperrt werden.

Eine Sperrung kann jedoch nur für die Zukunft erfolgen, rückwirkend ist sie unzulässig.


4.3.6 Sichere Signaturerstellungseinheiten

Eine sichere Signaturerstellungseinheit ist in § 2 Nr. 10 SigG01 definiert als eine für

qualifizierte elektronische Signaturen bestimmte, den Anforderungen des SigG entspre-

chende Software- und Hardwareeinheit zur Speicherung und Anwendung eines Signa-

turschlüssels. In der Praxis werden dafür nicht auslesbare Chip-Karten (sog. Smart-

Cards) eingesetzt, die über ein Kartenlesegerät mit dem Computer verbunden werden

und durch eine geheime PIN-Nummer oder durch biometrische Merkmale (z.B. Finger-

abdruck) des Karteninhabers vor Missbrauch geschützt sind. Die SmartCards werden in

Verbindung mit einem qualifizierten Zertifikat durch einen Zertifizierungsdiensteanbie-

ter vergeben.

4.3.7 Zertifizierungsdiensteanbieter

Als Zertifizierungsdiensteanbieter werden gemäß § 2 Nr. 8 SigG01 natürliche oder ju-

ristische Personen bezeichnet, die qualifizierte Zertifikate oder qualifizierte Zeitstem-

pel50 ausstellen. Zu den Aufgaben eines Zertifizierungsdiensteanbieter gehören im We-

sentlichen:

• Die Identifizierung einer Person und Bestätigung der eindeutigen Zuordnung

eines öffentlichen Signaturprüfschlüssels zu der Person durch Ausstellen eines

entsprechenden Zertifikates.

• Die Erzeugung der einem Zertifikat zugrundeliegenden Signaturschlüssel und

Aushändigung des privaten Signaturschlüssels auf einer sicheren Signaturer-

stellungseinheit (SmartCard) an den Zertifikatsinhaber.

• Das Führen eines jederzeit erreichbaren, öffentlich zugänglichen Verzeichnis-

und Sperrdienstes für vergebene Zertifikate, um eine Überprüfung der Gültig-

keit von Zertifikaten durch Dritte und eine Sperrung eines Zertifikates durch

den Inhaber zu ermöglichen.

Der Betrieb eines Zertifizierungsdienstes steht jeder natürlichen oder juristischen Person

(z.B. Unternehmen) frei. Allerdings muss ein Zertifizierungsdiensteanbieter verschiede-

nen gesetzlich festgelegten Anforderungen und Sicherheitspflichten (z.B. bezüglich

Fachwissen des Personals, Sicherheit der Zertifizierungsverfahren, etc.) nachkommen.

Dazu gehört insbesondere die Pflicht, die Identität einer Person, die ein qualifiziertes

50

Unter einem qualifizierten Zeitstempel versteht das SigG01 gemäß § 2 Nr. 14 eine elektronische Bescheinigung des Zertifi- zierungsdiensteanbieters, dass ihm bestimmte elektronische Daten zu einem bestimmten Zeitpunkt vorgelegen haben.


Zertifikat beantragt hat, sorgfältig zu prüfen. Qualifizierte Zertifikate werden deshalb in

der Regel nur auf Vorlage des Personalausweises oder Reisepasses ausgestellt. Die Ein-

haltung der Anforderungen und Pflichten wird von staatlicher Seite nicht kontrolliert,

vielmehr stehen die Zertifizierungsdiensteanbieter unter einem Zwang zur Selbstkon-

trolle indem ihnen umfassende Haftungsregelungen bei einer Verletzung der gesetzlich

vorgeschriebenen Pflichten auferlegt sind (siehe § 11 SigG01). Um einen eventuellen

Schadensersatz gegenüber Dritten sicherzustellen, müssen sie deshalb vor Inbetrieb-

nahme des Dienstes eine geeignete Deckungsvorsorge nachweisen.

Im Unterschied zum Signaturgesetz von 1997 ist der Betrieb eines Zertifizierungsdiens-

tes gemäß § 4 Abs. 1 SigG01 nicht mehr genehmigungspflichtig sondern lediglich an-

zeigungspflichtig gegenüber der Regulierungsbehörde für Telekommunikation und

Post (RegTP). Die RegTP fungiert als den Zertifizierungsdiensteanbietern gesetzlich

vorgeschriebene übergeordnete Instanz (sog. Wurzelinstanz). Bei Inbetriebnahme stellt

sie dem Zertifizierungsdiensteanbieter ein qualifiziertes Zertifikat aus, welches dieser

zum Signieren der von ihm ausgestellten Zertifikate einsetzen muss, um eine vertrau-

enswürdige Zuordnung der Zertifikate zu dem jeweiligen Inhaber zu gewährleisten. Die

von der RegTP ausgestellten Zertifikate sind wiederum mit deren privaten Schlüssel

signiert, so dass diese ebenfalls auf Vertraulichkeit geprüft werden können. Auf diese

Weise entsteht eine mehrstufige Sicherheitsstruktur an deren Ende die RegTP als staat-

lich anerkannte vertrauenswürdige Instanz steht.

4.3.8 Akkreditierte Zertifizierungsdiensteanbieter

Nach § 15 SigG01 können sich Zertifizierungsdiensteanbieter einem freiwilligen Akk-

reditierungsverfahren durch die RegTP unterziehen. Ein qualifiziertes Zertifikat eines

akkreditierten Zertifizierungsdiensteanbieters ist Grundlage zum Ausstellen einer quali-

fizierten elektronischen Signatur mit Anbieterakkreditierung wie sie insbesondere

nach § 14 Abs. 4 Satz 2 Umsatzsteuergesetz (UStG) zur Erstellung steuerrechtlich aner-

kannter Rechnungen benötigt wird (siehe Kapitel 5.1.5).

Eine erfolgreiche Akkreditierung bescheinigt dem Zertifizierungsdiensteanbieter, dass

dieser, regelmäßig kontrolliert durch die RegTP bzw. durch von der RegTP beauftragte

Prüfstellen, alle durch das Signaturgesetz geforderte Pflichten und Sicherheitsvorkeh-

rungen erfüllt. Um die erteilte Akkreditierung gegenüber Dritten nachweisen zu können,

wird dem Zertifizierungsdiensteanbieter ein Zertifikat mit entsprechenden Angaben von

4.4 Das Signatur-Verfahren aus Sicht des Anwenders 30

Seiten der RegTP ausgestellt und mit deren privaten Schlüssel elektronisch signiert.

Eine Liste aller akkreditierten und nicht-akkreditierten Zertifizierungsdiensteanbieter ist

unter http://www.regtp.de einsehbar. Des weiteren lassen sich unter http://www.nrca-

ds.de die von der RegTP ausgestellten Zertifikate online auf Gültigkeit überprüfen.

4.4 Das Signatur-Verfahren aus Sicht des Anwenders

Zum Ausstellen einer qualifizierten elektronischen Signatur gemäß SigG01 benötigt der

Anwender eine sog. Signatur-Public-Key-Infrastruktur (Signatur-PKI) , bestehend

aus

• einem qualifizierten Zertifikat (mit/ohne Anbieterakkreditierung),

• einer zugehörigen SmartCard (als sichere Signaturerstellungseinheit),

• einem Kartenlesegerät und

• entsprechender Signatursoftware.

Die Kosten für ein qualifiziertes Zertifikat und die damit verbundenen Leistungen eines

Zertifizierungsdiensteanbieters sind von Anbieter zu Anbieter unterschiedlich, belaufen

sich aber im Schnitt auf ca. 50,- € pro Jahr. Die einmaligen Kosten für die SmartCard

liegen durchschnittlich bei ca. 20,- €, hinzu kommen 80,- € bis 200,- € (anbieterabhän-

gig) für ein Kartenlesegerät. Die Signatursoftware wird in der Regel kostenlos zusam-

men mit der SmartCard ausgegeben.51

Der genaue Ablauf der Signaturerstellung unter Anwendung einer Signatur-PKI ist ab-

hängig von der eingesetzten Signatursoftware, prinzipiell gestaltet er sich für den An-

wender folgendermaßen (vgl. dazu Abbildung 4.1):

1. Zunächst wird das zu signierende elektronische Dokument ausgewählt und die zur

Erstellung der qualifizierten elektronischen Signatur eingesetzte Signatursoftware

aufgerufen. Diese kann als PlugIn mit anderen Softwareprodukten verknüpft sein

(z.B. mit einem E-Mail-Client) oder als eigenständiges Programm arbeiten.

2. Anschließend wählt der Anwender sein (der Signatur zugrundeliegendes) qualifi-

ziertes Zertifikat aus, führt die zugehörige SmartCard in das Lesegerät ein und star-

tet den Signaturvorgang.

51

Vgl. STACH (2003), Kapitel 5


3. Bevor dieser durchgeführt wird, erscheint eine Warnmeldung, die den Anwender

(mit der Möglichkeit zum Abbruch) darauf hinweist, dass er im Begriff ist, eine

rechtsgültige elektronische Signatur über das ausgewählte Dokument zu erzeugen.

4. Ist der Anwender mit der Erstellung der Signatur einverstanden, muss er sich an-

schließend durch Eingabe seiner geheimen PIN-Nummer als rechtmäßiger Inhaber

des Zertifikates authentifizieren. Dadurch wird sichergestellt, dass die Signatur nur

durch die dazu berechtigte Person ausgestellt werden kann.

5. Nach erfolgreicher Authentifizierung berechnet die Signatursoftware den Hashwert

über das ausgewählte Dokument und übermittelt diesen an die SmartCard. Auf die-

ser wird der Hashwert mit Hilfe des auf der SmartCard gespeicherten privaten

Schlüssel des Zertifikatsinhabers verschlüsselt. Das Ergebnis stellt die qualifizierte

elektronische Signatur des Dokuments dar und wird zurück an die Software übertra-

gen.

6. Die Software verknüpft nun die elektronische Signatur und das qualifizierte Zertifi-

kat (inkl. des öffentlichen Schlüssels) des Signierers mit dem Originaldokument und

erzeugt eine aus diesen Daten bestehende Signaturdatei.

Herrn Müller Büroartikel GmbH Manfred Mustermann Hans Müller Musterstrasse 14 Müllerweg 24 34651 Musterstadt 73564 Mühlenstadt Volksbank Mühlenstadt, BLZ 789654, Kto-Nr. 12345 Datum 26. März 2003-05-15 Rechnungsnummer: 4711

ABRECHNUNG Für meine Lieferung der unten aufgeführten Artikel gemäß ihrer Bestellung vom 12. Februar 2003 gestatte ich mir zu berechnen:

Artikelnr. Bezeichnung Menge Einzelpreis Preis

123A-4 Drehstuhl "Aida", schwarz 2 129,90 259,80

231C-12 Tintenpatrone HP 23A 3 36,90 110,70

16S-11 Pack Kopierpapier DIN A4 weiß 80g 12 5,99 71,88

345R-23 Pack Folienstifte bunt

1 8,59 8,59

129A-1 Halogen-Lampe "Jojo", rot

1 139,50 139,50

Summe 810,60

Zuzüglich 16% Mehrwertsteuer 129,70

Gesamtgebühr 940,30

Mit freundlichen Grüßen Müller Büroartikel GmbH

-----BEGIN HASH-----d5da3783ea26bc60f4b7584df4227866=8S8V-----END HASH-----

SmartCard

AsymmetrischeVerschlüsselung

Privater SchlüsselPasswort (PIN) des Absenders

-----BEGIN SIGNATURE-----Version: 7.3fgTz78HGbnmja2T546hj09LK235473Ghnbv778BG5123fgGhK9==234thT-----END SIGNATURE-----

QualifiziertesZertifikat

Herrn Müller Büroartikel GmbH Manfred Mustermann Hans Müller Musterstrasse 14 Müllerweg 24 34651 Musterstadt 73564 Mühlenstadt

Volksbank Mühlenstadt, BLZ 789654, Kto-Nr. 12345 Datum 26. März 2003-05-15 Rechnungsnummer: 4711



123A-4 Drehstuhl "Aida", schwarz 2 129,90 259,80

231C-12 Tintenpatrone HP 23A

3 36,90 110,70

16S-11 Pack Kopierpapier DIN A4 weiß 80g

12 5,99 71,88

345R-23 Pack Folienstifte bunt 1 8,59 8,59


1 139,50 139,50

Summe 810,60




OriginaldokumentQualifiziert elektronisch

signiertes Dokument

Hashfunktion

Signatursoftware

Abbildung 4.1: Erstellen einer qualifizierten elektronischen Signatur52

52

Vgl. DATEV E:SECURE


Das Signaturgesetz sieht keine Regelungen für die Überprüfung elektronischer Signatu-

ren vor. Wer allerdings auf eine Signatur oder ein Zertifikat vertraut ohne eine vorheri-

ge Überprüfung vorgenommen zu haben, trägt im Falle einer Schadensersatzforderung

eine Mitschuld, aufgrund dessen der Schadenersatzanspruch gemindert werden kann

oder sogar ganz entfällt.

Zur Verifikation einer qualifizierten elektronischen Signatur wird eine geeignete Prüf-

software (sog. Signatur-Verifier) benötigt. Für eine Signaturprüfung mit voller rechtli-

cher Beweiskraft ist außerdem ein Internet-Zugang notwendig. Sie umfasst neben der

(lokalen) Verifikation der qualifizierten elektronischen Signatur auch eine Online-

Überprüfung der gesamten zugrundeliegenden Zertifikate (vom Anwender-Zertifikat

über das Zertifizierungsdienst-Zertifikat bis hin zur RegTP). Dies wird allerdings nicht

durch jede Signatursoftware unterstützt und muss deshalb evtl. manuell durchgeführt

werden.

Eine vollständige Überprüfung verläuft in den folgenden Prüfstufen:

1. Zunächst erfolgt die lokale (offline) Prüfung der Korrektheit der elektronischen Sig-

natur. Dazu startet der Anwender die Prüfsoftware und wendet sie auf das elektro-

nisch signierte Dokument an. Die Prüfsoftware entschlüsselt zunächst die elektroni-

sche Signatur mit Hilfe des öffentlichen Schlüssels aus dem angehängten Zertifikat

des Signierers, so dass der Hashwert wird lesbar wird. Anschließend berechnet sie

einen Hashwert über das vorliegende Dokument, vergleicht beide Werte und gibt

das Ergebnis (z.B. "Signaturprüfung erfolgreich" bzw. "Signaturprüfung nicht er-

folgreich" bei Gleichheit bzw. Ungleichheit der Hashwerte) zusammen mit dem

Zeitpunkt der Signaturprüfung aus. Des Weiteren werden die genauen Angaben des

zugrundeliegenden qualifizierten Zertifikates angezeigt (Inhaber, Aussteller, öffent-

licher Schlüssel, etc.).


Entschlüsselung

-----BEGIN SIGNATURE-----Version: 7.3fgTz78HGbnmja2T546hj09LK235473Ghnbv778BG5123fgGhK9==234thT-----END SIGNATURE-----

Herrn Müller Büroartikel GmbH Manfred Mustermann Hans Müller Musterstrasse 14 Müllerweg 24 34651 Musterstadt 73564 Mühlenstadt Volksbank Mühlenstadt, BLZ 789654, Kto-Nr. 12345 Datum 26. März 2003-05-15 Rechnungsnummer: 4711



123A-4 Drehstuhl "Aida", schwarz

2 129,90 259,80

231C-12 Tintenpatrone HP 23A

3 36,90 110,70

16S-11 Pack Kopierpapier DIN A4 weiß 80g 12 5,99 71,88

345R-23 Pack Folienstifte bunt

1 8,59 8,59


1 139,50 139,50

Summe 810,60





Hashfunktion


Öffentlicher Schlüsseldes Absenders

Ergebnis derSignaturprüfung

Signatur-Prüfsoftware

Qualifiziert elektronischsigniertes Dokument

Ver

glei

ch

Abbildung 4.2: Lokale Signaturprüfung mit einer Signatur-Prüfsoftware

2. Anschließend wird das angehängte Absender-Zertifikat durch einen Online-Abruf

des Verzeichnisdienstes, der für das Ausstellen des Zertifikates verantwortlichen

Zertifizierungsstelle, auf Vorhandensein, Gültigkeit und eventuelle Sperrung zum

aktuellen Zeitpunkt geprüft. Um zusätzlich die Vertrauenswürdigkeit der Zertifi-

katsangaben zu überprüfen, wird die Signatur des Zertifikates mit Hilfe des öffentli-

chen Schlüssels des Zertifizierungsdiensteanbieters auf Korrektheit geprüft.

3. Die von dem Zertifizierungsdiensteanbieter über das Zertifikat ausgestellte Signatur

basiert auf einem von der RegTP für den Zertifizierungsdiensteanbieter ausgestellten

und signierten Zertifikat, welches bei dem Verzeichnisdienst der RegTP online ab-

gerufen und überprüft werden muss. Abschließend muss der Anwender nun noch die

Signatur der RegTP verifizieren.

Einige Anbieter von Signatursoftware bzw. kompletten Signatur-PKIs bieten eine kos-

tenlose Signaturprüfsoftware an, die den jeweiligen Empfängern von signierten Daten

zur Überprüfung der Signatur zur Verfügung gestellt werden kann.53

53

Beispielsweise Utimaco Safeware AG oder Datev eG

5.1 Die Rechnung im deutschen Umsatzsteuerrecht 34

5 Gesetzliche Rahmenbedingungen der elektronischen Rech-nungsstellung

5.1 Die Rechnung im deutschen Umsatzsteuerrecht

5.1.1 Einleitung

Die deutsche Rechtsprechung erkennt durch Computersysteme automatisch erzeugte

und per Datenübertragung übermittelte elektronische Willensäußerungen als rechtlich

ordnungsgemäß an. Gemäß des Bürgerlichen Gesetzbuches (BGB)54 herrscht Formfrei-

heit in der Art und Weise wie Willenserklärungen geäußert und Verträge abgeschlossen

werden können, sofern keine bestimmte Form gesetzlich vorgeschrieben wird.55 Für die

Rechnungsstellung sind derartige Formvorschriften im BGB nicht vorhanden, somit ist

der elektronische Versand von Rechnungen im Geschäftsverkehr grundsätzlich mög-

lich.56

Problematisch ist aber die Anerkennung elektronischer Rechnungen durch die Finanz-

behörden. Insbesondere ist die Berechtigung eines Unternehmens, empfangene Rech-

nungen zum Vorsteuerabzug gegenüber dem Finanzamt geltend zu machen, im deut-

schen Umsatzsteuergesetz (UStG)57 an eine in der Schriftform vorliegende Rechnung

gebunden.

Ab 01.01.2002 sind nun elektronische Rechnungen den Rechnungen in Papierform im

UStG gleichgestellt und berechtigen somit zum Vorsteuerabzug. Voraussetzung für eine

Gleichstellung im Sinne des UStG ist aber, dass die elektronischen Rechnungen zum

einen die allgemeinen Voraussetzungen an eine ordnungsgemäße Rechnung erfüllen

(siehe Kapitel 5.1.3) und zum anderen mit einer qualifizierten elektronischen Signatur

mit Anbieterakkreditierung (gemäß § 15 Abs. 1, siehe Kapitel 4.3.8) versehen sind. Mit

dieser Neuregelung wurden gesetzliche Rahmenbedingungen für einen papierlosen,

steuerrechtlich anerkannten Rechnungsaustausch zwischen Unternehmen geschaffen.

Damit wurde insbesondere entsprechenden Forderungen seitens der Wirtschaft Rech-

nung getragen.

54

BGB (2002) 55

Das BGB unterscheidet neben der Textform und der vereinbarten Form insbesondere die Schriftform und die elektronische Form. 56

Vgl. STRÖMER (1997), S. 86 57

Die im Weiteren aufgeführten Paragraphen des UStG werden im Anhang zitiert, siehe A1


5.1.2 Das Prinzip des Vorsteuerabzugs

Eine zum Verkauf angebotene Ware durchläuft in der Regel von der Erstellung bis zum

Kauf durch den Endverbraucher mehrere Stufen einer Handelskette. Auf jeder Stufe

dieses Warenweges wird der Wert der Ware durch Kosten und Gewinn erhöht. Dieser

Mehrwert je Stufe schlägt sich im Unterschied zwischen Einkaufs- und Verkaufspreis

nieder.58

Der Staat beteiligt sich an dieser Wertschöpfung auf jeder Stufe in Form der Mehrwert-

bzw. Umsatzsteuer (MwSt bzw. USt) auf Grundlage des Umsatzsteuergesetzes (UStG).

Die Umsatzsteuer beträgt in Deutschland im allgemeinen 16% (=allgemeiner Steuer-

satz) und für Lebensmittel und bestimmte andere Umsätze 7% (=ermäßigter Steuer-

satz).59 Da der Unternehmer aber diese abzuführende Umsatzsteuer dem Kunden in

Rechnung stellt, belastet sie ihn nicht und wird letztendlich nur von dem Endverbrau-

cher getragen. In diesem Zusammenhang wird auch von einer Steuerabwälzung gespro-

chen.

Beispielsweise fordert der Produzent Umsatzsteuer von einem Großhändler beim Ver-

kauf seiner Produkte an diesen. Auf die von dem Großhändler an einen Einzelhändler

weiterveräußerte Ware, berechnet der Großhändler wiederum Umsatzsteuer auf den

Weiterverkaufspreis. Zum Abschluss der Handelskette wird der Endverbraucher beim

Kauf der Ware vom Einzelhändler mit der gesamten Umsatzsteuer belastet.

Das Prinzip des Vorsteuerabzugs besteht darin, dass Unternehmer im Sinne von § 2

UStG (im Beispiel: Produzent, Groß-, und Einzelhändler) die von ihnen beim Kauf ei-

nes Produktes gezahlte Umsatzsteuer (auch als Vorsteuer bezeichnet) mit ihrer Umsatz-

steuerschuld beim Verkauf verrechnen können. Sie müssen somit nur die Umsatzsteuer

auf den in ihrer Stufe der Handelskette hinzugewonnenen Mehrwert des Produktes an

das Finanzamt abführen.60

58

Vgl. SCHMOLKE, DEITERMANN (1998), S. 60 59

ebenda 60

Vgl HOERETH, ROISCH, SCHIEGL (2001), S. 2


Die nachfolgende Abbildung stellt das Umsatzsteuersystem und das Prinzip des Vor-

steuerabzuges aus Sicht eines Unternehmens anhand einer Eingangs- und Ausgangs-

rechnung eines im Unternehmen weiterverarbeiteten Produktes dar.

Weiterverarbeitung

Das Umsatzsteuersystem mit Vorsteuerabzug

aus der Perspektive eines Unternehmens

Abbildung 5.1: Das Umsatzsteuersystem aus der Perspektive eines Unternehmens61

Das Prinzip des Vorsteuerabzuges wird in der nachfolgenden Tabelle an einem Beispiel

eines vierstufigen Warenweges weiter verdeutlicht. Die auf den jeweiligen Umsatzstu-

fen aufgeführte Rechnung stellt sowohl die Ausgangsrechnung eines Unternehmens

61

Vgl. BÖING, http://www.nboeing.de, Abruf 20.01.03


dieser Umsatzstufe als auch die Eingangsrechnung für ein Unternehmen der folgenden

Umsatzstufe dar.

Beispiel eines vierstufigen Warenweges mit Vorsteuerabzug

Umsatzstufen Rechnung USt b. Verk.–Vorsteuer = Zahllast

Nettowert 1500,00 + 16% USt 240,00

Material-Herstellung

↓↓↓↓ Rechnungspr. 1740,00 240,00 - 240,00

Nettowert 7000,00 + 16% USt 1120,00

Weiterverarbei-tende Industrie

↓↓↓↓ Rechnungspr. 8120,00 1120,00 240,00 880,00

Nettowert 8900,00 + 16% USt 1424,00

Großhandel ↓↓↓↓

Rechnungspr. 10342,00 1424,00 1120,00 304,00

Nettowert 10000,00 + 16% USt 1600,00

Einzelhandel ↓↓↓↓

Endverbraucher Rechnungspr. 11600,00 1600,00 1424,00 176,00

Probe: 4384,00 – 2784,00 = 1600,00 Verbindlichk.– Gutschrift = Zahllast

Tabelle 5.1: Vierstufige Warenweg mit Vorsteuerabzug62

Die Rechnung spielt beim Vorsteuerabzug eine entscheidende Rolle: Um die gezahlte

Umsatzsteuer als Vorsteuer abziehen zu können, bedarf es nach § 15 Abs. 1 Satz 1 Nr. 1

UStG zum einen einer Leistung, die ein Unternehmer für einen weiteren Unternehmer

erbracht hat, und zum anderen einer Rechnung im Sinne von § 14 UStG (siehe Kapitel

5.1.3) darüber. In dieser wird das anfallende Entgelt und die darauf erhobene Umsatz-

steuer explizit ausgewiesen. Da dem Leistungsempfänger diese Rechnung tatsächlich

vorliegen muss, kann er das Ausstellen einer Rechnung gemäß § 14 Abs. 4 UStG vom

leistenden Unternehmer einfordern.

5.1.3 Inhaltliche Anforderungen an eine Rechnung

Das deutsche Umsatzsteuergesetz definiert in § 14 Abs. 1 UStG alle Angaben, die in

einer Rechnung aufgeführt werden müssen, um steuerrechtlich als solche anerkannt zu

werden. Im Einzelnen sind dies:63

• der Name und die Anschrift des leistenden Unternehmers,

62

Vgl. SCHMOLKE, DEITERMANN (1998), S. 61 63

Siehe Anhang A 1 Umsatzsteuergesetz § 14 und § 15 Abs. 1


• der Name und die Anschrift des Leistungsempfängers,

• die Menge und die handelsübliche Bezeichnung des Gegenstandes der Liefe-

rung oder die Art und den Umfang der sonstigen Leistung,

• der Zeitpunkt der Lieferung oder der sonstigen Leistung,

• das (Netto-) Entgelt für die Lieferung oder sonstige Leistung und

• der auf das Entgelt entfallenen Steuerbetrag.

Nach dem durch Artikel 1 Nr. 2 des Steuerverkürzungsbekämpfungsgesetzes vom 19.

Dezember 2001 neu eingefügten § 14 Abs. 1a UStG hat der leistende Unternehmer seit

dem 01. Juli 2002 in Rechnungen auch die ihm vom Finanzamt erteilte Steuernummer

anzugeben. Allerdings ist die Angabe der Steuernummer nicht Voraussetzung für den

Vorsteuerabzug.

In der Praxis wird häufig auch ein Rechnungsdatum und eine Rechnungsnummer ange-

geben. Das UStG enthält diesbezüglich aber bisher keine Regelung. Erst ab dem

01.01.2004 werden Rechnungsdatum und fortlaufende Rechnungsnummer zu Pflichtan-

gaben (siehe Kapitel 5.4).

Sind die geforderten Angaben vollständig enthalten, ist es unerheblich, ob die Rechnung

auch als solche bezeichnet wird. Andere Bezeichnungen sind beispielsweise Gebühren-

note, Abrechnung oder ähnliches. Als Rechnung gilt unter den Voraussetzungen des §

14 Abs. 5 UStG insbesondere auch eine Gutschrift, die ein Leistungsempfänger gegen-

über einem leistenden Unternehmer abrechnet.

5.1.4 Rechnungen in Schriftform

Der Begriff der Rechnung war und ist in § 14 Abs. 4 UStG folgendermaßen definiert:64

"Rechnung ist jede Urkunde, mit der ein Unternehmer oder in seinem Auftrag ein Drit-

ter über eine Lieferung oder sonstige Leistung gegenüber dem Leistungsempfänger ab-

rechnet, gleichgültig, wie diese Urkunde im Geschäftsverkehr bezeichnet wird."

Gemäß dieser alten Fassung (gültig bis 31.12.2001) konnte eine zum Vorsteuerabzug

berechtigende Rechnung nur die Form einer Urkunde haben. Das bedeutet, dass die

Rechnung (dem Urkundenbegriff in der Zivilprozessordnung (ZPO) entsprechend65) in

64

siehe Anhang A 1 Umsatzsteuergesetz § 14 und § 15 Abs. 1 65 Eine Urkunde im Sinne der ZPO liegt vor, wenn es sich um eine Verkörperung einer Gedankenerklärung durch Schriftzeichen

handelt, siehe ZPO (2001)


einer in einem Schriftstück verkörperten Form vorliegen musste. Eine per Post oder per

Telefax gesendete schriftliche Rechnung erfüllt diese Formerfordernis zweifelsfrei.

Eine alleinige elektronische Rechnungsdatenübermittlung z.B. per E-Mail, Datenfern-

übertragung oder Datenträgeraustausch genügte den bis dahin gültigen Anforderungen

der Finanzbehörden nicht. Ein Vorsteuerabzug durfte daraufhin noch nicht vorgenom-

men werden. Dies galt auch dann, wenn die elektronisch übermittelten Daten von dem

Leistungsempfänger ausgedruckt wurden und somit in Papierform vorlagen.

Im Falle einer elektronischen Rechnungsdatenübermittlung wurde von Seiten der Fi-

nanzbehörden eine zusätzliche schriftliche Rechungserstellung durch das leistende Un-

ternehmen gefordert. In der Praxis haben sich die Unternehmen vorwiegend mit perio-

disch ausgestellten Sammelrechnungen beholfen. Eine periodische Sammelrechnung

fasst die einzelnen Umsätze eines Datenübertragungszeitraums zusammen und stellt die

Summe schriftlich in Rechnung. Sofern eine Sammelrechnung die allgemein geforder-

ten Rechnungsangaben (siehe Kapitel 5.1.3) enthält, erfüllt sie in Verbindung mit den

gespeicherten Einzelabrechnungen, die per Datenfernübertragung oder Datenträgeraus-

tausch übermittelt wurden, die Anforderungen an eine Rechnung und ist zum Vorsteu-

erabzug berechtigt.

5.1.5 Die elektronische Rechnung

Im Rahmen des deutschen Steueränderungsgesetz 2001 (StÄndG2001) hat der Gesetz-

geber steuerrechtlich anerkannte elektronische Rechnungen eingeführt, indem er den

§ 14 Abs. 4 UStG um folgenden zweiten Satz mit Wirkung ab 01.01.2002 ergänzt hat:66

"Als Rechnung gilt auch eine mit einer qualifizierten elektronischen Signatur mit Anbie-

ter-Akkreditierung nach § 15 Abs. 1 des Signaturgesetzes versehene elektronische Ab-

rechnung."

Ab 01.01.2002 haben Unternehmer nun die Möglichkeit, Vorsteuerabzüge basierend auf

rein elektronisch gesendeten und empfangenen Rechnungen geltend zu machen. Es

handelt sich demnach bei der elektronischen Rechnung gemäß § 14 Abs. 4 Satz 2 UStG

um eine Rechnung mit dem nach § 14 Abs. 1 UStG (siehe Kapitel 5.1.3) geforderten

Inhalt, die anstatt in Papierform als Datei erstellt und mit einer qualifizierten elektroni-

schen Signatur mit Anbieter-Akkreditierung nach § 15 Abs. 1 des Signaturgesetzes

(siehe Kapitel 4.3.8) digital signiert wird. Die elektronische Signatur dient dabei dem

66

Siehe Anhang A 1 Umsatzsteuergesetz § 14 und § 15 Abs. 1

5.2 Zugang und Wirksamwerden elektronischer Rechnungen 40

Nachweis der Herkunft und Unverfälschtheit der Rechnung. Der Anspruch der körperli-

chen Form einer Rechnung ist unter diesen Voraussetzungen nun nicht mehr notwendig.

Die in Kraft getretene Neuregelung bezieht sich nicht nur auf elektronische Rechnun-

gen, die über das Internet oder andere Datennetze übertragen werden, sondern umfasst

auch elektronische Abrechnungen, die auf maschinell lesbaren Datenträgern wie Disket-

te, CD-ROM, DVD oder Magnetband gespeichert und übersendet werden.67

Die Möglichkeit einer elektronischen Rechnungsstellung ergänzt dabei die bestehenden

Regelungen. Das bedeutet, dass es Unternehmen nach wie vor erlaubt ist, Rechnungen

in der herkömmlichen Papierform zu erstellen oder Abrechnungsdaten elektronisch (oh-

ne elektronische Signatur) zu versenden und eine schriftliche Sammelrechnung folgen

zu lassen.

Die in § 14 Abs. 4 UStG getroffene (derzeit gültige) Regelung bezüglich der steuer-

rechtlichen Anerkennung elektronischer Rechnungen ist allerdings nicht von langer

Dauer, sondern verliert spätestens am 01.01.2004 ihre Gültigkeit. Im Rahmen der am

20.12.2001 verabschiedeten EU-Richtlinie 2001/115/EG, deren Vorgaben bis spätestens

01.01.2004 von allen Mitgliedsstaaten in das nationale Umsatzsteuerrecht umgesetzt

werden müssen, ist u.a. festgelegt, dass elektronische Rechnungen schon mit einer fort-

geschrittenen elektronischen Signatur bzw. einer qualifizierten elektronischen Signatur

anzuerkennen sind (siehe Kapitel 5.4). Welche der beiden Signaturen für eine steuer-

rechtlich anerkannte elektronische Rechnung einzusetzen ist, liegt im Entscheidungsbe-

reich des jeweiligen Staates.

5.2 Zugang und Wirksamwerden elektronischer Rechnungen

Aufgrund der aufgeführten Ergänzung des § 14 Abs. 4 UStG können Unternehmen in

Deutschland seit dem 01.01.2002 der Papierform gleichgestellte elektronische Rech-

nungen erstellen und versenden. Es stellt sich nun die Frage, ob derartige elektronische

Rechnungen nach Belieben an einzelnen Rechnungsempfänger versendet werden dürfen

und wann eine elektronische Abrechnung wirksam wird.

Grundsätzlich gilt, dass eine Abrechnung wirksam wird, wenn sie derart in den "Ein-

flussbereich" des Empfängers gelangt, dass dieser jederzeit darauf zugreifen und der

Absender mit einer Kenntnisnahme rechnen kann. Bei der papierbasierten Rechnungs-

67

Vgl. SCHMITTMANN (2001), S. 1051

5.3 Anforderungen der Finanzbehörden 41

stellung über den Postweg stellt der Briefkasten bzw. das Postfach den Einflussbereich

des Empfängers dar, da davon ausgegangen werden kann, dass der Empfänger diesen/s

regelmäßig (in der Regel täglich) kontrolliert. Analog dazu ist dies bei einer elektroni-

schen Rechnungsübermittlung per E-Mail das E-Mail-Postfach des Empfängers. Die

Rechtsprechung behandelt einen Geschäftspartner, der in der geschäftlichen Kommuni-

kation mit einer E-Mail-Adresse auftritt, demnach so wie den Empfänger von Papier-

post, d.h. es wird erwartet, dass er sein Mail-Postfach mindestens einmal täglich ab-

ruft.68

Gibt ein Geschäftskunde eine E-Mail-Adresse für Geschäftszwecke an, ist davon auszu-

gehen, dass die technischen Voraussetzungen zum Empfang elektronischer Rechnungen

auf Seiten des Rechnungsempfängers gegeben sind, so dass diese Art der Rechnungs-

stellung genutzt werden kann. Im Falle eines Rechtsstreits liegt allerdings die Nach-

weispflicht bzw. die Beweislast, dass eine elektronische Rechnung dem Einflussbereich

des Rechnungsempfängers tatsächlich zugegangen ist, auf Seiten des Absenders.

Einem Unternehmen, das Rechnungen nach wie vor nur in Papierform erhalten will, ist

es zu empfehlen, entsprechende Vereinbarungen mit den Geschäftspartnern zu treffen.

5.3 Anforderungen der Finanzbehörden

5.3.1 Umgang und Aufbewahrung elektronischer Rechnungen

Damit ein Vorsteuerabzug basierend auf elektronischen Rechnungen im Sinne von § 14

Abs. 4 Satz 2 UStG erfolgen kann, muss der Originalzustand einer übermittelten (gege-

benenfalls verschlüsselten) elektronischen Rechnungen während der gesamten Aufbe-

wahrungsfrist von 10 Jahren (gemäß § 147 Abs. 3 Abgabenordnung (AO)) für eine

mögliche Betriebsprüfung durch das Finanzamt jederzeit überprüfbar sein. Dies gilt

sowohl für das rechnungsstellende als auch für das rechnungsempfangende Unterneh-

men. Die in einem Schreiben des BMF (Bundesministerium für Finanzen) am 16. Juli

2001 veröffentlichten "Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Un-

terlagen (GDPdU)"69 stellen dafür neben den ohnehin zu beachtenden "Grundsätze ord-

nungsgemäßer DV-gestützter Buchführungssysteme (GoBS)"70 folgende Anforderungen

an den Umgang und die Aufbewahrung elektronischer Rechnungen zur steuerlichen

Anerkennung: 68

Vgl. STRÖHMER (1997), S. 89-90 69

Siehe GDPDU, II. Prüfbarkeit digitaler Unterlagen 70

Siehe GOBS


• Vor der Weiterverarbeitung der elektronischen Rechnung muss die qualifizier-

te elektronische Signatur bezüglich der Integrität der Daten und Signaturbe-

rechtigung geprüft und der Zeitpunkt der Prüfung sowie das Ergebnis doku-

mentiert werden.

• Die Speicherung der elektronischen Rechnung darf nur auf einem Datenträger

geschehen, der nachträgliche Änderungen nicht mehr zulässt. Bei einer zeit-

weiligen Speicherung auf einem änderbaren Datenträger muss das DV-System

sicherstellen, dass keine Änderungen möglich sind.

• Wird die elektronische Rechnung in ein unternehmenseigenes Format (sog.

Inhouse-Format) konvertiert, müssen beide Versionen archiviert und nach den

GoBS mit demselben Index verwaltet werden. Zusätzlich muss die konvertier-

te Version als solche gekennzeichnet sein.

• Der Signaturprüfschlüssel und das zugrundeliegende qualifizierte Zertifikat

müssen für eine nachträgliche Überprüfung der Signatur aufbewahrt werden.

• Bei einer verschlüsselt übertragenen elektronischen Rechnung ist sowohl die

verschlüsselte als auch die entschlüsselte Rechnung sowie der zugehörige

Schlüssel zur Entschlüsselung zu archivieren.

• Eingang, Archivierung und gegebenenfalls Konvertierung sowie die weitere

Verarbeitung der Rechnung müssen protokolliert werden. Die eingesetzten

Übertagungs-, Archivierungs- und Konvertierungssysteme müssen außerdem

den Anforderungen der GoBS an die Dokumentation, das interne Kontrollsys-

tem, das Sicherheitskonzept sowie an die Aufbewahrung entsprechen.

• Bei der Archivierung der elektronischen Rechnung und den zugehörigen Da-

ten ist zu beachten, dass die Haltbarkeitsdaten einiger elektronischer Archivie-

rungsmedien nicht der gesetzlich vorgeschriebenen Aufbewahrungsfrist von

10 Jahren entsprechen. Beispielsweise besitzen Disketten eine dreijährige

Mindesthaltbarkeit, Magnetband-Streamer haben sogar nur eine Mindesthalt-

barkeit von 2 Jahren. Die Empfehlung der Finanzbehörden geht dahingehend

die Archivierung auf CD-ROMs vorzunehmen, die eine Datensicherheit von

mindestens 20 Jahren versprechen.71

Weiterhin gilt, dass Dokumente, deren Signaturen im Laufe der Aufbewahrungsfrist

ihre Sicherheit verlieren (durch Ablauf der gesetzlich festgelegten Sicherheitsdauer der

zugrunde liegenden Signaturverfahren bzw. -schlüssel), mit einem dann als sicher gel- 71

Vgl. ANDRES, HUSS (2002), Kap. II.4


tenden Signaturverfahren inklusive der alten Signatur neu signiert und mit einem quali-

fizierten Zeitstempel versehen werden müssen.

5.3.2 Datenzugriff durch das Finanzamt

Als Reaktion auf die neu geschaffenen Möglichkeiten Daten elektronisch zu archivie-

ren, wird in den von dem BMF herausgegebenen GDPdU (s.o.) dem Finanzamt das

Recht eingeräumt, im Rahmen einer betrieblichen Außenprüfung auf die in elektroni-

scher Form vorhandenen Daten der Unternehmen im Lese-Zugriff (Read-Only) zu-

zugreifen. Betroffen davon sind alle steuerlich relevanten Daten (wie z.B. umsatzsteu-

erpflichtige Rechnungen) beginnend ab dem 01.01.2002, die in elektronischer Form im

Unternehmen vorliegen. Der elektronische Datenzugriff tritt neben die herkömmlichen

Prüfungsmethoden und unterscheidet die drei folgenden Arten, auf die sich die Unter-

nehmen vorbereiten müssen:

• Unmittelbarer Zugriff: Der Außenprüfer kann unmittelbar auf die Hard- und

Software des Unternehmens oder Dritter zugreifen und Daten filtern, sortieren

und auswerten.

• Mittelbarer Zugriff: Der Datenzugriff erfolgt durch einen Mitarbeiter des

steuerpflichtigen Unternehmens nach konkreten Vorgaben des Prüfers.

• Datenträgerüberlassung: Die steuerrelevanten Daten werden dem Außen-

prüfer durch das Unternehmen auf maschinell auswertbaren Datenträgern zur

Verfügung gestellt. Nach Beendigung der Prüfung werden diese zurückgege-

ben oder gelöscht.

Diese drei Möglichkeiten bestehen parallel. Von welcher bzw. von welchen Möglich-

keiten Gebrauch gemacht wird, steht im Ermessen der Finanzbehörde. Bezogen auf eine

Überprüfung von elektronischen Signaturen, die über entsprechende steuerrelevante

Daten ausgestellt wurden, ist die Datenträgerüberlassung vorgesehen. Die eigentliche

Signaturprüfung findet dann auf einem Einzelplatz-PC mit Internetanschluss (zur Onli-

ne-Prüfung der zugrundeliegenden Zertifikate) im Finanzamt statt.72

72

Vgl. SREBNE (2002), S.23


5.3.3 Anmerkungen zu den Anforderungen

Die in den GDPdU getroffenen Regelungen der Finanzbehörden bezüglich elektroni-

scher steuerlich relevanter Daten stellen die Unternehmen und deren EDV-Systeme vor

hohe Anforderungen. Um diese zu erfüllen, müssen im Allgemeinen die EDV-Systeme

entsprechend umgestellt werden. Im Falle der elektronischen Rechnungsstellung müs-

sen sowohl das rechnungsstellende als auch das rechnungsempfangende Unternehmen

entsprechende Maßnahmen treffen. Wird das eingesetzte EDV-System den Anforderun-

gen nicht gerecht, müssen Investitionen für eine Systemerweiterung oder für die Neu-

einführung eines gesetzeskonformen Systems (z.B. Dokumenten-Management-Systems

(DMS)) getätigt werden.73

In einer von PricewaterhouseCoopers Deutschland im September 2002 durchgeführten

Befragung von 64 SAP R/3 Anwendern wurde festgestellt, dass, obwohl nahezu alle

Unternehmen steuerrelevante Daten elektronisch verarbeiten, lediglich 5% der Unter-

nehmen bereits die Anforderungen erfolgreich umgesetzt haben. Weitere 17% befinden

sich in der Umsetzungsphase und 22% in der Planungsphase. 27% haben sich bisher nur

informiert, 29% hingegen haben sich noch nicht mit der Problematik auseinanderge-

setzt.74

Das Ergebnis der Befragung zeigt, dass die steuerrechtlichen Voraussetzungen für den

Versand und den Empfang elektronischer Rechnungen im Sinne des UStG in der Regel

noch nicht gegeben sind. In diesem Bereich besteht also noch ein deutlicher Handlungs-

bedarf seitens der Unternehmen, um die Voraussetzungen für einen steuerrechtlich an-

erkannten elektronischen Rechnungsaustausch zu schaffen.

Nähere Informationen und Unterstützung (z.B. in Form von Checklisten) für Steuerbe-

rater, ihre Mandanten und Unternehmen zur Umsetzung der rechtlich vorgeschriebenen

Voraussetzungen für eine ordnungsgemäße Archivierung steuerrelevanter elektroni-

scher Daten sowie für eine elektronische Steuerprüfung lassen sich in einem von Com-

pario75 eingerichteten Internet-Forum unter "http://www.elektronische-steuerpruefung

.de" abrufen.

73

Beispielsweise bietet die PBS Software GmbH entsprechende Add-ons für SAP R/3 an, siehe http://www.pbs-software.com 74

Vgl PWC (2003), S. 15 75

Nähere Information: http://www.compario.de

5.4 Internationaler Einsatz elektronischer Rechnungen 45

5.4 Internationaler Einsatz elektronischer Rechnungen

Der Einsatz elektronischer Rechnungen (aber auch Papierrechnungen) im internationa-

len Geschäftsverkehr gestaltet sich derzeit kompliziert und unpraktisch. Schuld daran

sind die von Staat zu Staat unterschiedlichen Vorschriften über die obligatorischen

Rechnungsangaben und formalen Kriterien, die zur Anerkennung einer Rechnung not-

wendig sind. Beispielsweise muss in einigen Staaten parallel zu einer aus dem Ausland

stammenden elektronischen Rechnung weiterhin eine entsprechende Papierfassung ver-

schickt werden, in anderen ist eine elektronische Rechnungsstellung aus dem Ausland

nur unter bestimmten Voraussetzungen (z.B. nur mit Sondergenehmigung) zulässig.

Um diesen Missstand innerhalb des EU-Binnenmarktes zu beheben, wurde am

20.12.2001 die EU-Richtlinie 2001/115/EG mit dem Ziel der Vereinfachung, Moderni-

sierung und Harmonisierung der mehrwertsteuerlichen Anforderungen an die Rech-

nungsstellung vom Rat der EU-Finanzminister verabschiedet.76 Die Richtlinie schreibt

ein EU-weit einheitlich geltendes Regelwerk für die Rechnungsstellung vor, welches bis

spätestens zum 01.01.2004 in das nationale Umsatzsteuerrecht der einzelnen Mitglieds-

staaten umgesetzt werden muss. Die Richtlinie u.a. legt folgendes fest:

• Neben den ohnehin in Deutschland vorgeschriebenen Rechnungsangaben (sie-

he Kapitel 5.1.3) müssen Rechnungen zum Zwecke des Vorsteuerabzuges die

folgenden zusätzlichen Bestandteile beinhalten:

§ das Ausstellungsdatum,

§ eine fortlaufende Nummer, die zur Identifizierung der Rechnung

einmalig vergeben wird,

§ die dem Unternehmer vom Finanzamt erteilte Umsatzsteuer-

Identifikationsnummer (USt-ID-Nr – nicht zu verwechseln mit der

Steuernummer).

• Elektronisch übermittelte Rechnungen sind von den Mitgliedstaaten anzuer-

kennen, sofern die Echtheit der Herkunft und die Unversehrtheit des Inhalts

gewährleistet werden. Dies kann geschehen durch:

§ Verwendung einer fortgeschrittenen Signatur gemäß der europäi-

schen Signaturrichtlinie von 1999. Alternativ dazu können die Mit-

gliedsstaaten aber auch die Verwendung einer qualifizierten elektro-

nischen Signatur verlangen.

76

Siehe EU-RICHTLINIE (2001/115/EG)

5.4 Internationaler Einsatz elektronischer Rechnungen 46

§ Anwendung von Verfahren des elektronischen Datenaustauschs

(EDI, siehe Kapitel 7.1), die die Echtheit der Herkunft und die Un-

versehrtheit des Inhalts sicherstellen. Die Mitgliedsstaaten können

aber zusätzlich ein zusammenfassendes Dokument in Papierform

(Sammelrechnung) verlangen.

Die derzeit in Deutschland gemäß § 14 Abs. 4 Satz 2 UStG geltende Regelung, elektro-

nische Rechnungen nur mit qualifizierter elektronischer Signatur mit Anbieterakkredi-

tierung zum Vorsteuerabzug anzuerkennen (siehe Kapitel 5.1.5), muss demnach der

EU-Richtlinie entsprechend angepasst werden. Welche Form der elektronischen Signa-

tur in Deutschland spätestens ab 01.01.2004 verbindlich sein wird (fortgeschritten oder

qualifiziert), steht derzeit noch nicht fest.

6.1 Funktionen und Anforderungen der Rechnungsstellung 47

6 Geschäftsprozessanalyse der papierbasierten Rechnungs-stellung

6.1 Funktionen und Anforderungen der Rechnungsstellung

Das Ausstellen und Versenden einer Rechnung stellt einen unverzichtbaren Prozess

innerhalb eines Unternehmens dar. Nahezu jedes kaufmännische Geschäft wird mit ei-

ner zugestellten Rechnung und ihrer Bezahlung abgeschlossen. Schätzungen zufolge

geschieht dies allein in Deutschland ca. zehn Milliarden Mal im Jahr.77

Eine Rechnung erfüllt grundsätzlich die folgenden drei Funktionen:78

• Zahlungsaufforderungsfunktion,

• Leistungsnachweisfunktion,

• und Marketingfunktion.

Die Funktion einer Rechnung als Zahlungsaufforderung besteht darin, dass der Rech-

nungssteller (Kreditor) gegenüber dem Kunden/Rechnungsempfänger (Debitor) erklärt,

dass er seinen Teil des Vertrages (z.B. Produktion/Lieferung eines Produktes, Erbrin-

gung einer Dienstleistung, etc.) erfüllt hat. Der Kunde wird nun durch die Rechnung

aufgefordert, seinen Teil des Vertrages, nämlich die Bezahlung der erbrachten Leistung,

zu erfüllen. Die Rechnung dient dem Kunden später als Nachweis gegenüber Dritten

(z.B. den Finanzbehörden), dass von ihm eine Zahlung verlangt wurde.

Die Leistungsnachweisfunktion erbringt eine Rechnung durch die Dokumentation der

vom Rechnungssteller erbrachten Leistungen, insbesondere dann, wenn dem Kunden

kein separater Lieferschein über die bei ihm eingegangenen Waren vorliegt. Die Doku-

mentation geschieht durch die Auflistung beispielsweise von Einzelpositionen bei einer

Produktbestellung, von geleisteten Arbeitsstunden bei einer Dienstleistung oder der

Einzelverbindungen bei einer Telekommunikationsrechnung. Auf Seiten des Rech-

nungsempfängers werden die aufgelisteten Informationen zur Rechnungsprüfung (z.B.

für einen Abgleich mit dem zugehörigen Auftragsdokument bzw. Wareneingangsbu-

chung) und eventuell zur internen Kostenrechnung benötigt.

Die Marketingfunktion einer Rechnung besteht in ihrer Verwendung als Kommunika-

tions- und Informationsmittel von Seiten des Rechnungsstellers. Weitere Produkte und

Dienstleistungen lassen sich (eventuell kundenspezifisch angepasst) im Anhang einer

Rechnung präsentieren. Gerade in den Branchen, in denen Rechnungen zwar relativ

77

Vgl. GOERS (2003) 78

Vgl. EICKER, SCHWICHTENBERG (1999), S. 148-149

6.1 Funktionen und Anforderungen der Rechnungsstellung 48

häufig verschickt werden, aber der direkte Kundenkontakt fehlt (z.B. in der Telekom-

munikationsbranche), ist dies von besonderer Bedeutung.

Die aufgeführten Funktionen einer Rechnung gelten für Rechnungen im Allgemeinen.

Innerhalb eines Unternehmens besitzen Rechnungen eine Belegfunktion. Belegfunktion

bedeutet, dass Rechnungen einen bestimmten, im Unternehmen aufgetretenen Ge-

schäftsvorfall repräsentieren und deshalb gemäß den gesetzlichen Regeln einer geordne-

ten und lückenlosen Unternehmensbuchführung aufgezeichnet (gebucht) und archiviert

werden müssen.79 Ein derartiger Geschäftvorfall kann beispielsweise der Einkauf, aber

auch der Verkauf einer Ware/Dienstleistung sein. Demnach besitzt eine Rechnung so-

wohl im rechnungsstellenden Unternehmen als auch auf Seiten des Rechnungsempfän-

gers eine Belegfunktion und muss entsprechend gebucht und archiviert werden.

In Unternehmen eingehende Rechnungen haben außerdem eine steuerrechtliche Funk-

tion. Sie berechtigen das Unternehmen zu einem Vorsteuerabzug gegenüber den Fi-

nanzbehörden. Dazu muss die Rechnung der gesetzlich vorgeschriebenen Form entspre-

chen und ordnungsgemäß verbucht und archiviert für das Finanzamt aufbewahrt werden

(siehe Kapitel 5).

Ausgerichtet an den Funktionen einer Rechnung ergeben sich im zwischenbetrieblichen

Rechnungsaustausch folgende Anforderungen an die Rechnungserstellung und Rech-

nungsübermittlung durch den Absender sowie an den Rechnungseingang und die Wei-

terverarbeitung auf Seiten des Rechnungsempfängers.

Anforderungen aus Sicht des Rech-nungsstellers (Kreditor) an Erstellung und Übermittlung einer Rechnung:

Anforderungen aus Sicht des Rech-nungsempfängers (Debitor) an Rech-nungseingang und Weiterverarbeitung:

1) Niedrige Kosten

2) Hohe Transportgeschwindigkeit

3) Zuverlässigkeit

4) Nachweisbarkeit des Rechnungszu-gangs

5) Datenschutz

6) Einsatz der Rechnung als Marketing-instrument

1) Niedrige Kosten

2) Einfache Zugänglichkeit

3) Verständlichkeit

4) Genauigkeit

5) Auswertbarkeit

6) Weiterverarbeitbarkeit

7) Archivierbarkeit

8) Datenschutz

9) Steuerrechtliche Anerkennung

10) Guter Support

Tabelle 6.1: Übersicht Anforderungen an eine Rechnungsstellung im B2B-Bereich80

79

Siehe GOBS 80

Vgl. EICKER, SCHWICHTENBERG (1999), S. 150

6.2 Grundlagen und Ziele der Geschäftsprozessanalyse 49

6.2 Grundlagen und Ziele der Geschäftsprozessanalyse

Grundlage der im Folgenden durchgeführten Geschäftsprozessanalyse (siehe 2.4) ist

eine zwischenbetriebliche Rechnungsstellung basierend auf einer Rechnung in Papier-

form. Diese Form des Rechnungsversands wurde im Jahre 2001 von über 90% der deut-

schen Unternehmen im B2B-Bereich praktiziert (vgl. Ergebnisse der Seals Studie in

Kapitel 1) und stellt auch derzeit (Mitte 2003) das gemeinhin übliche Verfahren dar.

Daher ist es besonderes interessant zu prüfen, inwieweit die dazu durchgeführten Ge-

schäftsprozesse den in Tabelle 6.1 aufgestellten Anforderungen aus Sicht des Rech-

nungsstellers einerseits und des Rechnungsempfängers andererseits gerecht werden.

Ziel der Analyse ist des Weiteren, die Prozesse auf mögliche Optimierungspotentiale

durch eine Umstellung auf eine elektronische Rechnungsstellung zu untersuchen. Um

einen späteren Vergleich mit einer elektronischen Rechnungsstellung über das Internet

(siehe Kapitel 10) zu ermöglichen, werden Kennzahlen für die mittlere Bearbeitungszeit

und die durchschnittlich anfallenden Sachkosten (nur für Rechnungssteller) ermittelt.

Die Berechnung der Kennzahlen beruht jedoch nicht auf vom Autor erhobenen Daten,

sondern orientieren sich an einer vergleichbaren Untersuchung zu den Möglichkeiten

der Prozessoptimierung durch Einführung eines elektronischen Bestellsystems bei Luft-

hansa Air Plus.81

Die zur Analyse aufgestellten Geschäftsprozessmodelle basieren auf den Objekten und

Regeln der erweiterten ereignisgesteuerten Prozessketten (eEPK, siehe Kapitel 3.2).

Zusätzlich zu den Ereignissen und Prozessen werden die an der Durchführung der Ge-

schäftsprozesse beteiligten Daten, IT-Ressourcen und Aufgabenträ-

ger/Organisationseinheiten modelliert. Der Übersicht halber wird aber nicht für jeden

Prozess der ausführende Aufgabenträger bzw. die zuständige Organisationseinheit an-

gegeben, sondern nur zu Beginn einer Prozesskette und bei einem Wechsel.

6.3 Modellierung des IST-Modells

6.3.1 Modellgrundlagen

Der Versand einer Rechnung im B2B-Bereich löst - unabhängig davon, ob die Rech-

nung in Schriftform oder in elektronischer Form übermittelt wird - von ihrer Erstellung

und Übermittlung bis hin zu ihrer Bezahlung, verschiedene Geschäftsprozesse auf Sei- 81

Siehe STELZER (2002), S. 18-51, nach GARZ (2001)

6.3 Modellierung des IST-Modells 50

ten eines Rechnungsausstellers, Rechnungsempfängers und der mit der Zahlung beauf-

tragten Banken aus. Abbildung 6.1 zeigt ein vereinfachtes Modell eines gesamten

Rechnungsverlaufs unterteilt in die daran beteiligten Geschäftspartner.

Erstellung derRechnung

Kunden-kontostand

Rechnung erstellt

Leistungs-daten

Versand

Rechnungeingegangen

Prüfung

Nein Ja

Reklamation

Prüfung

Nicht OK OK

Erstellung einerM ahnung

Verbuchen undZahlung einleiten

W ahl derZahlungsmethode

Nicht OK OK

M ahnung erstellt

E ingang desZahlungsauftrags

Eingang derErmächtigung

Geldtransfer

Eingang derZahlung

Zahlungverbuchen

Ermächtigungweiterleiten

Rechnung

Reklamationeingegangen

Auftrags-daten

Ermäch-tigung

Ermäch-tigung,Auftrag

Zahlungs-mittel

Auftrag

Rechnungsaussteller

Rechnungs-em pfänger

Bank(en)

Datenerfassung

Daten erfasst

Rechnungarchivieren

Rechnungarchiviert

Rechnungs-daten

Datenerfassung

Daten erfasst

Zahlungs-daten

Abgleich m itRechnungsdaten

Zahlungverbucht

OK

Nicht OK

Kunden-kontostand

Rechnungsstel-lung erforderlich

Prozeß-Start

Rechnungs-daten

Zahlungs-daten

Prozeß-Ende

Abbildung 6.1: Vereinfachter Rechnungsprozess82

82



Ausgehend von diesem (allgemein gültigen) Modell wird nachfolgend der Ablauf der

Rechnungsstellung in Papierform, beschränkt auf das rechnungsstellende und das rech-

nungsempfangende Unternehmen, näher betrachtet. Das dazu aufgestellte Modell bildet

die Grundlage der hier durchgeführten Geschäftsprozessanalyse und stellt somit das

IST-Modell dar.

Auf Seiten des Rechnungsstellers wird ein typischer betrieblicher Ablauf von der Erstel-

lung bis hin zur Übermittlung einer den Anforderungen des UStG entsprechenden

Rechnung in Papierform darstellt. Auf Empfängerseite werden Eingang, Datenerfassung

und Archivierung der Papierrechnung modelliert.

6.3.2 Prozessablauf Rechnungssteller

Ein Rechnungssteller verwaltet die einer Rechnung zugrunde liegenden Kunden- und

Leistungsdaten (wie z.B. Name, Anschrift, Kundenkonto, etc.) üblicherweise in einer

computergestützten Datenbank, auf die er, durch Anwendung eines EDV-Systems,

zugreifen kann. Ist eine Rechnungserstellung erforderlich, werden die spezifischen Da-

ten ermittelt und auf deren Grundlage, mit Hilfe des EDV-Systems, eine den gesetzli-

chen Vorgaben entsprechende Rechnung aufgesetzt und ausgedruckt. Die Rechnung

wird anschließend unterschrieben und an den Kunden verschickt. Die Zustellung erfolgt

dabei durch die konventionelle Briefpost. Der Rechnungsausgang wird in einem

Postausgangsbuch registriert.

IST-Modell: Prozessablauf Rechnungssteller


Rechnungs-formular erstellen

InterneDatenbank

Rechnungunterschreiben

Vertrieb/Buchhaltung

Verant-wortlicher

Rechnungs-daten

Rechnungs-formular drucken

Rech-nungs-

formular

Rechnungserstel-lung erforderlich

Rechnungsdatenerfaßt

Rechnungs-formular erstellt

Rechnunggedruckt

(Papier-)Rechnung erstellt

2-5 min

1-2 min

1-2 min Rechnung

Rechnung

Rechnung zumVersand freigeben

Rechnung


Mit-arbeiter

EDV-Anwendung(z.B. Excel)

Postausgangsbuch

2-3 min

R. zum Versandfreigegeben

Rechnungkuvertieren

Rechnungkuvertiert

Rechnungfreistempeln

Rechnung istversandfertig

Rechnungversenden

Rechnung istversendet

Postausgangregistrieren

Postausgangregistriert

Rechnung1-2 min

1 min

1-3 Tage

Rechnungsbrief

Rechnungsbrief

Post


Mit-arbeiter

Leistungs-daten

Kunden-daten



Rechnungssteller

Abbildung 6.2: Rechnungserstellung und -versand in Papierform

6.3

Mod

ellierun

g des IS

T-M

odells

52

IST-Modell: Prozessbeschreibung Rechnungssteller

Nr. Prozess/Funktion Bearbeitungs-

zeit (min) ∅∅∅∅ Sach-kosten

Beteiligte Stelle IT-System-

Unterstützung Schwachstellen/

Probleme

1 Rechnungsdaten erfassen 2-5 - Vertrieb/Buchhaltung, Mitarbeiter

EDV-Anwendung (z.B. Excel), Datenbank

2 Rechnungsformular erstellen

Automatisch - Vertrieb/Buchhaltung, Mitarbeiter

EDV-Anwendung (z.B. Excel)

3 Rechnungsformular drucken

1-2 0,30€ Vertrieb/Buchhaltung, Mitarbeiter

EDV-Anwendung (z.B. Excel), Drucker

Medienbruch: Elektronische Daten→ Daten auf Papier

4 Rechnung unterschreiben 1-2 - Vertrieb/Buchhaltung, Verantwortlicher -

5 Rechnung zum Versand freigeben

- - Vertrieb/Buchhaltung, Verantwortlicher

-

6 Rechnung kuvertieren 1-2 0,05€ Vertrieb/Buchhaltung, Mitarbeiter

-

7 Rechnung freistempeln 1 1,20€ Vertrieb/Buchhaltung, Mitarbeiter

-

8 Rechnung versenden - - Externes Dienstleis-tungsunternehmen (z.B. Deutsche Post)

- Lange Postlaufzeit (min. 1-3 Tage Inland)

9 Postausgang registrieren 1-3 - Vertrieb/Buchhaltung, Mitarbeiter

-

Gesamt 7-15 ∅∅∅∅11

1,55€ 3 (davon 1 extern) Nur eingeschränkt Langsamer Prozess-ablauf, Medienbruch

Tabelle 6.2: Prozessbeschreibung IST-Modell Rechnungssteller

6.3

Mod

ellierun

g des IS

T-M

odells

5

3


6.3.3 Prozessablauf Rechnungsempfänger

Geht eine schriftliche Rechnung per Post ein, wird auf Seiten des Rechnungsempfän-

gers der Eingang registriert und der Rechnung eine eindeutige (interne) Belegnummer

zugewiesen (z.B. mit einem Stempel), anhand derer sie innerhalb des Unternehmens

identifiziert werden kann. Anschließend werden die Rechnungsdaten erfasst. Die Erfas-

sung erfolgt dabei durch manuelle Eingabe der auf Papier vorliegenden Daten in ein

EDV-System, das die Daten in einer Datenbank ablegt. Nach der Erfassung stehen die

Daten (im Idealfall) allen Abteilungen des Unternehmens zur Verfügung, beispielsweise

durch den Betrieb eines Firmennetzwerkes mit einem Datenbank-Server. Nun erfolgt

eine Rechnungsprüfung, d.h. der Rechnungsempfänger gleicht die Rechnungsdaten mit

den der Rechnung entsprechenden Wareneingangs- bzw. Auftragsdaten seines Unter-

nehmens ab. In diesem Modell wird davon ausgegangen, dass die Wareneingangs- bzw.

Auftragsdaten zum Zeitpunkt des Rechnungseingangs schon in elektronischer Form

vorliegen, so dass die Rechnungsprüfung EDV-gestützt ablaufen kann. Bei Unstimmig-

keiten erfolgt ein Klärungs-/Reklamationsfall, der hier nicht näher betrachtet werden

soll. Bei erfolgreicher Rechnungsprüfung werden die Rechnungsdaten verbucht, die

Zahlung eingeleitet und das Papierdokument archiviert.


IST-Modell: Prozessablauf Rechnungsempfänger

Posteingangsbuch

Rechnungeingegangen

Rechnungseingangregistrieren

Rechnung

Rechnungsein-gang registriert

(Interne) Beleg-nummer zuweisen

Belegnummerzugewiesen



Rechnung

Buchhaltung/Rechnungswesen

Mit-arbeiter

Rechnungarchivieren

Rechnung

Rechnungs-daten

Rechnung

Aktenordner

InterneDatenbank

EDV-Anwendung(z.B. Access)

1 - 2 min

5 - 25 min

3 - 5 min

Rechnungsprüfung

Nicht OK OK

Reklamation,Klärungsvorgang


Rechnungarchiviert

Warenein-gangsdaten

Auftrags-daten

2 - 3 min InterneDatenbank

EDV-Anwendung(z.B. Access)

1 min

Rechnungsempfänger

Abbildung 6.3: Eingang und Weiterverarbeitung einer Papierrechnung

Die Prozesse "Reklamation, Klärungsvorgang" und "Verbuchen und Zahlung einleiten"

werden hier nicht weiter verfolgt, da dies über den zu analysierenden Bereich der Rech-

nungsstellung hinausgeht. Durch die Darstellung als Prozesswegweiser soll aber ver-

deutlicht werden, dass die Prozessketten an diesen Stellen in einem vollständigen Rech-

nungsprozess gemäß Abbildung 6.1 fortgeführt werden müssen.

IST-Modell: Prozessbeschreibung Rechnungsempfänger

Nr. Prozess/Funktion Bearbeitungs-

zeit (min) Beteiligte Stelle IT-System-Unterstützung

Schwachstellen/Probleme

1 Rechnungseingang regist-rieren

1-2 Buchhaltung / Rech-nungswesen, Mitarbeiter

-

2 Rechnung interne Beleg-nummerzuweisen 1

Buchhaltung / Rech-nungswesen, Mitarbeiter

-

3 Rechnungsdaten erfassen 5-25 Buchhaltung / Rech-nungswesen, Mitarbeiter

EDV-Anwendung, Datenbank

Medienbruch: Daten auf Papier → elektronische Daten, Manuelle Erfassung: hoher Zeit-aufwand, eintönig und fehleranfällig

4 Rechnungsprüfung 2-3 Buchhaltung / Rech-nungswesen, Mitarbeiter

EDV-Anwendung, Datenbank

5 Rechnung archivieren 3-4 Buchhaltung / Rech-nungswesen, Mitarbeiter

- Manuelle (Papier-) Archivierung: großer Platzbedarf, lange Zugriffzei-ten

Gesamt 12-35 ∅∅∅∅24

1 Nur eingeschränkt Zeit- und kostenaufwändige ma-nuelle Prozesse, hohe Fehlerrate

Tabelle 6.3: Prozessbeschreibung IST-Modell Rechnungsempfänger

6.3

Mod

ellierun

g des IS

T-M

odells

5

6

6.4 Prozessbewertung 57

6.4 Prozessbewertung

Bezogen auf die in Tabelle 6.1 gestellten Anforderungen an die zwischenbetriebliche

Rechnungserstellung und Übermittlung durch den Absender sowie an den Rechnungs-

eingang und die Weiterverarbeitung auf Seiten des Rechnungsempfängers lassen sich

einige Unzulänglichkeiten der papierbasierten Rechnungsstellung erkennen.83

Aus Sicht des Rechnungsstellers ist

• der Druck, die Kuvertierung und der Versand einer Rechnung teuer und zeit-

aufwändig (insbesondere durch die Postlaufzeit),

• die Nachweisbarkeit der Zustellung nicht gegeben (Ausnahme: kostenaufwän-

dige Zusatzleistungen wie z.B. Einschreiben und Rückschein),

• der Datenschutz nur unzureichend gegeben (schwerer Nachweis eines Zugriffs

oder einer Manipulation durch Dritte),

• und die Marketingfunktion der Papierrechnung aufgrund hoher Zusatzkosten

für Papierbeilagen eingeschränkt.

Aus Sicht des Rechnungsempfängers ist

• die Zugänglichkeit der Rechnung bei Abwesenheit vom Zustellungsort er-

schwert,

• der Datenschutz nur unzureichend gegeben,

• die Darstellung der Rechnung nicht an individuelle Bedürfnisse anpassbar,

• die Weiterverarbeitung aufgrund der manuellen Datenerfassung zeitaufwändig

und stark fehleranfällig,

• und die Archivierung der Papierrechnung aufwändig (z.B. durch Scan-

Verfahren oder manuelles Abheften).

6.5 Optimierungspotentiale durch elektronische Rechnungsstellung

Bei der Analyse des IST-Modells fällt auf, dass die einer Rechnung zugrundeliegenden

Rechnungsdaten sowohl bei der Erstellung der Rechnung als auch bei der Buchung auf

Seiten des Rechnungsempfängers in elektronischer Form vorliegen. Das bedeutet, dass

eine durchgängige elektronische Rechnungsabwicklung prinzipiell möglich ist. In dem

vorgestellten Ablauf wird der Medienbruch, der durch das Ausdrucken der Rechnungs-

daten auf Papier im rechnungsstellenden Unternehmen entsteht, durch eine manuelle 83


6.5 Optimierungspotentiale durch elektronische Rechnungsstellung 58

Dateneingabe in das EDV-System des Rechnungsempfängers rückgängig gemacht. Die-

ser Vorgang ist allerdings ineffizient und stark fehleranfällig. Bei anspruchsvollen Da-

ten kann die Fehlerquote bis zu 80% betragen.84 Eine elektronische Rechnungsübermitt-

lung hingegen ermöglicht eine direkte Übernahme der Rechnungsdaten in das unter-

nehmensinterne EDV-System des Rechnungsempfängers, ohne dass eine erneute manu-

elle Erfassung durchgeführt werden muss. Das spart Bearbeitungszeit und hilft Fehler

zu vermeiden.

Durch eine elektronische Rechnungsübermittlung können des Weiteren folgende Opti-

mierungen gegenüber dem Ablauf des IST-Modells erreicht werden:

• Verkürzung der gesamten Durchlaufzeit einer Rechnung durch Wegfall der

Postlaufzeit,

• Reduzierung der Prozesskosten eines Rechnungsausgangs durch Einsparungen

von Papier-, Druck- und Portokosten,

• Verbesserter Datenschutz durch die Möglichkeit einer elektronisch verschlüs-

selten Übertragung,

• Verbesserte Marketingmöglichkeiten durch elektronische Werbung,

• Vereinfachte Archivierung der Rechnungsdaten in elektronischer Form.

Zusammenfassend betrachtet, können die drei Säulen des Geschäftsprozessmanage-

ments (Qualität, Zeit und Kosten, vgl. Abbildung 2.6) gestärkt werden, was zu einer

Steigerung der Kundenzufriedenheit und der Unternehmenseffizienz beiträgt.

Die Realisierung der aufgezeigten und eventuell weiterer Optimierungspotentiale durch

eine Umstellung der papierbasierten Rechnungsstellung auf eine Rechnungsstellung in

elektronischer Form ist in der Praxis von zwei Faktoren abhängig: Zum einen hängt sie

von der technischen Umsetzung von Verfahren zur elektronischen Rechnungsstellung

und –weiterverarbeitung und zum anderen von der Einbindung dieser Verfahren in die

bestehenden betrieblichen Abläufe ab. Mögliche Grundlagen für eine technische Um-

setzung sind beispielsweise eine Datenübertragung per EDI (siehe Kapitel 7) oder über

das Internet (siehe Kapitel 8).

84

Vgl. SCHMOLL (1994), S. 65, nach GORA (1991)

7.1 Grundlagen des elektronischen Datenaustauschs (EDI) 59

7 Elektronischer Datenaustausch (EDI) mit EDIFACT

7.1 Grundlagen des elektronischen Datenaustauschs (EDI)

Das Verfahren, Rechnungen und andere geschäftliche Dokumente auf elektronischem

Wege an die jeweiligen Empfänger zu übermitteln, existiert nicht erst seit der Entwick-

lung und Verbreitung des Internets. Bereits Ende der 60er Jahre entwickelte sich im

Bereich der zwischenbetrieblichen Kommunikation der sogenannte Elektronische Da-

tenaustausch, kurz EDI (Electronic Data Interchange), mit dem Ziel die Ineffizienzen

des papierbasierten Geschäftsverkehrs durch eine Umstellung auf eine Datenübertra-

gung in elektronischer Form zu beseitigen und dadurch Geschäftsprozesse zu optimie-

ren. Für EDI existieren in Literatur und Praxis verschiedene Definitionen. In dieser Ar-

beit wird sich auf folgende Definition nach SCHMOLL (1994) gestützt (vgl. dazu

Abbildung 7.1):

"Unter EDI wird im weiteren der interventionsfreie Austausch strukturierter Daten ver-

standen, die unter Nutzung der elektronischen Datenübertragung zwischen Applikatio-

nen beteiligter Kommunikationspartner transferiert werden."85

FinanzenBeschaffungFertigung

DistributionMarketing/Vertrieb

Unternehmen A

FinanzenBeschaffungFertigung

DistributionMarketing/Vertrieb

Unternehmen B

„EDI“Austausch strukturierter Geschäftsdaten

in standardisierten Formatenvon Anwendung zu Anwendung

über öffentliche und private Netze.

Abbildung 7.1: Electronic Data Interchange (EDI)86

EDI beschreibt (in seiner ursprünglichen Form) eine reine Maschine-zu-Maschine

Kommunikation, d.h. der Datenaustausch findet ohne menschliche Intervention statt.

Voraussetzung dafür ist, dass die zu transferierenden Daten in einer dem Sender und

dem Empfänger bekannten Struktur vorliegen. Strukturierte Daten zeichnen sich da-

durch aus, dass die Syntax und die Semantik ihrer Bestandteile genau festgelegt sind.

85

SCHMOLL (1994), S. 15 86

Vgl. SCHMOLL (1994), S. 16

7.2 EDI Standards 60

Die Syntax beschreibt die Ordnung der einer Nachricht zugrunde liegenden Zeichen und

Zeichenverbindungen. Die Semantik charakterisiert Bedeutung und Inhalt der durch die

Syntax festgelegten Zeichenfolgen. Erst die genaue Kenntnis von Syntax und Semantik

macht Daten lesbar und verständlich, und ermöglicht somit eine automatische Interpre-

tation und Weiterverarbeitung ohne menschliches Eingreifen.

Gerade im Dokumentenaustausch zwischen Geschäftspartnern finden sich zahlreiche

strukturierte Nachrichten, die zum Einsatz von EDI geeignet sind. Bestellungen, Auf-

trags-Formulare und insbesondere Rechnungen bedienen sich im wesentlichen einer

vorgegebenen, stabilen Struktur und unterscheiden sich nur inhaltlich. In der Regel kann

eine vollständige Auftragsabwicklung von der Angebotsanfrage bis hin zur Rechnung

per EDI abgewickelt werden.

Folgende operative Wettbewerbsvorteile können in der zwischenbetrieblichen Kommu-

nikation durch den Einsatz des elektronischen Datenaustauschs gegenüber dem traditio-

nellen Papierverkehr erreicht werden:87

• Beschleunigte Datenübertragung und Auftragsabwicklung,

• Reduzierung von Druck-, Papier- und Portokosten,

• Geringe Fehlerquote durch Wegfall der manuellen Datenneuerfassung auf Sei-

ten des Datenempfängers,

• Verringerung der Medienbrüche von Datenerfassung bis –archivierung,

• Möglichkeit zur automatisierten Weiterverarbeitung,

• Vereinfachung und Beschleunigung des grenzüberschreitenden Datenaus-

tauschs.

Die kurze Datenübertragungszeit verspricht außerdem einen optimierten Umgang mit

Unternehmens-Ressourcen. Lagerbestände können reduziert werden und zeitkritische

Anwendungen werden möglich. Gerade für Logistik-Unternehmen ist dies von großer

betriebswirtschaftlicher Bedeutung.

7.2 EDI Standards

Um die Vorteile von EDI in vollem Umfang ausnutzen zu können, müssen Vereinba-

rungen bezüglich der Art und Weise des Datenaustauschs zwischen den Kommunikati-

87

Vgl. SCHMOLL (1994), S. 37-38

7.2 EDI Standards 61

onspartnern getroffen werden. Aufgrund verschiedenster Computersysteme, Software

und Übertragungsprotokolle können in der zwischenbetrieblichen Kommunikation In-

kompatibilitäten auftreten. Eine medienbruchlose Weiterverarbeitung der transferierten

Daten ist in der Regel nicht möglich. Es bedarf also standardisierten Verfahren als

Grundlage für einen überbetrieblichen Datenaustausch. Diese Standards müssen sowohl

Datenstruktur (Syntax und Semantik) als auch die zugrundeliegenden Übertragungspro-

tokolle festlegen. Denkbar sind zwar auch individuelle Absprachen mit Geschäftspart-

nern bezüglich Struktur und Übertragungsprotokoll, jedoch ist schon bei einem mittel-

ständischen Unternehmen der Aufwand erheblich. Jedes Feld eines Datensatzes einer

elektronischen Nachricht müsste genau definiert werden, um es auf Empfängerseite

erkennen und automatisch weiterverarbeiten zu können. Die dann anfallenden Verein-

barungs- und Wartungskosten wiegen die Vorteile des papierlosen Datenaustauschs in

großem Teil auf.88

Die Notwendigkeit von Standardisierungen im elektronischen Datenaustausch bildete

Mitte der 80er Jahre brancheninterne Standards im Sinne von EDI heraus. Beispiele

hierfür sind:89

• VDA (Verband der deutschen Automobilindustrie) für die deutsche Automo-

bilindustrie,

• Rinet (Reinsurance and Insurance Network) für die europäische Versiche-

rungswirtschaft,

• SWIFT (Society for Worldwide Interbank Financial Telecommunication) für

den internationalen Interbankverkehr,

• SEDAS (Standardregelung Einheitlicher Datenaustauschsysteme) für den

Handel.

Diese Branchen-Standards stellen zwar eine Verbesserung gegenüber dem traditionellen

schriftlichen Geschäftsverkehr dar, doch stehen sie hinter den Möglichkeiten einer ein-

heitlichen Weltnorm zurück. Branchenbezogen und teilweise national begrenzt erlauben

sie keinen uneingeschränkten elektronischen Datenaustausch. Die Zahl der durch EDI

erreichbaren Kommunikationspartner wird auf eine Branche beschränkt. Ein Unterneh-

men kommuniziert aber vielfach über Branchen und nationale Grenzen hinweg, so dass

nur die Einführung und Nutzung eines Weltstandards ökonomisch sinnvoll ist.

88

Vgl. SCHMOLL (1994), S. 27 89

Vgl. SCHMOLL (1994), S. 27-28

7.3 Die EDIFACT–Nachricht 62

Die „UN/EDIFACT – ISO-Norm 9735 für den elektronischen Handelsdatenaus-

tausch“ versucht diesem Weltstandard gerecht zu werden. Sie stellt ein international

gültiges Regelwerk für Syntax und Zeichensatz von Geschäftsnachrichten dar.

UN/EDIFACT90 (für „United Nations / Electronic Data Interchange For Administration,

Commerce and Transport“) wurde im März 1987 in Genf vorgestellt. Entwickelt wurde

EDIFACT von einer Arbeitsgruppe zur „Erleichterung von Verfahren im internationa-

len Handel“ der UN/ECE91. Inzwischen ist EDIFACT zu einer ISO92- und einer DIN93-

Norm erhoben worden. Bei der Entwicklung stellte man folgende Voraussetzungen an

die Norm:94

• Unabhängigkeit vom Hersteller

• Unabhängigkeit von der Art der Übertragung

• Unabhängigkeit von der verwendeten Hardware

• Unabhängigkeit von der Betriebssystemsoftware

• Unabhängigkeit von der Landessprache

• Unabhängigkeit von der Branche

EDIFACT ermöglicht aufgrund dieser Eigenschaften einen weltweiten elektronischen

Austausch von Geschäftsdaten im Sinne der EDI–Definition. Im Juli 1994 deckte

EDIFACT mit 177 Nachrichten nahezu alle praktischen Geschäftsvorfälle eines Unter-

nehmens ab.95

7.3 Die EDIFACT–Nachricht

7.3.1 EDIFACT–Syntax–Regeln

Grundlage einer EDIFACT–Nachricht ist die schon erwähnte ISO-Norm 9735. Hier

sind die Syntaxregeln für die Strukturierung aller möglichen EDIFACT–

Nachrichtentypen (Bestellung, Rechnung, Reklamation, etc.) bis ins Detail festlegt.

Die wichtigsten Grundzüge der Syntax-Regeln werden im Folgenden näher erläutert.

Eine vollständige Beschreibung kann aufgrund der Komplexität nicht gegeben werden.

90

Nachfolgend sind UN/EDIFACT und EDIFACT synonym zu betrachten 91

Economic Commision for Europe of the United Nations (Wirtschaftskommission für Europa innerhalb der Vereinten Nationen) 92

International Standardization Organization, ISO-Norm 9735, 1987 93

Deutsches Institut für Normung, Berlin, DIN EN 29735 94

Vgl. SCHMOLL (1994), S. 30, nach GEORG, S. 29 95

Vgl. DEUTSCH (1994), S. 5


Die EDIFACT–Syntax regelt den formalen Aufbau einer Nachricht. Dabei determiniert

sie folgende Bestandteile:96

• den verwendeten Zeichensatz,

• die Reihenfolge und Hierarchie der Bausteine und Baugruppen,

• die Arten von Trennzeichen zwischen verschiedenen Komponenten.

Die Implementierung der Syntax-Regeln in Software macht eine automatische Erstel-

lung, Interpretierung und Weiterverarbeitung einer EDIFACT-Nachricht möglich. An-

hand des Regelwerks lassen sich Nachrichtenstrukturen erzeugen bzw. erkennen, so

dass den zu übermittelnden Daten die semantisch richtige Bedeutung zugeordnet wer-

den kann.

7.3.2 Aufbau einer EDIFACT – Übertragungsdatei

Rein äußerlich betrachtet ist eine EDIFACT-Übertragungsdatei eine lange Zeichenkette

(„Endlos-String“) im Format einer Textdatei (Endung *.txt). Textdateien können von

allen Computersystemen gelesen und verarbeitet werden. Dadurch wird die geforderte

Hardware-Unabhängigkeit erreicht.

Eine EDIFACT Übertragungsdatei setzt sich grundsätzlich aus folgenden vier Kompo-

nenten zusammen:97

• Datenelemente/Datenelementgruppen

• Segmente

• Nachrichten

• Nachrichtengruppen

Die möglichen Ausprägungen dieser Komponenten sind in sogenannten EDIFACT-

Verzeichnissen aufgelistet. Identifiziert durch einen eindeutigen Bezeichner sind darin

die Struktur und die semantische Bedeutung aller Komponenten detailliert beschrieben.

Dem Aufbau einer EDIFACT-Übertragungsdatei liegt eine Hierarchie der aufgeführten

Komponenten zu Grunde, die in der nachfolgenden Abbildung dargestellt ist.

96

Vgl. SCHMOLL (1994), S. 87- 88 97

Vgl. SCHMOLL (1994), S.79


Abbildung 7.2: Darstellung der EDIFACT–Hierarchie98

Steht die Verbindung zwischen den Anwendungen der EDIFACT-Kommunikations-

partner können Dateien übertragen werden. Eine Datei setzt sich aus Nachrichtengrup-

pen zusammen, die wiederum eine oder mehrere Nachrichten enthalten. Nachrichten

bestehen aus einer Auflistung von Segmenten. Ein Segment besteht aus einem Bezeich-

ner und einem oder mehreren Datenelementen bzw. Datenelementgruppen. Die Daten-

elemente beinhalten schließlich die zu übertragenen Werte. Die einzelnen Übertagungs-

dateien, Nachrichtengruppen und Nachrichten werden durch vorgegebene Segmente

voneinander getrennt. Die Trennung von Segmenten und der Elemente innerhalb eines

Segments erfolgt durch zu Beginn der Übertragung festgelegte Trennzeichen.

Auf unterster Ebene der EDIFACT–Hierarchie stehen die Datenelemente bzw. Grup-

pendatenelemente. Ein Datenelement bzw. Gruppendatenelement ist unteilbar und

trägt die eigentliche Information in Form eines Wertes. Zum Beispiel wird bei der Über-

tragung einer Rechnung die Artikelnummer und der Preis eines Artikels in einem Da-

tenelement übertragen.

Fasst man sachlich und logisch zusammenhängende Datenelemente zusammen, entsteht

eine Datenelementgruppe. Dabei ist die Reihenfolge der sogenannten Gruppendaten-

elemente fest vorgegeben. Anhand ihrer Position lassen sie sich somit eindeutig identi- 98

SCHMOLL (1994), S. 86, nach DIN/EN 29735, S. 10


fizieren. Ein Beispiel für eine Datenelementgruppe ist das Zusammenfassen von Menge

und Mengeeinheit eines Artikels einer Rechnung.

Die Zusammenfassung funktionell zusammenhängender Datenelemente und/oder Da-

tenelementgruppen bezeichnet man als Segment. Beispielsweise werden Informationen

über Bankverbindungen (Bankleitzahl, Kontonummer, Kontoinhaber, Name und Sitz

der Bank usw.) in einem Segment übertragen. Grundsätzlich unterscheidet man zwei

Arten von Segmenten:99

• Nutzdatensegmente beinhalten die wesentlichen Informationen einer Nach-

richt, wie sie auch in der klassischen Papierform vorkommen. Dazu gehören

u.a. Beträge, Werte, Namen und Anschriften.

• In Servicedatensegmenten hingegen werden erforderliche Datenelemente für

die Übermittlung übertragen. Dies sind zum Beispiel die elektronische Sender-

und Empfänger-Adresse, Datum und Uhrzeit der Übermittlung und die Priori-

tät. Servicedatensegmente zeichnen sich dadurch aus, dass sie vom eigentli-

chen Inhalt der übermittelten Nachricht unabhängig sind.

Unter einer Nachricht wird die Menge aller Segmente, die zur Darstellung einer Ge-

schäftstransaktion nötig sind, verstanden. Die zur Verfügung stehenden Segmente be-

finden sich dabei in einer genau spezifizierten Reihenfolge.100

Umrahmt wird eine EDIFACT-Nachricht von einem Nachrichten-Kopfsegment (UNH)

und einem Nachrichten-Endsegment (UNT). Das UNH-Segment trägt eine eindeutige

Referenz-Nummer (die sogenannte Common Access Number) und einen Nummernco-

de, der die Art der Nachricht (z.B. Bestellung, Rechnung, Lieferschein, usw. ) über Co-

de-Listen identifiziert. Im UNT-Segment steht die Anzahl der verwendeten Segmente

der Nachricht und die Common Access Number wird wiederholt.

Alle standardisierten und international anerkannten Nachrichten werden im "United

Nations Standard Messages"-Verzeichnis (UNSM) der UN/ECE geführt. Das Verzeich-

nis unterliegt einem dynamischen Prozess. Bis heute werden neue Nachrichten für spe-

zifische Geschäftsvorfälle vorgeschlagen, verabschiedet und in die Liste aufgenommen.

Eine Nachricht ist dabei durch einen Status gekennzeichnet. Der Status "0" charakteri-

siert ein Arbeitsdokument, "1" einen Entwurf zu Empfehlung und "2" eine von der

UN/ECE empfohlene, weltweit gültige Nachricht. Ein neuer Nachrichtentyp benötigt

99

Vgl. SCHMOLL (1994), S.81 100

Vgl. SCHMOLL (1994), S.83


ca. zwei Jahre um den Status "2" zu erreichen. Vorausgesetzt der Nachrichtentyp konnte

über einen längeren Zeitraum stabil in der Praxis eingesetzt werden.101

Summiert man Nachrichten eines Anwendungsbereichs, die alle an den gleichen Emp-

fänger adressiert sind, spricht man von einer Nachrichtengruppe. Die Art einer Nach-

richtengruppe wird zu Beginn, durch das Nachrichtengruppen-Kopfsegment (UNG)

codiert, angegeben. Abgeschlossen wird eine Nachrichtengruppe durch das Nachrich-

tengruppen-Endsegment (UNE).

Eine EDIFACT-Übertragungsdatei setzt sich aus einer oder mehreren Nachrichten-

gruppen zusammen. Dabei spezifiziert die Trennzeichenvorgabe (UNA) die innerhalb

der Übertragungsdatei verwendeten Trennzeichen. Das Nutzdaten-Kopfsegment (UNB)

identifiziert die Übertragungsdatei, die durch das Nutzdaten-Endsegment (UNZ) abge-

schlossen wird.

Zusammenfassend werden die Kopf- und Endsegmenten von Nachrichten, Nachrichten-

gruppen und Übertragungsdateien auch als Nutzdatenrahmen bezeichnet.

Abbildung 7.3: Aufbau des Nutzdatenrahmens einer EDIFACT - Übertragungsdatei102

Der Nutzdatenrahmen grenzt nach außen mehrere Übertragungsdateien voneinander ab.

Innerhalb einer Übertragungsdatei werden einzelne Nachrichtengruppen und Nachrich-

ten voneinander abgegrenzt. Enthält eine Übertragungsdatei nur eine Nachricht, so kön-

101

Vgl. DEUTSCH (1994), S. 44 102

SCHMOLL (1994), S. 87, nach: HERMES


nen die Nutzdaten-Segmente für die Nachrichten-Gruppe (UNG und UNE) ausgelassen

werden.

7.3.3 Eine EDIFACT Beispielrechnung

Die Papierrechnung:

Zum Abschluss dieses Abschnitts wird folgende Rechnung in Papierform (beispielhaft

für eine alltägliche Rechnung) als EDIFACT-Übertragungsdatei dargestellt:

PC Profi, Parkstrasse 14, 35390 Giessen

Max Muster Giessen, den 03.06.2002 Schlossallee 20 35781 Weilburg

Rechnungs-Nr.: 0206003 Ihre Bestellung Nr.: 380205 vom 30.05.2002

Pos Artikel-Nr. Artikel-Bezeichnung Anzahl Einzelpreis Gesamtpreis

1 4711.236 19’’ Flachbildschirm 1 820,00 820,00

2 4711.248 Optische Maus 1 41,90 41,90

3 4711.213 CD-Rohlinge 10er Pack

3 7,89 23,67

4 4711.256 ISDN-Karte 1 65,80 65,80 ------------ Gesamtsumme netto 951,37

Umsatzsteuer 16% 152,21 ------------

Rechnungsbetrag in € 1103,58

PC-Profi, Dresdner Bank Giessen, Kto.-Nr.: 246217, BLZ 51960815

Abbildung 7.4: EDIFACT-Beispielrechnung


Die EDIFACT-Übertragungsdatei:

Der Umsetzung der obigen Papierrechung ins EDIFACT-Format liegt der Nachrichten-

typ INVOIC (kommerzielle Rechnung) nach UN/EDIFACT-Standard D93A zugrunde.

Die EDIFACT-Übertragungsdatei besteht aus einem Endlosstring, d.h. die einzelnen

Segmente der Datei werden fortlaufend aneinander gehängt. Hier wird der Übersicht

halber in jeder Zeile nur ein Segment dargestellt:

UNA:+,?' UNB+UNOA:2+PCPROFI+MAXMUSTER+020604:1135+0206041135' UNH+INVOIC0001+INVOIC:D:93A:UN' BGM+380+0206003+9' DTM+3:20020603:102' RFF+ON:15491' DTM+4:20020530:102' NAD+SE+++PC Profi+Parkstrasse 14+Giessen++35390' NAD+BY+++Max Muster+Schlossallee 20+Weilburg++35781 ' FII+PE+246217:PCBOERSE+51960815:28:::::Dresdner Ban k Giessen' CUX+:EUR' LIN+1++4711.236' IMD+F++:::19?'?' Flachbildschirm' QTY+47:1:PCE' MOA+66:820' PRI+AAA:820' LIN+1++4711.248' IMD+F++:::Optische Maus' QTY+47:1:PCE' MOA+66:41,90' PRI+AAA:41,90' LIN+1++4711.213' IMD+F++:::CD-Rohlinge 10er Pack' QTY+47:3:PCE' MOA+66: 23,67' PRI+AAA:7,89' LIN+1++4711.256' IMD+F++:::ISDN-Karte' QTY+47:1:PCE' MOA+66:65,80' PRI+AAA:65,80' UNS+S' MOA+79:951,37' MOA+124:152,21' MOA+128:1103,58' TAX+7+VAT+++:::16+S' UNT+36+INVOIC0001' UNZ+1+0206041135'

Abbildung 7.5: EDIFACT-Übertragungsdatei

Eine genaue Erklärung aller Segmente dieser EDIFACT-Übertragungsdatei befindet

sich im Anhang (siehe A 4 Erklärung der EDIFACT Beispiel-Rechnung).

7.4 Übertragungswege für EDI 69

7.4 Übertragungswege für EDI

Bevor eine Nachricht an einen bestimmten EDI-Partner geschickt werden kann, müssen

die benötigten Daten gesammelt und konvertiert werden. Die Konvertierung beschreibt

die Umwandlung der zu übermittelnden Daten aus einem sendereigenen Anwendungs-

format (sogenanntes Inhouse-Format, z.B. iDoc bei SAP R/3) in das zwischen den Part-

nern vereinbarte Austauschformat, z.B. EDIFACT. Diese Aufgabe erfüllt sogenannte

Konverter-Software, jeweils angepasst an das verwendete Inhouse-Format. Auch auf

Seiten des Empfängers wird Konverter-Software benötigt, um die eingehende Datei in

das hier verwendete Inhouse-Format umzuwandeln.

Die Übertragung der erzeugten Nachricht erfolgt bei einem traditionellen EDI-Verkehr

über eine Standleitung, öffentliche Telefonleitung oder über Computernetze externer

Anbieter, basierend auf standardisierten Übertragungsprotokollen (z.B. X.400). Man

unterscheidet dabei grundsätzlich zwei Arten von Übertragungswegen für den elektroni-

schen Datenaustausch:103

• Punkt-zu-Punkt-Übertragung,

• Zwischengespeicherte Übertragung.

Beiden Verfahren gemeinsam sind hohe Implementierungs- und Betriebskosten auf Sei-

ten der EDI-Teilnehmer. Entsprechende Übertragungs-Software muss gekauft, eventuell

an eigene Gegebenheiten angepasst und eingerichtet werden.

Die Punkt-zu-Punkt-Übertragung zeichnet sich durch eine direkte Übertragung der

Daten vom Sender zum Empfänger aus. Voraussetzung dafür ist eine bestehende Ver-

bindung zwischen den Kommunikationspartnern. Um eine Nachricht senden bzw. emp-

fangen zu können, müssen beide Partner gleichzeitig übertragungsbereit sein. Des Wei-

teren müssen beide das gleiche Übertragungsprotokoll verwenden, um Inkompatibilitä-

ten zu vermeiden.

Der Vorteil der Punkt-zu-Punkt-Übertragung sind die geringeren Übertragungskosten

gegenüber einem zwischengespeicherten Transfer. Nachteilig dagegen ist der große

administrative Aufwand. So stellt z.B. die jeweilige Auswahl und Abstimmung eines

geeigneten Übertragungsprotokoll bei einer Vielzahl von Geschäftspartnern einen er-

heblichen administrativen Aufwand dar.

103


7.5 Elektronische Rechnungsübermittlung mit EDI 70

Unter einer zwischengespeicherten Übertragung versteht man die Übergabe der zu

übermittelnden Daten an einen externen Dienstleister, der die Daten dann dem Empfän-

ger zugänglich macht. Um Nachrichten senden bzw. empfangen zu können, genügt hier

eine Verbindung zu dem dienstleistenden Unternehmen, die völlig unabhängig vom

Sender bzw. Empfänger aufgebaut werden kann.

Die vorhandenen Anbieter dieser Dienstleistungen werden nach einem Mehrwert, den

sie den zwischengespeicherten Nachrichten hinzufügen können, unterschieden:

Übernimmt der Dienstleister lediglich die Aufgabe der Datenspeicherung, spricht man

von einem Datenaustausch über eine Mailbox . Eingehende Nachrichten werden anhand

der Empfänger-Adresse in zugehörige Mailboxen sortiert. Dort stehen sie dann für den

Eigentümer der Box zum Abruf bereit. Die Nachrichten bleiben dabei unverändert, d.h.

es wird kein Mehrwert hinzugefügt.

Ein VAN (Value Added Network) bezeichnet einen Dienstleister, der die zwischenge-

speicherten Daten mit einem Mehrwert versieht. Diese Mehrwertdienste, als VANS

(Value Added Network Services) bezeichnet, sind z.B. folgende Leistungen:104

• Aufsplitten einer Datei an mehrere Empfänger,

• Konvertierung nach vorgegebenen Richtlinien,

• Verschlüsseln,

• Prüfung der Authentizität,

• Archivieren,

• Generieren von Empfangsbestätigungen.

Die Nutzung eines VANS verringert den technischen und organisatorischen Aufwand

für einen elektronischen Datenaustausch auf beiden Seiten der beteiligten Kommunika-

tionspartner. Dem gegenüber stehen aber die zusätzlich zu den Übertragungskosten an-

fallenden Kosten für die Mehrwertdienste.

7.5 Elektronische Rechnungsübermittlung mit EDI

Rechnungen eignen sich aufgrund ihrer im wesentlichen festgelegten Struktur und ih-

rem hohen Übertragungsvolumen für eine elektronische Übermittlung per EDI. Aller-

dings kommt derartig übermittelten Rechnungsdaten keine steuerrechtliche Anerken-

nung im Sinne des UStG zu, so dass sie alleine nicht zu einem Vorsteuerabzug gegen-

104


7.6 EDI in der Praxis 71

über den Finanzbehörden berechtigen. Aus diesem Grund müssen im zwischenbetriebli-

chen Rechnungsaustausch zusätzlich zu den mit EDI übertragenen Daten, periodische

(in der Regel quartalsmäßige) Sammelrechnungen auf Papier an den Rechnungsemp-

fänger verschickt werden. Aufgrund dieses Mehraufwandes beschränkt sich die elektro-

nische Rechnungsübermittlung per EDI hauptsächlich auf Rechnungen mit großem Da-

ten- und Übertragungsvolumen wie z.B. der Übermittlung von Telefonrechnungen für

Konzerne, große Unternehmen und Verwaltungen.105

Grund für die nicht gegebene gesetzliche Anerkennung ist der fehlende Nachweis der

Authentizität und Integrität von EDI-Daten. Aus Sicht von EDI-Experten stellt dies je-

doch einen Missstand dar, da die heutzutage üblichen Übermittlungsverfahren und –

protokolle in der Lage sind, die Authentizität und Integrität der übertragenen EDI-Daten

(auch ohne den Einsatz qualifizierter elektronischer Signaturen) gewährleisten kön-

nen.106 Bisher waren aber die Forderungen verschiedener Wirtschaftverbände nach der

Schaffung von entsprechenden gesetzlichen Rahmenbedingen für den EDI-

Rechnungsaustausch nicht erfolgreich. Mit der bis zum 01.01.2004 geforderten Umset-

zung der EU-Richtlinie 2001/115/EG (siehe Kapitel 5.4) wird nun die Möglichkeit für

eine steuerrechtlich anerkannte elektronischen Rechnungsübermittlung mit EDI in die

Umsatzsteuergesetze der einzelnen Mitgliedsstaaten aufgenommen. Das Gesetz sieht

aber vor, dass die Mitgliedstaaten, unter von ihnen festzulegenden Bedingungen, das

Ausstellen einer zusätzlichen Sammelrechnung fordern können. Eine Stellungnahme, zu

den von Seiten der deutschen Gesetzgebung geplanten Bedingungen für das Ausstellen

von Sammelrechnungen, liegt derzeit noch nicht vor.

7.6 EDI in der Praxis

Die mit der EDIFACT-Norm geschaffenen Voraussetzungen ließen Anfang der 90er

Jahre einen Boom des nationalen und internationalen elektronischen Handelsverkehrs

per EDI erwarten. Hohe Wachstumsraten und eine starke nationale und internationale

Verbreitung von EDI-Produkten wurden vorausgesagt. Heutzutage weiß man, dass sich,

obwohl die Wettbewerbsvorteile gegenüber dem papierbasierten Datenaustausch allge-

mein anerkannt sind, die guten Prognosen für EDI nicht bewahrheitet haben. Einer em-

pirischen Untersuchung von 1997 zufolge "[...] nutzen nur 5% der Unternehmen, für die

105

Vgl. MEHNEN (2001), S. 3 106

ebenda


der Einsatz von EDI vorteilhaft wäre, auch tatsächlich EDI".107 Eine 2002 von der EU-

Kommission beauftrage Befragung von 10.000 europäischen Unternehmen kommt zu

dem Ergebnis, dass die EDI-Nutzungsrate bezogen auf alle Unternehmen (auch kleine)

bei 5-31% liegt.108 Der Einsatz von EDI liegt vor allem im Vertrieb und in der Beschaf-

fung (z.B. Bestellungen, Lieferscheine, etc.) der Unternehmen, die Übermittlung von

steuerrelevanten Dokumenten (z.B. Rechnungen) ist von vergleichsweise geringer Be-

deutung.109 Dieses Ergebnis findet sich auch in der schon in Kapitel 1 erwähnten Studie

der Seals GmbH über den Rechnungsaustausch im B2B-Bereich im Jahre 2001 wieder.

Lediglich 4% der über 130 befragten Manager bestätigten, dass sie in ihrem Unterneh-

men EDI zum Versand oder zum Empfang von Rechnungen einsetzen.110

Der Grund für die große Zurückhaltung der Unternehmen gegenüber EDI wird vor al-

lem in der aufwändigen Integration und in den hohen Implementierungs- und Betriebs-

kosten einer EDI-Lösung gesehen.111 Zum einen müssen kostenträchtige Übertragungs-

verbindungen eingerichtet und unterhalten werden. Zum anderen bedarf es spezifisch

angepasster und dadurch teurer Konverter-Software, um Daten automatisch aus einem

unternehmensinternen Inhouse-Format in ein EDI-Format und umgekehrt umzuwandeln

zu können. Des Weiteren kann nicht davon ausgegangen werden, dass alle Geschäfts-

partner eines Unternehmens am Datenaustausch per EDI teilnehmen. Demnach muss

weiterhin auch der papierbasierte Datenaustausch betrieben werden. Das bedeutet einen

Mehraufwand an Verwaltungsarbeit, da zwei Systeme der Datenübermittlung, -

erfassung und -archivierung betrieben werden müssen. Verbreitungshemmend wirkt

außerdem die mangelnde Flexibilität eines EDI-Standards. Auf einen geänderten Ge-

schäftsprozess kann nur mit großer Zeitverzögerung reagiert werden, da die Änderun-

gen erst getestet und später durch verantwortliche Gremien verabschiedet und in den

EDI-Standard aufgenommen werden müssen (dieses Verfahren kann bis zu 2 Jahre dau-

ern).

Der Einsatz von EDI beschränkt sich hauptsächlich auf große Unternehmen und Ban-

ken.112 Hierbei wird versucht, einzelne Bereiche wie beispielsweise das Bestellwesen

107

BUXMANN ET AL (2001), S 7, nach SEGEV/PORRA/ROLDAN (1997) 108

Vgl. BERLECON RESEARCH(2003), S. 93 109

ebenda, nach ZUMPE, ESSWEIN (2002) 110

Vgl. http://www.e-business.de/texte/4844.asp, abgerufen am 02.06.03 111

Vgl. BERLECON RESEARCH(2003), S. 94 112

Vgl. BERLECON RESEARCH(2003), S. 93


oder die Übermittlung von Zahlungsdaten, komplett mit EDI durchzuführen. Kleine und

mittelständische Unternehmen scheuen die hohen Setup- und Betriebskosten eines EDI-

Systems. Ein positiver Kosten-Nutzen-Effekt ist aufgrund des zusätzlichen Mehrauf-

wands bei vergleichsweise geringem Datenvolumen nur schwer erreichbar. Eine Ein-

führung geschieht oft nur auf Druck eines einflussreichen Geschäftspartners, der ein

EDI-System betreibt.113

Neuen Schwung in die Verbreitung des elektronischen Datenaustauschs im Geschäfts-

verkehr könnte das Internet bringen. Als kostengünstiges und leicht implementierbares

Medium könnte es die Punkt-zu-Punkt-Übertragung beziehungsweise VANS als Trans-

portmittel für elektronische Daten ablösen und somit auch kleinen und mittelständi-

schen Unternehmen den Einstieg in den elektronischen Datenaustausch erleichtern.

113

BUXMANN ET AL (2001), S 8

8.1 Einleitung 74

8 Elektronischer Datenaustausch über das Internet

8.1 Einleitung

Das Internet stellt eine Plattform für eine Vielzahl neuer Geschäftsaktivitäten dar. Diese

reichen von der reinen Unternehmensdarstellung durch eine Homepage bis hin zu Onli-

ne-Shopping-Systemen. Ein elektronischer Austausch von Geschäftsdaten mit dem In-

ternet als Grundlage der Datenübertragung wird als "EDI über das Internet" (engl.

"EDI over the Internet") bezeichnet. Ziel dieses Ansatzes ist es, die gegenüber der

papierbasierten Datenübertragung bestehenden Vorteile einer elektronischen Datenüber-

tragung auszunutzen und dabei gleichzeitig durch die Nutzung des Internets als Trans-

portmedium die bestehenden Hindernisse des traditionellen Geschäftsdatenaustauschs

per EDI (siehe 7.6) zu beseitigen.114

Das Internet ist eine ideale Plattform für einen elektronischen Datenaustausch. Musste

für eine traditionelle EDI-Kommunikation eine aufwändige Übertragungsinfrastruktur,

beschränkt auf die teilnehmenden Kommunikationspartner, aufgebaut werden, so ist mit

dem Internet ein nahezu globales Übertragungsnetz schon gegeben. Der Zugang zu die-

sem Netz steht jedem Unternehmen und Privathaushalt offen, wobei als technische Vor-

aussetzungen lediglich ein Internetanschluss und ein Browser benötigt werden. Nach

Ergebnissen einer EU-weiten Unternehmensstudie, haben bereits 83% aller Unterneh-

men mit weniger als 50 Mitarbeitern einen Internetanschluss. Bei Unternehmen mit

mehr als 250 Angestellten liegt der Wert sogar bei 99% (Stand Juli 2002).115 Es kann

demnach davon ausgegangen werden, dass diese Voraussetzungen für einen Datenaus-

tausch über das Internet in nahezu jedem Unternehmen gegeben sind, so dass für die

Übertragungsinfrastruktur keine Investitionen und Implementierungsmaßnahmen auf

Seiten der Kommunikationspartner notwendig werden. Ein weiterer Vorteil des Inter-

nets ist die kostengünstige Datenübertragung. Zahlte ein amerikanisches Unternehmen

mit ca. 25.000 EDI-Nachrichten pro Monat, Mitte der 90er Jahre monatlich zwischen

14.000 $ und 25.000 $ an seinen VAN-Provider, so fallen bei einem Transfer über das

Internet lediglich ca. 1920 $ an Kommunikationskosten an.116

Aufgrund dieser Vorteile setzt sich "EDI über das Internet" gegenüber der traditionellen

EDI-Kommunikationen immer mehr durch. Die Attraktivität des Internets ist so groß,

114

Vgl. BUXMANN ET AL (1998), S. 3 115

Vgl. EBUSINESS REPORT (2002/2003), S. 7 116

Vgl. BUXMANN ET AL (2001), S. 8

8.1 Einleitung 75

dass beispielsweise das Unternehmen 3Com, ein führender Hersteller von Netzwerk-

Infrastrukturprodukten und –lösungen, bis zum Jahr 2005 eine nahezu 100%ige Ab-

wicklung des EDI-Verkehrs über das Internet erwartet.117

Für eine technische Umsetzung von "EDI über das Internet" bildeten sich zwei unter-

schiedliche Lösungsmodelle: Internet-EDI und WebEDI.

Bei Internet-EDI beschränkt sich die Nutzung des Internets lediglich auf den Daten-

transport, wohingegen WebEDI Geschäftspartner über das World Wide Web und einen

Web-Browser miteinander verbindet. Für Internet-EDI kommen als Lösungen ein Da-

tenaustausch per E-Mail oder über das File Transfer Protocol (FTP) in Frage.118

Die folgende Abbildung gibt einen Überblick über die möglichen Dienste und Protokol-

le für "EDI über das Internet".

EDI over the Internet

Internet-EDI WebEDI

Electronic Mail File Transfer World Wide Web

Simple Mail TransferProtocol(SMTP)

File TranferProtocol(FTP)

HyperText TransferProtocol(HTTP)

Multipurpose InternetMail Extensions

(MIME)

HyperText MarkupLanguage(HTML)

Abbildung 8.1: Dienste und Protokolle für EDI über das Internet119

Internet-EDI per E-Mail: Im Internet werden E-Mails mit dem Simple Mail Transfer

Protocol (SMTP) versendet. Das SMTP-Protokoll definiert eine Menge von Regeln, die

benötigt werden um E-Mails über Mail-Server übertragen zu können. Dabei ist es mög-

117



Vgl. BUXMANN ET AL (1998), S. 4, nach Deutsche EDI Gesellschaft

8.1 Einleitung 76

lich, Dateien als sogenannte Attachments mit der E-Mail zu verknüpfen. Die Inhalte

dieser Attachments werden durch den MIME-Standard (Multi-purpose Internet Mail

Extensions) näher spezifiziert. Dieser Standard stellt eine Erweiterung des SMTP-

Protokoll dar und standardisiert die Übertragung von Graphiken, Sprache und anderen

binären Dateien, die kein Text sind.120

Bei der Anwendung von Internet-EDI per E-Mail werden die auszutauschenden Daten

im Anhang einer Mail an den Mail-Server des Senders übertragen. Dieser leitet die

Nachricht, unter Umständen über mehrere Server weiter, bis sie auf dem Mail-Server

des Empfängers angekommen ist. Dort steht die E-Mail mit den angehängten EDI-

Daten für den Empfänger zum Lesen und Weiterverarbeiten bereit. Ein Vorteil dieser

Übertragung ist, dass die beiden Kommunikationspartner nicht in ständigem Kontakt

stehen müssen. Des Weiteren ist keine spezielle Software nötig, sondern jedes beliebige

E-Mail Programm kann dafür eingesetzt werden. Um Datenschutz und rechtliche Si-

cherheit zu gewährleisten, können die E-Mails und der Anhang verschlüsselt übertragen

und elektronisch signiert werden. Zur Verschlüsselung wird in der Regel das SSL-

Protokoll (Secure Socket Layer Protocol) eingesetzt. Dieses Protokoll basiert auf dem

Prinzip der asymmetrischen Verschlüsselung (siehe Kapitel 4.2) und erzeugt eine 128

Bit Verschlüsselung der Daten.121

Internet-EDI per FTP : Um Internet-EDI über FTP zu betreiben, werden die zu trans-

ferierenden Daten auf einem FTP-Server des Senders abgelegt. Der Empfänger hat über

einen FTP-Client (passwortgeschützten) Zugriff auf diesen FTP-Server und kann die für

ihn bereitgestellten Daten von dort abrufen. Das zugrundeliegende FTP-Protokoll regelt

dabei die Client-Server-Kommunikation.122 Die dargestellte Vorgehensweise ist auch in

der entgegengesetzten Richtung möglich, d.h. ein Benutzer kann über einen FTP-Client

Daten für den Betreiber des FTP-Servers ablegen. Um einen Überblick zu bekommen,

welcher Benutzer welche Daten wann abgerufen oder abgelegt hat, kann der Betreiber

des FTP-Servers spezifische Zugriffsdateien auswerten. Bei diesem Verfahren ist es

ebenfalls möglich, die abgelegten Daten zu verschlüsseln und zu signieren.

WebEDI: Gegenüber den VANs bei traditionellem EDI (siehe Kapitel 7.4), geht bei

WebEDI die Nutzung des Internets über die Nutzung als verbilligtes Transportmedium

120

Vgl. SIEMENS ONLINE-LEXIKON 121

ebenda 122

ebenda

8.2 XML-basierter Datenaustausch 77

von EDI-Nachrichten hinaus. Die beteiligten Kommunikationspartner tauschen Daten

über in einem Web-Browser angezeigte Internet-Seiten per HTTP-Protokoll aus. Das

Internet wird somit zusätzlich als graphische Oberfläche für den Datenaustausch ge-

nutzt. Auch hier kann die Sicherheit durch eine verschlüsselte Verbindung gewährleistet

werden. Ein Beispiel für eine WebEDI-Anwendung ist ein Bestellnetzwerk, bei dem ein

Kunde über eine Eingabemaske einer Web-Site die gewünschten Artikel aus einem On-

line-Katalog des Lieferanten auswählt und bestellt. Die Bestellung wird dann per

HTTP-Protokoll über den Web-Server des Anbieters in dessen internes EDV-System

versendet und dort automatisch weiterverarbeitet.

Ausgerichtet an den Problemen des traditionellen EDI ergeben sich, für Software- und

Hardware-Anwendungen für den elektronischen Datenaustausch über das Internet, fol-

gende grundsätzlichen Anforderungen:123

• geringer Setup-Aufwand (Implementierungskosten und Zeitaufwand für die

Einführung),

• niedrige Betriebskosten,

• flexible Einsatzmöglichkeiten und Erweiterbarkeit,

• einfache Integration in Inhouse-Systeme (Bereitstellung geeigneter Schnitt-

stellen),

• leichte Bedienbarkeit,

• Sicherheit der Datenübertragung.

Für eine elektronische Rechnungsübertragung über das Internet muss zusätzlich der

Einsatz von elektronischen Signaturen in das Übertragungsverfahren eingebunden wer-

den.

8.2 XML-basierter Datenaustausch

8.2.1 Entwicklung und Motivation von XML

Analog zu dem elektronischen Datenaustausch per traditionellem EDI, bedarf es auch

bei "EDI über das Internet" einem standardisierten Austauschformat, auf dem entspre-

chende Software-Anwendungen aufbauen können. Die Auswahl eines geeigneten Da-

tenformats hat wesentlichen Anteil daran, inwieweit die Anwendungen den an sie ge-

123



stellten Anforderungen (s.o.) gerecht werden können. Im Falle von "EDI über das Inter-

net" ist die Extensible Markup Language (XML) das Datenformat, welches am Bes-

ten geeignet scheint.

Entwickelt wurde XML durch das World Wide Web Consortium (W3C), einem Kon-

sortium mit Mitgliedern aus den Bereichen Industrie, Forschung und Politik.124�XML

stellt einen offenen Standard dar und liegt seit Februar 1998 als so genannte Recom-

mendation125 ("Empfehlung") des W3C frei zugänglich vor. Ziel dieser XML-

Empfehlung ist es, eine standardisierte Referenz für XML öffentlich bereitzustellen, um

die Sprachspezifikationen schnell zu verbreiten und die Entwicklung von interoperablen

XML-Produkten zu fördern.126 Das W3C definiert XML als "data format for structured

document interchange on the web", was übersetzt bedeutet, dass XML ein Datenformat

für einen strukturierten Datenaustausch über das Internet darstellt.127 Analog zu der

Entwicklung von traditionellen EDI-Formaten wie beispielsweise EDIFACT liegt das

Hauptanliegen von XML demnach in der Beschreibung strukturierter Dokumente, wie

etwa Bestellungen, Produktbeschreibungen und Rechnungen. Allerdings mit dem Un-

terschied, dass diese Dokumente nicht für den Austausch über eigens dafür eingerichte-

te Verbindungen, sondern für den Austausch über das Internet geeignet sein sollen.

Mit HTML (HyperText Markup Language)128 existiert bereits eine (ebenfalls durch

das W3C entwickelte) einfache und weltweit etablierte Sprache, um Inhalte im Internet

darzustellen. HTML-Dokumente setzen sich aus Tags oder Auszeichnern (< >, </>) und

einem darin eingeschlossenen Inhalt zusammen. Die Aufgabe der Tags ist, dem Brow-

ser anzuzeigen, wie die Inhalte darzustellen sind. Beispielsweise bedeutet

<H1>Titel</H1> für einen Browser, das der Inhalt "Titel" in Times New Roman,

Schriftgröße 24 und fett gedruckt dargestellt werden soll.

HTML ist also vor allem eine Präsentationssprache für das Internet. Das HTML-

Sprachkonzept bringt folgende Probleme, die auch als "HTML-Dilemma" zusammenge-

fasst werden, mit sich:129

124

Mitglieder sind u.a. Microsoft, IBM, Deutsche Telekom. Nähere Informationen siehe http://www.w3c.org 125

Siehe W3C_XML 126

Vgl. http://www.edition-w3c.de/TR/1998/REC-xml-19980210, Abruf 19.05.03 127

Siehe W3C_XML 128

Siehe W3C_HTML 129

Vgl. BUXMANN ET AL (2001), S. 16-17, nach BOSAK, J. (1997)


• Erweiterbarkeit: HTML bedient sich nur einer fest vorgegebenen Menge von

Tags, d.h. es können weder eigene Tags gesetzt werden noch können indivi-

duelle Attribute zur semantischen Auszeichnung von Daten spezifiziert wer-

den. Ein in HTML codiertes Dokument enthält lediglich die Informationen,

wie Inhalte darzustellen sind, erlaubt aber keine Angaben über ihre semanti-

sche Bedeutung.

• Struktur: Abgesehen von Formatinformationen können in HTML keine Daten-

strukturen beschrieben werden. Ein Zusammenhang von Daten untereinander

ist nicht beschreibbar, d.h. bestehende Datenstrukturen gehen bei einer Über-

führung in HTML verloren.

• Validierung: HTML fehlen Sprachspezifikationen, die Anwendungen, die

HTML-codierte Daten verarbeiten sollen, eine Überprüfung der strukturellen

Validität der Daten erlauben.

Mit der Entwicklung von XML wurde versucht diese Nachteile zu beheben und somit

eine universell einsetzbare Sprache für das Internet zu erzeugen. Der Schwerpunkt von

XML liegt nicht nur auf der reinen Darstellung von Daten im Internet, sondern vor al-

lem darauf, Daten für eine Vielzahl von Anwendungen nutzbar zu machen.

XML stellt, genau wie HTML, eine Teilmenge bzw. Anwendung der Standard Gene-

ralized Markup Language (SGML)130 dar. SGML ist eine Metasprache, d.h. sie stellt

Vorschriften bereit um Auszeichnungssprachen (engl. Markup Languages) formal zu

definieren. SGML existiert bereits seit über 15 Jahren als internationaler Standard (ISO

8879) für die Definition, Identifikation und Benutzung von Struktur und Inhalt von Do-

kumenten. Während einerseits HTML wegen der fehlenden Erweiterbarkeit für kom-

plexere Anwendungen ungeeignet ist, ist SGML andererseits schon zu komplex und

deshalb im Internet nur eingeschränkt einsetzbar.131 XML stellt den Mittelweg dar, wie

die folgende Abbildung verdeutlicht:

130

Nähere Informationen siehe http://www.oasis-open.org/cover/ 131



SGML

XML

HTML

Struktur

Daten

grob fein

einfach

komplex

Abbildung 8.2: Abgrenzung HTML, XML und SGML 132

Um die Komplexität zu reduzieren, wurden bei der Entwicklung von XML alle für die

Anwendung im Internet als überflüssig angesehenen Eigenschaften und Funktionen von

SGML nicht übernommen. Laut den Entwicklern bietet XML 80% der Funktionalität

von SGML bei 20% der Komplexität.133 XML vereint demnach die Vorteile von HTML

und SGML: Auf der einen Seite ist XML einfach zu erlernen, zu verwenden und zu

implementieren und auf der anderen Seite bietet es die bei HTML fehlenden Vorteile

von SGML der Erweiterbarkeit, Strukturierung und Validierung.134

8.2.2 XML-Grundlagen

XML-Dokumente sind Textdateien, d.h. sie können plattformunabhängig mit jedem

beliebigen Texteditor erstellt, gelesen und verändert werden.

Rein äußerlich erinnert XML sehr stark an HTML, da auch XML-Dokumente aus Tags

und darin eingeschlossenem Inhalt bestehen. Während aber HTML als reine Präsentati-

onssprache Inhalt und Präsentation eines Dokuments untrennbar miteinander verknüpft,

beruht das Sprachkonzept von XML auf einer Trennung von Inhalt, Struktur und Prä-

sentation.

132

Vgl. MÖHR, SCHMIDT (1999), S. 94-99 133

Vgl. MÜLLER-STEINHAGEN (2001), S. 1 134

Vgl. BOSAK (1997)


Inhalt

Formatierung

Präsentation

Struktur

Abbildung 8.3: XML-Sprachkonzept135

Der Inhalt eines XML-Dokuments ist von Tags eingeschlossen, die aber im Gegensatz

zu HTML frei benannt werden können und somit nicht auf eine feste Menge beschränkt

bleiben. Damit ergibt sich die Möglichkeit, dass die Tags, durch eine entsprechende

Auszeichnung, Informationen über die Bedeutung des Inhalts enthalten können. Durch

eine Verschachtelung der Tags ineinander kann dem Dokument zudem eine Struktur

zugeordnet werden. Da diese Dokumentstruktur rein auf der Anordnung der verwende-

ten Tags basiert, können Inhalt und Struktur getrennt werden.

Für eine Präsentation von XML-Dokumenten sind separate Formatierungsangaben not-

wendig, die für die verwendeten Tags festlegen, wie deren Inhalte dargestellt werden

sollen.

Gegenüber HTML lassen sich folgende grundsätzliche Unterschiede erkennen:136

• XML-Tags und Attribute können individuellen Anforderungen entsprechend

neu definiert und benannt werden.

• XML-Dokumentenstrukturen lassen sich in beliebiger Komplexität abbilden

(z.B. ist die Struktur einer Datenbank darstellbar).

• XML-Dokumente können optional eine formale Beschreibung ihrer Gramma-

tik enthalten, anhand derer eine strukturelle Validierung des Dokuments durch

Applikationen möglich wird.

Die Vorteile eines XML-Dokuments gegenüber einem in HTML-codierten werden bei

einem direkten Vergleich deutlich. Nachfolgend sind Informationen zu einer Person

135


Vgl. BUXMANN ET AL (2001), S. 19, nach BOSAK, J. (1997)


(Name und Anschrift), wie sie beispielsweise in einer Rechnung benötigt werden, in

HTML und XML dargestellt:

HTML (person.html) XML (person.xml)

<P><strong>Herr Max Mus-ter</strong> Musterstrasse 20, 1000 Musterstadt</P>

<PERSON> <NAME> <ANREDE>Herr</ANREDE> <VORNAME>Max</VORNAME> <NACHNAME>Muster</NACHNAME> </NAME> <ADRESSE> <STRASSE>Musterstrasse</STRASSE> <HAUSNR>20</HAUSNR> <PLZ>1000</PLZ> <ORT>Musterstadt</ORT> </ADRESSE> </PERSON>

Tabelle 8.1: Vergleich HTML-/XML-Dokument

HTML beschränkt sich rein auf die Darstellung der durch die Tags eingeschlossenen

Information. Im obigen Beispiel wird das Attribut "Herr Max Muster" durch die Tags

<strong> </strong> fett dargestellt. Das es sich dabei um einen Namen handelt ist nur

an dem Namen selbst zu erkennen. Die ihn umschließenden Tags geben darüber keinen

Aufschluss.

Anders bei XML: Hier ist, durch die Möglichkeit Tags frei zu benennen, die semanti-

sche Bedeutung der Attribute anhand der Auszeichnung der Tags erkennbar. Im Bei-

spiel wird deutlich, dass es sich bei den aufgeführten Tags und ihren Inhalten um eine

komplette Beschreibung einer Person mit Namen und Adresse handelt.

Des weiteren lässt sich durch eine Verschachtelung der einzelnen Tags eine Dokument-

struktur abbilden. Im Beispiel besitzt der Tag "PERSON", welcher als Wurzeltag (Root-

Element) das Dokument umrahmt, die Angaben "NAME" und "ADRESSE", die jeweils

selbst weitere Kindelemente ("ANREDE", "VORNAME", "NACHNAME" bzw.

"STRASSE", "HAUSNUMMER", "PLZ", "ORT") enthalten.

Die Struktur eines XML-Dokuments kann in einem Baumdiagramm (XML-Tree ) dar-

gestellt werden. Umgekehrt kann ein Baumdiagramm Grundlage für die Verschachte-

lung der Tags eines XML-Dokuments sein. Auf diese Weise lässt sich die Datenhierar-

chie mit Hilfe von Parent- und Child -Elementen nachvollziehen bzw. definieren. Ein

Parent-Element kann mehrere Child-Elemente enthalten, jedem Child-Element ist aber

nur genau ein Parent zugeordnet. Neben diesen Elementen existiert noch das Root-


Element. Das Root-Element ist das erste Element (besitzt also kein Parent) in einem

XML-Dokument und enthält alle anderen Elemente.

Folgende Abbildung beschreibt das Baumdiagramm des obigen Beispiels:

PERSON

ADRESSE

ANREDE STRASSEVORNAME

NAME

NACHNAME HAUSNR PLZ

Musterstadt100020MusterstrasseMusterMaxHerr

Wert

ORT

Element

Abbildung 8.4: XML-Tree zum XML-Dokument in Tabelle 8.1

8.2.3 Wohlgeformte XML-Dokumente

XML-Dokumente müssen bestimmten syntaktischen Sprachspezifikationen entspre-

chen. Der Begriff der Wohlgeformtheit stellt eine Minimalanforderung an XML-

Dokumente dar und umfasst die folgenden Regeln:137

• Zu Beginn des Dokuments muss im so genannten Prolog der Hinweis auf die

zugrundeliegende XML-Version erfolgen: <?xml version="1.0"?>.

• Jeder geöffnete Tag muss explizit geschlossen werden.

• Tags ohne Inhalt müssen entweder explizit geschlossen werden oder mit />

enden (z.B. <BR></BR> oder <BR/>).

• Attribut-Werte müssen in doppelten Anführungszeichen stehen (z.B. <?xml

version="1.0"?>.

• Das Markup (Anordnung der Tags/Elemente) muss, wie bei SGML oder bei

der mathematischen Klammersetzung, streng hierarchisch gegliedert sein (ins-

besondere dürfen keine Überlappungen vorkommen).

• Innerhalb des Textes dürfen keine Markup-Zeichen (< oder &) vorkommen

und alle Attribute, die für alle Elemente verwendet werden können, müssen

vom Default-Typ CDATA (siehe Kapitel 8.2.4) sein.

137

Vgl. BUXMANN ET AL (2001), S. 22-23


Abbildung 8.5 zeigt ein wohlgeformtes XML-Dokument, dessen Struktur eine Rech-

nung mit den nach dem UStG geforderten, inhaltlichen Bestandteilen beschreibt. In der

ersten Zeile stehen im Prolog die XML-Deklaration (hier: Version 1.0) sowie ein Hin-

weis zu dem verwendeten Encoding Schema. Das Encoding Schema macht u. a. Anga-

ben zu dem zugrundeliegenden Zeichensatz (z.B. europäisch, chinesisch) des XML-

Dokuments und ermöglicht so einen international Einsatz von XML. Anschließend

folgt, umrahmt von dem Wurzelelement "RECHNUNG", das eigentliche Dokument un-

terteilt in die Bereiche "RECHNUNGSKOPF" und "RECHNUNGSPOSITIONEN", die

selbst wieder Kindelemente enthalten. Abschließend werden noch "GESAMT-NETTO"

und "UMSATZSTEUER" aufgeführt. Die Anordnung der Elemente ist dabei streng hie-

rarchisch und erfüllt somit das geforderte Wohlgeformtheitskriterium.

<?xml version=“1.0“ encoding=“UTF-8“ rmd=“NONE“?>

<RECHNUNG>

<RECHNUNGSKOPF> <KUNDE>

<NAME>Muster</NAME> <VORNAME>Max</VORNAME>

<ADRESSE> <STRASSE>Musterstrasse</STRASSE> <HAUSNR>20</HAUSNR> <PLZ>1000</PLZ> <ORT>Musterstadt</ORT> </ADRESSE>

</KUNDE> <ABSENDER> ...siehe Kunde... <STEUERNUMMER>432-334-121</ STEUERNUMMER> </ABSENDER>

<LIEFERDATUM>03.06.2002</LIEFERDATUM> <RECHNUNGSNR>12314</RECHNUNGSNR> <RECHNUNGSDATUM>12.06.2002</RECHNUNGSDATUM>

</RECHNUNGSKOPF>

<RECHNUNGSPOSITIONEN> <POSITION>

<BEZEICHNUNG>19'' Flachbildschirm</BEZEICHNUNG> <ARTIKELNUMMER>4711.236</ARTIKELNUMMER> <PREIS>820,00</PREIS> <ANZAHL>1</ANZAHL>

</POSITION> <POSITION> ... </POSITION>

</RECHNUNGSPOSITIONEN>

<GESAMT-NETTO>951,37</GESAMT-NETTO> <UMSATZSTEUER>152,21</UMSATZSTEUER>

</RECHNUNG>

Abbildung 8.5: Beispiel für ein wohlgeformtes XML-Dokument (Rechnung.xml)


8.2.4 Document Type Definition (DTD)138

XML-Dokumente können durch Applikationen gelesen und weiterverarbeitet werden.

Diese Applikationen werden als Parser bezeichnet. Wie bereits erwähnt kann ein

XML-Dokument mit einer Grammatik verknüpft werden, so dass eine Validierung des

Dokumentes durch einen Parser nach den Regeln dieser Grammatik ermöglicht wird.

Die Verknüpfung kann entweder implizit durch die Verwendung der Elemente in einer

bestimmten Reihenfolge geschehen (wie im obigen Beispiel) oder explizit in Form einer

zusätzlichen Grammatik, der so genannten Document Type Definition (DTD).

In einer DTD werden alle nötigen bzw. möglichen Tags und deren geschachtelte Struk-

tur im Dokument definiert. Der Verweis auf die zugehörige DTD erfolgt zu Beginn des

XML-Dokuments nach dem reservierten Schlüsselwort DOCTYPE (Dokumententyp).

Es werden der Dokumentenname, der identisch mit der Bezeichnung des Wurzelele-

mentes ist, und der Ort (Web-Adresse), an dem sich die DTD befindet, angegeben. Da-

mit weiß der Parser, wo die DTD zur Validierung abgelegt ist. Alternativ kann eine

DTD aber auch direkt in das XML-Dokument eingebunden werden. Dies geschieht,

indem die DTD in eckigen Klammern anstelle der Adressangabe in die DOCTYPE-

Deklaration eingefügt wird.

Ein wohlgeformtes XML-Dokument, das noch dazu seiner DTD entspricht, wird als

gültig (valid) bezeichnet.

DTDs können, neben der Möglichkeit XML-Dokumente auf strukturelle Fehler hin zu

untersuchen, auch dazu genutzt werden neue Instanzen des durch sie beschriebenen Do-

kumententyps zu bilden. Funktional lässt sich eine DTD mit dem Relationenschema

einer Datenbank vergleichen. Das Relationenschema legt die Inhalte und Beziehungen

einer Datenbank (dargestellt in einem Entity-Relationship Modell) fest, DTDs die In-

haltsmodelle bestimmter Dokumenttypen (dargestellt durch XML-Trees).

Eine DTD, die dem in Abbildung 1.4 dargestellten Dokumenttyp "Rechnung" ent-

spricht, kann wie folgt dargestellt werden:

138



<!ELEMENT RECHNUNG (RECHNUNGSKOPF, RECHNUNGSSPOSITIONEN, GESAMT-NETTO, UMSATZSTEUER)> <!ELEMENT RECHNUNGSKOPF (KUNDE, ABSENDER, LIEFERDATUM, RECHNUNGSNR, RECHNUNGSDATUM)> <!ELEMENT KUNDE (NAME, VORNAME, ADRESSE)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT VORNAME (#PCDATA)> <!ELEMENT ADRESSE (STRASSE, HAUSNR, PLZ, ORT)> <!ELEMENT STRASSE (#PCDATA)> <!ELEMENT PLZ (#PCDATA)> <!ELEMENT ORT (#PCDATA)> <!ELEMENT ABSENDER (NAME, VORNAME, ADRESSE)> <!ELEMENT LIEFERDATUM (#PCDATA)> <!ELEMENT RECHNUNGSNR (#PCDATA)> <!ELEMENT RECHNUNGSDATUM (#PCDATA)> <!ELEMENT RECHNUNGSPOSITIONEN (POSITION)> <!ELEMENT POSITION (BEZEICHNUNG, ARTIKELNUMMER, PREIS, ANZAHL)> <!ELEMENT BEZEICHNUNG (#PCDATA)> <!ELEMENT ARTIKELNUMMER (#PCDATA)> <!ELEMENT PREIS (#PCDATA)> <!ELEMENT ANZAHL (#PCDATA)> <!ELEMENT GESAMT-NETTO (#PCDATA)> <!ELEMENT UMSATZSTEUER (#PCDATA)>

Abbildung 8.6: Beispiel einer Document Type Definition (Rechnung.dtd)

In der DTD müssen alle in einem gültigen Dokument vorkommenden Elemente sowie

deren jeweils erlaubten Inhalte (Inhaltsmodell) deklariert sein. Im Allgemeinen können

Elemente andere Elemente (Kind-Elemente) oder Zeichendaten enthalten. XML unter-

scheidet bei Zeichendaten zwischen den Datentypen parsed character data (PCDA-

TA) und character data (CDATA). PCDATA beschreibt Zeichendaten eines XML-

Dokuments, die beim Lesen durch den Parser analysiert werden. Daten vom Typ

CDATA hingegen werden vom Parser ignoriert.

Der folgende Auszug aus der DTD in Abbildung 8.6 verdeutlicht das Prinzip der Ele-

mentdeklaration:

<!ELEMENT KUNDE (NAME, VORNAME, ADRESSE)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT VORNAME (#PCDATA)> <!ELEMENT ADRESSE (STRASSE, HAUSNR, PLZ, ORT)>

Das Element "KUNDE" besitzt die Kind-Elemente "NAME", "VORNAME" und "AD-

RESSE", die in genau dieser Reihenfolge im Dokument vorkommen müssen. Die Ele-

mente "NAME" und "VORNAME enthalten Zeichendaten vom Typ PCDATA, d.h. der

Inhalt kann von einem Parser gelesen werden. Das Element "ADRESSE" enthält selbst


wieder die Kindelemente "STRASSE", "HAUSNR", "PLZ" und "ORT", welche in der

DTD ebenfalls deklariert werden.

Im Inhaltsmodell kann mit Hilfe der Suffixes ?, + und * festgelegt werden, wie oft be-

stimmte Elemente vorkommen dürfen. Elemente können genau einmal (ohne Suffix),

höchstens (?) oder mindestens (+) einmal oder beliebig häufig (*) vorkommen.

Das folgende Beispiel

<!ELEMENT a (b, c? (d|e)+, f*)>

bedeutet, dass das Element mit dem Namen "a" als erstes Kindelement das Element "b"

haben muss, gefolgt von keinem oder einem Element "c", mindestens einem Element

"d" oder "e" und beliebig vielen Elementen "f".139

Elemente eines XML-Dokuments können des Weiteren durch Attribute näher beschrei-

ben werden. Attribute stellen Name-Wert-Paare dar, deren Wert nach den Regeln der

Wohlgeformtheit (siehe 8.2.3) in doppelten Anführungsstrichen stehen muss. Die Zu-

weisung des Wertes geschieht im Start-Tag eines Elements.

Wie die Elemente, müssen auch alle Attribute in der DTD deklariert sein. Dazu dient

das reservierte Schlüsselwort ATTLIST. Attribute können als optional (#IMPLIED), obli-

gatorisch (#REQUIRED) oder "fixed" (#FIXED – konstanter Attributwert) gekennzeich-

net sein. Die Attributdeklaration der Positionsbezeichnung (Element BEZEICHNUNG)

der Rechnungs-DTD aus Abbildung 8.6 könnte wie folgt aussehen:

<!ATTLIST BEZEICHNUNG typ CDATA #REQUIRED abbildung CDATA #FIXED "http://Produkt.Bilder.de/hd.html" status (angebot | normal) "normal">

Das Element "BEZEICHNUNG" hat in diesem Beispiel das obligatorische Attribut "typ"

und das Attribut "abbildung", dessen Wert immer die angegebene Web-Adresse ist. Das

Attribut "status" kann die Werte "angebot" oder "normal" annehmen, wobei "normal"

explizit als Standardwert angegeben ist.

139



Die folgenden Abbildungen zeigen das um eine DTD und Attribute erweiterte XML-

Rechnungsdokument aus Abbildung 1.4 und die zugehörige DTD.

<!ELEMENT RECHNUNG (RECHNUNGSKOPF, RECHNUNGSSPOSITIONEN, GESAMT-NETTO, UMSATZSTEUER)> <!ELEMENT RECHNUNGSKOPF (KUNDE, ABSENDER, LIEFERDATUM, RECHNUNGSNR, RECHNUNGSDATUM)> <!ELEMENT KUNDE (NAME, VORNAME, ADRESSE)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT VORNAME (#PCDATA)> <!ELEMENT ADRESSE (STRASSE, HAUSNR, PLZ, ORT)> <!ELEMENT STRASSE (#PCDATA)>

<!ELEMENT PLZ (#PCDATA)> <!ELEMENT ORT (#PCDATA)> <!ELEMENT ABSENDER (NAME, VORNAME, ADRESSE)> <!ELEMENT LIEFERDATUM (#PCDATA)> <!ELEMENT RECHNUNGSNR (#PCDATA)> <!ELEMENT RECHNUNGSDATUM (#PCDATA)> <!ELEMENT RECHNUNGSPOSITIONEN (POSITION)> <!ELEMENT POSITION (BEZEICHNUNG, ARTIKELNUMMER, PREIS, ANZAHL)> <!ELEMENT BEZEICHNUNG (#PCDATA)> <!ATTLIST BEZEICHNUNG typ CDATA #REQUIRED abbildung CDATA #FIXED "http://Produkt.Bilder.de/hd.html" status (angebot | normal) "normal"> <!ELEMENT ARTIKELNUMMER (#PCDATA)> <!ELEMENT PREIS (#PCDATA)> <!ELEMENT ANZAHL (#PCDATA)> <!ELEMENT GESAMT-NETTO (#PCDATA)> <!ELEMENT UMSATZSTEUER (#PCDATA)>

Abbildung 8.7: DTD zum XML-Dokument in Abbildung 8.5 (rechnung2.dtd)


<?xml version=“1.0“ encoding=“UTF-8“ rmd=“NONE“?> <!DOCTYPE RECHNUNG SYSTEM "rechnung2.dtd">

<RECHNUNG>


<NAME>Muster</NAME> <VORNAME>Max</VORNAME>

<ADRESSE> <STRASSE>Musterstrasse</STRASSE> <HAUSNR>20</HAUSNR> <PLZ>1000</PLZ> <ORT>Musterstadt</ORT> </ADRESSE>

</KUNDE> <ABSENDER> ...siehe Kunde... <STEUERNUMMER>432-334-121</ STEUERNUMMER> </ABSENDER>

<LIEFERDATUM>03.06.2002</LIEFERDATUM> <RECHNUNGSNR>12314</RECHNUNGSNR> <RECHNUNGSDATUM>12.06.2002</RECHNUNGSDATUM>

</RECHNUNGSKOPF>

<RECHNUNGSPOSITIONEN> <POSITION>

<BEZEICHNUNG>19'' Flachbildschirm</BEZEICHNUNG> <ARTIKELNUMMER>4711.236</ARTIKELNUMMER> <PREIS>820,00</PREIS> <ANZAHL>1</ANZAHL>

</POSITION> <POSITION> ... </POSITION>

</RECHNUNGSPOSITIONEN>

<GESAMT-NETTO>951,37</GESAMT-NETTO> <UMSATZSTEUER>152,21</UMSATZSTEUER>

</RECHNUNG>

Abbildung 8.8: Beispiel für ein gültiges XML-Dokument (rechnung2.xml)

8.2.5 XML-Schemata

Die explizite Festlegung einer Grammatik eines XML-Dokumenttyps in einer DTD un-

terliegt einigen (zum Teil) erheblichen Nachteilen. So handelt es sich bei DTDs nicht

um XML-Dokumente. Daher ist ein Datenzugriff über Zugriffsmodelle (wie z.B. Do-

cument Object Model (DOM) 140) oder Schnittstellen nicht möglich. Weiterhin sind die

Typdeklarationen stark eingeschränkt, es gibt zum Beispiel keinen Datentyp für eine

explizite Beschreibung von Datums- oder Währungsangaben.

140

Siehe W3C_DOM (2000)


Als Lösung auf diese Unzulänglichkeiten stellte das W3C nach 2 Jahren Entwicklungs-

zeit am 2. Mai 2001 die XML Schema Recommendation141 vor. Im Grunde erfüllen

die darin beschriebenen XML-Schemata die gleiche Funktion wie DTDs. Sie stellen

explizite formale Anforderungen an XML-Dokumente bzw. sind Grundlage für Instan-

zen von XML-Dokumenttypen.142

Die Vorteile eines Schemas gegenüber einer DTD liegen vor allem in den folgenden

Punkten:143

• Ein Schema ist ein (wohlgeformtes) XML-Dokument. Damit wird eine einfa-

che Weiterverarbeitung ermöglicht. Auf einzelne Elemente, Attribute etc.

kann direkt zugegriffen werden.

• Erweiterte Datentypen werden unterstützt (derzeit über 30 verschiedene, wie

beispielsweise Ganzzahl, Datum etc.) und eigene Datentypen können definiert

werden.

• Ein Vererbungskonzept ist implementiert.

• Erweiterte Strukturspezifikationen für Elemente können definiert werden (z.B.

wie häufig Elemente mindestens/höchstens vorkommen müssen/dürfen (mi-

nOccur/maxOccur)).

• Äquivalente Felddefinitionen sind möglich (z.B. Element PREIS = Element

PRICE).

• Eine offene/unvollständige Definition der Inhaltsmodelle ist möglich.

Aufgrund der aufgeführten Vorteile ist davon auszugehen, dass XML-Schematas die

DTDs nach und nach ablösen werden.144

Zur Verdeutlichung werden nachfolgend eine DTD und ein Schema zu dem sehr einfa-

chen XML-Dokument (person.xml) aus Tabelle 8.1 vorgestellt.

141

Siehe http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ 142


Vgl. BUXMANN ET AL (2001), S. 29-30 144

Vgl. WYKE (2002)


<!ELEMENT PERSON (NAME, ADRESSE)> <!ELEMENT NAME (ANREDE, VORNAME?, NACHNAME)> <!ELEMENT ANREDE (#PCDATA)> <!ELEMENT VORNAME (#PCDATA)> <!ELEMENT NACHNAME (#PCDATA)> <!ELEMENT ADRESSE (STRASSE, HAUSNR, PLZ, ORT)> <!ELEMENT STRASSE (#PCDATA)> <!ELEMENT HAUSNR (#PCDATA)> <!ELEMENT PLZ (#PCDATA)> <!ELEMENT ORT (#PCDATA)>

Abbildung 8.9: DTD (adresse.dtd) zu XML-Dokument in Tabelle 8.1

Die nachfolgende Abbildung stellt die gleiche Information in einem XML-Schema dar.

<?xml Version=“1.0“?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd: complexType name="PERSON"> <xsd:sequence> <xsd:element name="NAME" type="PersName"/> <xsd:element name="ADRESSE" type="PersAdresse"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="PersName"> <xsd:sequence> <xsd:element name="ANREDE" type="xsd:string"/> <xsd:element name="VORNAME" type="xsd:string" minOccurs="0" maxOccurs="1"/> <xsd:element name="NACHNAME" type="xsd:string"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="PersAdresse"> <xsd:sequence> <xsd:element name="STRASSE" type="xsd:string"/> <xsd:element name="HAUSNR" type="xsd:positiveInteger"/> <xsd:element name="PLZ" type=" xsd:positiveInteger "/> <xsd:element name="ORT" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:schema>

Abbildung 8.10: XML-Schema (Adresse.xsd) zu XML-Dokument in Tabelle 8.1145

Die erste Zeile zeigt, dass es sich hier im Gegensatz zur analogen DTD um ein (wohlge-

formtes) XML-Dokument handelt. Das anschließend folgende Wurzelelement "sche-

ma" beinhaltet die gesamte Definition des Inhaltsmodells eines auf diesem Schema auf-

bauenden XML-Dokuments. Jedes Element im Schema beginnt mit dem Präfix "xsd:"

145

Vgl. MINTERT (2002), S. 323


welches über die Deklaration xmlns:xsd="http://www.w3.org/2001/XMLSchema" bei

dem Wurzelelement "schema" kennzeichnet, dass alle hier verwendeten Elemente und

Datentypen dem durch das W3C definierten XML Schema-Vokabular zuzuordnen

sind.146

Grundsätzlich wird in XML Schema zwischen Elementen komplexen Typs (complex

types), die Elemente enthalten und Attribute tragen dürfen, und Elemente einfachen

Typs (simple types), bei denen das nicht zulässig ist, unterschieden. Das hier dargestell-

te Schema beginnt mit einem komplexen Typ mit Namen "PERSON", der eine Sequenz

(sequence), also eine Aufzählung von Elementen in fester Reihenfolge, enthält. Ele-

mente tragen stets einen Namen und können im XML-Dokument Werte eines bestimm-

ten Typs enthalten. Die bei "PERSON" aufgeführten Elemente "NAME" und "ADRES-

SE" sind von den selbst definierten Typen "PersName" und "PersAdresse". Diese bei-

den Typen beschreiben selbst wieder komplexe Typen, die zum einen eine Sequenz der

Elemente "ANREDE", "VORNAME" und "NACHNAME" und zum anderen "STRASSE",

"HAUSNR", "PLZ" und "ORT" enthalten.

Die in den Sequenzen von "PersName" und "PersAdresse" aufgeführten Elemente sind

einfache Typen und bis auf die Elemente "HAUSNR" und "PLZ" vom Datentyp string.

"HAUSNR" und "PLZ" beinhalten Zahlenwerte vom Typ positiveInteger (z.B. 1, 1256).

Das Element "VORNAME" ist optional, und darf, festgelegt durch die Werte von mi-

nOccurs/maxOccurs, keinmal oder höchstens einmal in einem dem Schema entspre-

chenden XML-Dokument vorkommen. Alle anderen Elemente besitzen keine explizite

Angabe der Häufigkeit und müssen demnach genau einmal vorkommen.

8.2.6 Präsentation von XML-Dokumenten147

XML-Dokumente können (im Gegensatz zu HTML) aus letztlich unendlich vielen ver-

schiedenen Tags bestehen, so dass in einer Applikation (z.B. einem Webbrowser) un-

möglich festgelegt sein kann, wie das Dokument darzustellen ist. Aufgrund des be-

schriebenen XML-Sprachkonzepts, basierend auf einer Trennung von Inhalt, Struktur

und Layout von Dokumenten, ist es aber für die Applikation auch nicht möglich, die

Informationen zur Präsentation des Dokuments aus dem Dokument selbst zu beziehen.

Die Präsentation von XML-Dokumenten erfolgt deshalb durch externe Formvorlagen,

den so genannten Style Sheets. Das Layout eines Dokuments wird in einem Style Sheet,

146

Vgl. MINTERT (2002), S. 322 147



auf das im Dokument explizit verwiesen wird, festgelegt. Der Verweis erfolgt durch

eine Processing Instruction (PI). PIs übergeben Informationen und Anweisungen un-

terschiedlichster Art an die das Dokument verarbeitenden Applikationen und werden

durch <? und ?> gekennzeichnet. Ein Verweis auf ein zugehöriges Style Sheet erfolgt in

einem Dokument beispielsweise durch:

<?xml-style-sheet type="text/css" href="style1.css"?>.

Mit Cascading Style Sheets (CSS)148 entwickelte das W3C eine Style-Sheet-Sprache

zur Formatierung von HTML-Dokumenten weiter, so dass auch die Darstellung von

XML-Dokumenten ermöglicht wird. Die folgende Abbildung zeigt, wie den einzelnen

Elementen des XML-Dokuments "rechnung.xml" (siehe Abbildung 1.5) durch ein ein-

faches CSS ("style1.css") Formatierungsbefehle zugewiesen werden und wie das Do-

kument daraufhin im Browser angezeigt wird:

XML-Dok. (rechnung.xml) Präsentation im Browser (Internet Explorer 5.0) <?xml version=“1.0“ enco-ding=“UTF-8“ rmd=“NONE“?> <?xml-stylesheet type="text/css" href="style1.css"?> <RECHNUNG>


...........................

</RECHNUNG>

CSS (style1.css)

RECHNUNG {Display: Block; background-color: yellow; float: left; padding: 15pt} NAME, VORNAME, E-MAIL {Display: Block; font-size: 14pt; font family: Times, serif} POSITION {Display: Block; background-color: blue; font-size: 14pt; font family: Times, sansserif}

Abbildung 8.11: XML-Dokument mit einfachem CSS

Eine eigens zur Darstellung von XML-Dokumenten entwickelte Style-Sheet-Sprache

stellt die Extensible Stylesheet Language (XSL)149 dar. Während CSS nur zur Präsen-

tation nutzbar ist, kann XSL auch aktive Operationen ausführen wie beispielsweise eine

148

Siehe W3C_CSS(2000) 149

Siehe W3C_XSL(2000)


Summenbildung in einem Geschäftsdokument oder sogar Dokumente vollständig trans-

formieren. Für Transformationen entstand XSL Transformations (XSLT) 150 als Teil

von XSL. Mit Hilfe von XSLT ist es möglich, eine Menge von Elementen oder ganze

Dokumente von XML in HTML oder in alle anderen Formate (z.B. RTF, DOC, PDF,

etc) umzuwandeln. Insbesondere lassen sich XML-Dokumente mit XSLT in HTML-

Code umwandeln und damit in einem Browser (ohne weitere Style Sheets) anzeigen.

8.2.7 Elektronische Signaturen mit XML

XML-Dokumente sind Textdateien und lassen sich somit durch entsprechende Signatur-

software problemlos elektronisch signieren.

XML selbst bietet aber ebenfalls die Möglichkeit elektronische Signaturen für beliebige

Datentypen (insbesondere für XML-Dokumente) zu erzeugen. Das W3C legte am 3.

Februar 2002 eine entsprechende Empfehlung für XML-Signaturen vor.151

Das Besondere an den XML-Signaturen ist, dass es sich dabei selbst um XML-Code

handelt. XML stellt somit einen Ansatz sowohl für den elektronischen Datenaustausch

als auch für elektronische Signaturen dar. Das bietet den Vorteil, dass bereits bestehen-

de XML-Tools auch für die Implementierung von Signaturen verwendet werden kön-

nen. Weiterhin können XML-Signaturen nicht nur über vollständige XML-Dokumente

definiert werden, sondern auch über einzelne Abschnitte oder sogar einzelne Elemente.

Beispielsweise könnten bei einem Dokument, geschrieben von mehreren Autoren, die

einzelnen Teile von den jeweils dafür verantwortlichen Autoren signiert werden.152

Grundsätzlich werden drei Arten der Signatur (verdeutlicht in Abbildung 8.12) unter-

schieden:153

• Ummantelt: Das Dokument ummantelt die Signatur, d.h. die Signatur ist im

Dokument eingebettet (z.B. zur Signatur einzelner Dokumentteile).

• Ummantelnd: Die Signatur ummantelt das Dokument.

• Getrennt: Dokument und Signatur existieren getrennt voneinander, entweder

separat (extern) oder zusammengefasst in einem neuen Dokument (intern). In-

150

Siehe W3C_XSLT(1999) 151

Siehe W3C_Signatur(2002) 152

Vgl. DOCTRONIC (2001) 153

Vgl. HEARN (2002), S. 22-25


nerhalb der Signatur wird aber auf das/die zu signierende/n Dokument/ Do-

kumentteile verwiesen.

Dokument

Signatur Signatur

Ummantelt Ummantelnd

Signatur

Dokument

Dokument Dokument

Signatur

Dokument

Extern

Getrennt

Intern

Abbildung 8.12: Drei Arten von XML-Signaturen

Nachfolgend ein Beispiel für eine elektronische Signatur in XML.

<Signature> <SignedInfo>

<CanonicalizationMethod Algorithm=‘‘REC-xml-c14n-20010315’’ /> <SignatureMethod Algorithm=‘‘rsa-sha1’’ /> <Reference URI=‘‘http://www.beispiel.de/rechnung.xml’’ >

<DigestMethod Algoritm=‘‘sha1’’ /> <DigestValue>j7H6hd8kh7I9jcz7hgtjIM6K0Pgb</DigestValue>

</Reference> </SignedInfo> <SignatureValue>78bla83ALBlA5=3jghblA9hBLaa8</SignatureValue> <KeyInfo>

<KeyValue>77564992370893420571690641</KeyValue> </KeyInfo>

</Signature>

Abbildung 8.13: XML-Signatur Beispiel154

Der für die Signatur verwendete Algorithmus (hier: "rsa-sha1") wird dem Attribut "Al-

gorithm" des Elements <SignatureMethod> zugewiesen. Die der Signatur zugrunde lie-

gende Datei (hier: XML-Dokument "rechnung.xml") wird durch das Attribut "URI" des

Elements <Reference> referenziert. Die Elemente <DigestMethod> und <DigestValue>

beschreiben den Hash-Algortihmus (hier: "sha1") und den damit berechneten Hashwert

der Datei. Das Element <SignatureValue> beinhaltet den aus dem Hashwert berechne-

ten Wert der Signatur. Der zur Verifikation der Signatur notwendige öffentliche Schlüs-

sel des Ausstellers wird durch das Element <KeyInfo> übertragen.

154

Vgl. HEARN (2002), S. 26

8.3 EDI mit XML (XML/EDI) 96

Neben der Entwicklung der hier vorgestellten XML-Signaturen legte das W3C ebenfalls

Empfehlungen für eine Verschlüsselung mit (XML-Encryption)155 sowie für ein XML-

basiertes Schlüsselverwaltungssystem (XML-Key-Management)156 vor. XML unter-

stützt demnach alle für einen vertrauenswürdigen und sicheren elektronischen Daten-

austausch notwendigen Technologien. Gelingt es, die Möglichkeiten der XML-

Signaturen mit dem Einsatz von qualifizierten Zertifikaten und SmartCards in Verbin-

dung zu bringen, steht dem Erstellen von SigG-konformen qualifizierten elektronischen

Signaturen mit XML nichts mehr im Wege.

8.3 EDI mit XML (XML/EDI)

8.3.1 Vorteile von XML

Der XML-basierte elektronische Datenaustausch über das Internet wird als XML/EDI

bezeichnet. Dass XML als Format für den elektronischen Datenaustausch über das In-

ternet besonders geeignet ist, lässt sich in den folgenden Punkten zusammenfassen:

• XML und alle vom W3C bereitgestellten, dazugehörigen Modelle (XLink,

XPointer, XSL, XSLT, DOM, XPath, etc.)157 sind offene und frei zugängliche

Standards, deren Beschreibung sich stark an HTML anlehnt. Da HTML schon

weltweit Millionen Internet-Usern bekannt ist, stellt die Einarbeitung in XML

in der Regel kein Problem mehr dar. Dies zeigt sich insbesondere daran, dass

schon zwei Jahre nach der Standardisierung durch das W3C eine Fülle zum

Teil frei verfügbarer XML-Tools wie Parser, Editoren etc. von allen großen

Softwareanbietern angeboten wurde.

• XML unterstützt internationale Zeichensätze (Unicode) und ist damit weltweit

einsetzbar.

• XML-Dokumente sind Textdateien. Sie sind somit plattformunabhängig und

können mit jedem Text-Editor erstellt, gelesen und manipuliert werden.

• XML unterstützt elektronische Signaturen und Verschlüsselung (siehe 8.2.7)

und wird somit den Sicherheitsanforderungen an einen elektronischen Daten-

austausch gerecht.

155

Siehe W3C_ENCRYPTION(2001) 156

Siehe W3C_XKMS(2001) 157

Für eine nähere Beschreibung dieser Modelle siehe z.B. BUXMANN ET AL (2001), S. 25ff


• XML ist leicht lesbar. Während Datenformate des traditionellen EDI rein für

die Maschine-zu-Maschine Kommunikation konzipiert sind, können XML-

Dokumente bei entsprechend sinnvoller Strukturierung und Auszeichnung der

Tags auch für Menschen ohne Weiteres interpretierbar sein.

• XML ist sehr flexibel. Die Struktur, die zum Verständnis und zur Verarbei-

tung der auszutauschenden Daten notwendig ist, muss nicht als fester Bestand-

teil in der verarbeitenden Applikation integriert sein, sondern kann Teil des

Dokumentes sein (als DTD/Schema). Daraus ergibt sich die Möglichkeit, neue

Standards schnell zu entwickeln oder bestehende Dokumenten-Standards zu

verändern, ohne dass dies einen langwierigen Standardisierungsprozess nach

sich zieht.

• XML kann beliebig komplexe Datenstrukturen erzeugen und wiedergeben.

• In XML-Dokumenten kann auf einzelne Elemente oder Elementgruppen di-

rekt zugegriffen werden. Dazu dienen frei zugängliche Zugriffsmodelle.

• XML-Dokumente können sowohl durch Anwendungen (Parser) automatisch

weiterverarbeitet werden als auch durch einen Web-Browser strukturiert dar-

gestellt werden (durch Anwendung von Style Sheets, XSL). Dabei ist es auf-

grund der Trennung von Inhalt und Layout möglich, verschiedene Sichtweisen

(z.B. Normalansicht / Detailansicht) auf ein Dokument bereitzustellen, ohne

den Inhalt verändern zu müssen.

• XML-Dokumente sind ohne großen Aufwand in alle gängigen Formate trans-

formierbar (durch Anwendung von XSLT). Kostenintensive Konvertersoft-

ware ist also nicht notwendig.

• XML-Dokumente können jeden beliebigen Datentyp beinhalten. Dies reicht

von "klassischen" Daten wie Text und Zahlen über Multimediadaten wie Bil-

der, Sounds und Videos bis hin zu aktiven Komponenten wie Java-Applets

oder ActiveX-Komponenten.

• XML ist von der IT-Branche als Datenaustauschformat der Zukunft akzeptiert

worden. Mittlerweile wird XML von allen führenden Software-Anbieter wie

Software AG, IBM, Sun, Microsoft, Netscape, SAP, etc. unterstützt bzw. ist

eine Unterstützung angestrebt. Beispielsweise bietet Microsofts Office 2003


Paket eine umfassende XML-Unterstützung.158 Des Weiteren sind alle moder-

nen Web-Browser in der Lage XML-Dokumente darzustellen.

Ein oft aufgeführter Nachteil von XML ist, dass XML-Übertragungsdateien ein größe-

res Datenvolumen haben als traditionelle EDI-Nachrichten. Praktisch gesehen stellt dies

aber keinen Nachteil dar, da sich aufgrund des stetigen technischen Fortschritts die Ü-

bertragungsgeschwindigkeiten im Internet verringern und Rechnerleistungen steigen.

Außerdem sind XML-Dokumente leicht und effektiv komprimierbar (z.B. durch Einsatz

der kostenlosen Komprimier-Software XMLZip).

8.3.2 XML/EDI-Standardisierung

8.3.2.1 Notwendigkeit zur Standardisierung

Der Prozessablauf einer XML/EDI-Kommunikation zwischen Geschäftspartnern gestal-

tet sich grundsätzlich folgendermaßen:

Datenübertragungper Internet

Geschäfts-daten XML-

Datei

Inhouse-Anwendungdes Absenders

Geschäfts-daten

Inhouse-Anwendungdes Empfängers

= Evtl. unterschiedliche Inhouse-Formate

Erstellt KonvertiertXML-Datei

Abbildung 8.14: Ablauf XML/EDI-Kommunikation

Auf Seiten des Absenders werden die auszutauschenden Daten zusammengestellt und

daraus ein dem Nachrichtentyp (Rechnung, Bestellung, Auftragsbestätigung, etc.) ent-

sprechendes XML-Dokument erstellt. Dieses wird (eventuell verschlüsselt und elektro-

nisch signiert) dem Empfänger per Internet zugesandt oder bereitgestellt. Der Empfän-

ger greift nun auf die in XML vorliegenden Dokument-Daten zu und liest/konvertiert

diese mit Hilfe eines Parsers zur Weiterverarbeitung in seinen Inhouse-Anwendungen.

In dem dargestellten Ablauf stellt XML lediglich eine standardisierte Syntax für die

auszutauschenden Geschäftsdokumente bereit. Aussagen über die Bedeutung des Inhalts

(Semantik) werden nicht gemacht. Grundvoraussetzung für einen funktionierenden 158

Für nähere Informationen siehe: http://www.microsoft.com/germany/ms/office2003/OfficeundXML/xmlsystem.htm


elektronischen Datenaustauschs ist aber ein Nachrichtenformat, welches von den betei-

ligten Geschäftspartnern auch inhaltlich verstanden wird. Da Struktur und Auszeich-

nung der Tags eines XML-Dokuments dem Autor überlassen sind, können die Inhalte

von dem Empfänger nur richtig interpretiert werden, wenn sich die Kommunikations-

partner im Voraus auf Bezeichnung, Struktur und Bedeutung der einzelnen Elemente

geeinigt haben, beispielsweise durch den Austausch von kommentierten DTDs oder

Schemata.

Unter diesem Gesichtspunkt stellt sich die Flexibilität als eine der großen Stärken von

XML/EDI auch als die größte Schwäche heraus. Denn jedes Unternehmen kann Tags

und Dokumentstrukturen nach spezifischen Anforderungen mit dem jeweiligen Ge-

schäftspartner vereinbaren. Diese Form der Vereinbarungen führt aber bei einer Viel-

zahl von Geschäftspartnern zu einem erheblichen Mehraufwand und eventuellen In-

kompatibilitäten und ist somit nicht praktikabel.159

Um das volle Nutzenpotential von XML/EDI ausschöpfen zu können, müssen sich

demnach, über einzelne Unternehmen hinaus, einheitliche Definitionen der Tags und

ihrer semantischen Bedeutung entwickeln, z.B. in Form von standardisierten XML-

Schemata. Die Bildung von globalen, herstellerunabhängigen Standards für den ge-

schäftlichen Datenaustausch mit XML ist entscheidend für den Erfolg und eine weite

Verbreitung von XML/EDI-Anwendungen.160

8.3.2.2 Standardisierungsinitiativen161

Analog zu den Standardisierungsinitiativen beim klassischen EDI, basieren auch die

bestehenden XML/EDI-Standards auf Initiativen sowohl staatlicher Einrichtungen (z.B.

der UN) als auch einzelner Firmen oder Firmenkonsortien.

Einer Studie zufolge existierten bereits im August 2000 über 250 unterschiedliche

XML-Geschäftssprachen.162 Hierbei handelt es sich in der Regel um industrie- und un-

ternehmensspezifische Sprachen bzw. um XML-Sprachen für stark spezialisierte An-

wendungen wie beispielsweise den Austausch physikalischer oder genetischer Daten.163

Die nachfolgend vorgestellten Initiativen haben (zusammen mit einigen anderen) den

Anspruch einem universell einsetzbaren Standard für den Geschäftsdatenaustausch mit

159

Vgl. STEFFEN (2000), S. 3 160

Vgl. STEFFEN (2000), S. 4 161

Vgl. BUXMANN ET AL (2001), S. 79-155 162




XML gerecht zu werden. Ob und welche Lösungen sich in der Praxis gegenüber ande-

ren durchsetzen können, hängt vor allem davon ab, welche Unternehmen sie mit wel-

chem Einsatz unterstützen.

Eine bedeutende Firmeninitiative von Microsoft ist BizTalk . BizTalk stellt keinen

XML/EDI-Standard dar, sondern beschreibt ein komplettes Rahmenwerk zum Aus-

tausch von beliebigen Geschäftsdokumenten auf XML-Basis. Das Rahmenwerk besteht

aus einem XML-Framework , in dem Formatvorschriften und Elemente, die ein Biz-

Talk-Dokument enthalten kann/muss, definiert werden. Außerdem aus einem offenen

Portal (oder Repository), in dem (dem XML-Framework entsprechende) XML-

Schemata von Unternehmen oder Privatpersonen frei eingestellt und abgerufen werden

können. Die dritte Komponente ist der BizTalk Server, der ein- und ausgehende Biz-

Talk-Dokumente verarbeitet und den Austausch leitet. Während das XML-Framework

und das Portal über das Internet kostenfrei genutzt werden können, muss die Software

zum Einrichten eines BizTalk-Servers lizenziert werden.

Eine mit der Entwicklung des EDIFACT-Standards vergleichbare XML/EDI-Initiative

der Vereinten Nationen (Abteilung UN/CEFACT) zusammen mit OASIS (ein internati-

onales Nonprofit-Konsortium, bestehend aus Soft- und Hardware-Herstellern, z.B. Sun,

IBM, u.a.) ist Electronic Business XML (ebXML). Ziel von ebXML ist das Bereitstel-

len eines offenen XML-Frameworks, in dem technische Spezifikationen definiert sind,

die einen einheitlichen, weltweiten, konsistenten Austausch elektronischer Geschäftsda-

ten auf der Grundlage von XML ermöglichen. Insbesondere soll ebXML dazu dienen,

die Eintrittsbarrieren zum E-Business für kleine und mittelständische Unternehmen so-

wie Entwicklungsländer zu senken.

Mitte 2001 ist nach ca. 18 Monatiger Entwicklungszeit ein ebXML-Standard verab-

schiedet worden. Analog zu XML handelt es sich dabei um einen offenen Standard, der

im Internet unter http://www.ebxml.org abrufbar ist. Auf lange Sicht wird angestrebt

ebXML bei anerkannten Standardisierungsgremien als internationalen Standard einzu-

reichen.

Eine deutsche Initiative ist der 1999 verabschiedete DIN-Entwurf 16557-4 des Deut-

schen Institut für Normung (DIN) und der Deutschen EDI/EC Gesellschaft (DEDIG).

Der Entwurf mit dem Namen "EDIFACT - Teil 4: Regeln für die Auszeichnung von

8.4 Fazit 101

UN/EDIFACT-Übertragungsstrukturen mit der Extensible Markup Language (XML)

unter Einsatz von Document Type Definitions (DTDs)"164 beschreibt kein komplettes

Transaktionsframework wie beispielsweise Microsofts BizTalk oder ebXML, sondern

beinhaltet ein Regelwerk wie UN/EDIFACT-Übertragungsstrukturen in XML DTDs

überführt werden können. Der Zweck der Norm ist es, die über Jahre erarbeitete und

bewährte Semantik von UN/EDIFACT in XML nutzbar zu machen. Dies geschieht

durch eine 1:1 Abbildung der EDIFACT-Norm in das XML-Format. Die, anhand der in

der Norm beschriebenen Regeln, erzeugten DTDs dienen als Grundlage für die spezifi-

schen Geschäftsdokumente in XML.

Allerdings ist die Norm nicht unumstritten. Einerseits richtet sich die semantische Inter-

pretation derartig erzeugter XML-Dokumente nach den schon vorliegenden

UN/EDIFACT-Richtlinien und bedarf deshalb keiner langwierigen Entwicklungs- und

Standardisierungsprozessen, aber andererseits geht dadurch der Vorteil von XML als

flexibles, leicht menschenlesbares Format verloren.165

Für eine ausführliche Beschreibung der hier vorgestellten und weiteren interessanten

XML/EDI-Standardisierungsinitiativen siehe BUXMANN ET AL (2001), S. 79-155.

8.4 Fazit

Abschließend kann festgestellt werden, dass "EDI über das Internet" zahlreiche Vorteile

gegenüber traditionellen EDI-Anwendungen besitzt und somit zu einer Verbreitung des

elektronischen Datenaustauschs beitragen kann.

Die Nutzung des Internet als Transportmedium ermöglicht eine schnelle, kostengünstige

und nahezu globale Datenübertragung, an der jedes Unternehmen bzw. jeder Privat-

haushalt mit minimalem Setup-Aufwand teilnehmen kann. Die Sicherheit der Übertra-

gung sowie die Authentizität der Daten kann durch Anwendung moderner Verschlüsse-

lungs- und Signaturverfahren sichergestellt werden. Die Extensible Markup Language

stellt ein für einen Datenaustausch über das Internet geeignetes Datenformat dar. XML

bietet (in Verbindung mit den dazugehörigen weiteren Standards) als offener und flexib-

ler Standard vielfältige Möglichkeiten einer Integration und Weiterverarbeitung in be-

stehenden EDV-Systemen. Aufgrund der Einfachheit sowie der zahlreich vorhandenen

164

DIN(2000) 165


8.4 Fazit 102

XML-Tools können leistungsfähige XML-basierte EDI-Lösungen leicht, kostengünstig

und schnell implementiert werden.

XML/EDI-Lösungen senken demnach die bei der Teilnahme an einem traditionellen

EDI-Netz bestehenden Einstiegshürden und öffnen somit EDI-Netze für eine Vielzahl

neuer Teilnehmer. Der elektronische Datenaustausch und seine Vorteile gegenüber dem

papierbasierten Datenaustausch bleibt durch XML/EDI nicht mehr nur großen Unter-

nehmen vorbehalten, sondern wird nun auch für kleine und mittelständische Unterneh-

men ohne großes finanzielles Investitionsrisiko möglich.

9.1 Einleitung 103

9 Electronic Billing mit elektronischen Signaturen

9.1 Einleitung

Unter dem Begriff Electronic Business (kurz eBusiness) wird ganz allgemein jede ge-

schäftliche Transaktion, deren Teilnehmer elektronisch interagieren, verstanden.166 In

der Regel zielen eBusiness-Strategien darauf ab, die Transaktionskosten durch den Ein-

satz moderner Technologien (z.B. Internet) zu reduzieren und gleichzeitig die Kunden-

bindung durch unternehmensübergreifende, integrierte Geschäftsprozesse zu erhöhen.

Unter diesen Gesichtspunkten entwickelte sich auch das Verfahren der elektronischen

Rechnungsstellung über das Internet, Electronic Billing (kurz eBilling)167 genannt.168

Eine Umstellung der Rechnungsstellung von der traditionellen Papierform hin zu dem

Einsatz von eBilling-Verfahren ermöglicht eine Optimierung der folgenden Wettbe-

werbsfaktoren:169

• Geschäftsprozessoptimierung: Auf Seiten des Rechnungsstellers lassen sich

durch einen elektronischen Versand der Rechnung Druck-, Papier- und Porto-

kosten einsparen. Auf Seiten des Rechnungsempfängers kann durch eine au-

tomatisierte Datenerfassung die Bearbeitungszeit gesenkt und somit Kosten

eingespart werden. Rechnungen in elektronischer Form ermöglichen des Wei-

teren eine einfache elektronische Archivierung ohne den zusätzlichen Einsatz

von zeit- und kostenintensiven Scan-Verfahren.

• Kundenbindung: Elektronische Rechnungen können in Bezug auf das Daten-

format, Layout und zusätzliche Darstellungs- und Auswertungsmöglichkeiten

an Kundenwünsche angepasst werden. Dem Kunden kann somit ein kosten-

freier Mehrwert geliefert werden, der zu einer verstärkten Kundenbindung

führt.

• Marketing : Die elektronische Rechnungsstellung kann zu einem effektiven

Marketing genutzt werden. Elektronische Beilagen sind kostengünstiger als

entsprechende Beilagen auf Papier und bieten den Vorteil, dass der Empfänger

selbst entscheiden kann, ob er die Werbung öffnet, ignoriert oder direkt löscht.

166

Vgl. BUXMANN ET AL . (2001), S. 1 167

Alternativ dazu wird oft auch der Begriff "Electronic Bill Presentment and Payment" (EBPP) verwendet. Allerdings beinhaltet EBPP neben der elektronischen Rechnungsstellung auch die elektronische Zahlungsabwicklung.

168 Vgl. SCHILLER, VOLLMER (2002), S. 9

169 Vgl. SCHILLER, VOLLMER (2002), S. 9-12

9.2 eBilling-Modelle 104

Die aufgeführten Optimierungspotentiale von eBilling-Verfahren lassen sich sowohl im

zwischenbetrieblichen Rechnungsaustausch (B2B-Bereich) als auch bei einer Rech-

nungsstellung an Privatkunden realisieren. Bei dem Einsatz im B2B-Bereich ist aller-

dings zu beachten, dass die elektronischen Rechnungen mit einer den Anforderungen

des § 14 UStG entsprechenden elektronischen Signatur versehen sein müssen, um auf

Seiten des Empfängers einen Vorsteuerabzug gegenüber dem Finanzamt geltend ma-

chen zu können. Dazu muss das Signaturverfahren in den Ablauf der elektronischen

Rechnungsstellung eingebunden werden. (siehe Kapitel 9.4).

Abbildung 9.1 stellt den Ablauf der papierbasierten Rechnungsstellung dem prinzipiel-

len Ablauf von eBilling-Verfahren unter Einsatz einer elektronischen Signatur gegen-

über.

AusdruckVersand und Porto

Manuelle Erfassung

EDV

Papierba-sierte

Archivie-rung oder Microfiche

Elektron. Archivier-

ung

DigitaleSignatur

Elektron. Versand

(z.B. E-Mail)

Eingabe, Verar-beitungEDV

Traditioneller Rechnungsversand

auf Papier

Vorteile von E-Billing:

• Reduktion der Prozesskosten

• Vermeidung von Medienbrüchen

• Beschleunigte Rechnungsabwicklung

• Gleiche Rechtsgültigkeit

Auto-matischeErfassung

EDV

Rechnungs-daten

= Medienbruch

E-Billing Verfahren mit digitaler

Signatur

Rechnungssteller: Rechnungsempfänger:

Abbildung 9.1: Vergleich Rechnungsstellung auf Papier bzw. per eBilling170

9.2 eBilling-Modelle

9.2.1 Direktes eBilling171

Grundsätzlich kann bei eBilling-Verfahren zwischen einem direkten und einem indirek-

ten Modell unterschieden werden.

170

Vgl. "Innovative Sicherheitslösungen", abrufbar unter www.trustcenter.de, abgerufen am 05.06.03 171

Vgl. GOERS (2003) EBPP-Modelle


Ein direktes eBilling zeichnet sich dadurch aus, dass die Rechnungen direkt auf elekt-

ronischem Wege von dem Rechnungssteller an die jeweiligen Kun-

den/Rechnungsempfänger übertragen werden. Diese Vorgehensweise entspricht der

Punkt-zu-Punkt-Übertragung bei dem traditionellen EDI-Geschäftsverkehr (siehe Kapi-

tel 7.4).

Rechnungs-steller

Rechnungs-empfänger

Rechnung

Abbildung 9.2: Direktes eBilling172

Ein Vorteil des direkten eBilling ist der unmittelbare Kundenkontakt, d.h. die Rech-

nungsstellung lässt sich an gezielt Kundenwünsche anpassen und zu einem auf den je-

weiligen Geschäftspartner abgestimmten Marketing nutzen. Des Weiteren ist von Vor-

teil, dass die sensiblen Kunden- und Rechnungsdaten stets in den Händen des rech-

nungsstellenden Unternehmens bleiben. Nachteilig wirkt sich dagegen aus, dass das für

die Rechnungserstellung und -übermittlung eingesetzte eBilling-System im Unterneh-

men selbst implementiert und betrieben werden muss. Dadurch werden Kosten verur-

sacht und personelle Ressourcen gebunden.

9.2.2 Indirektes eBilling173

Bei einem indirekten eBilling ist zwischen Rechnungssteller und Kunden eine dritte

Instanz, der sogenannte Konsolidator (oder engl. Bill Consolidator), eingeschaltet. Der

Rechnungssteller übermittelt seine elektronischen Rechnungsrohdaten (z.B. in XML,

Excel, etc.) an einen Konsolidator, der diese dann im Auftrag des Rechnungsstellers

speichert, aufbereitet und an die jeweiligen Rechnungsempfänger übermittelt. Indirekte

eBilling-Verfahren werden auch als Bill Consolidation-Verfahren bezeichnet. Diese Art

172

Vgl. GOERS (2003), EBPP-Modelle 173

ebenda


der Übertragung ist vergleichbar mit der Nutzung eines VANS bei EDI (siehe Kapitel

7.4).


Rechnung

Rechnungs-steller

KonsolidatorRechnungs-

rohdaten

Rechnungs-rohdaten

Abbildung 9.3: Indirektes eBilling174

Bei diesem Modell kann auch von einem Outsourcing der Rechnungsstellung gespro-

chen werden, da die Aufbereitung und Übermittlung der Rechnungsdaten nicht im rech-

nungsstellenden Unternehmen selbst, sondern durch ein beauftragtes externes Dienst-

leistungsunternehmen durchgeführt wird.

Der Vorteil des indirekten eBilling liegt in dem geringen Aufwand, den ein rechnungs-

stellendes Unternehmen zur Übermittlung elektronischer Rechnungen leisten muss. Das

Unternehmen muss lediglich die den Rechnungen zugrundeliegenden Kunden- und

Rechnungsdaten an einen Konsolidator übermitteln und die für die Nutzung seines

Dienstes anfallenden Gebühren aufbringen. Um einen ausreichenden Datenschutz zu

gewährleisten, müssen gesicherte Verbindungen genutzt und eine entsprechende Ver-

traulichkeit von Seiten des konsolidierenden Unternehmens vertraglich geregelt werden.

Problematisch gestaltet sich der Einsatz elektronischer Signaturen in indirekten eBil-

ling-Verfahren: Um eine den Anforderungen des Umsatzsteuergesetzes entsprechende

qualifizierte elektronische Signatur mit Anbieterakkreditierung ausstellen zu können,

bedarf es einem qualifizierten Zertifikat einer akkreditierten Zertifizierungsstelle. Da

aber nach §2 Satz 7 SigG01 qualifizierte Zertifikate nur natürlichen Personen zugeord-

net werden können, ist es einem konsolidierenden Unternehmen nicht möglich, derarti-

ge elektronische Signaturen im Auftrag des rechnungsstellenden Unternehmens auszu-

stellen.

174

Vgl. GOERS (2003), EBPP-Modelle

9.3 Angewandte eBilling-Lösungen 107

Indirektes eBilling eignet sich demnach vor allem für eine Rechnungsstellung im Pri-

vatkundenbereich, da Privatpersonen nach dem Umsatzsteuergesetz grundsätzlich nicht

zum Vorsteuerabzug berechtigt sind und somit bei der Rechnungsstellung keine elekt-

ronischen Signaturen benötigt werden. Für einen Einsatz im B2B-Bereich sind zusätzli-

che Sammelrechnungen notwendig.

9.3 Angewandte eBilling-Lösungen

9.3.1 Web-Billing

Eine auf dem Konzept des WebEDI (siehe Kapitel 8.1) aufbauende eBilling-Lösung

stellt das Web-Billing dar. Unter Web-Billing wird die Übertragung der Rechnung über

das World Wide Web verstanden. Das bedeutet, dass die Rechnungsdaten dem entspre-

chenden Rechnungsempfänger über eine Web-Seite im Internet präsentiert und zum

Download bereitgestellt werden. Der Betreiber eines Web-Billing-Systems kann dabei

der Rechnungssteller selbst oder ein beauftragter Konsolidator sein. Durch Web-Billing

lassen sich also sowohl eine direkte als auch ein indirekte elektronische Rechnungsstel-

lung realisieren.

Der Ablauf einer elektronischen Rechnungsstellung mit Hilfe eines Web-Billing-

Systems gestaltet sich folgendermaßen: Der Rechnungssteller überträgt seine Rech-

nungs-Rohdaten an ein Web-Billing-System. Dort werden die Rechnungsdaten aufgear-

beitet und zum Abruf bereitgestellt. Ein Rechnungsempfänger greift mit Hilfe eines

Web-Browsers auf die Web-Seiten des Rechnungsausstellers bzw. Konsolidators zu und

bekommt dort nach einer erfolgreichen Authentifizierung (z.B. durch Benutzername

und Passwort) die für ihn vorliegenden Rechnungen präsentiert. Neben der Präsentation

der Rechnungsdaten im Browser stehen diese auch in einem zur Weiterverarbeitung

durch den Rechnungsempfänger geeigneten Format zum Download über eine gesicherte

Verbindung bereit. Hier eignet sich insbesondere XML (siehe Kapitel 8.3.1) als Daten-

format, da XML beide Funktionalitäten (Präsentation und Weiterverarbeitung) vereint.

Die Einbindung der elektronischen Signatur erfolgt derart, dass die zur Weiterverarbei-

tung abrufbaren Rechnungsdaten elektronisch signiert werden bzw. eine zusätzliche,

elektronisch signierte Rechnungsdatei durch den Rechnungssteller bereitgestellt wird.175

175



IT-SystemRechnungs-steller

Datenauf-bereitung Web-Portal

AufbereiteteRechnungsdaten

Web-Billing-System

Ansicht, Download


Authentifizieren

Rechnungs-Rohdaten

Abbildung 9.4: Elektronische Rechnungsstellung mit Web-Billing

Der Vorteil von Web-Billing-Lösungen liegt in der Interaktivität des Internets: Dem

Rechnungsempfänger kann die Möglichkeit gegeben werden, die Art der Rechnungs-

darstellung nach seinen Wünschen zu gestalten. Beispielsweise kann er Sprache,

Schriftart, Farben etc. der Rechnung auswählen. Des Weiteren können verschiedene

Sichtweisen (z.B. Gesamtübersicht, Detailansicht), umfassende Auswertungsmöglich-

keiten und Statusinformationen (bezahlt, unbezahlt) auf der Web-Seite bereitgestellt

werden.

Ein schwerwiegender Nachteil des Web-Billing (aus Sicht des Rechnungsempfängers)

besteht aber darin, dass ein Rechnungsempfänger nicht ohne Weiteres über den Eingang

einer Rechnung informiert wird (mögliche Lösung: zusätzliche E-Mail, siehe Kapitel

9.3.3). Der Rechnungsempfänger muss selbst aktiv werden und die Web-Billing-Seiten

von potentiellen Rechnungsstellern in regelmäßigen Abständen abfragen. Bei einer

Vielzahl von Geschäftspartnern, die ein Web-Billing-System betreiben, bedeutet dies

einen nicht unerheblichen Aufwand.176

Von Seiten des Betreibers eines Web-Billing-Systems erfordern Implementierung und

Betrieb einen hohen technischen und finanziellen Aufwand sowie entsprechendes

Fachwissen. Ein direktes Web-Billing setzt demnach eine genügend große IT-Abteilung

und ein hohes Rechnungsvolumen voraus, um ein schnelles Return-on-Investment

(ROI) gewährleisten zu können. Es bleibt dadurch eher großen Unternehmen mit einem

Rechnungsaufkommen von mehr als 100.000 Rechnungen pro Monat oder großen Un-

ternehmen im reinen B2B-Bereich vorbehalten.177 Kleineren Unternehmen, die eine e-

lektronischen Rechnungsstellung per Web-Billing anstreben, wird der weitaus günstige-

re Dienst eines darauf spezialisierten Konsolidators empfohlen.178

176

Vgl. EICKER, SCHWICHTENBERG (1999), S. 153-154 177

Vgl. GOERS (2003), EBPP-Modelle 178

Vgl. GOERS (2003), EBPP-Modelle


9.3.2 E-Mail-Billing

E-Mail-Billing zeichnet sich dadurch aus, dass die zu transferierenden Rechnungsdaten

im Anhang einer E-Mail über das SMTP-Protokoll per Internet an den Empfänger über-

tragen werden. Es handelt sich also dabei um eine konkrete Anwendung des in Kapitel

8.1 vorgestellten Internet-EDI per E-Mail.

Eine elektronische Rechnungsstellung per E-Mail-Billing verläuft wie nachfolgend be-

schrieben: Der Rechnungssteller stellt die aus seinem System stammenden Rechnungs-

daten in einem zur Weiterverarbeitung durch den Rechnungsempfänger geeigneten

Format und (falls notwendig) zusätzlich in einem elektronisch signierten Format bereit

(bzw. in einem Format welches beide Anforderungen gleichermaßen erfüllt, wie z.B.

XML). Diese Daten werden nun als Anhang einer E-Mail über das Internet an den je-

weiligen Empfänger geschickt. Der Text der Mail kann die wesentlichen Rechnungsda-

ten wie z.B. Absender, Rechnungsgrund, Betrag und Fälligkeit enthalten und weist so

den Empfänger auf die im Anhang befindlichen Rechnungsdaten hin. Die Datenübertra-

gung erfolgt über einen oder in der Regel mehrere Mail-Server und kann/sollte zur Si-

cherheit verschlüsselt werden. Die E-Mail steht nach der Übertragung in einem zentra-

len Postfach des Rechnungsempfängers zum Abruf bereit. Von dort werden die Rech-

nungsdaten dann zur Weiterverarbeitung in das hauseigene EDV-System importiert.179

IT-SystemRechnungs-steller

E-Mail mitRechnungsdaten


Mail-Server

Zentrales Mail-Postfach

Abbildung 9.5: Elektronische Rechnungsstellung mit E-Mail-Billing

Gegenüber Web-Billing-Lösungen sind die Darstellungs- und Auswertungsmöglichkei-

ten der Rechnungsdaten bei E-Mail-Billing eingeschränkt. Detaillierte Rechnungs- und

Auswertungsdaten müssen von Seiten des Rechnungsstellers explizit mitverschickt

werden und setzen eine zur Präsentation geeignete Software auf Seiten des Rechnungs-

empfängers voraus. Entscheidender Vorteil des E-Mail-Billing ist, dass der Rechnungs-

179



empfänger direkt auf den Eingang einer Rechnung in seinem Mail-Postfach aufmerk-

sam wird.180

E-Mail-Billing eignet sich vor allem für eine direkte Rechnungsübermittlung, da der zur

Implementierung und zum Betrieb benötigte technische und zeitliche Aufwand ver-

gleichsweise gering ist und somit im Unternehmen selbst geleistet werden kann. Auf-

grund der geringen Anforderungen kann diese Form des eBilling also auch in kleineren

Unternehmen mit einem niedrigen Rechnungsvolumen realisiert werden.

9.3.3 Kombination von Web- und E-Mail-Billing 181

Sowohl Web-Billing als auch E-Mail-Billing weisen Vor- und Nachteile auf. Eine

Kombination der beiden Verfahren kann die jeweiligen Vorteile nutzen und ihre

Nachteile vermeiden. Im Folgenden werden drei unterschiedliche Szenarien für eine

Integration kurz vorgestellt.

E-Mail-Billing mit Details im Web: Der Rechnungssteller überträgt die zur Weiter-

verarbeitung auf Seiten des Rechnungsempfängers notwendigen Rechnungsdaten per E-

Mail und stellt zusätzlich Detailinformationen und Auswertungsmöglichkeiten auf ei-

nem Web-Server bereit. Auf diese kann der Rechnungsempfänger über einen in der E-

Mail enthaltenen Hyperlink zugreifen.

Web-Billing mit E-Mail als Hinweis: Der Rechnungssteller betreibt ein Web-Billing-

System. Sobald eine Rechnung für einen Rechnungsempfänger bereit gestellt wird, be-

kommt dieser eine E-Mail mit einem entsprechenden Hinweis. Über einen Hyperlink

kann die Rechnung aus der E-Mail heraus abgerufen werden. Alternativ oder ergänzend

zur E-Mail kann die Benachrichtigung auch über andere Medien wie z.B. Pager, Telefax

oder Handy erfolgen.

Web-Billing mit E-Mail als Erinnerung: Die Rechnungsdaten werden mit einem

Web-Billing-System bereitgestellt. Der Rechnungsempfänger bekommt nur dann eine

E-Mail zugesandt, wenn die Rechnung überfällig ist. Auch hier können die oben ge-

nannten alternativen Benachrichtigungsarten genutzt werden.

180

Vgl. EICKER, SCHWICHTENBERG (1999), S. 154-156 181


9.4 Integration des Signatur-Verfahrens 111

9.4 Integration des Signatur-Verfahrens

9.4.1 Einleitung

Um steuerrechtlich anerkannte elektronische Rechnungen übermitteln zu können, muss

neben dem Einsatz einer eBilling-Lösung auch ein Signatur-Verfahren zum Ausstellen

der durch das Umsatzsteuergesetz geforderten qualifizierten elektronischen Signaturen

mit Anbieterakkreditierung (siehe Kapitel 5.1.5) in die unternehmensinternen IT-

Systeme des Rechnungsstellers integriert werden. Dabei kann zwischen einer dezentra-

len und einer zentralen Signatur-Lösung unterschieden werden.182

9.4.2 Dezentrale Signatur-Lösung

Die dezentrale Signatur-Lösung sieht vor, dass elektronische Signaturen an mehreren

Stellen des IT-Netzwerks eines Unternehmen ausgestellt werden können. Dazu werden

an den jeweils dafür vorgesehenen Arbeitsplätzen die zum Ausstellen einer Signatur

benötigten PKI-Komponenten (Signatur-Software, Kartenlesegerät, siehe Kapitel 4.4)

eingerichtet. Des Weiteren müssen die vom Unternehmen zur Signierung berechtigten

Mitarbeiter mit einem qualifizierten Zertifikat einer akkreditierten Zertifizierungsstelle

und einer entsprechenden Smart Card mit dazugehöriger PIN-Nummer ausgestattet

werden (siehe 4.4).

Signatur-ArbeitsplatzArbeitsplatz

Unternehmens-Netzwerk

Arbeitsplätze/Anwender

Datenbank,Mail-Server,

eBilling-System

Abbildung 9.6: Dezentrale Signatur-Lösung

Die dezentrale Signatur-Lösung bringt allerdings mehrere Nachteile mit sich, die sie für

ein Signieren im Massenbetrieb ungeeignet machen:183

182

Vgl. SCHILLER, VOLLMER (2002), S. 18-19 183

Vgl. SCHILLER, VOLLMER (2002), S. 18


• Es müssen an mehreren/vielen Stellen im Unternehmen Signatur-

Infrastrukturen eingerichtet und betrieben werden. Gerade für Unternehmen

mit einer großen Buchhaltungsabteilung entstehen dadurch schwer abschätz-

bare Kosten.

• Da eine Vielzahl von Personen mit dem Umgang der Signatur- Hard- und

Software vertraut gemacht werden müssen, bedarf es umfangreicher Schu-

lungsmaßnahmen. In Unternehmen mit einer häufig wechselnden Mitarbeiter-

Struktur bedeutet dies einen zusätzlichen finanziellen und organisatorischen

Aufwand.

• Die Handhabung des Signatur-Vorgangs gestaltet sich eher umständlich. Da

die Daten in der Regel nur einzeln signiert werden können, erweisen sich die

dazu notwendigen Prozesse (Smart Card einlesen, PIN-Nummer eingeben und

bestätigen, siehe Kapitel 4.4) im Massenbetrieb als unpraktikabel und lang-

sam.

Die dezentrale Signatur-Lösung eignet sich aufgrund der aufgeführten Nachteile vor

allem für Unternehmen, die nur geringe Datenmengen (insbesondere eine geringe An-

zahl von Rechnungen) elektronisch signieren möchten und somit das Signieren auf we-

nige Mitarbeiter und Arbeitsplätze konzentrieren können. In diesem Fall zeichnet sich

diese Vorgehensweise durch geringe Anschaffungs- und Betriebskosten aus (siehe Ka-

pitel 4.4) und stellt die Unternehmen vor ein nicht allzu großes Investitionsrisiko.

9.4.3 Zentrale Signatur-Lösung

Die zentrale Signatur-Lösung entwickelte sich aus den Nachteilen der Dezentralen, mit

dem Ziel, die elektronische Signatur auch im Massenbetrieb praktikabel einsetzen zu

können. Die zentrale Lösung sieht vor, die Signatur-Komponenten nur an einer zentra-

len Stelle in das bestehende IT-System des Unternehmens einzubinden.


Unternehmens-Netzwerk

Arbeitsplätze/Anwender

Signatur-Server

Datenbank,Mail-Server,

eBilling-System

Abbildung 9.7: Zentrale Signatur-Lösung184

In der Praxis wird die zentrale Signatur durch den Betrieb eines Signatur-Servers reali-

siert. Der Signatur-Server verwaltet die SmartCards und die darauf gespeicherten quali-

fizierten Zertifikate der zum Ausstellen einer Signatur berechtigten Mitarbeiter. Alter-

nativ dazu, können die einer Signatur zugrundeliegenden personenbezogenen Schlüssel-

informationen auch in einem Hardware-Sicherheitsmodul gespeichert werden. Der Sig-

natur-Server nimmt Signatur-Anfragen der berechtigten Mitarbeiter entgegen, wählt

deren SmartCards/Schlüsselinformationen aus und erstellt nach Eingabe der persönli-

chen PIN-Nummer die qualifizierte Signatur über das zugrundeliegende Dokument

bzw. die zugrundeliegende Datei. Die erzeugte Signaturdatei wird dann an die jeweilige

Anwendung am Arbeitsplatz des Mitarbeiters zurückgegeben.185

Die Vorteile der zentralen Signatur-Lösung in Form eines Signatur-Servers sind im We-

sentlichen die Folgenden:186

• Es muss nur eine Signatur-Infrastruktur eingerichtet und betrieben werden. Es

reicht demnach aus, einzelne Mitarbeiter mit der Administration des Signatur-

Servers zu betrauen und entsprechend zu schulen.

• Die Handhabung an den einzelnen Arbeitsplätzen ist unkompliziert. Um eine

Signatur erstellen zu können muss lediglich die persönliche PIN-Nummer ein-

gegeben werden.

• Durch den Betrieb mehrerer SmartCards pro Mitarbeiter ist eine parallele Sig-

natur mehrerer Daten möglich. Dadurch lassen sich erhebliche Performance-

Vorteile gegenüber der dezentralen Einzelplatz-Lösung erzielen. Beispielswei-

184

Vgl. Utimaco Signatur Server, abrufbar unter www.utimaco.de, abgerufen am 11.04.03 185

ebenda 186

Vgl. SCHILLER, VOLLMER (2002), S. 19


se benötigt der Utimaco Signatur Server durch den Einsatz von 10 SmartCards

nur ca. 4 Minuten für 10.000 Signaturen (in Abhängigkeit von der verwende-

ten SmartCard) gegenüber ca. 45 Minuten bei dem Einsatz einer einzelnen

SmartCard.187

Während das dezentrale Ausstellen einer Signatur an einem Einzelarbeitsplatz mit einer

Standard-Signatur-PKI (siehe Kapitel 4.4) realisiert werden kann, bedarf es für den Be-

trieb eines Signatur-Servers einem speziellen Hard- und Software-System entsprechen-

der Anbieter. Die genauen Kosten für Implementierung und Betrieb eines Signatur-

Servers sind abhängig von dem Anbieter188 und von der Größe des zu signierenden Da-

tenvolumens (danach richtet sich z.B. die Anzahl der eingesetzten SmartCards). Im

Durchschnitt belaufen sich die einmalig anfallenden Hardware-Kosten auf ca. 30.000,-

€, hinzu kommen Lizenz- und Supportkosten von 50.000,- bis 100.000,- € pro Jahr.189

Die Einrichtungs- und Betriebskosten lassen sich demnach nur bei intensiver Nutzung

des Systems schnell wieder erwirtschaften, so dass der Einsatz eines zentralen Signatur-

Servers vor allem für Unternehmen geeignet ist, die eine Vielzahl von Daten (z.B.

Rechnungen) in kurzer Zeit elektronisch signieren möchten. Beispielsweise wirbt die

AuthentiDate International AG bei der Einführung ihrer eBilling-Lösung (siehe Kapitel

11.2) basierend auf dem AuthentiDate Signatur-Server mit einem ROI innerhalb eines

Jahres bei einem durchschnittlichen Rechnungsvolumen von 10.000 Rechnungen pro

Monat.190

187

Vgl. Produkt-Beschreibung Utimaco Signatur Server SC, Utimaco Safeware AG. Abrufbar unter http://www.utimaco.de, abgerufen am 11.04.03

188 Anbieter sind u.a.: Utimaco Safeware AG siehe http://www.utimaco.de, AuthentiDate International AG siehe http://www.authentidate.de, Secunet Security Networks AG siehe http://www.secunet.de

189 Die Angaben stammen aus einem telefonischen Gespräch vom 23.04.03 mit Frau Svjetlana Lovric, Mitarbeiterin der TietoEnator Business Services GmbH, Frankfurt a. M.

190 Vgl. AUTHENTIDATE (2002), S. 5

10.1 Grundlagen und Ziele 115

10 Geschäftsprozessoptimierung durch E-Mail-Billing

10.1 Grundlagen und Ziele

Nachdem in Kapitel 9 verschiedene eBilling-Verfahren vorgestellt wurden, soll im Fol-

genden der Ablauf einer zwischenbetrieblichen Rechnungsstellung per direktem E-

Mail-Billing analysiert werden. Die Analyse bezieht sich auf die Ergebnisse der in Ka-

pitel 6, basierend auf der Rechnungsstellung in Papierform, durchgeführten Geschäfts-

prozessanalyse und soll prüfen, inwieweit eine Umstellung auf E-Mail-Billing die auf

Seiten des Rechnungsstellers und auf Seiten des Rechnungsempfängers ablaufenden

Geschäftsprozesse optimieren kann.

Analog zu Kapitel 6 erfolgt die Analyse an einem Geschäftsprozessmodell in eEPK-

Notation (siehe Kapitel 3.2). Bezogen auf das Modell der papierbasierten Rechnungs-

stellung (IST-Modell, siehe Kapitel 6.3), stellt der hier betrachtete Ablauf der elektroni-

schen Rechnungsstellung mit E-Mail-Billing das vermeintlich optimierte SOLL-Modell

dar. Anhand der beiden Modelle soll ein Kostenvergleich basierend auf der mittleren

Bearbeitungszeit und den durchschnittlich anfallenden Sachkosten (nur für das rech-

nungsstellende Unternehmen) durchgeführt werden. Die entsprechenden Kennzahlen

wurden in Kapitel 6.3 für das IST-Modell berechnet. Für das SOLL-Modell werden sie

im Verlauf der Analyse ermittelt. Auch hier beruhen die zugrundeliegenden Zeit- und

Kostenangaben der einzelnen Prozesse nicht auf einer vom Autor durchgeführten Un-

tersuchung, sondern orientieren sich an der in Kapitel 6 genannten Untersuchung zur

Einführung einer elektronischen Bestellabwicklung bei Lufthansa Air Plus.191

10.2 Analyse des SOLL-Modells

10.2.1 Modellgrundlagen

Das nachfolgende SOLL-Modell stellt den Ablauf einer zwischenbetrieblichen Rech-

nungsstellung per E-Mail-Billing-Verfahren dar und ist unterteilt in die Bereiche Rech-

nungssteller und Rechnungsempfänger.

Um den Anforderungen des § 14 UStG bezüglich einer steuerrechtlichen Anerkennung

elektronischer Rechnungen gerecht zu werden, wird ein Signatur-Verfahren in den Ab-

lauf integriert. Das Ausstellen der geforderten qualifizierten elektronischen Signatur mit

Anbieterakkreditierung kann dabei sowohl durch einen zentralen Signatur-Server als

191

Siehe STELZER (2002), S. 18-51, nach GARZ (2001)

10.2 Analyse des SOLL-Modells 116

auch durch den Einsatz einer dezentralen Einzelplatz-Lösung erfolgen (siehe Kapitel

9.4). Als Übertragungsformat der Rechnungsdaten soll XML dienen. Grundsätzlich ist

das Modell auch auf andere Übertragungsformate (wie z.B. EDIFACT) anwendbar,

jedoch eignet sich XML aufgrund der in Kapitel 8.3.1 aufgezeigten Vorteile besonders

für einen elektronischen Geschäftsdatenaustausch. Den nachfolgend dargestellten Pro-

zessen geht voraus, dass sich Rechnungssteller und Rechnungsempfänger im vorhinein

auf einen der Rechnung zugrundeliegenden XML-Standard und/oder das verwendete

Schema bzw. DTD (Vgl. z.B. Abbildung 8.6, Rechnung DTD) geeinigt haben. Damit ist

sichergestellt, dass dem Rechnungsempfänger die Dokumentenstruktur der XML-

Rechnung bekannt ist und somit die Inhalte durch einen implementierten XML-Parser

richtig interpretiert werden können.

10.2.2 Prozessablauf Rechnungssteller

Der Rechnungssteller erzeugt die Rechnung basierend auf den in seiner Datenbank vor-

liegenden Kunden- und Leistungsdaten mit Hilfe eines EDV-Systems.192 Anstatt die

Rechnung auszudrucken und damit einen Medienbruch zu verursachen, wird eine dem

vereinbarten Standard bzw. Schema entsprechende Rechnungsdatei im XML-Format

erzeugt. Dazu dient ein speziell dafür vorgesehener XML-Konverter, der im Idealfall

über eine Schnittstelle direkt mit dem EDV-System verbunden ist. Anschließend wird

die XML-Rechnung mit einem den gesetzlichen Anforderungen entsprechenden, gülti-

gen Zertifikat elektronisch signiert und für die eigene Buchhaltung gespeichert. Die

damit zum Vorsteuerabzug berechtigende elektronische Rechnung wird nun als Anhang

einer E-Mail über das Internet an den Empfänger gesendet. Dafür kann eine beliebige

E-Mail-Software eingesetzt werden. Wichtig dabei ist, dass der elektronische Postaus-

gang, gemäß den Anforderungen der Finanzbehörden bezüglich einer lückenlosen

Buchführung, registriert wird.193 Dies kann beispielsweise durch eine automatische Re-

gistrierung in einem Postausgangsordner des Mail-Servers geschehen. Der Text der E-

Mail kann die wesentlichen Rechnungsdaten wie z.B. Absender, Rechnungsgrund, Be-

trag, Fälligkeit enthalten und weist den Empfänger darauf hin, dass sich im Anhang die

elektronisch signierten, detaillierten Rechnungsdaten befinden. Eventuell können zu-

sätzlich noch Angaben zu dem verwendeten XML-Standard/Schema gemacht werden.

192

Das eingesetzte EDV-System registriert den Rechnungsausgang automatisch 193

Siehe GOBS

SOLL-Modell: Prozessablauf Rechnungssteller


XML-Rechnungerstellen

InterneDatenbank

Rechnungs-daten

Rechnungspeichern

Rechnungsstel-lung erforderlich


XML-Rechnungerstellt

Rechnunggespeichert


Mit-arbeiter

Rechnung zumVersand freigeben

InterneDatenbank


R. zum Versandfreigegeben

Rechnungversenden

Rechnung istversandt E-Mail

Postausgangregistrieren

Postausgangregistriert

Ausgangs-Postfach


Mit-arbeiter

1-2 minE-Mail

Anwendung(z.B. Outlook)

E-MailAnwendung

(z.B. Outlook)

Kunden-kontostand

Leistungs-daten

2-5 min


XML-Konverter

Mail-Server

Rechnung<XML-Datei>

Rechnung<XML-Datei>

Rechnungdigital signieren


ElektronischeRechnung erstellt

1-2 min

Signatur Hard-und Software

Rechnung<XML-Datei>

EDV-Anwendung

Verant-wortlicher

Rechnung<XML-Datei>

InterneDatenbank

1 min

Abbildung 10.1: Rechnungserstellung und -versand mit E-Mail-Billing

10

.2 A

nalyse d

es SO

LL

-Mo

dells

11

7

SOLL-Modell: Prozessbeschreibung Rechnungssteller

Nr. Prozess/Funktion Bearbeitungs-zeit (min)

∅∅∅∅ Sach-kosten

Beteiligte Stelle IT-System-Unterstützung Schwachstel-len/Probleme

1 Rechnungsdaten erfassen 2-5 - Vertrieb/Buchhaltung, Mitarbeiter


2 XML-Rechnung erstellen 1 - Vertrieb/Buchhaltung, Mitarbeiter

EDV-Anwendung(z.B. Ex-cel), XML-Konverter

Absprache über XML-Standard/Schema not-wendig

3 Rechnung elektronisch signieren

1-2 - Vertrieb/Buchhaltung, Verantwortlicher

Signatur Hard- und Software, gültiges Zertifikat

Spezielle Hardware notwendig

4 Rechnung speichern - - Vertrieb/Buchhaltung, Verantwortlicher

EDV-Anwendung (z.B. Excel), XML-Konverter, Datenbank

5 Rechnung zum Versand freigeben - -

Vertrieb/Buchhaltung, Verantwortlicher

-

6 Rechnung versenden 1-3 0,30€ Vertrieb/Buchhaltung, Mitarbeiter

E-Mail-Anwendung (z.B. Outlook), Internet

7 Postausgang registrieren Automatisch - Vertrieb/Buchhaltung, Mitarbeiter

E-Mail-Anwendung (z.B. Outlook)

Gesamt 5-11 ∅∅∅∅8

0,30€ 2 Durchgehend

Tabelle 10.1: Prozessbeschreibung SOLL-Modell Rechnungssteller

10

.2 A

nalyse d

es SO

LL

-Mo

dells

11

8


10.2.3 Prozessablauf Rechnungsempfänger

Auf Seiten des Rechnungsempfängers geht die E-Mail mit der elektronisch signierten

XML-Rechnung im Anhang in einem Postfach auf einem Mailserver ein. Der Eingang

im Postfach wird automatisch durch die von Seiten des Empfängers eingesetzte E-Mail-

Software registriert. Zunächst wird die Gültigkeit der elektronischen Signatur der Rech-

nung durch Anwendung einer geeigneten Signatur-Prüfsoftware verifiziert (detaillierter

Prozessablauf siehe Kapitel 4.4). Damit wird sichergestellt, dass die Rechnungsdaten

tatsächlich von dem angegebenen Absender stammen und auf ihrem Übertragungsweg

über das Internet nicht verfälscht wurden. Bei einer positiven Signaturprüfung wird die

Rechnungsdatei als solche akzeptiert. Bei einem negativen Prüfergebnis ist die Datei

nicht vertrauenswürdig und wird nicht akzeptiert und weiterverarbeitet. Aufgrund der

durch das Bundesfinanzministerium vorgegebenen Regelungen bezüglich des Umgangs

mit elektronischen Rechnungen194, muss das Prüfergebnis zusammen mit der signierten

Rechnungsdatei und den zum Entschlüsseln angewandten Komponenten (Signatur-

Prüfschlüssel, qualifiziertes Zertifikat) archiviert werden (siehe Kapitel 5.3.1). Die Ar-

chivierung erfolgt auf einem gesicherten Server oder alternativ auf Magnetband bzw.

optischen Datenträgern wie beispielsweise CD oder DVD. Nun erfolgt die Weiterverar-

beitung der Rechnungsdaten in der Buchhaltungsabteilung bzw. im Rechnungswesen

des Unternehmens. Ein auf den vereinbarten Standard bzw. das vereinbarte Schema

abgestimmter XML-Parser liest dazu die Inhalte der XML-Rechnung aus und übergibt

diese über eine Schnittstelle an ein EDV-System, mit dem die Rechnungsdaten weiter-

verarbeitet werden sollen. Die Datenerfassung geschieht ohne Medienbruch durch einen

automatisierten Import der Daten in das EDV-System bzw. in die Datenbank des Rech-

nungsempfängers. Die Rechnungsdaten sind nun (im Idealfall) allen Abteilungen des

Unternehmens zugänglich. Nach erfolgreicher Rechnungsprüfung (Abgleich mit Wa-

reneingangsdaten bzw. Auftragsdaten) wird die Rechnung verbucht und die Zahlung

eingeleitet.

194

Siehe GDPDU


SOLL-Modell: Prozessablauf Rechnungsempfänger

Elektr. Rechnungeingegangen

ElektronischeSignatur prüfen

Elektr. Rechnungnicht akzeptieren

Prüfung negativ Prüfung positiv

Elektr. Rechnungakzeptieren

Elektr. Rechnungakzeptiert



Rechnung u. Prüf-ergebnis archivieren

Mail-Postfach

Rechnungs-daten

InterneDatenbank

1-2 min

2-5 minEDV-

Anwendung(z.B. Access)

Archivierungs-Software

Rechnungsprüfung

Prüfung negativ Prüfung positiv

Reklamation,Klärungsvorgang


Archivierungabgeschlossen

Warenein-gangsdaten

Auftrags-daten

2 - 3 min InterneDatenbank

1-2 min

Elektr. Rechnungnicht akzeptiert


Mail-Server

Archiv-Server

XML-Parser

Rechnung<XML-Datei>

Rechnung<XML-Datei>

Rechnung<XML-Datei>

Rechnung<XML-Datei>

Buchhaltung,Rechnungswesen

Mit-arbeiter

Rechnungs-eingang

Mit-arbeiter

Signatur-Prüfsoftware

Abbildung 10.2: Eingang und Weiterverarbeitung einer E-Mail-Rechnung

SOLL-Modell: Prozessbeschreibung Rechnungsempfänger

Nr. Prozess/Funktion Bearbeitungs-zeit (min)

Beteiligte Stelle IT-System-Unterstützung Schwachstellen/

Probleme

1 Elektronische Signatur prüfen 1-2 Buchhaltung / Rechnungs-wesen, Mitarbeiter

Signatur-Prüfsoftware Spezielle Software not-wendig

2a Elektronische Rechnung akzeptieren

- Buchhaltung / Rechnungs-wesen, Mitarbeiter

-

2b Elektronische Rechnung nicht akzeptieren

- Buchhaltung / Rechnungs-wesen, Mitarbeiter

- Prozess-Ende

3 Rechnung u. Prüfergebnis archivieren

1-2 Buchhaltung / Rechnungs-wesen, Mitarbeiter

Archivierungs-Software, Datenbank

4 Rechnungsdaten erfassen 2-5 Buchhaltung / Rechnungs-wesen, Mitarbeiter

EDV-Anwendung (z.B. Access), Datenbank

5 Rechnungsprüfung 2-3 Buchhaltung / Rechnungs-wesen, Mitarbeiter


Gesamt 6-12 ∅∅∅∅9

1 Durchgehend

Tabelle 10.2: Prozessbeschreibung SOLL-Modell Rechnungsempfänger

10

.2 A

nalyse d

es SO

LL

-Mo

dells

12

1


10.2.4 Kostenvergleich IST/SOLL-Modell

Im Folgenden werden die für einen Rechnungssteller bzw. Rechnungsempfänger anfal-

lenden Gesamtkosten einer Rechnungsstellung in Papierform berechnet und den dafür

anfallenden Gesamtkosten beim Einsatz des beschriebenen E-Mail-Billing-Verfahrens

gegenübergestellt. Die Grundlage der Berechnung bilden die anhand des IST- bzw.

SOLL-Modells ermittelten Kennzahlen für die mittlere Bearbeitungszeit und die durch-

schnittlich anfallenden Sachkosten (nur für Rechnungssteller). Für die auszuführenden

Prozesse wird ein kalkulatorischer Stundensatz von 30,- Euro zugrundegelegt.195

Kostenvergleich: Rechnungsübermittlung durch Rechnungssteller

Durchschnitt pro Rechnung Papierrechnung E-Mail-Billing

Zeitbedarf (in Minuten) 11 8

kalkulatorischer Stundensatz 30,00 € 30,00 €

Bearbeitungskosten (= Bearbei-tungszeit /60 * Stundensatz)

5,50 € 4,00 €

Sachkosten 1,55 € 0,30 €

Gesamtkosten (= Bearbeitungs-kosten + Sachkosten) 7,05 € 4,30 €

Kosteneinsparung - 2,75 €

Tabelle 10.3: Kostenvergleich Rechungsübermittlung

Kostenvergleich: Rechnungsbearbeitung durch Rechnungsempfänger

Durchschnitt pro Rechnung Papierrechnung E-Mail-Billing

Zeitbedarf (in min) 24 9

kalkulatorischer Stundensatz 30,00 € 30,00 €

Bearbeitungskosten 12,00 € 4,50 €

Gesamtkosten 12,00 € 4,50 €

Kosteneinsparung - 7,50 €

Tabelle 10.4: Kostenvergleich Rechnungsbearbeitung

195

Ausgerichtet an dem durchschnittlichen Stundensatz einer Sekretärin. Vgl. Fiebich & PartnerInnen Steuerberatungskanzlei, abrufbar unter http://www.fiebich.com/fiebich_folder.pdf, abgerufen am 19.05.03

10.3 Ergebnis der Optimierung 123

Auf Seiten des Rechnungsstellers lassen sich bei der elektronischen Rechnungsstellung

per E-Mail-Billing durchschnittliche Kosteneinsparungen von 30% gegenüber der Pa-

pierrechnung erzielen. Das Einsparpotential setzt sich zum einen aus einem geringfügig

beschleunigten Prozessablauf (3 min) und zum anderen aus den Einsparungen durch den

Wegfall von Druck-, Kuvertierungs- und Portokosten zusammen.

Auf Seiten des Rechnungsempfängers ist allein die stark verkürzte Bearbeitungszeit

(vor allem bedingt durch die automatisierte Datenerfassung) für Kosteneinsparungen

von über 60% verantwortlich.

Das am Beispiel des E-Mail-Billing-Verfahrens errechnete Einsparpotential der elektro-

nischen Rechnungsstellung fügt sich in die Ergebnisse allgemeiner Untersuchungen und

Marktschätzungen zum Einsatz von eBilling-Lösungen ein. Beispielsweise geht eine

PwC-Prozessanalyse auf Seiten des Rechnungsstellers von einem durchschnittlichen

Einsparpotential von 1,60 € - 3,00 € pro elektronisch versandter Rechnung aus.196 Das

Unternehmen TietoEnator kalkuliert die durchschnittlichen Bearbeitungskosten einer

eingegangenen Papierrechnung mit 5,00 € - 20,00 € und schätzt das Kostensenkungspo-

tential durch die vereinfachte Bearbeitung einer elektronischen Rechnung auf bis zu

70%.197

10.3 Ergebnis der Optimierung

Im Vergleich zu den Ergebnissen der Analyse der papierbasierten Rechnungsstellung,

erfüllt das beschriebene E-Mail-Billing-Verfahren unter Einsatz einer elektronischen

Signatur die in Tabelle 6.1 gestellten Anforderungen an den zwischenbetrieblichen

Rechnungsprozess in hohem Maße.

Auf Seiten des Rechnungsstellers lassen sich folgende Vorteile durch den elektroni-

schen Rechnungsversand per E-Mail-Billing erzielen:

• Druck-, Kuvertierungs- und Portokosten können eingespart und die Bearbei-

tungszeit verkürzt werden, so dass sich die Gesamtkosten eines Rechnungs-

ausgangs merklich reduzieren lassen (siehe Tabelle 10.3).

196

Analyse von PricewaterhouseCoopers, Vgl. LAPP ET AL (2002), S. 3 197

Vgl. TietoEnator Business Services GmbH, abrufbar unter http://www.sealsnet.tietoenator.com/de, Link: Kundenservice �ROI Kalkulation, abgerufen am 20.05.03


• Die Rechnungsdaten lassen sich durch den Wegfall der Postlaufzeit zeitnah

übertragen. Dadurch kann die gesamte Rechnungsstellung beschleunigt wer-

den, so dass die geforderten Zahlungen früher ausgelöst werden können. Das

wiederum führt zu einem erhöhten Zinsgewinn und Cashflow seitens des rech-

nungsstellenden Unternehmens.

• Durch eine automatisch erzeugte Empfangsbestätigungsmail kann die Nach-

weisbarkeit der Zustellung günstig und komfortabel realisiert werden.

• Die Anwendung von Verschlüsselungsverfahren ermöglicht einen effektiven

Datenschutz.

• Die Marketingfunktion der Rechnung kann kostengünstig und kundenfreund-

lich gestaltet werden. Beispielsweise können Werbe-Informationen an die E-

Mail angehängt werden und/oder Links auf die Web-Seiten des Rechnungs-

stellers verweisen.

Auf Seiten des Rechnungsempfängers ermöglicht der Eingang einer elektronischen

Rechnung folgende Optimierungen:

• Die im Mail-Postfach eingehenden Rechnungsdaten sind jederzeit und überall

(Internetanschluss vorausgesetzt) abrufbar. Eventuell auftretende Klärungsfäl-

le können ebenfalls zeitnah per E-Mail ablaufen.

• Die E-Mail-Rechnung kann innerbetrieblich schnell und einfach weitergeleitet

werden.

• Die Rechnungsdaten können automatisch (ohne Medienbruch) in das hausei-

gene EDV-System übernommen werden. Dadurch lassen sich Fehler vermei-

den und die Bearbeitungszeit verkürzen, so dass insgesamt die Bearbeitungs-

kosten erheblich gesenkt werden können (siehe Tabelle 10.4).

• Die beschleunigte Rechnungsübertragung und –bearbeitung erleichtert das

Einhalten von Skontofristen.

• Die Rechnung kann unmittelbar (in rein elektronischer Form - ohne zusätzli-

che periodische Sammelabrechnung) zu einem Vorsteuerabzug gegenüber den

Finanzbehörden geltend gemacht werden. Dadurch wird der Vorsteuergewinn

beschleunigt.

• Durch eine direkte elektronische Archivierung der Rechnung lassen sich wei-

tere Kosten einsparen. Zum einen entfallen aufwändige Scan-Verfahren um

Daten auf Papier in eine elektronische Form zu überführen und zum anderen


lassen sich die Mietkosten für den Archivraum senken (Verhältnis: 20.000

Seiten auf Papier entsprechen 1 CD-ROM bzw. 700 MB auf einem Archiv-

Server). Vor allem in Unternehmen mit einem hohen Rechnungsvolumen stellt

dies aufgrund der langen Aufbewahrungsfrist von 10 Jahren einen bedeuten-

den Vorteil dar.

Zusammenfassend kann festgestellt werden, dass sich, durch eine Umstellung vom pa-

pierbasierten Rechnungsaustausch hin zu einem direkten E-Mail-Billing mit elektroni-

schen Signaturen, die durchzuführenden Geschäftsprozesse auf beiden Seiten des Rech-

nungsaustauschs schlanker und effizienter gestalten lassen. Kosteneinsparungen können

sowohl auf Seiten des Rechnungsstellers als auch auf Seiten des Rechnungsempfängers

erzielt werden. Der Rechnungsempfänger kann die Vorteile der elektronischen Rech-

nungsstellung ohne eigenen finanziellen Aufwand nutzen, so dass die Bindung zu dem

rechnungsstellenden Unternehmen gestärkt und die Kundenzufriedenheit gesteigert

werden kann.

Die hier aufgeführten Vorteile lassen sich im Wesentlichen auch auf das Web-Billing-

Verfahren übertragen, so dass allgemein betrachtet, die Einführung einer eBilling-

Lösung und das damit verbundene Re-Design der beteiligten Geschäftsprozesse den

Zielen des Geschäftsprozessmanagements (siehe Kapitel 2.2) gerecht wird.

11.1 Einleitung 126

11 eBilling in der Praxis

11.1 Einleitung

Dieses Kapitel erhebt keinen Anspruch auf Vollständigkeit, sondern versucht einen

Einblick in verschiedene, in der Praxis angewandte eBilling-Lösungen zu geben.

Bisher gibt es im deutschsprachigen Raum nur wenige praktizierte eBilling-Verfahren

mit elektronischen Signaturen. Im zwischenbetrieblichen Rechnungsaustausch be-

schränkt sich ein derartiger Einsatz nur auf vereinzelte Unternehmen. Eine von Pricewa-

terhouseCoopers Deutschland im September 2002 durchgeführte Umfrage beschränkt

auf SAP R\3-Anwender hat ergeben, dass lediglich 17% der befragten Unternehmen

elektronische Rechnungen im Sinne des Umsatzsteuergesetzes in einzelnen Unterneh-

mensbereichen einsetzen.198 Der Grund für die Zurückhaltung wird vor allem in den

hohen gesetzlichen Anforderungen an die elektronische Signatur und den damit verbun-

denen Investitionen gesehen. Grundsätzlich ist aber ein Trend zu einem zunehmenden

Einsatz von eBilling-Anwendungen zu erkennen. So gaben in der oben genannten Um-

frage 48% der Unternehmen, die derzeit noch keine elektronischen Rechnungen einset-

zen an, dass sie eine (zumindest teilweise) Umstellung auf eine elektronische Rech-

nungsstellung in den nächsten 2-3 Jahren planen.199

11.2 AuthentiDate eBilling-Signatur-Lösungen

Im Folgenden werden zwei eBilling-Lösungen der AuthentiDate International AG200 mit

Sitz in Düsseldorf näher betrachtet. Ziel des Unternehmens ist die Entwicklung und der

Vertrieb Signatur-basierter Geschäftsprozesslösungen. Die AuthentiDate International

AG ist ein durch die Regulierungsbehörde für Telekommunikation und Post (RegTP)

akkreditierter Zertifizierungsdienstanbieter. Somit besteht die Möglichkeit neben den

Geschäftsprozesslösungen auch die entsprechenden Zertifikate von dem Unternehmen

zu beziehen.

Im Mittelpunkt der eBilling-Lösungen steht der von der AuthentiDate International AG

entwickelte eBilling-Server. Der eBilling-Server vereint die Funktionen eines zentralen

Signatur-Servers (siehe Kapitel 9.4.3) und eines Mail-Servers. Das heißt, er ermöglicht 198

Vgl. PWC (2003), S. 17 199

Vgl. PWC (2003), S. 18 200

Für nähere Informationen zu dem Unternehmen siehe http://www.authentidate.de

11.2 AuthentiDate eBilling-Signatur-Lösungen 127

zum einen die massenweise und schnelle Ausstellung qualifizierter elektronischer Sig-

naturen (entsprechend den Anforderungen des §14 UStG) und zum anderen den Ver-

sand der signierten Rechnungen. Dazu verwaltet der eBilling-Server sowohl die den

Signaturen zugrundeliegenden, personenbezogenen Zertifikate in Form einer (oder e-

ventuell mehrerer) SmartCards pro zeichnungsberechtigter Person als auch die E-Mail-

Adressen der Rechnungsempfänger.

Die zunächst beschriebene eBilling-Lösung der AuthentiDate International AG basiert

auf der Implementierung und dem Betrieb des eBilling-Servers im rechnungsstellenden

Unternehmen (Inhouse-Lösung).201

Unternehmen A

Unternehmen B

Mail Server

Mitarbeiter

Mitarbeiter

Buchhaltung

Zeichnungs-berechtigter

Dokumentenarchivdes Unternehmens

Interne und externeZertifaktsverwaltungSignieren/VerifizierenZeitsignierenVerschlüsseln/Entschlüsseln

SmartCardqualifizierte Signatur

Internet

Mail Server

Abbildung 11.1: AuthentiDate eBilling-Inhouse-Lösung202

Die mit der Rechnungsstellung betrauten Mitarbeiter des Unternehmens übertragen die

(in beliebigen Datenformaten) erstellten elektronischen Rechnungen zusammen mit den

E-Mail-Adressen der Rechnungsempfänger an den eBilling-Server. Zur Signatur der

Rechnungen authentifiziert sich ein Zeichnungsberechtigter von seinem Arbeitsplatz

aus über einen PIN-Code gegenüber dem eBilling-Server. Dieser wählt das entspre-

201

Vgl. AUTHENTIDATE PRODUKTINFORMATION, S. 3-6 202

Vgl. WENDENBURG (2002), S. 12


chende qualifizierte Zertifikat des Mitarbeiters aus und signiert die bereitgestellten

Rechnungen automatisch. Damit sich die zeichnungsberechtigten Personen nicht für

jeden Signatur-Vorgang neu authentifizieren müssen, kann die PIN-Eingabe mit der

Öffnung eines Zeitfensters gekoppelt werden, d.h. der Mitarbeiter muss sich z.B. nur

einmal pro Tag authentifizieren.

Die Rechnungen können nach der Signatur direkt an die jeweiligen Empfänger im An-

hang einer E-Mail verschickt werden. Es findet also ein direktes E-Mail-Billing (siehe

Kapitel 9.3.2) statt. Alternativ ist aber auch eine Anbindung an ein Web-Billing-System

(siehe Kapitel 9.3.1) möglich.

Zur gesetzeskonformen Sicherung der Ausgangsrechnungen mit zugehöriger Signatur

und allen Signatur-Komponenten kann der eBilling-Server optional mit einem Doku-

mentenarchiv des Unternehmens verbunden werden. Des Weiteren bietet der Authenti-

Date eBilling-Server die Möglichkeit, Rechnungen zu verschlüsseln und zur Dokumen-

tation des Rechnungsausgangs mit einem Zeitstempel zu versehen. Die dafür notwendi-

gen Schlüsselinformationen werden ebenfalls von dem Signatur-Server verwaltet. Da

außerdem auch externe Schlüssel-Zertifikate verwaltet werden können, lassen sich auch

im Unternehmen eingehende elektronisch signierte und/oder verschlüsselte Daten durch

den eBilling-Server verifizieren und/oder entschlüsseln sowie mit einem Zeitstempel

versehen und sichern.

Zusätzlich zur Einrichtung der Hard- und Software des eBilling-Servers bietet die Au-

thentiDate International AG auch einen umfassenden Support- und Update-Service des

Systems. Dies ist insofern von Bedeutung, dass damit sichergestellt wird, das der eBil-

ling-Server gemäß eventuellen, zukünftigen gesetzlichen Änderungen im Bereich der

Rechnungsstellung oder der Signatur (z.B. Vergrößerung von Schlüssellängen) umge-

stellt und weiter betrieben werden kann. Dadurch wird eine (für die Unternehmen sehr

wichtige) Investitionssicherheit gewährleistet.

Alternativ zu dem hier vorgestellten Betrieb des eBilling-Servers in dem rechnungsstel-

lenden Unternehmen kann der Betrieb auch von einem externen ASP-Partner (Applica-

tion Service Provider203) der AuthentiDate International AG übernommen werden (z.B.

durch die Deutsche Telekom/T-Systems). Dazu wird unter Mithilfe der AuthentiDate

203

Der Application Service Provider bietet standardisierte und vorkonfigurierte Anwendungen (Lösungen) sowie die für die Nutz- ung erforderlichen Service- und Hardware-Umgebungen an, auf die via Internet zugegriffen werden kann. Quelle: K. F. Krie- singer, IBM Global Services 2001


International AG ein entsprechender Vertrag mit dem externen Dienstleistungsunter-

nehmen abgeschlossen.204 Der ASP-Partner übernimmt dann als vertrauenswürdiger

Dritter (Trust Center) das Ausstellen der Signaturen und den Versand der elektronischen

Rechnungen. Diese Vorgehensweise entspricht dem Prinzip des indirekten eBilling über

einen Konsolidator (siehe Kapitel 9.2.2).

Interne und externeZertifaktsverwaltung

Signieren/Verifizieren

Zeitsignieren

Verschlüsseln/Entschlüsseln

SmartCardqualifizierte Signatur

Buchhaltung

Dokumenten-archiv des

Unternehmens

Mail Server

EDV-System

eBilling-Client

Mail Server

Mitarbeiter

Mitarbeiter

Internet

Abbildung 11.2: AuthentiDate eBilling-Lösung über Trust Center205

Die aus dem EDV-System stammenden Rechnungsdaten werden zusammen mit den E-

Mail-Adressen der Rechnungsempfänger über einen, im rechnungsstellenden Unter-

nehmen eingerichteten, eBilling-Client an den AuthentiDate eBilling-Server des ASP-

Dienstleisters (verschlüsselt) übermittelt. Nach der Authentifikation durch einen zeich-

nungsberechtigten Mitarbeiter über den eBilling-Client werden die Rechnungen dann

automatisch mit dem persönlichen Zertifikat dieses Mitarbeiters signiert, mit einem

Zeitstempel versehen und (evtl. verschlüsselt) per E-Mail an die Rechnungsempfänger

übertragen. Kopien der Originalrechnung (inkl. Signatur und Zertifikat) können zur Ar-

chivierung auf CD-ROM gespeichert oder über einen Mail-Server in das Dokumenten-

archiv des Unternehmens zurückgeschrieben werden.

Die AuthentiDate International AG empfiehlt die Inhouse-Lösung Unternehmen mit

eigener IT-Abteilung und einem hohen Aufkommen an Ausgangsrechnungen (Empfeh-

204

Vgl. AUTHENTIDATE PRODUKTINFORMATION, S. 4 205

Vgl. WENDENBURG (2002), S. 13

11.3 T-Mobile RechnungOnline 130

lung: mehr als 1.000 Rechnungen monatlich).206 Das Unternehmen wirbt bei einem

durchschnittlichen Rechnungsaufkommen von 10.000 Rechnungen pro Monat mit ei-

nem ROI innerhalb des Einführungsjahres.207 Unternehmen mit einer geringen Anzahl

an Ausgangsrechnungen oder Unternehmen, die Installation, Betrieb und Wartung eines

eBilling-Servers nicht selbst vornehmen möchten, wird dagegen die ASP-Lösung emp-

fohlen.208

11.3 T-Mobile RechnungOnline

Vorreiter in der praktischen Umsetzung von eBilling-Verfahren ist die Telekommunika-

tionsbranche. Diese Branche zeichnet sich durch ein in regelmäßigen Abständen auftre-

tendes hohes Rechnungsvolumen mit einer Vielzahl von Kunden und einem intensivem

Marketing aus. Dadurch bietet sich ein Einsparpotential durch eine elektronische Rech-

nungsstellung.

T-Mobile Deutschland (Mobilfunk-Abteilung der Deutschen Telekom AG) betreibt

schon seit längerem ein direktes Web-Billing-System mit dem Namen "T-Mobile

RechnungOnline". Den Kunden wird damit die Möglichkeit gegeben, auf die traditio-

nelle Papierrechnung zu verzichten und die monatlichen Mobilfunk-Rechnungen kos-

tenfrei (abgesehen von dem Online-Nutzungsentgelt) über das Internet abzurufen. Dazu

loggt sich der Kunde über eine mit 128Bit-SSL-Verschlüsselung gesicherte Verbindung

mit einem, nach Anmeldung von der Telekom per Post zugestelltem, Benutzernamen

und Passwort auf den entsprechenden Web-Seiten von T-Mobile ein. Dort bekommt er

die für ihn bereitgestellten Rechnungen präsentiert. Dabei stehen zahlreiche Ansichten

(z.B. Einzelverbindungsnachweis (kurz EVN)) und Auswertungsmöglichkeiten für pri-

vate und geschäftliche Zwecke zur Verfügung. Neben einer Gesamt- und Detailüber-

sicht über die monatlichen Rechnungsbeiträge können die Verbindungen individuell

nach Zeitraum, Telefongesprächen, Daten- oder Faxverbindungen sortiert werden. Des

Weitern können alle Rechnungs- und Einzelverbindungsdaten zur Weiterverarbeitung

(z.B. in Excel/Access) im CSV-Format209 heruntergeladen werden. Zusätzlich stehen die

monatlichen Rechnungen im PDF-Format zum Download bereit. Den Zeitpunkt, wann

eine neue Rechnung online verfügbar ist, bekommen die Kunden auf Wunsch per E-

206


Vgl. AUTHENTIDATE (2002), S. 5 208


CSV=Comma Separated Values, standardisiertes Textformat mit der Möglichkeit zum Datenimport in MS-Excel/Access


Mail oder SMS mitgeteilt. In einem Rechnungsarchiv bleiben die Rechnungen bis 13

Monate nach der Ausstellung verfügbar.210 Bisher war es für Geschäftskunden aber nicht

möglich die elektronischen Mobilfunk-Rechnungen für einen Vorsteuerabzug gegen-

über dem Finanzamt geltend zu machen, da sie nicht entsprechend elektronisch signiert

wurden. Auf papierbasierte Sammelabrechnungen konnte also nicht vollends verzichtet

werden.

Seit Februar 2003 hat T-Mobile nun die Möglichkeiten von "T-Mobile RechnungOnli-

ne" um den Einsatz qualifizierter elektronischer Signaturen gemäß §14 UStG erweitert.

Die dafür eingesetzte Signaturlösung wurde in Zusammenarbeit mit der AuthentiDate

International AG (siehe Kapitel 11.2) entwickelt und implementiert. T-Mobile ist nach

eigenen Angaben damit der erste und zur Zeit einzigste Mobilfunkanbieter, der seinen

Kunden die Möglichkeit bietet, elektronisch signierte Rechnungen direkt zum Vorsteu-

erabzug beim Finanzamt elektronisch einzureichen.211 Auf Wunsch bekommt der Kunde

nun zusätzlich zu der monatlichen Rechnung im PDF-Format eine, mit einer qualifizier-

ten elektronischen Signatur ausgezeichnete, Rechnungsdatei zum Download bereitge-

stellt.212

Die PDF-Rechnung und die Signaturdatei gehören unmittelbar zusammen. Insbesondere

gegenüber den Finanzbehörden müssen beide Dateien vorliegen. Um die Zusammenge-

hörigkeit am Dateinamen erkennen zu können, gibt T-Mobile RechnungOnline folgende

Zusammensetzung der Dateinamen beim Download standardmäßig vor:

[Bezeichnung des Inhaltes]_[Rechnungsjahr]_[Rechnungsmonat]_[Rechnungsnummer].

[Format]. Ein Beispiel dafür : Papierrechnung_2002_12_0123456000789.pdf (statt "Pa-

pierrechnung" kann es auch "EVN" oder "Gutschrift" heißen). Die dazugehörige Signa-

turdatei ist dann wie folgt benannt: Papierrechnung_2002_12_0123456000789.ads.213

210

Siehe http://www.t-mobile.de/rechnungonline/, abgerufen am 26.05.03 211

Vgl. Pressebericht vom 24.01.2003, abrufbar unter http://www.authentidate.de, abgerufen am 26.05.03 212

Diese Funktion ist in der dargestellten Demo-Version nicht verfügbar 213

Vgl. http://www.t-mobile.de/rechnungonline/, abgerufen am 26.05.03


Abbildung 11.3: Einzelverbindungsnachweis T-Mobile RechnungOnline214

Einen vergleichbaren Service, jedoch derzeit ohne den Einsatz elektronischer Signatu-

ren, bietet die Deutsche Telekom mittlerweile auch für die Festnetz-Telefonrechnung

an. Der Kunde wird derzeit durch Werbung im Internet und durch Beilagen zur Papier-

rechnung auf die Möglichkeit der Online-Rechnungsstellung hingewiesen. Neben den

umfassenden Darstellungs- und Auswertungsmöglichkeiten wird vor allem auch mit

dem Aspekt Umweltschutz durch Papiereinsparung geworben. Laut Angaben der Deut-

schen Telekom nehmen derzeit 2 Millionen Telekom-Kunden das Angebot der Online-

Telefonrechnung war. Das bedeutet, dass jedes Jahr etwa 412 Tonnen weniger Papier

produziert, bedruckt und transportiert werden müssen.215 Die Marketingoffensive der

Telekom geht aber noch einen Schritt weiter. So werden den Kunden, die sich zu einer

ausschließlichen Abrechnung der Festnetz-Telefongebühren über das Internet entschei-

den, 4,80 € in der nächsten Abrechnung gut geschrieben.

An dieser Initiative zeigt sich, dass gerade die großen Unternehmen in der Telekommu-

nikationsbranche an einer möglichst umfassenden Umstellung des Rechnungsaustauschs

interessiert sind, da sie das Einsparpotential der elektronischen Rechnungsstellung über

das Internet erkannt haben.

214

T-Mobile RechnungOnline – Demo, abrufbar unter http://www.t-mobile.de/rechnungonline/, abgerufen am 26.05.03 215

Vgl. http://www.telekom.de/rechnung-online, abgerufen am 26.05.03

Download der EVN-Daten

Download der Signatur-Datei

11.4 TietoEnator Sealsnet 133

11.4 TietoEnator Sealsnet

Das Unternehmen TietoEnator Business Services GmbH stellt den Kunden mit "Seals-

net" ein sicheres Netzwerk zum Austausch von Geschäftsdokumenten verschiedenster

Art (z.B. Bestellungen, Rechnungen, Lieferscheine, etc.) zur Verfügung. Das Sealsnet

wurde bis zur vollständigen Übernahme durch die TietoEnator Business Services

GmbH im Januar 2003 von der Seals Document Services GmbH mit Sitz in Frankfurt

betrieben.216

Laut Angaben des Unternehmens nutzen rund 2.500 Kunden den Service von Sealsnet.

Daraus resultieren monatlich ca. 40 Millionen Transaktionen über das Netzwerk. 217 Ein

besonderer Schwerpunkt liegt dabei im elektronischen Rechnungsversand, u.a. übermit-

teln das Expressdienstleistungsunternehmen TNT und Lufthansa AirPlus elektronische

Rechnungen über Sealsnet.

Der elektronische Rechnungsversand über das Sealsnet gestaltet sich wie folgt:218

1. Der Rechnungssteller authentifiziert sich gegenüber TietoEnator und überträgt

seine Rechnungsdaten in einem hauseigenen Format an das Unternehmen. Die

Übertragung kann per Web-Browser oder voll automatisch über eine speziell

eingerichtete Übertragungssoftware erfolgen.

2. Die eingehenden Daten werden von TietoEnator in XML konvertiert und in ei-

ner zentralen Rechnungsdatenbank gespeichert.

3. Ein Rechnungsempfänger greift auf die Homepage des rechnungsstellenden Un-

ternehmens oder direkt auf das Sealsnet zu und identifiziert sich über ein vorher

festgelegtes Verfahren, z.B. durch Benutzername und Passwort oder per Smart-

Card.

4. Nach erfolgreichem Login werden die für den Rechnungsempfänger vorliegen-

den XML-Daten an den Webserver übertragen und im Browser präsentiert.

5. Die Rechnungen können nun in verschiedenen Ansichten betrachtet, ausge-

druckt und in einem vom Rechnungsempfänger festgelegten Format herunterge-

laden werden. Die Rechnungsdaten können demnach direkt in das unterneh-

menseigene Software-System übernommen werden.

216

Siehe http://www.sealsnet.tietoenator.com/de unter "Wir über uns", abgerufen am 26.05.03 217

ebenda, unter "Wir über uns" � "Kunden", abgerufen am 26.05.03 218

Vgl. www.seals.net, abgerufen am 20.12.02 (nicht mehr abrufbar aufgrund der Unternehmensübernahme durch TietoEnator)


Die Prozesse (Login, Download) auf Seiten des Rechnungsempfängers können bei gro-

ßen Dokumentenmengen auch vollautomatisch abgewickelt werden.

Der Ablauf einer Rechnungsübermittlung über das Sealsnet entspricht einem indirekten

Web-Billing mit TietoEnator als Konsolidator (siehe Kapitel 9.2.2). Die genauen Kos-

ten pro Transaktion richten sich nach der Gesamtanzahl der Transaktionen und nach der

Anzahl der zu verwaltenden Empfänger. Im Durchschnitt liegen die Kosten bei ca.

0,95 € pro Transaktion, hinzu kommt noch eine einmalige Einrichtungsgebühr von

3900,- €.219

Die Einbindung elektronischer Signaturen in den Rechnungsversand über Sealsnet ist

bis dato noch nicht erfolgt, wird aber von TietoEnator in naher Zukunft angestrebt.

Probleme bereitet dabei, dass nach § 2 Satz 7 SigG die den qualifizierten elektronischen

Signaturen zugrundeliegenden qualifizierten Zertifikate nur an natürliche Personen aus-

gestellt werden können. Dadurch ist es TietoEnator als Dienstleister des Rechnungsver-

sands nicht möglich, elektronische Signaturen gemäß §14 UStG im Auftrag des rech-

nungsstellenden Unternehmens zu erstellen und zu verwenden.

Das Unternehmen erarbeitet derzeit zusammen mit dem BMF (über das hessische Fi-

nanzministerium) Lösungsvorschläge, die einerseits eine Verwendung von Zertifikaten

für juristische Personen (z.B. "Firmenzertifikat", stellvertretend für ein Unternehmen)

und andererseits eine Delegation des Signatur-Verfahrens an Ditte ermöglichen.220

Die folgende Abbildung veranschaulicht das von TietoEnator vorgeschlagene Verfahren

zur Übermittlung zwischenbetrieblicher elektronischer Rechnungen über einen Dienst-

leistungsunternehmen unter Einbindung elektronischer Signaturen.

219

Siehe http://www.sealsnet.tietoenator.com/de, Link: Kundenservice � ROI Kalkulation, abgerufen am 26.05.03 220

Siehe http://www.sealsnet.tietoenator.com/de/download/te-sealsnet-digisig.pdf, abgerufen am 26.05.03


Abbildung 11.4: TietoEnator Lösungsvorschlag221

Das zur Diskussion gestellte Modell sieht vor, dass weiterhin unsignierte elektronische

Rechnungen über das Dienstleistungsunternehmen an den Empfänger übermittelt wer-

den. Zur Sicherstellung des Vorsteuerabzugs folgen aber in regelmäßigen Abständen

elektronisch signierte Sammelrechnungen. Die dabei zugrundeliegende Signatur wird

im Auftrag des rechnungsstellenden Unternehmens mit Hilfe eines entsprechenden Fir-

menzertifikats ausgestellt.

Bis eine endgültige rechtliche Regelung, die eine Rechnungsstellung in der dargestellten

Art und Weise ermöglicht, gefunden und verabschiedet ist, bietet TietoEnator, als Er-

gänzung zu den elektronisch übermittelten Rechnungen, den Versand von papierbasier-

ten Sammelrechnungen an.222

221

Siehe http://www.sealsnet.tietoenator.com/de/download/te-sealsnet-digisig.pdf, abgerufen am 26.05.03 222

ebenda

XML

12.1 Ergebnis der Arbeit 136

12 Schlussbetrachtung

12.1 Ergebnis der Arbeit

Das Ziel der vorliegenden Arbeit war, die elektronische Rechnungsstellung über das

Internet im zwischenbetrieblichen Rechnungsaustausch auf mögliche Optimierungspo-

tentiale gegenüber der papierbasierten Rechnungsstellung zu überprüfen. Des Weiteren

sollten die gesetzlichen Rahmenbedingungen der elektronischen Rechungsstellung be-

trachtet und technische Umsetzungsmöglichkeiten aufgezeigt werden.

Der Gesetzgeber hat positiv zu bewertende Rahmenbedingungen geschaffen, die Pro-

zesse der zwischenbetrieblichen Rechnungsstellung handelsstufenübergreifend über das

Internet abwickeln zu können. Ein zusätzliches Papierdokument für den Vorsteuerabzug

wird nicht mehr benötigt. Daran wird deutlich, dass die bisher bestehende Lücke in der

zwischenbetrieblichen elektronischen Verkaufsabwicklung geschlossen werden kann.

Die durchgeführten Geschäftsprozessanalysen zeigen am Beispiel des E-Mail-Billing-

Verfahren, dass sich durch eine elektronische Rechnungsstellung über das Internet so-

wohl auf Seiten des Rechnungsstellers als auch auf Seiten des Rechnungsempfängers

Optimierungspotentiale gegenüber der papierbasierten Rechnungsstellung ausschöpfen

lassen. Insbesondere können auf beiden Seiten nachhaltige Kosteneinsparungen erreicht

werden, so dass die Wettbewerbsfähigkeit der Unternehmen gesteigert werden kann.

Der Einsatz der gesetzlich geforderten qualifizierten elektronischen Signatur mit Anbie-

terakkreditierung gewährleistet eine größtmögliche Sicherheit bezüglich der Authentizi-

tät und Integrität der elektronisch übertragenen Rechnungsdaten. Eine derartige elektro-

nische Signatur erfüllt einen weitaus höheren Sicherheitsstandard als eine handschriftli-

che Unterschrift. Eventuell bestehende Sicherheitsbedenken seitens der Unternehmen

bezüglich der Anwendung bzw. dem Empfang elektronisch signierter Rechnungen sind

somit unberechtigt.

Als Grundlage der Datenübertragung erweisen sich die Medien Internet und E-Mail als

vorteilhaft. Aufgrund der schon vorhandenen, kostengünstigen Infrastruktur und der

weit verbreiteten Anwendung sind Akzeptanzprobleme wie bei dem Einsatz des traditi-

onellen EDI nicht zu erwarten.

Die vorgestellten technischen Umsetzungsmöglichkeiten von eBilling-Verfahren zei-

gen, dass eine Umstellung auf eine elektronische Rechnungsstellung über das Internet

prinzipiell von jedem Unternehmen realisierbar ist. Allerdings zeigt sich auch, dass das

12.2 Ausblick 137

Ausstellen der qualifizierten elektronischen Signaturen mit Anbieterakkreditierung ei-

nen technischen, organisatorischen und nicht zuletzt finanziellen Aufwand seitens der

Unternehmen bedeutet. Qualifizierte Mitarbeiter-Zertifikate müssen verwaltet und Sig-

natur- Hard- und Software implementiert werden. Insbesondere das Ausstellen der Sig-

naturen im Massenbetrieb setzt eine kostenintensive Technik voraus.

Entscheidender Faktor für oder gegen eine Einführung und die Auswahl eines geeigne-

ten Verfahrens ist die Anzahl der potentiell auf eine eBilling-Lösung umstellbaren Kun-

den. Mit diesem Wert steht und fällt der Erfolg einer derartigen Umstellung. Daran wird

deutlich, dass die jeweilige Unternehmenssituation genau analysiert werden muss, um

ein geeignetes Verfahren auswählen und die erhofften Einsparungen erzielen zu können.

Als Gesamtergebnis der Arbeit kann festgehalten werden, dass die zum 01.01.2002 ge-

schaffenen Regelungen des § 14 Umsatzsteuergesetz zusammen mit den vorgestellten

Internet-basierten eBilling-Lösungen die Möglichkeit bieten, eine sichere und effiziente

elektronische Rechnungsstellung im B2B-Bereich zu realisieren und damit die Prozesse

der Rechungsstellung zu optimieren. Es liegt nun an den Unternehmen diese Möglich-

keiten für sich zu nutzen.

12.2 Ausblick

Dass sich die elektronische Rechnungsstellung im zwischenbetrieblichen Rechungsaus-

tausch durchsetzen wird, kann aus gegenwärtiger Sicht als realistische Prognose gelten.

Inwieweit diese Form der Rechnungsstellung aber in absehbarer Zeit die seit Jahrhun-

derten praktizierte Rechnungsstellung in Papierform vollständig ersetzen kann, ist der-

zeit noch offen.

Vieles hängt davon ab, ob sich die Unternehmen der neuen Technik gegenüber offen

präsentieren. Insbesondere müssen sie bereit sein, sich von den traditionellen Prozessen

der papierbasierten Rechnungsstellung zu lösen. Soft- und Hardwarehersteller stehen

vor der Aufgabe geeignete Produkte zu entwickeln, die sich effektiv in bestehende

EDV-Systeme integrieren lassen. Des Weiteren müssen Wirtschaft und Verbände dazu

beitragen, einen einheitlichen Standard zur elektronischen Rechnungsstellung über das

Internet zu etablieren. Die derzeit bestehenden XML-Standardisierungsinitiativen exis-

tieren in der Regel parallel zueinander und bringen somit vorerst nur heterogene Lösun-

gen hervor.

12.2 Ausblick 138

Fest steht, dass sich die Wirtschaft dem Einsparungspotential der elektronischen Rech-

nungsstellung bewusst ist. Die aktuelle Entwicklung zeigt, dass eBilling-Verfahren vor

allem im Privatkunden-Bereich verstärkt eingesetzt werden. Insbesondere in Unterneh-

men der Telekommunikationsbranche gewinnt diese Form der Rechnungsstellung zu-

nehmend an Bedeutung. Im zwischenbetrieblichen Rechnungsaustausch hingegen wer-

den vielfach die hohen Anforderungen an die einzusetzende elektronische Signatur als

abschreckend empfunden. Praktizierte eBilling-Verfahren sind in diesem Bereich bisher

noch die Ausnahme. Von großer Bedeutung ist daher die durch die Bundesbehörden, im

Rahmen der bis zum 01.01.2004 umzusetzenden EU-Richtlinie 2001/115/EG (siehe

Kapitel 5.4), zu treffende Entscheidung bezüglich der zukünftigen Anforderungen an

die Signatur einer steuerrechtlich anerkannten elektronischen Rechnung (fortgeschritte-

ne oder qualifizierte elektronische Signatur). Aus wirtschaftlichen Gesichtspunkten for-

dern verschiedene Unternehmen und Verbände eine Reduzierung der Anforderungen

auf fortgeschrittene elektronische Signaturen. Denn diese können ohne zusätzliche In-

vestitionen in Signatur- Hard- und Software sowie Gebühren für Zertifizierungs-

diensteanbieter erstellt werden. Aller Voraussicht nach wird dieser Forderung aber nicht

entsprochen, da dadurch wichtige Sicherheitsvorkehrungen, insbesondere die vertrau-

enswürdige Identitätsprüfung des Absenders, verloren gehen würden. Des Weiteren

müssten dann auch die Gesetze zur Gleichstellung elektronisch signierter Dokumente

mit Dokumenten in Papierform angepasst werden. In diesem Fall, würden die Zertifizie-

rungsdiensteanbieter ihre Daseinsberechtigung verlieren und müssten sich vom Markt

zurückziehen.

Aufgrund der unsicheren zukünftigen Rechtslage warten derzeit viele Unternehmen den

Beschluss der Bundesbehörden bezüglich der neuen Signaturanforderungen ab, bevor

sie in eBilling-Lösungen investieren. Steht das Ergebnis fest, ist aber davon auszuge-

hen, dass sich auch in der zwischenbetrieblichen Rechungsstellung eBilling-Verfahren

weiter durchsetzen. Vor allem Unternehmen mit einem hohen Rechnungsaufkommen

werden aufgrund der Einsparmöglichkeiten die Rechnungsstellung zumindest in Teilbe-

reichen auf die elektronische Form über das Internet umstellen.

13 Literaturverzeichnis 139

13 Literaturverzeichnis

ANDRES, HUSS (2002): Andres, J., Huss, B., Die elektronische Rechnung im deutschen

Umsatzsteuerrecht; JurPC Web-Dok. 99/2002; Online seit 15.04.2002/23.04.2002, ab-

rufbar unter http://www.jurpc.de/aufsatz/20020099.htm, abgerufen am 10.06.2002.

AUTHENTIDATE (2002): Zentrale und automatische eBilling Prozesse unter Einsatz

qualifizierter elektronischer Signaturen nach § 14 UStG; Informationsbroschüre Au-

thentiDate International AG Düsseldorf, November 2002. Abrufbar unter http://www.

authentidate.de/pdfs/25032002031537PM.pdf, abgerufen am 27.05.03.

AUTHENTIDATE PRODUKTINFORMATION: AuthentiDate eBilling: Die neue Art Rechnun-

gen zu schreiben – sicher, schnell und effizient; Produktinformation AuthentiDate eBil-

ling-Lösungen, AuthentiDate International AG Düsseldorf, 2003. Abrufbar unter

http://www.authentidate.de/pdfs/AuthentiDate_elektronische_Rechnungsstellung_2003

_GER.pdf, abgerufen am 27.05.03.

BECKER ET AL (2002): Becker, J., Kugeler, M., Rosemann, M., (Hrsg.), Prozessmana-

gement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung; 3. Auflage,

Springer Verlag, Berlin u.a., 2002.

BERLECON RESEARCH (2003): E-Business-Standards in Deutschland – Bestandsauf-

nahme, Probleme, Perspektiven; Forschungsbericht des Bundesministeriums für Wirt-

schaft und Arbeit, durchgeführt von Berlecon Research GmbH, Analysten: Quantz, J.,

Wichmann, T., Berlin, April 2003. Abrufbar unter: http://www.bmwi.de/Homepage/

download/infogesellschaft/standardstudie.pdf, abgerufen am 25.05.03.

BGB (2002): Bürgerliches Gesetzbuch (BGB), Beck Texte im dtv, 50. Auflage, 2002.

BOSAK (1997): Bosak, J., XML, Java and the future of Web; Stand 03.10.1997, abrufbar

unter http://www.ibiblio.org/pub/sun-info/standards/xml/why/xmlapps.htm, abgerufen

am 26.03.03.


BUXMANN ET AL (1998): Buxmann, P., Weitzel, T., Kronenberg, R., Ladner; F., Erfolgs-

faktor Standard, Internet-basierte Kooperation mit WebEDI und XML/EDI; Lehrstuhl

für Betriebswirtschaftslehre, Johann Wolfgang Goethe Universität Frankfurt, 1998.

BUXMANN ET AL (1999): Buxmann, P., Weitzel, T., König, W., Ladner, F., XML-

Konzept und Anwendung der Extensible Markup Language; Lehrstuhl für Betriebswirt-

schaftslehre, Johann Wolfgang Goethe Universität Frankfurt, 1999.

BUXMANN ET AL (2001): Buxmann, P., Ladner, F., Weitzel, T., Anwendung der Exten-

sible Markup Language (XML), Konzeption und Implementierung einer WebEDI-

Lösung; WIRTSCHAFTSINFORMATIK 43 (2001) 3, S. 257-267.

BUXMANN ET AL (2001): Weitzel, T., Harder, T., Buxmann, P., Electronic Business und

EDI mit XML; 1. Auflage, dpunkt.verlag, Heidelberg, 2001.

DATEV E:SECURE: Fit für die qualifizierte elektronische Signatur; Hrsg. Datev eG,

abrufbar unter http://www.rechtsanwaltskammerhamburg.de/Signatur/Anlgen/Signatur_

Unterrichtung.pdf, abgerufen am 25.05.03.

DIN (2000): (Norm-Entwurf) DIN 16557-4, Ausgabe 06.2000 Elektronischer Datenaus-

tausch für Verwaltung, Wirtschaft und Transport (EDIFACT) - Teil 4: Regeln für die

Auszeichnung von UN/EDIFACT-Übertragungsstrukturen mit der Extensible Markup

Language (XML) unter Einsatz von Document Type Definitions (DTDs); Beuth Verlag

GmbH, Berlin, 2000.

DOCTRONIC (2001): Mit XML unterschreiben; Doctronic Newsletter Ausgabe 5 vom

04.12.2001. Abrufbar unter http://www.doctronic.de/knowhow/newsletter/newsletter5.

html, abgerufen am 19.05.03.

DUDEN (1983): Der kleine DUDEN, Fremdwörterbuch, 2. Auflage, Mannheim, Wien,

Zürich, Bibliographisches Institut, 1983.


EBUSINESS REPORT (2002/2003): The European e-Business Report, 2002/2003 edition,

Executive Summary of the First Synthesis Report, European Commission Brussels,

March 2003; Abrufbar unter: http://www.ebusiness-watch.org, abgerufen am 28.05.03.

EICKER, SCHWICHTENBERG (1999): Eicker, S., Schwichtenberg, H., Internet Bill Pre-

sentment und Payment als neue Form des Electronic Billing, In: Scheer, A.-W. (Hrsg),

Nüttgens, M., Electronic Business Engineering/4, Internationale Tagung Wirtschaftsin-

formatik; Seite 149-168, Physica Verlag, Heidelberg, 1999.

EU-RICHTLINIE (1999/93/EG): Richtlinie 1999/93/EG des Europäischen Parlaments

und des Rates vom 13. Dezember 1999 über gemeinschaftliche Rahmenbedingungen für

elektronische Signaturen, Amtsblatt der Europäischen Gemeinschaften vom 19. Januar

2000 Nr. L 13/12.

EU-RICHTLINIE (2001/115/EG): EU-Richtlinie 2001/115/EG des Rates zur Änderung

der Richtlinie 77/388/EWG mit dem Ziel der Vereinfachung, Modernisierung und Har-

monisierung der mehrwertsteuerlichen Anforderungen an die Rechnungsstellung;

Amtsblatt der Europäischen Gemeinschaften vom 17. Januar 2002 Nr. L 15/24.

GAITANIDES ET AL (1994): Gaitanides M., Scholz, R., Vrohlings, A., Raster, M. (Hrsg.),

Prozeßmanagement – Konzepte, Erfahrungen und Umsetzung des Reengineering; Mün-

chen, Wien, 1994.

GAITANIDES ET AL (1994): Gaitanides, M., Scholz, R., Vrohlings, A., Prozessmanage-

ment - Grundlagen und Zielsetzungen; In: Gaitanides, M., Scholz, R., Vrohlings, A.,

Raster, M. (Hrsg.): Prozessmanagement - Konzepte, Erfahrungen und Umsetzung des

Reengineering, München, Wien, S. 2-19.

GARZ (2001): Garz, A., Electronic Procurement im operativen Einsatz, Einführung des

elektronischen Beschaffungssystems ProNet von Lufthansa AirPlus zur Abwicklung der

Bestellprozesse ausgewählter C- Artikel bei der Lufthansa Technik AG; Unveröffent-

lichte Diplomarbeit am Fachgebiet Informationsmanagement der TU Ilmenau, Ilmenau,

2001.


GDPDU: Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen

(GDPdU); BMF-Schreiben vom 16. Juli 2001 - IV D 2 - S 0316 - 136/01.

Abrufbar unter http://www.bundesfinanzministerium.de/Anlage8440/BMF-Schreiben-

vom-16.07.01.pdf.

GEORG (1993): Georg ,T., EDIFACT - Ein Implementierungskonzept für mittelständi-

sche Unternehmen; Deutscher Universitaets Verlag, Leverkusen, 1993.

GOBS: Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS);

Schreiben des Bundesministeriums der Finanzen an die obersten Finanzbehörden der

Länder vom 7. November 1995 - IV A 8 - S 0316 - 52/95- BStBl 1995 I S. 738.

GOERS (2003): EBPPinfo-Portal; Informations- und Diskussionsportal zum Thema

Electronic Bill Presentment and Payment (EBPP), GOERS CONSULT GmbH. Abruf-

bar unter http://www.ebppinfo.de, letzter Abruf 02.06.03.

GORA (1991): Gora, W., Informationsarchitektur für Europa; Datacom, 3-89238-037-6

HEARN (2002): Hearn, C., Digitale Signaturen; Vortrag im Rahmen der Software AG

Benutzerkonferenz 2002. Abrufbar unter http://www.softwareag.com/germany/news/

09_02/P31-Digitale-Signaturen.pdf, abgerufen am 26.03.03.

HOERETH, ROISCH, SCHIEGL (2001): Hoereth, U., Robisch, M., Schiegl, B., Die elektro-

nische Rechnung; n-tv Steuern transparent, Informationen zur Sendung, 29.11.01, ab-

rufbar unter: www.ey.com/global/download.nsf/Germany/Die_elektronische_Rechnung

/$file /Die_elektronische_Rechnung.pdf, abgerufen am 25.05.03.

JUNGINGER (2000): Junginger, S., Modellierung von Geschäftsprozessen - State-of-the-

Art, neuere Entwicklungen und Forschungspotentiale; BPMS-Bericht, Universität

Wien, Juni 2000.

JUNGINGER ET AL (2000): Junginger, S., Kühn, H., Strobl, R., Karagiannis, D., Ge-

schäftsprozessmanagement der nächsten Generation – ADONIS Konzeption und An-

wendungen; BPMS-Bericht, Universität Wien, April 2000; gekürzte Fassung erschienen


in: WIRTSCHAFTSINFORMATIK 42 (2000) 5, Seite 392-401, Vieweg Verlag, Wiesba-

den, Oktober 2000.

KARAGIANNIS ET AL (1996): Karagiannis, D., Junginger, S., Strobl, R., Introduction to

Business Process Management Systems Concepts; Seite 81-106, in: Scholz-Reiter, B.,

Eberhard (Hrsg.), Business Process Modelling; Springer Verlag, Berlin u.a., 1996.

KELLER ET AL (1992): Keller, G., Nüttgens, M., Scheer, A.-W., Semantische Prozess-

modellierung auf der Grundlage "Ereignisgesteuerter Prozessketten (EPK)"; In: Scheer,

A.-W. (Hrsg.), Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi); Univer-

sität des Saarlandes, Heft 89, Januar 1992.

KELLER, TEUFEL (1997): Keller, G., Teufel, T., SAP R/3 prozessorientiert anwenden -

Iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten; Addison Wesley

Verlag, Bonn, 1997.

KÜHN, KARAGIANNIS (2001): Kühn, H., Karagiannis, D., Modellierung und Simulation

von Geschäftsprozessen; In: wisu – das wirtschaftsstudium, 30. Jg., 8-9/01, Seite 1161-

1170, August 2001.

LANGNER ET AL (1997): Langner, P., Schneider C., Wehler, J., Prozessmodellierung mit

Ereignisgesteuerten Prozessketten (EPKs) und Petri-Netzen; In: WIRTSCHAFTSIN-

FORMATIK 39 (1997) 5, Seite 479-489, Vieweg Verlag, Wiesbaden, 1997.

LAPP ET AL (2002): Lapp, T., Bernütz, S., Gröger, H.-H., Elektronische Rechnungsab-

wicklung – Ein Instrument zur strategischen Kostenreduktion; Abrufbar unter

http://www.dr-lapp.de/vortrag/e-invoicing.pdf, abgerufen am 20.05.03.

MEHNEN (2001): Mehnen, H., Anerkennung elektronisch erhaltener Rechnungen; GLI

Gesellschaft für Logistik und Informationssysteme mbH, 2001. Abrufbar unter

http://www.gli.de/download/news_artikel/Anerkennung_elektronisch_psw.pdf, abgeru-

fen am 02.06.03.


MERZENICH (2002): Merzenich, M., Prozessanalyse; Skript SS2002; Lehrstuhl für

ABWL und Wirtschaftsinformatik, Katholische Universität Eichstätt-Ingolstadt.

MINTERT, S. (2002): Mintert, S. (Hrsg.), XML & Co, Die W3C-Spezifikation für Doku-

menten- und Datenarchitektur; Addison-Wesley Verlag, München, 2002.

MÖHR, SCHMIDT (1999): Möhr, W., Schmidt, I. (Hrsg.), SGML und XML, Anwendun-

gen und Perspektiven; Springer Verlag, Berlin u.a., 1999.

MÜLLER-STEINHAGEN (2001): Müller-Steinhagen, G., XML – Schlüsseltechnologie des

neuen Jahrhunderts; SAG Systemhaus GmbH, 14.12.2001. Abrufbar unter

http://www.begin.de/deutsch/know/markt/xml_schluessel.htm, abgerufen am 19.05.03.

NÜTTGENS, RUMP (2002): Syntax und Semantik (EPK); Abrufbar unter http://epk.et-inf.

Fho-emden.de/literatur/2002/Promise2002_Nuettgens_Rump.pdf, Abruf am 26.03.03.

PWC (2003): Datenzugriff durch die Finanzverwaltung – Anforderungen für SAP R/3-

Anwender bei der steuerrechtlichen Betriebsprüfun. Ergebnisse einer Umfrage im Sep-

tember 2002; PricewaterhouseCoopers Deutsche Revision, Februar 2003. Abrufbar

unter http://www.pwcglobal.com/de/ger/ins-sol/publ/ger_510_GDPdU_Umfrage_Endv

.pdf, abgerufen am 05.06.03.

REGTP (1998): Die digitale Signatur; Hrsg. Referat IS 15, Regulierungsbehörde für

Telekommunikation und Post, 1998. Abrufbar unter http://www.regtp.de/imperia/

md/content/tech_reg_t/digisign/10.pdf, abgerufen am 02.06.03.

RITTGEN (2000): Rittgen P., Quo Vadis EPK in ARIS, Ansätze zur syntaktischen Erwei-

terung und einer formalen Semantik; In: WIRTSCHAFTSINFORMATIK 42 (2000) 1, S.

27-35, Vieweg Verlag, Wiesbaden, 2000.

RUMP (1999): Rump, F., Geschäftsprozessmanagement auf der Basis ereignisgesteuer-

ter Prozessketten, Formalisierung, Analyse und Ausführung von EPKs; Teubner Verlag,

Stuttgart, 1999.


SCHEER (1995): Scheer, A.-W., Referenzmodelle für industrielle Geschäftsprozesse;

Studienausgabe, 2. Auflage, Springer Verlag, Berlin u.a., 1995.

SCHEER (1998): Scheer, A.-W., ARIS-Modellierungsmethoden, Metamodelle, Anwen-

dungen; 3. Auflage, Springer Verlag, Berlin u.a., 1998.

SCHEER ET AL (1995): Scheer, A.-W., Nüttgens, M., Zimmermann, V.: Rahmenkonzept

für ein integriertes Geschäftsprozessmanagement; In: Wirtschaftsinformatik, 37 (1995)

5, S. 426-434.

SCHILLER, VOLLMER (2002): Schiller, J., Vollmer, J., Digitaler Rechnungsversand, eBil-

ling – Intelligentes Redesign ihrer Rechnungsstellung; Abrufbar unter http://www.

competence-site.de/ecommerceshop.nsf/7939D620E936BC56C1256C560043B814/

$File/ebilling_avinci.pdf, abgerufen am 18.05.03.

SCHMITTMANN (2001): Schmittmann, J. M., Der gläserne Steuerpflichtige? - Anmer-

kungen zu den Grundsätzen des BMF zum Datenzugriff und zur Prüfbarkeit digitaler

Unterlagen; In: Die Wirtschaftsprüfung, Heft 19/2001, Essen, 2001.

SEGEV/PORRA/ROLDAN (1997): Segev, A., Porra, J., Roldan, M., Internet-Based EDI

Strategy; Working Paper 97-WP-1021, Haas School of Business, University California

of Berkeley, Berkeley, 1997.

SIEMENS ONLINE-LEXIKON: Online-Lexikon der Siemens AG; Abrufbar unter

http://w3.siemens.de/solutionprovider/_online_lexikon/, abgerufen am 19.05.03.

SIGNATURGESETZ (1997): Gesetz zur Regelung der Rahmenbedingungen für Informati-

ons- und Kommunikationsdienste; Artikel 3 in: Gesetz zur digitalen Signatur, vom 13.

Juni 1997. Bundesgesetzblatt Jahrgang 1997 Teil I S. 1870.

SIGNATURGESETZ (2001): Gesetz über Rahmenbedingungen für elektronische Signatu-

ren und zur Änderung weiterer Vorschriften; Verabschiedet am 16. Mai 2001, veröf-

fentlicht in Bundesgesetzblatt Jahrgang 2001 Teil I Nr.22, S. 876 vom 21. Mai 2001.


SMOLKE, DEITERMANN (1998): Schmolke, S., Deitermann, M., Industrielles Rech-

nungswesen IKR; 26. Auflage, Winklers Verlag, Gebrüder Grimm, Darmstadt, 1998.

SREBNE (2002): Srebne, T., Datenzugriff durch die Außenprüfung – Prüfbarkeit und

Archivierung digitaler Unterlagen; Unveröffentlichter Vortrag SER-Inforum Februar

2002, Frankfurt a. M.

STACH (2003): Stach, C., Rechtliche Anerkennung, kryptographische Algorithme und

praktischer Einsatz der elektronischen Signatur; Unveröffentlichte Diplomarbeit am

Institut für Informatik, Justus-Liebig-Universität Giessen, Juni 2003.

STEFFEN, T. (2000): Steffen, T., XML in der betrieblichen Praxis, d.punkt Verlag, Hei-

delberg, 2000.

STELZER (2002): Stelzer, D., Überbetriebliche Geschäftsprozesse und IV- Integration,

4 Electronic Procurement; Vorlesungsskript Sommersemester 2002, Institut für Wirt-

schaftsinformatik, Technische Universität Ilmenau. Abrufbar unter http://www. wirt-

schaft.tu-ilmenau.de/deutsch/institute/wi/wi3/lehreundforschung/ lehreundforschung13.

html, abgerufen am 13.05.03.

STOETZER (1994): Stoetzer, M.-W., Neue Telekommunikationsdienste: Stand und Per-

spektiven in der deutschen Wirtschaft; In: Ifo-Schnelldienst, Heft 7, S. 8-19, 1994.

STRÖHMER (1997): Ströhmer, T. H., Online-Recht; 1. Auflage, d.punkt-Verlag, Heidel-

berg, 1997.

TC TRUSTCENTER (2001): Sichere Internet Kommunikation mit Zertifikat; Produktin-

formation TC Trustcenter AG, Hamburg, 09/2001. Abrufbar unter http://www.trustcen-

ter.de, abgerufen am 19.05.03.

TUROWSKI, FELLNER (2001): Turowski, K., Fellner, K.-J. (Hrsg.), XML in der betriebli-

chen Praxis - Standards, Möglichkeiten, Praxisbeispiele; xml.bibliothek, dpunkt.verlag,

Heidelberg, Februar 2001.


USTG (2001): Umsatzsteuergesetz, Stand 19. Dezember 2001. Bundesgesetzblatt Teil I

Jahrgang 1999, S. 1270. Zuletzt geändert am 19. Dezember 2001 im Bundesgesetzblatt

Teil I Jahrgang 2001, S. 3922.

V-MODELL: Das V-Modell - Entwicklungsstandard für IT-Systeme des Bundes; Abruf-

bar unter http://www.v-modell.iabg.de, .abgerufen am 27.05.03.

W3C_CSS(2000): Cascading Style Sheets (CSS); Abrufbar unter http://www.w3.org/

Style/CSS/

W3C_DOM(2000): Document Object Model (DOM); Abrufbar unter http://www.w3.

org/DOM/

W3C_ENCRYPTION(2001): XML Encryption; Abrufbar unter http://www.w3.org/

Encryption/2001/

W3C_HTML: Hypertext Markup Language; Abrufbar unter http://www.w3.org/Mar-

kUp/

W3C_Signatur(2002): XML Signature; Abrufbar unter http://www.w3.org/Signature/

W3C_XKMS(2001): XML Key-Management; Abrufbar unter http://www.w3.org/

XKMS/2001/

W3C_XML: Extensible Markup Language (XML); Abrufbar unter http://www.

w3.org/XML/

W3C_XSL(2000): Extensible Stylesheet Language (XSL); Abrufbar unter http://www.

w3.org/Style/XSL/

W3C_XSLT(1999): XSL Transformations (XSLT): Abrufbar unter http://www.w3.org/

TR/xslt


WENDENBURG (2002): Wendenburg, J. C.: Zentrale Signaturprozesse – Automatische

Signaturlösungen mit hohem Investitionsschutz; Vortrag Signaturtage Berlin, 2002. Ab-

rufbar unter http://www.regtp.de/signatur-tage/wendenburg.pdf, abgerufen am 12.05.03.

WYKE (2002): Wyke, R.-A., Fitzgerald, M., Watt, A., XML Schema Essentials; Wiley

XML Essentials, Juli 2002.

ZILAHI -SZABÓ (2001): Zilahi-Szabó, M. G., Qualitätsmanagement für steuerberatende

und prüfende Berufe; 1. Auflage, Deutsches Steuerberatungsinstitut e.V. Berlin, 2001.

ZILAHI -SZABÓ (2002): Zilahi-Szabó, M. G., Geschäftsprozessmodellierung; Lehrveran-

staltung Software-Engineering, Wintersemester 2002/2003, Institut für Informatik, Jus-

tus-Liebig Universität Giessen.

ZPO (2001): Zivilprozessordnung (ZPO), Beck Texte im dtv, 33. Auflage, 2001.

ZUMPE, ESSWEIN (2002): Zumpe, S., Esswein, W.: Konzeptuale Schnittstellenanalyse

von eCommerce-Applikationen; Dresdner Beiträge zur Wirtschaftsinformatik 36/02.

Anhang 149

Anhang

A 1 Umsatzsteuergesetz § 14 und § 15 Abs. 1

[Umsatzsteuergesetz, Stand 19. Dezember 2001. Bundesgesetzblatt Teil I Jahrgang

1999, S. 1270. Zuletzt geändert am 19. Dezember 2001 im Bundesgesetzblatt Teil I

Jahrgang 2001, S. 3922]

§ 14 UStG Ausstellung von Rechnungen

(1) Führt der Unternehmer steuerpflichtige Lieferungen oder sonstige Leistungen nach §

1 Abs. 1 Nr. 1 aus, so ist er berechtigt und, soweit er die Umsätze an einen anderen Un-

ternehmer für dessen Unternehmen ausführt, auf Verlangen des anderen verpflichtet,

Rechnungen auszustellen, in denen die Steuer gesondert ausgewiesen ist. Diese Rech-

nungen müssen die folgenden Angaben enthalten:

1. den Namen und die Anschrift des leistenden Unternehmers,

2. den Namen und die Anschrift des Leistungsempfängers,

3. die Menge und die handelsübliche Bezeichnung des Gegenstandes der Lieferung oder

die Art und den Umfang der sonstigen Leistung,

4. den Zeitpunkt der Lieferung oder der sonstigen Leistung,

5. das (Netto-) Entgelt für die Lieferung oder sonstige Leistung (§ 10) und

6. den auf das Entgelt (Nummer 5) entfallenden Steuerbetrag.

In den Fällen des § 10 Abs. 5 sind die Nummern 5 und 6 mit der Maßgabe anzuwenden,

dass die Bemessungsgrundlage für die Leistung (§ 10 Abs. 4) und der darauf entfallende

Steuerbetrag anzugeben sind. Unternehmer, die § 24 Abs. 1 bis 3 anwenden, sind jedoch

auch in diesen Fällen nur zur Angabe des Entgelts und des darauf entfallenden Steuer-

betrags berechtigt. Vereinnahmt der Unternehmer das Entgelt oder einen Teil des Ent-

gelts für eine noch nicht ausgeführte steuerpflichtige Lieferung oder sonstige Leistung,

so gelten die Sätze 1 und 2 sinngemäß. Wird eine Endrechnung erteilt, so sind in ihr die

vor Ausführung der Lieferung oder sonstigen Leistung vereinnahmten Teilentgelte und

die auf sie entfallenden Steuerbeträge abzusetzen, wenn über die Teilentgelte Rechnun-

gen im Sinne des Satzes 2 ausgestellt worden sind.

[Mit Inkrafttreten des Steuerverkürzungsbekämpfungsgesetz am 01.01.2002 wurde das

geltende UStG um folgenden Abs. 1a ergänzt.]

Anhang 150

(1a) Der leistende Unternehmer hat in der Rechnung die ihm vom Finanzamt erteilte

Steuernummer anzugeben.

(2) Hat der Unternehmer in einer Rechnung für eine Lieferung oder sonstige Leistung

einen höheren Steuerbetrag, als er nach diesem Gesetz für den Umsatz schuldet, geson-

dert ausgewiesen, so schuldet er auch den Mehrbetrag. Berichtigt er den Steuerbetrag

gegenüber dem Leistungsempfänger, so ist § 17 Abs. 1 entsprechend anzuwenden.

(3) Wer in einer Rechnung einen Steuerbetrag gesondert ausweist, obwohl er zum ge-

sonderten Ausweis der Steuer nicht berechtigt ist, schuldet den ausgewiesenen Betrag.

Das gleiche gilt, wenn jemand in einer anderen Urkunde, mit der er wie ein leistender

Unternehmer abrechnet, einen Steuerbetrag gesondert ausweist, obwohl er nicht Unter-

nehmer ist oder eine Lieferung oder sonstige Leistung nicht ausführt.

(4) Rechnung ist jede Urkunde, mit der ein Unternehmer oder in seinem Auftrag ein

Dritter über eine Lieferung oder sonstige Leistung gegenüber dem Leistungsempfänger

abrechnet, gleichgültig, wie diese Urkunde im Geschäftsverkehr bezeichnet wird. Als

Rechnung gilt auch eine mit einer digitalen Signatur nach dem Signaturgesetz vom

22.07.1997 (BGBl. I S. 1870, 1872) in der jeweils geltenden Fassung versehene elekt-

ronische Abrechnung.

(5) Als Rechnung gilt auch eine Gutschrift, mit der ein Unternehmer über eine steuer-

pflichtige Lieferung oder sonstige Leistung abrechnet, die an ihn ausgeführt wird. Eine

Gutschrift ist anzuerkennen, wenn folgende Voraussetzungen vorliegen:

1. Der leistende Unternehmer (Empfänger der Gutschrift) muss zum gesonderten Aus-

weis der Steuer in einer Rechnung nach Absatz 1 berechtigt sein.

2. Zwischen dem Aussteller und dem Empfänger der Gutschrift muss Einverständnis

darüber bestehen, dass mit einer Gutschrift über die Lieferung oder sonstige Leistung

abgerechnet wird.

3. Die Gutschrift muss die in Absatz 1 Satz 2 vorgeschriebenen Angaben enthalten.

4. Die Gutschrift muss dem leistenden Unternehmer zugeleitet worden sein.

Die Sätze 1 und 2 sind auf Gutschriften sinngemäß anzuwenden, die der Unternehmer

über das für eine noch nicht ausgeführte steuerpflichtige Lieferung oder sonstige Leis-

tung entrichtete Entgelt oder Teilentgelt ausstellt. Die Gutschrift verliert die Wirkung

Anhang 151

einer Rechnung, soweit der Empfänger dem in ihr enthaltenen Steuerausweis wider-

spricht.

(6) Das Bundesministerium der Finanzen kann mit Zustimmung des Bundesrates zur

Vereinfachung des Besteuerungsverfahrens durch Rechtsverordnung bestimmen, in

welchen Fällen und unter welchen Voraussetzungen

1. als Rechnungen auch andere Urkunden anerkannt werden können,

2. auf einzelne Angaben bei der Ausstellung von Rechnungen (Absatz 1) verzichtet

werden kann oder

3. eine Verpflichtung des Unternehmers zur Ausstellung von Rechnungen mit gesonder-

tem Steuerausweis (Absatz 1) entfällt.

§ 15 UStG Vorsteuerabzug Abs. 1

(1) Der Unternehmer kann die folgenden Vorsteuerbeträge abziehen:

1. die in Rechnungen im Sinne des § 14 gesondert ausgewiesene Steuer für Lieferungen

oder sonstige Leistungen, die von anderen Unternehmern für sein Unternehmen ausge-

führt worden sind. Soweit der gesondert ausgewiesene Steuerbetrag auf eine Zahlung

vor Ausführung dieser Umsätze entfällt, ist er bereits abziehbar, wenn die Rechnung

vorliegt und die Zahlung geleistet worden ist;

2. die entrichtete Einfuhrumsatzsteuer für Gegenstände, die für sein Unternehmen in das

Inland eingeführt worden sind oder die er zur Ausführung der in § 1 Abs. 3 bezeichne-

ten Umsätze verwendet;

3. die Steuer für den innergemeinschaftlichen Erwerb von Gegenständen für sein Unter-

nehmen. Nicht als für das Unternehmen ausgeführt gilt die Lieferung, die Einfuhr oder

der innergemeinschaftliche Erwerb eines Gegenstandes, den der Unternehmer zu weni-

ger als 10 vom Hundert für sein Unternehmen nutzt.

Anhang 152

A 2 Erklärungen zum V-Modell223

Das V-Modell stellt einen international anerkannten Entwicklungsstandard für IT-

Systeme dar. Darin ist festgelegt, was zu tun ist, wie die Aufgaben auszuführen sind und

womit dies zu geschehen hat.

Es gliedert sich dementsprechend in folgende Bereiche:

• Das Vorgehensmodell (Was)

• Die Methodenzuordnung (Wie)

• Die Funktionalen Werkzeuganforderung (Womit)

Das Vorgehensmodell enthält die verbindlichen Regelungen für die durchzuführenden

Arbeitsschritte (Aktivitäten) und Ergebnisse (Produkte), grafisch dargestellt in Form

eines "V".

Interpretiert wird das grafische Modell von links nach rechts entlang des "V". Der linke

Arm wird von oben nach unten, der rechte von unten nach oben gelesen. Die Ausprä-

gungen der Arbeitsschritte werden auf der linken Seite (von oben nach unten) immer

detaillierter und rechts (von unten nach oben) immer komplexer. Die Spitze des "V"

kann als Übergang von der Entwicklung in die praktische Umsetzung interpretiert wer-

den.

Die Besonderheit des Vorgehensmodells ist, dass sich gegenüberliegende Arbeitsschrit-

te gegenseitig beeinflussen. So können die Ergebnisse der Umsetzung rechts zu einer

Überarbeitung der Entwicklung auf der linken Seite führen und diese wiederum zu neu-

en praktischen Ergebnissen. Es besteht demnach eine Interaktion zwischen Entwicklung

und Anwendung vom ersten Einzeltest eines Systembausteins bis hin zur vollständigen

System-Einführung.

Ursprünglich entwickelt wurde das V-Modell im Auftrag des Bundesministeriums für

Verteidigung (BMVg) in Zusammenarbeit mit dem Bundesamt für Wehrtechnik und

Beschaffung (BWB) von der Industrieanlagen-Betriebsgesellschaft mbH (IABG) in

Ottobrunn bei München. Das Bundesministerium des Inneren (BMI) übernahm 1992

das V-Modell für den Bereich der Bundesverwaltung, dort ist es seit Juni 1996 eine ver-

bindlich einzusetzende Vorschrift.

223

http://www.v-modell.iabg.de

Anhang 153

A 3 Übersicht der EPK-Verknüpfungsarten

Verknüpfungs-operatoren

Verknüpfungsart

Entweder/Oder

Und Und/Oder

Ereignis-typver-

knüpfung

Funktions-typver-

knüpfung

AuslösendeEreignis-

typen

AuslösendeEreignis-

typen

ErzeugteEreignis-

typen

ErzeugteEreignis-

typen

= Ereignis

= Funktion= nicht erlaubt

F

E

E

E

F

E

E

F

E

E

F

E

E

F

E

E

F

E

E

F

E

E

F

E

E

F

E

E

F

F

F

E

F

F

E

F

F

E

Abbildung A 1: EPK-Verknüpfungsarten224

224

Vgl. Keller et al. (1992) Seite 14

Anhang 154

A 4 Erklärung der EDIFACT Beispiel-Rechnung

Die Kopfzeilen der Tabellen enthalten das jeweils zu erklärende EDIFACT-Segment. In

den folgenden Zeilen stehen sich die zugehörigen Datenelemente und/oder Datenele-

mentgruppen (links) mit ihren Erklärungen (rechts) gegenüber.

Zunächst werden die Trennzeichen definiert:

UNA:+,?' : Gruppendatenelement-Trennzeichen + Datenelement-Trennzeichen , Dezimal-Zeichen ? Release-Zeichen (hebt Bedeutung von Sonderzeichen auf) ' Segmentende-Zeichen

Es folgt das Servicedatensegment UNB mit Informationen für den Daten-Transfer:

UNB+UNOA:2+PCPROFI+MAXMUSTER+020604:1135+0206041135’ UNOA:2 Zeichensatz PCPROFI Vereinbarte Absender-Kennung MAXMUSTER Vereinbarte Empfänger-Kennung 020604:1135 Datum und Zeit der Übertragung 0206041135 Sender-Interne Übertragungsnummer

Erst jetzt beginnt die Nachricht INVOIC:

Zu Beginn die Nutzdaten der Nachricht:

UNH+INVOIC0001+INVOIC:D:93A:UN' INVOIC0001 Interne Nummer der Rechnung (nicht die Rechnungsnummer) INVOIC:D:93A:UN' Nachrichtentyp, Standard, Kontrollinstanz (UN)

Die Rechnungsnummer wird nun im BGM-Segment angegeben:

BGM+380+0206003+9’ 380 Qualifier: 380=Rechnung, 381=Gutschrift 0206003 Rechnungsnummer 9 9=Original (kein Duplikat / Kopie)

Das Rechnungsdatum steht im folgenden DTM-Segment:

DTM+3:20020603:102' 3 Spezifiziert das Datum als Rechnungsdatum 20020603 Rechnungsdatum 102 Format CCYYMMDD

Es folgt die referenzierte Bestellnummer und das Datum der Bestellung:

RFF+ON:15491' ON ON=Order number (Bestellnummer) 15491 Bestellnummer

Anhang 155

DTM+4:20020530:102' 4 Spezifiziert das Datum als Bestelldatum 20020530:102 Bestelldatum im Format CCYYMMDD

Nun folgen Angaben zu Namen und Adresse:

NAD+SE+++PC Profi+Parkstrasse 14+Giessen++35390' SE Spezifiziert Adresse als Adresse des Verkäufers

NAD+BY+++Max Muster+Schlossallee 20+Weilburg++35781 ' BY Spezifiziert Adresse als Adresse des Käufers

Die Daten der Bankverbindung werden mit dem FII-Segment übertragen:

FII+PE+246217:PCBOERSE+51960815:28:::::Dresdner Ban k Giessen' PE Spezifiziert Konto des Verkäufers 246217:PCBOERSE Konto-Nummer, Inhaber 51960815:28:::::Dresdner Bank Giessen

Bankleitzahl, Name der Bank

Es folgen Währungsangaben:

CUX+:EUR' EUR Währung (Euro)

Der Kopf der Rechnung ist nun vollständig. Es beginnt die Auflistung der Rechnungs-

positionen. Hier wird nur die erste Rechnungsposition genau erklärt, 2.-4. sind analog.

LIN+1++4711.236’ 1 Artikel-Position 4711.236 Artikel-Nummer

IMD+F++:::19?’?’ Flachbildschirm’ F Spezifiziert Typ der Produktbeschreibung 19?’?’ Flachbildschirm’ Freie Produktbeschreibung

QTY+47:1:PCE’ 47 Spezifiziert die in Rechnung gestellte Anzahl (Quantity) 1 Anzahl 1 PCE Maßeinheit: Stück

MOA+66:820’ 66 Spezifiziert den Betrag als Gesamtsumme dieser Rechnungs-Position 820 Betrag der Rechnungs-Position

PRI+AAA:820’ AAA Spezifiziert Preis als Einzelpreis 820 (Netto-)Preis

Anhang 156

Die Detailangaben (sprich Rechnungspositionen) sind nun vollständig definiert.

Es folgt Beschreibung der Summensektion:

UNS+S' S Markiert den Übergang zur (S)ummensektion

Das MOA Segment bildet die Rechnungsendbeträge ab:

Netto-Gesamtbetrag:

MOA+79:951,37’ 79 Spezifiziert den Betrag als Gesamtsumme der Rechnungs-Positionen 951,37 Gesamtsumme der Rechnungs-Positionen

Steuerbetrag:

MOA+124:152,21’ 124 Spezifiziert den Betrag als Steuerbetrag 152,21 Steuerbetrag

Gesamtbetrag inklusive Umsatzsteuer:

MOA+128:1103,58’ 128 Spezifiziert den Betrag als den zu zahlenden Gesamtbetrag 1103,58 Gesamtbetrag inklusive Umsatzsteuer

Angaben zum Steuersatz:

TAX+7+VAT+++:::16+S’ 7 Spezifiziert eine gesetzlich zu erhebende Steuer VAT Steuertyp: Umsatzsteuer (Value Added Tax) 16 Prozentsatz (16%) S Definiert den Prozentsatz als Standardprozentsatz

Die Nachricht ist nun vollständig und wird mit dem UNT Segment abgeschlossen.

Dieses Segment dient als interne Kontrollinstanz:

UNT+36+INVOIC0001' 36 Anzahl der Segmente in der Nachricht (einschließlich UNH- und UNT-Segment) INVOIC0001 Interne Nachrichtennummer (muss mit der Nummer im UNH-Segment übereinstimmen)

Letztlich der Abschluss der Übertragungsdatei.

Das UNZ-Segment komplettiert den Nutzdatenrahmen:

UNZ+1+0206041135' 1 Anzahl der Nachrichten in der Übertragungsdatei (hier: 1) 0206041135 Sender-interne Übertragungsnummer (muss mit der Nummer im UNB-Segment über-

einstimmen)

Erklärung 157

Erklärung

Hiermit versichere ich, dass ich die Arbeit selbstständig verfasst

und keine anderen als die angegebenen Hilfsmittel verwandt und

die Stellen, die anderen Werken im Wortlaut oder dem Sinne

nach entnommen sind, mit Quellenangaben kenntlich gemacht

habe.

______________________________ Braunfels-Tiefenbach, im Juni 2003

DIPLOMARBEIT Anforderungen, Potentiale und technische ... · Fachbereich Mathematik und Informatik,...

Documents

Transcript of DIPLOMARBEIT Anforderungen, Potentiale und technische ... · Fachbereich Mathematik und Informatik,...