Status

Owner
Stakeholders

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 order to meet group policy and regulatory compliance.

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

Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.


Background & Context

Explain the context in which the decision is being made.


Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 


Constraints

Capture any additional constraints that the chosen alternative (i.e. the decision made) might impose on other parts of the overall design, solution, or processes.


Impacts

Describe the impact of the decision on processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.


Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 


Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Option A: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly


Option B: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly


Option C: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly


Option D: Option Title

Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly


Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.



Option A

Option B
Option C
Option D
Criterion 1

(plus)Pro

(minus)Con

(plus)Pro

(plus)Pro

(plus)Pro

(minus)Con

(plus)Pro

(minus)Con

Criterion 2

(plus)Pro

(minus)Con

(minus)Con

(plus)Pro

(plus)Pro

(minus)Con

(minus)Con

Criterion 3(plus)Pro(minus)Con(minus)Con(plus)Pro

See also

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.


Change log

Workflow history