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 according to different accounting standards/principles to comply with group policy and regulatory accounting rules.

In the past, SAP legacy systems such as SAP ERP with classic General Ledger Accounting 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 is 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 roll-outs.

Recommendation

Currency Types:

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

Ledgers and Currency Type Assignments:

The recommendation is to go with option A for both, the proposed ledger setup explained under section 'Options Considered' and the currency type assignments 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 needs to be considered in the decision making process on the ideal default ledger setup for Syensqo.

1.) Leading and Non-leading Ledgers:

a) Leading Ledger

By 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 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 unless a new feature introduced in S/4 HANA, edition 2023 called 'Universal Parallel Accounting' is switched on which is subject to another KDD document - please refer to this document for further details about this feature.

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 Ledger

Non-leading or parallel ledgers are optional to use in S/4 HANA. It is widely used nowadays to serve primarily two purposes:

1. Allow for different accounting treatments based on differing local GAAP standards compared to the leading ledger’s accounting principle.
2. Allow for reporting according to different fiscal year variants compared to the leading ledger

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.

Non-leading standard ledger postings do not update the Controlling module. By default, these ledgers are purely meant for external reporting and not for management accounting purposes. Any cost objects assigned to postings made to the non-leading ledger will be retained for statistical reporting purposes but will not trigger any updates of transactional data in the Controlling module.

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 are not feasible.

2.) Ledger Types

a) Standard Ledgers

In 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 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 it up as a standard or an extension ledger. Standard ledgers can follow different fiscal year and posting period variants than the leading ledger.

Subsequent implementations of standard ledgers require data migration activities.

b) Extension Ledgers

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 posted 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).

Extension ledgers are typically used for scenarios where top-side adjustments are necessary. This may be required for tax reporting purposes, for example. 

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 need not be rolled-up into the respective database tables.

3.) Currency Types

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 Currencies:

In 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 historic values of preceding transactions in end-to-end 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 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.

The relevant valuation views for Syensqo are further assessed in a separate KDD on Transfer Pricing - please refer to  for further details on the evaluation of relevant valuation views for Syensqo.

Assumptions

Constraints

Impacts

Business Rules

Options considered

Option A: 

Option B: 

Option C: 

Option D: 

Evaluation

	Option A	Option B	Option C	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

See also

Change log

Workflow history