Adjustments must be made to SAP’s Asset Accounting (FI-AA) component to make it compliant with International Financial Reporting Standards (IFRS). Learn what preparatory settings are required in an SAP system to facilitate these adjustments and how to use parallel reporting to ensure IFRS compliance.
Key Concept
International Financial Reporting Standards (IFRS) are globally accepted accounting principles that are issued by the International Accounting Standards Board (IASB).
The Preferred Approach for IFRS Compliance in an SAP System
Before any specific adjustments can be made in the SAP Asset Accounting (FI-AA) component to make it compliant with International Financial Reporting Standards (IFRS), you need to make some preparatory settings that provide a foundation for various adjustments in SAP capital asset management. These settings need to be carried out in both SAP FI-GL and SAP FI-AA.
As a first step toward compliance with IFRS using parallel reporting in an SAP system, the following are prerequisites. The solution I discuss for IFRS compliance (creating leading and nonleading ledgers) can be achieved only with SAP General Ledger functionality made available by SAP ERP Central Component 6.0 (SAP ECC 6.0):
- A technical upgrade to an SAP ECC 6.0 platform
- Migration from the classic GL to SAP General Ledger
You can establish parallel reporting functionality in SAP ECC 6.0 using the following options:
- Account solution: Single ledger, common, and legal reporting requirements for specific GL accounts are used.
- Special Purpose Ledger: Additional special ledgers are set up for each accounting principle.
- Parallel ledger: Several parallel ledgers (general ledgers) are set up for different accounting principles. These ledgers are based on the standard totals table FAGLFLEXT delivered by SAP. During posting, data can be posted to all ledgers, to a specified selection of ledgers, or to a single ledger (leading and nonleading ledgers).
The parallel ledger is the most preferred option because of the following reasons:
- It facilitates a complete set of separate legal reporting books.
- A single set of GL accounts is used.
- It facilitates different fiscal years for a different legal set of books.
- It facilitates segment reporting using its document splitting feature.
- It is most suitable for complex installations where there are large differences between IFRS and local Generally Accepted Accounting Principles (GAAP).
Note
The account-based approach is recommended when relatively few IFRS differences exist, thereby making it possible to handle them in one ledger. Although it is the quickest and least expensive option to implement, it can lead to a more complex chart of account (COA).
Basic IMG Settings for Parallel Ledgers
Below I explain the desired general settings as a prerequisite required for parallel reporting in SAP. Later I move on to the specific adjustments required in the FI-AA component to address the differences identified and ensure IFRS compliance in FI-AA.
Settings in Financial Accounting Global Settings
Define one leading ledger or group for deriving statements in accordance with US GAAP and at least one nonleading ledger or group for deriving statements according to IFRS. When you create a ledger, the system automatically generates a ledger group with the same name.
Note
The reason I suggested that US-based companies define US GAAP as the leading ledger is because as of today, most of these companies are still following US GAAP as their primary accounting principle. The SEC has not yet declared the final roadmap for mandatory IFRS compliance. The current tentative deadline is 2014-2015 for mandatory compliance. Until the time IFRS becomes mandatory, US-based companies may opt for reporting as per IFRS in parallel during the transition phase.
Follow IMG menu path > Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Ledger > Define Ledgers for General Ledger Accounting (Figure 1).

Figure 1
Define leading and nonleading ledgers
In the setting shown in Figure 1, the objective is to define two types of ledgers:
- Leading ledger. The leading ledger is based on the accounting principle that is normally used by a company to prepare consolidated financial statements. The leading ledger is integrated with all the subsidiary ledgers and is also updated for all company codes. In this scenario, the leading ledger is defined for US GAAP.
- Nonleading ledger. A parallel ledger to the leading ledger, the nonleading ledger is based on the accounting principle for parallel accounting (e.g., IFRS). Subsidiaries of the parent company use this ledger for reporting as per their local accounting principle. In this scenario, the nonleading ledger is defined as IFRS.
Note
Only one ledger can be defined as a leading ledger. However, more than one ledger can be a nonleading ledger.
Define currencies for leading ledger per company code. Follow IMG menu path Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Ledger > Define currencies of leading ledger (Figure 2).

Figure 2
Define currencies for leading ledger per company code
The screen of this transaction looks similar to the one used to define additional local currencies under global settings in FI. This transaction is the corresponding transaction to define additional currencies for company codes in Financial Accounting (New) where the SAP General Ledger is activated. This screen is not immediately seen after you execute this transaction. It appears after selecting the company code for defining additional currencies after following the preceding menu path.
As shown in Figure 2, you define the currencies to be applied to the leading ledger and make the following settings for each company code:
- Company code currency or first local currency
- One or two additional local currencies per company code parallel to the first local currency
For each of the additional local currencies, define the following key parameters:
- The exchange rate type that is used to determine the exchange rate. (e.g., type M [the average rate] that is commonly used)
- The source currency that is used as a basis for currency translations (e.g., transaction currency or first local currency)
- The date that is used as a basis for translating amounts according to the exchange rate table (TCURR), such as the posting date or document date
Activate the nonleading ledger for company codes with the assignment of currencies, fiscal year variant, and posting period variant (PPV). Follow IMG menu path Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Ledger >Define and Activate Non-Leading Ledgers (Figure 3).

Figure 3
Activate nonleading ledgers for company codes
The following settings are made in this IMG activity:
- Nonleading ledgers in the company codes are activated.
- Additional currencies for the nonleading ledger are defined.
- The fiscal year variant for the nonleading ledger is defined in case it’s different from the leading ledger.
- The PPV for the nonleading ledger is defined in case it’s different from the leading ledger.
In this scenario, a nonleading ledger for IFRS can be defined and activated for the company codes in the scope for reporting as per IFRS besides US GAAP.
Note
For each company code, the leading ledger adopts the same settings that apply to that company code such as fiscal year variant, PPV, and currencies. However, the nonleading ledger can have a different fiscal year and posting period variant from those assigned to the company code. Also, assignment of second and third local currencies to the nonleading ledger is optional.
Define the accounting principles by following IMG menu path Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Parallel Accounting > Define accounting Principles (Figure 4).

Figure 4
Define the accounting principles you are adopting
In this setting, as shown in Figure 4, the user needs to create keys for accounting principles being adopted for reporting. Because the accounting principles defined here are used by various other functions such as foreign currency valuation, and manual accruals, SAP advises that you not delete these principles once they are created. In this scenario, for example, it’s US GAAPs and IFRS. Assign the accounting principles to the leading and nonleading ledgers already defined. Follow IMG menu path Financial Accounting (New) > Financial Accounting Global Settings (New) > Ledgers > Parallel Accounting > Assign accounting principle to Ledger Groups (Figure 5).

Figure 5
Assign accounting principles to the leading and nonleading ledgers
In this setting, the accounting principles are assigned to the leading and nonleading ledgers. By virtue of this setting, documents that are assigned to a particular accounting principle are only posted to the assigned ledger. In this scenario, US GAAP can be assigned to the leading ledger and IFRS to the nonleading ledger.
Settings in the Asset Accounting Subledger (SAP FI-AA)
Define a real and a derived depreciation area for recording transactions in the SAP system that are related to fixed assets in accordance with the IFRS principle. These two depreciation areas are required exclusively for IFRS adjustment postings. Other depreciation areas cater to other specific reporting requirements for which they are created. For example, reporting as per a different accounting principle, reporting as per central/state tax laws, or reporting as per any other statutory requirements. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 6).

Figure 6
Define additional depreciation areas for IFRS reporting
Note
The settings shown in Figures 6 to 10 can be made in a one-time execution without leaving the transaction. For the purpose of identifying and explaining each setting, I have listed each setting in a separate figure. Selection of or setting up a chart of depreciation is one of the basic and required settings you carry out during the initial customization of FI-AA. I have concentrated only on the settings required for IFRS compliance in FI-AA. Hence, I assume that setting up a chart of depreciation has already been done and didn’t mention it separately.
Assign the nonleading ledger group (IFRS) to the two IFRS depreciation areas. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 7).

Figure 7
Assign nonleading ledger (IFRS) to the depreciation areas created for IFRS reporting
The book depreciation area (01) is always assigned to the leading ledger group. In this scenario, the leading ledger created for US GAAP is assigned to the book depreciation area.
Set the real depreciation area to adopt its values from the book depreciation area (01) and choose Area Posts Depreciation Only. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 8).

Figure 8
Define the real depreciation area for IFRS to post depreciation only
The two depreciation areas are created (one of them is real, the other one is derived) because of the following reasons:
- The real depreciation area is defined because you need a depreciation area that adopts acquisition and production costs (APC) and depreciation values from book depreciation area (01) and stores them in the database. They can be updated periodically as per IFRS requirements.
- The derived depreciation area is for calculating the delta between the book depreciation (01) and the real depreciation for IFRS and posting to the parallel ledger for IFRS to reconcile GL and FI-AA.
Note
Although you can define the derived depreciation area in a way to post both depreciation and APC, SAP recommends that you follow this approach as a best practice (i.e., define real dep. Area to post Depreciation Only and define derived dep. Area to post APC only).
Set the derived depreciation area to represent the difference between the book depreciation area (01) and the IFRS real depreciation area and choose Area Posts APC Only. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 9).

Figure 9
Define the derived depreciation area for IFRS to post APC only
For the derived depreciation area, specify that all values are allowed (i.e., both positive and negative values). Also, set the indicator that this derived depreciation area is treated as a real depreciation area as shown in Figure 10.

Figure 10
Define depreciation areas
The derived depreciation area is defined to accept both positive and negative values because this depreciation area represents the arithmetical difference between the two real depreciation areas (e.g., book dep. Area and real dep.area for IFRS). Hence, this arithmetical difference/adjustment to be posted to the IFRS parallel ledger can be either positive or negative.
The objective of setting the indicator Derived Depreciation Area as Real Area is to enable the derived depreciation area to post real differences in APC between book depreciation (01) and the real depreciation area for IFRS to the parallel ledger apart from posting of depreciation differences. Follow menu path IMG > Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 10).
Both IFRS depreciation areas (i.e., real and derived) use the same set of GL accounts as the book depreciation area (01). Create this setting by entering depreciation area 01 as the Different Depreciation Area that is used for account assignment. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Define depreciation areas (Figure 11).

Figure 11
Setting that ensures postings to the same set of GL accounts as used by book depreciation area
Note
A derived depreciation area is used so that the values of the asset subsidiary ledger are correctly reflected in General Ledger Accounting. The derived depreciation area triggers adjustment postings to keep the general ledger and subsidiary ledgers in sync. SAP ECC 6.0 also facilitates setting up depreciation areas for parallel valuation using a wizard. Follow IMG menu path Financial Accounting (New) > Asset Accounting > Valuation > Depreciation Areas > Set up areas for parallel valuation.
Define transaction types for IFRS postings. A transaction type is a key that is required to classify a business transaction in FI-AA (e.g., acquisition, retirement, or transfer) and determines how the transaction is processed in SAP. You are required to enter a transaction type for each posting activity that is relevant for asset accounting. Every transaction type is assigned to a standard transaction type group delivered by SAP, and it is not possible to change them or add new groups.
Create Z transaction types as a copy of transaction type 100 (external asset acquisition) and transaction type 101 (acquisition of negative asset). Follow IMG menu path Financial Accounting (New) > Asset Accounting > Transactions > Acquisitions > Define transaction types for acquisitions. You need to create Z transaction types because these transaction types need to be restricted or limited to only IFRS depreciation areas, unlike the standard transaction types (Figure 12).

Figure 12
Define transaction types for IFRS postings
Limit these Z transaction types to the IFRS depreciation areas (real and derived). Follow IMG menu path Financial Accounting (New) > Asset Accounting > Transactions > Acquisitions > Define transaction types for acquisitions (Figure 13).

Figure 13
Specify depreciation areas
Click Limit transaction types to depreciation areas (Figure 14). Then, select the desired transaction type that you already created and click Depreciation area specification on the left.

Figure 14
Limit transaction types to specified depreciation areas
Note
SAP has provided standard transaction types for common business transactions. It is also possible to define new transaction types based on the business requirements. The naming convention of the new user-defined transaction types must have x, y, or z at any position in the three-character transaction type key. This requirement prevents the user-defined transaction types from being overwritten during a release upgrade.
Harsh Mathur
Harsh Mathur is a senior consultant at Infosys Limited, a consulting and IT services major. By qualification he is a chartered accountant and a member of the Institute of Chartered Accountants of India. He carries 10 years of experience with expertise in SAP financials and controlling. He has worked on implementation, upgrade, and support projects for clients primarily in the high-tech industry.
You may contact the author at harsh1209@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.