Skip to main content
insightsoftware Documentation insightsoftware Documentation
{%article.title%}
Published:
Was this article helpful?
0 out of 0 found this helpful

Matrixkonsolidierung

Inhaltsverzeichnis

Einleitung / Begriffsklärung

Wenn von Harmonisierung des internen und externen Konzern-Rechnungswesens die Rede ist, fällt regelmäßig das Schlagwort Matrixkonsolidierung, weil man die legale Sichtweise auf der X-Achse, die interne Sichtweise auf der Y-Achse einer Matrix darstellen kann.

Abbildung 1: Beispiel einer Matrixkonsolidierung

Solange eine Gesellschaft eineindeutig einem Segment zugeordnet werden kann, ist die Umsetzung einer Matrixkonsolidierung nicht weiter anspruchsvoll, da die Segmente in IDL Konsis z. B. über reporttechnische Teilkonzerne abgebildet werden können.

Entscheidend beim Reporting konsolidierter Segmente ist immer die Frage: Wie ist jede einzelne Konsolidierungsbuchung einzuordnen: segment-intern oder segmentübergreifend. Bei der Abbildung über reporttechnische Teilkonzerne braucht sich der Anwender darüber keine Gedanken zu machen, das erledigt in IDL Konsis das Programm REPKTK.

Sobald sog. Zebra-Gesellschaften vorkommen (Gesellschaften, die nicht eineindeutig einem einzigen Segment zugerechnet werden können), müssen in IDL Konsis die Daten dieser Gesellschaft und aller übrigen Gesellschaften mit Geschäftsbereichen gemeldet werden.

Die Konsolidierung auf Ebene der Geschäftsbereiche ist in IDL Konsis bereits vollständig umgesetzt.

Zwar wurde vor Jahren eine Möglichkeit in IDL Konsis geschaffen, Geschäftsbereiche zu aggregieren. Jedoch machte sie bislang reporttechnisch u. U. Probleme, da das bisherige Merkmal an der Konsolidierungsbuchung, welches sie als segment-intern bzw. segmentübergreifend kennzeichnete, nicht mehr geeignet war, dies auch in einer aggregierten Struktur korrekt zu kennzeichnen.

Wir wollen dies mit dem folgenden Beispiel verdeutlichen:

Abbildung 2: Beispiel für IC-Beziehungen segment-intern und segmentübergreifend

Die erste Buchung mit Betrag 100 gilt als segment-intern, da sie Sachverhalte innerhalb des Segments Automotive bucht, die zweite Buchung mit Betrag 150 gilt als segmentübergreifend, da sie Sachverhalte in zwei unterschiedlichen Segmenten bucht.

Umsetzung in IDL Konsis

Es wurden vor der programmtechnischen Umsetzung unterschiedliche Lösungsansätze intensiv diskutiert. Schließlich wurde dann die folgende Lösung umgesetzt:

Konsolidierungsbuchungen

Das in der Konsolidierungsbuchung bereits seit Jahren vorhandene Kennzeichen segmentübergreifend ist nicht mehr ausreichend, sobald Geschäftsbereiche aggregiert werden. Da durch die Aggregation mehrerer Geschäftsbereiche auch als segmentübergreifend markierte Buchungen zu segment-internen Buchungen werden können.

Da wir davon ausgegangen sind, dass sich die Reportinganforderungen auch nach Durchführung der Konsolidierung ändern können, wollten wir eine in dieser Hinsicht möglichst flexible Lösung schaffen. Beispielsweise sollte der Anwendungsfall abgebildet werden können, dass im laufenden Jahr eine abweichende Aggregation der Segmente stattfindet wie im Vorjahr. Dennoch sollte das Vorjahr mit der aktuellen Segment-Struktur zu Vergleichszwecken berichtet werden können.

Daher hatten wir uns entschieden, zu den bereits an der Konsolidierungsbuchung vorhandenen Attributen Gesellschaft und Geschäftsbereich jeweils Gegen-Gesellschaft und Gegen-Geschäftsbereich als weitere Attribute hinzuzufügen. Damit nicht nur je Konsolidierungsbeleg, sondern je Konsolidierungsbuchung die betroffenen Partner eineindeutig sind.

Abbildung 3: Übersicht der Konsolidierungsbuchungen

Die neu geschaffenen Attribute Gegen-Gesellschaft/Gegen-Geschäftsbereich gehen nicht in die Prüfsummenberechnung mit ein.

Schulden- bzw. Aufwands- und Ertragskonsolidierung

Im Rahmen der Schulden- bzw. Aufwands- und Ertragskonsolidierung werden ggfs. innerhalb eines Konsolidierungsbelegs mehrere Buchungssatznummern verwendet, jeweils für jedes Pärchen bestehend aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich. Das bedeutet auch, dass wir nicht eine einzige Differenz je Gesellschaftspärchen auszubuchen haben, sondern es werden unter Umständen mehrere Differenzen je Kombination aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich ausgewiesen. Es ist zwingend erforderlich, dass die Konsolidierungsbuchungen je Buchungssatznummer, also je Pärchenkombination aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich aufgehen.

Dies ist auch einer der Hauptgründe, warum allein durch das Einspielen des Release 22.3 an dem bestehenden Datenbestand nichts verändert wird . Das Konvertierprogramm lässt die Konsolidierungsbuchungen unangetastet, da es die nötige Arbeit gar nicht leisten könnte.

Die Attribute Gegen-Gesellschaft/Gegen-Geschäftsbereich können nicht manuell ergänzt oder bearbeitet werden. Sie werden vom System befüllt, wenn eine Konsolidierungsverarbeitung gestartet wird.

Wenn der Kunde für eine bereits abgeschlossene Periode die neue Funktionalität ausprobieren möchte, oder eine bereits abgeschlossene Periode als Vergleichsperiode heranziehen möchte, müsste er sämtliche Konsolidierungsbuchungen überarbeiten und durch die Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich (s.u.) anreichern.

Manuelle Buchungen

Werden manuelle Buchungen „on top“ gebucht, so ist meist in dem Konsolidierungsbeleg nur eine einzige Beleggesellschaft eingetragen. Folglich ist dann auch die maschinell ermittelte Gegen-Gesellschaft identisch zur Buchungsgesellschaft. Gleiches gilt analog für Geschäftsbereich und Gegen-Geschäftsbereich.

Abbildung 4: Übersicht der Konsolidierungsbuchungen

Aggregationen in den Geschäftsbereichen

In der Anwendung UBR können sog. Schemata aus Geschäftsbereichen und Aggregaten gebildet werden. Für das Reporting im Sinne einer Matrixkonsolidierung ist es zwingend erforderlich, mindestens ein Schema im Sinne eines „obersten, gemeinsamen Knotens“ zu bilden.

Abbildung 5: In der Anwendung UBR wird aus Geschäftsbereichen und Aggregaten ein Schema gebildet

Konzern-Reports

Im Konzern-Report kann man ein zuvor definiertes Schema auswählen. Wenn man ein Schema auswählt, muss man auch zwingend die gewünschte Hierarchieebene angeben. Die Aggregation der Geschäftsbereiche wird dann entsprechend dem zuvor gewählten Schema durchgeführt. Sollen die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich ausgewertet werden, ist dies ganz rechts mit dem entsprechenden Schalter anzukreuzen.

Abbildung 6: Parameter im Report-Kopfsatz

Kreuzt man die Option mit Gegen-Geschäftsbereichnicht an, so verwendet der Report die bisherige Logik und wertet lediglich das an der Konsolidierungsbuchung befindliche Attribut segmentübergreifend aus. Solange Geschäftsbereiche nicht aggregiert werden, ist dies ausreichend.

Die Angabe Hierarchieebene 0 ist möglich, aber vermutlich nur bedingt sinnvoll. Verständlicherweise existieren hier keinerlei segmentübergreifende Buchungen, da wir ja nur ein einziges Segment betrachten, dieses ist per Definition identisch mit dem Gesamtkonzern.

Die hier verwendete Report-Spaltenoption #KTKGB zeigt in den Spalten in alphanumerischer Reihenfolge die einzelnen konsolidierten Segmente an, sowie die Überleitung (SegmÜbergr) zur legalen Konsolidierung. Die letzte Spalte (Gesamt) entspricht hierbei immer der legalen Konsolidierung. In den folgenden Screenshots sehen wir daher, dass – unabhängig von der betrachteten Hierarchiestufe – in der letzten Berichtsspalte immer die identischen Beträge angezeigt werden.

Abbildung 7: Reportergebnisanzeige, Hierarchieebene 0

Abbildung 8: Reportergebnisanzeige, Hierarchieebene 1

Abbildung 9: Reportergebnisanzeige, Hierarchieebene 2

Aufriss Buchungen

Bekanntlich können wir aus der Report-Ergebnisanzeige heraus in die Konsolidierungsbuchungen verzweigen. Wir müssen allerdings beachten, dass wir in der Anzeige der Konsolidierungsbuchungen keine Selektion auf „segmentübergreifend“ im Sinne des zuvor betrachteten Reports und dessen UBR-Aggregationsschema zur Verfügung haben, weshalb wir hier immer sämtliche Konsolidierungsbuchungen, beispielsweise eines Kontos oder einer Position angezeigt bekommen.

Wenn wir also den Betrag der segmentübergreifenden Konsolidierungsbuchungen in Höhe von 3.489.600,00 bei den sonstigen betrieblichen Erträgen nachvollziehen möchten, sehen wir dies nicht auf den ersten Blick:

Abbildung 10: Konsolidierungsbuchungen (aus der Reportergebnisanzeige heraus)

Man kann die Konsolidierungsbuchungen in einem ersten Schritt nach dem Kriterium „segmentübergreifend“ filtern, muss aber bedenken, dass je nach zuvor im Report gewähltem Berichtsschema, durch die Aggregation bedingt, nun immer noch segmentinterne Konsolidierungsbuchungen als segmentübergreifend gekennzeichnet sein können.

In diesem Fall hilft es nur, sich in den einzelnen Buchungszeilen jeweils Geschäftsbereich sowie Gegen-Geschäftsbereich anzusehen, und die Buchungsbeträge einzeln zu markieren:

Abbildung 11: Konsolidierungsbuchungen manuell gefiltert

Wechsel-Strategie für Kunden

Aktuell gibt es noch keine Erfahrungswerte, da das Thema Matrixkonsolidierung noch zu neu ist. Zunächst war die Empfehlung seitens Hotline, wenn Kunden die Matrixkonsolidierung nutzen möchten, sollten sie ihr System neu aufsetzen, da die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich nicht manuell in den Konsolidierungsbuchungen befüllt bzw. bearbeitet werden können. Zwar sind die Felder in den vorgetragenen Konsolidierungsbuchungen stets befüllt. Es kann aber vorkommen, dass sie nicht korrekt befüllt wurden. Andererseits stellt das Neu-Aufsetzen des gesamten Systems eine relativ hohe Hürde dar. Daher sollte wohl idealerweise im Einzelfall geprüft werden, ob nach dem Erzeugen der Periodenvorträge möglicherweise Vortragsbelege mit mehr als zwei Gesellschafts-/Geschäfts-bereichskombinationen existieren und wie diese „geheilt“ werden können.

Unproblematisch sind z. B. KK V-Belege. Problematisch könnten dagegen zum Beispiel ZU-, SK- und AE-Vorträge sein, da diese nicht mehr alle Buchungen aus der Vorperiode enthalten und somit der Gegen-Geschäftsbereich nicht mehr korrekt zu ermitteln ist. Dies trifft generell auf WX-Belege zu, da in den Vorträgen nicht mehr sämtliche Buchungszeilen des Ursprungsbeleges enthalten sind und daher die Gegen-Gesellschaft unter Umständen nicht korrekt ermittelt werden kann. Allerdings laufen diese Belege aus, wenn zum zweiten Mal ein Geschäftsjahreswechsel vollzogen wird.

Neue Datenart

Entweder bleibt der Kunde in der selben Datenbank und nutzt lediglich eine neue Datenart, dann können die allermeisten übrigen Stammdaten (z.B. Kontenplan, Spiegeldefinitionen, Reportdefinitionen) weiterhin genutzt werden.

Neue Datenbank

Der Kunde beginnt eine komplett neue Datenbank. Dieser Weg bietet die Chance, auch bei den Stammdaten noch einmal neu aufsetzen zu können, falls hier möglicherweise auch Überarbeitungsbedarf besteht.

Nutzt der Kunde Schnittstellen, so sollte bitte unbedingt geprüft werden, wie die bisherige Konsis-Datenbank in diesen Schnittstellen angesprochen wird.

Beispiel: In Schnittstellen zum Importieren von Daten aus ERP-Systemen ist die Datenbank, in die geschrieben wird, in aller Regel „unter der Motorhaube“ fest eingestellt. Folglich kann der Kunde nicht in der Programmoberfläche einstellen, in welche Datenbank geschrieben werden soll.

Werden Daten z. B. über Datamart in nachgelagerte Berichtssysteme übertragen, sollte geprüft werden, ob diese Systeme in der Lage sind, auch die „alte“ Datenbank bei Bedarf anzuzapfen, wenn beispielsweise Vergleichszahlen berichtet werden sollen.

Der laufende Pflegeaufwand seitens der Kunden-IT ist etwas größer, da man bedenken muss, dass die „neue“ und die „alte“ Datenbank bei zukünftigen Releasewechseln aktualisiert werden, damit auf die Daten in der „alten“ Datenbank nach wie vor zugegriffen werden kann.

Besonderheiten bei Konsolidierungskreisveränderungen

Der interne Verkauf (IK) funktioniert korrekt. Bei Entkonsolidierung (XK und YK) und Verschmelzung (PS) kommt es immer dann zu einem Problem, wenn es mehrere zu eliminierende Belege (z. B. MB01 V und MB02 V) gibt, da es zu diesen Belegen immer nur einen einzigen Beleg gibt, der die Buchungen eliminiert. Dadurch kann es dann vorkommen, dass mehr als zwei Geschäftsbereiche in einem Beleg verarbeitet werden müssen und Gegen-Gesellschaft und Gegen-Geschäftsbereich nicht korrekt befüllt werden können. Dieses Problem wird in einem separaten JIRA-Task beschrieben, der zu einem späteren Zeitpunkt umgesetzt werden soll.

Der aktuelle Stand kommt in das Release 22.3. Wir haben uns unter Abwägung aller Pros und Contras zu diesem Schritt entschlossen, da wir angenommen haben, dass ein Kunde, der mit Matrixkonsolidierung arbeiten möchte, nicht gleich im ersten Berichtsjahr eine Entkonsolidierung oder eine Verschmelzung durchzuführen hat.

Andernfalls hätte es bedeutet, die bis auf die oben erwähnten Situationen bei Entkonsolidierung und Verschmelzung komplett funktionstüchtig umgesetzte Matrixkonsolidierung als Ganzes auf einen späteren Veröffentlichungszeitpunkt zu verschieben. Dies schien uns nicht angebracht.

Die Warnmeldung, dass mehr als zwei Geschäftsbereiche je Buchungssatznummer verwendet werden, wurde für die Verarbeitungen ausgeschaltet, damit sie Kunden nicht stört, die zwar mit Geschäftsbereichen, jedoch nicht mit der neuen Funktionalität arbeiten.

Besonderheiten bei Spiegelumbuchungen

Die Verarbeitungen KU, SU und FU führen Spiegelumbuchungen durch. KU bucht Spiegelvorträge im Rahmen einer Erstkonsolidierung um in Zugang Konsolidierungskreis. Die SU korrigiert die Spiegeldarstellung im Rahmen der Schuldenkonsolidierung. Die FU durchzuführen, sollte eigentlich gar nicht mehr erforderlich sein. Dennoch kann diese Verarbeitung in der Praxis noch immer gute Dienste leisten, wenn es darum geht, Spiegelvorträge abzustimmen und zu korrigieren. Hierbei können je Buchungssatznummer mehr als zwei Gegen-Geschäftsbereiche vorkommen, mit der Folge, dass diese nicht korrekt ermittelt werden können.

In der Praxis stelle ich mir allerdings die Frage, wie relevant etwaige Spiegeldarstellungen in Bezug auf (aggregierte) Geschäftsbereiche sind.

Fragen & Antworten

  1. Q: Es können je Konsolidierungsbeleg max. 100 Buchungssätze gebildet werden. Bei zwei Gesellschaften mit jeweils 10 Geschäftsbereichen werden in maximaler Ausprägung bereits 100 Kombinationsmöglichkeiten erreicht, somit wären 100 Buchungssätze erforderlich. Was machen wir im Rahmen von Schulden- bzw. Aufwands- und Ertragskonsolidierung, wenn es mehr Kombinationsmöglichkeiten werden?
    A: Ab dem Buchungssatz 99 können keine neuen Buchungssatznummern mehr generiert werden, da das Feld nur zweistellig ist, daher wird der „Rest“ dann in Buchungssatznummer 99 verarbeitet. > Folge: In der letzten Buchungssatznummer kann es Buchungen mit mehr als zwei Geschäftsbereichen geben, mit der Folge, dass der Gegen-Geschäftsbereich nicht korrekt ermittelt werden kann.
  2. Q: Wie werden die Felder Gegen-Gesellschaft und Gegen-Geschäftsbereich für alte, abgeschlossene Perioden angezeigt?
    A: Nach dem Einspielen des Release 22.3 werden aktuell die Spalten für Gegen-Gesellschaft und Gegen-Geschäftsbereich leer angezeigt. Hat der Kunde die Ansichts-Option Leere Spalten ausblenden gewählt, werden die Spalten nicht mehr angezeigt. Dies gilt selbstverständlich auch für alte, abgeschlossene Perioden.
  3. Q: Wie wird mit den Feldern Gegen-Gesellschaft und Gegen-Geschäftsbereich umgegangen, wenn der Kunde gar nicht mit Geschäftsbereichen arbeitet?
    A: Auch wenn wir gar nicht mit Geschäftsbereichen arbeiten, wird dennoch das Feld Gegen-Gesellschaft zukünftig immer befüllt. Dies erleichtert auch das Verständnis und die Nachvollziehbarkeit der Buchungen, die beispielsweise in SU-Belegen erzeugt werden.
  4. Q: Können die Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich mit Xlslink gelesen werden?
    A: Die Lesefunktion Konsolidierungsbuchungen von IDL Xlslink kann derzeit die beiden neuen Felder noch nicht auslesen, die Funktionalität soll aus Gründen der Vollständigkeit mit einem Fixpack nachgeschoben werden. Für die Exportfunktion Konsolidierungsbuchungen sind die beiden Felder ohnehin irrelevant, da in Konsis keine Möglichkeit besteht, die Felder manuell zu befüllen und somit auch keine Möglichkeit besteht, die Feldinhalte zu importieren.
  5. Q: Wie sind die Auswertungsmöglichkeiten im Designer oder in anderen Berichtswerkzeugen, die über Datamart zugreifen?
    A: Derzeit wird beim Erzeugen des Reportergebnisses in Konsis entschieden, welche Konsolidierungsbuchung(en) als segmentintern und welche als segmentübergreifend einsortiert werden müssen. Die fachliche Logik steckt also in der Erzeugung des Reportergebnisses. Folglich müsste in externen Berichtswerkzeugen, wie z.B. IDL Designer, diese Logik nachgebaut werden, um dieselben Auswertungen mit denselben Ergebnissen fahren zu können, wie direkt in Konsis.
  6. Q: Stehen die Felder Gegen-Gesellschaft und Gegen-Geschäftsbereich zur Auswertung über die MISPAR Schnittstelle zur Verfügung?
    A: MISPAR-Schnittstelle Version 1 bis 3 kopiert bereits vorhandene Daten in weitere Datenbanktabellen K8xx. Version 4 der MISPAR-Schnittstelle ist eine Menge von Datenbank-Views, die den direkten Zugriff auf die KONSIS-Daten erlauben, ohne vorher einen Kopiervorgang starten zu müssen. Diese Version ist auch bekannt als Datamart. Die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich sind bislang in keiner Version der MISPAR berücksichtigt. > Meeting am 18.8. HGR, BSI, UWE, Ergebnis:
    Es kann nicht schaden, die zwei neuen Felder in den Views (MISPAR Version 4) zur Verfügung zu stellen. Die Versionen 1-3 sollen jedoch nicht mehr angefasst werden. Ähnlich wie in IDL Xlslink möchten wir gerne der Vollständigkeit halber die beiden Felder perspektivisch zur Verfügung stellen. Dies könnte in einem späteren Release nachgeliefert werden.

Literaturhinweise

Zum Öffnen des jeweiligen Dokuments bitte auf die Dokumentenvorschau in der rechten Spalte doppelklicken.

Deutsches Rechnungslegungs Standards Committee: DRS28 (Segmentberichterstattung), veröffentlicht durch das Bundesministerium der Justiz und für Verbraucherschutz im Bundesanzeiger Banz AT 05.08.2020 B2

Wirth, Johannes; Alper, Rolf und Neis, Thomas: Softwareseitige Umsetzung einer intern/extern harmonisierten Konsolidierung – Matrixkonsolidierung, in: KoR 7-8/2013 Seite 370-375.
Published:

Matrixkonsolidierung

Inhaltsverzeichnis

Einleitung / Begriffsklärung

Wenn von Harmonisierung des internen und externen Konzern-Rechnungswesens die Rede ist, fällt regelmäßig das Schlagwort Matrixkonsolidierung, weil man die legale Sichtweise auf der X-Achse, die interne Sichtweise auf der Y-Achse einer Matrix darstellen kann.

Abbildung 1: Beispiel einer Matrixkonsolidierung

Solange eine Gesellschaft eineindeutig einem Segment zugeordnet werden kann, ist die Umsetzung einer Matrixkonsolidierung nicht weiter anspruchsvoll, da die Segmente in IDL Konsis z. B. über reporttechnische Teilkonzerne abgebildet werden können.

Entscheidend beim Reporting konsolidierter Segmente ist immer die Frage: Wie ist jede einzelne Konsolidierungsbuchung einzuordnen: segment-intern oder segmentübergreifend. Bei der Abbildung über reporttechnische Teilkonzerne braucht sich der Anwender darüber keine Gedanken zu machen, das erledigt in IDL Konsis das Programm REPKTK.

Sobald sog. Zebra-Gesellschaften vorkommen (Gesellschaften, die nicht eineindeutig einem einzigen Segment zugerechnet werden können), müssen in IDL Konsis die Daten dieser Gesellschaft und aller übrigen Gesellschaften mit Geschäftsbereichen gemeldet werden.

Die Konsolidierung auf Ebene der Geschäftsbereiche ist in IDL Konsis bereits vollständig umgesetzt.

Zwar wurde vor Jahren eine Möglichkeit in IDL Konsis geschaffen, Geschäftsbereiche zu aggregieren. Jedoch machte sie bislang reporttechnisch u. U. Probleme, da das bisherige Merkmal an der Konsolidierungsbuchung, welches sie als segment-intern bzw. segmentübergreifend kennzeichnete, nicht mehr geeignet war, dies auch in einer aggregierten Struktur korrekt zu kennzeichnen.

Wir wollen dies mit dem folgenden Beispiel verdeutlichen:

Abbildung 2: Beispiel für IC-Beziehungen segment-intern und segmentübergreifend

Die erste Buchung mit Betrag 100 gilt als segment-intern, da sie Sachverhalte innerhalb des Segments Automotive bucht, die zweite Buchung mit Betrag 150 gilt als segmentübergreifend, da sie Sachverhalte in zwei unterschiedlichen Segmenten bucht.

Umsetzung in IDL Konsis

Es wurden vor der programmtechnischen Umsetzung unterschiedliche Lösungsansätze intensiv diskutiert. Schließlich wurde dann die folgende Lösung umgesetzt:

Konsolidierungsbuchungen

Das in der Konsolidierungsbuchung bereits seit Jahren vorhandene Kennzeichen segmentübergreifend ist nicht mehr ausreichend, sobald Geschäftsbereiche aggregiert werden. Da durch die Aggregation mehrerer Geschäftsbereiche auch als segmentübergreifend markierte Buchungen zu segment-internen Buchungen werden können.

Da wir davon ausgegangen sind, dass sich die Reportinganforderungen auch nach Durchführung der Konsolidierung ändern können, wollten wir eine in dieser Hinsicht möglichst flexible Lösung schaffen. Beispielsweise sollte der Anwendungsfall abgebildet werden können, dass im laufenden Jahr eine abweichende Aggregation der Segmente stattfindet wie im Vorjahr. Dennoch sollte das Vorjahr mit der aktuellen Segment-Struktur zu Vergleichszwecken berichtet werden können.

Daher hatten wir uns entschieden, zu den bereits an der Konsolidierungsbuchung vorhandenen Attributen Gesellschaft und Geschäftsbereich jeweils Gegen-Gesellschaft und Gegen-Geschäftsbereich als weitere Attribute hinzuzufügen. Damit nicht nur je Konsolidierungsbeleg, sondern je Konsolidierungsbuchung die betroffenen Partner eineindeutig sind.

Abbildung 3: Übersicht der Konsolidierungsbuchungen

Die neu geschaffenen Attribute Gegen-Gesellschaft/Gegen-Geschäftsbereich gehen nicht in die Prüfsummenberechnung mit ein.

Schulden- bzw. Aufwands- und Ertragskonsolidierung

Im Rahmen der Schulden- bzw. Aufwands- und Ertragskonsolidierung werden ggfs. innerhalb eines Konsolidierungsbelegs mehrere Buchungssatznummern verwendet, jeweils für jedes Pärchen bestehend aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich. Das bedeutet auch, dass wir nicht eine einzige Differenz je Gesellschaftspärchen auszubuchen haben, sondern es werden unter Umständen mehrere Differenzen je Kombination aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich ausgewiesen. Es ist zwingend erforderlich, dass die Konsolidierungsbuchungen je Buchungssatznummer, also je Pärchenkombination aus Gesellschaft/Geschäftsbereich und Gegen-Gesellschaft/Gegen-Geschäftsbereich aufgehen.

Dies ist auch einer der Hauptgründe, warum allein durch das Einspielen des Release 22.3 an dem bestehenden Datenbestand nichts verändert wird . Das Konvertierprogramm lässt die Konsolidierungsbuchungen unangetastet, da es die nötige Arbeit gar nicht leisten könnte.

Die Attribute Gegen-Gesellschaft/Gegen-Geschäftsbereich können nicht manuell ergänzt oder bearbeitet werden. Sie werden vom System befüllt, wenn eine Konsolidierungsverarbeitung gestartet wird.

Wenn der Kunde für eine bereits abgeschlossene Periode die neue Funktionalität ausprobieren möchte, oder eine bereits abgeschlossene Periode als Vergleichsperiode heranziehen möchte, müsste er sämtliche Konsolidierungsbuchungen überarbeiten und durch die Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich (s.u.) anreichern.

Manuelle Buchungen

Werden manuelle Buchungen „on top“ gebucht, so ist meist in dem Konsolidierungsbeleg nur eine einzige Beleggesellschaft eingetragen. Folglich ist dann auch die maschinell ermittelte Gegen-Gesellschaft identisch zur Buchungsgesellschaft. Gleiches gilt analog für Geschäftsbereich und Gegen-Geschäftsbereich.

Abbildung 4: Übersicht der Konsolidierungsbuchungen

Aggregationen in den Geschäftsbereichen

In der Anwendung UBR können sog. Schemata aus Geschäftsbereichen und Aggregaten gebildet werden. Für das Reporting im Sinne einer Matrixkonsolidierung ist es zwingend erforderlich, mindestens ein Schema im Sinne eines „obersten, gemeinsamen Knotens“ zu bilden.

Abbildung 5: In der Anwendung UBR wird aus Geschäftsbereichen und Aggregaten ein Schema gebildet

Konzern-Reports

Im Konzern-Report kann man ein zuvor definiertes Schema auswählen. Wenn man ein Schema auswählt, muss man auch zwingend die gewünschte Hierarchieebene angeben. Die Aggregation der Geschäftsbereiche wird dann entsprechend dem zuvor gewählten Schema durchgeführt. Sollen die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich ausgewertet werden, ist dies ganz rechts mit dem entsprechenden Schalter anzukreuzen.

Abbildung 6: Parameter im Report-Kopfsatz

Kreuzt man die Option mit Gegen-Geschäftsbereichnicht an, so verwendet der Report die bisherige Logik und wertet lediglich das an der Konsolidierungsbuchung befindliche Attribut segmentübergreifend aus. Solange Geschäftsbereiche nicht aggregiert werden, ist dies ausreichend.

Die Angabe Hierarchieebene 0 ist möglich, aber vermutlich nur bedingt sinnvoll. Verständlicherweise existieren hier keinerlei segmentübergreifende Buchungen, da wir ja nur ein einziges Segment betrachten, dieses ist per Definition identisch mit dem Gesamtkonzern.

Die hier verwendete Report-Spaltenoption #KTKGB zeigt in den Spalten in alphanumerischer Reihenfolge die einzelnen konsolidierten Segmente an, sowie die Überleitung (SegmÜbergr) zur legalen Konsolidierung. Die letzte Spalte (Gesamt) entspricht hierbei immer der legalen Konsolidierung. In den folgenden Screenshots sehen wir daher, dass – unabhängig von der betrachteten Hierarchiestufe – in der letzten Berichtsspalte immer die identischen Beträge angezeigt werden.

Abbildung 7: Reportergebnisanzeige, Hierarchieebene 0

Abbildung 8: Reportergebnisanzeige, Hierarchieebene 1

Abbildung 9: Reportergebnisanzeige, Hierarchieebene 2

Aufriss Buchungen

Bekanntlich können wir aus der Report-Ergebnisanzeige heraus in die Konsolidierungsbuchungen verzweigen. Wir müssen allerdings beachten, dass wir in der Anzeige der Konsolidierungsbuchungen keine Selektion auf „segmentübergreifend“ im Sinne des zuvor betrachteten Reports und dessen UBR-Aggregationsschema zur Verfügung haben, weshalb wir hier immer sämtliche Konsolidierungsbuchungen, beispielsweise eines Kontos oder einer Position angezeigt bekommen.

Wenn wir also den Betrag der segmentübergreifenden Konsolidierungsbuchungen in Höhe von 3.489.600,00 bei den sonstigen betrieblichen Erträgen nachvollziehen möchten, sehen wir dies nicht auf den ersten Blick:

Abbildung 10: Konsolidierungsbuchungen (aus der Reportergebnisanzeige heraus)

Man kann die Konsolidierungsbuchungen in einem ersten Schritt nach dem Kriterium „segmentübergreifend“ filtern, muss aber bedenken, dass je nach zuvor im Report gewähltem Berichtsschema, durch die Aggregation bedingt, nun immer noch segmentinterne Konsolidierungsbuchungen als segmentübergreifend gekennzeichnet sein können.

In diesem Fall hilft es nur, sich in den einzelnen Buchungszeilen jeweils Geschäftsbereich sowie Gegen-Geschäftsbereich anzusehen, und die Buchungsbeträge einzeln zu markieren:

Abbildung 11: Konsolidierungsbuchungen manuell gefiltert

Wechsel-Strategie für Kunden

Aktuell gibt es noch keine Erfahrungswerte, da das Thema Matrixkonsolidierung noch zu neu ist. Zunächst war die Empfehlung seitens Hotline, wenn Kunden die Matrixkonsolidierung nutzen möchten, sollten sie ihr System neu aufsetzen, da die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich nicht manuell in den Konsolidierungsbuchungen befüllt bzw. bearbeitet werden können. Zwar sind die Felder in den vorgetragenen Konsolidierungsbuchungen stets befüllt. Es kann aber vorkommen, dass sie nicht korrekt befüllt wurden. Andererseits stellt das Neu-Aufsetzen des gesamten Systems eine relativ hohe Hürde dar. Daher sollte wohl idealerweise im Einzelfall geprüft werden, ob nach dem Erzeugen der Periodenvorträge möglicherweise Vortragsbelege mit mehr als zwei Gesellschafts-/Geschäfts-bereichskombinationen existieren und wie diese „geheilt“ werden können.

Unproblematisch sind z. B. KK V-Belege. Problematisch könnten dagegen zum Beispiel ZU-, SK- und AE-Vorträge sein, da diese nicht mehr alle Buchungen aus der Vorperiode enthalten und somit der Gegen-Geschäftsbereich nicht mehr korrekt zu ermitteln ist. Dies trifft generell auf WX-Belege zu, da in den Vorträgen nicht mehr sämtliche Buchungszeilen des Ursprungsbeleges enthalten sind und daher die Gegen-Gesellschaft unter Umständen nicht korrekt ermittelt werden kann. Allerdings laufen diese Belege aus, wenn zum zweiten Mal ein Geschäftsjahreswechsel vollzogen wird.

Neue Datenart

Entweder bleibt der Kunde in der selben Datenbank und nutzt lediglich eine neue Datenart, dann können die allermeisten übrigen Stammdaten (z.B. Kontenplan, Spiegeldefinitionen, Reportdefinitionen) weiterhin genutzt werden.

Neue Datenbank

Der Kunde beginnt eine komplett neue Datenbank. Dieser Weg bietet die Chance, auch bei den Stammdaten noch einmal neu aufsetzen zu können, falls hier möglicherweise auch Überarbeitungsbedarf besteht.

Nutzt der Kunde Schnittstellen, so sollte bitte unbedingt geprüft werden, wie die bisherige Konsis-Datenbank in diesen Schnittstellen angesprochen wird.

Beispiel: In Schnittstellen zum Importieren von Daten aus ERP-Systemen ist die Datenbank, in die geschrieben wird, in aller Regel „unter der Motorhaube“ fest eingestellt. Folglich kann der Kunde nicht in der Programmoberfläche einstellen, in welche Datenbank geschrieben werden soll.

Werden Daten z. B. über Datamart in nachgelagerte Berichtssysteme übertragen, sollte geprüft werden, ob diese Systeme in der Lage sind, auch die „alte“ Datenbank bei Bedarf anzuzapfen, wenn beispielsweise Vergleichszahlen berichtet werden sollen.

Der laufende Pflegeaufwand seitens der Kunden-IT ist etwas größer, da man bedenken muss, dass die „neue“ und die „alte“ Datenbank bei zukünftigen Releasewechseln aktualisiert werden, damit auf die Daten in der „alten“ Datenbank nach wie vor zugegriffen werden kann.

Besonderheiten bei Konsolidierungskreisveränderungen

Der interne Verkauf (IK) funktioniert korrekt. Bei Entkonsolidierung (XK und YK) und Verschmelzung (PS) kommt es immer dann zu einem Problem, wenn es mehrere zu eliminierende Belege (z. B. MB01 V und MB02 V) gibt, da es zu diesen Belegen immer nur einen einzigen Beleg gibt, der die Buchungen eliminiert. Dadurch kann es dann vorkommen, dass mehr als zwei Geschäftsbereiche in einem Beleg verarbeitet werden müssen und Gegen-Gesellschaft und Gegen-Geschäftsbereich nicht korrekt befüllt werden können. Dieses Problem wird in einem separaten JIRA-Task beschrieben, der zu einem späteren Zeitpunkt umgesetzt werden soll.

Der aktuelle Stand kommt in das Release 22.3. Wir haben uns unter Abwägung aller Pros und Contras zu diesem Schritt entschlossen, da wir angenommen haben, dass ein Kunde, der mit Matrixkonsolidierung arbeiten möchte, nicht gleich im ersten Berichtsjahr eine Entkonsolidierung oder eine Verschmelzung durchzuführen hat.

Andernfalls hätte es bedeutet, die bis auf die oben erwähnten Situationen bei Entkonsolidierung und Verschmelzung komplett funktionstüchtig umgesetzte Matrixkonsolidierung als Ganzes auf einen späteren Veröffentlichungszeitpunkt zu verschieben. Dies schien uns nicht angebracht.

Die Warnmeldung, dass mehr als zwei Geschäftsbereiche je Buchungssatznummer verwendet werden, wurde für die Verarbeitungen ausgeschaltet, damit sie Kunden nicht stört, die zwar mit Geschäftsbereichen, jedoch nicht mit der neuen Funktionalität arbeiten.

Besonderheiten bei Spiegelumbuchungen

Die Verarbeitungen KU, SU und FU führen Spiegelumbuchungen durch. KU bucht Spiegelvorträge im Rahmen einer Erstkonsolidierung um in Zugang Konsolidierungskreis. Die SU korrigiert die Spiegeldarstellung im Rahmen der Schuldenkonsolidierung. Die FU durchzuführen, sollte eigentlich gar nicht mehr erforderlich sein. Dennoch kann diese Verarbeitung in der Praxis noch immer gute Dienste leisten, wenn es darum geht, Spiegelvorträge abzustimmen und zu korrigieren. Hierbei können je Buchungssatznummer mehr als zwei Gegen-Geschäftsbereiche vorkommen, mit der Folge, dass diese nicht korrekt ermittelt werden können.

In der Praxis stelle ich mir allerdings die Frage, wie relevant etwaige Spiegeldarstellungen in Bezug auf (aggregierte) Geschäftsbereiche sind.

Fragen & Antworten

  1. Q: Es können je Konsolidierungsbeleg max. 100 Buchungssätze gebildet werden. Bei zwei Gesellschaften mit jeweils 10 Geschäftsbereichen werden in maximaler Ausprägung bereits 100 Kombinationsmöglichkeiten erreicht, somit wären 100 Buchungssätze erforderlich. Was machen wir im Rahmen von Schulden- bzw. Aufwands- und Ertragskonsolidierung, wenn es mehr Kombinationsmöglichkeiten werden?
    A: Ab dem Buchungssatz 99 können keine neuen Buchungssatznummern mehr generiert werden, da das Feld nur zweistellig ist, daher wird der „Rest“ dann in Buchungssatznummer 99 verarbeitet. > Folge: In der letzten Buchungssatznummer kann es Buchungen mit mehr als zwei Geschäftsbereichen geben, mit der Folge, dass der Gegen-Geschäftsbereich nicht korrekt ermittelt werden kann.
  2. Q: Wie werden die Felder Gegen-Gesellschaft und Gegen-Geschäftsbereich für alte, abgeschlossene Perioden angezeigt?
    A: Nach dem Einspielen des Release 22.3 werden aktuell die Spalten für Gegen-Gesellschaft und Gegen-Geschäftsbereich leer angezeigt. Hat der Kunde die Ansichts-Option Leere Spalten ausblenden gewählt, werden die Spalten nicht mehr angezeigt. Dies gilt selbstverständlich auch für alte, abgeschlossene Perioden.
  3. Q: Wie wird mit den Feldern Gegen-Gesellschaft und Gegen-Geschäftsbereich umgegangen, wenn der Kunde gar nicht mit Geschäftsbereichen arbeitet?
    A: Auch wenn wir gar nicht mit Geschäftsbereichen arbeiten, wird dennoch das Feld Gegen-Gesellschaft zukünftig immer befüllt. Dies erleichtert auch das Verständnis und die Nachvollziehbarkeit der Buchungen, die beispielsweise in SU-Belegen erzeugt werden.
  4. Q: Können die Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich mit Xlslink gelesen werden?
    A: Die Lesefunktion Konsolidierungsbuchungen von IDL Xlslink kann derzeit die beiden neuen Felder noch nicht auslesen, die Funktionalität soll aus Gründen der Vollständigkeit mit einem Fixpack nachgeschoben werden. Für die Exportfunktion Konsolidierungsbuchungen sind die beiden Felder ohnehin irrelevant, da in Konsis keine Möglichkeit besteht, die Felder manuell zu befüllen und somit auch keine Möglichkeit besteht, die Feldinhalte zu importieren.
  5. Q: Wie sind die Auswertungsmöglichkeiten im Designer oder in anderen Berichtswerkzeugen, die über Datamart zugreifen?
    A: Derzeit wird beim Erzeugen des Reportergebnisses in Konsis entschieden, welche Konsolidierungsbuchung(en) als segmentintern und welche als segmentübergreifend einsortiert werden müssen. Die fachliche Logik steckt also in der Erzeugung des Reportergebnisses. Folglich müsste in externen Berichtswerkzeugen, wie z.B. IDL Designer, diese Logik nachgebaut werden, um dieselben Auswertungen mit denselben Ergebnissen fahren zu können, wie direkt in Konsis.
  6. Q: Stehen die Felder Gegen-Gesellschaft und Gegen-Geschäftsbereich zur Auswertung über die MISPAR Schnittstelle zur Verfügung?
    A: MISPAR-Schnittstelle Version 1 bis 3 kopiert bereits vorhandene Daten in weitere Datenbanktabellen K8xx. Version 4 der MISPAR-Schnittstelle ist eine Menge von Datenbank-Views, die den direkten Zugriff auf die KONSIS-Daten erlauben, ohne vorher einen Kopiervorgang starten zu müssen. Diese Version ist auch bekannt als Datamart. Die neuen Attribute Gegen-Gesellschaft und Gegen-Geschäftsbereich sind bislang in keiner Version der MISPAR berücksichtigt. > Meeting am 18.8. HGR, BSI, UWE, Ergebnis:
    Es kann nicht schaden, die zwei neuen Felder in den Views (MISPAR Version 4) zur Verfügung zu stellen. Die Versionen 1-3 sollen jedoch nicht mehr angefasst werden. Ähnlich wie in IDL Xlslink möchten wir gerne der Vollständigkeit halber die beiden Felder perspektivisch zur Verfügung stellen. Dies könnte in einem späteren Release nachgeliefert werden.

Literaturhinweise

Zum Öffnen des jeweiligen Dokuments bitte auf die Dokumentenvorschau in der rechten Spalte doppelklicken.

Deutsches Rechnungslegungs Standards Committee: DRS28 (Segmentberichterstattung), veröffentlicht durch das Bundesministerium der Justiz und für Verbraucherschutz im Bundesanzeiger Banz AT 05.08.2020 B2

Wirth, Johannes; Alper, Rolf und Neis, Thomas: Softwareseitige Umsetzung einer intern/extern harmonisierten Konsolidierung – Matrixkonsolidierung, in: KoR 7-8/2013 Seite 370-375.
For an optimal Community experience, Please view on Desktop
Powered by Zendesk