Aufbau einer Payment Factory - Finance Trainer · Aufbau einer Payment Factory Ansätze zur...

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



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



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



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



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



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)



Ü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



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


System

Trading-Plattform

In-house-Clearing-System



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


IC-Auszug

InterneZahlungen

Begünstigte/r

Kontoauszüge

Begünstigte/r

Zentrales Treasury-

Konto(Ausland)

Zahlung


System

Trading-Plattform

Zentrales Treasury-

Konto(Inland)

Zahlung

„On-behalf”-Zahlungen

Group Treasury

internextern


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



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


IC-Auszug

InterneZahlungen

Begünstigte/r

Kontoauszüge

Begünstigte/r

Lokales KG Bankkonto

(Ausland)

Zahlung


System

Trading-Plattform

Zentrales Treasury-

Konto(Inland)

Zahlung


Group-Treasury

internextern


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



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.


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



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



... ü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



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

[email protected]

Michael MichaelisPartner

[email protected]

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 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


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


Juristische Einheiten der ALBA Group in D

| 02.10.2014 | ALBA Group | …Seite 8


Inhaltsverzeichnis


| 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


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


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 |


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


DIE EGGER GRUPPEGESCHÄFTSBEREICHE - FOKUS B2B BUSINESS


DIE EGGER GRUPPEVISION



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


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


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


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)


Electronic Banking C Bank C


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


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)


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)


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


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


DIE EGGER PAYMENT FACTORY

EGGER Kernbanken


RON:ROI/ROA

FX:zB DTAZV

EBICS


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


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)


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


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)


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


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 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/



Vielen Dank für Ihre Aufmerksamkeit

Gerald JobstLeiter Treasury Gruppe

Fritz Egger GmbH & Co. OG

Telefon: + 43 50 600 10229E-mail: [email protected]

21

Date post:	24-Aug-2018
Category:	Documents
Upload:	vunga
View:	235 times
Download:	1 times

Aufbau einer Payment Factory - Finance Trainer · Aufbau einer Payment Factory Ansätze zur...

Documents