Co-Authored by Gabi Hoffmann and Stefan Walz
Welcome to this blog, in which we will show you how the S/4HANA accounting and controlling innovations influence the sell from stock business process. Central functionality is the universal Journal integrated margin analysis. The screenshots are taken out of a CE 2208 system, but the scenario is valid for OP 2022 too.
In this business scenario an inventory managed product is planned in a sales order item, delivered by outbound delivery to customer and then billed. These process steps create journal entries for cost of goods sold and billed revenue. Additional to the logistic process there are controlling applications available to get a margin analysis for the sales order and market segment.
New in S/4: the market segment is incorporated in Universal Journal and all its attributes are stored in in the relevant G/L journal entry items. The sell from stock logistic transactions create P&L journal entry items, which are account assigned to a profitability Object/Market segment. All co documents are posted in the general ledger.
We will start in this blog with first insights in the financial innovations in S/4HANA and the new reporting capabilities, followed by the explanation of the architecture. Then we will show you an end-to end process for a sell from stock scenario of a manufactured good in the system. We close with deeper insights in the event -based revenue recognition.
In S/4 the accounting applications General ledger, Controlling, event-based revenue recognition and margin analysis are now integrated in the Universal Journal, in which all actual data of margin analysis is stored. There is no separate data store. All KPIs like realized revenues, cost of goods sold, margin per quantity unit or multilevel contribution margin are calculated based on journal entry items, stored in the Universal Journal single source of truth.
Let’s have first a look on the architecture evolution path related to the sell from stock process
Figure 1 S/4HANA controlling evolution 4 sales process
In ERP there was a separation between G/L and the market segment reporting, which also means different reporting entities like G/L account in accounting and value field in CO-PA. The process updates were made at different times: the G/L with delivery and billing, the CO-PA only at the time of billing. Thus, reconciliation was cumbersome.
In S/4HANA all data are stored in Universal Journal; the order entry in the prediction ledger – see next chapters. Delivery and billing update G/L and margin analysis with the same journal entry. The matching principle for revenue and cogs is ensured by event-based revenue recognition. EBRR cares also for the IFRS15 case, when different revenues has to be realized as billed.
Calculatory costs based on SD price conditions are posted in an own management ledger. The CO allocations update the GL. This we will see step by step in our posting example.
Let us start with some impressions about the reporting capabilities of financial accounting for sales processes in S/4HANA.
Figure 2 – app product profitability
In figure 2 you see a multilevel margin reporting for one sales order, 18579, based on journal entries, which are created by the logistic processes and controlling allocation postings. We enrich these journal entries with multiple information. For example:
we store the fixed Amount portion of an cost component split item. What allow us to show the “cogs – fixed amount in CC Crcy”
we store the market segment attributes in all the journal entries, which can be selected by the navigation panel on the left. This allows us to slice and dice the margin flexible by all market segment fields
On the top you see the 4 revenue rows. To get the product revenue, we need to aggregate the billed amount and the realized revenue, created by EBRR based on the delivery postings. The realized revenue shows the matching revenue for deliveries, which are not yet billed.
How we get these figures, we will show you step by step in the system in chapter 3.
An KPI overview for the market segments we get with the app “product and service margins
Figure 3 – product and service margins
In the line items you can select the market segments – here customer and product sold. In the columns we get the KPIs. The recognized revenues are the aggregation of the billed revenues and the realized revenues from EBRR. The accrued revenue/WIP you can drilldown too by all market segments.
Innovation overview for product sales
Using the Universal Journal, we automatically get the following innovations:
The incoming order value and prediction is stored in an extension ledger with the same Universal journal entities and posting logic like in the standard ledger. The posting logic enable us to report the “remaining order value” too – see chapter 3.1. In this extension ledger manual controlling adjustments can be posted.
Manual cost allocations can be posted to sales order and market segment -> see chapter 3.2
The cost component split of a manufactured good is posted in Universal Journal with the outbound delivery with multiple journal entry items – see figure 3.7
Production variances are account assigned to profitability object and posted in G/L (not covered in this blog)
An example for the controlling value flow including the cost centers and their under/ over absorption you get in figure below.
Figure 4 – overview for value flow for sell from stock
In Figure 4. you see, how the different processes generate Journal entry items. All journal entry items in the right table are account assigned to a profitability segment (ACCASTY = EO). The aggregation of the items results in the multilevel contribution margin. Example for the postings we will show in system in chapter 3 – except production process.
The following picture explains, how the margin analysis attributes are derived and provided in Universal Journal.
Figure 2.1 – market segment account assignment and derivation logic for sales order
With creation of the sales order item a Profitability object, a set of market segment attributes, is derived and assigned to the sales order item. Some attributes are taken direct from sales order item like customer and product sold. Others are derived: e.g industry, country and customer group from customer master. With margin analysis extensibility you can add own attributes. These attributes are added to universal journal! To derive the attributes the app manage substitution/validation is available. Here you can create a rule by selecting business context and event equal “Market Segment”.
If margin analysis is active, we account assign for all sales business processes the profitability controlling object (ACCASTY = EO) – if there is no other co object derived by process for the sales order item like a wbs element. Thus, Cost elements for inventory change and revenue accounts are required! This is different to cost based CO-PA processes, where we use non-operating P&L accounts for inventory change/ cogs and billed revenue.
In the sell from stock scenario we real account assign the profitability segment. This is different to the service and customer project scenario, where we attribute the profitability segment. Example for attributed profitability segments you get here:
professional service customer project scenario
new service management scenario
Project based sales scenario
Extension Ledger
The sales order business transactions like billing and delivery create postings in the legal standard ledger. To apply management accounting specific information, which are not G/L relevant, we provide the extension ledger. Here calculatory costs and management adjustment postings can be applied. And we store here prediction and purchase order commitment information.
In cloud we provide the two extension ledger OE and OC:
Figure 2.2 – extension ledger set-up in S/4HANA cloud
Extension Ledger are assigned only to the leading ledger; in S/4HANA cloud this is ledger 0L.
To get a complete management accounting view, the underlying ledger are always aggregated: when you start a report with ledger 0C, you get the data from ledger 0C plus the data from ledger 0L. If you start a report for Ledger 0E, you get the data for ledger 0E plus 0C plus 0L.
For ledger 2L in this example there are no additional management information available.
Frozen profitability segment
As we stated before the profitability segment is created and stored to the sales order item and used for subsequent delivery and billing. If there is now a document flow in place with multiple sales order objects like debit memo request, credit memo request or return order and you want to report all the related costs and revenues on the original sales order item, you can freeze the original profitability segment for such a document flow. In this case the profitability segment is not determined new in a subsequent sales document, but copied over from the preceding sales order
Figure 2.3 – option to freeze market segment in document flow
In this example the revenues of the debit memo request and the credit memo request have the original sales order 5011/10 in their market segment assigned.
This is the default setting in S/4HANA cloud. It is controlled with the SD copy control customizing, which you can change in on premise.
Realignment
The market segment attributes are derived and updated in the journal entry with the document posting. Later or even during the process attributes may change. For example, there is another product group assigned to the material master or you change the derivation logic of a market segment field. To keep the data consistent and current we provide a realignment with the app “Run realignment – Profitability analysis”. With this app we change the market segment attribute in already posted documents. This is the only use case, in which we update posted Journal entries. Of course, we ensure compliance. Thus, we only update fields that are not relevant for legal reporting. For example, we do not change profit center or segment. For Profit Center changes there is a reorganization tool in place.
We will now show a sell from stock process plus subsequent controlling allocations in a S/4HANA cloud 2208 system.
Let us first look on the product or material master. For our example we created the product SW-Fert07.
Figure 3.1: material master – costing 2 data
There is a standard price for valuation maintained of 15.04 EUR. Every goods issue – like a delivery will be valuated with this price. You see, this price has been calculated with a cost estimate in Period 007/2022
Material dependent Market segment attributes are for example maintained in the sales org 1 tab: the material group = L004 and the Division = 00. In the tab sales General/Plant the profit center = YB110 is assigned.
Now let’s look in detail on this standard price cost estimation.
Figure 3.2: cost estimation – cost component view
In the cost component view you can see the total costs for our product of 15,04 EUR per piece, of which 1,58 EUR are fixed. The value is split according to cost components – for example material costs of 6,77 EUR. We will follow up on this view in the goods issue posting and the multilevel margin reporting.
Now let’s look on the customer master, with the BP role “Customer”
Figure 3.3: customer master – billing
With the account assignment Group customer, here 01, the G/L account determination is determined. Because the customer is located in the same country as assigned company code Domestic revenues will be posted.
The selected Term of payment 0002 will lead to a statistical discount condition in SD pricing of 2%. We will come to this later when we will post the billing
In the same role in the tab orders the customer group 01 is defined.
In the BP role “customer FIN accounting” the industry “91 trading” and the country DE is defined. All three attributes are part of the standard market segment.
Now we start the business process with the sales order creation – app create sales order
Figure 3.4: sales order – overview
As Sold-to-party and ship-to party we enter our customer 10100001 we show before.
We enter one sales order item for product SW-Fert07 with an order quantity of 10 pieces. There is a sales price maintained of 30 EUR per piece.
We double click on the item to get the item view and select the tab account assignment. From there you can get to the market segment screen below by selecting the button Profitability segment.
Figure 3.5 sales order item – assigned profitability segment
You see the attributes taken from sales order: customer and product and the sales area. When you scroll down you see additional attributes derived from product and customer master. Customer group, country of the customer and Industry are derived from customer master. The material group from product master.
With these market segment fields all Journal entry line items of subsequent business processes will be updated.
Now we create an outbound delivery for our sales order by starting the app ‘create outbound deliveries from Sales Orders’.
Figure 3.6: outbound delivery
We deliver 5 of the planned 10 pieces and post goods issue. Let’s look on the posted journal entries in ledger 0L. We start the app “Display line items – margin analysis” with the selection of the reference document equal to the outbound delivery material document.
Figure 3.7 journal entries posted by outbound delivery
We see that the prima nota, the goods issue of delivery (visible in reference document number 4900010019) generates 3 journal entries.
The second journal entry is the goods issue, which credits the inventory and post cost of goods sold to market segment.
The third journal entry provides the cost component split of the product in the Universal Journal. In the first line item the cogs line item of the goods issue posting is reversed. The other line items post on G/L accounts reflecting the cost components. Their values are taken from the cost estimation of the product – see Figure 3.2. Please recognize the fixed Amount column: here the fixed portion of the cost component split is updated. There can be fixed portions for the activities and the overheads. In our example there was a fixed portion for machine time of 9,76 USD. Please note, fixed amount is stored in global currency only.
The first journal entry is the event-based revenue recognition posting. In Ledger 0L we realize the revenues already with the cogs posting of the goods issue. We deliver 5 pieces and we have maintained a selling price of 30€/ per piece in the sales order item. Thus, we can realize 150€ revenue.
With the event-based revenue recognition journal entry we ensure event-based matching principle: cogs and realized revenue always match. This is especially important if delivery and billing is not in the same period.
Remark: in ledger 2L we have implemented a different revenue recognition method: we realize revenue first with billing. How this parallel valuation looks like, please see parallel valuation in chapter 4.
Except the inventory line item all line items are account assigned to the profitability segment (column Account Assignment Type = EO). With this we get multiple market segment fields derived and stored in the line items. You see them in the right columns: customer. Product sold, customer Industry, sales organization.
Now let’s come to next business transaction, the customer billing.
We start the app “Create Billing documents” and enter as reference document the outbound delivery, visible in figure 3.6. With entering return, we get to invoice proposal, which we save. With this we get the journal entries posted. Let’s have a look on the pricing data of the invoice.
Figure 3.8: billing document – pricing data
In the condition scheme you see at the bottom two statistical condition types. Statistical conditions do not influence the sales price determination. They are used for additional information, and they can be included in margin analysis reporting.
Let’s look in detail on the cash discount. DCD1 is a Cash Discount we offer to the customer. In our case this is triggered by the business partner attribute Terms of payment – see Figure 3.3. We expect the customer to take advantage of this when paying, but it does not affect the total invoice price. For the delivered and billed 5 pieces there will be a discount offered of 2% of 178,50€ (150€ product price plus 28,50 output tax – see screen shot on top) = 3,57€ We will see this value of in our margin reporting as sales deductions.
Let’s have a look on the posted accounting documents. With selecting the Accounting button, we get the popup below.
Figure 3.9: overview of journal entries posted by billing document
Journal entry 4 is the accounting document for the invoice: the journal entry items for the billed revenue, receivables and tax. It is handled as prima nota and posted in all active standard ledger with the same values.
Journal entry 1 to 3 are EBRR postings. There is an own document per standard ledger, for which the postings can differ per ledger.
The fifth document is posted in the extension ledger OC, the ledger for additional management adjustment postings. Here the management posting for the statistical sales condition is stored.
Documents 6 and 7 are technically documents to support additional controlling features.
Now we will analyze the corresponding financial documents with the app Display line items – Margin analysis
Figure 3.10: journal entries posted by billing document
The second document is the General ledger posting of the invoice. We debit receivables domestic and credit domestic revenues and tax. Please recall the domestic revenue G/L account group in the business partner – Figure 3.3.
The third document is the management posting for the statistical sales condition. It is posted in the extension ledger OC, the ledger for additional management adjustment postings. The second line item is the posting on the profitability object, which provides all market segment information. The used P&L G/L account cash discounts will update the sales deduction in the multilevel margin reporting. As we follow the logic of double-entry accounting in the extension ledger too, we need an additional line item, which balance the document to zero. The first journal entry item posts against an accrual account without any market segment relevant attributes.
The first document is the revenue recognition posting. We realized already revenue with the cogs posting of the delivery in ledger 0L. Now we get additional billed revenue. Thus, we need to reverse this already realized revenue.
Now let’s have a look how these two business transactions impact the multilevel margin reporting for our market segment reporting – represented by our example sales order 18579. To get the management posting included, we select with the extension ledger OC.
Figure 3.11: multilevel product contribution margin – after delivery and billing
We get a three-level margin reporting. The line items are semantic tags, an aggregation of G/L accounts, taking fix and variable costs in account.
Contribution Margin I is the sum of the billed revenue, minus the sales deduction of 3,57€ we posted in the extension ledger and the variable costs of the product, we get from the cost component split. In our case this leads to a margin I of 79,10€.
Margin II includes the fix price portion of the product. In our case the 7,87€ of the machine time – see cost component split in Figure 4.2. This leads to a contribution margin II of 71,23 €
Additionally, the margin I per billed quantity is provided. We billed 5 pieces, so we get a margin of 15,82€ per piece.
With the creation of a sales order, we calculated the expected costs and revenues and store it in the prediction ledger 0E – please recap architecture chapter and figure 2.2. We get these values by simulating the delivery and the billing. This leads to the following order entry/ incoming sales order value in our example with the app “Incoming sales orders – prediction accounting”:
Figure 3.1.1 incoming sales order reporting
When you recap figure 4.4, we planned in the sales order item 10 pieces with a price of 30€, so an order value of 300€. The cogs for 10 pieces are 150,40€. All KPIs are based on Journal entries, which you can access on the bottom.
Same as in legal ledger we follow for the prediction JE the principle for double-entry bookkeeping. The created journal entries for prediction look similar the JE for billing and delivery we showed above for the actual postings. We get them with selection of ledger OE.
Figure 3.1.2 Order entry Journal entries for sales order 18579
Please recognize that we even post the cost component split, what allows a detail margin analysis for the prediction reporting.
As mentioned above we do not only store the Values for every new created and changed sales order; we update prediction ledger with every subsequent posting. In our example we delivered and billed 5 pieces. This reduces the remaining order value to 5 pieces, result is 150€ open revenue, same the expected cogs are reduced.
We get the remaining order value for our sales order 18579 with the same app, but select in the filter “remaining orders” instead of “incoming orders”:
Figure 3.1.3: update prediction ledger remaining sales order
For our example sales order 18579 there remains an order value of 150€. With the Journal entries on the bottom, you see here the value of 300€ created with order entry and the reversal of 150€ with the billing.
All data for order entry and remaining order volume we get out of the prediction ledger OE.
Now we show, how you can apply special direct costs and periodic allocation postings with reference to a sales order. With margin analysis activated these transactions will be stored in Universal Journal in a legal ledger – like the other sales process postings – with account assignment type “EO”!
Manual allocation postings
To apply special direct costs, you can account assign the profitability segment in many transactions like reassign cost and revenue app (for example KB11N), manage direct activity allocation (KB21N) or post General Journal entry (for example FB01).
Let’s post a direct activity allocation
Figure 3.2.1: activity allocation for 1 hour R and D effort
In the line item for 1 hour R&D you see that the Receiver Profitability Segment is Assigned.
There is a pop up available, in which you can maintain the profitability segment.
Figure 3.2.2: activity allocation – market segment pop-up
We maintain the sales order 18579/10 as market segment, as well as Customer and product sold. Material group, Country and Industry will be derived.
Let’ look on the created Journal entry.
Figure 3.2.3: activity allocation journal entry
The one hour R&D time is posted against the profitability segment, in which the sales order item 18579/10 is assigned. It will be part of the margin contribution of the sales order – see below figure 3.2.8
Please recognize, these management postings are not taken in account in revenue recognition, the posted costs are just realized. In the EBRR methods for sales processes we take only the logistic processes billing and delivery in account.
Periodic Margin Analysis allocation postings
Now we come to the allocation of periodic costs to market segments. These costs cannot be applied direct to a market segment or even a sales order item with the primary posting.
In our example, periodic freight costs of €1000 have been incurred. They are initially posted to an unspecified market segment:
Figure 3.2.4: 1000€ of freights posted to market segment
The periodic freight costs should be allocated to the sales orders, which are billed in this period. The allocated freight amount should be weighted according to the billed revenues they generated.
Figure 3.2.5: postings on receiver market segment
In sum we have an Amount of 927,65€ billed. The billed amount of our example sales order is 150€. We expect with the allocation an amount of 150/927,65 * 1000€ = 161.70€ to our sales order 18579.
Now let’s create a top-down distribution cycle for the freight costs with the app “manage allocations”. There is an own Allocation context for “margin Analysis.
Figure 3.2.6: margin analysis allocation cycle
There are 3 different methods available to allocate costs to market segments: Distribution of costs, overhead allocation for e.g. allocation of over-/under absorption of a cost center to market segment and the Top down distribution.
All these 3 allocations post in a legal ledger. There can be a single ledger selected for the rule. But if the rule should be applicable for all ledger, you can flag the checkbox “Flexible ledger” in the rule’s processing indicators.
We create one for the freight costs and start the allocation run. The posted Journal entries you see here:
Figure 3.2.7: postings of Top down Distribution run
There is an own business transaction type applied for Top-down distribution, AAAT.
In a first journal entry item the costs are reversed from the original market segment with no specific attributes.
In the rule we specified the allocation receiver by customer, product sold and sales order header. Thus, the allocated freight costs are enriched with these attributes.
In the third line you see the allocated freight costs of 161,70€ on our example sales order – as expected.
The activity allocation and the freight TDD has impact on the contribution margin of our sales order example:
Figure 3.2.8: final contribution margin for our example sales order
The freight costs are assigned to the sales overhead costs, for special research and development costs there is an own contribution margin item.
In this case we get a negative CM III KPI.
We have seen above that event-based revenue recognition is integrated in the sell from scenario. In our example revenue recognition postings were triggered with goods issue and customer invoicing.
Let’s have here a deeper look on the revenue recognition options for sell from stock scenario.
Activation of event-based revenue recognition
Activation of Event based revenue recognition occurs when the sales order item is assigned to a revenue recognition key.
The revenue recognition keys are in cloud predefined. A revenue recognition key defines how the values are calculated and at which point in time costs and revenues are realized.
For the sell from stock process there is a specific revenue recognition derivation table available – see figure 4.1. The derivation depends on the company code, sales order item category, value chain category and the material maintained in the sales order item. If the derivation logic should be independent of the material, it is possible to maintain a star. If a process should not be relevant for revenue recognition, the rev rec key can be kept initial.
Figure 4.1 revenue recognition key derivation logic
To track all relevant steps of the business processes:
the value chain category is introduced. The category is the basis of the value chain monitoring. In addition, the information can be used to derive a revenue recognition key. This has the advantage that the different business processes are flexibly supported by event-based revenue recognition.
There are four value chain categories available:
Information to Value Chain Monitoring you can get here SAP Help Portal
The checkbox ‘Bundling’ is required to enable additional IFRS15 functionality. With this it is possible to use IFRS15 revenue allocation between items within a sales order.
These are the available revenue recognition keys in S/4HANA cloud:
Let’s take a closer look at the revenue recognition keys and method associated with them.
Recognize revenue based on an invoice simulation (revenue recognition key SFS)
The revenue recognition key ‘SFS’ you can use for a sales order item, which uses delivery-based invoicing. With the applied method costs and realized revenues will be posted with goods issue posting. Posting revenue and costs at the same time, enables the matching principle and allows a profitability anaylsis in real time. The revenue value is determined with an invoice simulation.
Figure 4.2 posting logic for key SFS, realization by delivery
(1’) and (3’) With goods issue posting, accrued revenue is calculated by simulating an invoice for the current delivery. The amounts of the accrued revenues are posted using the document currency of the sales document item as document currency.
(2’) and (4’) Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition to deferred revenue. The currency amounts for deferred revenue are copied from the primary posting.
(5) Period-end closing does a balance sheet clearing between accrued and deferred revenue.
If there is at period-end run the sales order item status ‘finally delivered’ and ‘finally invoiced’ possible balances on deferred revenue and accrued revenue will be cleared.
A system example for this method you get in chapter 3 before. Please recap figure 3.7 for the delivery and figure 3.10 for the billing
Recognize costs and revenue when finally billed (revenue recognition key: SFSCCM)
If the revenue recognition key ‘SFSCCM’ is used for an sales order item, which uses delivery-related invoicing, costs and revenues will be deferred until the sales order item is completed. With sales order item completed (‘finally delivered’ and ‘finally invoiced’), the posted billed revenue and costs will be realized. The next period-end run will realize revenue and costs and cancel all remaining accruals and deferrals.
Figure 4.3 posting logic for realization with completed contract
(1’) and (3’) With goods issue posting, cost adjustment and deferred CoGS is triggered.
(2’) and (4’) Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition to deferred revenue. The currency amounts for deferred revenue are copied from the primary posting.
(5) With period-end and the sales order item status ‘finally delivered’ and ‘finally invoiced’ balances on deferred revenue and deferred CoGS are cleared and revenue and CoGS are realized.
In our system example before we applied a completed contract method for the parallel ledger 2L. This lead for the goods issue of the outbound delivery to the following postings.
Figure 4.4 posting logic for realization with completed contract
The costs are just deferred. Different to the posting in ledger 0L, in which we realized revenue already with the cogs posting by invoice simulation.
Recognize revenue based on an invoice simulation without liability posting
To support such posting logic, you have to use the revenue recognition key SFSSSM. The realization logic is the same as for revenue recognition key ‘SFS’, but the used accounts are different.
Figure 4.5 posting logic revenue recognition key SFSSM
In real-time processing, accrued revenue is created by simulating an invoice for the current delivery. Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition direct to the accrued revenue account. We do not use here the deferred revenue account like we do in SFS scenario.
Process “Sell from stock with transfer of ownership” (incoterms)
The requirement to realize revenues with the transfer of ownership is also supported.
For this requirement you have to refer to the sell from stock with valuated stock in transit functionality. The process must be activated in logistics and the corresponding category must be maintained in derivation table for revenue recognition keys. The category for the valuated stock in transit is ‘SFSV’.
When using incoterms, the system posts to stock in transit until the transfer of control according to the incoterms happens. This logic is built into the sell from stock functionality.
Once the transfer of control happens, the system credits the stock in transit account and posts cost of goods sold. If you use the revenue recognition key SFS, this is also the trigger to realize revenue and post accrued revenue real-time.
Using SFS, the billed revenue from the invoice is deferred – you may have to create the invoice prior to the goods issue being posted. Under SFS, the period end then clears accrued and deferred revenue.
Sell from Stock with Valuated Stock in Transit SAP Help Portal
Transfer of Control of Goods SAP Help Portal
Valuated Stock in Transit SAP Help Portal
Parallel valuation
Two different keys are needed to support parallel valuation. To set up a parallel valuation an additional customizing must be maintained.
Figure 4.6 SSCUI for different revenue recognition valuation per ledger
With this configuration step you can define a deviating recognition key for a specific accounting principle In our example there is a standard key maintained, which realizes revenue with the goods issue (key SFS). This key is stored in the sales order item. We assign here now for the accounting principle DEAP, which is applied in the ledger 2L, the key SFSCCM, which refers to the completed contract method. This key is not stored in the sales order item. It is taken in ledger 2L from this table, when EBBR runs for a project with key SFS
The resulting different posting logic we show you for the delivery posting in our system example.
In ledger 0L we realize revenue with the goods issue/ cogs posting see figure 3.7
Figure 3.7 realization of revenue with cogs posting
In the parallel ledger 2L we defer the cogs – see figure 4.4
Figure 4.4 completed contract method- cogs are just deferred
In ledger 2L we applied completed contract method. Thus, the cogs of 75,20€ are 1:1 deferred – see journal entry 3.
You see, that one prima nota can trigger different revenue recognition postings in different ledger.
The revenue recognition monitor / applying temporary adjustments
Event-Based Revenue Recognition provides in addition the option to adjust realized costs and revenues of the current posting period. A manual, temporary booking is carried out via the App ‘Event-Based Revenue Recognition Sales Orders’. You select sales order, here 18638, the ledger, period and company code.
Figure 4.7 App ‘Event-Based Revenue Recognition Sales Orders’
Within this App you get information about the KPIs like realized revenue and costs and you get additional options
Let us focus on ‘Enter Temporary Adjustment’:
currently 30.08 € costs are posted and 100,00 € matching revenues are realized. We select the button ad get the figure below.
Figure 4.8 Event-Based revenue recognition ‘Enter Temporary Adjustment’
In our example we adjust both, costs, and revenues. The new recognized costs should be 28.00 € and the new revenue value should be 110.00 €. We enter the new values and hit button “Simulate”.
As you can see on our screen shot the recognized costs are reduced by “cost adjustment”; as offsetting account Deferred costs/ WIP is used. The revenues are increased, as the revenue adjustment amount is increased by 10€. As offsetting account Accrued revenue is used. It is also possible to adjust only the costs or only the revenues. The adjustments are reversed with the next period end run.
Let’s have a look on the created journal entry items:
Figure 4.9 Event-Based revenue recognition ‘Enter Temporary Adjustment’ journal entries
Four journal entry items are created by EBRR adjustment posting. As the other EBRR postings all 4 journal entry items are account assigned to a profitability object. This object e.g. includes e.g. the sales order item. Thus, the EBRR manual adjustment postings impact the sales order and market segment margin!
More information about event-based revenue recognition and it’s availability you can get here:
An Introduction to Event-Based Revenue Recognition with Customer Projects in SAP S/4HANA Cloud | SAP Blogs
Closing remarks
We hope you enjoyed this overview on the margin analysis for product sales in S/4HANA. It is another scenario, in which we are now benefiting from the innovations in financial accounting. The Universal Journal provides the great advantage of the inherent reconciliation between general ledger and controlling and margin analysis – and new reporting insights for the accounting applications. With EBRR we have now a tool in place, which ensures the periodic correct realization of revenues and cost of goods sold – providing all market segment information.
Please note that SAP S/4HANA provides additional sales processes:
a tailored end-to-end solution for professional services, which has consultancy, audit and tax companies in scope. More information you get in the blogs mentioned above in the architecture chapter.
Feedback welcome
Okumaya devam et...
Welcome to this blog, in which we will show you how the S/4HANA accounting and controlling innovations influence the sell from stock business process. Central functionality is the universal Journal integrated margin analysis. The screenshots are taken out of a CE 2208 system, but the scenario is valid for OP 2022 too.
In this business scenario an inventory managed product is planned in a sales order item, delivered by outbound delivery to customer and then billed. These process steps create journal entries for cost of goods sold and billed revenue. Additional to the logistic process there are controlling applications available to get a margin analysis for the sales order and market segment.
New in S/4: the market segment is incorporated in Universal Journal and all its attributes are stored in in the relevant G/L journal entry items. The sell from stock logistic transactions create P&L journal entry items, which are account assigned to a profitability Object/Market segment. All co documents are posted in the general ledger.
We will start in this blog with first insights in the financial innovations in S/4HANA and the new reporting capabilities, followed by the explanation of the architecture. Then we will show you an end-to end process for a sell from stock scenario of a manufactured good in the system. We close with deeper insights in the event -based revenue recognition.
1. First insights in financial innovations
In S/4 the accounting applications General ledger, Controlling, event-based revenue recognition and margin analysis are now integrated in the Universal Journal, in which all actual data of margin analysis is stored. There is no separate data store. All KPIs like realized revenues, cost of goods sold, margin per quantity unit or multilevel contribution margin are calculated based on journal entry items, stored in the Universal Journal single source of truth.
Let’s have first a look on the architecture evolution path related to the sell from stock process
Figure 1 S/4HANA controlling evolution 4 sales process
In ERP there was a separation between G/L and the market segment reporting, which also means different reporting entities like G/L account in accounting and value field in CO-PA. The process updates were made at different times: the G/L with delivery and billing, the CO-PA only at the time of billing. Thus, reconciliation was cumbersome.
In S/4HANA all data are stored in Universal Journal; the order entry in the prediction ledger – see next chapters. Delivery and billing update G/L and margin analysis with the same journal entry. The matching principle for revenue and cogs is ensured by event-based revenue recognition. EBRR cares also for the IFRS15 case, when different revenues has to be realized as billed.
Calculatory costs based on SD price conditions are posted in an own management ledger. The CO allocations update the GL. This we will see step by step in our posting example.
Let us start with some impressions about the reporting capabilities of financial accounting for sales processes in S/4HANA.
Figure 2 – app product profitability
In figure 2 you see a multilevel margin reporting for one sales order, 18579, based on journal entries, which are created by the logistic processes and controlling allocation postings. We enrich these journal entries with multiple information. For example:
we store the fixed Amount portion of an cost component split item. What allow us to show the “cogs – fixed amount in CC Crcy”
we store the market segment attributes in all the journal entries, which can be selected by the navigation panel on the left. This allows us to slice and dice the margin flexible by all market segment fields
On the top you see the 4 revenue rows. To get the product revenue, we need to aggregate the billed amount and the realized revenue, created by EBRR based on the delivery postings. The realized revenue shows the matching revenue for deliveries, which are not yet billed.
How we get these figures, we will show you step by step in the system in chapter 3.
An KPI overview for the market segments we get with the app “product and service margins
Figure 3 – product and service margins
In the line items you can select the market segments – here customer and product sold. In the columns we get the KPIs. The recognized revenues are the aggregation of the billed revenues and the realized revenues from EBRR. The accrued revenue/WIP you can drilldown too by all market segments.
Innovation overview for product sales
Using the Universal Journal, we automatically get the following innovations:
- the Universal Journal provides the great advantage of inherent reconciliation between general ledger and management accounting/margin analysis
- all financial reporting is based on journal entries and G/L accounts and not on different data sources and separate entities – there is a single source of thruth.
- we offer new insights into reporting and analysis for sales processes, as profitability attributes are now available for all General ledger Journal entries. The journal entries for Inventory change, WIP and billing you can drilldown e.g. by customer and product sold – example see figure 3
- to ensure matching principle for cogs and revenues we provide event-based revenue recognition. This allows a real-time market segment and margin reporting and ensures matching cogs and revenues, if the goods issues are posted in a different period as the billing. And if applicable EBRR supports the determination of allocated revenue based on IFRS15 requirements.
- Using Universal Journal, we get for all margin analysis postings – Costs and revenues, as well as revenue recognition postings – the option for reporting in multiple currencies
- Simplified extensibility. When we add a new customer specific field – with e.g. market segment extensibility, it will be available in all accounting applications.
- And we get the option for parallel valuation within one company as we provide parallel ledger. So, for example you can realize revenue in one ledger with the goods issue, in a second ledger first with the billing. Example we will show with a system example in the last section of this blog.
The incoming order value and prediction is stored in an extension ledger with the same Universal journal entities and posting logic like in the standard ledger. The posting logic enable us to report the “remaining order value” too – see chapter 3.1. In this extension ledger manual controlling adjustments can be posted.
Manual cost allocations can be posted to sales order and market segment -> see chapter 3.2
The cost component split of a manufactured good is posted in Universal Journal with the outbound delivery with multiple journal entry items – see figure 3.7
Production variances are account assigned to profitability object and posted in G/L (not covered in this blog)
An example for the controlling value flow including the cost centers and their under/ over absorption you get in figure below.
Figure 4 – overview for value flow for sell from stock
In Figure 4. you see, how the different processes generate Journal entry items. All journal entry items in the right table are account assigned to a profitability segment (ACCASTY = EO). The aggregation of the items results in the multilevel contribution margin. Example for the postings we will show in system in chapter 3 – except production process.
2. Financial Accounting architecture
The following picture explains, how the margin analysis attributes are derived and provided in Universal Journal.
Figure 2.1 – market segment account assignment and derivation logic for sales order
With creation of the sales order item a Profitability object, a set of market segment attributes, is derived and assigned to the sales order item. Some attributes are taken direct from sales order item like customer and product sold. Others are derived: e.g industry, country and customer group from customer master. With margin analysis extensibility you can add own attributes. These attributes are added to universal journal! To derive the attributes the app manage substitution/validation is available. Here you can create a rule by selecting business context and event equal “Market Segment”.
If margin analysis is active, we account assign for all sales business processes the profitability controlling object (ACCASTY = EO) – if there is no other co object derived by process for the sales order item like a wbs element. Thus, Cost elements for inventory change and revenue accounts are required! This is different to cost based CO-PA processes, where we use non-operating P&L accounts for inventory change/ cogs and billed revenue.
In the sell from stock scenario we real account assign the profitability segment. This is different to the service and customer project scenario, where we attribute the profitability segment. Example for attributed profitability segments you get here:
professional service customer project scenario
new service management scenario
Project based sales scenario
Extension Ledger
The sales order business transactions like billing and delivery create postings in the legal standard ledger. To apply management accounting specific information, which are not G/L relevant, we provide the extension ledger. Here calculatory costs and management adjustment postings can be applied. And we store here prediction and purchase order commitment information.
In cloud we provide the two extension ledger OE and OC:
Figure 2.2 – extension ledger set-up in S/4HANA cloud
Extension Ledger are assigned only to the leading ledger; in S/4HANA cloud this is ledger 0L.
To get a complete management accounting view, the underlying ledger are always aggregated: when you start a report with ledger 0C, you get the data from ledger 0C plus the data from ledger 0L. If you start a report for Ledger 0E, you get the data for ledger 0E plus 0C plus 0L.
For ledger 2L in this example there are no additional management information available.
Frozen profitability segment
As we stated before the profitability segment is created and stored to the sales order item and used for subsequent delivery and billing. If there is now a document flow in place with multiple sales order objects like debit memo request, credit memo request or return order and you want to report all the related costs and revenues on the original sales order item, you can freeze the original profitability segment for such a document flow. In this case the profitability segment is not determined new in a subsequent sales document, but copied over from the preceding sales order
Figure 2.3 – option to freeze market segment in document flow
In this example the revenues of the debit memo request and the credit memo request have the original sales order 5011/10 in their market segment assigned.
This is the default setting in S/4HANA cloud. It is controlled with the SD copy control customizing, which you can change in on premise.
Realignment
The market segment attributes are derived and updated in the journal entry with the document posting. Later or even during the process attributes may change. For example, there is another product group assigned to the material master or you change the derivation logic of a market segment field. To keep the data consistent and current we provide a realignment with the app “Run realignment – Profitability analysis”. With this app we change the market segment attribute in already posted documents. This is the only use case, in which we update posted Journal entries. Of course, we ensure compliance. Thus, we only update fields that are not relevant for legal reporting. For example, we do not change profit center or segment. For Profit Center changes there is a reorganization tool in place.
3 Margin Analysis for sell from stock process – system walkthrough
We will now show a sell from stock process plus subsequent controlling allocations in a S/4HANA cloud 2208 system.
Let us first look on the product or material master. For our example we created the product SW-Fert07.
Figure 3.1: material master – costing 2 data
There is a standard price for valuation maintained of 15.04 EUR. Every goods issue – like a delivery will be valuated with this price. You see, this price has been calculated with a cost estimate in Period 007/2022
Material dependent Market segment attributes are for example maintained in the sales org 1 tab: the material group = L004 and the Division = 00. In the tab sales General/Plant the profit center = YB110 is assigned.
Now let’s look in detail on this standard price cost estimation.
Figure 3.2: cost estimation – cost component view
In the cost component view you can see the total costs for our product of 15,04 EUR per piece, of which 1,58 EUR are fixed. The value is split according to cost components – for example material costs of 6,77 EUR. We will follow up on this view in the goods issue posting and the multilevel margin reporting.
Now let’s look on the customer master, with the BP role “Customer”
Figure 3.3: customer master – billing
With the account assignment Group customer, here 01, the G/L account determination is determined. Because the customer is located in the same country as assigned company code Domestic revenues will be posted.
The selected Term of payment 0002 will lead to a statistical discount condition in SD pricing of 2%. We will come to this later when we will post the billing
In the same role in the tab orders the customer group 01 is defined.
In the BP role “customer FIN accounting” the industry “91 trading” and the country DE is defined. All three attributes are part of the standard market segment.
Now we start the business process with the sales order creation – app create sales order
Figure 3.4: sales order – overview
As Sold-to-party and ship-to party we enter our customer 10100001 we show before.
We enter one sales order item for product SW-Fert07 with an order quantity of 10 pieces. There is a sales price maintained of 30 EUR per piece.
We double click on the item to get the item view and select the tab account assignment. From there you can get to the market segment screen below by selecting the button Profitability segment.
Figure 3.5 sales order item – assigned profitability segment
You see the attributes taken from sales order: customer and product and the sales area. When you scroll down you see additional attributes derived from product and customer master. Customer group, country of the customer and Industry are derived from customer master. The material group from product master.
With these market segment fields all Journal entry line items of subsequent business processes will be updated.
Now we create an outbound delivery for our sales order by starting the app ‘create outbound deliveries from Sales Orders’.
Figure 3.6: outbound delivery
We deliver 5 of the planned 10 pieces and post goods issue. Let’s look on the posted journal entries in ledger 0L. We start the app “Display line items – margin analysis” with the selection of the reference document equal to the outbound delivery material document.
Figure 3.7 journal entries posted by outbound delivery
We see that the prima nota, the goods issue of delivery (visible in reference document number 4900010019) generates 3 journal entries.
The second journal entry is the goods issue, which credits the inventory and post cost of goods sold to market segment.
The third journal entry provides the cost component split of the product in the Universal Journal. In the first line item the cogs line item of the goods issue posting is reversed. The other line items post on G/L accounts reflecting the cost components. Their values are taken from the cost estimation of the product – see Figure 3.2. Please recognize the fixed Amount column: here the fixed portion of the cost component split is updated. There can be fixed portions for the activities and the overheads. In our example there was a fixed portion for machine time of 9,76 USD. Please note, fixed amount is stored in global currency only.
The first journal entry is the event-based revenue recognition posting. In Ledger 0L we realize the revenues already with the cogs posting of the goods issue. We deliver 5 pieces and we have maintained a selling price of 30€/ per piece in the sales order item. Thus, we can realize 150€ revenue.
With the event-based revenue recognition journal entry we ensure event-based matching principle: cogs and realized revenue always match. This is especially important if delivery and billing is not in the same period.
Remark: in ledger 2L we have implemented a different revenue recognition method: we realize revenue first with billing. How this parallel valuation looks like, please see parallel valuation in chapter 4.
Except the inventory line item all line items are account assigned to the profitability segment (column Account Assignment Type = EO). With this we get multiple market segment fields derived and stored in the line items. You see them in the right columns: customer. Product sold, customer Industry, sales organization.
Now let’s come to next business transaction, the customer billing.
We start the app “Create Billing documents” and enter as reference document the outbound delivery, visible in figure 3.6. With entering return, we get to invoice proposal, which we save. With this we get the journal entries posted. Let’s have a look on the pricing data of the invoice.
Figure 3.8: billing document – pricing data
In the condition scheme you see at the bottom two statistical condition types. Statistical conditions do not influence the sales price determination. They are used for additional information, and they can be included in margin analysis reporting.
Let’s look in detail on the cash discount. DCD1 is a Cash Discount we offer to the customer. In our case this is triggered by the business partner attribute Terms of payment – see Figure 3.3. We expect the customer to take advantage of this when paying, but it does not affect the total invoice price. For the delivered and billed 5 pieces there will be a discount offered of 2% of 178,50€ (150€ product price plus 28,50 output tax – see screen shot on top) = 3,57€ We will see this value of in our margin reporting as sales deductions.
Let’s have a look on the posted accounting documents. With selecting the Accounting button, we get the popup below.
Figure 3.9: overview of journal entries posted by billing document
Journal entry 4 is the accounting document for the invoice: the journal entry items for the billed revenue, receivables and tax. It is handled as prima nota and posted in all active standard ledger with the same values.
Journal entry 1 to 3 are EBRR postings. There is an own document per standard ledger, for which the postings can differ per ledger.
The fifth document is posted in the extension ledger OC, the ledger for additional management adjustment postings. Here the management posting for the statistical sales condition is stored.
Documents 6 and 7 are technically documents to support additional controlling features.
Now we will analyze the corresponding financial documents with the app Display line items – Margin analysis
Figure 3.10: journal entries posted by billing document
The second document is the General ledger posting of the invoice. We debit receivables domestic and credit domestic revenues and tax. Please recall the domestic revenue G/L account group in the business partner – Figure 3.3.
The third document is the management posting for the statistical sales condition. It is posted in the extension ledger OC, the ledger for additional management adjustment postings. The second line item is the posting on the profitability object, which provides all market segment information. The used P&L G/L account cash discounts will update the sales deduction in the multilevel margin reporting. As we follow the logic of double-entry accounting in the extension ledger too, we need an additional line item, which balance the document to zero. The first journal entry item posts against an accrual account without any market segment relevant attributes.
The first document is the revenue recognition posting. We realized already revenue with the cogs posting of the delivery in ledger 0L. Now we get additional billed revenue. Thus, we need to reverse this already realized revenue.
Now let’s have a look how these two business transactions impact the multilevel margin reporting for our market segment reporting – represented by our example sales order 18579. To get the management posting included, we select with the extension ledger OC.
Figure 3.11: multilevel product contribution margin – after delivery and billing
We get a three-level margin reporting. The line items are semantic tags, an aggregation of G/L accounts, taking fix and variable costs in account.
Contribution Margin I is the sum of the billed revenue, minus the sales deduction of 3,57€ we posted in the extension ledger and the variable costs of the product, we get from the cost component split. In our case this leads to a margin I of 79,10€.
Margin II includes the fix price portion of the product. In our case the 7,87€ of the machine time – see cost component split in Figure 4.2. This leads to a contribution margin II of 71,23 €
Additionally, the margin I per billed quantity is provided. We billed 5 pieces, so we get a margin of 15,82€ per piece.
3.1 Sales Margin Prediction
With the creation of a sales order, we calculated the expected costs and revenues and store it in the prediction ledger 0E – please recap architecture chapter and figure 2.2. We get these values by simulating the delivery and the billing. This leads to the following order entry/ incoming sales order value in our example with the app “Incoming sales orders – prediction accounting”:
Figure 3.1.1 incoming sales order reporting
When you recap figure 4.4, we planned in the sales order item 10 pieces with a price of 30€, so an order value of 300€. The cogs for 10 pieces are 150,40€. All KPIs are based on Journal entries, which you can access on the bottom.
Same as in legal ledger we follow for the prediction JE the principle for double-entry bookkeeping. The created journal entries for prediction look similar the JE for billing and delivery we showed above for the actual postings. We get them with selection of ledger OE.
Figure 3.1.2 Order entry Journal entries for sales order 18579
Please recognize that we even post the cost component split, what allows a detail margin analysis for the prediction reporting.
As mentioned above we do not only store the Values for every new created and changed sales order; we update prediction ledger with every subsequent posting. In our example we delivered and billed 5 pieces. This reduces the remaining order value to 5 pieces, result is 150€ open revenue, same the expected cogs are reduced.
We get the remaining order value for our sales order 18579 with the same app, but select in the filter “remaining orders” instead of “incoming orders”:
Figure 3.1.3: update prediction ledger remaining sales order
For our example sales order 18579 there remains an order value of 150€. With the Journal entries on the bottom, you see here the value of 300€ created with order entry and the reversal of 150€ with the billing.
All data for order entry and remaining order volume we get out of the prediction ledger OE.
3.2. CO allocation postings
Now we show, how you can apply special direct costs and periodic allocation postings with reference to a sales order. With margin analysis activated these transactions will be stored in Universal Journal in a legal ledger – like the other sales process postings – with account assignment type “EO”!
Manual allocation postings
To apply special direct costs, you can account assign the profitability segment in many transactions like reassign cost and revenue app (for example KB11N), manage direct activity allocation (KB21N) or post General Journal entry (for example FB01).
Let’s post a direct activity allocation
Figure 3.2.1: activity allocation for 1 hour R and D effort
In the line item for 1 hour R&D you see that the Receiver Profitability Segment is Assigned.
There is a pop up available, in which you can maintain the profitability segment.
Figure 3.2.2: activity allocation – market segment pop-up
We maintain the sales order 18579/10 as market segment, as well as Customer and product sold. Material group, Country and Industry will be derived.
Let’ look on the created Journal entry.
Figure 3.2.3: activity allocation journal entry
The one hour R&D time is posted against the profitability segment, in which the sales order item 18579/10 is assigned. It will be part of the margin contribution of the sales order – see below figure 3.2.8
Please recognize, these management postings are not taken in account in revenue recognition, the posted costs are just realized. In the EBRR methods for sales processes we take only the logistic processes billing and delivery in account.
Periodic Margin Analysis allocation postings
Now we come to the allocation of periodic costs to market segments. These costs cannot be applied direct to a market segment or even a sales order item with the primary posting.
In our example, periodic freight costs of €1000 have been incurred. They are initially posted to an unspecified market segment:
Figure 3.2.4: 1000€ of freights posted to market segment
The periodic freight costs should be allocated to the sales orders, which are billed in this period. The allocated freight amount should be weighted according to the billed revenues they generated.
Figure 3.2.5: postings on receiver market segment
In sum we have an Amount of 927,65€ billed. The billed amount of our example sales order is 150€. We expect with the allocation an amount of 150/927,65 * 1000€ = 161.70€ to our sales order 18579.
Now let’s create a top-down distribution cycle for the freight costs with the app “manage allocations”. There is an own Allocation context for “margin Analysis.
Figure 3.2.6: margin analysis allocation cycle
There are 3 different methods available to allocate costs to market segments: Distribution of costs, overhead allocation for e.g. allocation of over-/under absorption of a cost center to market segment and the Top down distribution.
All these 3 allocations post in a legal ledger. There can be a single ledger selected for the rule. But if the rule should be applicable for all ledger, you can flag the checkbox “Flexible ledger” in the rule’s processing indicators.
We create one for the freight costs and start the allocation run. The posted Journal entries you see here:
Figure 3.2.7: postings of Top down Distribution run
There is an own business transaction type applied for Top-down distribution, AAAT.
In a first journal entry item the costs are reversed from the original market segment with no specific attributes.
In the rule we specified the allocation receiver by customer, product sold and sales order header. Thus, the allocated freight costs are enriched with these attributes.
In the third line you see the allocated freight costs of 161,70€ on our example sales order – as expected.
The activity allocation and the freight TDD has impact on the contribution margin of our sales order example:
Figure 3.2.8: final contribution margin for our example sales order
The freight costs are assigned to the sales overhead costs, for special research and development costs there is an own contribution margin item.
In this case we get a negative CM III KPI.
4 Further insights in revenue recognition
We have seen above that event-based revenue recognition is integrated in the sell from scenario. In our example revenue recognition postings were triggered with goods issue and customer invoicing.
Let’s have here a deeper look on the revenue recognition options for sell from stock scenario.
Activation of event-based revenue recognition
Activation of Event based revenue recognition occurs when the sales order item is assigned to a revenue recognition key.
The revenue recognition keys are in cloud predefined. A revenue recognition key defines how the values are calculated and at which point in time costs and revenues are realized.
For the sell from stock process there is a specific revenue recognition derivation table available – see figure 4.1. The derivation depends on the company code, sales order item category, value chain category and the material maintained in the sales order item. If the derivation logic should be independent of the material, it is possible to maintain a star. If a process should not be relevant for revenue recognition, the rev rec key can be kept initial.
Figure 4.1 revenue recognition key derivation logic
To track all relevant steps of the business processes:
- Advanced Intercompany Sales
- Advanced Intercompany Stock Transfer
- Sell from Stock with Valuated Stock in Transit (VSiT)
the value chain category is introduced. The category is the basis of the value chain monitoring. In addition, the information can be used to derive a revenue recognition key. This has the advantage that the different business processes are flexibly supported by event-based revenue recognition.
There are four value chain categories available:
| Category | Value Chain Description |
| “Initial” | Standard Sell from Stock |
| ICSL | Intercompany Sales Process |
| ICST | Intercompany Stock Transfer Process |
| SFSV | Sell from Stock with Valuated Stock in Transit Process |
Information to Value Chain Monitoring you can get here SAP Help Portal
The checkbox ‘Bundling’ is required to enable additional IFRS15 functionality. With this it is possible to use IFRS15 revenue allocation between items within a sales order.
These are the available revenue recognition keys in S/4HANA cloud:
| Recognition Key | Revenue Recognition Key Description |
| SFS | Recognize revenue based on an invoice simulation |
| SFSCCM | Recognize costs and revenue as occurred when finally billed or completed, otherwise defer costs and revenue |
| SFSN | Recognize costs and revenue as occurred |
| SFSR | Recognize costs on revenue based POC using plan costs from material price, plan revenue from conditions |
| SFSSSM | Recognize revenue based on an invoice simulation, balance sheet-related items are posted as assets always |
Let’s take a closer look at the revenue recognition keys and method associated with them.
The revenue recognition methods
Recognize revenue based on an invoice simulation (revenue recognition key SFS)
The revenue recognition key ‘SFS’ you can use for a sales order item, which uses delivery-based invoicing. With the applied method costs and realized revenues will be posted with goods issue posting. Posting revenue and costs at the same time, enables the matching principle and allows a profitability anaylsis in real time. The revenue value is determined with an invoice simulation.
Figure 4.2 posting logic for key SFS, realization by delivery
(1’) and (3’) With goods issue posting, accrued revenue is calculated by simulating an invoice for the current delivery. The amounts of the accrued revenues are posted using the document currency of the sales document item as document currency.
(2’) and (4’) Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition to deferred revenue. The currency amounts for deferred revenue are copied from the primary posting.
(5) Period-end closing does a balance sheet clearing between accrued and deferred revenue.
If there is at period-end run the sales order item status ‘finally delivered’ and ‘finally invoiced’ possible balances on deferred revenue and accrued revenue will be cleared.
A system example for this method you get in chapter 3 before. Please recap figure 3.7 for the delivery and figure 3.10 for the billing
Recognize costs and revenue when finally billed (revenue recognition key: SFSCCM)
If the revenue recognition key ‘SFSCCM’ is used for an sales order item, which uses delivery-related invoicing, costs and revenues will be deferred until the sales order item is completed. With sales order item completed (‘finally delivered’ and ‘finally invoiced’), the posted billed revenue and costs will be realized. The next period-end run will realize revenue and costs and cancel all remaining accruals and deferrals.
Figure 4.3 posting logic for realization with completed contract
(1’) and (3’) With goods issue posting, cost adjustment and deferred CoGS is triggered.
(2’) and (4’) Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition to deferred revenue. The currency amounts for deferred revenue are copied from the primary posting.
(5) With period-end and the sales order item status ‘finally delivered’ and ‘finally invoiced’ balances on deferred revenue and deferred CoGS are cleared and revenue and CoGS are realized.
In our system example before we applied a completed contract method for the parallel ledger 2L. This lead for the goods issue of the outbound delivery to the following postings.
Figure 4.4 posting logic for realization with completed contract
The costs are just deferred. Different to the posting in ledger 0L, in which we realized revenue already with the cogs posting by invoice simulation.
Recognize revenue based on an invoice simulation without liability posting
To support such posting logic, you have to use the revenue recognition key SFSSSM. The realization logic is the same as for revenue recognition key ‘SFS’, but the used accounts are different.
Figure 4.5 posting logic revenue recognition key SFSSM
In real-time processing, accrued revenue is created by simulating an invoice for the current delivery. Invoices are posted by the primary posting to an income statement account and are reposted by revenue recognition direct to the accrued revenue account. We do not use here the deferred revenue account like we do in SFS scenario.
Process “Sell from stock with transfer of ownership” (incoterms)
The requirement to realize revenues with the transfer of ownership is also supported.
For this requirement you have to refer to the sell from stock with valuated stock in transit functionality. The process must be activated in logistics and the corresponding category must be maintained in derivation table for revenue recognition keys. The category for the valuated stock in transit is ‘SFSV’.
When using incoterms, the system posts to stock in transit until the transfer of control according to the incoterms happens. This logic is built into the sell from stock functionality.
Once the transfer of control happens, the system credits the stock in transit account and posts cost of goods sold. If you use the revenue recognition key SFS, this is also the trigger to realize revenue and post accrued revenue real-time.
Using SFS, the billed revenue from the invoice is deferred – you may have to create the invoice prior to the goods issue being posted. Under SFS, the period end then clears accrued and deferred revenue.
Sell from Stock with Valuated Stock in Transit SAP Help Portal
Transfer of Control of Goods SAP Help Portal
Valuated Stock in Transit SAP Help Portal
Parallel valuation
Two different keys are needed to support parallel valuation. To set up a parallel valuation an additional customizing must be maintained.
Figure 4.6 SSCUI for different revenue recognition valuation per ledger
With this configuration step you can define a deviating recognition key for a specific accounting principle In our example there is a standard key maintained, which realizes revenue with the goods issue (key SFS). This key is stored in the sales order item. We assign here now for the accounting principle DEAP, which is applied in the ledger 2L, the key SFSCCM, which refers to the completed contract method. This key is not stored in the sales order item. It is taken in ledger 2L from this table, when EBBR runs for a project with key SFS
The resulting different posting logic we show you for the delivery posting in our system example.
In ledger 0L we realize revenue with the goods issue/ cogs posting see figure 3.7
Figure 3.7 realization of revenue with cogs posting
In the parallel ledger 2L we defer the cogs – see figure 4.4
Figure 4.4 completed contract method- cogs are just deferred
In ledger 2L we applied completed contract method. Thus, the cogs of 75,20€ are 1:1 deferred – see journal entry 3.
You see, that one prima nota can trigger different revenue recognition postings in different ledger.
The revenue recognition monitor / applying temporary adjustments
Event-Based Revenue Recognition provides in addition the option to adjust realized costs and revenues of the current posting period. A manual, temporary booking is carried out via the App ‘Event-Based Revenue Recognition Sales Orders’. You select sales order, here 18638, the ledger, period and company code.
Figure 4.7 App ‘Event-Based Revenue Recognition Sales Orders’
Within this App you get information about the KPIs like realized revenue and costs and you get additional options
- ‘Revalue’ can be used to initiate a period end posting for the selected sales order item and ledger.
- Change Revenue Recognition Key. With selecting ‘Change Recognition Key’ the assigned key in the sales order item can be changed. The already executed postings will be recalculated and reported in the selected period – based to the posting logic of the new revenue recognition key
- G/L Account Line items. The corresponding App is called for detail posting information on the selected sales order item.
- ‘Enter Temporary Adjustment’
Let us focus on ‘Enter Temporary Adjustment’:
currently 30.08 € costs are posted and 100,00 € matching revenues are realized. We select the button ad get the figure below.
Figure 4.8 Event-Based revenue recognition ‘Enter Temporary Adjustment’
In our example we adjust both, costs, and revenues. The new recognized costs should be 28.00 € and the new revenue value should be 110.00 €. We enter the new values and hit button “Simulate”.
As you can see on our screen shot the recognized costs are reduced by “cost adjustment”; as offsetting account Deferred costs/ WIP is used. The revenues are increased, as the revenue adjustment amount is increased by 10€. As offsetting account Accrued revenue is used. It is also possible to adjust only the costs or only the revenues. The adjustments are reversed with the next period end run.
Let’s have a look on the created journal entry items:
Figure 4.9 Event-Based revenue recognition ‘Enter Temporary Adjustment’ journal entries
Four journal entry items are created by EBRR adjustment posting. As the other EBRR postings all 4 journal entry items are account assigned to a profitability object. This object e.g. includes e.g. the sales order item. Thus, the EBRR manual adjustment postings impact the sales order and market segment margin!
More information about event-based revenue recognition and it’s availability you can get here:
An Introduction to Event-Based Revenue Recognition with Customer Projects in SAP S/4HANA Cloud | SAP Blogs
Closing remarks
We hope you enjoyed this overview on the margin analysis for product sales in S/4HANA. It is another scenario, in which we are now benefiting from the innovations in financial accounting. The Universal Journal provides the great advantage of the inherent reconciliation between general ledger and controlling and margin analysis – and new reporting insights for the accounting applications. With EBRR we have now a tool in place, which ensures the periodic correct realization of revenues and cost of goods sold – providing all market segment information.
Please note that SAP S/4HANA provides additional sales processes:
a tailored end-to-end solution for professional services, which has consultancy, audit and tax companies in scope. More information you get in the blogs mentioned above in the architecture chapter.
Feedback welcome
Okumaya devam et...