IFS Group Consolidation

Introduction

IFS Group Consolidation has its main focus in operational consolidation of the Balance Sheet and Income Statement. With the flexibility that it offers, e.g. any number of operational and legal structures handled in parallel, IFS Group Consolidation is perfectly suited for corporations which need a tool to handle consolidation of complex and changing structures.

Some characteristics:

• An integrated part of IFS, providing a common interface, full validation of all basic data and drill-down analysis to source companies. Existing basic data from IFS Accounting Rules, e.g. code string definition and values for the code parts, periods and currency rates are also used in IFS Group Consolidation.
• Consolidation specific basic data and rules are defined in one or several Master Companies, each one representing a separate independent consolidation universe.
• Any number of consolidation structures within one master company and any number of balance versions can be consolidated using the same structure (e.g. Actuals and Budget/Forecast).
• Support for segment reporting, i.e. elimination based on an alternative dimension structure.
• Each reporting company can report to any master company and against different balance versions in the same master company.
• Each company can report balances individually (push) or balances can be fetched for one or more reporting companies from the master company (pull).
• Freedom to have individual Charts of Accounts in the reporting companies, as well as to report in any currency, still being able to consolidate reported balances into a common Chart of Accounts and structure node specific currency.
• Support for different ownership levels, including ultimate ownership, different consolidation methods and changes related to the consolidation structure over time.
• The level of traceability is very high, both for changes in the set-up and when analyzing reported and consolidated balances.

An overview of the consolidation process looks like this:
 

When basic data and rules for the consolidation have been defined, the consolidation process is quite simple. It only consists of two main steps:

• Reporting from each Reporting Entity (company) to a master company, individually or for several reporting entities at the same time. Any needed translation/mapping of the reporting company’s Chart of Accounts takes place in this process, so the reported balances that ends up in the master company will be according to the master company’s Chart of Accounts. Necessary adjustments can be added to the reported balances, either for specific reporting entities or for separate adjustment entities. These reported balances and adjustments can be analyzed both on screen and in reports, as well as with IFS Business Reporter.
• Consolidation of one or more consolidation structures in the master company, node by node or the full structure in one step. Any needed currency conversions of the reporting companies reported balances takes place in this process, so the consolidated balances can be compared in a common currency per structure node. Before ending up with the net consolidated balances several other steps might be processed, i.e. ownership elimination and its related profit/loss adjustment, as well as intercompany balance elimination and equity elimination. The consolidated balances can then be analyzed on any level in a consolidation structure, both on screen and in reports, as well as with IFS Business Reporter.

Further details are outlined below.

Terminology

Most of the terminology used is equal or similar to what is being used in the General Ledger. There are however a few frequently used new terms that might require a bit of explanation:

• A Master Company is a company in IFS which holds the specific basic data and rules for the consolidation process, as well as where the actual consolidation process takes place. Any number of master companies can be defined and any normal company can report to several master companies. A master company only exists for the purpose of handling consolidation for a group of companies. This is why business transactions should not be entered is such a company, as the resulting balances in a master company cannot be included in the consolidation process. All companies in a group, subsidiaries as well as the parent company, should be defined as normal companies and report to a master company. The consolidated group is represented by a node in a consolidation structure, typically the top node. A typical set-up would be to have only one master company for a group, but it is of course possible to have several for test or simulation purposes. It is recommended to use the group currency as the accounting currency for a master company.
• A Reporting Entity normally represents a company which should report balances to the master company, i.e. to the group. It can however also represent an adjustment entity, not connected to any company, with the purpose of holding adjustments for a specific node in a consolidation structure.
• The Reporting Transaction Type separates balances from different sources, the two most obvious being reported balances and adjustments. Any number of reporting transaction types can however be defined, depending on the required level of source separation.
• A Balance Version represents different sets of reported and consolidated balances. Reporting and consolidation is always done for a specific balance version, typically one balance version for actual balances and one or more for budget/forecast balances. Multiple balance version for actual balances can of course also be defined for different purposes, e.g. actuals according to budget rates.

The remaining terms are either familiar from IFS General Ledger or generic consolidation terms, used by most consolidation systems.

Set-up

The set-up of IFS Group Consolidation can be divided into two main areas, i.e. defining basic data needed for the reporting and adjustments, as well as defining one or more consolidation structures. How this is done is described in detail in the activity descriptions linked to each page in the system, but a few things might require special attention:

• When defining a Reporting Entity which should be used as an adjustment entity for a node in a consolidation structure, the system does not require that the reporting entity currency should be identical to the node currency, although that might still be the most common set-up.
• When defining a Reporting Entity which should represent a company, the system does not require that the identity of the reporting entity and the company should be identical, but having identical identities simplifies things for the users.
• The same can be said about the Counterpart 1 needed for internal trade elimination, i.e. the system does not require that the identity of the counterpart and the company it represents should be identical, but having identical identities simplifies things for the users. You will then have consistent identities for companies, reporting entities and counterparts.
• A Balance Version represents different sets of reported and consolidated balances, typically actuals and budget/forecasts:
  • Each Balance Version needs to be connected to two Currency Rate Types, one representing average rate to be used for Income Statement accounts and one representing closing rate to be used for Balance Sheet accounts. These rate types are used for the currency conversion that might happen during the consolidation process, as well as when entering adjustment journals in another currency than the reporting entity currency. All rates for these rate types will be entered against the master company’s accounting currency, i.e. the master company’s accounting currency is the reference currency for these rate types. This means that, e.g. if a company reports in GBP to an EUR node in a consolidation structure, and the top node represents the master company in USD, there will be no rate between GBP and EUR. Instead, the system will do a triangulation, i.e. first converting the GBP into USD and then converting the USD into EUR.
  • An Alternative Balance Version can be connected to a normal balance version. When used for consolidation, all reported balances and adjustment journals from the connected normal balance version will be included, while rates and additional adjustment journals will be fetched from the alternative balance version.
• Code Part Mapping gives total flexibility in defining which accounting dimensions (code parts) that should be included in the reporting from a reporting company to a master company, as well as against which master company dimension it should be mapped. All 9 analytical dimensions in a reporting company can be mapped against any of the 19 analytical dimensions available in a master company:
  • Note that the consolidation logic requires that the dimension representing counterpart for intercompany balances in the reporting company should be mapped against the fixed dimension Counterpart 1 in the master company.
  • Also note that the consolidation logic requires that the dimension representing the counterpart for alternative dimension elimination (segment reporting) in the reporting company should be mapped against the fixed dimension Counterpart 2 in the master company.
  • The same applies to the dimension representing currency (currency balance) in the reporting company, which should be mapped against the fixed dimension Currency in the master company.
• Code Part Value Mapping supports having identical or different charts of accounts per reporting company, as well as having identical or different values for the other accounting dimensions included in the reporting. Specific accounts can also be excluded from the balance transfer, e.g. statistical accounts only used locally. Mapping for one reporting company can be copied to the mapping for one or more other companies.
• Consolidation Security can be defined separately for the reporting and consolidation processes:
  • Reporting, i.e. transferring balances and entering adjustment journals, can be restricted to individual users, separately per reporting entity and reporting transaction type if needed. The same applies to approving reporting and adjustment journals, as well as viewing these journals and the resulting balances.
  • Execution of the consolidation can also be restricted to individual users, separately per consolidation structure, structure node and balance version if needed. The same applies to viewing the result of the consolidation. Note that access to a specific node also gives access to any node below it in the structure. These rules can be set for a specific period interval to accommodate organizational changes.
• Historical Consolidation Rates supports to translate certain balance sheet account balances which require special treatments in translating such as Retained Earnings, etc. That is, to translate at historical rates instead of closing rates and recognize the translation reserve portion in each recorded item.
• The Acquisition Register holds information about how the different subsidiaries were acquired. This information is used for equity elimination and amortization of overvalues during the consolidation process.
• A Consolidation Structure consists of nodes, either representing reporting entities or consolidation nodes (group or subgroups). The connection between two nodes defines how the underlying node should be consolidated into the node above. The most important information is the Ownership % (1-100) and the Consolidation Method (Equity Majority, Equity Minority and Proportional). There is however no relation between the two values, i.e. although you might only own 40% of a company, you could still be in full control, justifying the use of the Equity Majority method. The reporting entity representing the parent company in a group or subgroup should always be included in its consolidation node with 100% ownership and consolidation method Equity Majority. Each addition or change to a consolidation structure is valid from a specified period (which could deviate from the specified date for the event), and all additions or changes are logged for follow-up purposes. This means that a specific consolidation structure can be presented differently, depending on which period you select for the presentation.

Reporting and Adjustments

Reporting can also be divided into two different parts:

• Periodic balance reporting per reporting company connected to the master company.
• Adjustments of reported balances and/or adjustments only valid at node level (group or subgroup).

Regardless of which type of reporting you are doing, the combination of used reporting transaction type, balance version and period must be open for reporting for your reporting entity.

Reporting of accumulated period balances for a reporting entity (company) can be done any number of times, as long as the period is still open for reporting. If the profit or loss for the accumulated periods isn’t posted as part of the reported balances, the system will automatically create balancing transactions individually for the Income Statement and the Balance Sheet. Any errors from the balance transfer can be viewed in the Balance Transfer Log. Typical errors are missing code part value mapping and/or missing automatic posting instructions. Once corrected, it’s just a matter of report for the same period again.

Adjustment Journals might have to be created for a number of different reasons. Examples could be:

• Errors in reporting, etc.
• Adjustment for differences in local and corporate GAAP.
• Internal sales of fixed assets.
• Income Statement adjustments due to acquisitions and/or sales of companies, or part of companies, during the year.
• Any other adjustment needed.

A number of copying functions simplifies the creation of these adjustments:

• All journals from previous period, which are still valid for the current period, can be copied. The copied journals will have In Progress status, meaning that adjustments can still be made to them before they are approved for inclusion in the consolidation process.
• Individual journals can be copied and adjusted before they are approved for inclusion in the consolidation process.
• Selected rows from individual journals can be copied to a new journal. These rows can also be adjusted before the journal is approved for inclusion in the consolidation process.

When both the reporting and all necessary adjustments are done for all reporting entities, it is recommended to close the period for further reporting. The consolidation can then be executed without risking to consolidate a moving target. This is however not mandatory, so preliminary consolidations can be carried out any number of times based on preliminary balances, for the full consolidation structure or parts of it.

Consolidation

Once the set-up and reporting/adjustments have been done, the consolidation is almost just a push of a button. Consolidation is always done for the combination of a specific consolidation structure, balance version and period, and can be carried out for the whole structure at once or only for a selected node. Note that adjustments journals which are not yet approved can optionally be included in the consolidation.

During the consolidation process, the following steps can be executed, depending on the individual set-up and the balances to be consolidated:

The reported and adjusted balances are not modified by the consolidation process. Instead, the system creates new transactions from each step in the process. This gives two main benefits:

• As the net consolidated balances is just an addition of all transactions, it enables drill-down analysis of the transactions that generated the net consolidated balances.
• Reported balances and adjustments can still be analyzed after the consolidation.

If the result of the consolidation isn’t what was expected, it can be rolled-back. After necessary changes, e.g. new reporting from a reporting company or additional adjustment journals, the consolidation can be executed again. Errors that might occur during the consolidation are clearly stated, typically missing currency rates and/or missing automatic posting instructions. Once corrected, it’s just a matter of executing the consolidation again.

Once the consolidation has been initiated for a specific consolidation structure, balance version and period, changes made to the structure and/or the consolidation security rules will not affect the consolidation process. If such changes exist, and they affect the period for which the consolidation has been initiated, any executed consolidation should be rolled-back and the combination of consolidation structure, balance version and period should be re-initiated. Then the consolidation can be executed again, for the complete structure or for selected nodes.

Consolidation with Period Rates

The consolidation described in the previous section involves accumulated balances for both income statement and balance sheet. The translations are also performed on these accumulated balances and using single average rate such as Yearly Average Rate, etc. Alternatively, income statement balances could be translated at the rates (eg: period rates) in each period via the option 'Income Statement Period Rates' in the Balance Version definition. The main purpose of this option is to eliminate currency translation differences due to seasonal fluctuations in currency rates which arises when a single average is used.

Alternative Dimension Elimination for Segment Reporting

It is sometimes necessary to be able to split the reporting from a group of companies into different segments, e.g. divisions. IFS Group Consolidation supports this through the ability to define a structure based on another dimension than Reporting Entity (company). Once the normal consolidation has been executed, the structure which is based on the selected alternative dimension is applied. The result will be a reversal of any intercompany elimination and instead it is replaced by an elimination based on the dimension selected for the structure, e.g. division.

Analysis and Reports

The analysis and reports can also be divided into three different parts:

• Reported balances and adjustment journals
• Consolidated balances and their details
• Consolidated Period balances

Reported Balances can be analyzed with the required level of detail in the presentation (Zoom-in). Drill-down capabilities to the journals and their rows which build up the balances, regardless of if it is reporting or adjustment journals. Reporting journals can be further drilled-down to the GL/IL Analysis of the company which the reporting journal originates from. All or selected journals can also be printed in a report. Finally, an Information Source enables total freedom in analyzing or printing reported balances from IFS Business Reporter or another BI tool.

Consolidated Balances can be analyzed for individual nodes in a consolidation structure, with the required level of detail in the presentation (Zoom-in). Optionally, user defined accounting structures can be applied to the presentation for further grouping of a selected code part. Drill-down capabilities to the consolidation details which build up the net consolidated balances, also with the required level of detail in the presentation (Zoom-in). Intercompany balances and the effect on them from the consolidation process can be analyzed separately. A report simplifies reconciliation of any remaining differences from the intercompany balance elimination. Finally, an Information Source enables total freedom in analyzing or printing consolidated balances and their details from IFS Business Reporter or another BI tool.

Consolidated Period Balances can be generated in two ways. Firstly, accumulated consolidated balances on a given node could be broken down to period consolidated balances as an option in the consolidation process. Secondly, Consolidated Income Statement Period balances and the details could be generated by using an option in the Balance Version definition. These period balances and details can be analyzed for individual nodes in a consolidation structure. Also an Information Source enables total freedom in analyzing or printing consolidated balances and their details from IFS Business Reporter or another BI tool.

Comparison with IFS Consolidated Accounts

For the time being, IFS offers two different solutions for consolidation:

• IFS Group Consolidation (the topic of this document)
• IFS Consolidated Accounts (old solution, not compatible with Group Consolidation)

IFS Consolidated Accounts might be discontinued sometime in the future, but until then it will be available in parallel with IFS Group Consolidation. The two solutions and their level of flexibility are quite different, but both have their pros and cons. Below is a high-level comparison between the two solutions:

Basically, you could say that IFS Consolidated Accounts fits the smaller corporation with fully own subsidiaries, where changes to the corporate structure are not common and internal trade between the companies is limited. It can also be used to consolidate branch offices into one legal entity before that legal entity reports to IFS Group Consolidation.

In all other cases, IFS Group Consolidation should be the preferred consolidation solution.