Issue

Large multinational organisations with a global footprint such as Syensqo are typically required to report Financial Statements out of their main operational accounting systems with different accounting standards and principles in order to comply with internal group policy and regulatory accounting rules.

In the past, SAP legacy systems did not have a sophisticated solution to cater for parallel accounting requirements so, as a best practice model, an approach called account-based solution was widely adopted, amongst many other customers using classic G/L functionalities in SAP ERP also at Syensqo.

With the advent of the new General Ledger (later on referred to as new G/L) functionalities and the rise of globalization and IFRS as a commonly adopted reporting standard across the world, SAP has introduced the concept of ledgers to replace the outdated - and for many customers painful - account-based solution for parallel accounting to handle multi-GAAP reporting requirements for its customers.

Moving to S/4 HANA, the adoption of the new General Ledger is mandatory for all SAP customers. While not all features that new G/L Accounting offers are mandatory, the usage of at least one leading ledger and its currency types are mandatory. Besides the leading ledger which is typically used for keeping the books in accordance with the company’s group reporting standards and policies (e.g. IFRS for listed companies), SAP now offers additional parallel non-leading ledgers which can be used instead of the outdated account-based solution to keep books according to different GAAP valuation rules. 

Introducing additional (standard) ledgers and/or currency types for a particular ledger is a time-consuming process requiring smaller-scaled data migration projects. Activating ledgers also has process implications especially with regards to period-end activities as certain closing activities are ledger-specific so introducing additional ledgers may create additional workload for business users with limited benefits. As such it is advisable to establish design principles upfront on the default ledger setup for Syensqo entities in S/4 HANA and put forth guidelines to follow for future company code setups in the system.

The following two decisions shall therefore be made as part of this KDD:

1.) Default Ledger Setup in S/4 HANA

2.) Currency Types and Ledger Assignments

Recommendation

There are two key decisions to be made as part of this KDD, the default ledger setup (decision 1) and the definition of currency types and ledger assignments (decision 2). Each decision has multiple options - the recommendation for each decision is as follows:

a) Currency Types:

It is recommended to set up the following currency types with the specified attributes as per below table:

b) Ledgers and Currency Type Assignments:

The recommendation is to go with option A (Multiple GAAP Ledgers, Single Valuation Ledgers) for both required decisions, the proposed default ledger setup (Decision 1) explained under section 'Options Considered' and the currency type assignments (Decision 2) options laid out in the same section of this document.

For both configuration items, option A is the more future-proof and streamlined setup compared to option B with benefits clearly outweighing the drawbacks of the proposed design options.

Background & Context

Three key aspects need to be considered in the decision-making process on the ideal default ledger setup for Syensqo:

1.) Leading and Non-leading Ledgers

For further background information on ledgers in S/4 HANA, please expand the below section:

2.) Ledger Types

For further background information on ledger types, please expand the below section.

3.) Currency Types

For further background information on currency types, please expand the below section.

Assumptions

• Syensqo will move to a private-cloud S/4 HANA environment. This is important to call out as some configuration features for ledger and currency types are not available in public cloud environments.
• Best practice and roadmap design from SAP S/4 HANA Finance is followed to step away from an account-based solution towards a ledger-based solution for multi-GAAP accounting.
• Syensqo will not use an SDT conversion approach for migrating to S/4 HANA. New ledgers and additional currency types cannot be introduced during an SDT conversion from ECC to S/4 HANA in a standard migration scenario. SLO services are available for a conversion from an account-based solution to a ledger-based solution as part of an SDT conversion but require additional chargeable consulting services from SAP to be purchased.
• Translation of functional currency closing balances to the group’s presentation currency for consolidation purposes takes place in the consolidation system. S/4 HANA will provide accurate values for each company’s functional currency in legal valuation only.
• Transfer Pricing solution will be enabled in S/4 HANA. 
• The system design should allow for potential activation of UPA (Universal Parallel Accounting) in the future.

Constraints

• Should the Transfer Pricing solution not be enabled in S/4 HANA, the group valuation currency types become obsolete hence a revision of the proposed ledger setup and currency type assignment will be necessary.

Impacts

• Infrastructure/Basis: No impact.
• Security: No impact.
• Technical/ABAP: No impact.
• Data Migration: The data migration approach for  Finance transactional data needs to allow for introduction of new ledgers and currency types in the target system. The data needs to be migrated from local accounts (current parallel accounting approach) to the respective local ledgers (to-be parallel accounting approach) with enrichment of data for the newly introduced currency types.
  • Migration of material masters and stock balances will require extra attention due to the recommended implementation of dual valuations for the IFRS ledgers.
• Data Cleansing: No impact but data in the respective accounts for IFRS as well as LGAAP accounting shall be brought on in a tidy state with a minimal amount of open items.

Business Rules

1.) The company code currency of a company (currency type 10) must follow its functional currency.

2.) The hard currency of a company code shall follow the country currency if the country currency is not defined as an entity’s functional currency. This is to allow for accurate tax accounting and reporting in country currency.

3.) Accounting principles for the local GAAP ledger need to be defined for every country separately to pave the way for a future seamless deployment of UPA (see note 3191636 for further details).

Options considered

Two decisions are required to be made as part of this design document. Options for both decisions are proposed separately.

Decision 1 - Default Ledger Setup for S/4 HANA company codes:

Option A: Leading IFRS Ledger & Mandatory Standard Non-Leading Ledger for local GAAP Accounting & 2 separate Extension Ledgers for Tax Accounting and Commitment Updates

In this design option, a non-leading ledger for local GAAP accounting and Tax Accounting is mandated besides the mandatory leading ledger for all operational Syensqo entities set up in the system. 

Should an entity not require a local GAAP ledger currently because of identical accounting treatments between IFRS and their local GAAPs, the idea is to still activate the ledger but set it up in the same way as the leading ledger so month-end activities need not be performed for this ledger by the responsible departments. This makes the ledger setup for each Syensqo entity streamlined, future-proof and scalable with minimal disruptions and additional workloads for the business users at period-end.

For management of commitments from the Materials Management module, a technical extension ledger is also recommended to be added to the base ledger setup in this option to follow SAP’s target design for Commitment Management in S/4 HANA.

Proposed setup:

Option B: Leading IFRS Ledger & Optional Standard Non-Leading Ledger for local GAAP and Tax Accounting & Mandatory Extension Ledger for Commitment Updates

In this option, the usage of the non-leading ledgers for local GAAP and Tax Accounting is not mandated. The usage of local GAAP and Tax ledgers can be decided on by the respective Finance country managers. The decision to use or not use local GAAP ledgers must be taken at country level as Chart of Depreciations in the Asset Accounting module are defined and harmonised at country level. Depreciation areas set up in each Chart of Depreciation are linked to ledgers via accounting principles. All company codes sharing the same Chart of Depreciation are therefore required to also have the same set of ledgers set up in Financial Accounting.

For management of commitments from the Materials Management module, a technical extension ledger is also recommended to be added to the base ledger setup in this option to follow SAP’s target design for Commitment Management in S/4 HANA.

Proposed setup:

Decision 2 - Currency Type Assignments in Ledgers:

Option A: Single Valuation Ledgers with two parallel currencies

The idea behind this option is to keep separate ledgers for each valuation view. 

The leading ledger (0L) will be kept for legal valuation only while a non-leading, parallel ledger (0G) is introduced to capture the value flows in group valuation view.

For local GAAP, Tax as well as Commitment reporting only legal valuation figures are relevant hence group valuation currency types are not required in the respective ledgers. 

Proposed setup:

• Ledger 0L will be reserved for currency types representing legal valuation views thereby following IFRS valuation principles.
• Ledger 0G will be reserved for currency types representing group valuation views thereby following IFRS valuation principles.
• Currency types 10 and 30 are fixed and cannot be changed for all ledgers for data integrity reasons. For ledger ‘0G’ currency types 10 and 30 will automatically be replaced with the corresponding group valuation currency types ‘11’ and ‘31’.
• Accurate global P&L reporting in group currency is possible out of the group valuation ledger ‘0G’ with I/C profits eliminated in real-time. Unless currency type 11 will be activated as a material-ledger currency, currency type 11 may not be accurately reflecting group valuation value flows which is also not required in local currency typically. Technically currency type 11 must be enabled in the system if group valuation views are used in the system (see SAP note 2882025).
• For inventory accounts, the difference between currency type 30 (legal valuation) in ledger ‘0L’ and currency type 31 (group valuation) in ledger ‘OG’  can be used as the basis for the profit in stock elimination posting performed in BFC.
• For statutory reporting, accurate P&L as well as B/S reporting will be possible out of the LGAAP ledger ‘LG’ in the functional currency of the entity (currency type 10).
• The closing balances from the leading ledger (‘0L’) in currency type 10 (functional currency) will be extracted and imported into BCF at period-end for consolidation purposes. 
• The tax ledger (‘0L’) will inherit the currency settings from the underlying local GAAP base ledger (‘LG’). As such, tax adjustments can only be made to legal valuation views for statutory tax filings.

Option B: Mixed Valuation Ledgers with three fully-integrated FI currencies & two freely-defined currencies

In this option, the idea is to combine currency types from legal and group valuation into one single ledger. This reduces the storage requirements as well as the time and efforts involved in closing operations. 

Proposed setup:

• Currency types 10 and 30 are fixed and cannot be changed for data integrity reasons.
• As per SAP recommendation, all currency type defined in the Currency & Valuation profile maintained at Controlling Area level should be set up as fully-integrated FI currency therefore LC3 is in this option reserved for currency type 31. This is to ensure that historic values are stored in integrated modules with lifecycles (e.g. Fixed Asset Accounting) and subsequent computations of dependent transactions (e.g. Depreciation) are based on historic values.
• The P&L for currency type 31 will consequently always be valuated at spot rate except for Fixed Asset-related transactions where the P&L postings will be a proportionate value based on historic costs. This will give the group controller an accurate view of the global group P&L which has I/C profits eliminated.
• For statutory reporting, accurate P&L as well as B/S reporting will be possible out of the LGAAP ledger ‘LG’ in the functional currency of the entity (currency type 10).
• The closing balances from the leading ledger (‘0L’) in currency type 10 (functional currency) will be extracted and imported into BCF at period-end for consolidation purposes.
• Balance sheet translation to presentation currency will be carried out in BFC as part of the consolidation process. 
• For inventory accounts, the difference between currency type 30 (legal valuation) and currency type 31 (group valuation) can be used as the basis for the profit in stock elimination posting performed in BFC.
• Freely-defined currencies 11 and 31 need to be added for technical reasons. Currency type 11 may not be accurate in all cases though as different conversion rules apply for freely-defined currencies which are not always compatible with translation rules stipulated in IAS21 so they are just indicative figures.

The main drawbacks of this option are two-fold:

1. Universal Parallel Accounting (UPA) does not support the use or migration of multi-valuation ledgers once activated which constitutes a potential roadblock for future activation of UPA.
2. The leading group valuation currency type occupies a fully integrated FI currency with the other two fully integrated currencies available in the system already defaulted by the system in a non-editable way. Should there be a need in a specific entity or country to report.

Evaluation

The below table provides a summary of the pros and cons of each option explained in the above section for both key design decisions and how each option scores  with view to the below four key pillars of the overarching project principles:

• Standardisation
• Simplification
• Future-Proof
• Process Discipline

See also

Glossary

Change log

Workflow history