Introduction
International companies must follow different Accounting Principles in their SAP system. The most common differences appear in provisions/ accruals handling as well as in assets depreciation and acquisition values. Their handling was already described several times in blogs/ SAP Help and other internet sources. However, there are quite often questions appearing in SCN how to handle different capitalization values in different depreciation areas.
This blog goal is to show how, with standard customizing in Investment Management (IM), different accounting principles can be fulfilled by defining which values should be capitalized to asset acquisition and which not.
The whole customizing and next steps are based on new FI-AA (activated business function FIN_AA_CI_1). However, the same settings work in classic FI-AA. For differences between both of them please see section ‘Differences between classic and new FI-AA’.
Prerequisites
Distinguishing which values are to be capitalized is supported only if you use IM objects – internal order or a WBS Element. Capitalization via pure FI-AA AuC (AIAB/ AIBU ) do not support this function.
Technical necessities will be mentioned in this blog in customizing part.
Accounting overview
From accounting point of view the initial bookings of asset-related-invoices are posted as usual to IO/ WBS element on a primary cost element. During the AuC capitalization, based on settings, system rebooks the amount not-to-be-capitalized to an account that should be P&L account without a primary cost element.
Below example presents sample postings, which are performed by system with proper customizing. In this blog the ledger-based approach will be used for presentation of bookings. However also the accounts-based approach can be used here if required – both ways are supported.
In real-life-scenarios most common differences between GAAPs are capitalization of following expenses:
- Realized and unrealized FX Differences
- Interest
- Bank charges related to investment
The booking of different values in different depreciation areas happens, dependent on the FI-AA, either during settlement – in new FI-AA – or during ASKBN posting in classic version.
Customizing
All settings are to be done in IMG Activities stored in following path:
IMG Investment Management -> Internal Orders as Investment Measures -> Capitalization Values per Depreciation Area
If WBS Elements are used, please choose ‘Projects as Investment Measures’ instead of IO path.
At first, the capitalization versions must be defined:
IMG Activity Define Capitalization Versions
Transaction OKGL
They represent a grouping of accounting rules – each version should be assigned to a depreciation area. A separate version should be defined for each different accounting principle, usually representing Group/ Local GAAP and the Tax law.
In my system I have 3 ledgers, represented by 3 separate depreciation areas, so I will define 3 different versions as a consequence.
Afterwards, in the same activity, the versions are to be assigned to depreciation area. If similar depreciation areas that share the same accounting principles exist, then the same version can be assigned to 2 or more areas.
Please note that if the controlling area currency is different than company currency, then a depreciation area with type 07 (Cost-acc. valuation) is mandatory. To such depreciation area no version can be assigned and always 100% of values will be settled (see also note 2498495 – ACC_AA170 during settlement).
In the second step a ‘capitalization key’ is to be created. Capitalization keys are assigned to AuC asset class directly. Imagine having two AuC classes, one for tangible and one for intangible assets. If a situation would happen that some activities booked on an investment should not be capitalized in intangible but can be capitalized in tangible AuC, you must be able to differentiate it. They belong to the same depreciation area, are booked with the same activity type though should be handled differentially during capitalization.
This means that a capitalization key gives you an option, to discern particular expenditures within the same depreciation area (capitalization version) separately. If no such behaviour is needed, then only on capitalization key can be created and assigned to AuC class.
IMG Activity Maintain Capitalization Keys -> Create Capitalization Key
Transaction OKOJ
In the example customizing I have no need to separately treat certain AuC expenditures so I created one capitalization key:
Afterwards, in:
IMG Activity Maintain Capitalization Keys -> Assign Asset Class to Capitalization Key
It should be assigned to AuC asset class:
Since assignment is done, the Capitalization key will be filled in automatically in every new AuC created in this class.
What is left now is to define in which case expenditures can be capitalized and in which not.
IMG Activity Maintain Capitalization Keys -> Define Capitalization Percentages
Transaction OKOI
Capitalization percentages enable to say which percentage of a value from a source posting should be capitalized.
Following the example in ‘Accounting Overview’ paragraph, in my case I would like to separate the investment interest expenditure between areas.
In my case account 90010 is used for all main investment-related expenditures and account 75911X to post interest. All other expense accounts should not be capitalized in any area.
A combination of 4 characteristics can be used to distinguish the source bookings: Cost Element / Cost Origin Group from Material Master (MBEW-HRKFT) / Cost Center / Activity Type.
The values can be assigned based with a single value or based on a pattern. If all types should be included (for example all activities booked on a particular cost element), then ‘++++’ can be entered in the field – this represents all possible values.
It is important to remember that the values are to be entered as they are stored in the database, so leading zeros should be entered as well. Single entries entered without leading zeros, however having leading zeros in database, will be accepted in the customizing entry but not recognized correctly during actual settlement.
Please note that once the capitalization per area functionality is used, system will assess for each characteristic if it should be capitalized or not. If a characteristic could not be determined from single value or a pattern the system assumption will always lead to 100% capitalization of the value in question. This could lead to inconsistencies in asset values.
Therefore it is better to specify at first the values, based on a pattern, which should not be capitalized and then the single or a pattern-based values which should be.
Once the percentages determination is done the last step is to be performed.
Accordingly to the accounting schema presented in ‘Accounting overview’ the amounts not to be capitalized will be reposted to a separate account.
IMG Activity Determine Accounts for Nonoperating Expense
Transaction AO69
This IMG activity is used to specify the account number for such postings is to be entered. This account should not have a cost element, otherwise the controlling module would be updated twice – once with the not activated values and second time with depreciation.
At the end the field ‘Capitalization key’ should be made visible and optional for entry in the asset layout assigned to the AuC class:
IMG Financial Accounting (New) -> Asset Accounting (New) -> Master Data -> Screen Layout -> Define Screen Layout for Asset Master Data
With these settings the customizing is finished.
Example of use
To check the customizing made I have created an Internal Order which is an investment and had automatically assigned capitalization key in AuC:
Having bookings done as presented previously in ‘Accounting overview’ the IO is ready for settlement to AuC:
The settlement is proposed:
As it can be seen the 120 is to be settled, however, system shows that is will be settled in full to asset – during simulation of settlement the capitalization key split is not taken into account – only during posting.
Executing production run created following settlement documents:
As it can be seen in new FI-AA system is creating directly an account per ledger. The differences between classic and new FI-AA are stated in next section of this blog.
Postings in the leading ledger (which is the base for controlling in my case – can be assigned differently in S4HANA):
Postings to non-leading ledgers where the value of 20 should have been capitalized:
Asset values presentation is also correct in leading:
And non-leading Ledgers:
Differences between classic and new FI-AA
The system behaviour in classic and new FI-AA is slightly different when it comes to postings. Classic FI-AA the settlement did post accordingly to leading ledger values to Nonoperating Expense Account only and from this account the ASKBN transaction did reposting in non-leading ledger. The posting schema was following:
Thank you for your attention and stay tuned, more blogs showing specific accounting settings will follow.
Marek
Okumaya devam et...