In IDL Konsis a chart of accounts (KTP) is a key under which
A chart of accounts is created by either taking the 'action' - 'Create new data' or via the asterisk in the toolbar. Changes can be made by marking the chart of accounts with the 'action'- 'Edit data' or the pencil in the toolbar or by right clicking and entering 'Edit data.'
From the application 'Chart of accounts' (KTP), you can branch off directly into the subsequent applications 'Accounts' (KTO), 'Account categories' (KTPGRP) or even the 'Controlling objects' (CNT) application, if you have work to do with the additional module CONTROLLING.
A chart of accounts is issued on a group-wide basis and therefore considered to belong to the group of group-wide data (KONDAT).
Description of individual attributes:
[Chart of accounts]: To make it easier for the user to maintain the individual charts of accounts necessary, IDL Konsis relies on so-called chart of account numbers. The field length for chart of account numbers consists of six digits and these can be issued alphanumerically. The company charts of accounts can be used by more than one company at the same time. Once a chart of account number has been issued, the underlying charts of accounts may be used as follows:
[Description]: The description can consist of a max. of 70 digits.
[Short name]: The short word can contain up to 10 digits.
[Chart of accounts flag]: The chart of accounts flag defines whether the chart of accounts is a company chart of accounts (G) or a group chart of accounts (K).
[Fixed asset object prefix]: If you enter a fixed asset object prefix, you will automatically generate fixed asset objects for this chart of accounts whose keys consist of the prefix entered here and the account number. The special entry '*' means no prefix will be defined. The key for the fixed asset object will then automatically be the account number. We urgently recommend that you use different prefixes for company and group charts of accounts provided that naming conventions allow for identical account numbers to be used.
[Chart of accounts type]: This field controls whether the chart of accounts key issued here is also the key for a controlling plan. A distinction is made here between only a chart of accounts (K), only a controlling plan (C) and both accounts and a controlling plan (M).
[Default B/unit of chart of accounts]: If you work with business units, you will be given the chance to store a standard business unit here for the chart of accounts. This will always be accessed if a business unit entry is missing (with a controlling object or an account).
[Number of columns for account No.]: This field is used to control the length of the account numbers that are to be managed in IDL Konsis. Entries of between 01 and 14 are possible. The following functionalities are associated with entering the account length:
[Accounting standard]:Seven different accounting standards that can be allocated to these charts of accounts are available for you to select from (see selection)
[Allocated group chart of accounts]: Via this field, the chart of accounts to be used will be stored during the recoding of the company chart of accounts to the group chart of accounts. This will be offered automatically when you allocate company to group accounts in the account master application (KTO).
NOTE:
[Valid from / until]:The valid from period is a mandatory field, while the valid until period represents an optional attribute. Both attributes define the period as of which or until which the chart of accounts is valid. Via the user-specific startup setting (VOR), you can control whether or not charts of accounts with limited validity (any entry of a valid until period) should be displayed any longer.
The application 'Accounts' (KTO) provides an overview of all of the accounts defined for one or more charts of accounts. The accounts of the group chart of accounts will be issued on a group-wide basis and therefore belong to the set of group-wide data (KONDAT). The company accounts, on the other hand, will be defined for each individual company or for a group of individual companies.
The accounts cannot only be displayed and printed out in this overview, but also selected in a distinct manner. This can be done by either using the fields shown in the overview or the filter function in the toolbar. Furthermore, the 'sort and select option' also offers a variety of different frequently used ways to sort and select.
The action menu can be opened by either pressing the right mouse button or using 'action' in the toolbar. Various actions can also be taken by using the toolbar.
Explanation of individual actions:
[Create new data]: The master applications account single record (KTOE) can be accessed by taking the action 'Create new data.' A new account can be created here as discussed in the next chapter.
[Edit data]: You can access the master application accounts single record (KTOE) by way of the 'Edit data' action. Here, you will be able to edit accounts as described in the next chapter.
[Mass-copy]: The mass-copy action can be used to copy certain accounts in another chart of accounts.
[Mass-change]: With mass-change, the attributes shown in the illustration below can be changed simultaneously analogous to the master application account single record (KTOE) for several marked lines (with the exception of the key fields with yellow backgrounds).
[Positions&Accounts-Allocation]: Branches off into the overview 'Positions&accounts allocations' (POSKTO), in which the accounts that contain report positions can be linked.
[Create allocation POSKTO for company account no.]: This function is quite helpful and saves a lot of time if the accounts of a company chart of accounts have already been assigned to group accounts, but not report positions. The following steps are mandatory in order to perform subsequent processing:
[Groups for account/posting key allocation]: Branches off into the application 'BSG,' in which a posting key set can be allocated to the respective account or allocated transaction development. You will need this allocation to prevent invalid combinations of the account and posting keys.
[Edit help text/Display help text]: The action 'Edit help text' allows you to store and edit detailed descriptions on every account. Then you can use 'Display help text' to review these.
This application is used to maintain the accounts master data for a specific account in the accounts overview or to open a new account. This application can be accessed via the line actions, from out of 'KTO,' via the action'-' Create new data,' the action '-' Edit data' or by using the asterisk or pencil in the toolbar.
The IDL Konsis account number consists of a maximum of 14 digits and is defined as a numerical field. Besides the description 1 (max. 70 digits), a brief description of the account (max. 10 digits) and the so-called Balance sheet/P&L code, the valid from date also needs to be kept up-to-date. Furthermore, an account can be issued with a variety of additional specifications that have a distinct controlling character in the subsequent applications.
The following Balance /P & L code is possible in IDL Konsis:
The Balance /P & L code allows for selections to be made with respect to the various account groups and allows for plausibility checks (Balance /P & L codes 1 to 4), like the balance sheet/P/L assessment of the account balances (KTOSAL) in the checking block.
The user can also present quantities in the form of accounts in IDL Konsis by using the statistical code '5'. As an example, employee figures or the number of branches can be maintained in IDL Konsis. Parallel information that corresponds with the Balance /P & L codes 1 to 4 but does not appear directly in the balance sheet or in profit & loss can also be stored in the other statistical codes 6-9. Examples include sales revenue by regions or displaying the guarantees and other commitments or financial commitments.
If an intercompany code is maintained in statistical accounts, these can be taken into consideration during automatic consolidation of debits and credits. Nevertheless, they should be allocated to one special, individually created consolidation process like S1, for instance, because it is easier to reconcile.
Codes for certain roles can be allocated via the account flag, for instance, the entry that further details are needed.
The following flags are available:
[C = retained earnings deconsolidation]: classifies accounts (e.g. retained earnings, IFRS reserves) which have to be considered at calculation of a deconsolidation result. The deconsolidation function therefore considers beside the accounts with the account flags 'W' and 'X' also thaccounts with the account flag 'C' at calculation of the deconsolidation result.
[E = Results account]: The consolidation system will require a so-called E account at both the level of the company and group chart of accounts. The annual results calculated by the system will be stored in this account. This will allow for details on the total P/L position 'Annual result' if the respective setting has been entered across the entire company in 'KTOSAL' and serves as the basis for calculating the amount of 'profit that belongs to other companies' (consolidation function 'FK' - calculation of minority interests).
[F = Minority interests on results]: The 'Annual net profit share of foreign companies' account can be marked with the accounting flag 'F'. This will allow for deviating position allocations for the report. The allocation in the application 'POSKTO' is generally only permitted between accounts and positions with a related balance sheet/P/L flag, for instance, '1' (assets) with '2' (liabilities), '1' with '3' (earnings), on the other hand, is not possible. The results account (Account flag 'E') represents an exception that can be allocated as a passive account ('2') for an earnings position ('3'). Yet another similar exception is also possible for the account 'Annual net profit of foreign companies' which is then to be issued with the account flag 'F'.
[G = Group results account]: Group results can be defined using the account flag 'G'. This is necessary if the results postings for consolidation vouchers that have an effect on results are not to be entered in a general results account (with the account flag 'E'), but rather in a separate group results account.
[N = Clearing account]: Clearing accounts are characterized by the account flag 'N.' Only accounts that are marked accordingly may be listed as clearing accounts in the consolidation parameters. Clearing accounts are only permitted in the group chart of accounts. No company financial statement data may be recorded in clearing accounts and consolidation postings only if a clearing account is specified in the respective consolidation parameter. For this reason, they will normally not be shown in the account selection (exception: clearing account in the consolidation parameters).
[Q = Rounding difference of quotal companies]: This flag characterizes accounts that were set up especially for handling rounding differences from proportionate conversion.
[T = Difference amount]: The account flag 'T' is used to mark difference amount accounts. Only accounts that have this account flag are allowed to be entered as difference amount accounts in the consolidation parameters.
[U = Account for BU split / cost center]: If you work with business units while specifying account groups in the company & business unit allocations (GESUBR), automatic compensation for the differences in results will take place in a compensation account. This compensation account is to be issued the account flag 'U'. If the compensation account is a balance sheet account, then the results will be zero in accordance with the totals of P/L balances, in other words for a balance sheet business unit (account set 'B'). The opposite will be true for the results in accordance with the total of the balance sheet balances, in other words for a P/L business unit (account set 'G') at zero if the compensation account is a P/L account.
[W = Net income acc. carry-forward HBII ]:This account flag refers to an account for retained earnings at the company level. Only one account is allowed to have this flag and it can only be stored in the company chart of accounts.
[X = Net income acc carry-forward HBI]: This account flag refers to the account for retained earnings for both the company level (if account flag W not used here) as well as the group level. Only one account is allowed to be issued this flag.
The field "IC account flag" collects the intercompany characteristics of the account. The following characteristics are available:
[B = Participations]: the participation situation can be entered into the system for the accounts marked with 'B' via IDL Konsis application 'Shareholding transactions' (GESGES). Normally, a 'B' is entered as the minimum in the account 'Shares in affiliated companies'. If shareholdings are to be managed for other accounts as well, these accounts should also be labeled accordingly. Note: A participations account must be a balance sheet account.
[I = Intercompany account]: The main account balances alone are not sufficient for consolidating debits and credits and consolidation of income and expenses. In addition, detailed information on the distribution of the account balance to the respective partner companies is also needed. These can be compared for each company pair as part of the appropriate consolidation function. In IDL Konsis this detailed information can be entered or read into the application 'IC sub-account balances' (ICKTOSAL) for all I accounts.
[J = Intercompany account / details incomplete]: The account flag 'J' means the account balance contains partly IC information and therefore only a share of the details are shown on IC account balances. For this reason, accounts from the company chart of accounts with the account flag 'J', 'I' or without an account flag can also be assigned to a 'J' account in the group chart of accounts. Regardless of this, it is possible to pass on the change in the account flag of a group account from 'J' to all of the allocated accounts. Here, the user will be asked whether an adjustment should be made. If he confirms this, all of the allocated company accounts will also be issued the account flag 'J.' The exceptions are IC main accounts (accounts with a fixed IC company) that will retain the account flag 'I'. Otherwise, the account flags of the company accounts will be retained as in the past.
The field "Matching P/L , transaction development" collects the flags 'D' , 'Y' and 'Z' for adjustment between p&l accounts with these flags und transaction development columns with the same flags.
[D = Depreciation account]: IDL Konsis is capable of auditing the ongoing depreciation according to the fixed asset transaction development (transaction development column 13) together with the depreciations in profit & loss. The prerequisite for this plausibility check is that the system must be capable of identifying the depreciation accounts in profit & loss. For this reason, all of the relevant reconciliation accounts must be set up with 'D' in profit & loss. Note:A 'D' account must be a P/L account and cannot be a fixed asset account at the same time.
[Y = Provision releases, Z = Provision additions]: The account flags 1 = 'Y' and 'Z' refer to P/L accounts in which amounts for the release or addition of provisions are maintained. In terms of their character, they are quite similar to the AfA accounts (Account flag 1 = 'D'). If Y or Z accounts are defined in the chart of accounts, a check will be performed for the provisions transactions for the transaction development columns for releases or additions against the amounts in these accounts. Deviations will be reported during every audit, also in producing the provisions transaction development.
When a transaction development is allocated to an account, a determination is made as to which transaction development this account will be processed in. Every account can only be assigned one transaction development. The choice of the transaction developments is made in the 'Transaction development' (SPI) application.
The following types of transaction developments are usually maintained in IDL Konsis:
[Fixed asset transaction developments]:Fixed asset accounts are to be allocated to a fixed asset transaction development to ensure that the transactions can be maintained appropriately in ANLBEW. Only then can a fixed asset transaction development be generated with IDL Konsis. A fixed asset transaction development also allows you to automatically calculate depreciations and reconcile depreciations with the appropriately labeled P/L accounts (account flag 'D').
[Capital transaction developments]: Capital transactions (KAPBEW) have two functions in IDL Konsis. On the one hand, they help to describe the development of equity capital in order to generate an EC transaction development. On the other hand, they are a mandatory prerequisite for illustrating historical equity capital conversion. This development can be entered for capital accounts by using posting keys in the application KAPBEW.
[Provisions transaction developments]: If you are planning to generate a provisions transaction development with IDL Konsis, the transactions that pertain to the individual provisions accounts must be entered into the system. Maintaining this development in the application provisions transactions (RUEBEW) is only allowed for accounts that are assigned to an appropriate transaction development. A provision transaction development also enables you to reconcile the additions and releases with the help of the appropriately labeled P/L accounts (account flags 'Y' and 'Z').
[Other transaction developments]: The customer can define additional transaction developments that have no special function in IDL Konsis, for instance for account payable transaction developments or cash flow statements. The transactions from the account balances in the application 'SPIBEW' can be maintained for the accounts assigned to these transaction developments.
There is an entry code for annual, quarterly and monthly closings that are used to determine what periods data is allowed to be entered in this account. If the entry code is set at 'X', then data can be entered into this account in these types of periods. Otherwise, the entry will be refused as an error. Therefore, accounts that are not approved for entries will not be issued an entry in the respective fields.
Oftentimes main accounts are maintained in financial accounting systems for a specific subsidiary. If this is the case, then a company account can be allocated correctly to a certain company and maybe even to a certain division of this company via the fields 'for IC company' and 'for IC unit.' This ensures that an IC balance is automatically generated for the company/business unit specified and entered into the intercompany sub-account balances overview (ICKTOSAL) when a company fact is changed into a group fact (for instance from I2 to I3). Parallel details on the account balance are possible with the help of the application ICKTOSAL by making an appropriate setting in FAC. This is only possible for the company entered in the account master, however.
With this attribute, an account can be permanently assigned to a specific business unit.
On the one hand, the (neutral) values '1' (internal) and '2' (external) and, on the other hand, the most common accounting types 'F' (FER (CH)), 'H' 'HGB', 'I' (IFRS), 'L' (Local GAP) and 'U' (US-GAAP) are the types offered for users to utilize. If there are changes in the account master (dialogue or import), only an account of the same accounting standard or an account that does not specify the accounting standard can be used as the higher-level group account if an accounting standard has been entered in the company chart of accounts. For the report data contained in this account, the standard selected is not allowed to deviate from a standard that might perhaps be entered in facts.
This attribute allows you to determine the reconciliation circle for consolidation of debits and credits (SK) including special treatment of IC accounts for dividends (SD) and consolidation of income and expenses (AE) inside of which an I or J account is to be eliminated. The respective reconciliation circles are defined in the application 'KVA' (consolidation functions).
An entry can be made for each capital account as to whether differences between equity capital in the company financial statement (HB2) and the equity capital entered in capital consolidation should remain in the respective account or be reposted to a so-called carry forward capital consolidation account. This function can help you to ensure that the respective capital account from the group view is always 'cleaned up' to read zero. If this field remains empty, this means reposting will not take place.
By making an entry in the field account for aggregation, certain accounts can be pre-aggregated (for instance, determination of the total balances of all Deutsche Bank accounts, calculation of the amount payable from aggregation of input tax and value added tax accounts). Aggregation will be applied to the reconciliation for the next fact. If the chart of accounts is not changed (for instance from I1 to I2), the aggregation flag must be entered for the target fact (I2) in the application FAC. If the chart of accounts is changed (from I1 to I4, for instance), the settings in the aggregations will always be taken into consideration even if facts are to be skipped. The account type 'V' can be selected after this account in the overview KTO.
Example 1: Aggregation of accounts with the same Balance /P & L code:
This example shows how multiple bank accounts with a bank can be aggregated within one of these accounts. Our customers use this function most of the time.
Illustration:Entry of an account for aggregation for the marked bank accounts
| Account | Description | Aggregation Account | Accounts balance | S/H-Knz. | Fact |
|---|---|---|---|---|---|
| 112201 | Deutsche Bank Account B | 112200 | 351.350,98 | H | I1 |
| 112202 | Deutsche Bank Account C | 112200 | 737.282,89 | H | I1 |
| 112200 | Deutsche Bank Account A | 112200 | 1.088.633,87 | H | I2 |
After switching from fact I1 to fact I2, account 112200 Deutsche Bank account A will contain the entire balance in the amount of 1,088,633.87H. It is assumed that account 112200 in I1 does not have a balance. In general, this is possible, however.
The presentation and composition of the aggregation balances can be understood by keying up to a 'higher fact' in the KTOSAL application by using the selection option VG - Selection and Sorting by chart of accounts / account for aggregations / company number / business unit.
If you aggregate the accounts 112201 and 112202 in I1 within the account 112200, you'll see the following in the account balances:
You can also display the exact composition of the balance in fact I2 in account 112200 with the help of the origin list that you were able to develop in the application KTOHER.
Example 2: Aggregation of accounts with different Balance /P & L codes (fictitious):
This example shows how the active currency account exchange (kept in USD) and the passive account current business (kept in EURO) can be aggregated. Account receivables and account payables are balanced together due to the fact that one assumes that both accounts are with the same bank. Ongoing passive transactions take place with banks by way of the customer account receivables or advances to. Practically speaking, however, this example is not used very often.
| Account | Description | Aggregation Account | Account Balance | S/H-Knz. | Fact |
|---|---|---|---|---|---|
| xxx (Active -Kto) | Cash (USD) Institute A | xxx (Active account) | 1,000,000 | H | I1 |
| yyy (Passive account) | Continuing operations (EU) | xxx (Active -Kto) | 750,000 | S | I1 |
| xxx (Active account) | Cash (USD) Institute A | xxx (Active -Kto) | 250,000 | H | I2 |
Example 3: Aggregation of intercompany accounts:
Accounts that show the account flag 1 = I can also be aggregated. This is quite helpful in the following example:
The accounts 164600, 164610 and 164620 are intercompany accounts and contain an entry in the IC company field. This means a new account needs to be entered if IC balances exist with other companies like 010, for example, etc. In this case, the accounts mentioned are aggregated inside the account 164599 loans that is also an IC account, but lacks an entry for permanent company. If the balances are posted to the next higher fact in which aggregation has been performed, IC balances against the respective companies will be generated automatically. These can then be taken into consideration during automatic consolidation of debits and credits.
The planning account for aggregation will only be analyzed in IDL Forecast. It is designed to minimize the number of accounts that need to be planned for planning. The account type 'P' can be selected after this account in the overview KTO.
By making an entry in the field entitled account if D/C changed with a group account, a correct active / passive entry can be achieved at the group level foreign account contained in the company chart of accounts whose balance can change. Accounts if D/C changed can be issued at both the company and the group level. It is recommended that aggregations take place within the fact I2, and accounts if D/C changed and S/H controls be set up at the group level. The account type 'W' can be selected after this account in the overview 'KTO'.
Example:
| G-Kto. | Bezeichng. | B/G | K-Kto. | Bezeichng. | B/G | WechsKto. | Bezeichng. | B/G | Balance GesKto |
|---|---|---|---|---|---|---|---|---|---|
| 112200 | Dt.Bank Kto.A | Active | 28410 | Guthaben Kreditinst. | Active | 42010 | Verbindlkt. Kreditinst. | Passiv | 1.088.633,87 H |
Case 1: Balance in H (see above): The company account 112200 is assigned to the group account 28410 cash at the bank. With the group account 28410, account 42010 accounts payable at the bank is defined as an account if D/C changed. With this constellation, documentation in group takes place in the group account 42010 accounts payable bank due to the fact that a positive balance is supplied to an active account (Balance/profit & loss code =1) via the group account and the allocation in group to an active account (Balance/profit & loss code = 1) with an account if D/C changed (Balance/profit & loss code = 2) is controlled passively. If the debit / credit code deviates from the standard value, the account if D/C changed will be addressed.
Case 2:Balance in S (not shown: if the balance in account 112200 is negative, it will be shown in group in the group account 28410 cash at the bank due to the fact that a debit balance in an active account (Bil/P/L-Knz.=1) is controlled by the group account in the standard allocation and the group is also controlled by an active account.
Note: The allocation of accounts if D/C changed must be mutual. It can be checked by using the overview KTO. The allocated account if D/C changed must have the opposite Balance/profit & loss code. The transaction developments should match as closely as possible to ensure that transactions can be retained during reconciliation with the next fact. If an account if D/C changed is entered with a different transaction development, a warning will be displayed, however the selection will depend on the transaction development.
If the balances for a fully consolidated company face the balances of a quota consolidated company in the consolidation of debits and credits or consolidation of income and expenses then the proportionate share of the IC balances for the fully consolidated company as well will be directly eliminated (based on the quota of the opposite company). If a quota reference account is entered in the account master for the IC accounts, the remaining share of IC balances for the fully consolidated company will be reposted to yet another posting set in the quota reference account and will not remain entered in the IC account. Accordingly, the establishment of a quota reference account is only possible and only makes sense with an account that contains the account code 'I'. In addition, you must show the same Balance/profit & loss code and the same transaction development in order for the amount posted to this account to be reposted in a proper transaction development manner. The quota reference account can have a 'J' as the account flag, but not a 'I'. The account type 'Q' can be selected after this account in the overview KTO.
This account can also be entered for all capital accounts (based on the transaction development of the account) and is used in place of the minority interests account mentioned in the consolidation parameter 'FK.' This allows for yet another distinction in posting of the minority interests for each capital account to be achieved. If this field is left empty, postings will be made as normal to the account shown in the consolidation parameter 'FK'. Then the account type 'F' can be selected after this account in the overview KTO.
A retained earnings account to which the carry forward postings should be made can be assigned to each P/L account instead of normally using what is shown in FAC (for group charts of accounts) or the account with the account flag = 'W' (for company charts of accounts). This account must be a balance sheet account. It has priority over the retained earnings account entered in the fact with carry forwards for a period. The account type 'E' can then be selected for entry after this account in the overview 'KTO.'
The link between accounts from the company chart of accounts and the respective group accounts takes place via the 'allocated group account' field. In this case, the chart of accounts number of the group chart of accounts (KON001, for instance) will be read from the respective field from the definition of the company chart of accounts number (GES001, for instance).
The valid from period is a mandatory field, while the valid until period represents an optional attribute. Both attributes define the calculation period as of which or until which values can be assigned to an account and until which these are to be included in reports.
Limitations to the validity are inherited by all of the allocated fixed asset objects with fixed asset accounts, therefore a fixed asset object can never have longer validity then a fixed asset account.
By using the user-specific startup data (VOR) you can control whether accounts with limited validity should be displayed any longer (with any entry of a valid until period).