The purpose of the cash flow statement is to provide cash flow-oriented information for the preceding business year of a company or group of companies. The emphasis is therefore on the origin and use of the liquid funds.
This information can therefore be used as a basis in order to derive the capacity of a company to realise future means of payment. It also serves to estimate the future liquidity requirement.
It is hereby necessary to make the cash flow quantities available. Pure cash flow quantities are not normally available however. Instead of this, the change quantities are then indirectly determined. Such change quantities are made available in IDL Konsis in the form of transaction data, the account balances also being made available here.
For the correct presentation of the cash flow statement, the transaction data in IDL Konsis is to be subdivided into carry forward data and changes during the current period.
This has already been carried out for the standard history sheets (Assets, capital and provision history sheet) included in IDL Konsis.
Figure: sample provision history sheet
The controlling of the history sheet column in which the value is included is executed via a posting key which has a value column allocated to it.
However, the changes to all of the balance sheet accounts within the current period must be taken into account in the cash flow statement in order to calculate the liquidity change.
In order to ensure this, IDL Konsis offers the possibility of allocating balance sheet accounts which are not allocated to a standard history sheet, individual history sheets. These individual history sheets generate the corresponding transaction data (carried-forward, ongoing change), at the individual company closing level so that the transaction data from all of the balance sheet accounts is available in the cash flow statement (refer to part A of the documentation for the implementation of individual history sheets).
Situations exist at group level which necessitate a correction of the transaction data and with it the data in the history sheet columns. This is explained as follows:
The following non-conclusive listing results in a correction of the individual company closing transaction data:
Figure: necessary correction of the history sheet columns due to consolidation processing
Within the scope of the capital consolidation, the consolidation functions <KK> and <KA> in IDL Konsis are so implemented that the elimination of the equity capital and the participations are correctly executed in accordance with the history sheet columns.
Figure: Sample group equity capital history sheet, elimination at group level in accordance with the history sheet columns
Figure: Sample group assets history sheet, elimination at group level in accordance with the history sheet columns.
The debt consolidation (consolidation function SK) is currently so conceived that it does not execute the elimination posting in accordance with the history sheet columns. The consolidation function <SU> is implemented in IDL Konsis in order to obtain correct results in the cash flow statement. The consolidation function <SU> ensures that the debt consolidation is presented within the transaction data in keeping with the columns. Details are explained further down.
Changes to the consolidation extent (additions/decreases of affiliated companies) require a separate inclusion in the cash flow statement which is explained as follows.
The following consolidation processing is of fundamental importance when generating the capital flow statement:
Figure: Function of the KVAs
The %U-documents have no effect on the generation of the balance sheet as they only repost posting keys to the very same account. These documents are required for the correct presentation of the cash flow statement and the history sheet applications. This function guarantees a presentation of the group situation in accordance with the history sheet columns.
The SU-history sheet reposting for quota companies is executed according to quota.
The basic conception or manner of functioning of the various history sheet repostings is initially presented.
There then follows a description of the cases in which manual corrections of the SU-documents are necessary and how these are handled in IDL Konsis.
In the scope of the generation of the cash flow statement manual corrections are necessary in IDL Konsis as a result of changes to the consolidation extent. The necessary requirements are explained below.
Figure: Correlation between account balances and history sheet and further processing of the cash flow statement
The SK-history sheet reposting <SU> must be separately activated after execution of the consolidation processing <SK>. The function can be accessed from <KTKGES> (group monitor) via the action menu.
Figure: Calling up the SK-history sheet reposting
The debt consolidation function is currently conceived in IDL Konsis in such a way that the consolidation is not executed in accordance with the history sheet columns. The SK-history sheet reposting has the purpose of implementing the debt consolidation which was implemented at the accounts balance level in the history sheet movements
As from Release 2006.0, the SK history sheet reposting is executed on the basis of the IC-transaction data.
The consolidation function <KU> posts all of the carried forward figures for all of the history sheet applications (standard history sheet and individual history sheet) on the basis of the individual closing transaction data from the carry over history sheet column to the group extent changes history sheet column. IDL Konsis hereby utilizes a posting key with VwKnz=E for group extent addition and a posting key with VwKnz=F for group extent decrease.
A requirement for the automatic history sheet reposting is that posting keys with VwKnz=E and F are generated for all of the history sheet applications:
Figure: BSL with VwKnz=E and F
An additional requirement is that the access to the participations was entered in the 'GESGES' application with BSL=02 (access to first consolidation).
In the current conception of IDL Konsis the history sheet applications include all of the carried forward values from companies which join the group extent. These carried forward values were however not yet included in the previous year's group balance. The carried forward columns of all of the history sheets must therefore be corrected by the carried forward values of the first consolidation companies.
This required correction posting is implemented by the consolidation processing (KVA) <KU>. The <KU> is automatically called up when the capital consolidation <KK> is called up. The <KU> can also be separately implemented. The <KU> is an individual application. The application is called up from the action menu.
Figure: Call up the KK history sheet reposting
Repostings are implemented for all standard history sheet (assets and reserves) and for each individual history sheet. A carried forward value for the standard equity capital history sheet is not required as the capital accounts carried forward values are eliminated in the carried over columns in the scope of the capital consolidation.
The function <KU> can also be manually carried out if corrections are made to the history sheet transaction data.
Figure: Sample KU-posting document for company 500 in subgroup WTK-02:
As was already explained above, it is not necessary to generate repostings for capital accounts as an elimination of the group situation has already been implemented within the scope of the capital consolidation.
Figure: Presentation of the history sheet reposting in the fixed assets:
Figure: Presentation of the history sheet reposting in the cash flow report:
Figure: Presentation of the history sheet reposting in the reserves history sheet:
Figure: Presentation of the history sheet reposting in the cash flow report:
Figure: Presentation of the participation addition in the equity capital history sheet:
Figure: Effect of the history sheet reposting in individual history sheet S9 (balance sheet accounts without a history sheet application):
Figure: Presentation of the history sheet in the capital flow report:
Presentation of the history sheet reposting in the individual history sheet S1 payables history sheet without the generation of carried forward figures: the carried forward figures are included in the same sample accounting history sheet as the reposting of the carried forward figures are included in:
Figure: History sheet reposting in the liabilities history sheet
Sample: Company 500: addition to subgroup WTK-02 in period 2007
Action:
It is recommended that a separate type of data be generated for the entering of the balances in the acquisition balance sheet in the previous period (here 12/2006). This is then to be defined in such a way that only account balances and IC-balances are entered and so that a currency conversion is to be implemented.
Figure: FACE for additions to the consolidation extent
The balance sheet balances and the IC-balances can be entered after the type of data has been generated.
The data generation can be implemented as follows as an alternative:
Figure: Form entry
Figure: Importing the balance sheet balances
Singe record Application <KTOE>
After all of the relevant data has been entered, the period carried forward can be separately implemented in the current period in the 'PERGES' application separately for each history sheet or as a global application for all of the history sheets.
Illustration: Action <Erstellen Ges. carried forward new period>
Contrary to Procedure 1, the balances of the acquisition balance sheet are not entered in the previous period.
With Procedure 2, it is assumed that no data is available for the previous year upon the initial acquisition.
Conclusive history sheet transaction data (carried over figures and ongoing changes) normally exist for the standard history sheet (assets, capital and provisions).
No correct carried forward balances can be determined for the history sheet transaction data which is automatically generated by IDL Konsis as no data existed in the previous period. For this reason, the previous year's transaction data must be manually implemented.
It is first of all imperative that the carried forward transaction data of the automatic individual history sheet is generated prior to entering/importing the account balances.
Only then can the account balances be entered or imported. As carried forward transaction data has been entered in IDL Konsis IDL Konsis determines the correct transaction data for the automatic individual history sheet during entering/IMPORT.
This clear posting key can be used to ensure that the group extent additions and group extent decreases are presented separately in the cash flow statement.
Sample group extent addition: company 500 joins subgroup WTK-02 in period 2007.
The change to the liquid funds in the subgroup resulting from the acquisition of company 500 results in the following inventory account (=acquisition balance sheet):
Figure: Inventory account of the GES 500
Figure: Presentation of the addition in the cash flow report as an investment
Figure: Presentation of the acquired liquid funds in the group extent addition
The presentation of group extent decreases is only possible to an extent in the current Release.
Group extent decreases can only be currently presented if no balances from the deconsolidated company exist for the period.
In this case, no transaction data should exist for the deconsolidated company.
The liquidity-affecting change to the cash flow report is then evaluated by means of a manually generated document.
Figure: KONBUCH, manually generated document for the decrease.
The consolidation function <FU> ensures that situations posted at group level which result in a change to the individual closing balance are carried forward to the following period. This guarantees that the correct transaction data is evaluated in the following period within the cash flow statement.
Sample: In the 2006 period, a cheque which had not yet been received was subsequently posted at group level. This correction was carried out in the scope of the IC-clearing.
Figure: SK-Document
Figure: Presentation in the cash flow report:
The cheque posting must be deleted at group level in the following period. The consolidation function <FU> "ongoing change to carried forward"
Figure: FU-Posting in the following period
This ensures that the liquid funds carried forward are correctly presented in the cash flow statement.
Figure: Presentation in the cash flow report
As the FU-function is to be executed as the last consolidation function, it is recommended that the following sequence is adhered to.
Figure: recommended process procedure