Intercompany matching and elimination logics: advanced settings
Data Processing tile > Basic Consolidation > IC matching and elimination logics > List > IC Matching and IC Elimination Logics tab
Data Processing > Basic Consolidation > IC matching and elimination logics > List > IC Matching and IC Elimination Logics tab
Introduction¶
Details and examples of more complex attributes for defining intercompany matching and elimination logics are provided below.
Attribute: Move Reconciliation accounts to the elimination logic
Intercompany Matching tab > Advanced section
Allows you to cover specific cases. For example, there may be several matching logics that operate on several details of a single main item of information. In this case, an elimination-only logic must be defined containing the main information and all the details into which any amounts loaded onto the reconciliation accounts of the various detail logics must also flow.
Example
The model contains two revenue accounts with relative geographical details:
- 50010: Revenues from sales of products
- 50010_500: Revenues from sales of products Italy Area
- 50010_510: Revenues from sales of products Europe Area
- 50010_520: Revenues from sales of products America Area
- 50020: Other revenues
- 50020_500: Other revenues Italy Area
- 50020_510: Other revenues Europe Area
- 50020_520: Other revenues America Area
Two cost accounts are also present, with the same details as the revenue accounts:
- 50110: Cost of sales
- 50110_500: Cost of sales Italy Area
- 50110_510: Cost of sales Europe Area
- 50110_520: Cost of sales America Area
- 50220: Advertising/publicity costs
- 50220_500: Advertising/publicity costs Italy Area
- 50220_510: Advertising/publicity costs Europe Area
- 50220_520: Advertising/publicity costs America Area
The matching strategy requires that three matching-only logics be defined to match Revenues and Costs for every individual geographical area. The consolidation must therefore obtain these outcomes:
- Eliminate the total of the amounts on the revenue and cost accounts.
- Eliminate the individual details.
To do this, it is necessary to define the following logics:
- An initial logic that manages the elimination only on all the accounts, normal and detail.
- Three matching-only logics that compare the details of the various geographical areas. These logics must have the Move Reconciliation accounts to the elimination logic option activated. Moreover, the move must take place on the elimination logic created in the previous point. This creates a link between the three matching logics and the elimination logic that logically includes them.
This makes it possible to move any data loaded onto reconciliation accounts in the three logics of the details to the elimination logic. Thus, the generated journal takes account of the matched values, even if they are inserted on different logics.
Attribute: Invoice matching
In the matching process, you may need to not be restricted to the relationship between entities but also go down to a more analytical level of detail, introducing information on the invoice number, the date sent/received, the date booked, etc. into the declaration.
This attribute is useful for this purpose.
IMPORTANT: to manage these additional fields in the intercompany entry declaration step, you must activate their management in the advanced Data Entry rules Setup & Admin > Data Entry & Submission rules tile > Amount & Intercompany rules) with the Enable additional fields on IC option.
On the pages dedicated to intercompany entries, in both the web interface and Excel, the fields related to invoicing appear, such as:
- invoice number
- date received
- invoice type
The IC matching cockpit and the elimination journals remain unchanged. The validation of the relationship between entities is effective for both of them. Since CCH Tagetik has saved the additional information, it can be used. This is possible through dedicated data processing (see Invoice IC matching).
Attribute: Bundle on Elimination Rule
Eliminations tab > Rows advanced configuration section
This attribute allows you to generate a single journal containing the impacts of two or more logics. In fact, two elimination logics can concern accounts that are similar at the conceptual level, but which you want to keep separate because they have different settings.
Example
You want to keep trade payables/receivables separate from financial considerations, while generating a single Receivables/Payables elimination journal.
To obtain this outcome, you must:
- Define 2 “standard” elimination logics, one for Trade Receivables/Payables and one for Financial Receivables/Payables.
- Select the Bundle on elimination rule attribute.
This brings the impacts of the two eliminations into a single Receivables/Payables elimination journal.
Attribute: Enumerate on elimination rule
Eliminations tab > Rows advanced configuration section
In some cases, it may be useful to create a new matching/elimination logic (e.g. for trade payables/receivables) to include the new accounts. To prevent spurious situations from being generated when past scenarios are re-processed, it is necessary to define a new logic in which the additional accounts will be included.
The automatic journals created on the basis of elimination logics contain the following information in the journal number:
- the code of the entities involved in the journal
- the category code
- the currency code
- the code of the logic that generated the journal.
Consequently, when a new logic is defined, CCH Tagetik generates a new journal, with a code linked to this new logic. The new IC declarations on trade payables/receivables would not therefore be eliminated on the journal carried forward from the previous years.
This attribute allows you to avoid doubling journals between the old and new model (existing logic vs. new logic) by imposing a sort of automatic “recoding” on the new logic. The new elimination rows generated by the new logic are therefore inserted into the journal carried forward from the journal generated by the pre-existing logic.
The new eliminations are inserted into the carry forward and reversal entries provided for by the set restoration.
Attribute: Change sign on Dependent accounts
Intercompany Matching tab > Advanced section
If the declarations on the accounts involved in the logic are all inserted with positive signs instead of applying standard “accounting signs”, the balancing checks on the generated journals are all incorrect, because CCH Tagetik expects a “opposite signs” approach by default. This attribute allows you to prevent this, but ensuring that the system correctly calculates the journal balancing.
Example
The IC declarations both have positive values, as in the table, and the Change sign on Dependent accounts attribute is selected.
| Entity | Account | CTP entity | Value |
|---|---|---|---|
| Entity 1 | Quantity sold | A04 | 340 |
| Entity 2 | Quantity purchased | A00 | 330 |
The matching cockpit shows an unbalanced amount of 10 (340 - 330) = 10.
Attribute: Plug Account
Eliminations tab > Rows advanced configuration section
In some cases, one of the project’s requirements is for the Consolidated Financial Statements to contain Profit and Loss and Balance Sheet statements that are balanced in contribution. The Plug account enables precisely this: all the elimination entries generated by the counterparty elimination data processing are balanced on it by entity. CCH Tagetik therefore automatically creates, by deploying the relative calculation logics, one or several calculated system accounts (one for the normal account and one for each of its variations, where applicable) that the calculation data processing uses exclusively in the journals generated by the same logic.
To satisfy this requirement, it is necessary to set the account on which the system creates a balancing contra-entry as the Plug account.
This account is set by the Plug Account field. The financial investment elimination logics from the ownership structure register contain two plug accounts: one to be used for the part pertaining to the owner entity and the other to be used for the part pertaining to the owned entity. The two accounts can also be the same.
Every Entity will therefore have a balanced contribution on every journal.
Example
This journal shows elimination between Revenues and Costs, with the contra-entries generated on the plug account (equal and opposite amount):
The presence of the plug account does not invalidate the coherence of any consolidation impacts.
IMPORTANT: in processes whose relationship type is “by entity/custom dimension 2”, for the journals with the same entity as both the owner and owned entity in their header, the system always uses the owner entity’s plug account.