Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
stefan_walz
Product and Topic Expert
Product and Topic Expert
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:

  • the G/L ledger is also available in Controlling, revenue recognition and market segment reporting, this allows parallel valuations end-to-end.

  • the market segments of the margin analysis application are available in G/L and revenue recognition.

  • the CO account assignments are also available in G/L and revenue recognition.


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.



I CO Object as Account Assignment for P&L Postings


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:

  • distribution of overhead costs

  • settlement of costs or revenues

  • surcharge calculations

  • revenue recognition

  • commitment management


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

  • ACDOCA-ACCASTY defines the CO Object type of the real account assignment.

  • ACDOCA-ACCASTY is called Account assignment type on the UI.

  • For P&L journal entry items using cost element and derived ACCASTY, additional to the ACCASTY the ACDOCA-OBJNR is updated, which contains the object number of the real account assignment. Both fields indicate, that the financial business transactions – examples above - run on the CO Object.


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:







II CO Object Account Assignments for Balance Sheet


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

  • ACDOCA-ACCASTY defines the CO object type of the real account assignment.

  • Market segment attribution can be updated based on the ACCASTY object.

  • ACDOCA-OBJNR is not updated, therefore such postings are not relevant for subsequent CO processes like e.g., allocations. This is different to P&L accounts.


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:

  • a down payment request of 1,200€

  • Accrued Revenue of 960€ and deferred revenue of 120€ - posted with event-based by EBRR.

  • a manual accrual of 80€ - posted with the EBRR monitor.


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.

  • Valuated Project Stock is account assigned to the related project (account assignment type PR).
    Market segment attributes will also be added for these postings.

  • Valuated Sales Order Stock will be account assigned to the related market segment (account assignment type EO) on roadmap.
    Market segment attributes will be derived from the related sales order item.

  • There is no ACCASTY update for anonymous inventory available and not planned on roadmap.


 

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.

 

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.


III Multiple CO Object Assignments in One Journal Entry Item


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.

III.1 Statistical CO Account Assignments


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:

  1. CO object is defined as statistical. This can only be done for internal orders or WBS elements in their master data.
    Example:
    You enter a PM order and a statistical WBS element. In this case the PM order is the real account assignment (ACCASTY = OR) and the WBS element is updated statistically.

  2. If you enter two non-statistical CO objects, this will only work if one of the CO objects is a cost center. In this case the cost center will be updated statistically, and the other object determines the real account assignment (ACCASTY).
    Example:
    You enter a non-statistical order and a cost center. In this case the order is the real account assignment (ACCASTY =OR) and the cost center is updated statistically.


If the order is a statistical order, the cost center becomes the real account assignment (ACCASTY = KS).

additional remarks

  • In table ACDOCA there is always just one field for each CO object (e.g., one field for cost center, one field for WBS element). Therefore, it is not possible to assign two CO objects of the same type to one journal entry item, even if one of the CO objects is statistical, this is not possible. Example: you cannot enter an internal order and a statistical internal order

  • Besides the statistical scenario it is not possible to enter more than one real account assignment on the UI – for example in a purchase order or supplier invoice only one real account assignment can be entered.

  • In case the given combination of CO objects does not fulfill the rules (i.e. the real object cannot be determined) the error message “Account & requires an account assignment relevant to cost accounting" (KI 235) will be raised


 

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

  • The account assignment type of the real CO Object is stored in the field ACDOCA-ACCASTY

  • The fields ACDOCA-ACCASTY_N1 to N3 are used to distinguish statistical account assignments from real account assignments. Example: a journal entry item is account assigned to an internal order and a statistical WBS element. Result:

  • real account assignment = ACCASTY = OR,

  • statistical account assignment = ACCASTY_N1 = PR and

  • the IDs of the internal order and the WBS element are updated in the related ACDOCA fields.


 

Let’s look at an overview of these rules.


Figure 7 overview of account assignment rules


 

III.2 Attributed CO Account Assignments


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:

  1. The link to the object, which carries the market segment information, must be stable. This anchor object is assigned to all postings and used as reference object in case of realignment. Examples for anchor objects:
    In the customer project scenario, it is the WBS billing element. This is also valid for valuated project stock. The link from the WBS element to the billing element is stable. The market segment is derived from the settlement rule in the billing element or from the assigned sales order item.
    In the service order scenario, it is the service order item. This also applies for the Service with Advanced Execution scenario (service order with assigned PM order).



  1. Market segment reporting selects postings that use the market segment as the real account assignment and in addition attributed postings are also selected. The system ensures that the margin for the market segment is correctly updated with attributes. If only costs and no revenues would be attributed with a customer project, this would have a negative impact on the margin for the project/ market segment. An attribution can only be made, when it is ensured, that the matching revenues – or cost adjustments - are attributed as well.


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




IV Update Market Segment Fields in Journal Entries


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.


Closing remarks


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.

 
2 Comments