Key Terms and Concepts

This section aims to explain the key terms and concepts.

Adjustment Entry

An entry passed in the Product Processor (PP) to reconcile it with the associated GL for the amount equivalent to the difference and an entry in the Contra GL Account with the opposite sign for the same amount   is an adjustment entry.

Adjustment Entry Floor

If the difference of Source and Target  is less than the Adjustment Entry Floor specified in the definition, then the calculated difference is not eligible for adjustment and entry will not be logged in the Adjustment Entry Table.

Attributed Dimension

 A dimension whose members can have other properties or qualifiers known as Dimension Attributes.

Data set

A dimension used for segregating data into different sets according to its use or its source, for example, to separate actuals data, budget data, and encumbrances data. Other uses include separating test data from production data and creating separate data sets for What-if Analysis

Dimension

A structure that can be used to categorize business data. A dimension contains members. A dimension can be hierarchical in that you can organize the members into one or more hierarchies, or non-hierarchical.

 Dimension Attributes

A property or qualifier that further describes a dimension member. An attribute can be anything such as a date, a number, or a character string. For example, the Geography dimension can have an attribute Population that designates how many people live in that area. Each member of the Geography dimension therefore has an associated population.

Hierarchy

A structure of dimension members organized by parent-child relationships

Global Threshold

Global Threshold is applied at an execution level where all the reconciliation differences for execution are added and checked across the absolute sum of source balance.

Inherit to Child

This feature is used to find child legal entities under the hierarchy node of a Legal Entity that is selected at the definition level. If this feature is used while defining the GL Reconciliation rule, then all child nodes will participate in the reconciliation process.

Reconciliation

The process of comparing information from one data source to another. An Account Reconciliation for a specific Period. Reconciliations consist of account balances (obtained from the Source System for the Period) and account properties.

Reconciliation Difference

Reconciliation difference refers to the difference in the balance between the Source and Target .

Threshold

A tolerance level to be set by the user in terms of either the maximum difference allowed in any single Product Processor and its corresponding GL or the maximum number of Product Processors having differences in the GL Reconciliation.

Positive Threshold

These values are used to identify the breach types, categorized as Negative Percentage Threshold (NPT), Positive Percentage Threshold (PPT), Negative Absolute Threshold (NAT), Positive Absolute Threshold (PAT), and Not Breached (NB). The Breach Type is identified at runtime during the reconciliation process and Audit Trail entries are posted with this information.

Negative Threshold

These values are used to identify the breach types, categorized as Negative Percentage Threshold (NPT), Positive Percentage Threshold (PPT), Negative Absolute Threshold (NAT), Positive Absolute Threshold (PAT), and Not Breached (NB). The Breach Type is identified at runtime during the reconciliation process and Audit Trail entries are posted with this information.

Threshold Breached Type

The different types of threshold breaches are listed as follows:

·       PAT - Positive Absolute Threshold

·       NAT -Negative Absolute Threshold

·       PPT - Positive Percentage Threshold

·       NPT - Negative Percentage Threshold

·       G- Global

·       NB: Not breached

General Ledger to Product Processor

 

Consolidation Type

There are two consolidation types supported by the application:

·       Solo

·       Consolidated

       Solo

When a legal entity is selected with consolidation type as Solo, then all the exposures of that particular legal entity are selected for processing. Manual reconciliation definition can process solo legal entity data.

Consolidated

When a parent legal entity is selected as Consolidated, then all the exposures of that legal entity and exposure of each level (or levels) of descendant child legal entities (without intra-group exposures) are selected for processing. In intra-group exposures, the counterparty is a child descendant of any level. For an intra-group scenario (where GL Structure has specific intra-group GL Code in addition to regular GL Codes), intra GL Codes are considered only from the GL side for processing. Non-Intra is a scenario where no GL Codes are present for reconciliation definition.

Figure 4: Consolidated Process Flow

 

In this case, LE 1 is the parent legal entity, and LE2 and LE3 are the immediate child legal entities of LE1. Similarly, LE4 and LE5 are immediate child legal entities of LE2, but second-level descendant legal entities of LE1.

If you select LE2 (parent) for consolidated treatment, then exposure to LE 4, LE 5, and LE7 are considered as intra-group exposures.

NOTE:   

The application only aggregates data on the PP side for a consolidation reconciliation type; such aggregation is only to reconcile data and does not consider minority or majority holdings.

 

Intra-group exposures are identified by the customer reference ID in the Product Processor. For LE2, if the customer reference ID is LE4, LE5, and LE7, then these are considered as intra-group exposures. Exposures to LE3 or LE6 are not considered as intra-group exposures as they are not the child descendant of LE 2. If you select LE7 for consolidated treatment, then no exposures are considered as intra-group exposure since LE7 has no child legal entity.

NOTE:   

Intra-group exposures are identified by the customer reference ID in the PP Table.

 

Inherit to Child

This feature is used to find child legal entities under the hierarchy node of a Legal Entity that is selected at the definition level. If this feature is used when defining the GL Reconciliation rule, then all child nodes will participate in the Reconciliation Process.

 Manual Reconciliation Definition

In manual reconciliation definition, user input is sought on the GL side and PP side to determine the course of reconciliation. This is applicable for both GL level and map level reconciliation. In GL level reconciliation, unique GL codes are identified from the GL code mapping. At the map level, GL codes do not form a part of the reconciliation definition. A manual reconciliation definition can be used for a solo or consolidated legal entity. The reconciliation definition for a consolidated GL, having an intra-group GL structure, is computed from GL Data and not from PP Data. Therefore, any account present in the PP but unavailable in GL is not captured in the reconciliation definition.

GL Level Reconciliation

In GL level reconciliation the difference between GL system and Product Processors Systems at each reconciliation dimension node level within a GL Code is identified. For manual reconciliation definition, unique GL codes are identified from the GL side. If it is at the solo level, then exposures originating in the legal entity are selected. If it is at the consolidated level, then exposures originating in the selected legal entity and its Child Entities (with or without intra-group exposures depending on GL Structure) are selected.

The adjustment entry allocation depends on the reconciliation type selected. In GL level reconciliation after a definition is executed, the differences that emerge as a part of the reconciliation definition (GL–PP level reconciliation) are reported in the adjustment entry table. This table shows all the entries of an executed map that requires adjustment. In GL level reconciliation, the difference in amount can either be posted to Product Processors or an external table. For more information on the external table, see the Data Requirement.

NOTE:   

In GL level reconciliation the adjustment allocation is always automatic, that is, you do not have the option of editing the allocation ratio.

 

Map Level Reconciliation

In map level reconciliation the difference between GL Data and PP Data at each reconciliation dimension node level across all PPs is identified. Unlike GL level reconciliation, map level reconciliation is computed at an aggregate level of the reconciliation definition; by ignoring the GL code and by considering reconciliation dimensions. Map level reconciliation is applied at the legal entity level - either solo or consolidated. If it is at the solo level, then exposures originating in a particular legal entity are selected. If it is at the consolidated level, then exposures originating in the selected legal entity and its child entities (excluding intra-group exposure depending on GL structure) are selected.

NOTE:   

In a map level reconciliation, adequate filters for the PP data must be selected to ensure that the actual data selected on both sides are the same.

You need to create GL hierarchy data with one additional node value as ‘DEFAULT’. You can provide this Child code as ‘DEFAULT’ and name of the node can be set to ‘Default’.

The adjustment entry allocation depends on the reconciliation type selected. In map level reconciliation, once a definition has been executed the differences that emerge as a part of the reconciliation (General Ledger–Product Processor Level Reconciliation) are reported in the Adjustment Entry Table. This table shows all the entries of an executed map that requires adjustment. In map level reconciliation, the difference in amount can either be posted to Product Processors or an external table. In map level reconciliation, the adjustment allocation can either be automatic or manual.