GL Intra Company Accounting

• Overview
• ICA Structure
• Balancing Elements
• Postings

Overview

ICA processing lets the system, based upon set-up parameters, generate journal lines to keep a single transaction balanced for each set of books represented by a user's data entry.

You must designate one of your account segments as the balancing segment for a transaction. For example, if your account definition is Div-Acct-Centre, you may specify that when a transaction crosses divisions, the system should generate lines to keep each division balanced. You can also specify that when a transaction crosses management codes, the system should generate transaction to keep each management code balanced. Otherwise, you can specify that when a transaction crosses cost centres, the system should generate transactions to keep each centre balanced.

You can find further information on ICA in:

• Defining Intra-Company Accounting (ICA) Relationships
• Setting Up Company Controls
• Intra company Accounting (ICA)

ICA Structure

ICA processing relies upon GL structures. On the structure, you specify the points in the organisation that require a balanced set of books. These points are called BTZ (balance to zero) elements. You can also specify additional elements that allow you to generate a BS or P&L Statement. But if the element is not a BTZ element, the statements will not balance.

The following structure is based on locations. For each BTZ element, you specify the path keys that point to the element. When you enter a journal with path keys that cross multiple BTZ elements, the system generates lines to make the debits equal the credits for each BTZ. See Structures for more information on structures and path keys.

Diagram gl030

The locations, LOC1, LOC2, etc. are defined as management codes on the Chart of Accounts for the management segment Location. This structure is then designated as the ICA structure on the GL Company Controls screen MEAB and the Location segment is identified as the relevant ICA management segment. Suppose that the elements marked with an asterisk are BTZ elements. When necessary, the system generates postings for each element, so they will be in balance with regard to Location. Any element that is higher in a structure than a BTZ element, must also balance. For example, SUB1 will balance, as will DIV3 and COMP.

Balancing Elements

e5 GL works on the principle that for every actual balance (AB) posting there is an equal but opposite posting. For example, for a £100 debit posting to LOC1, there will be a £100 credit, which may post to another location, or to a different nominal for LOC1, assuming the structure on the previous page is the ICA structure. If the £100 credit posts to LOC2, these two postings will balance to zero for DIV1 when the management segment Location is considered.

ICA is demonstrated when the double-entry posting involves two BTZ elements. For example, a £100 debit to LOC1 and £100 credit to LOC3. This would leave DIV1 and DIV2 out of balance if not for ICA. The system makes additional postings using a Location management code for DIV1 and DIV2 to credit DIV1 with £100 and to debit DIV2 with £100.

ICA only generates these additional postings when actual or accrual postings are made. Planning and commitment accounting adjustments do not generate any ICA postings as there is no requirement for equal and opposite postings for those types of processing.

Cost Allocation only generates ICA postings when actual values (AB) or value-dated balances (VB) are allocated.

Postings

This section shows the postings that arise in a company that is using ICA. These postings may occur when transactions originate outside of GL or within GL. In the examples in this section, a batch of transaction details is created and, as part of the ICA routine, additional ICA postings may be created.

In all of the examples, the following structure is used:

Diagram gl040

There are five BTZ entities on this structure, as defined on the Intra Company Account screen MECJ. They are indicated with an asterisk (*). The ICA management code that is set up to use when generating ICA postings is indicated with a hash sign (#).

The following list identifies how this structure is set-up:

• DIV1 uses location LOCA when it generates ICA postings for DIV1
• DIV2 uses location LOCB when it generates ICA postings for DIV2
• LOC5 uses location LOC5 when it generates ICA postings for LOC5
• LOC6 uses location LOC6 when it generates ICA postings for LOC6
• SUB2 uses location LOC7 when it generates ICA postings for SUB2

The ICA Relationship screen MAKJ lets you specify which BTZ elements can trade with one another. This screen also lets you specify the nominal and other required segments the system should use for the ICA when generating ICA lines.

Suppose trading between the following:

Note: The location LXXX in the following examples indicates the entry is irrelevant, as it will be overlaid with the preceding locations when the system generates transactions.

This can be achieved with the following arrangement in which eight trading relations are defined on the ICA Relationship screen MAKJ:

NOTE There are no entries between DIV1 and the elements in DIV3. Therefore, when transactions cross elements in these divisions, the system uses the first entry in the table (the default). If you want to prevent a pair of elements from trading, create an entry with a blank account number.

A key concept in ICA is that there is an "owning" BTZ element for every data entry batch. The owning BTZ element holds responsibility for entered transactions and represents the trading point for the transactions.

If the trading point is not one of the BTZ elements to which one of the line-level entered ICA management codes is linked, there will be additional ICA postings.

Data Entry Transactions:

Assume the user enters these detail lines for all of the following examples:

Example 1:

If the header BTZ element is DIV1, the system generates these ICA postings:

Consequently, each BTZ element remains in balance with these journal lines:

Example 2:

If the header BTZ element is DIV2, the system generates these ICA postings:

Consequently, each BTZ element remains in balance with these journal lines:

Example 3:

If the header BTZ element is SUB2, the system generates these ICA postings:

Consequently, each BTZ element remains in balance with these journal lines:

See also

General Ledger Home Page