SEPA-Umstellung mit SAP · 2012. 10. 2. · Bonn Boston Jürgen Weiss SEPA-Umstellung mit SAP ®...

Bonn � Boston

Jürgen Weiss

SEPA-Umstellung mit SAP ®

1987-7.book Seite 3 Donnerstag, 6. September 2012 3:18 15

Auf einen Blick

1 Einleitung ....................................................................... 19

TEIL I Hintergrund und Rahmenbedingungen von SEPA

2 SEPA – Von der Vision zur Umsetzung ............................ 27

3 Welche Veränderungen bringt SEPA? .............................. 75

TEIL II Das SEPA-Paket von SAP

4 Verfügbarkeit und Auslieferung ...................................... 167

5 SEPA-Mandatsverwaltung ............................................... 171

6 Neue Zahlungsformate .................................................... 207

7 IBAN und BIC ................................................................. 253

TEIL III Optionale SEPA-Erweiterungen

8 SAP In-House Cash ......................................................... 269

9 SAP Bank Communication Management ......................... 315

10 SAP Integration Package for SWIFT ................................. 355

TEIL IV SEPA in der Praxis und Ausblick

11 Empfehlungen für ein SEPA-Projekt ................................ 397

12 Zusammenfassung .......................................................... 409

13 Ausblick auf E-SEPA ........................................................ 413


9

Inhalt

Vorwort zur dritten Auflage ...................................................... 17

1 Einleitung ................................................................ 19

1.1 SEPA – Was kommt auf Europa zu? ......................... 191.2 Ziel des Buches ....................................................... 20

1.2.1 Viele Unternehmen unterschätzen SEPA ... 201.2.2 Herausforderungen für Unternehmen ......... 21

1.3 Zielgruppen des Buches .......................................... 221.4 Aufbau des Buches ................................................. 22

Teil I Hintergrund und Rahmenbedingungen von SEPA

2 SEPA – Von der Vision zur Umsetzung ................... 27

2.1 Ein Blick zurück ...................................................... 272.1.1 Überlegungen nach der Währungsunion .... 272.1.2 Lissabon-Agenda ....................................... 292.1.3 EG-Verordnung 2560/2001 ....................... 302.1.4 Europäischer Rat für Zahlungsverkehr ........ 312.1.5 Richtlinie über Zahlungsdienste ................. 322.1.6 EG-Verordnung 924/2009 ......................... 332.1.7 SEPA-Verordnung 260/2012 ...................... 342.1.8 Deutsches SEPA-Begleitgesetz ................... 38

2.2 Motive für SEPA ..................................................... 382.3 Geltungsbereich von SEPA ...................................... 482.4 Treibende Kräfte hinter SEPA .................................. 532.5 Fahrplan – Wie SEPA verwirklicht wird ................... 672.6 Bisherige SEPA-Erfahrungen .................................... 702.7 Fazit ....................................................................... 73

3 Welche Veränderungen bringt SEPA? ..................... 75

3.1 Neue Zahlungsinfrastrukturen ................................. 753.1.1 Rahmenwerk für Clearing-Häuser ............... 753.1.2 Exkurs: Grenzüberschreitender

Eurozahlungsverkehr .................................. 763.1.3 Paneuropäische Clearing-Häuser ................ 803.1.4 EBA Clearing und STEP2 ............................ 81


Inhalt

10

3.2 Neue Zahlungsinstrumente ...................................... 823.2.1 SEPA-Überweisung ..................................... 823.2.2 Datensätze der SEPA-Überweisung ............. 903.2.3 SEPA-Lastschrift als Basisversion für

Privatkunden .............................................. 933.2.4 Datensätze der SEPA-Basislastschrift ........... 1053.2.5 SEPA-B2B-Lastschrift für Firmenkunden ..... 116

3.3 Neue XML-Zahlungsformate: Standard ISO 20022 ................................................ 1173.3.1 Motivation für den ISO-20022-

Nachrichtenstandard .................................. 1183.3.2 Funktionsweise von ISO 20022 .................. 1203.3.3 Struktur der ISO-20022-Nachrichten .......... 1243.3.4 Zusammenhang zwischen ISO 20022

und SEPA ................................................... 1293.3.5 ISO 20022 Common Global

Implementation (CGI) ................................. 1333.4 Neue Stammdaten: IBAN und BIC ........................... 134

3.4.1 Internationale Bankkontonummer (IBAN) ........................................................ 134

3.4.2 BIC oder SWIFT-Code ................................. 1393.4.3 IBAN und BIC im Zusammenhang mit

SEPA: Auswirkungen auf Gebühren ............ 1423.5 Richtlinie über Zahlungsdienste ............................... 142

3.5.1 Inhalt der Richtlinie .................................... 1433.5.2 Rechtliche Aspekte ..................................... 147

3.6 Neue Infrastruktur für Zahlungskarten ..................... 1483.6.1 Status quo des europäischen

Kartenmarktes ............................................ 1483.6.2 EPC-Rahmenwerk für SEPA-Karten ............. 149

3.7 SEPA in der Schweiz und in Österreich .................... 1513.7.1 SEPA-Umstellung in der Schweiz ................ 1513.7.2 SEPA-Umstellung in Österreich ................... 153

3.8 Konsequenzen von SEPA ......................................... 1553.8.1 Auswirkungen auf Endverbraucher .............. 1553.8.2 Auswirkungen auf große und

mittelständische Unternehmen ................... 1573.8.3 Auswirkungen auf Banken und

Clearing-Häuser .......................................... 1613.9 Fazit ........................................................................ 163


Inhalt

11

Teil II Das SEPA-Paket von SAP

4 Verfügbarkeit und Auslieferung .............................. 167

5 SEPA-Mandatsverwaltung ...................................... 171

5.1 Grundlagen ............................................................. 1715.2 Unterstützung verschiedener SAP-Anwendungen .... 1725.3 Stammdaten der SEPA-Mandate ............................. 1785.4 Dialogtransaktionen zur Verwaltung von

SEPA-Mandaten ..................................................... 1875.4.1 Eigene SEPA-Dialogtransaktionen .............. 1895.4.2 Massenaktivität zum Anlegen von

Mandaten .................................................. 1965.5 Integration in SAP-Anwendungen ........................... 2005.6 Weitere Funktionen der

SEPA-Mandatsverwaltung ....................................... 2035.7 Anbinden einer externen Mandatsverwaltung ......... 2055.8 Fazit ....................................................................... 206

6 Neue Zahlungsformate ............................................ 207

6.1 Payment Medium Workbench ................................ 2076.1.1 Vorteile und Funktionsweise der

Payment Medium Workbench ................... 2086.1.2 Ablauf der Prozesse in der

Payment Medium Workbench ................... 2136.2 Data Medium Exchange Engine .............................. 217

6.2.1 Aufgaben der Data Medium Exchange Engine ...................................................... 217

6.2.2 Definition von DMEE-Formatbäumen ........ 2196.3 SEPA-Überweisung im SAP-System ......................... 222

6.3.1 Aufbau des DMEE-Formatbaums ............... 2226.3.2 Hierarchieebenen im

DMEE-Formatbaum ................................... 2236.3.3 Verwendungszweck-Informationen in der

Nachricht ................................................... 2246.3.4 Optionale Felder ........................................ 232

6.4 SEPA-Lastschrift im SAP-System .............................. 2356.5 Kontoauszugsverarbeitung ...................................... 243

6.5.1 Neue Geschäftsvorfallcodes ....................... 244


Inhalt

12

6.5.2 Änderungen im Feld 86 .............................. 2466.5.3 Interpretation der Feldbezeichner

im SAP-System ........................................... 2496.6 Fazit ........................................................................ 251

7 IBAN und BIC .......................................................... 253

7.1 Funktionalität im SAP-System .................................. 2537.2 Unterstützung bei der Umstellung auf IBAN ............ 257

7.2.1 IBAN-Umstellung in Deutschland ............... 2577.2.2 IBAN-Umstellung in der Schweiz und

in Österreich .............................................. 2597.2.3 IBAN-Umstellung in SAP ............................ 260

7.3 Unterstützung bei der Umstellung auf BIC ............... 2647.4 Fazit ........................................................................ 266

Teil III Optionale SEPA-Erweiterungen

8 SAP In-House Cash .................................................. 269

8.1 Betriebswirtschaftliche Grundidee ........................... 2698.2 Organisationsformen im Konzernzahlungs-

verkehr .................................................................... 2708.3 Organisationseinheiten innerhalb von

SAP In-House Cash .................................................. 2738.4 Stammdaten im In-House Cash Center .................... 275

8.4.1 Bankkreis und Buchungskreis ...................... 2758.4.2 Geschäftspartner ........................................ 2768.4.3 Definition von Produkten ........................... 2788.4.4 Einrichtung von Konten .............................. 2798.4.5 Konditionen und Konditionstypen .............. 2808.4.6 Limite ......................................................... 284

8.5 Operative Geschäftsprozesse inSAP In-House Cash .................................................. 2868.5.1 Interne Zahlungsverrechnung ..................... 2868.5.2 Zentrales Zahlen ......................................... 2948.5.3 Lokales Zahlen ............................................ 2988.5.4 Zentraler Geldeingang ................................ 299

8.6 Bankkreisübergreifendes Buchen ............................. 3028.6.1 Internes Zahlen über mehrere In-House

Cash Center ................................................ 302


Inhalt

13

8.6.2 Zentrales Zahlen über mehrere In-House Cash Center ............................................... 305

8.7 Währungstausch ..................................................... 3078.8 Periodische Arbeiten ............................................... 3088.9 Mandatsinformationen in SAP In-House Cash ......... 3128.10 Funktionale Erweiterungen von SAP

In-House Cash ........................................................ 3138.11 Integration mit anderen SAP-Komponenten ........... 3148.12 Fazit ....................................................................... 314

9 SAP Bank Communication Management ................ 315

9.1 Betriebswirtschaftliche Grundidee ........................... 3159.2 Funktionaler Überblick ............................................ 3199.3 Zahllauf, Erzeugung von Zahlungssammlern

und Batching .......................................................... 3229.3.1 Zahlungsprogramme im

SAP-System ............................................... 3229.3.2 Erzeugen von Zahlungssammlern ............... 3259.3.3 Batching von Zahlungen ............................. 328

9.4 Freigabe von Zahlungen .......................................... 3329.4.1 Regelwerk für Freigaben ............................ 3329.4.2 Freigabetransaktion für Batches und

Zahlungen .................................................. 3349.4.3 Authentifizierung der Anwender ................ 338

9.5 Aktualisierung des Zahlungsstatusmonitors ............. 3429.5.1 Parameter für die Selektion von

Zahlungen .................................................. 3429.5.2 Umwandlung von

Geschäftsvorfallschlüsseln .......................... 3449.6 Behandlung von Ausnahmen .................................. 3469.7 Aktualisierung des Kontoauszugsmonitors .............. 3489.8 Integration mit anderen

Komponenten ......................................................... 3519.9 Fazit ....................................................................... 353

10 SAP Integration Package for SWIFT ....................... 355

10.1 Betriebswirtschaftliche Grundidee ........................... 35510.2 Rolle von SWIFT ..................................................... 358

10.2.1 Aufgabengebiet von SWIFT ........................ 358


Inhalt

14

10.2.2 Organisationsstruktur von SWIFT ................ 35910.3 Funktionsweise des SWIFT-Netzes ........................... 360

10.3.1 Aufbau von MT-Nachrichten ...................... 36010.3.2 Verschiedene Messaging-Dienste im

SWIFT-Netz ................................................ 36410.4 Teilnahmemöglichkeiten am SWIFT-Netz ................ 367

10.4.1 Direkte oder indirekte Teilnahme ............... 36710.4.2 Anschlussoptionen für Unternehmen .......... 36810.4.3 Voraussetzungen für die

SCORE-Teilnahme ...................................... 37110.5 Integration mit SWIFTAlliance Access und

SWIFTAlliance Gateway ........................................... 37210.5.1 Aufgabe der SWIFT-Applikationen .............. 37310.5.2 Ablauf der Kommunikation im

FIN-Szenario ............................................... 37510.5.3 Ablauf der Kommunikation im

FileAct-Szenario ......................................... 37710.6 Technische Grundlagen von SAP NetWeaver

Process Integration .................................................. 37810.6.1 Architektur von SAP NetWeaver PI ............. 37810.6.2 Architektur des SAP Integration

Package for SWIFT ...................................... 38710.7 Enterprise Services für die

Bankenkommunikation ............................................ 39110.8 Integration mit anderen Komponenten .................... 39110.9 Fazit ........................................................................ 393

Teil IV SEPA in der Praxis und Ausblick

11 Empfehlungen für ein SEPA-Projekt ....................... 397

11.1 Phasen eines SAP-Projekts ....................................... 39711.2 Überlegungen zu einem SEPA-Projekt ..................... 401

11.2.1 Projektvorbereitung .................................... 40211.2.2 Blueprint .................................................... 40211.2.3 Realisierung ................................................ 40511.2.4 Letzte Vorbereitung .................................... 40611.2.5 Produktivstart ............................................. 406

11.3 Fazit ........................................................................ 407


Inhalt

15

12 Zusammenfassung ................................................... 409

13 Ausblick auf E-SEPA ................................................ 413

13.1 E-Invoicing ............................................................. 41413.2 E-Reconciliation ...................................................... 41713.3 E-Payments ............................................................. 419

Anhang ............................................................................ 421

A Glossar .............................................................................. 423B Im Buch verwendete SAP-Hinweise, Transaktionen etc. ..... 429C Literaturverzeichnis ........................................................... 435D Wichtige Internetseiten ..................................................... 445E Der Autor ......................................................................... 447

Index ....................................................................................... 449


17

Vorwort zur dritten Auflage

Die erste Auflage dieses Buches zum einheitlichen Euro-Zahlungsver-kehrsraum erschien bereits im November 2007. Mit Fug und Rechtkann ich behaupten, dass sich dieses Buch seitdem zu dem deutschenStandardwerk für die Single Euro Payments Area (SEPA) entwickelthat, das betriebswirtschaftliche Hintergrundinformationen mit kon-kretem SAP-Anwendungswissen verknüpft.

Nach dem Erscheinen der zweiten Auflage im Jahr 2009 haben ver-schiedene Entwicklungen nun eine weitere Überarbeitung desBuches erforderlich gemacht:

� Das Europaparlament und der Europäische Rat haben im März2012 den Weg für den einheitlichen europäischen Zahlungsraumendgültig frei gemacht, indem sie ein verbindliches Enddatum(1. Februar 2014) für die Parallelphase von nationalen und SEPA-Zahlungsformaten festgelegt haben.

� Der Europäische Rat für Zahlungsverkehr hat neue Regelwerkeund Implementierungsrichtlinien für die SEPA-Zahlungsformatepubliziert.

� SAP hat die im SEPA-Paket enthaltenen Funktionen an die neuenRegelwerke angepasst und funktionale Erweiterungen für die indiesem Buch beschriebenen Komponenten bereitgestellt.

Damit waren auch die Eckpunkte für eine vollständige Überarbeitungder zweiten Auflage klar: Dieses Buch basiert auf den aktuellen, abNovember 2012 gültigen SEPA-Regelwerken und -Implementie-rungsrichtlinien in den Versionen 6.0 und 4.0 (für die SEPA-Basis-und -B2B-Lastschrift) sowie in Version 6.0 für die SEPA-Überweisung.Außerdem berücksichtigt diese dritte Auflage den aktuellen Stand derSAP-Funktionen, die mit den Erweiterungspaketen 1 bis 6 (EHP 1 bis6) für SAP ERP 6.0 ausgeliefert wurden. Darüber hinaus wurden indiesem Buch formale und sprachliche Korrekturen sowie punktuellefachliche Erweiterungen und Verbesserungen vorgenommen.

Jürgen Weiss


19

»SEPA ist die größte Initiative im Zahlungsverkehr, die es jemals in Europa – ja der ganzen Welt – gegeben hat.«European Payments Council (EPC)

1 Einleitung

Die Einführung des einheitlichen Euro-Zahlungsverkehrsraums (Sin-gle Euro Payments Area, SEPA) bringt für alle Banken und Unterneh-men, die in Europa tätig sind, massive Veränderungen mit sich. Auchwenn SEPA zumindest die europäischen Kreditinstitute seit mehr alsfünf Jahren beschäftigt, haben sich viele Unternehmen noch nichtdetailliert mit diesem Thema auseinandergesetzt: Ein verbindlichesEnddatum, zu dem SEPA umgesetzt und die nationalen Zahlungsver-kehrsformate abgelöst werden müssen, existiert erst seit März 2012.Daher fassen wir in diesem Kapitel noch einmal die Bedeutung derSEPA-Initiative zusammen. Zudem lernen Sie hier die Struktur desBuches kennen.

1.1 SEPA – Was kommt auf Europa zu?

Umstellungs-aufwand

Einige Beobachter schätzen die mit SEPA verbundenen IT-Umstel-lungsprojekte größer ein als die Aufwände, die insgesamt durch dieJahr-2000-Umstellung und die Euro-Einführung angefallen sind.Während solche Einschätzungen primär auf die Umstellungsauf-wände abzielen, sollten sie nicht den Blick auf die betriebswirtschaft-lichen Umwälzungen versperren, auf die sich Unternehmen und Ban-ken im Euro-Raum vorbereiten müssen. SEPA ist ein weitererBaustein auf dem Weg hin zu einem gemeinsamen Binnenmarkt mitgleichen Rechten und Pflichten für alle Marktteilnehmer. Auch wennderzeit noch immer nicht absehbar ist, welche Synergien tatsächlichdurch SEPA erzielt werden, ist dennoch erkennbar, dass entlang derfinanziellen Wertschöpfungskette, der Financial Supply Chain, einvielversprechendes Optimierungspotenzial besteht – dazu gehöreninsbesondere das Rechnungswesen, das Cash Management und derBereich des Zahlungsverkehrs.


20

Einleitung1

1.2 Ziel des Buches

Dieses Buch nimmt den Blickwinkel von produzierenden und Dienst-leistungsunternehmen sowie von Kommunen und Behörden ein, dievon SEPA betroffen sind. Insgesamt hat der einheitliche Euro-Zah-lungsverkehrsraum erhebliche Auswirkungen, da die Veränderun-gen nicht nur für Kreditinstitute, sondern für alle Unternehmen spür-bar sein werden. In diesem Abschnitt werden die Motive für diesesBuches kurz zusammengefasst.

1.2.1 Viele Unternehmen unterschätzen SEPA

Risiken derNichtbeachtung

In den letzten Jahren haben sich in erster Linie nur Finanzinstituteund einige wenige Großunternehmen mit der SEPA-Problematik aus-einandergesetzt. Während sich Banken gegenüber der EuropäischenKommission verpflichtet haben, Anfang 2008 »SEPA-ready« zu sein,und ein Teil der Großunternehmen frühzeitig den Aufwand und diemöglichen betriebswirtschaftlichen Synergien erkannt hat, habensich kleine und mittelständische Unternehmen, die gerade inDeutschland das Gros der Betriebe stellen, jedoch nur unzureichendmit dem Thema SEPA beschäftigt. Eine Umfrage der ibi Researchunter 270 deutschen Unternehmen aus dem Jahr 2012 hat beispiels-weise ergeben, dass 66% der befragten Firmen entweder nur »relativvage Vorstellungen« davon haben, was SEPA konkret für ihr Unter-nehmen bedeutet, oder gar noch nie etwas von dem neuen Rahmen-werk gehört haben (ibi Research, 2012, http://www.ecommerce-leit-faden.de/geschaefte-ohne-grenzen-e-commerce-international-2012.html).

Ähnlich wie bei der Euro-Einführung birgt diese fehlende Sensibilitäterhebliche Risiken. So besteht zum einen die Gefahr, dass vieleUnternehmen ab dem 1. Februar 2014 (dem Zeitpunkt, zu dem SEPAauch in Deutschland in Kraft tritt) nicht mehr kompatibel mit demdann geltenden SEPA-Rahmenwerk sein werden. Zum anderen dro-hen vielen Unternehmen erhebliche Wettbewerbsnachteile, da siesich nicht frühzeitig und umfassend mit den Möglichkeiten von SEPAbefasst haben.

UnterschätztesThema

Gelegentlich ist auch zu beobachten, dass das Thema in vielenFinanzabteilungen unterschätzt und nicht an die entsprechende Füh-rungsebene adressiert wird. Das ist ein strategischer Fehler: SEPA ist


21

Ziel des Buches 1.2

Chefsache, und jeder Geschäftsführer bzw. Finanzvorstand ist bes-tens beraten, sich intensiv damit auseinanderzusetzen.

Die Veränderungen, die SEPA für die besonders sensiblen Bereiche»Zahlungsverkehr« und »Finanzbuchhaltung« mit sich bringen wird,gehen über den reinen IT-Anpassungsaufwand hinaus. Der Bundes-verband Informationswirtschaft, Telekommunikation und neue Me-dien e.V. (BITKOM) geht in seinem SEPA-Leitfaden davon aus, dassvon SEPA »nahezu jede Abteilung betroffen« ist (BITKOM, 2012,http://www.bitkom.org/files/documents/BITKOM_SEPA-Leitfaden.pdf).So wirft der einheitliche Euro-Zahlungsverkehrsraum beispielsweiseauch rechtliche Fragen auf und sollte für alle Unternehmen Anlasssein, ihre bisherigen Geschäftsprozesse zu überprüfen und an dieneuen Rahmenbedingungen anzupassen. Ohne ausreichende Ana-lyse und Vorlaufzeit sowie sorgfältige Vorbereitung ist die Wahr-scheinlichkeit groß, dass ein SEPA-Projekt nicht oder nicht rechtzei-tig erfolgreich zum Abschluss gebracht werden kann.

Zum Zeitpunkt der Drucklegung dieses Buches – September 2012 –ist der SEPA-Einführungstermin weniger als zwei Jahre entfernt: DieUhr tickt also!

1.2.2 Herausforderungen für Unternehmen

Motivationfür SEPA

Um das Bewusstsein für SEPA und die damit verbundenen Änderun-gen zu wecken, soll Ihnen dieses Buch einen betriebswirtschaftlichenÜberblick über die Motive und politischen Hintergründe von SEPAvermitteln. Mit diesem Verständnis sind die neuen SEPA-Rahmenbe-dingungen besser nachzuvollziehen und einzuordnen. Daneben stelltdieses Buch die für Nicht-Banken relevanten Veränderungen vor undwagt einen kleinen Ausblick darauf, welche Konsequenzen sich fürdie verschiedenen Marktteilnehmer (Banken, Unternehmen undEndkunden) in den nächsten Jahren ergeben werden.

Auch wenn SEPA, wie bereits erwähnt, nicht nur die IT-Infrastrukturtangieren wird, liegt der Schwerpunkt dieses Buches selbstverständ-lich auf den Anpassungen, die Sie als SAP-Anwender in Ihrem ERP-System vornehmen müssen, um für die neue SEPA-Welt gerüstet zusein. SAP liefert an alle Bestandskunden mit gültiger Wartungsver-einbarung kostenfrei funktionale Erweiterungen aus, um die SEPA-Kompatibilität der SAP-Software sicherzustellen.


22

Einleitung1

SEPA sollte jedoch nicht nur als lästige Pflichtübung aufgefasst, son-dern auch als strategische Weichenstellung für die Zukunft verstan-den werden. Aus diesem Grund stellt Ihnen dieses Buch eine Reiheweiterer Anwendungskomponenten vor, die sinnvolle Ergänzungenbieten, um vom SEPA-Potenzial zu profitieren. Dazu gehören insbe-sondere Komponenten für die Optimierung der Bankenkommunika-tion und zur Verbesserung der Transparenz von Zahlungsströmen.

1.3 Zielgruppen des Buches

Dieses Buch richtet sich an verschiedene Zielgruppen:

� Entscheider und Mitarbeiter in Finanz-, IT- und Rechnungswesen,Treasury und Cash Management von Nicht-Banken erhalten einenumfassenden Überblick über die durch SEPA ausgelösten Verän-derungen.

� Mitarbeiter im Produktmanagement, Cash Management und Zah-lungsverkehr von Banken erhalten ein besseres Verständnis fürdie betriebswirtschaftlichen und technischen Vorgänge in den IT-Systemen ihrer Unternehmenskunden.

� Projektleiter erhalten Informationen über die wesentlichen funk-tionalen Aspekte der SAP-Lösungen, deren Integration in andereAnwendungskomponenten und nützliche Hinweise für die Imple-mentierung.

� Beratungsunternehmen und Wirtschaftsprüfer erhalten einenkonkreten Einblick in neue Lösungen, die nicht nur die rechtlicheund betriebswirtschaftliche SEPA-Kompatibilität sicherstellen,sondern auch zu einer besseren Transparenz der Zahlungsströmean der Kunde-Bank-Schnittstelle beitragen.

1.4 Aufbau des Buches

SEPA-Pflichtund SEPA-Kür

Das Buch ist in vier Teile gegliedert. Teil I (Kapitel 2 und 3) konzen-triert sich auf die betriebswirtschaftlichen und politischen Hinter-gründe von SEPA, die damit verbundenen Änderungen und derenAuswirkungen auf die verschiedenen Marktteilnehmer. In Teil II(Kapitel 4 bis 7) wird der Funktionsumfang des SEPA-Pakets von SAPdargestellt – die Mandatsverwaltung, die SEPA-Zahlungsformate


23

Aufbau des Buches 1.4

sowie die Stammdaten IBAN und BIC. Während sich dieser Teil aufdie Pflichtanpassungen konzentriert, um künftig SEPA-konform zusein bzw. zu bleiben, widmet sich Teil III (Kapitel 8 bis 10) der»SEPA-Kür«. Hier werden drei SAP-Anwendungskomponenten vor-gestellt, die für die SEPA-Kompatibilität zwar nicht notwendig sind,aber für viele Unternehmen einen erheblichen Zusatznutzen undeine strategische Weiterentwicklung darstellen. Teil IV (Kapitel 11bis 13) gibt schließlich Hinweise zur Abwicklung eines SEPA-Projektsund wagt einen Ausblick in die Zukunft.

Im Detail ist das Buch wie folgt aufgebaut:

Teil I Hintergrund und Rahmenbedingun-gen von SEPA

In Kapitel 2, »SEPA – Von der Vision zur Umsetzung«, werden diebetriebswirtschaftlichen und politischen Motive für die Einführungvon SEPA beschrieben. Hinzu kommen ein Überblick des geografi-schen und wirtschaftlichen SEPA-Geltungsbereichs und eine Vorstel-lung der treibenden politischen Kräfte hinter der SEPA-Initiative. DieDarstellung des zeitlichen SEPA-Fahrplans rundet dieses Kapitel ab.

In Kapitel 3, »Welche Veränderungen bringt SEPA?«, werden dieeinzelnen SEPA-Bestandteile detailliert vorgestellt. Die neuen Zah-lungsinstrumente und XML-basierten Zahlungsformate werdenebenso behandelt wie die Veränderungen bei den Zahlungskartenund den Stammdaten. Außerdem werden die Richtlinie über Zah-lungsdienste (Payment Services Directive, PSD) sowie die im Jahr2012 verabschiedete SEPA-Verordnung vorgestellt. Ein Blick überdie deutschen Landesgrenzen hinaus auf die Schweiz und Österreichsowie eine Prognose der zu erwartenden Auswirkungen von SEPAauf die verschiedenen Marktteilnehmer schließen dieses Kapitel ab.

Teil II SEPA-Pflicht – Das SEPA-Paket von SAP

Die Erläuterung des SEPA-Pakets von SAP beginnt mit Kapitel 4,»Verfügbarkeit und Auslieferung«. Sie erfahren hier, wann und wiedie SEPA-Funktionen ausgeliefert wurden und welche Releasesunterstützt werden.

Kapitel 5, »SEPA-Mandatsverwaltung«, widmet sich den Stammda-ten für die Verwaltung der Basis- und B2B-Lastschriften sowie derIntegration in die FI-Nebenbuchhaltungen FI-AR und FI-CA.

Kapitel 6, »Neue Zahlungsformate«, beschäftigt sich mit der Imple-mentierung der SEPA-Überweisung und der SEPA-Lastschrift imSAP-System.


24

Einleitung1

Kapitel 7, »IBAN und BIC«, beschäftigt sich mit den Veränderungen,die sich durch SEPA für die Verwaltung der Stammdaten ergeben.

Teil IIISEPA-Kür –

Optionale SEPA-Erweiterungen

In Kapitel 8, »SAP In-House Cash«, steht die Anwendungskompo-nente »SAP In-House Cash« im Vordergrund, die es Konzernenermöglicht, die Zahl ihrer Bankbeziehungen und Zahlungstransaktio-nen zu reduzieren sowie den ein- und ausgehenden Zahlungsverkehrzu zentralisieren.

Kapitel 9, »SAP Bank Communication Management«, widmet sichder Anwendungskomponente »SAP Bank Communication Manage-ment«, die zu einer besseren Transparenz der Zahlungsströme und zueiner Optimierung der Kunde-Bank-Schnittstelle beiträgt.

Kapitel 10, »SAP Integration Package for SWIFT«, geht schließlich aufden Funktionsumfang und die technische Realisierung des SAP Inte-gration Package for SWIFT sowie auf die grundlegende Bedeutungvon SWIFT für den Zahlungsverkehr ein.

Teil IVSEPA in der Praxis

und Ausblick

In Kapitel 11, »Empfehlungen für ein SEPA-Projekt«, folgen einigeelementare Überlegungen und Best Practices für die erfolgreicheGestaltung eines SEPA-Projekts.

Kapitel 12, Zusammenfassung«, resümiert die Erläuterungen diesesBuches und Kapitel 13, »Ausblick«, wagt einen Blick in die Zukunftund beschäftigt sich mit weiteren, durch SEPA zu erwartenden Ver-änderungen.

Das Buch endet einem ausführlichen Glossar von Fachbegriffensowie einer Übersicht über die im Buch zur Sprache gekommenenTransaktionen, SAP-Hinweise, Funktionsbausteine etc.


82

Welche Veränderungen bringt SEPA?3

4.500 indirekten Teilnehmern genutzt, letztere sind nicht direkt anSTEP2 angeschlossen.

Der STEP2-Service für die SEPA-Basislastschrift wird ebenfalls nachAngaben von EBA Clearing derzeit von 87 direkten und mehr als3.900 indirekten Teilnehmern genutzt, während die SEPA-B2B-Last-schrift 71 direkte und mehr als 3.300 indirekte Teilnehmer verwen-den.

Italien und Luxemburg wickeln seit 2006 ihre inländischen Überwei-sungszahlungen über STEP2 ab. Die finnischen Banken folgten imJahr 2011, und auch Irland ist gerade dabei, seinen inländischenMassenzahlungsverkehr (Überweisungen und Lastschriften) anSTEP2 zu übertragen.

STEP2 weist somit bereits ein hohes Transaktionsvolumen aus undist als PE-ACH auch für SEPA-Mehrwertdienste (sogenannte AOS,Additional Optional Services) gerüstet. Stand September 2012 bietetSTEP2 bereits vier solcher AOS an, unter anderem erweiterte Ver-wendungszweckinformationen und die Unterstützung des griechi-schen Zeichensatzes. Des Weiteren plant EBA Clearing, auch mögli-che kürzere Zahlungsfristen für die SEPA-Basislastschriften (bis zueinem Tag vor dem Fälligkeitstermin) zu unterstützen (EBA Clearing,Seite 21).

3.2 Neue Zahlungsinstrumente

Sie müssen sich in Ihrem Unternehmen im Rahmen von SEPA vorallem mit zwei neuen Zahlmethoden auseinandersetzen: der SEPA-Überweisung und der SEPA-Lastschrift. Die spezifischen Merkmaleund Abläufe der beiden Zahlungsinstrumente werden in den folgen-den Abschnitten genau beschrieben.

3.2.1 SEPA-Überweisung

SCT-Regelwerk Die Grundidee von SEPA ist, dass Privatkunden und UnternehmenEuro-Überweisungen im SEPA-Raum künftig genauso einfach undkomfortabel vornehmen können, wie sie Inlandszahlungen ausfüh-ren. Hierzu hat das EPC ein Regelwerk (Schema) für SEPA-Überwei-sungen in Euro (SEPA Credit Transfer, SCT) verfasst, das im Novem-ber 2012 in der Version 6.0 erscheint und für den Interbanken-


83

Neue Zahlungsinstrumente 3.2

Zahlungsverkehr verpflichtenden Charakter hat. Die Version 6.0 löstdie Version 5.1 ab, die sich aber nur unwesentlich von Version 6.0unterscheidet.

Dieses Schema umfasst derzeit noch keine Eilzahlungen, Fremdwäh-rungszahlungen (Nicht-Euro-Währungen) und Überweisungenaußerhalb des geografischen SEPA-Gültigkeitsbereichs. Das SCT-Regelwerk zeichnet sich unter anderem durch folgende Eigenschaf-ten aus (EPC-Regelwerk SCT, 2011 Seite 12):

� Trennung von Schema (eine einzelne Menge von Regeln, Verfah-ren und Standards) und darunterliegender Infrastruktur für denBetrieb

� klare und unmissverständliche Rechte und Pflichten der Beteilig-ten

� Verwendung von offenen Industriestandards für Zahlungsnach-richten

� Möglichkeit, innovative Mehrwertdienstleistungen anzubieten

Vorteile für NutzerFür das EPC bietet das SCT-Schema zahlreiche Vorteile hinsichtlichFunktionalität, Einfachheit, Kosteneffizienz und durchgehenderDatenverarbeitung (STP). Absender und Begünstigter der Zahlungprofitieren vor allem von folgenden Aspekten (EPC-Regelwerk SCT,2011, Seite 13):

� GebührenregelungEs gibt keine Gebührenabzüge beim Zahlbetrag. Der Auftraggeberund Begünstigte der Zahlung tragen ihre eigenen Kosten. (SHAREist die einzige Gebührenoption, und die Gebühren sollen von denBanken für die Beteiligten getrennt ausgewiesen werden.)

� BetragsgrenzeEs gibt keine Betragsgrenze für Überweisungen, wobei das Rah-menwerk hier individuelle Vereinbarungen zulässt, um beispiels-weise Risikomanagementaspekten Rechnung zu tragen.

� ErreichbarkeitDer Auftraggeber kann jedes Empfängerkonto innerhalb desSEPA-Raums erreichen.

� DatenformatEs gibt für den Interbanken-Zahlungsverkehr fest vorgegebene,auf XML-Standards basierende Nachrichtensätze.


84


� LaufzeitDie Laufzeit für Überweisungen, von der Auftragserteilung bis zurGutschrift, darf seit dem 1. Januar 2012 nicht länger als ein Bank-arbeitstag sein.

� ZahlungsstatusEs sind strukturierte und fest vorgegebene Zahlungsstatus fürRückgabe oder Storno von Zahlungsaufträgen (Reject/Return) vor-gesehen.

� VerwendungszweckEs gibt ein dediziertes Referenzfeld für den Auftraggeber mit einerLänge von 140 Zeichen, und die am Zahlungsverkehr beteiligtenKreditinstitute und Clearing-Häuser verpflichten sich dazu, diese(strukturierten oder unstrukturierten) Referenzinformationenunverändert zum Empfänger zu transportieren.

� KontenidentifikationAls Kontoidentifikation muss die internationale Kontonummer(International Bank Account Number, IBAN) verwendet werden.Die Verwendung des SWIFT-Codes (Bank Identifier Code, BIC)entfällt für Inlandszahlungen, wie in Kapitel 2, »SEPA – Von derVision zur Umsetzung«, erwähnt, zum 1. Februar 2014 und fürgrenzüberschreitende Zahlungen zum 1. Februar 2016.

� Einzel- und Sammelzahlungen (Single und Bulk Payments)Das Rahmenwerk unterstützt verschiedene Zahlungsformen.

� Bei einer Einzelzahlung werden das Konto des Auftraggebersund Begünstigten mit einem Betrag belastet/gutgeschrieben.

� Bei einer Sammelzahlung wird der Überweisungsbetrag aufmehrere Zahlungsempfänger verteilt (Bulk Payment Instruc-tions). Sammelzahlungen werden jedoch nicht im Regelwerkbehandelt.

Vorteile für Bankenund Clearing-

Häuser

Auch für Banken und Clearing-Häuser gibt es laut EPC zahlreichewirtschaftliche Vorteile. Sie könnten beispielsweise ihre Prozessevereinheitlichen, den Erwartungen ihrer Firmenkunden gerecht wer-den und auf Basis des Regelwerks Mehrwertdienste (Additional Opti-onal Services, AOS) anbieten, etwa elektronische Rechnungsstellungund Bezahlung. Diese AOS werden im Regelwerk des EPCs nichtnäher beschrieben und letztlich durch die Innovationsstärke der ein-zelnen Banken determiniert.


85


MehrwertdiensteAllerdings sieht das Regelwerk drei grundlegende Prinzipien für AOSvor (EPC-Regelwerk SCT, 2011, Seite 17):

� Die Mehrwertdienste dürfen die Interoperabilität des Regelwerksnicht gefährden oder Wettbewerbsbarrieren aufbauen.

� Die Mehrwertdienste sollten sich am Marktbedarf orientieren, unddas EPC behält sich ausdrücklich das Recht vor, allgemein benötigteAOS in künftigen Versionen in das Regelwerk aufzunehmen.

� Es soll weitgehende Transparenz bei gemeinschaftlichen Mehr-wertdiensten vorherrschen, insbesondere hinsichtlich der Ver-wendung von bestimmten Datenelementen. So sollen die Anwen-dungsregeln für die AOS zum Beispiel auf einer öffentlichen Web-site publiziert werden.

SCT-Regelwerk: Vier-Ecken-Modell

BeteiligteDas SCT-Regelwerk umfasst fünf Parteien:

� Auftraggeber der Überweisung (Zahlungspflichtiger)

� Begünstigter der Überweisung (Zahlungsempfänger)

� Bank des Auftraggebers

� Bank des Begünstigten

� das in den Interbanken-Zahlungsverkehr involvierte Clearing-Haus

Die Beziehungen zwischen diesen Parteien werden vom EPC in einemsogenannten »Vier-Ecken-Modell« (Four Corner Model) beschrieben(EPC-Regelwerk SCT, 2011, Seite 19). Abbildung 3.1 stellt die Bezie-hungen zwischen den Parteien im Vier-Ecken-Modell dar.

Das Schema und insbesondere die dabei verwendeten Datenformatehaben für den Interbanken-Zahlungsverkehr formal bindenden Cha-rakter: Banken oder Clearing-Häuser, die SEPA-konform sein möch-ten, sind verpflichtet, das Einhalten dieser Vereinbarung mithilfeeiner Beitrittserklärung (Adherence Agreement) schriftlich gegen-über dem EPC zu dokumentieren. Der entsprechende Prozess ist aufder EPC-Website ausführlich beschrieben (http://www.european-paymentscouncil.eu/).

SWIFT verwaltet die BIC-Codes aller Finanzinstitute, die SEPA-kon-form (und damit auch für SEPA-Transaktionen erreichbar) sind undein solches Adherence Agreement unterschrieben haben, in einem


86


SEPA Routing Directory (http://www.swift.com/products/sepa_routing_directory). Mehr als 4.500 Kreditinstitute sind bei Druckle-gung dieses Buches (September 2012) bereits SEPA-konform.

Abbildung 3.1 Vier-Ecken-Modell für SEPA-Überweisung

Für die Kommunikation zwischen Unternehmen und ihren Kredit-instituten stellt das SCT-Regelwerk mit seinen neuen Datenformatenformal lediglich eine Empfehlung dar. Nach dem Inkrafttreten derSEPA-Migrationsverordnung müssen sich Firmenkunden allerdingszwangsläufig mit den neuen SEPA-Regelungen und Formaten ver-traut machen.

Prozess der SEPA-Überweisung im Detail

Ablauf Im SCT-Regelwerk werden der gesamte Prozess der Abwicklungeiner SEPA-Überweisung sowie die dazu benötigten Nachrichten-sätze genau beschrieben (Regelwerk SCT, 2011, Seite 21 ff.).

1. Der Prozess beginnt beim Zahlungspflichtigen, der bei seiner Bankeine Überweisung einreicht. Das Regelwerk sieht dafür keinegenauen Fristen vor – diese können von den beiden Parteien indi-viduell vereinbart werden.

2. Die Bank des Zahlungspflichtigen prüft die Überweisung auf for-male Kriterien hin – insbesondere, ob das Format korrekt ist und

Lieferung von Waren oder Dienstleistungen (1)

Konto-gutschrift (6)

Überweisungs-auftrag (2)

Clearingund

Abrechnung

Übertragen derÜberweisung (4)

Weiterleiten derÜberweisung (5)

Konto-belastung (3)

SEPA-ECT-Schemahält

Schema ein

Zahlungs-pflichtiger

Zahlungs-empfänger

Bank desZahlungs-

empfängers

Bank desZahlungs-pflichtigen

hältSchema ein


87


die verwendeten IBANs und BICs bestimmten Plausibilitätskrite-rien genügen.

3. Zum Einreichungsdatum (Acceptance Date D) belastet die Bankdas Konto des Zahlungspflichtigen und leitet den Überweisungs-auftrag an das zuständige Clearing-Haus weiter.

4. Das Clearing-Haus reicht den Auftrag am Regulierungstag (Settle-ment Day) an die Bank des Zahlungsempfängers weiter.

5. Die Bank des Zahlungsempfängers prüft den Überweisungsauftragund informiert den Zahlungsempfänger über die Gutschrift. DieBank des Zahlungspflichtigen muss dem Begünstigten den Zah-lungsbetrag spätestens einen Banktag nach dem Einreichungsda-tum gutschreiben.

In Abbildung 3.2 ist der Prozess der SEPA-Überweisung schematischdargestellt. Auf die jeweils verwendeten Datensätze (DS-xx) gehenwir in Abschnitt 3.2.2, »Datensätze der SEPA-Überweisung«, nochdetailliert ein.

Abbildung 3.2 Prozess der SEPA-Überweisung

Zahlungs-pflichtiger

Bank des Zah- lungspflichtigen Clearing-Haus

Bank des Zah- lungsempfängers

Zahlungs-empfänger

Rückgabe

Storno

Storno

Storno

DS-01

DS-04

DS-02

DS-02

DS-03

DS-03

DS-03

DS-03

DS-03

DS-03

Überweisungs-auftrag erstellen

und weiterleiten

Überweisungs-auftrag prüfen und

validieren

Konto des Zahlungspflichtigen

belasten


gutschreiben

Prüfen, abrechnen und Regulierung

vorbereiten

Zahlungsauftrag prüfen und Gutschrift

auf Konto des Zahlungsempfängers

Prüfen, abrechnen und Regulierung

vorbereiten


gutschreiben

Rückgabe

Rückgabe


88


Rückruf Das EPC-Rahmenwerk sieht auch den Rückruf (Recall) von SEPA-Überweisungen durch den Auftraggeber der Zahlung vor (RegelwerkEPC, 2011, Seite 26 f.). Ein solcher Rückruf, der zu einem Storno derSEPA-Überweisung führt, ist gemäß dem EPC-Regelwerk binnenzehn Banktagen nach der Ausführung der Überweisung möglich. DasRegelwerk nennt drei mögliche Gründe für einen solchen Rückruf:

� Fehler bei der Übertragung

� Duplikate

� Betrugsfälle

Abbildung 3.3 Rückrufprozess der SEPA-Überweisung

Der Rückruf enthält einen Ursachenschlüssel für den Rückruf. ImGegensatz zu den Ausnahmefällen »Return« und »Reject« (siehe dennächsten Abschnitt) kann der stornierte Zahlungsbetrag vom originä-ren Zahlungsbetrag abweichen, da die Bank des Zahlungspflichtigeneine Gebühr für die Bearbeitung des Rückrufs einbehalten kann. DieBank des Zahlungspflichtigen kann den Rückruf ablehnen, sofern

Zahlungspflichtiger Bank des Zahlungspflichtigen Clearing-HausBank des

Zahlungsempfängers Zahlungsempfänger

Rückruf vorbereiten und ausführen

Prüfen, ob Abrechnungbereits erfolgt

Konto und Konditionenprüfen

Stornierung

Autorisierung fürRückruf erteilen


gutschreiben

negative Antwort

Verarbeitung undVerrechnung


gutschreibenGutschrift

Ablehnung

Autorisierungsanfragenegative Antwort

positive Antwort

negative Antwortfür Rückruf erzeugen

negative Antwort


89


einer der drei Gründe nicht zutrifft. Die Bank des Begünstigten mussin Abhängigkeit von der landesspezifischen Rechtslage den Rückrufsofort ausführen und das Konto des Begünstigten entsprechend belas-ten oder sogar eine Autorisierung des Begünstigten einholen. Im Falleiner fehlenden Autorisierung, ungenügender Kontodeckung oderaufgrund von anderen Gründen, die im Rahmenwerk aufgeführt sind(EPC-Regelwerk, 2011, Seite 28), versendet die Bank des Begünstigteneine negative Antwort an die Bank des Zahlungspflichtigen.

Abbildung 3.3 stellt den Rückrufprozess schematisch dar. In Version6.0 des SCT-Regelwerks, die ab November 2012 gültig ist, wird klar-gestellt, dass die Bank des Begünstigten für einen Rückruf zwar eineBearbeitungsgebühr erheben, diese aber nicht direkt vom Gutschrift-betrag abziehen darf.

Behandlung von Ausnahmen

Reject und ReturnWährend des Überweisungsprozesses sind verschiedene Zeitpunktevorgesehen, an denen Ausnahmen auftreten können. Dabei kann essich entweder um eine Rückgabe der Überweisung (Reject) odereinen Storno (Return) handeln. Während ein Reject vor dem Zeit-punkt der Interbanken-Verrechnung erfolgt, tritt ein Return erstdanach auf. Im Reject-Fall kommt die Überweisung vor dem Settle-ment, im Return-Fall nach dem Settlement (der Datensatz wurdebereits an die Bank des Zahlungsempfängers weitergeleitet) nicht zurAusführung. In beiden Fällen soll der originäre Zahlungsbetrag demZahlungspflichtigen gutgeschrieben werden, das heißt, es findet keinGebührenabzug durch die beteiligten Kreditinstitute statt. Außerdementhält das Regelwerk Fristen, die für den Versand der Nachrichteneinzuhalten sind (Reject: maximal ein Banktag; Return: maximal dreiBanktage).

In beiden Nachrichten ist ein Ursachenschlüssel vorgesehen, der hel-fen soll, die Ausnahme zu identifizieren. Gründe können zum Bei-spiel Formatfehler, ein falscher IBAN- oder BIC-Schlüssel oder einnicht (mehr) existierendes Konto sein.

In Version 6.0 des SCT-Regelwerks (ab November 2012) ist ergän-zend festgelegt, dass der Stornoprozess nicht zur Anwendungkommt, wenn der Zahlungsbetrag bereits auf dem Konto des Begüns-tigten gutgeschrieben wurde (in diesem Fall muss der Zahlungsemp-fänger eine neue Überweisung ausführen).


90


Im folgenden Abschnitt werden die Datensätze der SEPA-Überwei-sung näher beleuchtet.

3.2.2 Datensätze der SEPA-Überweisung

Sechs Datzensätze Das SCT-Regelwerk enthält Vorgaben hinsichtlich der Datensätze derSEPA-Überweisung. Es sind insgesamt sechs Datensätze für die SEPA-Überweisung vorgesehen (Regelwerk SCT, 2011, Seite 32 ff.):

� Überweisungsauftrag des Zahlungspflichtigen an die Bank desZahlungspflichtigen (Datensatz 01 – DS-01)

� Datensatz für den Interbanken-Zahlungsverkehr (DS-02)

� Datensatz für die R-Transaktionen Reject und Return (DS-03)

� Nachricht der Bank des Zahlungsempfängers an den Zahlungsemp-fänger (DS-04)

� Datensatz für den Rückruf des Überweisungsauftrags (DS-05)

� Datensatz für die Antwort auf den Rückrufauftrag (DS-06)

Attribute Tabelle 3.1 enthält eine vergleichende Übersicht der Attribute, die inden Datensätzen DS-01, DS-02 und DS-04 auf Basis der Version 5.1enthalten sind (die Neuerungen in Version 6.0 werden im Anschlussan die Tabelle erläutert). Die Attribute 01 bis 19 beziehen sich dabeiauf den Zahlungspflichtigen, während die Attribute 20 bis 39 zumZahlungsempfänger gehören. Alle übrigen Attribute werden zusätz-lich für eine SEPA-konforme Überweisung benötigt. Die zwingenderforderlichen Attribute sind mit M, die optionalen Attribute mit Ogekennzeichnet.

Attributnummer und Bezeichnung DS-01 DS-02 DS-04

01 IBAN des Zahlungspflichtigen M M –

02 Name des Zahlungspflichtigen M M M

03 Adresse des Zahlungspflichtigen O M(sofern enthalten)

–

04 Überweisungsbetrag in Euro M M M

05 Verwendungszweckangaben für den Zahlungsempfänger

O M(sofern enthalten)

M(sofern enthalten)

Tabelle 3.1 Attribute in den Datensätzen der SEPA-Überweisung


91


06 BIC der Bank des Zahlungs-pflichtigen

– M –

07 Durchführungsdatum des Auftrags (= D)


–

08 abweichender Zahlungspflichtiger (Originator Reference Party)


M(sofern enthalten)

09 Identifikationscode desabweichenden Zahlungspflichtigen


M(sofern enthalten)

10 Identifikationscode des Zahlungs-pflichtigen


M(sofern enthalten)

20 IBAN des Kontos des Zahlungs-empfängers

M M M

21 Name des Zahlungsempfängers M M M

22 Adresse des Zahlungsempfängers O M(sofern enthalten)

–

23 BIC der Bank des Zahlungs-empfängers

M M –

24 Identifikationscode des Zahlungs-empfängers


M(sofern enthalten)

28 Name des abweichenden Zahlungs-empfängers


M(sofern enthalten)

29 Identifikationscode desabweichenden Zahlungsempfängers


M(sofernenthalten)

40 Identifikationscode desSEPA-Überweisungsschemas

– M –


Tabelle 3.1 Attribute in den Datensätzen der SEPA-Überweisung (Forts.)


92


Auf die Inhalte der übrigen Datensätze DS-03, DS-05 und DS-06 sollan dieser Stelle nicht weiter eingegangen werden, da sie mit Aus-nahme des Datensatzes DS-03 nur für den Interbanken-Datenaus-tausch relevant sind.

Erweiterungenin Version 6.0

Version 6.0 des EPC-Regelwerks, die zum 17. November 2012 inKraft tritt und dann Version 5.1 ersetzt, enthält nur unwesentlicheÄnderungen. Dazu gehört im Wesentlichen die Klarstellung, dass derStornoprozess nicht zur Anwendung kommt, sofern der Zahlungsbe-trag bereits auf dem Konto des Begünstigten gutgeschrieben wurde(in diesem Fall muss der Zahlungsempfänger eine neue Überweisungausführen). Außerdem führt die neue Version des Regelwerks einneues Attribut (49) im Datensatz DS-06 ein, mit dem im Fall einesRückrufs aufgrund von Betrug weitere Informationen übertragenwerden können.

Kritik Einige Unternehmen haben kritisiert, dass der Datensatz DS-04wesentliche Daten des Zahlungspflichtigen nicht an den Zahlungsemp-fänger weiterleitet. IBAN und die Adresse des Zahlungspflichtigensowie der BIC der Bank des Zahlungspflichtigen werden nicht übertra-gen, könnten jedoch bei der Kontoauszugsverarbeitung im SAP-Systemdes Zahlungsempfängers sehr nützlich sein, um den auszugleichendenDebitorenposten eindeutig zu identifizieren. Die SAP-Kontoauszugs-verarbeitung wird in Abschnitt 6.5 detailliert beschrieben.

41 Referenz des Auftraggeberszur Überweisung

O M M

42 Interbanken-Settlement-Datum – M O

43 Transaktionsreferenz der Bankdes Zahlungspflichtigen

– M –

44 Verwendungszweck der Überwei-sung


M(sofernenthalten)

45 Transaktionsart der Überweisung O O O


Tabelle 3.1 Attribute in den Datensätzen der SEPA-Überweisung (Forts.)


118


3.3 Neue XML-Zahlungsformate: Standard ISO 20022

Der Europäische Rat für Zahlungsverkehr hat sich in seinen Imple-mentierungsrichtlinien dafür entschieden, bei den Formaten für SCTund SDD auf einen bereits bestehenden internationalen Standard fürden elektronischen Zahlungsverkehr zu setzen: ISO 20022, gelegent-lich auch unter dem Akronym UNIFI (Universal Financial IndustryMessage Scheme) bekannt.

3.3.1 Motivation für den ISO-20022-Nachrichtenstandard

Der ISO-20022-Standard »strebt eine weltweite Konvergenz von exis-tierenden und neuen Nachrichtenstandards aus verschiedenen Berei-chen des Finanzwesens an« und »bietet eine Plattform, die einen ein-heitlichen Entwicklungs- und Modellierungsprozess von Nachrichtenvorgibt«. (BdB, ISO 20022 im Überblick, 2006, Seite 2). Dabei umfasstder Standard nicht nur Nachrichten für den Zahlungsverkehr, son-dern harmonisiert auch Nachrichten in den Bereichen Wertpapiere,Außenhandelsfinanzierung und Treasury. Mittel- bis langfristig sollendie UNIFI-Nachrichtentypen die aktuell in der SWIFT-Gemeinschaftverwendeten MT-Formate (Message Types) ablösen. UNIFI-Formatewerden mitunter auch als MX-Formate bezeichnet.

Standardvielfalt Weltweit existiert eine Vielzahl von Standardisierungsorganisatio-nen, die im Finanzdienstleistungsbereich einheitliche XML-Stan-dards für die Kommunikation zwischen verschiedenen Geschäftspar-teien entwickeln möchten. Obwohl niemand infrage stellt, dass dieseBemühungen sehr wichtig für eine verbesserte Kommunikation sind,besteht natürlich die Gefahr, dass letztendlich viele Standards paral-lel existieren und sich die Nachrichten sogar semantisch überlappen.Damit sind weder Interoperabilität noch durchgehende Datenverar-beitung gewährleistet, und die beteiligten Geschäftspartner müssenmit viel Aufwand die Nachricht eines Standards in das Format einesanderen Standards konvertieren. Abbildung 3.9 stellt diese Proble-matik schematisch dar.

Die mangelnde Standardisierung erhöht signifikant die Implementie-rungs- und Betriebskosten für Unternehmen und Finanzinstitute undverringert mögliche Skaleneffekte. Tatsächlich ist es sogar so, dassjeder zusätzliche Standard zu einer exponenziell zunehmenden Kom-


119

Neue XML-Zahlungsformate: Standard ISO 20022 3.3

plexität führt, wie ein Beispiel der ISO zeigt (ISO, Introduction to ISO20022, 2007, Folie 6). Wenn sieben Standards untereinander kom-munizieren sollen, werden 7 × 6 = 42 Schnittstellen benötigt. Kom-men nur drei weitere hinzu, müssen jeweils zehn Standards mit denneun anderen kommunizieren, was mehr als doppelt so viele Schnitt-stellen bedeutet (10 × 9 = 90 Schnittstellen).

Abbildung 3.9 Schnittstellenvielfalt aufgrund mangelnder Standardisierung

Beispiel zur Verringerung der Komplexität

Ganz anders sieht das Rechenbeispiel aus, wenn sich die unterschied-lichen Standardisierungsgremien um ein gemeinsames Nachrichten-modell bemühen. In unserem Beispiel müsste die Formatumsetzungnur noch jeweils einmal implementiert werden, um eine Nachricht andas Nachrichtenmodell zu übergeben und von dort zu empfangen. Dasbedeutet, dass nur zwei Schnittstellen pro Standard, 7 × 2 = 14 Schnitt-stellen, benötigt werden. Mit diesem Vorgehen wird eine Prozessinte-gration erheblich vereinfacht, und es fallen weniger Konvertierungs-aufwände an. Diese Vereinfachung ist in Abbildung 3.10 dargestellt.

Abbildung 3.10 Verringerte Komplexität durch ISO 20022

RosettaNet

SWIFT

Proprietäres Format

EDIFACT

IFX

OAGi

TWIST n x (n–1) = 42 SchnittstellenEDIFACT

RosettaNet

SWIFT

Proprietäres Format

EDIFACT

IFX

OAGi

TWIST

ISO 20022-Nachrichten-

modell

n x 2 = 14 Schnittstellen


120


Exkurs: Standardisierungsinitiativen im Finanzdienstleistungsbereich (Auswahl)

Im Finanzdienstleistungsbereich sind unter anderem die folgenden Stan-dardisierungsinitiativen von Bedeutung:

ebXMLElectronic Business Using Extensible Markup Language – Start im Jahr1999, fokussiert auf E-Commerce

FIXMLFinancial Information Exchange Markup Language – seit 1999 vor allem inden USA bedeutendes Protokoll für den Wertpapierhandel

FinXMLDigital Language for Capital Markets – besteht seit 1999 und ist fokussiertauf den Datenaustausch von derivativen Produkten.

FinTSFinancial Transaction Services – deutscher Standard für den Betrieb vonOnline-Banking und Nachfolger des HBCI-Standards (Homebanking Com-puter Interface)

IFXInteractive Financial Exchange – besteht seit 1999 und ist auf den Aus-tausch von Finanzdaten zwischen Unternehmen zugeschnitten (etwa imBereich der elektronischen Rechnungsstellung).

TWISTTransaction Workflow Innovation Standards Team – besteht seit 2001und beschäftigt sich vor allem mit dem strukturierten Nachrichtenaus-tausch zwischen Unternehmen und Banken.

RosettaNetKonsortium von mehr als 600 Firmen, vor allem aus dem Hochtechnolo-giesektor, das sich um E-Business-Standards kümmert

SWIFT XML – SWIFTSociety for Worldwide Interbank Financial Telecommunication – definiertneue XML-basierte Nachrichtenformate (MX-Nachrichten), die die bishe-rigen MT-Nachrichten (Message Types) ablösen sollen.

XBRLExtensible Business Reporting Language – XML-Standard zum Erstellenelektronischer Dokumente im Bereich der Finanzberichterstattung


121


3.3.2 Funktionsweise von ISO 20022

ISOISO 20022 stellt den verschiedenen Standardisierungsorganisationeneine Plattform zur Verfügung, um einerseits unabhängig voneinan-der Nachrichten zu entwickeln und sie anschließend bei der Interna-tionalen Organisation für Normung (ISO) einzureichen und als welt-weit gültigen Standard zertifizieren zu lassen.

Die ISO wurde 1946 gegründet und arbeitet in vielen Bereichen aninternationalen Normen. In der ISO sind mehr als 150 Länder vertre-ten. Insgesamt besteht der Standard ISO 20022 aus sechs Teilen:

1. gesamte Methodik und Formatspezifikationen des ISO-20022-Nachrichtenverzeichnisses

2. Rollen und Verantwortlichkeiten der Standardregistrierungsgre-mien

3. ISO-20022-Modellierungsrichtlinien

4. ISO-20022-XML-Designregeln

5. ISO-20022-Rekonstruktion (Reverse Engineering)

6. ISO-20022-Nachrichtenübertragungsform

Ablauf der Registrierung

Registration Management Group

Am Beginn des Registrierungsprozesses neuer UNIFI-Nachrichtensteht eine betriebswirtschaftliche Rechtfertigung. Damit soll die ein-reichende Standardisierungsorganisation den ungefähren Umfangder zu entwickelnden Nachrichten beschreiben und den Grund nen-nen, warum diese benötigt werden. Dazu gehört auch, dass die Ziel-gruppe, der mögliche Nutzen und das Einsparpotenzial geschätztwerden. Die einreichende Organisation soll zudem andere Initiati-ven, die in die Entwicklung involviert sein werden, und die voraus-sichtliche Entwicklungszeit nennen. Dieser Vorschlag wird anschlie-ßend von der Registrierungsverwaltungsgruppe (RegistrationManagement Group, RMG) geprüft.

Die RMG ist das bedeutendste UNIFI-Registrierungsgremium, über-wacht den gesamten Registrierungsprozess und berichtet direkt andas technische ISO-Komitee TC68, das für alle ISO-Standards miteinem finanzwirtschaftlichen Hintergrund verantwortlich ist (unteranderem auch BIC und IBAN). Die RMG setzt sich aus erfahrenen


122


Industrievertretern zusammen und befindet darüber, ob der einge-reichte Entwicklungsvorschlag in den UNIFI-Rahmen passt, keineDublette von bereits existierenden Nachrichten ist und tatsächlicheinen Mehrwert darstellt. Wenn die RMG den Antrag genehmigt,legt sie auch fest, welche Standardevaluierungsgruppe (StandardsEvaluation Group, SEG) sich mit den Nachrichten befassen soll. Abdiesem Zeitpunkt gelten die neuen Entwicklungen als Anwärter fürISO-20022-Nachrichten. Für die Nachrichten des Zahlungsverkehrsgibt es eine eigene SEG.

RegistrationAuthority

Die mit dieser Aufgabe betraute SEG überprüft und billigt denUmfang der eingereichten Nachrichten. Außerdem stellt die SEGsicher, dass die richtigen Standardisierungsorganisationen in die Ent-wicklung involviert sind. Sobald die SEG grünes Licht gegeben hat,beginnt die Standardisierungsorganisation, die den Vorschlag einge-reicht hat, mit der Entwicklung von UNIFI-konformen Nachrichten-modellen. Dabei steht ihr die ISO-20022-Registrierungsinstanz(Registration Authority, RA) mit Rat und Tat zur Seite. Die RA gene-riert unter anderem die XML-Schemata und hilft bei der Dokumen-tation der neuen Nachrichten für die SEG. Die RA wacht gewisserma-ßen über das UNIFI-Nachrichtenverzeichnis, eine zentraleDatenbank, in der unter anderem die Bestandteile der Nachrichten,die Geschäftsprozessmodelle und die abgeleiteten XML-Schemataenthalten sind. Die RA stellt zudem sicher, dass neue Einträge mitden verabschiedeten technischen Spezifikationen übereinstimmen,und veröffentlicht das Verzeichnis im Auftrag von ISO auf der Inter-netseite www.iso20022.org. Die Rolle der Registrierungsinstanz hatSWIFT übernommen. Als Standardisierungsorganisation von welt-weit gültigen Zahlungsverkehrsnachrichten kann SWIFT darüberhinaus wie jede andere Organisation Nachrichten, die nach den Vor-gaben von ISO 20022 entwickelt wurden, bei ISO 20022 registrierenlassen.

UNIFI-Verzeichnis Auf der Basis der erarbeiteten Dokumentation bewertet die SEG dieneuen UNIFI-Nachrichten. Wichtigstes Ziel ist dabei, die Zustim-mung von künftigen Anwendern zu erhalten. Dabei unterstützt sieauch die Standardisierungsorganisation, die den neuen Satz vonNachrichten eingereicht hat. Sobald die Nachrichten von der SEGgenehmigt wurden, ändert die RA den vorläufigen Status des Ein-trags im Nachrichtenverzeichnis, vergibt einen offiziellen Registrie-


123


rungsstatus und veröffentlicht die neuen UNIFI-Nachrichten imNachrichtenkatalog auf www.iso20022.org. Abbildung 3.11 fasst denAblauf der ISO-20022-Zertifizierung zusammen.

Abbildung 3.11 Ablauf einer ISO-20022-Zertifizierung für neue Nachrichten

XML-Nachrichten-schemata

Das UNIFI-Verzeichnis besteht aus dem Datenverzeichnis und einemKatalog von Geschäftsprozessen. Das Datenverzeichnis enthält Enti-tätenmodelle, die von betriebswirtschaftlichen Transaktionen ver-wendet werden. Diese Entitäten werden als betriebswirtschaftlicheKomponenten bezeichnet. Daneben enthält das DatenverzeichnisNachrichtenbausteine, die Modelle der Nachrichten darstellen, diewährend der Ausführung von betriebswirtschaftlichen Transaktio-nen immer wieder verwendet werden. Dabei werden Nachrichtenals Kombinationen solcher Nachrichtenbausteine modelliert. Abbil-dung 3.12 erläutert diese Zusammenhänge.

Veröffentlichung

neuen Nachrichtensatz einreichen

betriebswirtschaftliche Rechtfertigung

Projektgenehmigung und Zuordnung zu einer Standard-Evaluierungsgruppe (SEG)

Genehmigung des Umfangs

Entwicklung und vorläufige Registrierung

betriebswirtschaftliche Gültigkeit und technische Beurteilung

offizielle RegistrierungISO-20022-Nachrichten

Anwärter fürISO-20022-Nachrichten

Verzeichnis

Wörterbuch

Katalog


124


Abbildung 3.12 Inhalt des UNIFI-Verzeichnisses

Die Datentypen, die zur Darstellung der verschiedenen Formate oderWerte dieser Komponenten und Bausteine verwendet werden, sindebenfalls Bestandteil des Datenverzeichnisses. Der Katalog derGeschäftsprozesse beinhaltet zum einen die verschiedenen betriebs-wirtschaftlichen Modelle und stellt die Geschäftsprozesse sowie diebenötigten Informationen der beteiligten Parteien dar. Daneben ent-hält der Katalog die betriebswirtschaftlichen Transaktionen, die not-wendig sind, um eine finanzwirtschaftliche Transaktion ganzheitlichabzuwickeln. Dazu gehören insbesondere der dabei verwendeteNachrichtenfluss und die Beschreibung jedes Nachrichtenmodells.Außerdem umfasst der Katalog auch die XML-Nachrichtenschemata,die aus den Nachrichtenmodellen generiert werden. Da hierzu eineUML-nach-XML-Abbildung zum Einsatz kommt, lässt sich jedes Ele-ment in einem XML-Schema letztlich zu einer betriebswirtschaftli-chen Komponente zurückverfolgen, wie sie in einer betriebswirt-schaftlichen Transaktion verwendet wird.

3.3.3 Struktur der ISO-20022-Nachrichten

PAIN, ACMT,CAM und PACS

Die ISO-20022-Zahlungsverkehrsnachrichten sind in PAIN-, PACS-,ACMT- und CAMT-Nachrichten unterteilt.

XML-Schemata (generiert aus Nachrichten)

Katalog von Geschäftsprozessen

Datenverzeichnis

Nachrichten-bausteine

betriebswirtschaft-liche Komponenten

Nachrichten (bestehen aus Nachrichtenbausteinen)

betriebswirtschaftliche Transaktionen

B wird aus A abgeleitet UML XMLA B


449

Index

A

ABAP 191, 217, 225, 385ABAP-Proxy-Laufzeit 391Abrechnung 40Accelerated SAP 423Acceptance Date 87ACK-Nachricht 365, 376, 392Acknowledgement 365, 376Adapter-Framework 385Additional Optional Service (AOS) 80,

84, 94, 130, 162, 217, 410, 423Adherence Agreement 85Advanced Adapter Engine 378, 380,

385, 387ALE � Application Link Enabling

(ALE)Alert-Framework 346Alert-Kategorie 346Altmandat 101ALV 262ALV-Liste 262, 265, 344Amendment 100Änderungs-Log 195Anwendung 172Application Link Enabling (ALE) 287,

334logisches System 287Partnervereinbarung 289Verteilungsmodell 288

Association for Financial Professionals (AFP) 157

AttributBANKL 253BANKN 253BANKS 253

auslaufendes Mandat 199Außenwirtschaftsverordnung (AWV)

423Auto Payments 334Automated Clearing House (ACH) 40,

423Automated File Transfer 373automatische Folgefunktion 337Avisprogramm 214AWV-Meldung 235

B

BAdI � Business Add-in (BAdI)Bank Identifier Code (BIC) 30, 84,

139, 223, 253, 264, 359, 361, 423Aufbau 140BIC Directory 139Datenimport 265Datenübernahme 264kritische Punkte 141länderspezifische Prüfung 266Schlüssel 139Umstellung 264

Bankbuchhaltung 324Bankkontonummer, technische 256Bankkreis (SAP In-House Cash) 275,

289, 302, 312bankkreisübergreifendes Buchen

(SAP In-House Cash) 302bankkreisübergreifendes Buchen

(SAP In-House Cash), Leitweg 303Bankleitzahl 42Bank-Verlag GmbH 257BAPI-Schnittstelle, externe Mandats-

verwaltung 205Batch 222, 235Batch bearbeiten 335Batching-Regel 329BEN-Kostenregelung 47Benutzersignatur

eigenes Schlüsselpaar 340Schlüsselpaar des Systems 340

BITKOM 21Bruttosystem 77Buchungskreis 196, 214, 227, 236,

348Buchungskreis (SAP In-House Cash)

273, 276Buchungsregel, Geschäftsvorfallcode

245Bulk Payment Instruction 84Bundesverband Informationswirt-

schaft, Telekommunikation und neue Medien e.V. � BITKOM

Business Add-in (BAdI) 330BNK_BADI ORIG_PAYMT_CHG 337BNK_BADI_BATCH_GROUPING

330


450

Index

BNK_BADI_FILE_ERROR_ALRT 347BNK_BADI_ORIG_PAYMT_CHG

353BNK_BADI_PAYM_STAT_ALRT 347CHECK_INVOICE_ATTACHMENT

338ES_FIEB_MAPPING_X 251GET_INVOICE_ATTACHMENT 338

Business Application Programming Interface (BAPI)BAPI_ SEPAMAND1_EXISTENCE-

CHECK 205BAPI_SEPA_ SEPAMAND1_DIS-

PLAY 205BAPI_SEPAMAND1_CREATE 205BAPI_SEPAMANDATE_ CHANGE1

205BAPI_SEPAMANDATE_ CREATE1

205BAPI_SEPAMANDATE_ DISPLAY1

205BAPI_SEPAMANDATE_ EXISTENCE-

CHECK 205BAPI_SEPAMANDATE_ READ1 205

Business FunctionFIN_FSCM_BNK 321FIN_FSCM_INTEGRATION 321

Business Process Engine 379

C

Cash Concentration (SAP In-House Cash) 271, 279, 308

Cash Management 47, 270, 357, 409, 423

Certificate Revocation List 341Certification Authority 339, 340CGI-Formatempfehlung 133Clearing 40, 76, 423Clearing-Haus 40, 75, 80

paneuropäisches 80SEPA-kompatibles 76

Clearing-Partner (SAP In-House Cash) 289

Co-Branding 150Collector 321, 325, 326Common Global Implementation (CGI)

133, 234, 423Compliance 317, 319

Cross-Border-Zahlung (SAP In-House Cash) 297, 298

Cryptoboard 341Cut-off-Zeit 99

D

Data Medium Exchange Engine (DMEE) 208, 217, 227, 231, 423Aufgabe 217Baumtyp 217Ein- und Ausgangsdatei 217Knotentyp 220PMW 218XML-Datei 221

Data Medium Exchange Engine (DMEE), Formatbaum 217, 218, 224, 235Aufbau 221, 222Exit-Funktion 221Hierarchie 223Knoten 220Kopfdaten 220Referenz-ID 220SEPA-Lastschrift 235

DatensätzeE-Mandat 114SEPA-Basislastschrift 105SEPA-Überweisung 90

Datenträger anzeigen 216Datenträgerverwaltung

�DTA-VerwaltungDebitor 173, 188Debitorenbuchhaltung � FI-ARDelimeter 246Delivery Notification 388Dematerialisierung 109Deutsche Kreditwirtschaft 130, 233,

244, 247, 423Feldschlüssel 247Formatempfehlung 130Namensraum 234

Dialogtransaktion 187digitale Signatur 318, 338, 373

Signaturbenutzer 342Signaturprüfschlüssel 339Signaturschlüssel 339

DMEE � Data Medium Exchange Engine (DMEE)


451

Index

Dreiparteiensystem 148dreistelliger Fehlercode 249DTA-Verwaltung 212, 215

E

EBA Clearing 69, 78, 81ebXML (Standardisierungsinitiative)

120ECOFIN-Rat 32, 35, 64, 424ECON-Ausschuss 65, 424EG-Richtlinie 2007/64 142EG-Verordnung 2560/2001 28, 30,

31, 142EG-Verordnung 924/2009 33eilige Zahlung 337Einmallastschrift 98, 107E-Invoicing 410, 414, 415

Buyer-Direct-Modell 415Consolidator-Modell 415Seller-Direct-Modell 415

Einzugsermächtigung 97Einzugsermächtigung migrieren 101Einzugsgebühr 37Electronic Banking Internet Communi-

cation Standard (EBICS) 423Electronic Banking Internet Communi-

cation Standard (EDIFACT) 356, 363

Electronic Bill Presentment and Payment (EBPP) 159

elektronisches Mandat 103, 114E-Mandat 103, 114

Ablauf 104Beteiligte 103Datensätze 114

Empfängeradapter 386Empfängerermittlung 382Empfängervereinbarung 382, 387EMV-Chip 151Enhancement Package � Erweite-

rungspaket (EHP)Enterprise Services Repository 379,

381E-Payments 414, 419EPC � European Payments Council

(EPC)EPC-Regelwerk 58E-Reconciliation 414, 417, 418erweiterte IBAN-Funktionalität 167

Erweiterungspaket (EHP) 168, 321, 374

Erweiterungspaket 2 (EHP 2) 168Erweiterungspaket 3 (EHP 3) 168Erweiterungspaket 6 (EHP 6) 167,

250E-SEPA 414, 416, 424ESR-Content 381EU-Direktive 2009/110/EC 417EU-Richtlinie 2001/115/EG 417Euro 27Euro Alliance of Payment Schemes

(EAPS) 150Euro Banking Association (EBA) 31,

40, 54, 69, 77, 78, 81, 357EURO1 78, 424Euro-Krise 27Europäische Freihandelszone

� European Free Trade Association (EFTA)

Europäische Kommission 28, 32, 33, 41, 43, 54, 59, 64, 417, 424

Europäische Rat für Zahlungsverkehr � European Payments Council (EPC)

Europäische Union (EU) 29, 48, 59, 424

Europäische Währungsunion 27Europäische Zentralbank (EZB) 28,

32, 40, 41, 54, 65, 79, 413, 424Direktorium 66Rat 66

Europäischen Union, Rat Wirtschaft und Finanzen � ECOFIN-Rat

Europäischer Wirtschaftsraum (EWR) 50, 424

Europäisches Komitee für Bankstan-dards 134

Europäisches Parlament, Ausschuss für Wirtschaft und Währung � ECON-Ausschuss

Europäisches System der Zentralban-ken (ESZB) 424

Europaparlament 28, 32, 64, 143European Associations of Corporate

Treasurers (EACT) 417, 423European Committee for Banking Stan-

dards (ECBS) 134, 424European Currency Unit (ECU) 81European Free Trade Association

(EFTA) 50


452

Index

European Payments Council (EPC) 27, 28, 31, 47, 54, 129, 145, 149, 235, 413, 419, 424

EU-Verordnung 260/2012 29, 34, 35Inhalt 35SEPA-Umstellung 36

Eventtechnik 173Extensible Markup Language (XML)

58, 118, 129, 207, 217, 225, 292, 345, 357, 360, 363, 377, 378, 383, 387, 390, 416, 427Kontoauszug 167Kontoauszug einlesen 250Nachrichtenschema 124Namensraum 232Schema (Deutsche Kreditwirtschaft)

233Standard 118

externe Mandatsverwaltung 205

F

Feldbezeichner 246, 248, 249Feldschlüssel, Deutsche Kreditwirt-

schaft 247FI-AR 172, 188, 191, 205, 323FI-CA 172, 187, 191, 205, 243, 352File Transfer Protocol (FTP) 385File-/FTP-Adapter 382, 387, 390FileAct 424FileAct-Szenario 377File-Adapter 373, 375, 376Financial Action Task Force (FATF)

371, 424Financial Services Action Plan 29Financial Supply Chain 19Financials SWIFT Bank Statement

(FI-SBS) 247FIN-Szenario 375FIN-Teilstreckenverfahren 365FinTS (Standardisierungsinitiative)

120FinXML (Standardisierungsinitiative)

120FIXML (Standardisierungsinitiative)

120Format

BACS 325DTAUS0 325PKCS#7 340S/MIME 340

FormatempfehlungCommon Global Implementation (CGI)

134Deutsche Kreditwirtschaft 130

Four Corner Model � Vier-Ecken-Modell

Freigabeobjekt 332Freigabetransaktion 334Freigabeverfahren 332Fristen, SEPA-Lastschrift 98Funktionsbaustein

DMEE_EXIT_SEPA_21 231DMEE_EXIT_SEPA_31 231DMEE_EXIT_SEPA_41 231FI_APAR_MANDATE_AFTER_SAVE

176FI_APAR_MANDATE_AUTHORITY_

CHCK 176FI_APAR_MANDATE_CHECK 175FI_APAR_MANDATE_DEFAULT_

CRDID 174FI_APAR_MANDATE_DEFAULT_

DATA 174FI_APAR_MANDATE_DEFAULT_

MNDID 175FI_APAR_MANDATE_DOUBLE-

CLICK 175FI_APAR_MANDATE_ENHANCE

175FI_APAR_SEPA_FIELDS 178FKK_SEPA_AFTER_SAVE 176FKK_SEPA_AUTHORITY 176FKK_SEPA_BEFORE_SAVE 175FKK_SEPA_DEFAULT_ADR 174FKK_SEPA_DEFAULT_CRDID 174FKK_SEPA_DEFAULT_MNDID 175FKK_SEPA_DOUBLECLICK 175FKK_SEPA_ENHANCE 175SEPA_MANDATES_API_CHANGE

203SEPA_MANDATES_API_CREATE

203Funktionsgruppe FPAYM_SEPA 231

G

Gebührenregelung SHARE 83Geschäftsvorfallcode 244, 249Geschäftsvorfallschlüssel umwandeln

344


453

Index

Gläubiger-Identifikationsnummer � Kreditorenidentifikator

globale Sperre 191grafischer Editor 217Granularität 214Großbetragszahlung 38, 78

H

Hardware-Security-Modul 365Harmonisierungsvorteil (SAP In-House

Cash) 270Hash Message Authentication Code

(HMAC) 425Hash-Wert 375, 377Haupt- und Teilvorgang 173Hauptbuch 173Hauptbuch (SAP In-House Cash) 293Hauptbuchkonto (SAP In-House Cash)

273Hauptbuchübergabe (SAP In-House

Cash) 308High Value Payment 38HMAC-SHA256 373, 375, 377, 389

I

ibi Research 20IDoc 214, 291, 295, 299, 301, 302,

304, 305, 386, 425DIRDEB 202FINSTA 289, 297, 301PAYEXT 202, 286, 295, 299, 302,

305PEXR2002 312PEXR2003 202, 312

IDoc-Segment E1IDS01 312IFX (Standardisierungsinitiative) 120In-House Cash Center 271, 273, 280,

286, 294, 297, 299, 301, 306, 311Gebühren belasten 274Stammdaten 275Verwendung 270Zahlungsauftrags-Browser 293Zinsen berechnen 274

Integration Builder 379, 382, 386Integration Directory 379, 382, 387Integration Engine 379, 383, 387,

391

Integration Server 390InterAct 425Interface-Ermittlung 382Intermediate Document � IDocInternational Bank Account Number

(IBAN) 30, 84, 108, 134, 137, 188, 223, 253, 256, 318, 330, 425Hin- und Rückverfahren 257IBAN only 255Konversionstabelle 137Konvertierung 154Länge und Aufbau 135Massengenerierung 257Prüfung 262Prüfziffer 137Prüfziffernberechnung 138Rückdatei 263Service 258Serviceportal 257Variante 135

International Bank Account Number (IBAN), FunktionalitätEinschränkung 256erweiterte 255klassische 254Konfiguration 256

International Bank Account Number (IBAN), Umstellung 257Deutschland 257Österreich 259SAP 260Schweiz 259

International Standards Team Harmo-nization 359

Internationale Organisation fürNormung (ISO) � ISO

interne Revision 332Isabel 42ISO 108, 121ISO 20022 118, 208, 222, 223, 235,

250, 359, 360, 363, 377, 390, 393, 425ACMT-Nachricht 124CAMT-Nachricht 124Common Global Implementation (CGI)

133Funktionsweise 121Identifikatoraufbau 129Nachrichtenelemente 129Nachrichtenenstandard 118Nachrichtenidentifikator 128


454

Index

PACS-Nachricht 124PAIN-Nachricht 124Registrierung 121Registrierungsinstanz 122Standard, Schweiz 152Struktur 124Überweisung 223Zahlungsformat 118Zertifizierung 123

ISO-Namensraum 232

J

Java 379, 384, 386

K

Kartenmarkt 148Kommunikationskanal 377, 382, 387Kontoauszug (MT-940) 244Kontoauszugsformat

Feld 86 246Feldschlüssel 246Steuerzeichen 246

Kontoauszugsmonitor 348Anzeige 350Status 349

Kontoauszugsverarbeitung 243Kontoidentifikationsnummer 137Kontoinformation ein- und auslesen

260Konzentrator 368Korrespondenzbank 77Kreditorenidentifikator 108, 187

Aufbau 108Erwerb 109

Kunde-Bank-Beziehung 125

L

länderspezifische Prüfung BIC 266Liquiditätsvorschau 353Lissabon-Agenda 29Local Authentication 389Löschvormerkung 265Low Value Payment 38

M

Macro Payment 419MA-CUG 369, 370Maintenance Optimizer 400Mandat � SEPA-MandatMandatsverwaltung � SEPA-Mandats-

verwaltungMapping 384, 390Massenzahlung 38, 79, 208MasterCard 148McCreevy, Charlie 33, 46MGUID-Schlüssel 200Micro Payment 162, 419Migration, Altmandant 101Migrationsregel 102Mitentscheidungsverfahren 65Mobile Payment 33, 162, 414MOD-97-10-Algorithmus 108Modulo 97-10 137Modulprozessor 386MT-940-Kontoauszug 244MultiCash 42Multilateral Interchange Fee

� EinzugsgebührMX-Nachricht 366

N

NachrichtBankToCustomerStatement 250CustomerCreditTransferInitiation

222CustomerDirectDebitInitiation 235

NAK-Nachricht 365, 376Netting 40, 270Nettosystem 77New Legal Framework 33Niederlassungsnetz 77Not-Acknowledgement 365, 376

O

One-leg-out-Zahlung 52Online Certificate Status Protocol

(OCSP) 341Opportunitätskosten 46Organisation for Economic Coopera-

tion and Development (OECD) 371


455

Index

Österreich, SEPA-Umstellung 153IBAN-Konvertierungsservice 154Namensraum 154

OUR-Kostenregelung 47

P

Pan-European Automated Clearing House (PE-ACH) 76, 80, 81, 425

Parallelisierungstechnik 173Parallelphase 28Payload 387Payment Factory 47, 157, 158, 269,

270, 271, 294, 299, 314, 351Payment Institution 33Payment Medium Workbench (PMW)

207, 227, 327, 392, 405, 425Buchungskreisdaten 210DMEE 218Granularität 214, 215Konfiguration 210Massenzahlung 208Programm 216Prozessablauf 213Selektionsvariante 212Verwendungszweck 210, 212

Payment Milestone Program 417Payment Services Directive (PSD) 23,

28, 32, 52, 143, 145, 425SEPA 147

Payment Status Report 125PayPal 33Pflege-View

V_SEPA_CTRL 174V_SEPA_CUST 176, 178V_SEPA_FIELDS 177, 178

PIN-Verfahren 151PKCS#7 425PMW � Payment Medium Work-

bench (PMW)Portal SEPA-Now 170Preisprofil

globales 45regionales 45

Pre-Notification 98Proxy 390Public-Key-Infrastruktur (PKI) 340,

341, 356, 365, 366, 425

R

Rat der Europäischen Union 61Rechnungsstellung, elektronische

159, 162Rechtsrahmen, neuer 33Referenzinformation 113Refund 94, 100, 105Refusal 94, 99Registration Authority 122Registration Management Group

(RMG) 121Regulierung 40Reject 89, 90, 94, 99Relevé d’Identité Bancaire 42Remote Function Call (RFC) 203, 288Repair Fee 142Report

FEB_FILE_HANDLING 250RF_CONVERT_XEZER_TO_MAN-

DATE 196, 197RFAWVZ40N 235RFBVALL_0 266RFBVBIC2 264, 265RFEBBU10 247RFEBKA00 250RFEKA400 247RFFOAVIS_FPAYM 213, 214RFIBANMD 260, 263RSEPAARR01 203RSEPAARR02 203RSEPAARR03 203RSEPALIST 191, 193SAPFPAYM 213, 214, 233SAPFPAYM_SCHEDULE 213

Request for Cancellation 99Return 89, 90, 94, 100Reversal 94, 100Revocation 94, 99RFC � Remote Function Call (RFC)Richtlinie 2005/60/EG 146Richtlinie über Zahlungsdienste 23,

28, 32, 52, 142RosettaNet (Standardisierungsinitia-

tive) 120, 417Routing, logisches 384R-Transaktion 90, 94, 125, 249Rückgabe der SEPA-Überweisung 89Rückgabegrund 99Rückläuferverarbeitung 250


456

Index

Rücknahmeausgleich 328Rückrufprozess, SEPA-Überweisung

88Rulebook 58, 68Runtime Workbench 380, 384

S

SAP Bank Communication Manage-ment 24, 314, 315, 325, 332, 347, 376Freigabehistorie 333Funktionalität 319Integration 351Prozesse 319, 320

SAP Bank Communication Manage-ment, Zahllauf 322

SAP Bank Communication Manage-ment, ZahlungBatching 328eilige 337freigeben 332mobile Freigabe 338

SAP Bank Communication Manage-ment, Zahlungsanordnung 324

SAP Bank Communication Manage-ment, Zahlungsdatei 325

SAP Bank Communication Manage-ment, Zahlungsfreigabemonitor 334

SAP Bank Communication Manage-ment, Zahlungshistorie 344

SAP Bank Communication Manage-ment, Zahlungsprogramm 322Ablauf 322Zahlungsvorschlag 322

SAP Bank Communication Manage-ment, Zahlungssammler 325

SAP Bank Communication Manage-ment, Zahlungssammler stornieren 327, 328

SAP Bank Communication Manage-ment, Zahlungsstatusmonitor 343, 346, 350aktualisieren 342Ausnahmezustand 346Timeout 346

SAP Business Workflow 333SAP Cash and Liquidity Management

275, 318, 413

SAP ECC 6.0 321SAP for Banking 332SAP In-House Cash 24, 269, 324, 351,

392dezentrale Organisationsform 271gemischte Organisationsform 272IDocs 289lokales Zahlen 298Rollenkonzept 276SAP-Mandatsverwaltung 202Transaktionsarten pflegen 290zentrale Organisationsform 271zentrales Zahlen 294

SAP In-House Cash, Geschäftspartner 276Ansprechpartner 278Kontoauszugsempfänger 278Kontoführer 277Kontoinhaber 277Verfügungsberechtigter 277

SAP In-House Cash, Inter-Company-Konten 274

SAP In-House Cash, Kontokorrent-konto 273, 278, 280, 299, 305Gebühren 282Individualkondition 280Kondition 280Konditionsgruppe 281Konditionskreis 281Limit 280, 284Limittyp 285Produkt 278, 279Produktkonfigurator 278Standardkondition 281Wertstellung 283Zins 281

SAP In-House Cash, Tagesendverarbei-tung 293, 308Bilanzvorbereitung 308, 311Buchungsschnitt 308Cash Concentration 309Hauptbuchübergabe 308, 312Kontenhierarchie 310Kontoabschluss 311Zinsabgrenzung 311Zinskompensation 311

SAP In-House Cash, Währungstausch 307Kontowährung 307Transaktionswährung 307


457

Index

SAP Integration Package for SWIFT 24, 314, 321, 325, 351, 355, 367, 373, 387, 388

SAP List Viewer � ALVSAP NetWeaver Application Server

385SAP NetWeaver PI 373, 376, 378,

380, 382, 383, 384, 426SAP NetWeaver PI-Content 389SAP Security Library 341SAP Service Marketplace 399SAP Solution Composer 399SAP Solution Manager 399SAP Treasury and Risk Management

393SAP-Geschäftspartner 173SAP-Hinweis

1019633 2631064419 3881090321 1691090664 1691091178 2491115137 2351144603 3741153053 3741251446 2611251447 2611360908 2341403282 2631413147 2021540040 2221591536 1901665873 2341686264 2511709875 1671710815 1671712322 1671712562 167503396 254634191 254969416 235

SAP-J2EE-Engine 385SAP-Projekt 397

Accelerated SAP (ASAP) 397ASAP-Methodik 397ASAP-Projektphasen 398ASAP-Werkzeuge 399

SAP-Währungstabelle 307Schema 82Scheme 57, 68

Schweiz 50Schweiz, SEPA-Umstellung 151Schweizer ISO-20022-Zahlungsstan-

dard 152Schweizer Kreditorenidentifikations-

nummer 153SCORE 371SCT-Schema 82

Prinzipien für AOS 85Vorteile 83

Secure Hash Algorithm 374Secure Store and Forward (SSF) 426Secure Store and Forward (SSF),

Schnittstelle 340Selektionsvariante 212Senderadapter 386Sendervereinbarung 382, 387SEPA 17

Bestandteile 32bisherige Erfahrung 70Fahrplan 67Geltungsbereich 48jüngste Entwicklungen 17Teilnehmer 50verbindliches Enddatum 35Vision 31

SEPA B2B Direct Debit � SEPA-B2B-Lastschrift

SEPA Cards Framework 149SEPA Core Direct Debit � SEPA-Basis-

lastschriftSEPA Credit Transfer � SEPA-Über-

weisungSEPA Routing Directory 86SEPA, Auswirkung

Bank und Clearing-Haus 161Endverbraucher 155große und mittelständische Unterneh-

men 157SEPA-B2B-Lastschrift 93, 116SEPA-Basislastschrift 93, 95

Datensätze 105wiederkehrende 98

SEPA-Begleitgesetz 29, 38SEPA-Dialogtransaktion 189SEPA-Format, FI-CA 243SEPA-Karten 149

EMV-Chip 151PIN-Verfahren 151Systemoption 149


458

Index

SEPA-Lastschrift 58, 93, 207, 211, 235, 426Attribute in Datensätzen 110Beteiligte 95DMEE-Formatbaum 211, 235, 236DMEE-Hierarchieebene 235Firmenkunden 116Fristen 98Granularität 236Privatkunden 93Rückgabegrund nach Settlement 100Rückgabegrund vor Settlement 99Sortier- und Schlüsselfeld 235Variante 93Zahlweg konfigurieren 236Zahlweg pflegen 237

SEPA-Lastschriften, Unterschiede 117SEPA-Mandat 96, 419, 425

analysieren und ändern 193ändern 189Änderungszeitpunk 194Anforderung 114anlegen in FI-CA 190anzeigen in FI-AR 188Attribute 107Aufbewahrung 97auslaufendes 199äußere Form 105Dialogtransaktion 187Doppelfunktion 96FI-AR-Protokoll 198Formular 204Gültigkeit 97Massenaktivität 196Massenänderung in FI-AR 194massenhaftes Erzeugen in FI-AR 198Prozess 95prüfen 237speichern 205Status 185Systemzustand 194Validierung 115Version 177Zusätze 100

SEPA-Mandatsanzeige 184Empfänger 186Grunddaten 184Sender 185Version 186Verwendung 186

Zahlungsbeleg 201SEPA-Mandatsattribut konfigurieren

178SEPA-Mandatsverwaltung 171, 188,

189Archivierung 203Auswertung 191Berechtigungsobjekt 205Datenmodell 179Formular 203Grundlagen 171Integrati

SEPA-Umstellung mit SAP · 2012. 10. 2. · Bonn Boston Jürgen Weiss SEPA-Umstellung mit SAP ®...

Documents

Transcript of SEPA-Umstellung mit SAP · 2012. 10. 2. · Bonn Boston Jürgen Weiss SEPA-Umstellung mit SAP ®...