Issue

Succinctly describe the issue or problem statement that this Decision addresses. Why is a decision required? What business or technical problem does it address?

Syensqo is currently operating in a multi-system SAP landscape which is the result of acquisitions of organizations with separate SAP systems and legacy decisions to keep separate SAP systems for confidentiality reasons (e.g. WPX for classified information of materials used in the defense industry, PI1 to ring-fence access to data and transactions pertaining to in-house banking). This has lead to disparities between the two systems in terms of Finance master data in use across the various systems, most notably on key master data objects such as Chart of Accounts or Cost Centres and Profit Centres.

With a move to a single SAP system, opportunities arise to harmonize master data from the various systems and define new master data frameworks and associated governance rules to ensure that all master data objects follow a single design and purpose in the new system with the goal of increasing transparency, efficiency and accountability across the organization.

In this KDD recommendations will be provided for the following three critical Finance master data objects:

1.) Chart of Accounts

2.) Profit Centres and Profit Centre Hierarchies

3.) Cost Centres and Cost Centre Hierarchies

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.

Multiple Finance master data objects do not follow a consistent and unique master data governance design and approach across the organization due to its diverse system landscape which has grown over time from acquisition activities as well as special requirements with regards to data confidentiality. As part of the transition to S/4 as a single system-of-records, the following master data objects have been identified as potential candidates for further rationalisation and simplification:

Chart of Accounts

As part of the transition to S/4 HANA, a single controlling area will be introduced for all Syensqo entities operating in S/4 HANA. To subsume multiple entities under one controlling area in SAP, all company codes need to be using the same operational Chart of Accounts in the system. With this constraint an opportunity arises to consolidate and simplify the operational Chart of Accounts and re-design the CoA in such a way that it can - in the long run - also be used as a group CoA.

A single operational Chart of Accounts resembling the consolidated group Chart of Accounts which can be used across all Syensqo entities globally can lead to potential benefits such as

• Reduced Reconciliation Efforts: A single operational Chart of Accounts which uses the group Chart of Accounts as the baseline helps to reduce reconciliation efforts across all teams involved in Financial Accounting processes end-to-end ranging from operational to management to group and statutory reporting teams, everyone is working with the same or vastly similar set of base data which doesn't require additional mappings or other aggregation methods to be understood by the various teams involved at the various levels of the Financial reporting chain.

• Time Savings at Period-End: At period-end where time is of essence, time-savings can be realized by the reduced need for mappings and data aggregations to lift Financial data from the operational accounting system up into the consolidation engine for consolidated group reporting purposes. Again, reduced reconciliation efforts across the various teams from the largely unified data sets are expected to lead to time gains at period-end.

• Unified Process Views: Across the organization, a single set of G/L accounts will lead to unified process views globally. Accountants will have a consistent view of process results as G/L accounts used in the processes serve one and the same purpose globally across all Syensqo entities set up in S/4 HANA.  Governance rules will be defined which will help to keep the accounts set up in a streamlined way across the organization supporting global process designs.

• Lower Administration Efforts: The administration efforts to maintain G/L account master data are expected to decrease from using a single operational Chart of Accounts. G/L accounts are defined and managed centrally with a single governance strategy applicable to all Syensqo entities operating in S/4 HANA.

• Cleansed Accounts: A higher degree of cleansed accounts and books can be expected from a single operational Chart of Accounts that is managed centrally. Critical account control settings such as open item management or account currency settings that can heavily influence the data hygiene on G/L accounts will be set and monitored centrally.

Introducing a new Chart of Accounts across an organization requires thorough review of group, legal and process requirements to ensure that the Chart of Accounts as the backbone of each Financial Accounting system-of-records is suitable to cater for all reporting as well as technical integration needs in a highly-integrated system environment.

The introduction of the universal journal ledger (single-source-of-truth database table for Financial Accounting) in S/4 HANA has opened up new avenues for Financial reporting based on auxiliary reporting dimensions besides the G/L account to differentiate the nature of the Financial transaction. Actual disclosure requirements on the face of Financial Statements either at group or statutory level should now be the guiding principle for creating G/L accounts in the operational Chart of Accounts (besides the mandatory accounts for technical integration of the various system components) while all other reporting requirements previously met through dedicated G/L accounts in the operational CoA should be revisited as the additional reporting attributes now available in the universal journal ledger in S/4 HANA may serve the respective purpose and can therefore be used alternatively for Financial Reporting.

Furthermore, the advent of the ledger solution replacing the outdated account-based approach for dealing with multi-GAAP/parallel accounting requirements makes local accounts in the operational CoA for the sake of parallel accounting redundant. In the current operational CoA used in PF1, for example, local accounts contribute approximately 25% to the overall data footprint of the operational Chart of Accounts kept in the system which could be eliminated to a large extent by a move to a single operational CoA in S/4 HANA.

The current operational Chart of Accounts used in the main operational SAP systems PF1 and WP1 are very different with regards to their architecture and numbering conventions. Both of them have a significant amount of active G/L accounts with PF1 standing out with a total count of >13,000 G/L accounts. This high number of G/L accounts is primarily driven by two factors, local accounts on the one hand accounting for roughly 25% of the overall count and Treasury-related G/L accounts accounting for roughly 35% of the total count on the other. In WP1, the situation is similar with local accounts contributing 15% to the total count and Treasury-related accounts again making up roughly 35% of the overall account. The high number of Treasury-related accounts in both systems is primarily caused by the complex in-house bank setup at Syensqo which may be revisited in S/4 HANA.

The current group Chart of Accounts is lean with approximately 170 real group accounts. Additional disclosure items are computed and aggregated positions calculated on the back of the group account balances. Its primary purpose is to support external IFRS and internal consolidated management and cost reporting. The structure of the group CoA is clearly segregated based on the disclosure requirements, the codification logic follows an alphanumeric pattern with clear segregation between P&L and B/S via a unique alphabetic character used as a prefix but overlapping number range intervals between P&L and B/S for the numeric part of the group account number - see below screenshot for some examples of the current codification logics used in the group CoA:

Due to the overlapping account number ranges it may not be a suitable baseline for a new operational Chart of Accounts with intuitive numbering conventions in S/4 HANA which resembles the numbering conventions of the current group Chart of Accounts. With the move to a new consolidation system in S/4 HANA at some stage, an opportunity arises to design a new group CoA as well and it should be considered during the detailed design of the consolidation deployment phase to potentially adopt the operational CoA as the group CoA for the aforementioned reasons. Attempts will be made to design the new operational CoA in S/4 HANA in such a way that it also meets the needs of group and management reporting allowing for a seamless future use as the common group CoA once the new consolidation system is put in place.

Profit Centres and Profit Centre Hierarchies:

Cost Centres and Cost Centre Hierarchies:

The implementation of an effective cost center hierarchy is crucial for accurate financial reporting, cost control, and efficient allocation of resources within an organization. This proposal outlines best practices for creating an SAP cost center hierarchy that aligns with organizational objectives, supports strategic decision-making, and enhances financial transparency. The objective of a uniform cost center structure are the follwing

• Enhance Financial Reporting: Enable detailed and accurate financial reporting at various organizational levels.
• Improve Cost Control: Facilitate better tracking and management of costs.
• Support Strategic Decision-Making: Provide insights to support budgeting, forecasting, and strategic planning.
• Streamline Operations: Ensure efficient allocation and utilization of resources.
• Compliance and Auditability: Maintain compliance with internal and external reporting standards and facilitate audits.

Best Practices for Cost Center Hierarchy:

1. Define Clear Organizational Structure

• Align with Business Units: The cost center hierarchy should reflect the organizational structure, aligning with business units, departments, and functions.
• Hierarchy Levels: Establish multiple levels in the hierarchy, such as corporate, division, department, and sub-department, to ensure granularity and detailed reporting.

2. Standardization and Consistency

• Naming Conventions: Use consistent and descriptive naming conventions for cost centers to facilitate easy identification and avoid ambiguity.
• Coding Structure: Implement a standardized coding structure that reflects the hierarchical levels and organizational alignment.

3. Flexibility and Scalability

• Modular Design: Design the hierarchy to be modular, allowing for easy additions or modifications as the organization grows or changes.
• Adaptability: Ensure the structure can adapt to organizational changes such as mergers, acquisitions, or restructurings without significant disruptions.

4. Integration with Financial Processes

• Budgeting and Forecasting: Align cost centers with budgeting and forecasting processes to support accurate financial planning.

Proposed SAP Cost Center Hierarchy Structure:

• • Direct production
  • Indirect production
  • SCM
  • R&D
  • Sales 
  • Marketing 
  • Administration

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. 

• The new S/4 HANA system will be either on-prem or private cloud edition.
• Decision will be made to move away from account-based solution towards a ledger-based solution for multi-GAAP accounting in S/4 HANA.
• In-house bank setup and design will be revisited functionally in S/4 HANA.

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

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

• Consolidation: New mapping rules required to be set up in SAP BFC for upload of operational accounting data from S/4 HANA into the consolidation system.
• Data Migration: Account mappings between the old G/L account numbers from legacy ECC systems and new account numbers from S/4 HANA will need to be established.

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

Decision 1 - Chart of Accounts:

Option A: Introduce new operational CoA in S/4 HANA

In this option, a new operational CoAs shall be designed and introduced in S/4 HANA with the following objectives:

• CoA design shall support and facilitate reporting at operational, statutory, management and group level without a need for extensive mappings or reconciliations at period-end.
• Create an intuitive and consistent architecture and numbering convention in the CoA for an enhanced ease of use.
• Reduce number of G/L accounts used across the organization for unified process views.

Option B: Retain operational CoA from legacy ECC system

In this option, one of the currently used operational CoAs in the SAP systems shall become the operational CoA in S/4 HANA. 

Decision 2 - Profit Centres and Profit Centre Hierarchies:

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

Decision 3 - Cost Centres and Cost Centre Hierarchies:

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

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.

	Decision 1 - Chart of Accounts
	Option A -  Introduce new operational CoA in S/4 HANA	Option B -  Retain operational CoA from legacy system	Option C	Option D
Pros and Cons	Standardise use of accounts across all Syensqo entities Supports global process designs and unified process views across the organization Opportunity to design new CoA with intuitive codification logic and consistent architecture Opportunity to design new CoA that can potentially become group CoA in the new consolidation tool in S/4 HANA Reduced reconciliation efforts and time savings at period-end due to standardized CoA across all levels of the organization Opportunity to design new CoA considering administration and IT maintenance aspects (e.g. CoA must be scalable without extra configuration requirements from IT). Mappings required for data migration and consolidation in BFC Change impact for entities migrating to S/4 HANA needs to be managed	Limited change impact as operational CoA will remain the same for some entities migrating to S/4 HANA. Constraints apply with regards to restructuring options in S/4 HANA as most account ranges are already used/occupied. Local GAAP G/L accounts no longer required in S/4 HANA. Current CoAs not suitable for future adoption as group CoA as it's too granular. Mappings required for data migration.	Pro Con	Pro Con
Standardisation	High	High	Pro Pro	Con Con
Simplification	High	Medium	Con	Pro
Future-Proof	High	Low
Change Management	Low	Medium

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