Glossary

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 in the past (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 (CoA)

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.

The transition to a single SAP S4 system presents a significant opportunity for Syensqo to harmonize and optimize its Finance master data objects.  By designing a new operational CoA, Cost Centre, and Profit Centre structures, Syensqo can achieve:

• Improved standardization,
• To facilitate compliance with international financial reporting standards and align with best practices
• simplification and future-proofing of its financial processes and reporting
• Reduced reconciliation efforts and time savings at period-end closing
• and a more unified global process view, thereby enhancing efficiency and accountability. 

While the transition may initially be complex and resource-intensive, the long-term advantages far outweigh the temporary disruptions.  Therefore, it is strongly recommended that Syensqo adopts Option A: the introduction of new operational CoA, Cost Centre, and Profit Centre structures in S/4. 

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 - potentially 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 Centers and Cost centers 

In the paragraphs below, we provide a brief overview of the current profit and cost center structure in the two systems and propose guidelines for the future design. It should be noted that the final structure and codification logic will be defined during the detailed design phase, utilizing the guidelines proposed in this key design document.

Provided that we will utilize segments as well, the structures should be defined as one segment having many profit centers and one profit center having many cost centers, resulting in a 1:N relationship between these objects. The cost center group will represent a collection of cost centers for reporting, and similarly, the profit center group will represent a collection of profit centers.

According to wiki, there are 2 types of profit centers in PF1 currently: 

1. Reporting profit centers

In PF1, the determination of the business structure is done in the P&L using a reporting profit center that is in the COPA posting.  To make this everything works (through interfaces):

• All material codes should be assigned to a reporting profit center (in the view "costing 1")
• All objects in CO should be assessed to a profit center in COPA 

2. Organizational profit centers

All CO objects (cost centers, orders, WBS) are assigned to a non reporting profit center.

PF1 follows the single controlling area model. The business structure is supported by custom tables for further derivations and consolidated reporting.  

Current profit center structure WP1:

According to wiki, in WP1 the profit center is used to: 

Assign the following variances to the P&L (COPA)

• Variances on purchase
• Inventory differences
• Variances on transfer
• Variances on process order
• Revaluation variances

Split the Working Capital

Calculate some indicators of the industrial dashboard and identify by Value Stream.

In WP1 there several controlling areas. In particular there are four controlling areas by Region (Europe, APAC, North America, South America) plus one for Financial companies, total five controlling areas. Like in PF1, the business structure is supported by custom tables for further derivations and consolidated reporting.  

Key Considerations for future profit centers structure 

1. Standardization: A common and uniform profit center structure that will be active for all the company codes in scope. 
2. Scalability: Ensure the hierarchy can be easily expanded as Syensqo grows. Flexible structures to adapt to business changes quickly.
3. Reporting: Profit centers should facilitate profitability analysis.
4. Management Control: Enable effective management control and decision-making across different levels.

5. Real-time Reporting and Analytics: Leveraging S4 for real-time profit center reporting and analytics.

6. Compliance and Governance: Ensuring structures comply with international financial reporting standards (IFRS, GAAP).

Structuring cost centers, profit centers, and segments is crucial for accurate financial reporting. These profit centers will remain flexible for modification and restructuring as the company grows or adopts new approaches for its Business units. This basic proposal balances centralized control with decentralized operations, empowering local entities while maintaining overall oversight. We also considered the current BFC reporting structure, which includes dimensions like business units, specific activities, and groups of activities. However, it is important to note that the final proposal will be part of the detailed design process.

• Company Code
• • Bussines units (GBUs)
    
    • Novecare (NC)
      • Business Activity (This can be a product line or end-market)
    • Aroma Performance (AP)
      • Business Activity (This can be a product line or end-market)
    • Specialty Polymers (SP)
      • Business Activity (This can be a product line or end-market)
    • Oil and Gas (OG)
      • Business Activity (This can be a product line or end-market)
    • Defence Materials (DM)
      • Business Activity (This can be a product line or end-market)
    • Other GBU...

Higher entities such as regions, operating segments, and groups of business units GBUs) can be positioned above the company code if needed. By maintaining this structure, we can assign segments to profit centers, ensuring compliance with IFRS and other accounting standards for segmental reporting.

Cost Centers and Cost Centre Hierarchies:

Current structure PF1:

According to Rules - Cost center Standard hierarchy, the code of the standard hierarchy in PF1 is KCHEF_HIER and it is structured in 2 main sub-groups

• CC_ORGANIS
• CC_CHEOPS (Not used anymore)

The group CC_CHEOPS was used for reporting cost centers. These cost centers are not used anymore. In other words the group CC_CHEOPS should not be used anymore and all active cost centers should now be included in the group CC_ORGANIS.

The group CC_ORGANIS is only harmonized until the plant level, afterwards it is free for every site.

CC_ORGANIS

• XX - Country
  • E_CCCC - Company
    • CCCC_PP - Site
      • PPP - Plant 
        • Cost center 1
        • Cost center 2

XX = Country code

CCCC = Company code

PPP = plant code 

PP = First 2 digits of the plant code

Current structure WP1:

According to Rules - Cost center Standard hierarchy, In WP1, there is one standard hierarchy per Controlling Area. The structure must follow the standard rule:

Zxxx = Controlling Area

PPPP = Plant code

CCCC = Company code 

GB = GBU code 

• CB - Corporate Business Services
• CH - Special Chem
• CM - Composite Materials
• CS - Novecare
• CT - Coatis
• GY - Solvay Energy Services
• OG - Oil & Gas
• PA - Aroma Performance
• PE - Peroxides
• SD - Soda Ash
• SI - Silica
• SP - Specialty Polymers
• TS - Technology Solutions

Best Practices for Cost Center Hierarchy:

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 following

1. Define Clear Organizational Structure

• Align with Business Units (GBUs): The cost center hierarchy should reflect the organizational structure, aligning with business units, departments, and functions with the complementary use of the functional areas (See the next paragraph).

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

• 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 below company code level:

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

Higher entities such as regions, operating segments, and groups of business units GBUs) can be positioned above the company code if needed.

Functional areas as complementary attributes to cost centers

The SAP functional area is a specific aspect within the SAP Financial Accounting (FI) module used to categorize financial transactions and costs within an organization. Functional areas are used to break down costs and revenues. They are assigned to General Ledger (G/L) accounts and cost centers. This categorization enables organizations to classify expenses and revenues according to various functions or activities, such as production, marketing, sales, or administration.

For example, by destination, functional areas can include production (manufacturing costs and maintenance), administration (general administration and human resources), sales and distribution (sales and logistics), marketing (advertising and market research), and research and development (product development and innovation). By nature, functional areas can be categorized into operating expenses (salaries, rent, and utilities), direct costs (raw materials and direct labor), indirect costs (depreciation and overhead), capital expenditures (equipment purchases and building improvements), and financial costs (interest payments and insurance premiums).

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-approach solution towards a ledger-approach solution for multi-GAAP accounting in S/4 HANA.
• In-house bank setup and design will be revisited functionally in S/4 HANA.
• Unified reporting dimensions

Constraints

We are currently evaluating the potential limitations that could arise if EML becomes the standard template.

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,
• Data Migration: Cost center and profit center mappings between the old numbers from legacy ECC systems and new numbers from S/4 HANA will need to be established, wherever required.

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". 

• All three master data objects should be subject to a centralized master data governance authority enforcing governance rules defined during detailed design.

Options considered

Option A: Introduce new operational CoA, Cost Center and Profit Center structures in S/4 HANA

In this option, a new operational CoAs, cost center and profit center new structures 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.
• Develop an intuitive and consistent architecture, along with a systematic numbering convention for the Chart of Accounts (CoA), cost centers, and profit centers to enhance ease of use and improve organizational efficiency
• Reduce number of G/L accounts used across the organization for unified process views.
• Reduce number of profit centers and keep the same structure across legal entities
• Reduce number of cost centers and keep a consistent structure across legal entities

Option B: Retain operational CoA, Cost center and Profit center structure from legacy ECC system

In this option, one of the currently used operational CoAs in the SAP systems and the current cost center and profit center structures will be migrated to S/4 HANA. 

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 -  Introduce new operational CoA, Cost Center and Profit Center Structures in S/4 HANA	Option B -  Retain operational CoA, Cost Center and Profit Center structures from legacy system	Option A Evaluation	Option B Evaluation
Standardization	Standardise use of accounts, cost centers and profit centers across all Syensqo entities Supports global process designs and unified process views across the organization Opportunity to design new CoA, cost centers and profit centers with intuitive codification logic and consistent architecture. Aligns with current international financial reporting standards (e.g IFRS), enhancing regulatory compliance. Standardizing processes can be complex and time-consuming initially	Constraints apply with regards to restructuring options in S/4 HANA as most account ranges are already used/occupied.	High	Medium
Simplification	Reduced reconciliation efforts and time savings at period-end due to standardized CoA across all levels of the organization Simplifies complex processes by implementing modern, efficient structures without the dependencies of the two systems	Avoids the short term costs and disruptions associated with restructuring of cost centers and profit centers. Local GAAP G/L accounts no longer required in S/4 HANA. Inefficiencies and redundancies in obsolete and not uniform master data objects	High	Medium
Future-Proof	Opportunity to design new CoA considering administration and IT maintenance aspects (e.g. CoA must be scalable without extra configuration requirements from IT). A new profit center hierarchy will seamlessly integrate with new S4 universal ledger, ensuring long-term viability.	Current CoAs not suitable for future adoption as group CoA as it's too granular.	High	Low
Change Management	Adoption of S/4s best practices for the mentioned data objects ensures smoother transition. 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, cost centers and profit centers will remain the same for some entities migrating to S/4 HANA. Existing reporting structures stemming from the cost centers and profit centers are well-established and understood by all stakeholders therefore Minimal need for retraining staff, reducing disruption.. Mappings required for data migration.	Low	Medium

Qualitative analysis

In conclusion, the transition to a single SAP S4 system presents a significant opportunity for Syensqo to harmonize and optimize its Finance master data objects. The evaluation of the proposed options—introducing new structures in S/4 versus retaining the existing ones—highlights the substantial benefits of the former. By designing a new operational CoA, Cost Centre, and Profit Centre structures, Syensqo can achieve improved standardization, simplification, and future-proofing of its financial processes. This will lead to reduced reconciliation efforts, time savings at period-end, and a more unified global process view, thereby enhancing efficiency and accountability. 

While the transition may initially be complex and resource-intensive, the long-term advantages far outweigh the temporary disruptions. The new structures will facilitate compliance with international financial reporting standards, align with best practices, streamline financial processes and support strategic decision-making with real-time reporting and analytics. Therefore, it is strongly recommended that Syensqo adopts Option A: the introduction of new operational CoA, Cost Centre, and Profit Centre structures in S/4 HANA. 

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