In IDL.KONSIS there is automated support for the merger of a subsidiary with its parent company (upstream merger) and for the merger of two subsidiaries (sidestream merger). This document describes the prerequisites and steps that are necessary for the correct processing.
[company master data]
If a company is merged then, in the company master data (GES application), the information "merged with" and "merged on" has to be updated. Neither of these pieces of information can be entered, on their own, without the other. If a date is entered in the field "merged on" then an entry in the field "valid until" will be automatically assigned. This is the last date of the next higher period with the period indicator 'J' . If this has not yet been created then 24 months are calculated from the last 'J' period prior to the merger. The merger data will be displayed in the company financial statements + monitor if the date lies within the current period.
[transaction development definitions]
In order to correctly show the disposals of and additions to assets in the transaction developments you have to create additional transaction development columns (SSP application) with the usage tag 'MER' = additions and disposals from mergers. Likewise, all transaction development areas with the carry forward posting key (BSL application) have to be defined with the usage tag 'ME' = addition from merger and 'MF' = disposal from merger and allocated to these transaction development columns. For transaction development with sample accounting you will additionally need a cancellation posting key with the usage tag 'SME' or 'SMF'. Furthermore, for each transaction development, posting keys without usage tags should also be created that are allocated to the transaction development column 'MER' so that they are available in the event of manual entry. The transaction development columns with the usage tag 'MER' are evaluated differently in the transaction development reports: They are not reviewed in company reports and for each company there can be values in these transaction development columns. However, in group reports, the sum in this transaction development column must be 0.00, otherwise the appropriate error message will be displayed similarly as for the transaction development columns with the usage tag 'UMB'.
If you work with the standard transaction development columns from IDL.KONSIS that are carried forward then these transaction development extensions are included in the import files in the delivery batch folder and will already be available when these files are regularly imported.
[shareholding transactions]
For a parent company, the disposal of a participation has to be updated in Shareholding Transactions (GESGES). For this you use the posting key with the usage tag B16 for a merger. Currently, a merger is only supported in IDL.KONSIS if the absorbing company holds 100% of the subsidiary that is to be merged. That is why in the shareholding transactions you are only allowed to enter -100% in the percentage fields. Likewise, the entries are checked against the settings made previously in GES with respect to the merger date and merger company. Any potential bonus/malus arising from the merger has to be defined in the fields "Surplus Proceeds Account/ -BSL and -LC value. These data are important and have to be entered correctly because erroneous information can subsequently lead to erroneous posting vouchers in the consolidation.
If two subsidiaries are merged with each other then the absorbing company has to be updated for the addition of a participation as well. For this you use a transaction with a posting key with the usage tag B19. Transactions with this posting key may only be updated with 0% because no further participation percentages are provided in the case of a merger. The merger company has to be likewise updated in order to be able to distinguish between, potentially, several issues.
[other EA data]
The appropriate functions for the disposal or addition of development transactions from the merged company to the absorbing company is provided by the "Merger Company Financial Statements" MERGES application. It is included in the the resource tree in the "Company Financial Statements" area, however, it can also be called up as a follow-on application from "Company Financial Statements + Monitor" (EA), or else via the short word MERGES.
First of all, you have to specify the merged company, the period and the fact. You may only specify companies where the information "merged on" and "merged with" has been updated in the company master data.
The MERGES application is divided into the following sub-areas:
Balances (account balances, IC balances, controlling balances, etc.) are generally not transferred. Nevertheless, especially for automatically calculating transaction developments, it is necessary to import the account balances of the company that will cease to exist on the date of the merger for MERGES, or to copy them from the previous period. This is the only possible way to correctly generate current changes and disposals/additions from mergers. Once MERGES has been executed then these account balances have to be deleted once again, as it is assumed that the merged company will not report any more balances in the current period and that, instead, these will already be available at the absorbing company. The functions in MERGES merely take into account development transactions, posting vouchers and the entries of the IC company at the other companies.
A log tracks which data records are implemented for the mergers.
When two subsidiaries are merged, the capital received by the absorbing company has to be additionally updated there using the posting key for additions for mergers so that, for the merger in the group, the capital can be correctly eliminated.
If the merger date of the company lies within the current period then this will be indicated, once participation identification and status identification have happened, by the <red> status in the PS column in the group financial statements + monitor. The "Merger" function can be started via the context menu "Deconsolidation/Merger" of KTKGES.
[merger capital consolidation for the merger of a subsidiary with its parent company]
Two vouchers are created: The merged company/parent company/PS voucher eliminates the capital consolidation voucher KK or KF.
Furthermore, a parent company/ merged company/ PP voucher is created where the following postings are generated:
If all the "key data" are entered correctly then the PP voucher should merge as a result of these postings. Any potential difference that arises is posted to the suspense account.
The PP voucher includes both the merged company as well as the absorbing company in the voucher number, although all the postings are generated for the absorbing company. This is necessary in order to be able to execute the correct automatic operation even if, in one period, several companies are merged with the same parent company. When carrying forward into the next period, the merged company is replaced with the absorbing company, i.e. a carry forward voucher ‘absorbing company / absorbing company KF’ where, in some circumstances, several merger processes will be combined.
[merger capital consolidation for the merger of a two subsidiaries]
Likewise, for such a merger a PS voucher (company / parent company /PS) eliminates the capital consolidation voucher KK or KF.
In addition, a parent company / absorbing company / PP voucher is created. The following postings are generated here:
As several companies would have the same subsidiary and this would result in a PP voucher with the same name, for further mergers, vouchers will be created using the consolidation method O0-O9. For the carry forward, the postings are integrated in a KF voucher. A transfer of the company in the voucher header does not happen.
[merger capital consolidation between the merged company and its subsidiaries]
Here, likewise, a PS voucher is first generated that cancels the capital consolidation voucher KK or KF
Furthermore, a subsidiary / new parent company / PK voucher is created that sets the same postings again.
If there are indirect minorities for the merged company or its subsidiaries then a carried forward FV voucher is eliminated via a voucher with the suffix PG and newly posted via a new voucher with the absorbing company and the suffix PF.
[merger other consolidation between the merged company and its parent company]
All carry forward vouchers with voucher numbers where the company that is to be merged is present are first derecognised in a voucher with the same companies and the 'Px' consolidation method with a reversed sign. The same values are posted once again in a voucher that includes the absorbing company in the voucher number and the same 'Px' consolidation method is used as the voucher for derecognition.
Possible voucher suffixes can be: PM (for VM vouchers), PX (for VX vouchers) and PZ (for VZ vouchers).