Issue

The purpose of this document is to provide a comprehensive understanding of the transfer pricing and group valuation functionality in S4, aiding the decision-making process regarding the implementation of this functionality and potentially making the universal ledger the primary data source for PAPM, as opposed to continuing with the current solution.

Key areas covered in this document include, but are not limited to, the following:

• Background and context of the transfer pricing mechanism and intercompany transactions
• Evaluation of the transfer pricing solution
• Constraints
• A brief view of the current process with PAPM integration

The primary objective of this document is not to introduce a solution that replaces PAPM, but rather one that streamlines the current process and standardizes the primary data source for PAPM. 

Recommendation

Implement the Transfer price solution and make the Universal ledger the primary data source

Background & Context

Syensqo conducts business not only with external parties (customers and vendors) it also transacts internally within its group of companies. These internal transactions are usually recorded at transfer pricing, which is regulated according to the prescribed group policy.

A key factor for global companies like Syensqo to having a smooth intercompany process is setting up a pricing structure that conforms with the requirements of all countries and affiliate companies involved but also leads to a sufficient redistribution of profit from countries in high tax jurisdictions to countries in low tax jurisdictions. Another key factor is to ensure that they can analyse their global P&L per different segment and therefore make controlling decisions on how they will operate more efficiently on global scale.

Transfer pricing is the method of establishing this pricing structure. Because the transfer price is usually set by the organization itself, as opposed to an external supplier, it’s important for the organization to keep track of the original cost of the product because this is what (when compared with the revenue from an external sale) constitutes the real profit to the organization.

Group valuation aids with the tracking of this original cost because it eliminates any of the intercompany profit and intercompany COGS between the affiliate entities, which, while useful from an internal profitability point of view, doesn’t contribute to the overall Gross margin of the organization.

Nevertheless, Group valuation should not be confused with consolidation. While consolidation involves the reporting of financial statements of multiple companies as if they were a single entity, group valuation does this on a more granular level, for each individual material. and can therefore report in Margin analysis and PAPM accordingly. 

Intercompany and Intra-company Transfer Pricing

It has to be noted, also, that there are two types of transfer pricing: intercompany transfer pricing and intra-company (profit center) transfer pricing. Ownership of inventory changes hands as it is moved across the value chain. This stock movement can be valued differently depending on whether it is for the group, affiliates, or business segment reporting. In group reporting, stock is valued at cost and without any markup. In affiliate reporting, stock is valued at intercompany transfer pricing. Meanwhile in business segments reporting, stock is valued at profit center transfer pricing. For Syensqo, the Profit Center Valuation is not considered an option since there are not many intra-company sales scenarios where one sales organization sells to another sales organization within the same legal entity. Moreover, the Profit Center Valuation functionality is complex to maintain and operate, and the possible benefits are outweighed by the costs of operating it.

Therefore two valuations are considered as part of this KDD, these are:

• Legal (company code / Legal entity) valuation
• Group valuation

Here is a graphical view of the two valuations. The legal price of the stock is changing from one legal entity to another whereas the group price remains the same since the IC profit is eliminated. 

Ledger and Currency types

In S4 the Ledger approach will be applied to meet the local and legal valuation requirements either statutory or managerial (please see the Assumptions section as well as the GAAP Ledgers and Currency Types KDD).  Today, Syensqo runs on a single ledger due to technical limitations and they meet the several valution requirements with the so-called account approach. 

Furthermore, multiple valuation requires Legal and group valuations to be set up as currency types in the ledger. The first step is to set up those currency types. The next step is to prepare the ledger where two options are available, either as one multi-valuation ledger or two single-valuation ledgers. A seperate KDD has been prepared that deals with the multi or single valuation Ledger desicion. (see GAAP Ledgers and Currency Types KDD)

The key concept is that every currency type forms a separate amount column in the designated ledger. In the ledger that has or will have a global valuation view, the currency types 31 and 11 will store the global amounts (meaning the global standard price). The local valuation view, with the local (TP) standard prices, will be stored in different amount columns, and additional line items will be generated automatically to eliminate the intercompany profit or intercompany COGS for these currency type/amount columns.

Local (legal) std price and Group std price

A key aspect of the Transfer Price functionality is that the standard cost estimate is calculated not only at the company code (Legal entity) level but also at the Group level. This approach allows for the incorporation of intercompany transfer pricing (IC profit) in cost estimate calculations. On the other hand, in Group valuation, standard costs are determined at the group level, excluding both intercompany and intracompany markups from the cost estimate calculation. The key distinction lies in the inclusion of intercompany markup in the cost estimate for legal entity views, whereas such markup is excluded in the group view.

There are several ways to add an intercompany markup (or exclude conversely) to a cost estimate, including the following methods:

• Utilizing an costing sheet
• Employing a condition type sourced from the IC purchasing info record
• Incorporating additive costs or implementing small custom change to the standard program (a user exit). In the Syensqo set up this might involve utilizing the logic of the current custom tables that store the IC condition types.

These solution options will be fully investigated during the detailed design phase and in conjuction to the logistics streams design 

Intercompany sales and purchasing prices

In a typical intercompany scenario, stock is transferred from one affiliate to another at negotiated intercompany transfer pricing. The negotiated price is maintained as the purchasing price at receiving affiliates and as the selling price at issuing affiliates. In transfer pricing scenarios, transactions must be recorded in all the valuations. Hence, a controlling area must be set up accordingly to include currency types for legal and group valuations. The differences between the valuations are posted to a valuation clearing account.

Basic settings for IC Transfer pricing include the below:

• Selling price for Sender/Issuer Legal entity
• Purchase Info record for receiver Legal entity

AS-IS design and PAPM brief overview

Currently the process is that a set of custom program and custom tables feed PAPM which the Transfer price segmented P&L reporting solution/tool. The below slide provides a view of the data flow. We will not describe the details of the current solution that prepares the data for PAPM because it goes beyond the objectives of this documents but here a few highlights:

• A set of custom programs select data from both standard and custom tables. This data involves the transactional data and it is enriched with master data objects.
• These programs exist in both WP1 and PF1 systems.
• The standard prices (semi-standard approach)  and the actual prices (periodic unit price - ML actual price) are selected.
• The custom tables (TSRA)  feeds into COPA, which feeds into BW, which feeds PAPM.

Here is an as-is data flow diagram:

Assumptions

• The current Key Design Decision Document (KDD) describes SAP functionality designed for achieving group valuation and eventual generation of a group Profit and Loss (P&L).
• The production cost system will be S4

• If the transfer price functionality is implemented, activation of actual costing becomes mandatory. However, this does not require running revaluation on actuals at month-end.

• The KDD does not address the positive or negative implications of Universal Parallel Accounting on the valuation issue. Another KDD will cover Universal Parallel Accounting's new features and their implications for product costing.

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	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	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