Matrix Consolidation

1 Introduction / Definitions

When we talk about harmonization of internal and external group accounting, the keyword matrix consolidation regularly comes down, because you can present the legal perspective on the x-axis, the internal perspective on the y-axis of a matrix.

Figure 1: Matrix Consolidation Sample

As long as a company can be clearly assigned to a segment, the implementation of matrix consolidation is no longer demanding, since the segments can be mapped in IDL Konsis via reporting sub-groups, for example.

The key question for reporting consolidated segments is always the following: How to classify each individual consolidation posting: in-segment or across segments. The user does not have to worry about this when mapping the sub-groups for reporting. The program REPDIS is done in IDL Konsis.

As soon as so-called Zebra companies occur (companies which cannot be clearly assigned to a single segment), the data of these company and all other companies with business units must be reported in IDL Konsis.

Consolidation at business unit level has already been fully implemented in IDL Konsis.

Years ago, IDL Konsis created an opportunity to aggregate business units. However, it has so far caused problems in terms of reporting, as the previous feature of the consolidation posting, which it characterized as segment internal or cross-segment, was no longer suitable for correctly labeling this in an aggregated structure.

We would like to illustrate this with the following example:

Figure 2: Example for IC relationships segment-internal and segment-spanning

The first posting with the amount of 100 is considered to be segment internal, as it books events within the Automotive segment, the second posting with the amount of 150 is considered to be segment comprehensive, as it books events in two different segments.

2 Implementation in IDL Konsis

A number of different solutions were discussed at length before the program was implemented. Finally, the following solution was implemented:

2.1 Consolidation Postings

The cross-segment indicator that has been available in the consolidation posting for years is no longer sufficient once business units are aggregated. Because the aggregation of multiple business units can also make postings marked as cross-segment postings to be segment internal.

Since we assumed that the reporting requirements could change after consolidation has been carried out, we wanted to create a solution that was as flexible as possible in this regard. For example, it should be possible to depict the case where segments are aggregated differently in the current year than in the previous year. Nevertheless, it should be possible to report the previous year with the current segment structure for comparative purposes.

Therefore, we decided to add company and business unit attributes already available at the consolidation posting as counter-company and counter-business areas. This means that the partners concerned are unambiguous not only per consolidation voucher but per consolidation posting.

Figure 3: Overview of consolidation postings

The newly created attributes Counter-company/Counter-business unit are not included in the checksum calculation.

2.1.1 Debt/Expense and Income Consolidation

As part of the consolidation of liabilities, expenses and income, several accounting record numbers may be used within a consolidation voucher, each for each pair consisting of company/business unit and Counter-company/Counter-business unit. This also means that we do not have to account for a single difference per company language, but rather, several differences per combination of gender sell /business unit and counter-company/counter-business unit may be disclosed. It is imperative that the consolidation postings arise for each booking record number, i.e. for each pair combination from the company /business unit and the counter-company/counter business area.

This is also one of the main reasons why nothing is changed to the existing data stock simply by introducing release 22.3. The conversion program leaves the consolidation postings untouched because it could not do the necessary work.

The attributes Counter-company/Counter-business unit cannot be added or edited manually. The system fills them when a consolidation function starts.

If the customer wants to try out the new functionality for a completed period, or use a completed period as a comparison period, they would have to revise all consolidation postings and enrich them with the attributes Counter-company and Counter-business unit (see below).

2.2 Manual Postings

If manual postings are posted "on top", usually only one document company is entered in the consolidation voucher. As a result, the automatically determined gene company is also identical to the posting company. The same applies to business unit and counter-business unit.

Figure 4: Overview of consolidation postings

2.3 Aggregations in the Business Units

In the application BUDT, so-called schemas can be formed from business units and aggregates. For reporting in the sense of matrix consolidation, it is imperative to form at least one schema in the sense of an "uppermost common node".

Figure 5: In the BUDT application, a schema is formed from business units and aggregates

2.4 Group Reports

In the group report you can select a previously defined scheme. When selecting a schema, you must also specify the desired hierarchy level. The aggregation of the business units is then carried out according to the previously selected scheme. If the new attributes Counter-company and Counter-business unit are to be evaluated, this must be checked with the corresponding button on the far right.

Figure 6: Report header record parameter

Crossing the option with counter-business unit , the report uses the previous logic and only evaluates the attribute seg cross-ment located at the consolidation posting. As long as business units are not aggregated, this is sufficient.

It is possible to specify hierarchical level 0, but this is probably of limited value. Understandably, there are no cross-segment postings here, since we only consider one segment, which by definition is identical with the Group as a whole.

The report column option #KTKGB used here shows the individual consolidated segments in alphanumeric order in the columns, as well as the reconciliation (SegmÜbergr) to legal consolidation. The last column (total) always corresponds to legal consolidation. In the following screenshots we therefore see that - irrespective of the hierarchy level considered - the identical amounts are always displayed in the last report column.

Figure 7: Report result display, hierarchical level 0

Figure 8: Report result display, hierarchical level 1

Figure 9: Report result display, hierarchical level 2

2.5 Details Postings

As you know, we can branch out into the consolidation postings from the report results display. However, we must note that in the display of consolidation postings we do not have any selection on "cross segment" in terms of the previously viewed report and its BUDT aggregation scheme available, which is why we always see all consolidation postings, such as an account or a position here.

Therefore, if we want to understand the amount of the cross-segment consolidation postings of 3,489,600.00 under the other operating income, we do not see this at first glance:

Figure 10: Consolidation postings (from the report results display)

In the first step, you can filter the consolidation postings by the criterion "cross-segment", but you have to remember that depending on the reporting scheme previously selected in the report, which is due to the aggregation, intra-segment consolidation postings can still be marked as cross-segment.

In this case, it is only helpful to look at the business unit and offbusiness unit in the individual posting lines, and to mark the posting amounts individually:

Figure 11: Consolidation postings manually filtered

3 Change Strategy for Customers

There are currently no empirical values, as the topic of matrix consolidation is still too new. Initially, the recommendation by hotline was that customers should rebuild their system if they want to use matrix consolidation, since the new attributes Counter-company and Counter-business unit cannot be manually completed or edited in the consolidation postings. The fields in the consolidation postings presented are always completed. However, they may not have been filled correctly. On the other hand, the relaunch of the entire system represents a relatively high hurdle. Therefore, it is probably preferable to examine in individual cases whether, after the generation of the period carry-forwards, there may be carry-forward vouchers with more than two company/business area combinations and how these can be "cured".

For example, there is no problem with KK V vouchers. On the other hand, too -, CR - and AE - carries forward could be problematic, for example, since they no longer contain all postings from the previous period and therefore the counter -business area can no longer be correctly determined. This is generally the case for WX vouchers, as the carries forward no longer contain all the posting lines of the original document and therefore it may not be possible to correctly identify the company. However, these vouchers expire when a new financial year is implemented for the second time.

3.1 New Facts

Either the customer stays in the same database and only uses a new fact, then the vast majority of other master data (e.g. chart of accounts, mirror definitions, report definitions) can still be used.

3.2 New Database

The customer starts a completely new database. This approach offers the opportunity to also restate the master data in case there is also a need for revision.

If the client uses interfaces, it is important to check how the previous Konsis database is addressed in these interfaces.

Example: In interfaces for importing data from ERP systems, the database to which the data is written is set rule "under the hood". As a result, the customer cannot set in the program interface which database to write to.

For example, if data is transferred to downstream reporting systems via Datamart, it should be checked whether these systems are also able to tap into the "old" database as needed, for example, if comparative figures are to be reported.

The ongoing maintenance effort on the part of the customer IT is slightly greater, as it is necessary to bear in mind that the "new" and "old" database will be updated during future release changes so that the data in the "old" database can still be accessed.

4 Special Features of Changes in the Consolidation Scope

The internal sale (IC) is working correctly. With deconsolidation (XK and YK) and ver schmel zes (PS), there is always a problem if there are several vouchers to be eliminated (e.g. MB01 V and MB02 V), because there is only one voucher for these vouchers that eliminates the postings. As a result, more than two business areas may have to be processed in one voucher, and counter -company and counter-business may not be filled correctly. This issue is described in a separate JIRA task to be implemented at a later stage.

The current status is included in release 22.3. We decided to take this step by weighing up all pros and cons, as we assumed that a customer who would like to work with matrix consolidation does not have to carry out a deconsolidation or an upstream merger immediately in the first reporting year.

Otherwise, it would have meant postponing the matrix consolidation as a whole, which was implemented in a fully functional manner with regard to deconsolidation and upstream merger, until the previously mentioned situations, until a later publication date. We did not think that was appropriate.

The warning message that more than two business units are used per record number has been turned off for processing, so that it does not interfere with customers who work with business units but do not work with the new functionality.

5 Special Features of Development Repostings

Development repostings are carried out for KU, SU and FU processing. KU posts mirroring presentations as part of a first consolidation for the addition consolidation group. The SU corrects the mirror representation within the scope of the consolidation of debts. It should no longer be necessary to carry out the FU. However, this processing can still serve us well in practice when it comes to coordinating and correcting mirror lectures. There may be more than two counter-business units per entry record number, with the result that these cannot be determined correctly.

In practice, however, I wonder how relevant any reflections are in relation to (aggregated) business units.

6 Questions & Answers

1. Q: It may not exceed a maximum of 100 posting records. For two companies with 10 business units each, the maximum possible combination is already 100, meaning that 100 posting records would be required. What do we do as part of debt or expense and income consolidation when more combination opportunities become available?
   A: Starting with posting record 99, it is no longer possible to generate new transaction record numbers, since the field is only in two digits, therefore the "remainder" is then processed in transaction record number 99 . > sequence: In the last record number it can posting with more than two Business areas with the result that the counter-business unit cannot be correctly determined .
2. Q: How are the fields counter-company and counter-business unit for old completed periods?
   A: After inserting release 22.3, the columns for counter-company and counter- business unit are currently blank. If the customer has selected the Empty Columns view option from the same as the list, the columns are no longer displayed. This also applies, of course, to old, closed periods.
3. Q: How are the fields counter-company and counter-business unit dealt with if the customer does not work with business units at all?
   A: Even if we don't work with business units at all, the field counter-community of interests always filled in the future. This also makes it easier to understand and understand the postings that are generated in SU vouchers, for example.
4. Q: Can use attributes counter-company and counter-business unit with Xlslink who reads the?
   A: The consolidation postings reading function of IDL Xlslink cannot yet read the two new fields, the functionality should be moved with a fixed pack for completeness. In any case, the two fields are irrelevant for the consolidation postings export function, as Konsis does not have the option of manually filling the fields and therefore cannot import the field contents.
5. Q: What are the evaluation options in the designer or in other reporting tools that access Datamart?
   A: When creating the report result in Konsis, it is currently decided which consolidation postings must be classified as segment internal and which as cross-segment. The technical logic is therefore to generate the report result. Consequently, in external reporting tools, such as IDL Designer, this logic would have to be recreated in order to be able to run the same evaluations with the same results as directly in Konsis.
6. Q: When the fields counter-company and counter-business unit for evaluation via the MISPAR interface?
   A: MISPAR interface version 1 to 3 copies already existing data into further database tables K8xx. Version 4 of the MISPAR interface is a set of database views that allow direct access to the KONSIS data without having to start a copy process. This version is also known as Datamart. The new attributes Counter-company and Counter-business unit are not included in any version of MISPAR.

7 Literature

To open the relevant document, double-click on the document preview in the right-hand column.

German Accounting Standards Committee: DRS28 (Segment reporting), published by the Federal Ministry of Justice and for Consumer Protection in the Federal Gazette Banz AT 05.08.2020 B2

Wirth, Johannes; Alper, Rolf and Neis, Thomas: Software-side implementation of internally/externally harmonized consolidation - matrix consolidation, in: KoR 7-8/2013 Page 370-375.