Issue

Document Splitting is a functionality which allows an organization to report complete and sound Financial Statements at a different level than the company code out of SAP in real-time. Introducing document splitting brings about substantial benefits for business users from a reporting perspective but also increases the complexity of the solution as strict data integrity checks are being performed by the system for Financial Accounting documents to ensure that the principle of zero-balanced Financial Accounting documents and consequently also Financial Statements at the level of the defined splitting criteria (e.g. Profit Centre) never gets broken at any given point in time.

Switching on document splitting in a live environment requires data migration activities which can be quite complex and time-consuming. Switching on document splitting also has implications on integrated modules and data migration activities so it is advisable to decide on the usage of document splitting upfront in a greenfield project.

This KDD is therefore evaluating the pros and cons of using document splitting in the to-be solution to be built on S/4 HANA and a recommendation will be given on the preferred setup considering various aspects of the project charter.

Recommendation

With Syensqo being a publicly listed company, compliance with IFRS reporting standards is a legal requirement for the company. IAS8 mandates segmental reporting for companies to be fully IFRS-compliant in their external reporting to the markets. The state-of-the-art tool in S/4 HANA to support segmental reporting requirements out of the system is 'Document Splitting'.

Furthermore, the activation of document splitting at a later stage once a company code is in productive use in an S/4 HANA system with potentially multiple ledgers, valuations and parallel currencies running is a complex endeavor and requires deep technical and functional expertise and heavy involvement of business users for reconciliation purposes. The challenges in terms of integration and data migration during the initial setup are manageable but needs to be factored into the designs and approaches.

The recommended option is therefore 'Option A - Activate Document Splitting in S/4 HANA'.

Background & Context

Explain the context in which the decision is being made.

In response to segmental reporting requirements IFRS imposed on companies required to report their Financials in accordance with the rules and regulations stipulated in the IAS framework, SAP developed a functionality which allows companies to produce complete and fully-compliant Financial Statements in the system at a different level than the company code (e.g. at Segment or Profit Centre level) which removed a major constraint from legacy SAP systems in terms of reporting capabilities for many SAP customers around the world. This functionality has been labeled and marketed by SAP under the name 'Document Splitting' since its initial launch in the early 2000s.

Document splitting relies first and foremost on the definition of so called zero-balancing reporting criteria/characteristics - these are reporting dimensions below the company code at which the system supports the creation of zero-balanced and fully auditable Financial Statements. Commonly used dimensions used as zero-balancing reporting criteria are 'Profit Centre' or 'Segment', for example.

Document splitting at its core is a General Ledger solution and is fully compatible with the parallel ledger approach introduced in the new General Ledger Accounting solution meaning once enabled it will ensure the same level of data consistency across all active ledgers in the General Ledger Accounting module (leading and non-leading ledgers). To assure these levels of consistency and reporting accuracy across the General Ledger, the system is forced to apply more stringent data integrity checks for all transactional data updating the ledgers. The system needs to be able to derive or inherit the zero-balancing characteristics for each and every line item in the accounting document. This can be achieved via document splitting rules, built-in inheritance functionalities or ideally via explicit data provisioning of the zero-balancing characteristics from the sending applications.

Example of a Financial Accounting document where document splitting balances out an outgoing invoice based on the revenue account assignment objects (Profit Centre) which is defined as zero-balancing reporting characteristic in the system:

Example of a Financial Accounting document where document splitting completes a Financial Accounting document through inheritance of the zero-balancing reporting characteristic:

To ensure document splitting runs smoothly and delivers the desired outcomes with minimal disruptions to business processes in S/4 HANA, master data objects in the sending applications may need to be enriched to ensure that the system is able to derive the correct zero-balancing characteristics to be used for the Financial Accounting transaction across all business processes used in the system (please refer to section 'Impact' for further details on this aspect). Strict master data governance is also key after the initial implementation to ensure that document splitting is not causing disruptions to ongoing business operations.

Document Splitting requires careful assessment of all types of documents posted in the system to ensure that the correct base items are identified for splitting the respective balance sheet items. While this is relatively straight-forward for Accounts Payable (Accounts Payable is typically split based on the expense/GRIR legs of the document) and Accounts Receivable (Accounts Receivable is typically split based on revenue legs available in the document), other parts of the Balance Sheet may not require splitting at all (e.g. Tax is often a corporate function and doesn't require a split by zero-balancing characteristic used in the corresponding expense/revenue lines) or require a more complicated splitting rule to deliver the required outcome (e.g. cross-company postings often require special configurations especially if sub-ledger accounts are used as I/C clearing lines). This process of identifying all posting scenarios and determining the correct splitting rules for each scenario is relatively time-consuming and must be addressed early in the detailed design phase of a project.

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. 

• Data conversion approach will be greenfield using a posting approach to transactional Finance data into S/4 HANA.

Constraints

• Should the data conversion approach be an S/4 HANA conversion instead of a greenfield conversion using a posting approach, this may need to be revisited.

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.

Infrastructure: No impact - Document Splitting is part of the standard S/4 licensing package.

Basis/Security: No impact - no business functions or add-ons need to be installed. Likewise no special requirements arise from a Security perspective.

ABAP/Technical: No impact - Document Splitting is a SAP standard functionality that allows for flexible configurations to cater to various business scenarios.

Data Migration / Data Cleansing:

• Material Master: All materials must be be assigned to a profit centre in S/4 HANA.
• Open POs: All stock POs must be migrated with a profit centre maintained in EKPO.
• Projects: All migrated WBS elements must be tagged to a profit centre and responsible or requesting cost centre.
• Fixed Assets: All Fixed Assets must be tagged to a cost centre, also Assets under Construction.

HCM: As per recommendation by SAP, document splitting for payroll postings should occur upstream within the HCM module. This requires the activation of liability splitting functionalities which must be tested thoroughly to avoid adverse impacts to payroll calculations (in particular retro calculations).

Materials Management/Sales: All materials set up in the system require profit centre assignments.

Business Rules

• All materials need to be assigned to a profit centre.

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: Activate Document Splitting in S/4 HANA (with zero-balancing characteristics)

In this option, Document Splitting is activated by default for all entities set up in S/4 HANA with zero-balancing characteristics defined during detailed design stage. 

This gives Syensqo the ability to report complete Financial Statements at the required level of granularity to meet external Financial compliance or internal management reporting requirements at any given point in time, not just at period-end. Document splitting is the best practice approach in S/4 HANA to deal with segmental reporting requirements and has been around for nearly 20 years with many customers around the world using it so it can be considered a mature product from SAP. It still requires expert knowledge for its initial implementation which can be complex due to its powerful capabilities but once implemented and tailored to the needs of the business it is a reliable solution requiring only manageable maintenance efforts to keep it up and running.

It also future-proofs the solution as a retrospective activation of document splitting in a productive environment is complex to manage and execute requiring dedicated resources and project management. 

Option B: Disable Document Splitting in S/4 HANA

In this option, Document Splitting is switched off by default for company codes set up in S/4 HANA.

Compliance with segmental reporting requirements as per IFRS rules and other balance sheet reporting requirements at a lower level than the company code (e.g. Working Capital by GBU) required for statutory or group reporting purposes may still be possible using outdated and error-prone technologies such as balance sheets by business area which works for some parts of the balance sheet but not for all and requires additional month-end activities to achieve the desired split. The results of these activities are often lacking accuracy and may require manual adjustments subsequently.

A switch to Document Splitting at a later stage is a challenging project in a live environment as highlighted numerous times in this KDD. As such this option also has drawbacks from a future-proof perspective.

Evaluation

The below table provides a summary of the pros and cons of each option explained in the above section for both key design decisions, cost and compliance considerations and how each option scores with view to the below five key pillars of the overarching project principles:

• Standardisation: SAP Standard and best practices with harmonized and standardized business processes out of a single system are the preferred solution in S/4 HANA.
• Simplification: The solution design should be intuitive and easy to follow for end-users leading to higher adoption of the proposed to-be solutions.
• Future-Proof: The to-be solution needs to be future-proof and should strive to be in line with target designs from SAP in S/4 HANA.
• Process Discipline: The to-be solution should help the business to achieve better process discipline steering users away from off-the-system calculations and documentations.
• Change Management: Change impact must remain manageable in the to-be solution.

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