Aufbau einer Payment Factory Ansätze zur Zentralisierung des Zahlungsverkehrs 02. Oktober 2014 28. Alpbacher Finanzsymposium
Aufbau einer Payment FactoryAnsätze zur Zentralisierung des Zahlungsverkehrs
02. Oktober 2014
28. Alpbacher Finanzsymposium
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 2
Dezentrale Abwicklung des Zahlungsverkehrs Tochtergesellschaften (TG) führen Inlands- und Auslandszahlungsverkehr über eigene
Bankkonten aus. TG halten eigene Bankkonten für die wichtigsten Fremdwährungen. Cash wird auf zentralen Konten über Cash-Pooling-Strukturen konzentriert.
Schwächen Hohe Spesen für AZV-Transaktionen und hohe Margen bei FX-Konvertierungen Zahlreiche dezentrale Konten bei diversen Banken Komplexe Cash-Pooling-Strukturen Organisatorische Schwierigkeiten (ZB-Verwaltung) und potenzielle Sicherheitsrisiken
Die Ausgangssituation: Dezentrale Strukturen, hohe Gebühren und Ineffizienzen
TochtergesellschaftenERP-
System 1
ERP-System 2
ERP-System 3
EDIFACT
XML
DTAUS/DTAZVEB-System 1
EB-System 2
EB-System 3
MT101
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 3
Stichwort „Payment Factory“ – Was ist das eigentlich?
Die Payment Factory (PF) steht für eine Zentralisierung des Zahlungsverkehrs in einer zentralen Einheit, die Zahlungsdateien von den angebundenen Tochtergesellschaften erhält und diese nach spezifischen Regeln über Banken abwickelt
Neben Kostenreduktion durch automatisierte Prozesse ermöglicht die PF maximale Transparenz und Kontrolle über Zahlungen.
Durch die Implementierung einer PF werden verschiedene, nicht-standardisierte Electronic-Banking-Systeme durch einen einheitlichen Kommunikationsweg zu den Banken ersetzt.
Rechnungswesen ̶ intern
Information für die Konto-Disposition
Cash-Pooling
Bankgebührenstruktur
Intercompany-Funding/ Liquiditätsstatus der TG
Intraday-Auszüge
Salden operativer ZV-Konten
TR-Konten / Kontoinformation und Abstimmung
Externe Bank(en) Externe Kontrahenten
Operative ZV-Konten
Treasury-Konten
Accounts payable
Bankkonten (automatische Buchung im ERP) / IC-Konten
Payment Factory
TRH
R Zahlungsaufträge (vertraulich)
Zahlungsaufträgeman. Zahlungen
ReW
e
Massenzahlungen aus ERP
Bankkonnektivität
Workflow
Prozess
Auswirkung
Zahlungsdatei erstellen
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 4
Und was bringt‘s? Argumente für die Einführung einer Payment Factory.
Die Einführung einer PF löst aktuelle Herausforderungen und kann durch die Optimierung des Zahlungsverkehrs sowohl einen qualitativen als auch einen quantitativen Mehrwert schaffen.
Liquiditäts-ManagementLiquiditäts-Management
Zentrale Verwaltung und Transparenz über die externen Cashflows im Konzern Zentrale Sicht auf die Liquiditätssituation der angeschlossenen Gesellschaften Möglichkeit der Steuerung des Liquiditätsabflusses Verbessertes Working-Capital-Management durch Vermeidung von Frühzahlungen
ComplianceCompliance
Transparenz und zentrale Kontrolle im Zahlungsverkehr: Nachvollziehbarkeit der Zahlungenim Konzern
Standardisierung der Prüfungs- und Freigabeverfahren Vermeidung „dubioser“ Zahlungen und Transparenz über die Zahlungsempfänger Zentrale Kontrolle über die Bankverbindungen und damit das Banken-Exposure Funktionalität von Limiten zur Kontrolle ungewöhnlicher Zahlungsabflüsse aus TG
Kosten-effizienzKosten-effizienz
Einsparung von IT-Kosten durch Reduzierung der Zahlungsverkehrssysteme Zinseinsparungen durch Zahlwegsteuerung und Optimierung von Zahlungsterminen Optimierung der Fremdwährungspositionen und Reduzierung des FX-Risikos Skaleneffekte durch Bündelung von Zahlungen, Verringerung Transaktionsanzahl und -kosten Reduzierung der Transaktionskosten bei Auslands- und Fremdwährungszahlungen Automatisierung der Workflows im Zahlungsverkehr, Reduzierung von manuellen
Erfassungsvorgängen
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 5
Konzept Zahlungsverkehr: Wo und über wie viele Konten wird ZV durchgeführt?
Welche Verantwortungen, welche Banken, welche Systeme, welche Formate?
1ZV durch die Gesellschaft
und Meldung des Bedarfes für zentrale
Pool-Disposition
2Steuerung und Freigabe der Zahlungen über eine
zentrale Stelle
3Payment-Factory führt
Zahlungen für TG „on behalf of“ aus
Einheitlicher, zentralisierter Prozess und zentrale
Kontrolle und Steuerung
Wenige Zahlungsformate und eine zentrale Verteilerstelle (SWIFT, Banken-Provider)
Einbindung von „lokalen Banken“ in Pool meist nur mit
Valutaverlust möglich
Beibehaltung Status-quo- Mehrere EB-Systeme
bleiben bestehen (Wartung, Kosten, etc.)
- Avisierungsprozess muss gelebt werden
Zentrale Zahlungsfreigabe- Systemanpassung erford.
(Bankenkommunikation)+ Formatvereinheitlichung+ Sicherheit durch zentrale
Prozessvorgabe + Keine lokalen EB-Systeme
Payment-Factory- Substanzielle organi-
satorische Umstellungen- Payment-Factory System-
unterstützung erforderlich- Zeithorizont und Zeitbedarf
für Umsetzung
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 6
Zentrale Fragestellungen auf dem Weg zur Payment-Factory
Generelle Anforderungen Verrechnungskonten müssen für alle Konzerngesellschaften vorhanden sein Abwicklung aller internen Forderungen und Verbindlichkeiten über In-house-Bank
wünschenswert Zentraler Zugang für Kontoauszugsinformationen, Weitergabe der Informationen an die
Konzerngesellschaften Datentechnische Infrastruktur für das Verarbeiten und Konvertieren von
Zahlungsformaten
Welche Varianten kommen generell nach einem Kosten-/Nutzenvergleich in Frage?
Welche Länder?
Rechtliche Situation Steuerliche
Restriktionen Länderrisiken Geschäftsgewohnheiten Sprachliche Barrieren Zeitzonen (Cut-off)
Welche Bank(en)?
Länderabdeckung (im Verbund oder mit Partnerbanken)
Rahmenvertrag Landesspezifischer
Vertrag Anordnung der Konten
Welche Technik?
Formate und Konvertierung
Systeme (ERP-System, TMS, E-Banking)
Bankkommunikation (SWIFT, EBICS, H2H, etc.)
Compliance Screening
Welche Gesellschaften?
Ressourcen Knowhow Bereitschaft Operatives Geschäft Risiko
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 7
Herausforderungen bei der Implementierung einer Payment Factory
Nachverfolgung von Zahlungsvorgängen; Bearbeitung von Rückläufern
Aufsetzen von Verrechnungskonten und deren laufende Kontrolle (Vollständigkeit der Verarbeitung der Zahlungsvorgänge)
Generierung, Versand und Verarbeitung der internen Kontoauszüge
Definition und Umsetzung von Buchungsregeln (Verrechnungskonten, Währungsdifferenzen)
Einheitliche Stammdaten für Geschäftspartner
Vermeidung doppelter Datenhaltung im ERP-System und der Payment Factory
Verwaltung der Stammdaten der TGs (Aussteuern interner Zahlungen)
Umsetzung der zentralen Daten-anforderungen in den lokalen Systemen
Sicherheit und Vertraulichkeit der Zahlungsdaten
Kontroll- und Freigabeverfahren zwischen Konzerneinheiten, Payment Factory und externen Banken; Definition eines Limitsystems
Anbindung ausländischer TG hinsichtlich der Anlieferung spezifischer Zahlungs-formate
Anbindung ausländischer TG hinsichtlich rechtlicher, steuerlicher und regula-torischen Vorschriften (OFAC-Liste, Geldwäschebekämpfung etc.)
Anbindung von TG hinsichtlich heterogener ERP-Systeme und Release-Stände
Anbindung unterschiedlicher Banken in verschiedenen Ländern (Formate etc.)
Anbindungen und Integration Systeme und Prozesse Formate
Compliance und regulatorische Anforderungen Daten-Management Verbuchung und interne Verrechnung
Definition von Leistungsübergabepunktenund der dazugehörigen Verantwortung
Koordination der Zahlläufe, Integration von manuellen Zahlungen/Eilzahlungen
Kreditoren-Management bei Bündelung von Zahlungen mehrerer TG an einen Empfänger (Avise, Klärung von Rückfragen)
Implikation unterschiedlicher Zeitzonen bei mehreren In-house-Banken hinsichtlich der jeweiligen Linien
Auswahl der internen und externen Formate für Zahlungen (IDOC, CGI, SEPA XML, lokale Formate)
Auswahl der Formate für Kontoauszüge (MT940, CAMT, BAI2, etc.)
Prüfung und Konvertierung von Formaten
Effiziente Nutzung des Verwendungs-zweckfelds (Mitgabe einer Identifikations-nummer zur Kennzeichnung der Auftrag-geber-Legaleinheit bei „On-behalf"-Zahlungen)
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 8
Überblick der Payment-Factories: Komplexität steigt mit den Anforderungen
Auszahlg.ein Land
Auszahlg. mehrere Länder
Auszahlg. und Einzahlg. EU
Auszahlg. und Einzahlg. weltweit
Debitoren-/ Kreditoren-Management weltweit
Steigende Komplexität
Umfang der Payment-Factory
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 9
Variante 1: Abwicklung von IC-Zahlungen und „Transport-only“-Zahlungen
Beschränkt auf die Abwicklung von IC-Zahlungen und externe „Transport-only“-Zahlungen
TG, Zentrale und Treasury senden Zahlungsdateien zur PF.
Ziel ist, IC-Zahlungen zwischen TG so effizient und kostengünstig wie möglich zu verarbeiten.
„Transport-only“-Zahlungen sind Transaktionen, die von den TG initiiert und von der PF ohne Änderung der Routing-Regeln weitergeleitet werden.
Alle Zahlungsdateien können dabei entweder aus den jeweiligen ERP-Systemen oder manuell außerhalb des ERP (z. B. Excel) erzeugt werden.
Nutzung der Payment Factory sowohl für die Abwicklung und Steuerung konzerninterner Zahlungen als auch für externe „Transport-only“-Zahlungen
Zahlungsdateien
Buchhaltung
Zahlungsdateien
Intercompany-Auszug
Treasury-Management-
System
Trading-Plattform
In-House-Clearing-System
Begünstigte/r
„Transport-only“-Zahlungen
Tochtergesellschaften
Interne Zahlungen via Banktransfer (in Ausnahmen)
extern
Interne Zahlungen via Clearingkonten
TG 1(Inland)
TG 2(Ausland)
TG n(Inland oder Ausland)
Group Treasury
intern
PAYMENTFACTORY
- Filtern- Routing- Unterstützung im
Management vonIC-Klärungsfällen
Treasury-Management-
System
Trading-Plattform
In-house-Clearing-System
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 10
Variante 2a: Abwicklung von „On-behalf"-Zahlungen über Konten der PF
Nutzung günstigerer IZV-Gebühren für den AZV
Alle Zahlungen der Teilnehmer werden in der PF gesammelt und in das lokale Clearing des jeweiligen Landes überführt.
Die Zahlung einer Rechnung durch eine andere TG wird auch als „payment on behalf“ bezeichnet.
Resultat: Kosten für grenz-überschreitende Zahlungen werden auf das Niveau von lokalen Zahlungen gesenkt.
Bankkonten befinden sich im Eigentum der Payment Factory
Non-resident Accounts in den jeweiligen Ländern
Nutzung einer Payment Factory für die Umwandlung von Auslandszahlungen in Inlandszahlungen
TG 1 TG 2 TG n
Zahlungs-dateien
Zahlungsdatei
Tochtergesellschaften
IC-Auszug
InterneZahlungen
Begünstigte/r
Kontoauszüge
Begünstigte/r
Zentrales Treasury-
Konto(Ausland)
Zahlung
Treasury-Management-
System
Trading-Plattform
Zentrales Treasury-
Konto(Inland)
Zahlung
„On-behalf”-Zahlungen
Group Treasury
internextern
„On-behalf”-Zahlungen
PAYMENTFACTORY
- Filter (intern/extern)- Konsolidierung pro Land- Länderspez. Formate- Vermeidung länderüber-
greifender Transaktions-kosten
- Zahlungen so spät wie möglich
In-House-Clearing-System
Hauptbuch
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 11
Variante 2b: Lokalisierung von „On-behalf“-Zahlungen
Ebenfalls Nutzung günstigerer IZV-Gebühren für den AZV
Für die Zahlungen an Zahlungsempfänger in den verschiedenen Ländern werden lokale Bankkonten von Konzerngesellschaften in den jeweiligen Ländern genutzt.
„Payments on behalf“ mit mehrstufiger interner Verrechnung
Resultat: Kosten für grenz-überschreitende Zahlungen werden auf das Niveau von lokalen Zahlungen gesenkt.
Nutzung vorhandener lokaler Zahlungsformate und Bankverbindungen
Nutzung einer Payment Factory für die Umwandlung von Auslandszahlungen in Inlandszahlungen
TG 1 TG 2 TG n
Zahlungs-dateien
Zahlungsdatei
Tochtergesellschaften
IC-Auszug
InterneZahlungen
Begünstigte/r
Kontoauszüge
Begünstigte/r
Lokales KG Bankkonto
(Ausland)
Zahlung
Treasury-Management-
System
Trading-Plattform
Zentrales Treasury-
Konto(Inland)
Zahlung
„On-behalf”-Zahlungen
Group-Treasury
internextern
„On-behalf”-Zahlungen
PAYMENTFACTORY
- Filter (intern/extern)- Konsolidierung pro Land- Länderspez. Formate- Vermeidung länderüber-
greifender Transaktions-kosten
- Zahlungen so spät wie möglich
In-house-Clearing-System
Hauptbuch
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 12
Variante 3: Globale Plattform für den ZahlungsverkehrErweiterung der Payment Factory um die Funktionen einer In-house-Bank
Die Integration einer In-house-Bank (IHB) ermöglicht die zentrale Steuerung und Kontrolle aller finanzwirtschaftlichen Risiken eines Konzerns.
Das Treasury nimmt gegenüber den TG die Rolle einer Bank ein.
Die Kombination von IHB und PF ermöglicht vollständige Trans-parenz über alle internen und externen Zahlungsströme.
Aufgaben der IHB:̶ Verarbeitung von Zahlungen̶ Verwaltung interner Verrechn.-
Konten (IHB-Konten)̶ Lieferung von Kontoauszügen
Beim Aufbau von IHB und PF ist eine SWIFT-Anbindung denkbar.
Treasury-Management-
System
PAYMENT-FACTORY
Treasury-Zahlungen
OperativeZahlungenExterne
Zahlungen
Interne Zahlungen
IVK-Buchung
Operative Zahlungen
Konto-auszüge
GLOBAL TREASURY PLATFORM
BA
NK
EN
Trading-Plattform
Bestätigungen
Handel
TOCHTERGESELLSCHAFTEN
GLOBALE TREASURY-PLATTFORM
TG 1 TG 2 TG n
InterneVerrechnungs-
konten(IVK)
SWIFT
Konto-auszüge
Hauptbuch
Hauptbuch
ZENTRALE IN-HOUSE-BANK
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 13
Von Anforderungsanalyse, Business Case, Konzept und Systemauswahl...
Analyse der Anforderungen1
3
2
1
Eine detaillierte Konzeptphase (Scoping) dient dazu, auf Basisder Ist-Situation und den Anforderungen an die zukünftigenProzesse den gewünschten Projektumfang (einbezogene Länder, TG, Banken etc.) festzulegen.
Projektteam, Zeitrahmen, Ziele und Meilensteine sowie das „Wie” der Projektorganisation und -dokumentation werdenebenfalls in dieser Phase definiert.
Erhebung der Mengengerüste (Konditionen, Volumina, Stück-zahlen im Zahlungsverkehr) sowie Informationen zu Systemen,Formaten und Schnittstellen (u. a. Bankkonnektivität)
Erst auf dieser Basis sind seriöse Aussagen zu Kosten undNutzen des Projekts möglich.
In dieser Phase wird die zukünftige Systemlandschaft inkl. aller nötigen internen Schnittstellen sowie der externen Bank-anbindung (SWIFT?) und vor allem das System zur Abbildungder PF-Funktionen festgelegt.
Falls nötig, findet in dieser Phase auch erst die Auswahl eines„PF-tauglichen“ Systems statt bzw. werden im Falle einer SAP-Lösung allenfalls nötige weitere Module definiert und lizenziert.
Evaluierung der Systemplattformen3
Erstellung einesBusiness Case2
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 14
... über die Testphase zum Go-Live
Pilotierung(Land oder Region)5
Testing und Go-Live6
Rollout in weitereLänder und Regionen7
5
4
Prozesse und Funktionen rund um die neue Payment-Factory-Landschaft werden auf Detailebene festgelegt undzwischen Zentrale (PF) und TG auf Ebene des Treasury, des Rechnungswesens sowie der IT abgestimmt.
So sind u. a. Verantwortlichkeiten und Prozessschritte imKreditoren- und, falls relevant, im Debitoren-Management zuregeln, die Systematik der Verbuchung und internen Verrech-nung von „on-behalf“-Zahlungen ist festzulegen. Das Daten-Management (ext. und int. Stammdaten) ist zu vereinheitlichen,Kontroll- und Freigabeverfahren sind zu definieren etc.
Die festgelegten Prozesse und Funktionen werden anhandeines festgelegten Rollout-Plans zunächst mit ausgewähltenTG in einem bestimmten Land oder einer bestimmten Regionals „Pilot-User“ implementiert.
Der Rollout-Plan enthält die im Standardfall im Zuge der Imple-mentierung zu setzenden Maßnahmen und ist auf Einzelfall-basis an spezifische lokale Gegebenheiten (Steuer-, Devisen-beschränkungen, Zentralbankmeldewesen etc.) anzupassen.
Im Rahmen der Pilotierung gesammelte „Lessons learnt“können im Zuge des weiteren Rollouts berücksichtigt werden.
Entlang der im Rollout-Plan definierten Zeitschiene schritt-weiser Rollout der Lösung in weitere Länder/Regionen
Beispielhafte Abfolge:̶ 1. Interne Zahlungen und/oder Netting über IHB für alle Ges. ̶ 2. Externer ZV für Schweizer Gesellschaften (In- und Ausland)̶ 3. Externer ZV für Gesellschaften im SEPA-Raum ̶ 4. Externer ZV für alle anderen europäische Gesellschaften̶ 5. Internationaler ZV für Pilotgesellschaft(en) restliche Welt̶ 6. Internationaler ZV für alle verbleibenden Gesellschaften̶ 7. Inländischer ZV für alle verbleibenden Gesellschaften
Tests mit den an die Payment Factory angeschlossenen TG und Banken
Behebung von technischen Fehlern und Prozessschwächen,die im Laufe der Tests identifiziert wurden
Go-Live
6
Konzeption der Prozesse
und Funktionen4
7
© Schwabe, Ley & Greiner – www.slg.co.at 02. Oktober 2014..
AUFBAU EINER PAYMENT FACTORY 15
Haben Sie Interesse oder weitere Fragen? Ihre Ansprechpartner sind:
Schwabe, Ley & GreinerMargaretenstraße 70A-1050 WienTel.: +43-1-585 48 30Fax: +43-1-585 48 30-15
E-Mail: [email protected]: www.slg.co.at
Martin WinklerPartner und Geschäftsführer
Michael MichaelisPartner
Zentralisierung Zahlungsverkehr
ALBA Group
02.10.2014 / Sonja Brei / Leiterin Treasury
Inhaltsverzeichnis
1. Vorstellung ALBA Group2. Situation bis Ende 20103. Zentralisierung und Stand heute
Inhaltsverzeichnis
1. Vorstellung ALBA Group2. Situation bis Ende 20103. Zentralisierung und Stand heute
1. Vorstellung ALBA Group
über 180 Tochter- und Beteiligungsunternehmenüber 8.000 Mitarbeiter rund 2,6 Mrd. Umsatz
| 02.10. 2014 | ALBA Group | …Seite 4
Die Leistungsbereiche
Entsorgungsdienstleistungen im kommunalen und gewerblichen Bereich
Gewinnung und Vermarktung von Sekundärrohstoffen
Entwicklung und Betrieb von Recycling- und Produktionsanlagen
1. Vorstellung ALBA GroupALBA und INTERSEROHZwei starke Marken unter dem Dach der ALBA Group
ALBA – Wir nennen es Rohstoff INTERSEROH – Ihr starker Umweltdienstleister
Organisation Rücknahmesysteme für Verpackungen und Produkte
Entwicklung individueller Komplettlösungen und innovativer Kreislaufsysteme für Unternehmen
Consulting und Services unabhängig von Dienstleistern
| 02.10. 2014 | ALBA Group | …Seite 5
ALBA Group - Ein führender UmweltdienstleisterUnter den Top 10 weltweit
Die ALBA Group ist ein führendes, vertikal integriertes Umweltdienstleistungsunternehmen in Europa und deckt alle Stufen der Wertschöpfungskette ab.
Processing TradingCom-poundingRecyclingSortingLicensing End UserCollecting
| 02.10.2014 | ALBA Group | …Seite 6
1. Vorstellung ALBA Group
Umsatzaufteilung 2013 pro Land
Country/Region Sales 2013(Mio. EUR)
Share of Total Sales
Germany 1.705 66% China/Hongkong 303 12% Poland 140 5% RoE 328 13% RoW (incl. Turkey) 122 5% Total 2.599 100%
| 02.10.2014| ALBA Group | …Seite 7
1. Vorstellung ALBA Group
Juristische Einheiten der ALBA Group in D
| 02.10.2014 | ALBA Group | …Seite 8
1. Vorstellung ALBA Group
Inhaltsverzeichnis
1. Vorstellung ALBA Group2. Situation bis Ende 20103. Zentralisierung und Stand heute
| 02.10.2014 | ALBA Group | …Seite 10
2. Situation bis Ende 2010
Ca. 600 Konten im Unternehmen ALBA/Interseroh mit unterschiedlichsten „Zahlungsverkahrsbanken“
Kein zentrales Zahlungsverkehrssystem Bis Ende 2010 wurde im Treasury ALBA mit HVB TRXplus gearbeitet, auf IS Seite
mit weiteren Omikron-/Multicashprodukten, Cotel, DreCash…) Anbindung an Banken über veraltetes FTAM - Verfahren
3 Cash Manager im Unternehmen durch Splittung Interseroh / ALBA Interseroh: Bereiche SaM und Services mit differenzierter Disposition, Datenlieferung
von juristischen Einheiten an die Disponenten über Excel, mehrstufiges Verfahren ALBA: eigene Disposition via Excelsheets
Kick-Off zentrales Zahlungsverkehrssystem
| 02.10.2014 | ALBA Group | …Seite 11
2. Situation bis Ende 2010Kick-Off zentrales Zahlungsverkehrssystem
Verschiedenste Tools & dezentrale Unterschriftsberechtigte führten zu Falsch-Dispositionen (fehlende Anmeldung von Zahlungen bzw. Nichtausführung von angemeldeten Zahlungen)
Diverse Autorisierungstools im Einsatz bei Schlüsselpersonen (Passwörter, Disketten, USB-Sticks, Zufallsgeneratoren, „Rubbellose“…)
Zerklüftete Berechtigungsprofile im Bankprogramm (HVB TRXplus) Probleme bei plötzlichem Ausfall der MA Inkonsistente Struktur innerhalb der Berechtigungen Dezentrale Berechtigungen bei Tochtergesellschaften
Regelmäßige Performance-Probleme, wodurch die Disposition bereits um 12.00 Uhr startete
Inhaltsverzeichnis
1. Vorstellung ALBA Group2. Situation bis Ende 20103. Zentralisierung und Stand heute
Einführung eines zentralen Tools -ATAQ2Bank der Firma Technosis
| 02.10.2014 | ALBA GroupSeite 13
Umstellung auf den Übertragungsweg EBICS
Start der Zentralisierung des Zahlungsverkehrs & Zusammenführung der Kunden ID´sbei den Banken
Anpassung und Einführung einer einheitlichen Berechtigungsstruktur bei den Banken
Behebung der Performance-Probleme, sodass die Disposition auf 14.00 Uhr verlegt werden konnte
Vereinfachte Anmeldung und Verschlüsselung der Zahlungen innerhalb des Systems ohne Donkeys, Key-Cards, Sticks, usw.
3. Zentralisierung und Stand heute
Kontenlandschaft bei ALBA (incl. Kassen)Reduzierung der Konten auf Hauptbanken
| 02.10.2014 | ALBA GroupSeite 14
0
100
200
300
400
500
600
700
2009 2010 2011 2012 2013 2014
Anzahl Konten
3. Zentralisierung und Stand heute
ZV / Disposition / Unterschriften
Steuerung und Beobachtung der Konten und deren Limite + Inanspruchnahmen 148 Konten / 81 Gesellschaften (Volumens-/Umsatzanteil 91,6%) sind über 4
automatisierte Cashpools (Commerzbank, Deutsche Bank, SEB und Unicredit) zum Header ALBA Group plc & Co. KG (Dispositionskonten) gepoolt.
Zahlungsverkehr wird zentral durch Treasury für diese Gesellschaften freigegeben und automatisch disponiert (zu Spitzenzahltagen werden rd. 500 Zahldateien durch Treasury versendet).
Lediglich zwei externe Unterschriften sind dafür bei den Banken hinterlegt, jegliche Freigabenregelung erfolgt im TMS (Umsetzung von Betragsbeschränkungen, Unterschriftskombinationen, Vertretungsregelungen, Rollenverteilungen)
ALBA GroupSeite 15 | 02.10..2014 |
3. Zentralisierung und Stand heute
Ausgangszahlungen können nur mit elektronischer Unterschrift ausgeführt werden
ALBA GroupSeite 16 | 02.10..2014 |
Zahlungen über TMS Zahlungen außerhalb TMS> 90 % der Ausgangszahlungen <10 %
Überweisungen und Lastschriften werden grundsätzlich automatisch (Schnittstelle SAP) erfasst.
Großteil über zentrale Zweitsysteme (z.B. db-direct, pekao biznes etc.)
Zweite Freigabe erfolgt durch Treasury Zum Teil Freigabe durch Treasury
Administration von elektronischen Bankunterschriften liegt im Treasury
Bankkonten werden in das TMS eingelesen, auch wenn die Zahlungsdateien außerhalb TMS ausgeführt werden.Steuerung durch Limitierung (Zahlung nur aus Guthaben) und TreasuryseitigeLiquiditätsversorgung (mittels Übertrag).
Umstellung auf TMS (ausgewählte Konten werden aktuell abgelöst), ständige Überprüfung
ZV / Disposition / Unterschriften3. Zentralisierung und Stand heute
| 14. Mai 2014 | ALBA Group | …Seite 17
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 1
EGGER PAYMENT FACTORYUmsetzung einer europäischen Payment FactoryLösung bei der EGGER Holzwerkstoffe Gruppe
Gerald Jobst, Leiter Gruppen-Treasury
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
Die EGGER Holzwerkstoffe Gruppe im Kurzüberblick Implementieren wir eine Payment Factory
Die Ausgangssituation, Definitionen Projektabgrenzung, das Konzept Die Umsetzung des Projekts: Projektphasen, Einblicke Optimierungschancen, Erfolgen Projektverlauf, Projektstatus Herausforderungen und Lessons Learned
AGENDA
2
KURZÜBERBLICK
Ein führender Holzwerkstoffhersteller in Europa
Stammsitz in St. Johann in Tirol, Österreich
17 Werke in 7 Länder
Über 7.200 Mitarbeiter
Umsatz 2013/14: EUR 2.219 Mio.
Kapitalmarktorientierung
Zentrales Gruppen-Treasury (aktuell 4 Mitarbeiter)
Ein Familienunternehmen besonderer Prägung
DIE EGGER GRUPPE
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 3
DIE EGGER GRUPPEGESCHÄFTSBEREICHE - FOKUS B2B BUSINESS
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 4
DIE EGGER GRUPPEVISION
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 5
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
EGGER PAYMENT FACTORY
6
CASH MANAGEMENT BEI EGGERSTATUS QUO SOMMER 2011 – SEPA DEADLINE „FIXIERT“
1 einheitliches SAP(selber Release-Stand:
SAP ECC 6.0 EHP 6)2 Instanzen: FI und HR
OpCo SAPElectronic Banking A
Electronic Banking B
Bank A
Bank B
(Cashpool)
OpCo SAPElectronic Banking B
Electronic Banking C Bank C
OpCo SAPElectronic Banking B
Electronic Banking D Bank D
ZV Formate AT
ZV Formate DE
ZV Formate DE
ZV Formate DE
ZV Formate UK
ZV Formate RO
Electronic Banking E
ZV Formate FRBank E
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 7
PAYMENT (UND COLLECTION) FACTORYDEFINITION UND VERSTÄNDNIS
Shared Service Center: Zentralisierung Headcounts- Zentrale Abwicklungseinheit- Beibehaltung lokaler Bankbeziehungen- Keine Änderung der Kommunikationskanäle oder Zahlungsformate
Zentralisierung über einheitliche IT-Lösung- Anbindung von Banken über ein einheitliches System (Bankenlösung?)- Gruppengesellschaften zahlen in eigenem Namen- Freigabe von Zahlungen: zentral oder dezentral
Payments on behalf- In-house Bank Konzept - Abwicklung von Zahlungen über zentrales Konto („Payments on behalf“)- Intercompany-Verrechnung zur Verbuchung von Eingängen/Ausgängen
Principal / Agent Modell- Zentrale Gruppengesellschaft fungiert als einziger externer Kontrahent (Principal)- Zahlungen und Inkasso nur noch zentral durch Principal („Ein-Konto-Modell“)- Gruppengesellschaften als Agents
Projektabgrenzung Fachliche/sachliche Rechnungs-/Zahlungs-Genehmigung weiterhin lokal Erstellung Datenträger für Zahlung weiterhin lokal
Grafik: frei nach UBS, Treasurer Summit Wolfsberg 2013
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 8
EBICS
EGGER PAYMENT FACTORYZIELSTRUKTUR
1 einheitliches SAP(selber Release-Stand:
SAP ECC 6.0 EHP 6)2 Instanzen: FI und HR
OpCo SAPElectronic Banking A
Electronic Banking B
Bank A
Bank B
(Cashpool)
OpCo SAPElectronic Banking B
Electronic Banking C Bank C
OpCo SAPElectronic Banking B
Electronic Banking D Bank D
ZV Formate AT
ZV Formate DE
ZV Formate DE
ZV Formate DE
ZV Formate UK
ZV Formate RO
Electronic Banking E
ZV Formate FRBank E
ISO20022 XML
ISO20022 XML
ISO20022 XML Electronic Banking
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014 9
PROJEKTPHASEN
1. Phase:Ausgehende EUR Zahlungsverkehr für AT, DE, FR, UK, RO (bzw. auch FX-Zahlungen)a) Massenzahlungsverkehr operativ (Lieferanten, Steuern)b) Mitarbeiterzahlungen und HR-verwandte Zahlungenc) Manuelle ZahlungenZahlungen Gruppen-Treasury (alle Währungen)
2. Phase:Inlandszahlungsverkehr in nationaler Währunga) UK (in GBP)b) RO (in RON)jeweils schrittweise Umstellung wie in Phase 1
3. Phase:Inlandszahlungsverkehr, Auslandszahlungsverkehr in RU und TR(soweit rechtlich und technisch umsetzbar)
EGGER PAYMENT FACTORY
10EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
EGGER PAYMENT FACTORYDAS PROJEKT IM ZEITVERLAUF
Sommer / Herbst 2011
Nov 11 –Jän 12
März /April 12
Juni 12 Juni 12 – März 13 März 13 ab April 2013
Pre-SoundingBilaterale GesprächeAusarbeitung RFP
Versand RFP an 7 BankenRückmeldung/Angebote BankenAuswertung/Short-List
Präsentation BankenEntscheidung EGGER
Gemeinsames Kick-off Meeting mit Vertretern aller beteiligten Banken
Kick-off Meeting mit Reval – Scoping Projektumfang
Vertragliches Setup / Abstimmung Dokumentation
Formatabstimmung mit allen beteiligten BankenEntscheidung für ISO20022 XML v3
Formatentwicklung Banken und EGGER (SAP, Reval)
Intensive Formattests
Go-Live ISO20022 XML v3
Weitere Ausrollung Format auf andere Ländern, alle Banken
Umstellung HR Zahlungsverkehr
Umstellung manueller Zahlungsverkehr
Start Projektphase II(RON, GBP)
11EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
UMSETZUNGSINGLE SOLUTION – TOTAL VISIBILITY (AND CONTROL)
Anforderungen von EGGER: Ablöse von verschiedensten Electronic Banking (Insel-)Lösungen Verarbeitung und Erzeugung von (abgestimmten) bankenspezifischen XML-Format:
für SEPA und NON-SEPA (pain.001.001.03) EGGER Autorisierungskonzept muss darstellbar sein Vertrauliche Verarbeitung von Mitarbeiterzahlungen muss gewährleistet sein
Umsetzung in Reval erfüllte alle Anforderungen und ermöglichte Erhöhung der Transparenz: alle ausgehenden Zahlungen über ein zentrales System Reval als Cashmanagement-Tool bereits im Einsatz – intensivierte Nutzung Prozessautomatisierungsgrad erhöht
automatische Dispo halbautomatische Verarbeitung von Zahlungen einheitliches Format, einheitliche Anbindung aller EGGER Kernbanken
Verschlüsselte Verarbeitung HR-Zahlungen Direkte Erzeugung von Zahlungen aus Treasury-Modulen
12EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
UMSETZUNGSKONZEPT FRÜHJAHR 2012 – LIVE SEIT HERBST 2013
Konverter EGGER KernbankDateikonvertierungfür lokales Clearing
(zB BACS, CHAPS, ROI, ROA)
„CGI“ XML ISO 20022
‐ Lieferanten‐zahlungen
‐ Gehalts‐ und Lohnzahlungen
‐ Mietzahlungen
‐ Steuern & Sozial‐versicherungen
‐ Treasury ‐zahlungen
pain.002
MT940 /MT942
EGGER Holding
CompaniesDE
Companies FR
Companies UK
Companies RO
Payment Factory
EUR:EBA,
TARGET2Clearing
Import der XML‐Datei 1. und 2. Unterschrift durch das Gruppen Treasury & ReWe AT
(Version 13.1)
SAP: Erstellung der CGI XML ISO20022 ‐Dateien auf Basis der Zahlungsvorschläge
Lokales Treasury & Massenzahlungsverkehr
Treasury- & Einzel-
zahlungen
GBP:BACS + CHAPS Clearing
„CGI“ XML ISO 20022
DIE EGGER PAYMENT FACTORY
EGGER Kernbanken
„CGI“ XML ISO 20022
RON:ROI/ROA
FX:zB DTAZV
EBICS
13EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
EGGER PAYMENT FACTORYUMSETZUNG MIT ISO20022 UND EBICS
ISO20022 / SEPA XML / CGI bringt (auch neue) Anforderungen mit sich Lokale, landesspezifische Dialekte bleiben teilweise erhalten Bankenspezifische Anforderungen müssen erfüllt werden Dateigröße von XML im Vergleich zu txt-Zahlungsdatei Umsetzung von NON-EUR und Eilzahlungen
EBICS ist in der EGGER-Bankenstruktur der optimale Kommunikationskanal Beste gemeinsame Nenner Hohe Verfügbarkeit Schnelle und unkomplizierte Anbindung in Europa Kostengünstig
14EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
UMSETZUNGBEISPIEL SAP ZAHLUNGEN (FI) DURCHSCHLEUSEN
SAP StandardZahllauf (F110)
Download SAP Zahlungsdatenträger XML pain.001.001.03
(pain.008.001.02)
Info an Gruppen Treasury, Versand
Zahlungsbegleitliste
Import von SAP Zahlungsdatenträger
durch Gruppen Treasury in Reval
Kontrolle der importierten Zahlungsdatei – kein
Ändern/Nachbearbeiten
Freigabe der Zahlung gemäß EGGER
Berechtigungskonzept
Automatische Disposition Zahlungen auf Konten im
Cashmanagement
Versand der Zahlungsdateien über
EBICS an Banken
Abruf von Protokollen, untertägigen Auszügen(PTK, pain.002, MT942)
15EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
Anfrage und Abschluss FX
Geschäft über 360T durch
EGGER Front Office
Import von360T Trade Ticket
in Reval
Kontrolle und Freigabe des 360T Trades
in Reval durchEGGER Middle Office
Erstellung , Versand von Misys Matching
Datei anMisys CMS Deal
Confirmation Plattform
Import von MisysMatching Datei in
Revalnach erfolgreichem
Matching
Automatische Bestätigung und Disposition des Trades in Reval
Erstellung Zahlungautomatisch in Reval
direkt aus Trade(über
Standardzahlwege)
Kontrolle der erstellten Zahlung
(kein Ändern möglich) EGGER Back Office
Freigabe der Zahlung gemäß EGGER
Berechtigungskonzept
Versand der Zahlungsdateien über
EBICS an Banken
Abruf von Protokollen, untertägigen Auszügen
(PTK, pain.002, MT942)
UMSETZUNGBEISPIEL ZAHLUNGEN AUS DEVISENHANDEL
16EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
IMPLEMENTIERUNG EINER PAYMENT FACTORYOPTIMIERUNGSCHANCEN UND -ERFOLGE
Reduktion von Schwachstellen in der Zahlungsverkehrsabwicklung: korrekte und zeitgerechte Freigabe, Betrugsprävention, Erfüllung regulatorischer Anforderungen, Fremdwährungsmanagement, Datengenauigkeit, Formatierung, Abgleich Zahlungen
Prozessstandardisierung (auch der Annex-Prozesse) Erhöhung des Straight-Through-Processing Grades Liquiditätsmanagement: Erhöhung Transparenz, Planbarkeit und Kontrollmöglichkeit Unterstützung von Wachstumszielen: schnellere Integration von Akquisitionen,
rasche Anpassung an neue Märkte (Kanäle, Formate, etc.) Kontrahentenrisikomanagement: Verkürzung der Reaktionszeit
Und natürlich...Kosteneinsparungen durch Reduktion von Ineffizienzen (optimale Wahl Zahlweg, Instrumente), Beseitigung von Redundanzen (Bankkonten, IT-Landschaft) und Erreichen von Skaleneffekten (personelle Ressourcen, Volumen)
17EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
IMPLEMENTIERUNG EINER PAYMENT FACTORYKRITISCHE BETRACHTUNG
Die (Ziel-)Struktur determiniert die Wahl des Payment Factory Modells Gesellschaftsstruktur: bestimmend oder bestimmbar? Berücksichtigung rechtlicher/steuerlicher Rahmenbedingungen (zB „Payment on
behalf“ rechtlich möglich? In-House Bank: Bankkonto notwendig?) Einfluss der betroffenen Stakeholder (lokale Geschäftsführung, Regulatoren,...) Commitment der Geschäftsführung unerlässlich Zentralisierung bedingt Verantwortungsübernahme Zahlungsverkehrsprojekte sind (auch) IT-Projekte – Ressourcen? Eingesetzte Instrumente: Berücksichtigung lokaler Gewohnheiten und „Bedürfnisse“ Format: all-in-one Format (zB CGI ISO20022 XML) oder lokale Formate IT-Landschaft: multiple ERP-Systeme (oder Releasestände), ZV-System(e) Konnektivität: lokale Standards (zB EBICS), proprietär (H2H), global (SWIFT)? Banken: lokale Banken vs. globale Banken – Erreichbarkeit vs. Individualität
18EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
LEASONS LEARNED
Softwareanbieter, Banken Gemeinsame Kick-off Meetings mit allen Beteiligten (IT, Banken, Reval etc.) Verschiedene XML-Dialekte / Versionen auf einen Nenner bringen – Unterschiede zeitgerecht
erkennen / kommunizieren Klaren Zeitplan einfordern und Test-Schritte genau definieren Berücksichtigung unterschiedliche Technik-Stände (kleine) Abweichungen zwischen
Banken bzw. bei Softwareanbietern führen zu großen Auswirkungen in Projekt Technische Möglichkeiten bzgl. aktuellem Release-Stand abklären (Updates notwendig?) Pflichtenheft (inkl. Projektmanagement) für gemeinsames Verständnis Konsequenzen bei Abweichungen/Projektverzug
Intern Klares Projektmanagement; Detailplanung jedoch schwierig Parallelbetrieb in Übergangsphase / Contingency Lösungen Genügend Zeit für Tests einplanen (Ressourcen Banken, Softwareanbieter begrenzt!) Committent der Geschäftsleitung/Vorstand - Frühzeitige Informationspolitik an alle Stakeholder Optimierung vor- und nachgelagerte Prozesse (Kontoauszüge, AWV-Meldungen,
Freigabeprozess manuelle Zahlungen, Nutzung TMS / ERP) in Projekt aufnehmen
EGGER PAYMENT FACTORY
19EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
EGGER PAYMENT FACTORYRESÜMEE
Lange Projektdauer Aufbau Know-how ISO20022 XML und SEPA notwendig Komplexer Prozess, verschiedenste Stakeholder
Entwicklungen während Projektverlauf Extern: Entwicklungen Systemlandschaft Banken Intern: Entwicklungen SAP, TMS (Reval)
Umsetzungsform angepasst an EGGER Strukturen
Das ideale Nachfolgeprojekt zu SEPA Nutzen des internen und externen Know-hows Prozess- und Systemstandardisierung Transparenz
Wie alles begann…
http://www.iso20022.org/
20EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
EGGER PAYMENT FACTORY - 28. ALPBACHER FINANZSYMPOSIUM, 02.10.2014
Vielen Dank für Ihre Aufmerksamkeit
Gerald JobstLeiter Treasury Gruppe
Fritz Egger GmbH & Co. OG
Telefon: + 43 50 600 10229E-mail: [email protected]
21