| Status | |
| Owner | |
| Stakeholders |
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. To mitigate the drawbacks 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:
There are two key decisions to be made with each considering two options described in detail in the “Options Considered” 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:
After considering two options, the recommendation is to go with option A (Multiple GAAP Ledgers, Mixed Valuation Ledgers) for both Decision 1 and Decision 2.
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:
The main technical benefits for Syensqo from following the proposed design recommendations are:
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.
It is recommended to set up the following currency types with the specified attributes as per below table to enable the implementation of the above recommendations:
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 the currency key of the base legal currency (company code currency). |
31 | Group Currency, Group Valuation | Group | 10 | Global | Must follow the currency key of the base legal currency (group currency). |
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:
For further background information on ledgers in S/4 HANA, please expand the below section:
a) Leading LedgerBy using the mandatory new G/L module in S/4 HANA, a customer has to decide which ledger shall be used as the leading ledger for its Financial Accounting processes. The leading ledger is defined at client level so it will be applicable to all Syensqo entities set up in the system. Only the leading ledger is connected by default to the Controlling module in S/4 HANA as entries made in non-leading ledgers are usually not relevant for Management Accounting. Controlling can read data from non-leading ledgers but can never write data into the non-leading ledger across all Controlling processes unless a new feature introduced in S/4 HANA Edition 2022, called Universal Parallel Accounting (UPA) is switched on. This is the subject of a dedicated KDD. Accounting interfaces with the Logistics modules or HCM, for example, are usually ledger-agnostic which means transactions triggering Financial Accounting postings from integrated modules are posted simultaneously in real-time across all active ledgers in a company code. By default SAP assigns ledger code ‘0L’ to the leading ledger. It is common practice to stick to this ledger code as it is widely recognized as the leading ledger code in official SAP documentations. It is however up to each customer to decide which accounting principle the leading ledger should follow (e.g. IFRS, Belgian GAAP, etc.). b) Non-leading LedgerNon-leading or parallel ledgers are optional to use in S/4 HANA. It is, however, widely used nowadays to serve primarily two purposes:
As indicated in the above statement, non-leading (standard) ledgers can have different fiscal year variants assigned from the leading ledger. The system therefore also allows customers to use a different posting period variant compared to the leading ledger as posting period cycles may differ between the two ledgers. Direct postings into the non-leading ledgers from an FI module are only feasible via the ledger-specific postings either in the General Ledger directly or via the Fixed Asset sub-module. Updates to the non-leading ledger figures only for AP, AR or any other Finance-integrated system module (e.g. Materials Management, Sales and Distribution) are not supported. |
For further background information on ledger types, please expand the below section.
a) Standard LedgersIn S/4 HANA, standard ledgers are distinguished from extension ledgers. In contrast to extension ledgers, standard ledgers have a life of their own and can therefore be considered as technically entirely independent ledgers. The leading ledger is always defined as a standard ledger. For non-leading or parallel ledgers a choice can be made to either set them up as a standard or an extension ledger. Standard ledgers can follow different fiscal year and posting period variants as opposed to the leading ledger. Subsequent implementations of standard ledgers require data migration activities. b) Extension LedgersExtension ledgers are typically used for scenarios where top-side adjustments are necessary. This may be required for tax reporting purposes, for example. Extension ledgers are reliant on underlying base ledgers. When reporting out of extension ledgers, the data from the underlying base ledgers will always be read along with any delta postings that were made specifically to the respective extension ledger as target ledger. As such, extension ledgers are technically not independent ledgers and therefore inherit not only the data but also the settings and configurations of the base ledgers with regard to fiscal year assignments and currencies. Extension ledgers can only be updated directly out of the General Ledger module. Exceptions to this rule are technical extension ledgers such as commitment update or sales prediction ledgers which cannot be posted to directly in general and receive its updates to the transactional figures via events triggered in the integrated Logistics modules (e.g. goods issue, goods receipts). The biggest advantage of extension ledgers are more technical in nature. The data footprint is drastically reduced as the majority of its data is coming from the underlying base ledger therefore saving database storage. The second key advantage is that an activation of extension ledgers does not require any data migration activities and can be done at any given point in time as data does not need to be rolled-up into the respective database tables. |
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.
As currency types are difficult and sometimes even impossible to change in a productive environment, it is important to activate the relevant and required currency types in the respective ledgers during the initial setup of a new S/4 HANA system. a) Fully-integrated FI currencies and Freely-defined CurrenciesIn S/4 HANA, we distinguish between fully integrated FI currencies (formerly known as local currencies 1, 2 and 3 in the old line item table BSEG) that are managed based on historic conversions in all integrated sub-modules (e.g. Fixed Asset Accounting and Controlling) and non-Finance modules (e.g. Material Ledger and Materials Management) and freely-defined currencies which are solely available in Financial Accounting and re-translated based on the defined currency translation rules at transaction stage therefore not keeping track of historical values of preceding transactions in end-to-end business processes (e.g. Fixed Asset capitalizations from settlement of WBS elements). The currency types activated for the leading ledger dictate what currency types can be used in the non-leading ledger - the currencies activated in the non-leading ledgers can only be a subset of the currencies activated in the leading ledger. Document currency, company code currency and controlling area currency are mandatory currency types for all ledgers.
b) Legal Valuation vs. Group Valuation vs. Profit Centre Valuation:In S/4 HANA, ledgers can store values of currency types following different valuation views. Posted amounts can either be stored based on a legal view for external reporting, based on a group-centric view where I/C profits and mark-ups are automatically eliminated by the system for relevant I/C transactions and can even help to eliminate intra-company profits charged for sales between business units (profit centres) within a single entity. Group valuation currency types are meant for managerial reporting primarily for the P&L and some parts of the balance sheet (e.g. inventory valuation) but cannot be directly used for consolidation and external reporting. The respective currency types can be identified by the second digit of the currency type code as follows:
Different valuation views can be combined in a single ledger but limitations apply for currency conversions. Please refer to section 'Options Considered' for further details. The relevant valuation views for Syensqo are further assessed in a separate KDD on Transfer Pricing ('KDD008 - Transfer Pricing') - please refer to this document for further details on the evaluation of relevant valuation views for Syensqo. |
Two decisions are required to be made as part of this design document. Options for both decisions are proposed separately.
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 the respective country. | |
LT* | LGAAP | Standard | - | Jan-Dec | Technical ledger to enable local GAAP accounting in Fixed Asset Accounting for countries with alternate FY variants. | Conditional: 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 |
* As explained by SAP in note 2220152 as the 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 | 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.
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 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 the 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:
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 a of the four key pillars aligning with the overarching project principles:
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. |
Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.
| Document |
|---|
| KDD - Transfer Pricing |
| KDD - Universal Parallel Accounting |
