| Status | Approved |
| Owner | |
| Stakeholders |
Issue
In the past, Syensqo adopted the 'account approach' to deal with multi-GAAP accounting and reporting requirements. The account approach is based on different sets of General Ledger accounts within the operational Chart of Accounts representing the respective valuation principle which creates complications at period-end for Finance users to attain accurate statutory accounts for local reporting. It also leads to increased overhead in the system from a maintenance perspective as additional master data and system configurations need to be put in place to facilitate reporting based on local GAAP accounts.
SAP has meanwhile introduced the concept of ledgers to replace the outdated - and often inefficient - account-based solution for parallel accounting to handle multi-GAAP reporting requirements for its customers which should be considered in every new S/4 HANA implementation.
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 and currency type setup for Syensqo entities in S/4 HANA and put forth guidelines to follow for future company codes set up in the system.
The following two decisions shall therefore be made as part of this KDD:
- Default Ledger Setup in S/4 HANA
- 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:
Currency Type | Description | Valuation | Translation from Currency Type | Global/ Local Setting | Rule |
|---|---|---|---|---|---|
00 | Document Currency | - | - | Global | |
10 | Company Code Currency, Legal Valuation | Legal | 00 | Global | Must follow functional currency of company code. |
30 | Group Currency, Legal Valuation | Legal | 10 | Global | Group Currency should be translated from the functional currency as per IAS21. |
11 | Company Code Currency, Group Valuation | Group | 00 | Global | Must follow currency key of base legal currency (company code currency). |
31 | Group Currency, Group Valuation | Group | 10 | Global | Must follow currency key of base legal currency (group currency). |
b) Ledgers and Currency Type Assignments
The recommendation is to go with option A (Multiple GAAP Ledgers, Mixed Valuation Ledgers) for both required decisions, the proposed default ledger setup (Decision 1) explained under section 'Options Considered' in this paper 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.
The main business benefits for Syensqo from following the proposed design recommendations are
- Multi-GAAP accounting and reporting in real-time based on IFRS and local GAAP reporting requirements without manual adjustments.
- Additional separate tax ledger allowing for adjustments to statutory accounts for tax calculations and reporting.
- Ability to report accurate margins according to different valuation views in real-time (legal and group).
- Leaner operational Chart of Accounts.
- Ledger design supports unified global process designs for IFRS as well as local reporting.
The main technical benefits for Syensqo from following the proposed design recommendations are
- Future-proof ledger design in line with SAP target designs (e.g. UPA readiness)
- Ledger design and currency types in line with best practice setup in the EML systems (apart from group valuation ledger/currency types which are not activated in the EML landscape)
- Low probability of additional ledger requirements in the future which would require IT support
- Streamlined ledger and currency setup allowing for easier governance and reduced maintenance efforts from an IT perspective.
- Reduced maintenance efforts from leaner Chart of Accounts (e.g. account determinations for local accounts no longer required).
Although this decision technically reduces the number of accounts in the system, the net result of the combination of the multiple ledger and multiple currency types approaches means that flexibility in management and compliance reporting is actually enhanced over Syensqo's account-based setup in ECC.
Background & Context
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, Syensqo used the 'account approach' for this purpose which has been replaced by a new 'gold' standard in S/4 HANA commonly known as 'ledger approach' which allows a company to run multi-GAAP ledgers concurrently in the system.
For Syensqo, this means that local GAAP reporting can be performed in real-time in the future out of a parallel ledger following local GAAP valuation rules without a need for any adjustment or reclassification postings at period-end. The system will be able to produce zero-balanced local GAAP Financial Statements at any given point in time. At the same time, it gives Syensqo the opportunity to further consolidate and rationalize their operational Chart of Accounts. Local accounts used for multi-GAAP reporting in the current account-based solutions are creating a larger data footprint in the system (15-25% of all G/L accounts used in the current operational CoAs are local accounts) that is no longer needed in S/4 HANA.
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
Currently, Syensqo is only able to generate a global view of P&L results for the period with I/C revenue and COGS eliminated at period-end in the consolidation system. By using group valuation currency types besides the mandatory legal valuation in S/4 HANA, group controllers can get instant insights into the global P&L in real-time out of the operational accounting system.
For further background information on currency types, please expand the below section.
Assumptions
- Syensqo will move to a private-cloud S/4HANA environment. This is important to call out as some configuration features for ledger and currency types are not available in public cloud environments, and is also covered in a separate KDD.
- Best practice and roadmap design from SAP S/4HANA 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/4HANA. New ledgers and additional currency types cannot be introduced during an SDT conversion from ECC to S/4HANA 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/4HANA will provide accurate values for each company’s functional currency in legal valuation only.
- Transfer Pricing solution will be enabled in S/4HANA.
- The system design should allow for potential activation of UPA (Universal Parallel Accounting) in the future.
- As part of the detailed design phase of the SyWay program, most suitable options to potentially cater for US GAAP compliance for financial reporting were explored should this be required shortly after or even before the go-lives of the S/4 HANA systems. The recommended approach to facilitate US GAAP reporting in USD out of Group Reporting has been endorsed by key financial stakeholders of the organization (refer to the presented slide deck for further details). As such, there is no direct impact to the ledger and currency design in S/4 HANA from this decision. Should a primary listing in the US unexpectedly occur before go-live, the ledger design proposed in this KDD will need to be revisited.
Constraints
- Should the Transfer Pricing solution not be enabled in S/4HANA, 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
- The company code currency of a company (currency type 10) must follow its functional currency.
- 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.
- 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 SAP 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:
Ledger | GAAP | Leading | Ledger Type | Base Ledger | Fiscal Year | Purpose | Remark |
|---|---|---|---|---|---|---|---|
0L | IFRS | X | Standard | - | Jan-Dec | Group Reporting, Legal View | Mandatory |
LG | LGAAP | Standard | - | Jan-Dec or alternate FY variant. | Statutory Reporting | Mandatory: Same configuration for LG as for 0L if no LGAAP is required in respective country. | |
LT* | LGAAP | Standard | - | Jan-Dec | Technical ledger to enable local GAAP accounting in Fixed Asset Accounting for countries with alternate FY variants. | Condiitional: Only mandatory in countries with alternate FY requirements for statutory reporting (e.g. India) | |
TX | LGAAP | Extension | LG | Following LG | Tax Reporting | Mandatory | |
CO | IFRS | Extension | - | Jan-Dec | Commitment Reporting / Predictive Sales Reporting | Mandatory |
* Explained by SAP in note 2220152 as only possible option in S/4 HANA to handle parallel accounting with different fiscal year variants across multiple ledgers in Fixed Asset Accounting.
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:
Ledger | GAAP | Leading | Ledger Type | Base Ledger | Fiscal Year | Purpose | Remark |
|---|---|---|---|---|---|---|---|
0L | IFRS | X | Standard | - | Jan-Dec | Group Reporting, Legal View | Mandatory |
LG | LGAAP | Standard | - | Jan-Dec or alternate FY variant. | Statutory Reporting | Optional | |
LT* | LGAAP | Standard |
| Jan-Dec | Technical ledger to enable local GAAP accounting in Fixed Asset Accounting for countries with alternate FY variants. | Conditional: Mandatory in countries with alternate FY requirements for statutory reporting (e.g. India) | |
TX | LGAAP | Extension | LG | Following LG | Tax Reporting | Optional | |
CO | IFRS | Extension | - | Jan-Dec | Commit ment Reporting | Mandatory |
* Explained by SAP in note 2220152 as only possible option in S/4 HANA to handle parallel accounting with different fiscal year variants across multiple ledgers in Fixed Asset Accounting.
Decision 2 - Currency Type Assignments in Ledgers:
Option A: 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:
| Fully-integrated FI Currencies | Freely-defined Currencies | ||||||||||||||
| Ledgers | Accounting Principle | Valuation View | LC1 | LC2 | LC3 | FC1 | FC2 | FC3 | FC4 | FC5 | FC6 | FC7 | FC8 | FC9 | FC10 |
| 0L | IFRS | Mixed | 10 | 30 | 31 | 11 | 31 | ||||||||
| LG/LT | Local GAAP | Legal | 10 | 30 | |||||||||||
| CO | IFRS | Mixed | 10 | 30 | 31 | 11 | 31 | ||||||||
| TX | Local GAAP | Legal | 10 | 30 | |||||||||||
Please refer to the below section for further detailed explanations:
The main drawbacks of this option are:
- The leading group valuation currency type (currency type 31) occupies a fully integrated FI currency with the other two available fully integrated currencies being defaulted by the system design in a non-editable way. Should there be a need in a specific entity or country to report taxes, for example, in a different currency than the entity's functional currency directly out of the system there is no currency type left to support this requirement. At present, this situation does not exist at Syensqo. Should it become a requirement along the way, custom developments may be required for accurate tax reporting in such situations.
Option B: 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:
| Fully-integrated FI Currencies | Freely-defined Currencies | ||||||||||||||
| Ledgers | Accounting Principle | Valuation View | LC1 | LC2 | LC3 | FC1 | FC2 | FC3 | FC4 | FC5 | FC6 | FC7 | FC8 | FC9 | FC10 |
| 0L | IFRS | Legal | 10 | 30 | |||||||||||
| 0G | IFRS | Group | 11 | 31 | |||||||||||
| LG/LT | Local GAAP | Legal | 10 | 30 | |||||||||||
| CO | IFRS | Legal | 10 | 30 | |||||||||||
| TX | Local GAAP | Legal | 10 | 30 | |||||||||||
Please refer to the below section for further detailed explanations:
The main drawbacks of this option are:
- Fixed Asset Accounting can not be integrated with the group valuation ledger (refer to SAP note 255492 for further details). Without dedicated depreciation areas in Fixed Asset Accounting, acquisition costs cannot be tracked historically and periodic depreciation will therefore be inaccurate over time. This may affect the group valuation price calculated for all standard price materials by the product costing processes.
- The project cost settlement process at period-end which will be used for all CAPEX purchases in the to-be solution is not able to settle historic group costs captured in the group valuation ledger. A Proof-of-Concept study was carried out during conceptual design where this limitation was further evaluated and it was observed that Fixed Asset costs in the group valuation ledger will be capitalized based on legal historic costs leading to inaccuracies in the depreciation calculations. This inconsistent system behavior was also further investigated by SAP product owners who concluded that this is an unsupported settlement scenario in SAP standard and emphasized that no fix will be provided to address this product constraint. Recommended workaround from SAP is a mixed valuation ledger. Please refer to the slide pack prepared as part of the PoC study for further details.
- Universal Parallel Accounting (UPA) does not support a transactional data migration of values from single valuation ledgers into UPA-active ledgers which constitutes a potential roadblock for future activation of UPA.
- The business function to calculate COGS (FIN_CO_COGM) based on the non-leading local GAAP ledger, which may be required to efficiently comply with regulatory requirements in certain countries, technically necessitates a mixed valuation ledger setup for the underlying non-leading ledger for data integrity reasons.
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: Process designs should be standardized across the organization wherever this is operationally possible and practical. Solution designs should be standardized, ideally leveraging on SAP standard technology.
- Simplification: Process designs should be easy to understand and execute for the users with a primary focus on getting the basics right.
- Future-Proof: The process and solution design should pave the way for future product innovations from SAP and should be forward-looking to allow for easy adoption of expected product improvements and innovations.
- Process Discipline: Exceptions, workarounds and off-system work routines and procedures should be avoided by implementing simple global process designs that foster process discipline and in-system work routines across the organization.
Decision 1 - Default Ledger Setup | Decision 2 - Currency Type Assignment | Remarks | |||
|---|---|---|---|---|---|
Pros & Cons/ Project Principles | Option A Mandatory: Leading (IFRS), Local (LGAAP), Tax and Commitment | Option B Mandatory: Leading (IFRS), Commitment Optional: Local (LGAAP), Tax | Option A Mixed Valuation Ledger | Option B Single Valuation Ledger | |
| Pros and Cons |
|
|
|
|
|
Standardization | High | Medium | High | Low | For both decisions, option B will lead to a lower score in terms of standardization. While it leads to a lower process standardization for decision 1, option B will also require complex customization of SAP standard to deliver accurate results for integrated margin reporting which is the main reason for the low score of option B in decision 2. |
Simplification & Operational Efficiency | Medium | High | High | Medium | Due to the additional (optional) period-end activities option A has a slightly less favorable score compared to option B for decision 1. For decision 2, the medium score for option B can be explained by the additional mandatory period-end activity for costing purposes and the potential need for additional reconciliation due to reporting inaccuracies. |
Process Discipline & Ease of Reporting | High | Medium | High | Low | For decision 1, option B may foster the use of offline calculations and off-system reporting for local GAAP and tax accounting purposes which can lead to complications during audits. For decision 2, the low score is caused by the fact that accurate integrated margin and profit-in-stock reporting cannot be guaranteed in SAP standard and would require complex customization. |
| Future Compatibility | High | Low | Medium | Low | The low score on this evaluation criterion for option B in decision 1 is driven by the need for additional data migration activities should a non-leading ledger be required due to changes in accounting policies for countries without a local GAAP ledger. For decision 2, the low score of option B can be attributed to the lack of a migration path to UPA with a single valuation ledger setup. As per latest information received from SAP, this migration scenario is not supported currently and not foreseen to be enabled in the future (see incident 1997441/2024). The medium score for option A in decision 2 can be explained by the full use of all integrated currency types available in SAP standard in this option. Should there be a need for an additional integrated currency type in the future (not foreseen currently), customization of SAP standard may be required. |