Co-authored by Birgit Oettinger and Stefan Walz
Welcome to this blog, in which we will provide insights into the new options of multiple CO account assignments and market segment attribution – innovations made possible with the Universal Journal in S/4HANA. The blog explains for which business processes this functionality is supported, which new reporting insights are enabled and which rules for CO account assignment - still - apply. The examples shown are taken out of SAP S/4HANA Cloud, public edition, but the principles also apply for the on-premise solution.
With the Universal Journal, all accounting applications share a common database. All the individual applications are views of the Universal Journal. This not only makes data transfers between the applications and subsequent reconciliations obsolete, but also makes the attributes of one application available to all others. Examples:
Thus, the journal entries can be enriched with new information (done automatically by the system). This enables completely new insights and simplifies processes. The following example shows the different attributes updated in a customer project scenario:
Figure 1: the universal journal
With every cost posting to the project (journal entry 1), work in process and realized revenue is recognized and posted (journal entry 2). All postings are account assigned to the WBS element – also the balance sheet journal entry item. The journal entries for cost and event-based revenue recognition (EBRR) postings automatically derive the market segment. Thus, market segment reporting is directly available without the need for settlement or any other additional process steps. The account assignment type – here WBS element - defines the real account assignment in the universal journal.
The detailed information stored in the universal journal (ACDOCA) is the basis for financial reporting. SAP HANA supports performant reporting for all applications by aggregating the individual journal entries. This enables an aggregated reporting for all attributes and a drill-down to the detailed information, the individual journal entry, for all amounts and KPIs.
This example shows how additional update of market segments enrich reporting:
Figure 2: Product and Service Margin report for a customer project
The user posts expenses and time confirmations, performs a partial billing, and enters manual accruals. Together with these business transactions the system automatically creates additional revenue recognition postings to ensure costs and revenues are matching.
All journal entries are account assigned to a project (determined by account assignment type PR). In addition to the project account assignment market segment attributes are updated.
Thus, not only project reporting is possible, but also market segment reporting for example for product sold, customers or sales order.
To provide correct and value adding data, the update of additional CO Objects and market segment fields needs to follow clear rules. These rules are predefined by SAP per business process and cannot be changed. The additional attributes are derived by the system and cannot be entered manually. Details will be described in the next sections.
The glossary shows which different types of CO account assignments are described in this blog.
With S/4HANA cost elements and G/L accounts were merged. Now the general ledger account type determines how the general ledger account can be used in financial accounting (FI-GL) and management accounting (CO). The cost element is determined by the G/L account type "Primary Costs or Revenue" or "Secondary Costs" These G/L accounts are relevant for management accounting (CO). Postings to such G/L “cost element” accounts require a CO account assignment. P&L G/L accounts of type Secondary Costs control the value flow within Controlling, as they define for which kind of cost allocation methods the different P&L accounts can be used.
In combination with field status groups and validations, the cost element controls CO account assignments.
Only one CO Object can be the real account assignment in one journal entry item. This CO Object is determined via the field Account Assignment Type (ACDOCA-ACCASTY). Financial business transactions executed for a CO Object only consider the costs, which are real account assigned to it. Example for such transactions:
A real account assignment and a cost element are prerequisites for (market segment) attribution – see following chapters.
With manual account assignments, only one CO Object can be entered at a time. Additional account assignments can only be entered if they are statistical – see chapter III. l.
technical details:
Examples for CO Objects and their account assignment types:
For non-operating P&L accounts (G/L accounts w/o a cost element category assigned) no CO objects or market segment will be assigned or attributed.
Figure 3: overview account assignment logic for P/L accounts
CO Account Assignments for Specific P&L Postings:
With the universal journal (ACDOCA) balance sheet journal entry items are automatically account assigned for defined scenarios. It is not possible to account assign balance sheet journal entry items manually.
Account assigned balance sheet postings are available in CO reporting. These CO account assigned balance sheet journal entry items are not relevant for subsequent CO processes like e.g., allocation or settlement (it is planned for asset and valuated project stock postings that they will be relevant for budget availability checks). Additional market segment attributes are derived from the real account assignment and updated in the journal entry item.
Balance sheet accounts differ from P&L accounts in the fact that at the end of the business process, they must have a balance of zero for account assignments and the market segment attributes. Therefore, additional checks are performed if balance sheet accounts are account assigned/ attributed. Example: if we assign an attribute for a goods receipt posting to material inventory but cannot assign exactly to the same attribute for the goods issue, then the balance sheet value for the attribute will not balance to zero and remain visible forever. The reporting is no longer meaningful. "Balance sheet accounts do not forget".
technical details
Let’s look at a system example: We issue for a customer project SW009 a down payment request of 1200 EUR, a customer invoice of 120 EUR, we enter services or goods delivered, which realizes revenue and WIP of 960 EUR and a manual accrual of -80 EUR due to an anticipated sales deduction. We start the app project actuals for the project and filter on the balance sheet G/L accounts.
Figure 4: Project – Actuals report with balance sheet values
The following values are available for the project, and for the market segment fields customer 10100001 and the product sold P007:
These four balance sheet journal entry items inherit the cost object project SW009 and the related market segment fields.
The business scenario "WIP on a customer project" shows how this potential can be exploited.
We start with the app Balance Sheet/ Income Statement.
Figure 5: WIP amount in the Balance Sheet/ Income Statement report
The report shows a view on the assets selected with the company code 1010 and ledger 0L. From here we drilldown to WIP Accrued Revenue, which shows an amount of 16.008,33€. We mark the amount and navigate to the related report Display Line Items in General Ledger.
Figure 6: WIP amount explained by single journal entry items
The single journal entries sum up to a value of 16.008,33€ - which is exactly the value shown in the Balance Sheet/ Income Statement report. The line items are grouped by customer, product sold and project. Remark: the complete balance sheet amount is assigned to these attributes. With a drilldown to the project, we see the amount of 960€ for project SW009, the value shown in figure 4.
Remark: If a balance sheet journal entry item is account assigned to a market segment (ACCASTY=EO) or the item is attributed with a market segment, it is relevant for margin analysis realignment (details are described in section 4).
Let's look on the business processes, which update CO account assignments in balance sheet items.
Event-Based Revenue Recognition (EBRR)
All balance sheet postings from event-based revenue recognition – like accrued revenue, manual accruals, or deferred revenues – are account assigned to a CO object:
Material Inventory with Valuated Project and Sales Order Stock
Sales order or project stock shall be visible in CO reporting. Therefore, inventory postings for this kind of inventories are account assigned.
Customer Down Payment in Customer Project Scenario
For customer project scenarios, down payment requests can be planned in the sales order item’s billing plan. The down payment request and the received down payment are posted on balance sheet accounts with an account assignment to the customer project (ACCASTY = PR).
The system will also derive market segment attributes for these postings.
more information you get here blog about down payment 4 customer projects in S/4HANA
Event-Based Production WIP
With the new event-based production WIP, WIP postings will be account assigned to the related production order (ACCASTY=OR). In case of valuated project stock, the market segment attribution is provided too.
For details see New in Production Accounting – Event-Based Production Cost Posting | SAP Blogs
Additional Remarks
Statistical cost elements for balance sheet accounts (cost elements type 90) are not used any longer to enable CO account assignments for balance sheet accounts. In S/4HANA public cloud edition, CO account assignments are updated automatically for the processes described above. On premise customers can still go on using cost element type 90 accounts, if they already did so.
For AP/AR postings no CO account assignment will be derived. This is also currently not planned on the roadmap.
Balance carry forward postings do not keep/ update the account assignments of the initial postings (this applies for S/4HANA public cloud edition). Thus, drilldowns based on account assignments will not work in financial statement reporting after a balance carry forward is posted. But in other reports like e.g., Product and Service Margin or in one of the Display Line Items reports, the balance sheet values can still be analyzed by account assignment.
In general, there can be only one real account assignment in one journal entry item. This one and only will be identified by the account assignment type. But there are several use cases in which multiple CO Objects are assigned to one line item.
With using statistical CO Objects there can be more than one CO Object entered on UI. In this case one CO Object is updated as real account assignment the other one as statistical account assignment.
The determination of the real and statistical object is done by the system. Two different cases can be distinguished:
If the order is a statistical order, the cost center becomes the real account assignment (ACCASTY = KS).
additional remarks
Attribution – as described below – and statistical account assignments need to be stored and handled differently as statistical postings are relevant for budget checks (like real account assignments), whereas simple attributions are not relevant for budget checks. Therefore we distinguish these postings in ACDOCA:
technical details
Let’s look at an overview of these rules.
Figure 7 overview of account assignment rules
There is another option to manually apply multiple CO objects in one journal entry item. If a market segment is the real account assignment, there is the option to enter additional CO objects in the market segment pop-up. Like e.g., a WBS element and/ or an order. The account assignment type will be market segment (ACCASTY=EO) and in addition the order and the WBS element are attributed in the posting line.
Let’s look on an example, in which we account assign an expense account in the app Post General Journal Entries
Figure 8: manually post a journal entry that is account assigned to a market (profitability) segment.
For the journal entry item with the expense account 50301000 we assign a market segment as the real account assignment. We get the “Profitability Segment” (= market segment) pop up as shown in figure 9.
Figure 9: pop up for profitability (= market) segment attributes
On this pop up, values for e.g., sales order, order, cost center and WBS element can be entered.
The app Display Line Items – Margin Analysis can be used to analyze the journal entry:
Figure 10: app Display Line Items – Margin Analysis
You see the entered cost objects in the journal entry. The journal entry item is posted with account assignment type EO.
You can see these attributed costs for example in the project reporting:
Figure 11: Project – Actuals with attributed costs
Real and attributed/statistical costs are distinguished with the flag “WBS element is statistical”.
For several scenarios market segment attribution is provided automatically by system. This is done for the complete end-to-end processes, including balance sheet journal entries. To ensure data consistency, the following rules must be followed:
Therefore, market segment attribution is only provided for revenue carrying objects, for which event-based revenue recognition (EBRR) is active. With the assignment of the market segment to the original journal entries a settlement to market segment/ profitability becomes obsolete.
The following scenarios are supported:
Figure 12: overview of options for multiple CO Object assignments
The single attributes of a market segment are reflected as fields in the Universal Journal (table ACDOCA). This is also valid for margin analysis extensibility fields.
Fields exclusively used by CO-PA are stored in a separate area in ACDOCA. Examples for such fields are product sold, customer group, product sold group, and the margin analysis extensibility fields. For the latter the Manage Substitution/Validation app is available to derive the attributes. With this app you can create a derivation rule by selecting the business context and event "market segment".
However, there are also fields in the market segment that are also used in other business processes. In this case the same fields are updated by these business processes and by market segment attribution. Examples for such fields are customer, sales order (and item), and the CO objects WBS element, order, service order and service contract. This allows an aggregated reporting for e.g., a project - see figure 11 - with postings, which are direct account assigned like e.g., goods issues and time confirmations, and attributed postings that originate for example from a production order, which is assigned to the project in case of valuated project stock.
Let us look first at an example, that describes the update in case of a market segment as real account assignment (ACCASTY = EO), the sell from stock business process
Figure 13: update market segment fields in sell from stock scenario
When the sales order item is created, a market segment object is generated. For the market segment determination some attributes are taken directly from the sales order item, e.g., customer and product sold. Others are derived from the customer master e.g., industry, country, and customer group. With the extensibility of margin analysis, you can also add your own market segment attributes.
The goods issue for the outbound delivery posts with reference to the sales order item. If margin analysis is active, the real account assignment is the market segment (ACCASTY=EO), which is assigned to the sales order item. The attributes of the market segment are updated in the Universal Journal.
In difference to the cost-based CO-PA solution the G/L accounts for COGS and billed revenue must be defined as cost elements for margin analysis.
More information about this scenario can be found in this blog https://blogs.sap.com/2022/09/06/margin-analysis-4-sell-from-stock-in-s-4hana/
A second example describes a scenario, with postings account assigned to project and attributed with the market segment: the customer project.
Figure 14: market segment derivation in customer project scenario
In the customer project scenario, a fixed rule defines the derivation of the market segment. The example shows a time confirmation posting to the WBS element SW06.1.1 and the matching EBRR journal entry, which posts realized revenue and WIP on the billing WBS element SW06.0.1. The system checks if a unique sales order item is assigned to the WBS billing element. If this unique assignment is given, the market segment is derived automatically with every posting to the project – including revenue recognition postings. The product sold is derived from the sales order item. The customer, the sales organization, and the division are derived from the sales order header. If margin analysis extensibility is active, extensibility fields are also derived and stored in the market segment! These attributes are only stored in the journal entries, in difference to the sell from stock scenario described above, the market segment is not stored on the sales order item, but the assigned WBS billing element.
A reporting example is shown in figure 2.
The same rules also apply for the service management scenario.
The market segment attribution is by default active in S/4HANA public cloud. In on premise, it must be activated via the IMG activity “Activate Derivation for Items without Profitability Segment.”
Realignment of Market Segment Attributes in Universal Journal
The market segment attributes are derived and updated in the journal entry with every posted document. But the attributed objects can change over time. For example, a different product group is assigned to the material master, or the derivation logic of a market segment field is changed. To keep the data consistent and up to date, a realignment is offered for the market segment attributes (app Run realignment – Profitability Analysis). This app changes the market segment attributes in already posted documents – this applies for real account assigned and attributed market segments. It is the only use case where already posted journal entries are changed. Of course, compliance is ensured. This is why only fields that are not relevant for statutory reporting are updated. For example, profit centers or segments are not changed during this realignment. A separate reorganization tool is offered for profit center changes.
Here a summarization of what we described before:
More information about all the described scenarioscan be found in the S/4HANA Controlling book https://www.sap-press.com/controlling-with-sap-s4hana-business-user-guide_5282/
We hope you enjoyed the blog and gained new insights and ideas.
Feedback is highly appreciated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 |