IC Matching and Elimination Logics tab
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
Purpose of the tab¶
This tab allows you to set the characteristics of intercompany matching and elimination logics.
Attributes tab
| Field | Description |
|---|---|
| Code | Unique code of the logic |
| Description | Description of the logic in all languages enabled on the system |
| type | |
| IC matching logic | Indicates that it is an intercompany matching logic. Available to contribute to setting up an IC matching cockpit (see IC matching cockpit). If selected, the Matching tab appears. |
| Ctp elimination logic | Indicates that it is a counterparty elimination logic and that it can be used to generate an elimination entry with a consolidation journal among the accounts defined in the logic. The journals are generated by the “Counterparty Eliminations” data processing. If selected, the Eliminations tab appears. |
| Generate counterparty | Only for counterparty elimination logics. Generates an automatic contra-entry to balance the elimination journals. This is used when the IC declaration was made by one entity only, and it is necessary to generate the contra-entry on the second entity in the relationship, according to the attributes set in the Contra-entry tab. For example, it is used for the Dividends elimination logic in which Primary accounts only is also selected. If selected, the Contra-entry tab appears. |
| Generate balancing | Only for counterparty elimination logics. Allows you to set a tolerance threshold below which any difference within the journal will be automatically balanced. If selected, the Balancing tab appears. |
| Accounts filter | |
| Account nature | Nature of the account involved in the logic (Balance Sheet, Profit & Loss, Order, Other Variation, Other Stocks) |
| Account type | Type of accounts subject to the logic. It cannot be Variation if the nature of the account is Profit & Loss or Other Variation. |
| All accounts that aren't present in other logics | Inserts in the logic all the accounts not present in other logics with the same nature and type selected in the previous two items. Useful when it is not necessary to define all the accounts of the logic in detail. If accounts from the specific definition window (Account definition page) have already been inserted, they will be removed in order to be able to select this option. |
| Advanced configuration | |
| Primary accounts only | Indicates that only the accounts subject to the logic which belong to the Primary accounts section must be specified. If selected, the logic only shows the section related to the primary accounts. |
| Single adjustment relationship | Allows you to unite, into a single “element”, the IC impacts of entity A towards B and B towards A. A single journal, not a double journal, is therefore generated for every relationship. A single row is shown in the IC matching cockpit. - The elimination generates a single journal which includes all declarations of A and B for a given set of accounts. This is also the case if both involved entities have both primary accounts. Do not select if Primary accounts only and Generate contra-entry are selected for the logic. |
| Eliminate/match for single currency | If selected, the matching/elimination journal will be generated in the document currency. Otherwise, it will be generated in the currency of the entity that has the primary accounts. |
| IC spreading logic | Only for processes whose relationship type includes Custom dimension 2 and if you do not want to manually insert the information on Counterparty custom dimension 2 in the intercompany declarations. Enables the writing off of all intercompany declarations whose Counterparty custom dimension 2 is not significant, by reallocating the relative amounts on Counterparty custom dimension 2 obtained from the other entity’s declarations. |
Matching tab
Tab only visible if the IC matching logic option is selected. In this tab, it is possible to set thresholds, or values below which CCH Tagetik allows you to submit an IC relationship even if they are not matched, in the presence of automatic balancing. Also allows you to specify the entities that can or must match IC declarations.
| Field | Description |
|---|---|
| Threshold | |
| Absolute value | Absolute amount of the threshold below which it is possible to submit an IC relationship even if it is not matched. This usually assumes that there is automatic balancing. |
| Unit | Currency of the threshold value. Note: to run the balancing check, the threshold value is converted into the IC cockpit currency at the final FX rate. If a preferred currency is configured, this is assigned as the default currency for the threshold. The field is mandatory in the following cases: - Matching threshold, Balancing threshold or Variation/Detail types threshold is defined. - The rule is an IC matching rule and Matching threshold = 0. |
| % | Percentage for calculating the threshold dynamically |
| Maximum difference allowed | Value that the dynamic threshold percentage must not exceed |
| Reconciliation account | |
| Inserted by | Entity that can insert reconciliation accounts: - the entity with the primary accounts - the entity with the dependent accounts - both |
| Threshold | Amount of the reconciliation accounts below which an IC relationship can be submitted. The comparison is performed on the total number of the reconciliation accounts associated with the reconciliation logic. Note: If the value of the reconciliation accounts exceeds the threshold, only the consolidator of the relationship can perform the reconciliation. |
| Unit | Currency of the reconciliation accounts threshold value |
| Advanced | |
| Change sign on Dependent accounts | Allows you to invert the sign for the dependent accounts on the IC matching cockpit. Select to run matching between accounts whose amounts have been inserted with the same sign. |
| Invoice matching | Allows you to run the matching of intercompany entries for a single document/invoice. See Advanced matching logics. |
| Move Reconciliation accounts to the elimination logic | (Only for IC matching logics) Indicates the elimination logic on which to move the values loaded onto the accounts present in the logic in which it is activated. See Advanced elimination logics. |
| FX rate used for Conversion | FX rate used for conversion. Defined with the conversion type of the first of the primary accounts deployed for the elimination logic. If historical, the final FX rate is used. If at initial balance or period average FX rate, the previous final FX rate is used. In all other cases, the same conversion rate as the account is used. |
Eliminations tab
Tab only visible if the Ctp elimination logic option is selected. Allow you to manage the information needed to create an elimination entry through a consolidation journal among the accounts defined in the logic. The journals are generated by the “Counterparty eliminations” data processing.
| Field | Description |
|---|---|
| Journal attributes | |
| Proportional calculation method | Method for calculating the proportional percentage calculation to be applied to the generated elimination journal. To be set if there are entities consolidated according to the proportional or equity method in the consolidation perimeter. None: ignores the amounts due to the presence of an entity valued according to the proportional method. Lower %: the journal amounts are weighted in respect of the lowest % out of the two entities involved in the journal. If one of the entities is proportional, its proportional percentage will be used; however, if both entities are proportional then the system will apply the lower %. Typically used for IC reconciliation logics. Greater %: as for Lower %, applying the greater %. Entity 1: the amounts will be weighted based on the % of the entity that has values on the Primary accounts. Typically used for financial investment elimination logics and the related impacts (investment revaluations, devaluations, dividends, etc.). Entity 1 * Entity 2: - If the consolidation method both entities in the header is Proportional, the lesser proportional percentage of the two entities in the header will be applied. - If the consolidation method entity 1 in the header is Equity, of Non-consolidated controlled entity type, and the consolidation method of entity 2 in the header is Line-by-line, then the proportional percentage of entity 2 in the header will be applied. - In all other cases, the proportional percentage of entity 1 is multiplied by the proportionality percentage of entity 2 in the journal header. IMPORTANT: this option cannot be used in processes which use the “Database” consolidation engine. |
| Minorities calculation method | Specifies how the system will behave if the generated journal is included in the minorities calculation. See Minorities calculation. A minorities calculation is normally necessary if net equity accounts are involved. Note: the net equity accounts also include the net result, so, normally, if the journal impacts the net result, the minorities calculation is always necessary. - None: minorities are not calculated. It is not normally necessary in IC matching logics; in fact, there should be no impact on net equity and, in particular, on the net result. - Based on Entity 1 %: sets the entity’s minorities calculation with entries on the “Primary accounts”. E.g for the financial investment elimination journals and the associated impacts (investment revaluations, devaluations, dividends, etc.), where the primary entity holds the financial investment. - Advanced: allows you to customise the calculation separately for each of the two entities, considering the minorities percentages of Entities 1 or 2. - Normal: automatically applies each entity’s specific equity ratio percentage and consolidation percentage to Entity 1 and 2. |
| Minorities calculation on Entity ½ | Fields can only be customised if Advanced is selected in Minorities calculation method. Sets the minorities percentage of Entities 1 and 2. |
| Equity evaluation method | This attribute is considered when one of the entities involved in the generated journal is defined with the net equity method. If a journal has an impact on the net equity of an entity valued at equity, it must be considered in the valuation using the net equity method. The amounts must be duly “weighted” according to the consolidation %. Consequently, there is a calculation that increases or decreases the financial investment value for the entity that holds the investment. - None: does not apply the equity evaluation, even if the journal entities include entities consolidated at equity. - Delete: ignores the journal. Useful if one of the two entities is valued according to the net equity method and the journal does not impact net equity. (e.g. IC costs/revenues matching). The consolidable amount type is not generated. - Evaluate with equity method: single Entity journals: this is used for consolidation journals which arise from an entity relationship, but in which the rows are only attributed to entity 1 of the relationship; for example, for the elimination of a dividend or the elimination of the write-off of a financial investment. Only the rows which contribute to the entity with amounts on the “Primary accounts” will be considered. Any rows on the other entity (including manual rows) will be ignored. See Single entity journals. - Evaluate with equity method: if entity 2 is at equity:: only used for financial investment/net equity eliminations. In this type of journal, net equity should impact entity 2, but the NE could also be adjusted for entity 1 (e.g. FX rate differences on the financial investment account at the historical FX rate). In this case, the system also subjects entity 1’s rows to equity evaluation. |
| Tax calculation method | This field must be configured if you intend to calculate the taxes on the generated journal. None: the taxes calculation is not performed for that journal. Entity 1: Taxes are calculated according to the fiscal policy associated with the entity with amounts on the “Primary accounts”. Entity 2: Taxes are calculated according to the fiscal policy associated with the entity with amounts on the “Dependent accounts”. Entity 1 invert credits/debits: Taxes are calculated in the same way as the “Entity 1” and “Entity 2” methods, but the choice between the “Deferred taxes fund” and “Credits for prepaid taxes” accounts must be inverted. In other words: if the amount has the debit sign, the Deferred taxes fund is chosen; otherwise, the Credits for prepaid taxes account is chosen. Entity 2 invert credits/debits: As above but only for consolidation journals. None - Permanent OCI: Value for information purposes only. The tax calculation is not performed. None - Permanent P&L: Value for information purposes only. The tax calculation is not performed. |
| Reverse journal type | If you want to consider the new amounts of the current year only, ignoring the impacts of previous years, it is necessary to “reverse” the value carried forward by CCH Tagetik. Indicates how the reversals are performed for the carry forward on the subsequent year. See Journal reversal data processing. - None: no reversal. - Set BS accounts to 0 (cut off) - Set BS accounts to 0 and Write off P&L impact (IC) - Set BS accounts to 0, write off P&L impact and variations |
| Enable carry forward | Indicates whether or not the generated elimination journal must be carried forward into the subsequent scenario. Normally, every journal that involves balance sheet accounts open on variations must be carried forward. This is particularly the case if a journal has an impact on the net result account, since the net result account is always open on variations. Select for all logics regarding financial investments (eliminations with net amounts, revaluations, devaluations, dividends) or assets in general (elimination of profit from the intercompany sale of assets, for example). Do not select for profit and loss matching logics. |
| Periodic journal | Makes the automatic elimination journal periodic, not cumulated. |
| Exclude Reclassifications and NER | Excludes accounts and entries of the generated journal from any accounts or NER (Net Equity Reclassification) that may take place in the original or consolidated scenario. |
| Rows advanced configuration | |
| Keep Ctp on Reconciliation accounts | Allows you to keep the counterparty entity and the counterparty custom dimension 2 on the elimination rows related to reconciliation accounts. By default, the elimination rows related to reconciliation accounts are generated without defining the counterparty entity. This is because the reconciliation account represents a balancing of the IC relationship more than a declaration. However, it may be useful to use reconciliation accounts instead of IC declarations. In these cases, the counterparty must be defined. |
| Sum up generated journal | Indicates whether the amounts of the journal generated on the basis of the logic must be summed up with the same dimensions. If not selected, the generated rows have the same detail as the generating intercompany entries. |
| Plug Account | Account on which all the elimination entries generated by the counterparty elimination data processing are balanced, by entity. The plug account is used to balance contributing financial statements. See Plug Account. |
| Generate P&L result ctp | If the result calculation method is P&L: Calculated - BS: Copied from P&L result, CCH Tagetik separately calculates the net result on the Entities involved in the elimination journal on which the rows were generated: the rows that involve accounts of P&L nature. In the presence of intercompany (profit and loss) eliminations in currencies other than the consolidation currency, this behaviour feeds the FX rate differences on the net result in the balance sheet. Select this option only makes sense on rows that eliminate profit and loss intercompany entries. Allows you to generate, on every entity, a counterparty on the indicated “Ctp P&L result debit account” and “Ctp P&L result credit account” accounts in order to reverse the impact of the net result on the individual entity. The possible values are: - Yes - No (default value) Only for CTP elimination rules of a P&L nature. If selected, the Counterparty tab will be displayed. |
| Ctp P&L result debit account | Only defined if Generate P&L result ctp is selected. Account to be used to generate the contra-entry that reverses the impact on the debit net result. |
| Ctp P&L result credit account | Only defined if Generate P&L result ctp is selected. Account to be used to generate the contra-entry that reverses the impact on the credit net result. |
| Bundle on elimination rule | Allows you to generate a single journal containing the impacts of two or more logics. See Bundle on elimination rule. |
| Enumerate on elimination rule | Following the definition of a new logic, to include new accounts, the system generates a new journal, with a code linked to the new logic. Allows you to avoid the duplication of journals between the existing logic and the new logic. See Enumerate on elimination rule. |
Contra-entry tab
| Field | Description |
|---|---|
| Generate Counterparty in journal currency | Indicates the currency with which the automatic contra-entry for balancing elimination journals must be generated. If selected, the Entity currency amount journal field of the contra-entry is populated in the journal currency, otherwise it is populated in the currency of the entity involved. |
| Generate Counterparty figure with Counterparty | Indicates whether counterparty’s data must be defined in generating the automatic contra-entry for balancing the elimination journals. This only has an impact if the management of intercompany entries is enabled on the account. |
| Debit Account / Credit Account | Indicates the account on which to load the contra-entry. There may be two different accounts for debit and credit. |
| Entity for contra-entry | Declaring Entity: with the Primary Accounts Counterparty: with Dependent Accounts. |
| Contra-entry |
Allows you to set, for every custom dimension, whether to use, in generating the contra-entry, the same custom dimension as the value loaded by the Declaring Entity (custom dimension X of the source row), or the Entity Default defined for the entity in the list (default custom dimension X of the entity on which the contra-entry is generated). For custom dimension 2 only, the Counterparty (counterparty custom dimension 2 of the source row) is also available. |
Balancing tab
| Field | Description |
|---|---|
| Threshold | |
| Absolute value | Absolute amount of the threshold below which it is possible to submit an IC relationship even if it is not matched. This usually assumes that there is automatic balancing. |
| Currency | Currency of the threshold value. Note: to run the balancing check, the threshold value is converted into the IC cockpit currency at the final FX rate. |
| Account | |
| Debit Account/Credit Account | Indicates the account on which to load the balancing. There may be two different accounts for debit and credit. |
| Generate Balancing in journal currency | Indicates the currency with which the automatic balancing of elimination journals must be generated. If selected, the contra-entry’s Entity currency amount field is populated in the journal currency, otherwise it is populated in the currency of the entity involved. |
| Generate Balancing with Counterparty | Indicates whether the counterparty data must be defined in the automatic elimination journal balancing step. This only has an impact if the management of intercompany entries is enabled on the account. |
| Entity | |
| Debit Entity / Credit Entity | This can be the Entity with the primary accounts or the Entity with the dependent accounts. The comparison of the unbalanced amount with the balancing threshold and the choice of entity for debit/credit balancing is carried out on the basis of the total value of the unbalanced amount, without considering the split between custom dimensions. IMPORTANT: If the Single adjustment relationship attribute is selected in the logic, there is not enough information to choose the entity on which to write the balancing account. Therefore, Entity 2 from the journal header is selected automatically. |
| Allows you to set, for every custom dimension, whether to use, when generating the balancing, the same element as the custom dimension of the value indicated on the Entity maximum amount row of the entity to be adjusted, or the Default defined for the entity in the list. Or, with the Of the row option, it is possible to balance while maintaining the custom dimensions of the journal rows subject to balancing. If the latter option is chosen for at least one custom dimension, the same choice must be made for all managed custom dimensions. With this setup, the balancing is calculated separately for each combination of custom dimension fields present on the journal rows. The balancing will be performed on the custom dimensions of the row even if they are not included in the restrictions of the entity selected for the balancing. The custom dimension restrictions of the account used for the balancing, and the specific relationship type restrictions, will be applied. |
Relationships tab
| Field | Description |
|---|---|
| Nodes | Node of matching and elimination logics to which to relate the logic |