Währungsumstellung in Kroatien auf Euro

Zum 1. Januar 2023 stellt Kroatien als 20. Land der Europäischen Gemeinschaft seine Landeswährung, die Kuna (internationale Währungscode HRK, gebräuchliche Abkürzung KN), auf den Euro um. Erstmals eingeführt wurde die Kuna am 30. Mai 1994. Im vorherigen Blogbeitrag haben wir uns bereits mit den Herausforderungen dieser Währungsumstellung im Tool CCH Tagetik auf interne Finanzprozesse auseinander gesetzt. In diesem Beitrag erfahren Sie, wie sich die Währungsumstellung auf Ihren Konzernabschluss auswirkt und worauf Sie bei Ihrem verwendeten Konsolidierungsprodukt achten sollten.

Historischer Hintergrund

Mit dem 1. Januar 1999 startete das Gemeinschaftsprojekt Euro als Buchgeld und ab dem 1. Januar 2002 auch als Bargeld. Zu diesem Zeitpunkt waren 12 Staaten beteiligt. Ab 2007 bis 2015 treten 7 weitere Staaten bei – zuletzt Litauen. In dem Vertrag von Maastrich (1992) kamen die Staaten überein, dass alle Staaten der EU (Ausnahme Dänemark, Großbritannien) die Gemeinschaftswährung Euro einführen, sobald die Stabilitätskriterien nach dem Stabilitäts- und Wachstumspakt (1997) erfüllt sind.  Am 12. Juli 2022 hat der Rat der Europäischen Union den Umrechnungskurs für Kroatien 1 EUR = 7,53450 HRK festgelegt (Kroatien tritt Euroraum am 1. Januar 2023 bei. Europäische Zentralbank, Pressemitteilung, 12. Juli 2022).

Wie wirkt sich diese Währungsumstellung auf einen Konzernabschluss in Euro aus?

Ein Konzernabschluss wird unter der Fiktion eines einheitlichen Unternehmens erstellt. Die einbezogenen Konzernunternehmen werden dabei wie Betriebsabteilungen behandelt. Geht man von dieser Fiktion aus, dann darf sich kein Einfluss auf die Konzernbilanz ergeben.  

Vor Umstellung auf Euro – hier 2022 – sind die Finanzdaten für Kroatien sowohl in Landeswährung als auch in Konzernwährung vorhanden. Danach sind Landeswährung und Konzernwährung gleich.

Aus Konzernwährungssicht darf es somit keine Abweichungen zwischen den Endbeständen im Jahr 2022 und den Anfangsbeständen 2023 geben.

Wie sage ich es meinem Konsolidierungsprodukt?

Der Vorteil einer Währungsumstellung eines Landes ist, dass alle Konzerngesellschaften dieses Landes umgestellt werden. Bei den meisten Konsolidierungsprodukten sind sowohl die Währung der Gesellschaft als auch dessen Code im System fixiert. Nachträgliche Änderungen erlauben die Systeme aus Gründen der Datenintegrität selten.
Nachfolgende Überlegungen gehen von der sehr häufig gewählten Konstruktion aus: 

• Die Bilanz ist voll verspiegelt, m.a.W. jedes Konto hat einen Anfangs- und Endbestand. Für die Veränderungen im laufenden Jahr ist mindestens eine Bewegungsart vorhanden. 
• Beteiligungs- und Kapitalkonten sind historisch umgerechnet. Der Anfangsbestand wird in Konzernwährung vorgetragen und wird nicht aus dem laufenden Jahr z.B. durch historische Kurse berechnet.  
• Der Anfangsbestand in Landeswährung wird durch das System vorgetragen und ist nicht beschreibbar und damit gesperrt. 

Dadurch ergeben sich zwei denkbare Optionen. Die Gesellschaft bleibt mit dem vorhandenen Code erhalten oder es wird eine neue Gesellschaft mit einem neuen Code im Konsolidierungssystem angelegt.

Variante A: Die Gesellschaft wird mit dem alten Code weitergeführt.

Aus Sicht eines Konsolidierungsprodukts bleibt es bei einer Fremdwährungsgesellschaft. Ab dem Jahr 2023 werden die Kurse für den Durchschnittskurs (GUV-Daten und ein Teil der Bewegungen der Bilanz) und den Stichtagskurs (u.a. Endbeständen der Bilanz) mit dem Kurs von „1“ geführt.  
 
a) Vorteil dieser Variante ist, dass insbesondere der Intercompany-Code für alle anderen Konzerngesellschaften gleichbleibt. Gerade bei automatischem Upload aus Vorsystem ist keine Anpassung deren Schnittstellen nötig. Diese Anpassungen können sehr aufwändig sein.  
Die hinterlegte Kapitalkonsolidierung wird in Konzernwährung nicht berührt und weitergeführt. Manuelle Konzernbuchungen können weiterlaufen. 
b) Nachteil ist, dass der Übertrag der Bilanz auf Landeswährungsebene in Kuna erfolgt.  
 
Das sollen folgende Zahlenbeispiele veranschaulichen: 1506,90 Kuna entsprechen 200 EUR. Der Kurs für den Kuna wurde bereits 2022 fixiert.

Das gezeigte Zahlenbeispiel in der Tabelle 1 funktioniert zeigt die Schwierigkeiten auf:  

• In Landeswährung gibt es eine Inkonsistenz. Der Endbestand und die Summe der Bewegungsarten passen nicht zusammen. Damit es überhaupt funktioniert würde, müssten sowohl die Veränderung des Jahres als auch der Endbestand eingegeben bzw. aus dem Vorsystem geladen werden. Wird der Endbestand bzw. die Veränderung aber berechnet, kommt es schon zu unerwünschten Ergebnissen. 
• Bei der Währungsumrechnung kommt es dann aber zu unerwünschten Effekten, da für den Anfangsbestand (Anfangsbestand/ Stichtagskurs (1) – Anfangsbestand/ Vorjahresstichtagskurs (7,53450)) eine Währungsdifferenz berechnet werden wird, die das Ergebnis stark verfälscht.  
• Ist in dem System ein Check etabliert, der den Endbestand mit der Summe der Bewegungen abgleicht, würde dieser anspringen. Das passiert sowohl auf Landeswährung als auch auf Konzernwährungsebene und zum Fehler führen. 

Will man diesen Problemen begegnen, dann wäre eine Eingabe eines Differenzbetrags in Kuna denkbar, um den richtigen Betrag zu erhalten. Möglicher Kandidat wäre die Bewegungsart Währungsdifferenz. Das setzt aber voraus, dass die Bewegungsart in Landeswährung eingebbar ist.  

• Die Landeswährungsebene wäre damit glattgestellt. Allerdings muss diese Eingabe für jedes Konto erfolgen. 
• Es wird unterstellt, dass die Währungsdifferenz mit dem Stichtagskurs umgerechnet wird. Wie man aus dem Zahlenbespiel in Tabelle 2 sieht, geht es in Konzernwährung auf.

Eine andere Möglichkeit wäre – sofern vorhanden – die Bewegungsart Adjustment Anfangsbestand zu benutzen.  

• Die Landeswährungsebene wäre damit glattgestellt. Allerdings muss diese Eingabe für jedes Konto erfolgen. 
• Es wird unterstellt, dass die der Adjustment Anfangsbestand mit dem Vorjahresstichtagskurs umgerechnet wird und eine Währungsdifferenz berechnet, analog zum Anfangsbestand.
  Wie man aus dem Zahlenbespiel in Tabelle 3 sieht, laufen der Adjustment Anfangsbestand und die Währungsdifferenz in Konzernwährung heben sich auf, damit die Ebene geht auf. 

Abgesehen von dem Zahlenbeispiele in Tabelle 1, gibt es in der Tabelle 2 (Währungsdifferenz) und 3 (Adjustment Anfangsbestand) die Möglichkeit durch Eingriffe bzw. Ergänzungen im Jahr 2023 zum richtigen Ergebnis in Landes- und/oder Konzernwährung zu gelangen.
Die Methode in Tabelle 2 ist da eindeutig der Königsweg, da die Währungsdifferenz verschwindet und keine weiteren Werte auf anderen Bewegungsarten stehen bleiben. 

Beschriebenes Vorgehen hat den Nachteil, dass für jedes Konto mit einem Anfangsbestand der Korrekturbetrag ermittelt und eingegeben werden muss. Gäbe es andere Optionen? Denkbare Eingriffe wären: 

1. Arbeiten mit einem Transaktionskurs, der es erlaubt die Währungsumrechnung zu korrigieren. Bei CCH Tagetik ist dieser Eingriff möglich. Bei S4 Hana Group Reporting ist es nur möglich, wenn für die Bewegungsart ein Transaktionskurs erlaubt ist. Diese Option hilft aber nicht wirklich weiter, da das Beispiel in Tabelle 1 zeigt, dass es schon in Landeswährung inkonsistent ist.
2. Eine Reihe von Konsolidierungsprodukten bieten die Möglichkeit gezielt für eine Gesellschaft und einen Zeitraum abweichende Regeln zu definieren. Hier wäre z.B. Oracle|Hyperion Financial Management und SAP BPC zu nennen. Der Vortrag in Landeswährung wird so abgeändert, dass schon auf Ebene der Landeswährung der richtige Wert in Euro ankommt. Zusätzlich ist ein Eingriff in die Berechnung der Umrechnung – Vorjahresstichtagskurs mit 1 – erforderlich. 
3. CCH Tagetik bietet zusätzlich die Option, die hinterlegte Währung einer Gesellschaft ab einem bestimmten Zeitpunkt zu überschreiben. Dazu muss ein neuer Prozess definiert werden. Häufig findet man in der Praxis mehrere Prozesse in einem Geschäftsjahr. Sie sind untergliedert in Monats-, Quartal- und Jahresendprozess. Entsprechend braucht man dann für jeden Fall einen neuen Prozess. Analog wäre es bei Budget und Forecast zu sehen.
4. In Produkten wie SAP SEM-BCS gibt es sogar eine automatische Funktionalität um zum Jahresende eine Umstellung der Hauswährung vorzunehmen. Dabei wird zum Zeitpunkt des Saldovortrags eine neue Hauswährung definiert. Die Währungsumrechnung erstellt dabei einen abweichenden Saldovortrag in der entsprechenden Hauswährung.

Variante B: Für die Gesellschaft wird ein neuer Code etabliert.

Wird die kroatische Gesellschaft im System mit einem neuen Code etabliert, führt das zu umfangreichen Anpassungsmaßnahmen: 

1. Die alte Kuna-Gesellschaft muss am Anfang des Jahres endkonsolidiert werden. Damit sind alle vorgetragenen automatischen und manuellen Konzernbuchungen „verloren“ und müssen neu initialisiert werden. Ebenso ist die historische Währungsumrechnung nicht mehr verfügbar.
2. Bei der neuen kroatischen Gesellschaft in Euro müssen die Anfangsbestände in Euro eingetragen werden. Idealerweise auf der Bewegungsart, die das System für die Endkonsolidierung benutzt. Da es sich um keine echte, sondern „nur“ um eine technisch bedingte Endkonsolidierung handelt, darf am Schluss im Konzern auf dieser Bewegungsart Endkonsolidierung nichts mehr übrigbleiben.
3. Die Kapitalkonsolidierung muss neu initialisiert werden. Besondere Augenmerk ist auf die aufgelaufene historische Währungsumrechnung zu legen. Da es sich nun um eine neue Gesellschaft in Euro handelt, steht der Mechanismus der Währungsumrechnung nicht mehr zur Verfügung. Die Landeswährung entspricht der Konzernwährung und die Differenz ist nicht mehr so leicht zu erzeugen, weil der Mechanismus der Währungsumrechnung wegfällt. Hier kann man sich nur mit manuellen Buchungen behelfen, um das alte Bild zu erzeugen. Aus Konzernsicht ist nichts passiert!
4. Alle manuellen Konzernbuchungen sind neu zu hinterlegen. Wie bereits unter Punkt 2 beschrieben idealerweise auf der gleichen Bewegungsart, auf der die Endkonsolidierung erfolgt. 
5. In der Schnittstelle zum Vorsystem für die kroatische Gesellschaft muss der Datenfluss auf die neue Gesellschaft angepasst werden.
6. Durch den neuen Code ändert sich auch die Intercompany-Beziehung aller anderen Konzerngesellschaften. Die vorhandenen Daten, die über den Vortrag kommen, müssen entsprechend umgebucht werden. Die Schnittstellen dieser Gesellschaften müssen entsprechend angepasst werden, damit der neue Intercompany-Code richtig befüllt wird.
7. Eventuell sind Anpassungen an Reports erforderlich, falls diese nicht dynamisch im System hinterlegt sind. 

Bei einigen Systemen am Markt gibt es die Möglichkeit per Rule die Vorträge von einer Gesellschaft auf eine andere Gesellschaft für einen gewissen Zeitraum umzulenken. Damit erspart sich zumindest die Punkte 1-4.

Insbesondere die Vorjahreswerte aus der historischen Währungsumrechnung, die Kapitalkonsolidierung und die manuellen Konzernbuchungen bleiben in Konzernwährung erhalten.

Die Möglichkeit bietet z.B. Oracle|Hyperion Financial Management, wohl auch SAP BPC. Prevero als auch Frango und Cognos Controller präferieren hier die zweite Variante, wobei dann eine technisch neue Gesellschaft für die tatsächlich schon vorhandene Gesellschaft einzupflegen ist. Alle historischen Buchungen sind dann vor allem im Bereich der Kapitalkonsolidierung neu einzugeben. Ferner müssen dann auch aus den Vorsystemen bei allen IC-Beziehungen zu dieser Gesellschaft die IC-Codes für die Datenimporte geändert werden.

Resumee

Sofern die technische Möglichkeit besteht, ist die Variante A – Beibehaltung des bisherigen Codes der Gesellschaft – der Variante B – neue Gesellschaft – allemal den Vorrang zu geben. Der Anpassungsaufwand in dem Konsolidierungssystem ist auf alle Fälle geringer.

Es lohnt sich auf alle Fälle die technischen Optionen, die die verschiedenen Systeme bieten zu prüfen. Dadurch können sich erhebliche Arbeitserleichterungen ergeben.
Die schlechteste Variante ist das Anlegen einer neuen kroatischen Gesellschaft. Anpassung und Abstimmungsaufwand ist dort am höchsten.