Diplomarbeit Erkel - Forum Elektronische Steuerprüfung

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

2.1 Grundlegende Begriffe 5
Allgemein:
Beispiel:
Ziel
Erstellung/
Verkauf von
Dienstleistungen/
Produkten
Prozesskette
Beschaffung von
Ressourcen
Bereitstellung/
Lagerung von
Ressourcen
Geschäftsprozess
Unternehmen
Prozesskette
Einsatz der
Ressourcen/
Produktion
Prozesskette Ergebnis
Vertrieb der
Dienstleistungen/
Produkte
Abbildung 2.1: Vom Ziel zum Ergebnis eines Geschäftsprozesses 4
Dienstleistungen/
Produkte erstellt
und verkauft
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

2.1 Grundlegende Begriffe 6
Die folgende Abbildung verdeutlicht die Verfeinerung des Geschäftsprozesses "Rech-
nungseingang".
Geschäftsprozess Prozessketten Arbeitsprozesse Vorgänge
Rechnungseingang
Rechnungseingang
registrieren
Rechnung prüfen
Rechnungsgsdaten
erfassen
Rechnung
verbuchen
Rechnung
archivieren
Rechnungskopf-
Daten erfassen
Rechnungspositionen
erfassen
Abbildung 2.2: Hierarchische Unterteilung eines Geschäftsprozesses 6
Einzelbetrag
erfassen
Menge erfassen
Gesamtbetrag
erfassen
Steuersatz
erfassen
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.
6 Vgl. 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
Strategischer
Entscheidungsprozess
Festlegung der strategischen Vorgaben
Gestaltungsprozess
(Modellbasierte) Gestaltung von
Geschäftsprozessen, Organisation und
Produkten
Umsetzungsprozess
Organisation
Informationstechnologie
Ausführungsprozess
Durchführung der Geschäftsprozesse
(und „EDV-Betrieb“)
liefert
führt wieder zu
Evaluationsprozess
Evaluation von Geschäftsprozessen,
Organisation und Produkten
Operative
Daten
Abbildung 2.3: Konzept des Geschäftsprozessmanagements 8
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-Modells 9 ) beschrieben
werden kann:
Festlegung der
Zielsetzung
Anforderungsdefinition
Geschäftsprozessmodellierung/
Prozessentwurf
Teilprozessmodellierung/
Teilprozessentwurf
Testfälle
Validierung der Zielsetzung
Testfälle
Anforderungsvalidierung
Testfälle
Restrukturierung
Testfälle
Testlauf
Einzeltest
Betrieb
Einführung
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
t

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 beispielsweise 10
10 Vgl. KÜHN, KARAGIANNIS (2001), S. 5, vgl. JUNGINGER (2000), S. 11-12

2.3 Geschäftsprozessmodellierung 10
• 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

2.3 Geschäftsprozessmodellierung 11
Startzustand: Elektronisch signierte Datei empfangen
Aufspaltung
Zusammenführung
Datei akzeptieren
Endzustand: Datei akzeptiert
Aktivität
Entscheidung
Zertifikate prüfen
[korrekt]
[korrekt]
Datei als geprüft
markieren
Signatur prüfen
[fehlerhaft]
Datei ablehnen
[fehlerhaft]
Datei ablehnen
Endzustand: Datei abgelehnt
Endzustand: Datei abgelehnt
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 -Toolset 15 , Bonapart 16 und 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äftsprozessmanagements 19
17 Vgl. Merzenich (2002), S. 38
18 Vgl. Merzenich (2002), S. 33
19 Merzenich (2002), S. 33, nach GAITANIDES ET AL (1994), S. 16

2.4 Geschäftsprozessanalyse und -optimierung 13
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 Geschäftsprozessanalyse und -optimierung 14
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

2.4 Geschäftsprozessanalyse und -optimierung 15
• 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

2.4 Geschäftsprozessanalyse und -optimierung 16
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

3.1 Elemente und Verknüpfungen 18
§ 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)
Disjunktion
(ENTWEDER/ODER-Verknüpfung)
Adjunktion
(ODER-Verknüpfung)
Tabelle 3.1: EPK-Verknüpfungsoperatoren
a und b
Entweder a
oder b
[a oder b] oder
[a und b]
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

3.1 Elemente und Verknüpfungen 19
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.
Rechnungsdaten
NICHT OK
Rechnungsdaten
überarbeiten
Rechnungsdaten
überarbeitet
31 Vgl. ZILAHI-SZABÓ (2002), S. 35
Rechnungserstellung
erforderlich
Rechnungsdaten
erfassen
Rechnungsdaten
vollständig
Rechnungsdaten
prüfen
Rechnungsdaten
OK
Rechnungsformular
erstellen
Rechnungsformular
erstellt
Legende:
Ereignis
Prozess/Funktion
Prozesswegweiser
Kontrollfluß
Abbildung 3.1: Modell der Rechnungserstellung in EPK-Notation 31

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:
Mitarbeiter
Abteilung
EDV-Anwendung
(z.B. Exel)
Legende:
Datenbank
Anwendungssystem
Mitarbeiter
Abteilung
EDV-Anwendung
(z.B. Exel)
Datensatz
Rechnungsdaten
NICHT OK
Rechnungsdaten
überarbeiten
Rechnungsdaten
überarbeitet
Datei
Organisationseinheit
Rechnungsstellung
erforderlich
Rechnungsdaten
erfassen
Rechnungsdaten
vollständig
Rechnungsdaten
prüfen
Papier-
Dokument
Datenfluß,
Ressourcen
Interne
Datenbank
Auftrag
Bestellung
...
Rechnungsdaten
Rechnungsdaten
OK
Rechnungsformular
erstellen
Rechnungsformular
erstellt
(Papier-)
Ordner
Abbildung 3.2: Darstellung einer Rechnungserstellung durch eEPK
Rechnungsdaten
Rechnungsformular

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-Algorithmus 42 (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 Rechtliche Grundlagen 26
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 Software 49 ). 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/

4.3 Rechtliche Grundlagen 27
• 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 Rechtliche Grundlagen 28
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-
pel 50 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.

4.3 Rechtliche Grundlagen 29
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

4.4 Das Signatur-Verfahren aus Sicht des Anwenders 31
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
231C-12 Tintenpatrone HP
23A
16S-11 Pack Kopierpapier
DIN A4 weiß 80g
345R-23 Pack Folienstifte
bunt
129A-1 Halogen-Lampe
"Jojo", rot
2 129,90 259,80
3 36,90 110,70
12 5,99 71,88
1 8,59 8,59
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
Originaldokument
Passwort (PIN) des Absenders
52 Vgl. DATEV E:SECURE
Hashfunktion
Signatursoftware
-----BEGIN HASH----d5da3783ea26bc60f4b758
4df4227866
=8S8V
-----END HASH-----
SmartCard
Asymmetrische
Verschlüsselung
Privater Schlüssel
Qualifiziertes
Zertifikat
Qualifiziert elektronisch
signiertes Dokument
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
231C-12 Tintenpatrone HP
23A
16S-11 Pack Kopierpapier
DIN A4 weiß 80g
345R-23 Pack Folienstifte
bunt
129A-1 Halogen-Lampe
"Jojo", rot
2 129,90 259,80
3 36,90 110,70
12 5,99 71,88
1 8,59 8,59
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 SIGNATURE-----
Version: 7.3
fgTz78HGbnmja2T546hj09LK23
5473Ghnbv778BG5123fgGhK9=
=234thT
-----END SIGNATURE-----
Abbildung 4.1: Erstellen einer qualifizierten elektronischen Signatur 52

4.4 Das Signatur-Verfahren aus Sicht des Anwenders 32
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.).

4.4 Das Signatur-Verfahren aus Sicht des Anwenders 33
Qualifiziert elektronisch
signiertes Dokument
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
231C-12 Tintenpatrone HP
23A
16S-11 Pack Kopierpapier
DIN A4 weiß 80g
345R-23 Pack Folienstifte
bunt
129A-1 Halogen-Lampe
"Jojo", rot
2 129,90 259,80
3 36,90 110,70
12 5,99 71,88
1 8,59 8,59
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 SIGNATURE-----
Version: 7.3
fgTz78HGbnmja2T546hj09LK23
5473Ghnbv778BG5123fgGhK9=
=234thT
-----END SIGNATURE-----
Hashfunktion
Signatur-Prüfsoftware
-----BEGIN HASH----d5da3783ea26bc60f4b758
4df4227866
=8S8V
-----END HASH-----
Entschlüsselung
-----BEGIN HASH----d5da3783ea26bc60f4b758
4df4227866
=8S8V
-----END HASH-----
Öffentlicher Schlüssel
des Absenders
Abbildung 4.2: Lokale Signaturprüfung mit einer Signatur-Prüfsoftware
Vergleich
Ergebnis der
Signaturprüfung
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 Rechnungsstellung
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 Die Rechnung im deutschen Umsatzsteuerrecht 35
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

5.1 Die Rechnung im deutschen Umsatzsteuerrecht 36
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.
Das Umsatzsteuersystem mit Vorsteuerabzug
aus der Perspektive eines Unternehmens
Weiterverarbeitung
Abbildung 5.1: Das Umsatzsteuersystem aus der Perspektive eines Unternehmens 61
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

5.1 Die Rechnung im deutschen Umsatzsteuerrecht 37
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
Material- Nettowert 1500,00
Herstellung + 16% USt 240,00
↓ Rechnungspr. 1740,00
Weiterverarbei- Nettowert 7000,00
tende Industrie + 16% USt 1120,00
↓ Rechnungspr. 8120,00
Großhandel
↓
Nettowert 8900,00
+ 16% USt 1424,00
Rechnungspr. 10342,00
Einzelhandel Nettowert 10000,00
↓ + 16% USt 1600,00
Endverbraucher Rechnungspr. 11600,00
Tabelle 5.1: Vierstufige Warenweg mit Vorsteuerabzug 62
240,00 - 240,00
1120,00 240,00 880,00
1424,00 1120,00 304,00
1600,00 1424,00 176,00
Probe: 4384,00 – 2784,00 = 1600,00
Verbindlichk.– Gutschrift = Zahllast
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

5.1 Die Rechnung im deutschen Umsatzsteuerrecht 38
• 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) entsprechend 65 ) 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)

5.1 Die Rechnung im deutschen Umsatzsteuerrecht 39
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

5.3 Anforderungen der Finanzbehörden 42
• 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

5.3 Anforderungen der Finanzbehörden 43
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 Anforderungen der Finanzbehörden 44
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-
pario 75 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:
76 Siehe EU-RICHTLINIE (2001/115/EG)
§ 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.

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 Rechnungsstellung
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 Rechnungsstellers
(Kreditor) an Erstellung
und Übermittlung einer Rechnung:
1) Niedrige Kosten
2) Hohe Transportgeschwindigkeit
3) Zuverlässigkeit
4) Nachweisbarkeit des Rechnungszugangs
5) Datenschutz
6) Einsatz der Rechnung als Marketinginstrument
Anforderungen aus Sicht des Rechnungsempfängers
(Debitor) an Rechnungseingang
und Weiterverarbeitung:
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-Bereich 80
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.
Rechnungsaussteller
M ahnung erstellt
Erstellung einer
M ahnung
Nicht OK OK
Rechnungsem
pfänger
Bank(en)
Prüfung
Reklam ation
eingegangen
Rechnungsdaten
Rechnungsdaten
Auftragsdaten
Reklamation
82 Vgl. EICKER, SCHWICHTENBERG (1999), S. 150
Prozeß-Start
Rechnungsstellung
erforderlich
Erstellung der
Rechnung
Rechnung erstellt
Versand
Rechnung
Rechnung
eingegangen
Datenerfassung
Daten erfasst
Prüfung
Nicht O K O K
Verbuchen und
Zahlung einleiten
Nein Ja
Zahlungsdaten
Zahlungsdaten
Leistungsdaten
W ahl der
Zahlungsmethode
Auftrag
Eingang des
Zahlungsauftrags
Datenerfassung
Daten erfasst
Geldtransfer
Kundenkontostand
Rechnung
archivieren
Rechnung
archiviert
Zahlungsmittel
Nicht O K
Prozeß-Ende
O K
Ermächtigung
weiterleiten
Eingang der
Ermächtigung
Erm ächtigung
Abbildung 6.1: Vereinfachter Rechnungsprozess 82
Erm ächtigung,
Auftrag
Kundenkontostand
Abgleich m it
Rechnungsdaten
Zahlung
verbucht
Zahlung
verbuchen
Eingang der
Zahlung

6.3 Modellierung des IST-Modells 51
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.

Rechnungssteller
Mitarbeiter
Vertrieb/
Buchhaltung
EDV-
Anwendung
(z.B. Excel)
EDV-
Anwendung
(z.B. Excel)
EDV-
Anwendung
(z.B. Excel)
Verantwortlicher
Vertrieb/
Buchhaltung
Rechnungserstellung
erforderlich
Rechnungsdaten
erfassen
Rechnungsdaten
erfaßt
Rechnungsformular
erstellen
Rechnungsformular
erstellt
Rechnungsformular
drucken
Rechnung
gedruckt
Rechnung
unterschreiben
(Papier-)
Rechnung erstellt
Rechnung zum
Versand freigeben
IST-Modell: Prozessablauf Rechnungssteller
2-5 min
1-2 min
Kundendaten
Leistungsdaten
Rechnungs
-daten
Rechnungsformular
1-2 min Rechnung
Rechnung
Rechnung
Interne
Datenbank
Mitarbeiter
Vertrieb/
Buchhaltung
Abbildung 6.2: Rechnungserstellung und -versand in Papierform
R. zum Versand
freigegeben
Rechnung
kuvertieren
Rechnung
kuvertiert
Rechnung
freistempeln
Rechnung ist
versandfertig
Rechnung
versenden
Rechnung ist
versendet
Postausgang
registrieren
Postausgang
registriert
1-2 min
1 min
1-3 Tage
2-3 min
Rechnung
Rechnungsbrief
Rechnungsbrief
Post
Postausgangsbuch
6.3 Modellierung des IST-Modells 52

Nr. Prozess/Funktion
Bearbeitungszeit
(min)
IST-Modell: Prozessbeschreibung Rechnungssteller
∅ Sachkosten
1 Rechnungsdaten erfassen 2-5 -
2 Rechnungsformular
erstellen
3 Rechnungsformular
drucken
Automatisch -
4 Rechnung unterschreiben 1-2 -
5
Rechnung zum Versand
freigeben
Beteiligte Stelle
Vertrieb/Buchhaltung,
Mitarbeiter
Vertrieb/Buchhaltung,
Mitarbeiter
1-2 0,30€ Vertrieb/Buchhaltung,
Mitarbeiter
- -
Vertrieb/Buchhaltung,
Verantwortlicher
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 - -
9 Postausgang registrieren 1-3 -
Gesamt
7-15
∅11
Tabelle 6.2: Prozessbeschreibung IST-Modell Rechnungssteller
Externes Dienstleistungsunternehmen
(z.B. Deutsche Post)
Vertrieb/Buchhaltung,
Mitarbeiter
IT-System-
Unterstützung
EDV-Anwendung
(z.B. Excel), Datenbank
EDV-Anwendung
(z.B. Excel)
EDV-Anwendung
(z.B. Excel), Drucker
1,55€ 3 (davon 1 extern) Nur eingeschränkt
-
-
-
-
-
-
Schwachstellen/
Probleme
Medienbruch:
Elektronische Daten→
Daten auf Papier
Lange Postlaufzeit
(min. 1-3 Tage Inland)
Langsamer Prozessablauf,
Medienbruch
6.3 Modellierung des IST-Modells 53

6.3 Modellierung des IST-Modells 54
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.

6.3 Modellierung des IST-Modells 55
Rechnungsempfänger
Mitarbeiter
Buchhaltung/
Rechnungswesen
EDV-
Anwendung
(z.B. Access)
EDV-
Anwendung
(z.B. Access)
IST-Modell: Prozessablauf Rechnungsempfänger
Rechnung
eingegangen
Rechnungseingang
registrieren
Rechnungseingang
registriert
(Interne) Belegnummer
zuweisen
Belegnummer
zugewiesen
Rechnungsdaten
erfassen
Rechnungsdaten
erfaßt
Rechnungsprüfung
1 - 2 min
5 - 25 min
Nicht OK OK
Reklamation,
Klärungsvorgang
1 min
Verbuchen und
Zahlung einleiten
Rechnung
Posteingangsbuch
Rechnung
Rechnung
Rechnungs
-daten
Wareneingangsdaten
Rechnung
archivieren
Rechnung
archiviert
Interne
Datenbank
2 - 3 min Interne
Auftragsdaten
Datenbank
3 - 5 min
Abbildung 6.3: Eingang und Weiterverarbeitung einer Papierrechnung
Rechnung
Aktenordner
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.

Nr. Prozess/Funktion
1
2
Rechnungseingang registrieren
Rechnung interne Belegnummerzuweisen
Bearbeitungszeit
(min)
1-2
3 Rechnungsdaten erfassen 5-25
4 Rechnungsprüfung 2-3
5 Rechnung archivieren 3-4
Gesamt
1
12-35
∅24
Tabelle 6.3: Prozessbeschreibung IST-Modell Rechnungsempfänger
IST-Modell: Prozessbeschreibung Rechnungsempfänger
Beteiligte Stelle
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
IT-System-
Unterstützung
EDV-Anwendung,
Datenbank
EDV-Anwendung,
Datenbank
1 Nur eingeschränkt
-
-
-
Schwachstellen/Probleme
Medienbruch: Daten auf Papier →
elektronische Daten,
Manuelle Erfassung: hoher Zeitaufwand,
eintönig und fehleranfällig
Manuelle (Papier-) Archivierung:
großer Platzbedarf, lange Zugriffzeiten
Zeit- und kostenaufwändige manuelle
Prozesse, hohe Fehlerrate
6.3 Modellierung des IST-Modells 56

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 Vgl. EICKER, SCHWICHTENBERG (1999), S. 151

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
Unternehmen A
Finanzen
Beschaffung
Fertigung
Distribution
Marketing/Vertrieb
„EDI“
Austausch strukturierter Geschäftsdaten
in standardisierten Formaten
von Anwendung zu Anwendung
über öffentliche und private Netze.
Abbildung 7.1: Electronic Data Interchange (EDI) 86
Unternehmen B
Finanzen
Beschaffung
Fertigung
Distribution
Marketing/Vertrieb
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/EDIFACT 90 (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/ECE 91 . Inzwischen ist EDIFACT zu einer ISO 92 - und einer DIN 93 -
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

7.3 Die EDIFACT–Nachricht 63
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

7.3 Die EDIFACT–Nachricht 64
Abbildung 7.2: Darstellung der EDIFACT–Hierarchie 98
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

7.3 Die EDIFACT–Nachricht 65
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

7.3 Die EDIFACT–Nachricht 66
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 - Übertragungsdatei 102
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

7.3 Die EDIFACT–Nachricht 67
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

7.3 Die EDIFACT–Nachricht 68
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 Bank 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 Vgl. DEUTSCH (1994), S. 58

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 Vgl. DEUTSCH (1994), S. 61

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

7.6 EDI in der Praxis 72
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

7.6 EDI in der Praxis 73
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 Transfer
Protocol
(SMTP)
Multipurpose Internet
Mail Extensions
(MIME)
File Tranfer
Protocol
(FTP)
HyperText Transfer
Protocol
(HTTP)
HyperText Markup
Language
(HTML)
Abbildung 8.1: Dienste und Protokolle für EDI über das Internet 119
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 (2001), S. 8
118 Vgl. BUXMANN ET AL (1998), S. 3
119 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 Vgl. BUXMANN ET AL (1998), S. 7

8.2 XML-basierter Datenaustausch 78
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-
mendation 125 ("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
Titel 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)

8.2 XML-basierter Datenaustausch 79
• 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 Vgl. BUXMANN ET AL (2001), S. 18

8.2 XML-basierter Datenaustausch 80
komplex
einfach
Daten
HTML
XML
SGML
grob fein
Struktur
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)

8.2 XML-basierter Datenaustausch 81
Inhalt
Formatierung
Präsentation
Struktur
Abbildung 8.3: XML-Sprachkonzept 135
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
136 Vgl. BUXMANN ET AL (2001), S. 19, nach BOSAK, J. (1997)

8.2 XML-basierter Datenaustausch 82
(Name und Anschrift), wie sie beispielsweise in einer Rechnung benötigt werden, in
HTML und XML dargestellt:
HTML (person.html) XML (person.xml)
Herr Max Muster
Musterstrasse 20,
1000 Musterstadt
Tabelle 8.1: Vergleich HTML-/XML-Dokument
Herr
Max
Muster
Musterstrasse
20
1000
Musterstadt
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
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-

8.2 XML-basierter Datenaustausch 83
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:
NAME
PERSON
ADRESSE
ANREDE VORNAME NACHNAME STRASSE HAUSNR PLZ
Herr
Max
Muster
Musterstrasse
20
1000
Abbildung 8.4: XML-Tree zum XML-Dokument in Tabelle 8.1
8.2.3 Wohlgeformte XML-Dokumente
Element
ORT
Wert
Musterstadt
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: .
• Jeder geöffnete Tag muss explizit geschlossen werden.
• Tags ohne Inhalt müssen entweder explizit geschlossen werden oder mit />
enden (z.B. oder ).
• Attribut-Werte müssen in doppelten Anführungszeichen stehen (z.B. .
• 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

8.2 XML-basierter Datenaustausch 84
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.
Muster
Max
Musterstrasse
20
1000
Musterstadt
...siehe Kunde...
432-334-121
03.06.2002
12314
12.06.2002
19'' Flachbildschirm
4711.236
820,00
1
...
951,37
152,21
Abbildung 8.5: Beispiel für ein wohlgeformtes XML-Dokument (Rechnung.xml)

8.2 XML-basierter Datenaustausch 85
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 Vgl. BUXMANN ET AL (2001), S. 25-29

8.2 XML-basierter Datenaustausch 86
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:
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

8.2 XML-basierter Datenaustausch 87
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
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:
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 Vgl. BUXMANN ET AL (2001), S. 26

8.2 XML-basierter Datenaustausch 88
Die folgenden Abbildungen zeigen das um eine DTD und Attribute erweiterte XML-
Rechnungsdokument aus Abbildung 1.4 und die zugehörige DTD.
Abbildung 8.7: DTD zum XML-Dokument in Abbildung 8.5 (rechnung2.dtd)

8.2 XML-basierter Datenaustausch 89
Muster
Max
Musterstrasse
20
1000
Musterstadt
...siehe Kunde...
432-334-121
03.06.2002
12314
12.06.2002
19'' Flachbildschirm
4711.236
820,00
1
...
951,37
152,21
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)

8.2 XML-basierter Datenaustausch 90
Als Lösung auf diese Unzulänglichkeiten stellte das W3C nach 2 Jahren Entwicklungs-
zeit am 2. Mai 2001 die XML Schema Recommendation 141 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
143 Vgl. BUXMANN ET AL (2001), S. 29-30
144 Vgl. WYKE (2002)

8.2 XML-basierter Datenaustausch 91
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.
Abbildung 8.10: XML-Schema (Adresse.xsd) zu XML-Dokument in Tabelle 8.1 145
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

8.2 XML-basierter Datenaustausch 92
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-Dokumenten 147
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 Vgl. BUXMANN ET AL (2001), S. 38-40

8.2 XML-basierter Datenaustausch 93
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 gekennzeichnet. Ein Verweis auf ein zugehöriges Style Sheet erfolgt in
einem Dokument beispielsweise durch:
.
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)
...........................
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)

8.2 XML-basierter Datenaustausch 94
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

8.2 XML-basierter Datenaustausch 95
nerhalb der Signatur wird aber auf das/die zu signierende/n Dokument/ Do-
kumentteile verwiesen.
Dokument
Signatur
Signatur Dokument
Signatur
Ummantelt Ummantelnd
Dokument
Extern
Getrennt
Abbildung 8.12: Drei Arten von XML-Signaturen
Nachfolgend ein Beispiel für eine elektronische Signatur in XML.
Dokument
Signatur
Dokument
Intern
j7H6hd8kh7I9jcz7hgtjIM6K0Pgb
78bla83ALBlA5=3jghblA9hBLaa8
77564992370893420571690641
Abbildung 8.13: XML-Signatur Beispiel 154
Der für die Signatur verwendete Algorithmus (hier: "rsa-sha1") wird dem Attribut "Al-
gorithm" des Elements zugewiesen. Die der Signatur zugrunde lie-
gende Datei (hier: XML-Dokument "rechnung.xml") wird durch das Attribut "URI" des
Elements referenziert. Die Elemente und
beschreiben den Hash-Algortihmus (hier: "sha1") und den damit berechneten Hashwert
der Datei. Das Element 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 ü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

8.3 EDI mit XML (XML/EDI) 97
• 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

8.3 EDI mit XML (XML/EDI) 98
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:
Geschäftsdaten
Inhouse-Anwendung
des Absenders
Erstellt XML-
XML- Konvertiert
Datei
Datei
= Evtl. unterschiedliche Inhouse-Formate
Datenübertragung
per Internet
Abbildung 8.14: Ablauf XML/EDI-Kommunikation
Inhouse-Anwendung
des Empfängers
Geschäftsdaten
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

8.3 EDI mit XML (XML/EDI) 99
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 Standardisierungsinitiativen 161
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
Vgl. BUXMANN ET AL (2001), S. 75
163
Vgl. BUXMANN ET AL (2001), S. 75-78

8.3 EDI mit XML (XML/EDI) 100
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 Vgl. BUXMANN ET AL (2001), S. 145-147

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.
Rechnungssteller: Rechnungsempfänger:
Rechnungsdaten
E-Billing
Verfahren mit digitaler
Signatur
Eingabe,
Verarbeitung
EDV
Traditioneller
Rechnungsversand
auf Papier
= Medienbruch
Digitale
Signatur
Ausdruck
Elektron.
Versand
(z.B. E-Mail)
Vorteile von E-Billing:
• Reduktion der Prozesskosten
• Vermeidung von Medienbrüchen
• Beschleunigte Rechnungsabwicklung
• Gleiche Rechtsgültigkeit
Versand
und Porto
Automatische
Erfassung
EDV
Manuelle
Erfassung
EDV
Elektron.
Archivierung
PapierbasierteArchivierung
oder
Microfiche
Abbildung 9.1: Vergleich Rechnungsstellung auf Papier bzw. per eBilling 170
9.2 eBilling-Modelle
9.2.1 Direktes eBilling 171
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

9.2 eBilling-Modelle 105
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).
Rechnungssteller
Rechnung
Abbildung 9.2: Direktes eBilling 172
Rechnungsempfänger
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 eBilling 173
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

9.2 eBilling-Modelle 106
der Übertragung ist vergleichbar mit der Nutzung eines VANS bei EDI (siehe Kapitel
7.4).
Rechnungssteller
Rechnungsrohdaten
Rechnungsrohdaten
Konsolidator
Abbildung 9.3: Indirektes eBilling 174
Rechnung
Rechnungsempfänger
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 Vgl. EICKER, SCHWICHTENBERG (1999), S. 153-154

9.3 Angewandte eBilling-Lösungen 108
IT-System
Rechnungssteller
Rechnungs-
Rohdaten
Datenaufbereitung
Aufbereitete
Rechnungsdaten
Web-Billing-System
Web-Portal
Authentifizieren
Ansicht, Download
Abbildung 9.4: Elektronische Rechnungsstellung mit Web-Billing
Rechnungsempfänger
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 Angewandte eBilling-Lösungen 109
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-System
Rechnungssteller
E-Mail mit
Rechnungsdaten
Mail-Server
Zentrales Mail-
Postfach
Abbildung 9.5: Elektronische Rechnungsstellung mit E-Mail-Billing
Rechnungsempfänger
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 Vgl. EICKER, SCHWICHTENBERG (1999), S. 154-156

9.3 Angewandte eBilling-Lösungen 110
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 Vgl. EICKER, SCHWICHTENBERG (1999), S. 156-157

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).
Arbeitsplätze/
Anwender
Arbeitsplatz
Unternehmens-
Netzwerk
Signatur-Arbeitsplatz
Abbildung 9.6: Dezentrale Signatur-Lösung
Datenbank,
Mail-Server,
eBilling-
System
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

9.4 Integration des Signatur-Verfahrens 112
• 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.

9.4 Integration des Signatur-Verfahrens 113
Arbeitsplätze/
Anwender
Unternehmens-
Netzwerk
Signatur-
Server
Abbildung 9.7: Zentrale Signatur-Lösung 184
Datenbank,
Mail-Server,
eBilling-
System
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

9.4 Integration des Signatur-Verfahrens 114
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 Anbieter 188 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

Mitarbeiter
Vertrieb/
Buchhaltung
EDV-
Anwendung
(z.B. Excel)
XML-
Konverter
EDV-
Anwendung
(z.B. Excel)
Verantwortlicher
Vertrieb/
Buchhaltung
Signatur Hardund
Software
EDV-
Anwendung
Rechnungsstellung
erforderlich
Rechnungsdaten
erfassen
Rechnungsdaten
erfaßt
XML-Rechnung
erstellen
XML-Rechnung
erstellt
Rechnung
digital signieren
Elektronische
Rechnung erstellt
Rechnung
speichern
Rechnung
gespeichert
Rechnung zum
Versand freigeben
2-5 min
SOLL-Modell: Prozessablauf Rechnungssteller
1 min
1-2 min
Kundenkontostand
Leistungsdaten
Rechnungs
-daten
Rechnung
Rechnung
Rechnung
Interne
Datenbank
Interne
Datenbank
Interne
Datenbank
Mitarbeiter
Vertrieb/
Buchhaltung
E-Mail
Anwendung
(z.B. Outlook)
E-Mail
Anwendung
(z.B. Outlook)
R. zum Versand
freigegeben
Rechnung
versenden
Rechnung ist
versandt E-Mail
Postausgang
registrieren
Postausgang
registriert
Abbildung 10.1: Rechnungserstellung und -versand mit E-Mail-Billing
1-2 min
Rechnung
Ausgangs-
Postfach
Mail-Server
10.2 Analyse des SOLL-Modells 117

Nr. Prozess/Funktion
Bearbeitungszeit
(min)
SOLL-Modell: Prozessbeschreibung Rechnungssteller
∅ Sachkosten
1 Rechnungsdaten erfassen 2-5 -
2 XML-Rechnung erstellen 1 -
3
Rechnung elektronisch
signieren
1-2 -
4 Rechnung speichern - -
5
Rechnung zum Versand
freigeben
- -
Beteiligte Stelle IT-System-Unterstützung
Vertrieb/Buchhaltung,
Mitarbeiter
Vertrieb/Buchhaltung,
Mitarbeiter
Vertrieb/Buchhaltung,
Verantwortlicher
Vertrieb/Buchhaltung,
Verantwortlicher
Vertrieb/Buchhaltung,
Verantwortlicher
6 Rechnung versenden 1-3 0,30€ Vertrieb/Buchhaltung,
Mitarbeiter
7 Postausgang registrieren Automatisch -
Gesamt
5-11
∅8
Tabelle 10.1: Prozessbeschreibung SOLL-Modell Rechnungssteller
Vertrieb/Buchhaltung,
Mitarbeiter
EDV-Anwendung
(z.B. Excel), Datenbank
EDV-Anwendung(z.B. Excel),
XML-Konverter
Signatur Hard- und Software,
gültiges Zertifikat
EDV-Anwendung
(z.B. Excel), XML-Konverter,
Datenbank
E-Mail-Anwendung (z.B.
Outlook), Internet
E-Mail-Anwendung
(z.B. Outlook)
0,30€ 2 Durchgehend
-
Schwachstellen/Probleme
Absprache über XML-
Standard/Schema notwendig
Spezielle Hardware
notwendig
10.2 Analyse des SOLL-Modells 118

10.2 Analyse des SOLL-Modells 119
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 Rechnungen 194 , 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

10.2 Analyse des SOLL-Modells 120
Mitarbeiter
Rechnungseingang
Signatur-
Prüfsoftware
Archivierungs-
Software
Mitarbeiter
Buchhaltung,
Rechnungswesen
EDV-
Anwendung
(z.B. Excel)
SOLL-Modell: Prozessablauf Rechnungsempfänger
Elektr. Rechnung
nicht akzeptieren
Elektr. Rechnung
eingegangen
Elektronische
Signatur prüfen
1-2 min
Prüfung negativ Prüfung positiv
Elektr. Rechnung
nicht akzeptiert
XML-Parser
EDV-
Anwendung
(z.B. Access)
Elektr. Rechnung
akzeptieren
Elektr. Rechnung
akzeptiert
Rechnung u. Prüfergebnis
archivieren
Rechnungsdaten
erfassen
Rechnungsdaten
erfaßt
Rechnungsprüfung
2-5 min
Prüfung negativ Prüfung positiv
Reklamation,
Klärungsvorgang
Archivierung
abgeschlossen
Rechnung
1-2 min
Mail-
Postfach
Rechnung
Rechnung
Archiv-Server
Rechnung
Rechnungs
-daten
Verbuchen und
Zahlung einleiten
Mail-Server
Interne
Datenbank
Wareneingangsdaten
2 - 3 min Interne
Datenbank
Auftragsdaten
Abbildung 10.2: Eingang und Weiterverarbeitung einer E-Mail-Rechnung

Nr. Prozess/Funktion
SOLL-Modell: Prozessbeschreibung Rechnungsempfänger
Bearbeitungszeit
(min)
1 Elektronische Signatur prüfen 1-2
2a
2b
3
Elektronische Rechnung
akzeptieren
Elektronische Rechnung
nicht akzeptieren
Rechnung u. Prüfergebnis
archivieren
-
-
1-2
4 Rechnungsdaten erfassen 2-5
5 Rechnungsprüfung 2-3
Gesamt
6-12
∅9
Tabelle 10.2: Prozessbeschreibung SOLL-Modell Rechnungsempfänger
Beteiligte Stelle IT-System-Unterstützung
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Buchhaltung / Rechnungswesen,
Mitarbeiter
Signatur-Prüfsoftware
Archivierungs-Software,
Datenbank
EDV-Anwendung (z.B.
Access), Datenbank
EDV-Anwendung (z.B.
Excel), Datenbank
1 Durchgehend
-
Schwachstellen/
Probleme
Spezielle Software notwendig
- Prozess-Ende
10.2 Analyse des SOLL-Modells 121

10.2 Analyse des SOLL-Modells 122
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 (= Bearbeitungszeit
/60 * Stundensatz)
5,50 € 4,00 €
Sachkosten 1,55 € 0,30 €
Gesamtkosten (= Bearbeitungskosten
+ 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

10.3 Ergebnis der Optimierung 124
• 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

10.3 Ergebnis der Optimierung 125
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 AG 200 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
Buchhaltung
Zeichnungsberechtigter
Mail Server
Interne und externe
Zertifaktsverwaltung
Signieren/Verifizieren
Zeitsignieren
Verschlüsseln/Entschlüsseln
SmartCard
qualifizierte Signatur
Dokumentenarchiv
des Unternehmens
Unternehmen B
Mitarbeiter
Abbildung 11.1: AuthentiDate eBilling-Inhouse-Lösung 202
Internet
Mail Server
Mitarbeiter
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

11.2 AuthentiDate eBilling-Signatur-Lösungen 128
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 Provider 203 ) 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

11.2 AuthentiDate eBilling-Signatur-Lösungen 129
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).
Buchhaltung
Dokumentenarchiv
des
Unternehmens
eBilling-Client
EDV-System
Mail Server
Interne und externe
Zertifaktsverwaltung
Signieren/Verifizieren
Zeitsignieren
Verschlüsseln/Entschlüsseln
SmartCard
qualifizierte Signatur
Mitarbeiter
Mail Server
Abbildung 11.2: AuthentiDate eBilling-Lösung über Trust Center 205
Internet
Mitarbeiter
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-Format 209 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 PRODUKTINFORMATION, S. 4
207
Vgl. AUTHENTIDATE (2002), S. 5
208
Vgl. AUTHENTIDATE PRODUKTINFORMATION, S. 4
209
CSV=Comma Separated Values, standardisiertes Textformat mit der Möglichkeit zum Datenimport in MS-Excel/Access

11.3 T-Mobile RechnungOnline 131
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

11.3 T-Mobile RechnungOnline 132
Abbildung 11.3: Einzelverbindungsnachweis T-Mobile RechnungOnline 214
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.
Download der
Signatur-Datei
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

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)

11.4 TietoEnator Sealsnet 134
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

11.4 TietoEnator Sealsnet 135
Abbildung 11.4: TietoEnator Lösungsvorschlag 221
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.

13 Literaturverzeichnis 140
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.

13 Literaturverzeichnis 141
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.

13 Literaturverzeichnis 142
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

13 Literaturverzeichnis 143
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.

13 Literaturverzeichnis 144
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.

13 Literaturverzeichnis 145
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.

13 Literaturverzeichnis 146
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.

13 Literaturverzeichnis 147
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

13 Literaturverzeichnis 148
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-Modell 223
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üpfungsoperatoren
Verknüpfungsart
Ereignistypverknüpfung
Funktionstypverknüpfung
F
E
Auslösende
Ereignistypen
Erzeugte
Ereignistypen
Auslösende
Ereignistypen
Erzeugte
Ereignistypen
= Funktion
= Ereignis
224 Vgl. Keller et al. (1992) Seite 14
E
E
F
E
E
F
F
Entweder/
Oder
F
E
E
F
E
= nicht erlaubt
Abbildung A 1: EPK-Verknüpfungsarten 224
E
E
F
E
E
F
F
Und Und/Oder
F
E
E
F
E
E
E
F
E
E
F
F
F
E
E
F
E

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 Bank Giessen'
PE Spezifiziert Konto des Verkäufers
246217:PCBOERSE Konto-Nummer, Inhaber
51960815:28:::::Dresdner Bankleitzahl, Name der Bank
Bank Giessen
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 übereinstimmen)

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