1. Administering Financial Consolidation and Close
  2. Consolidating Data
  3. Intercompany Eliminations

Intercompany Eliminations

Standard Eliminations Overview

Companies record the results of transactions with other companies. Those other companies might be related companies or unrelated (that is, third party) companies. When reporting consolidated financial results, the impact of any transactions for which the legal companies within the scope of the consolidation have common control must be removed /eliminated from the consolidated results. The net results must be presented as if the group of legal entities were a single economic unit.

Transactions with unrelated companies do not require elimination. Transactions with related companies might need to be eliminated or partially eliminated depending on whether the related company is in the scope of the consolidated results and the accounting requirements applied to the consolidation arithmetic.

The nature of the relationship between the related parties will determine the manner in which information from the in-scope companies is aggregated and eliminated to produce the consolidated results. Different accounting standards will require some different aggregation methods, but most standards follow similar general principles.

When an application is enabled for Intercompany accounts and contains Intercompany account data, eliminations take place as part of the consolidation process.

Processing of Intercompany Eliminations

Data that are a result of transactions between two entities (that is, Intercompany transactions), both being consolidated into a common parent entity, must be eliminated in order to present the parent entity consolidated results as a single economic unit.

The intercompany transaction amounts are initially recorded twice. Each of the two parties (companies) involved in the transaction records their view of the transaction. The transaction is recorded separately by each entity, with the other entity as the "Intercompany partner". Note that the entries recorded by both entities represent the same transaction, but are entered separately by the two entities involved in that transaction.

The amounts to be eliminated are the amounts controlled "in common" by the parent entity at which common ownership is represented in the organization hierarchy. The net effect of the eliminations must be zero (that is, debits must equal credits), but the data is reclassified in order to net out at the parent entity. If the source data from both entities involved in the transaction is proportionalized at 100%, then the full proportionalized amount must be eliminated. If the amount proportionalized by either entity is less than 100%, then only the lowest proportional amount is eliminated because only the lowest proportionalized amount is controlled in common. Therefore an eliminated amount cannot exceed the proportionalized amount under any circumstances. If the Consolidation % for either of the companies involved is 0% then no elimination is processed.

Each elimination entry consists of two entries in the "FCCS_Intercompany Eliminations" Data Source dimension member in the Elimination Consolidation dimension member. The first entry reverses (or partially reverses) the original intercompany amount. All dimension members to which the reversal is applied are taken from the source POV with the exception of the Consolidation and Data source dimensions. An offsetting second entry is posted to the "Plug" account, as defined in the metadata for the source intercompany account. As with the reversal entry, the Plug entry is posted to the "FCCS_Intercompany Eliminations" Data Source dimension member in the Elimination Consolidation dimension member. All dimension members to which the Plug entry is applied are taken from the source POV with the exception of the Consolidation and Data source dimensions. If the Plug account is not set as an Intercompany account, then the Plug entry is posted to "FCCS_No Intercompany" in the Intercompany dimension.

Conditions for Intercompany Eliminations

The Entity structure(s) for an application can be created as a "Flat" structure (one parent entity with all directly owned and indirectly owned entities as immediate children). The parent entity represents the consolidated results of the ultimate Holding company. Alternatively, one or more multi-level (or "staged") structures can be created. In a multi-level structure, the sibling entities of each Holding company are those companies directly owned by the Holding company. If those directly owned companies themselves own other companies, then the sibling of the owning Holding company is the consolidated parent of the owned Holding company.

In a Flat structure, the logic for determining whether an elimination is to be processed is simple. The following logic is applied:

Data is a candidate for elimination if:

  1. The account is an intercompany account and has a valid Plug (clearing) account assigned

  2. The data has an Intercompany dimension entry of other than "FCCS_No Intercompany" (that is, contains a valid partner)

  3. The entity to which the intercompany transaction has been posted, and the partner referenced in the data definition (POV) both consolidate to the parent at greater than 0%

If these conditions are met, then the data is re-classified to the Plug account in the Elimination dimension member at the lower of the entity Consolidation % and the partner Consolidation %.

In a multi-level structure, the logic for determining whether an elimination is to be processed is in principle the same as in a Flat structure. However, the nature of a multi-level structure introduces additional potential complications. The following logic is applied:

Data is a candidate for elimination if:

  1. The account is an intercompany account and has a valid Plug (clearing) account assigned

  2. The data has an Intercompany dimension entry of other than "FCCS_No Intercompany" (that is, contains a valid partner)

  3. The entity to which the intercompany transaction has been posted, and the partner referenced in the data definition (POV) both consolidate to a common parent or ancestor at greater than 0%

  4. The Intercompany partner is a sibling of the current entity, or a descendant of a sibling

  • a. The entity and partner might not both consolidate to an immediate common parent either or both the entity and partner might consolidate to a common ancestor via one or more intermediate parents.

  • b. The relevant consolidation % used in the evaluation and posting of the elimination is the cumulative consolidation % derived by multiplying the level-by-level % from the entity or partner to the contribution to the common ancestor (that is, the cumulative factor specific to a branch of the hierarchy culminating at the common ancestor). The cumulative Consolidation % represents the contribution from the source entity / partner to the common ancestor for each contributor.

  • c. The "lower of entity or partner consolidation %" is applied to the sum of the entity cumulative %, aggregated across all siblings of the entity and the sum of the partner cumulative %, aggregated across all siblings of the entity. In a multi-level hierarchy, both the entity and the partner could exist in more than one branch of the hierarchy and could therefore aggregate to the common ancestor through multiple children of the common ancestor.

  • d. The data point could be a candidate for elimination at more than one level of the hierarchy, immediately below more than one common ancestor. If the partner exists in more than one branch of the hierarchy, then the entity’s consolidation path up through the structure could encounter more than one common ancestor. If immediately below the first (or a subsequent) common ancestor, the full entity amount is eliminated, then further elimination will not occur because the elimination amount cannot exceed the proportionalized amount. If no elimination (or only a partial elimination) occurred at previous levels of the hierarchy, then a further elimination could be required immediately below the current common ancestor.

  • The recognition of "immediately below a common ancestor" can be defined as the partner being a sibling or descendant of a sibling of the entity in which the data resides. The data is not a candidate for an elimination if the partner is a descendant of the parent and a descendant of the current entity unless it is also a sibling or descendant of a sibling of the current entity.

The system applies validations for Intercompany eliminations to be processed only when the correct conditions are met for a partner that is a sibling or a descendant of a sibling of the current entity. If you want to disable this functionality, you can create a Substitution Variable named StrictElimCondition and set its value to False. This will allow Intercompany data where the entity and partner are the same to continue to eliminate.

If these conditions are met, then the data is re-classified to the Plug account in the Elimination dimension member at the lower of the sum (across sibling entities / branches) of the cumulative entity Consolidation % and the sum (across sibling entities / branches) of the cumulative partner Consolidation %. If the aggregated partner Consolidation % is lower than the aggregated entity Consolidation %, then the partner % is applied.

Ensuring that Eliminations do not exceed Proportionalization

As previously noted, based on the concept of eliminating commonly controlled transactions, the cumulative elimination amount of an intercompany transaction cannot exceed the proportionalized amount. The system must therefore ensure that if the net contribution amount of an intercompany account has been reduced to zero, no further eliminations can occur.

It is possible that a computerized system cannot and does not record an accumulation to zero accurately*. This is due to a "decimal precision" issue common to all computer systems. As a result, a situation might arise such that the net contribution of a source intercompany amount is not reduced to exactly zero when it does logically equal zero. The test as to whether further intercompany eliminations should be processed can therefore not depend on the net contribution being equal to zero, but must instead be based on the net contribution being approximately equal to zero.

The test for whether a net contribution amount is approximately equal to zero can depend on the magnitude of the data in the system. By default, FCCS applies decimal precision of four decimals when applying the test. In this case, any net contribution of less than 0.0001 will be considered as zero and further eliminations will not be applied to the data. In most cases and for most currencies this level of precision should provide sufficient accuracy. However, if unexpected eliminations still occur, a Substitution Variable can be added to the application to modify the decimal precision applied to the test.

To add a substitution variable, navigate to the Variables card and select the Substitution Variables tab. Click on the plus symbol to add a new substitution variable. For "All Cubes", enter DecimalPrecision as the Name (no space between Decimal and Precision). Enter the required number of decimals to consider when applying the approximately equal test. The greater the magnitude of data values entered (that is, the number of significant digits to the left of the decimal point), the lower the decimal precision entry might need to be.

Note that the decimal precision variable entry must be an integer (zero or a positive or negative whole number) or subsequent consolidations might fail. A positive entry will round the net contribution amount to the specified number of decimal positions, zero will round to an integer and a negative entry will round to a multiple of 10 (so for example, a decimal precision of -2 will round 1,234,567.89 to 1,234,600, rounding to the nearest 100).

*For the specific conditions relating to FCCS, please see "The Limits of Data Precision in Essbase" at: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=443798297810512&id=1311188.1&_afrWindowMode=0&_adf.ctrl-state=zlaqk3trz_4.