| Status | |
| Owner | BECHTER-ext, Alex |
| Stakeholders |
Document Splitting is a functionality which allows an organization to report complete and sound Financial Statements at a lower 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) is never broken in the system at any given point in time.
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.
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'.
The recommended option is there 'Option A - Activate Document Splitting in S/4 HANA'.
Explain the context in which the decision is being made.
In response to segmental reporting requirements IFRS imposed on companies required to report its 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 lower 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.
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. 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 application.
Example of a Financial Accounting document where document splitting balances out an outgoing invoice based on the revenue account assignment objects 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, 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.
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.
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.
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.
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".
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.
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
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 |
|
|
|
|
| Criterion 2 |
|
|
| |
| Criterion 3 |
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.
