
We will start with an overview of the innovations provided by event-based revenue recognition. Then we will explain the guiding principles – especially how it supports the cloud principles and why it is so easy to use and transparent.
Many management accounting features are incorporated into event-based revenue recognition, which we touch. And we give an overview of the revenue recognition capabilities – including IFRS15 bundling functionality.
Finally, we provide links to further documentation and a remark regarding on premise availability.
Innovations in Event-Based Revenue Recognition
Event-based revenue recognition covers service industry requirements for a comprehensive revenue recognition functionality, and in particular the desire for an easy-to-use application supporting a simplified period-end close that covers the required legal functionality.
In on premise, revenue recognition functionality for customer projects with Time and Material and fixed price contracts is covered by results analysis. In results analysis, the calculated values are stored in a separate revenue recognition persistence and need to be settled to Accounting and CO-PA at period-end. Additional steps are necessary to reconcile the different applications (G/L, revenue recognition and CO-PA). Using Results analysis profitability information is only available after period-end closing.
Event-based revenue recognition is incorporated into journal entries in the Universal Journal and has no separate persistence – hence no reconciliation efforts or settlement are required. The calculated results are immediately available in the general ledger, together with the original posting on the customer project – e.g. time confirmation. Using the new margin analysis application, which is incorporated into the Universal Journal, the revenue recognition G/L line items already include market segment information. This means that settlement of customer projects as a step in the period-end closing is obsolete.
One important characteristic of event-based revenue recognition is that it inherently supports the matching principle for all postings. For every cost and revenue posting, the corresponding revenue recognition journal entry is created in real time. This allows up-to-date P&L and Profitability reporting -and WIP.
We fulfill not only balance sheet valuation requirements, we're also providing new management accounting functionalities with event-based revenue recognition – see examples below.
Thanks to event-based revenue recognition and the integration of market segment reporting into journal entries, amazing new reporting insights are now available – which can be seen for example in the Project Profitability Overview app.
Figure1: Project Profitability Overview app
What’s new about the report?
Always current, unique and expressive figures – reconciled by design. There is only one margin provided in the system - by revenue recognition in the Universal Journal. (In on premise there are different sources and data tables in G/L, CO, results analysis and CO-PA, which could show different values). The report is always up to date as soon as you start it, since the matching principle is supported inherently. There is no need to run period-closing jobs for revenue recognition and settlement before. Costs match revenue every time.
Supporting timely management decision-making. Up-to-date reporting – including margins – is available after every posting – for every project and market segment, such as customer group, sales organization or product group. Additionally, on the rightmost tile you get margin by profit center, origin (supporting) profit center and resource type.
New reporting insights. Drill-down for G/L accounts such as revenue and WIP on project, and profitability attributes such as customer group or product group.
All this provides benefits for several roles in S/4HANA:
Accountant
Controller
Project Manager
Real-time matching principle to provide profitability reporting that is always current
Revenue recognition postings are generated simultaneously with the source documents and directly stored in Accounting – this allows us to provide a real-time matching principle.
The entry of a source document, such as a time confirmation or expense posting, creates two separate journal entries (see figure 2).
Figure 2: Event-based revenue recognition supports the matching principle: one source document creates two journal entries
A postings overview based on T-Accounts you see in figure 3.
This posting logic is the same for fixed price and time and material billing, when revenues realized with the confirmation - based on POC.Figure 3: General posting logic of event-based revenue recognition with real-time matching principle
With (1a) the revenue recognition document is posted based on the time confirmation (1). The realized revenue is calculated based on POC: actual costs of the confirmation divided by planned costs => 100 EUR/ 10.000 EUR = 1%. This is multiplied with planned revenue of 12.000 EUR => 120 EUR realized revenue.
With (2a) we defer the billed revenue event-based, as revenue realization already took place with the confirmation. This leads in income statement for this project to an aggregated view of billed revenue of 110 EUR plus already realized revenue of 10 EUR.
With the revenue recognition period-end run (3) the accrued and deferred revenue will be balanced on period-end with €110. So, at period-end there will be for this project a balance of €10 on the accrued revenue account.
Balance sheet corrections we do with a period-end run.
The revenue adjustment is a G/L account, on which revenues are shown temporarily. When the project is completed, this G/L account will be balanced to zero – the same as the balance sheet accounts for accrued and deferred revenue.
In Figure 4 we show how the G/L postings for this example look like in S/4HANA Cloud. With this we come to the next principle of event-based revenue recognition.
Event-based revenue recognition is incorporated into the Universal Journal
With this principle we avoid the need for any reconciliation between revenue recognition data and G/L and we can enrich the information available in the journal entries, which enables new reporting insights. This of course also greatly simplifies the period-end close process.
Figure 4: Example of a CATS time confirmation for a fixed price project with the matching revenue recognition document
The first journal entry is the CO posting for the time confirmation (transfer between cost center and project) – this is like on premise.
The second journal entry is created by event-based revenue recognition with its own business transaction type TBRR
Column 3 shows the reference document. Column 4 shows document type CATS – time sheet document, which is the basis for both journal entries. We now have a link from the revenue recognition posting to the time sheet source document and vice versa. This simplifies tracing and auditing.
A new field in journal entries is Object Type (column 7, technically ACDOCA-ACCASTY). This field qualifies the real account assignment. It is needed because we now allow to store account assignments in parallel in one Journal entry item. In this example we provide the WBS element (column 8 and sales order item (columns 14 and 15) in one Journal entry. The real account assignment in lines 2 to 4 is PR, the WBS element. Hence the revenue recognition postings - including the balance sheet journal item - are posted on the WBS element. The sales order item is just an additional attribute (for more information on the functionality, see the next section or this blog co account assignment and attribution with S/4HANA ).
In any case we do not need to settle anymore, since the profitability attributes are already applied in the revenue recognition journal entry. Additional reporting attributes, such as Customer or Service Product, are derived for every revenue recognition posting (income statement and balance sheet items).
We provide a single source of truth for all Financials and Controlling purposes – now also including Revenue Recognition data.
Event-based revenue recognition is highly integrated into logistics processes
As an example, Let's take a look at the professional service scenario.
To every customer project there is a sales order assigned and to every WBS billing element the sales order item – see figure 6. The sales order item defines the customer contract and determines the revenue recognition method. All contract-related information is stored in the sales order. There is no separate persistence for revenue recognition, which helps us to avoid reconciliation issues. The required data for revenue recognition is provided already when the sales order item or contract is created.
Below you see the “Billing” tab in the customer project, which reflects the view on the assigned sales order (here sales order 29754)
Figure 5: Billing tab in the customer project – a simplified view of the sales order item/contract
On the Billing tab, the contract type (identical with the sales order item category) and the sold product are defined, based on both the revenue recognition key and method is derived.
The values in billing plan are basis for revenue recognition in fix price scenario and periodic Service.
In case of T&E scenario there are sales materials for the confirmations in the T&E application derived. For this sales materials sales prices are defined as pricing conditions in the SD billing application. These prices we take for calculating the realized revenue.
Event-based revenue recognition supports a simplified Cloud setup
As mentioned in Financials for customer project blog 1 there is in cloud a clear guidance and subsequent checks for completeness implemented in customer project set up to allow a real-time revenue recognition posting and profitability segment enablement.
An important aspect is the 1:1 relationship between sales order item and WBS billing element. This allows a clear definition of the revenue recognition key and method based on the sales order item – see figure 6
Furthermore, within one billing element tree only one Profit Center is provided, which can be maintained on the billing element level.
A customer project can only be released when all work packages are assigned to a project billing element. This guarantees that all data are available for revenue recognition when a confirmation hits the work package.
Figure 6: Object setup in S/4HANA public cloud professional service scenario
The costs are always posted to work packages. Revenue recognition considers all postings in the WBS billing element tree. The calculated revenue recognition values are posted as revenue adjustments (P&L) and WIP/ Accrued revenue on the billing element.
In S/4HANA Cloud best practice content is provided. This allows an out-of-the-box revenue recognition functionality and posting for every customer project and its assigned postings.
As you see in figure 5 there are only 3 contract types provided - with S/4HANA 1905, which cannot be enhanced or changed by customers. For these contract types the end-to-end processes are supported by all involved applications.
The business scenario defines the valuation of the processes and the revenue recognition method, thus there are very view customizing activities open to the user – mainly for derivation of customer preferred G/L accounts.
Event-based revenue recognition covers more than the legal requirements. We incorporated several management accounting features, too – affecting the P&L Journal entry items.
Event-based revenue recognition supports real-time profitability
The purpose of event-based revenue recognition is to enable real-time profitability information in the income statement, and as an additional effect real-time WIP. This is the answer to the request of project managers to get an up-to-date view of the margin and the unbilled revenue of the project.
Event-based revenue recognition calculates target revenue in fixed-price scenarios
This functionality is described in this blog: https://blogs.sap.com/2018/07/27/financial-accounting-for-customer-projects-in-sap-s4hana-cloud-part...
In a fixed-price scenario, to provide information about the revenue an employee would generate if he worked for a T&M contract, we calculate this value during revenue recognition too and post it as target revenue. This has no impact on legal reporting, it’s just for cost accounting purposes.
Profitability attributes for all revenue recognition postings
When we create a journal entry for revenue recognition, we use the Universal Journal profitability functionality to get the market segment attributes – same as for every single confirmation on the project (see figure 6). The steps are:
The derived profitability attributes are persisted in the P&L- and balance sheet item.
Please recognize the real account assignment – relevant for e.g. rev rec – is the WBS element. The sales order item is just an attribute. The real account assignment is defined by the journal entry field Object Type (technically ACDOCA-ACASTY) – see column 7 in figure 4
This profitability attribute derivation for every posting is the basis of real-time profitability margin reporting in figure 1 and figure 8. These attributes in the balance sheet item enable drill-down on WIP by, for example, Customer and Product Sold.
Event-based revenue recognition provides employee profitability
One requirement in the professional services industry is to provide employee profitability. This means we need to show revenues at the employee level. Not only billed revenue, but also realized revenue.
In a T&M contract scenario, where the billing is based on time confirmations, we now store in each confirmation the employee in the WIP and the realized revenue item – see example below in figure 7.
(In fixed-price scenarios we cannot provide this information on original posting, here the added target revenue items support this reporting requirement.)
Figure 7: Time confirmation on a T&M contract type
This allows real-time employee profitability and drill-down on WIP by employee for T&M scenarios.
In the Project Profitability app, you can get the real-time margin for several attributes - including employee:Figure 8: Project Profitability app
Event-based revenue recognition supports prediction valuation based on project resource planning
Customer project resource planning can be distributed across periods. This provides us with periodic cost planning. Based on the costs by period we calculate the matching plan revenues for period with the event-based revenue recognition. The transferred costs and calculated revenues we store in ACDOCP.
Hence, plan revenues are available in the exact periods and become available for forecast reporting. The revenue recognition method is the same as for actuals and depends on the sales order item category.
enhanced reporting capabilities
with EBRR a WIP breakdown by project and market segment is availble - see blog financial accounting 4 customer projects
Figure 9: WIP drilldown by market segment and project
With CE2402 it is possible to analyse for customer projects with T&E billing the open hours in WIP and the bill product, additional write offs and CAP amounts can be analyzed: blog advanced WIP reporting for customer projects
Customer downpayment request and received customer downayment can be anlysed in finacial reports. Received customer downpayment can be recognized by EBRR: blog customer downpayment 4 customer projects
Supported contract types
In fixed-price scenarios we calculate the percentage of completion based on plan and actual costs and revenues. The planned cost we get from CPM resource planning. Plan revenues are taken out of the billing plan.
Contract type Time & Material billing – including Usage Based Billing: for revenue recognition calculation we simulate for each cost posting/ confirmation on a customer project the time and material billing. The same as for billing, sold products get mapped and with this information pricing is called. Hence, we even get project-specific prices for revenue calculation (if maintained). We get the same result for revenue recognition valuation as for billing.
For contract type Periodic service we realize revenue based on the time-based billing plan. In this scenario, for every billing plan item a valid time frame needs to be maintained. Based on this time frame we distribute the realized revenues to the periods. Revenue is only realized with the periodic run. Hence, the billed revenue we completely defer.
Realization methods
Cost based: Revenues are already realized with the confirmation – we calculate the POC for every line item by dividing the actual posting amount by the total planned amount on the wbs element tree – see figure 6. Realized revenues are calculated by multiplying this POC with the total planned revenues.
Revenue based: Costs are just deferred as WIP as they occur. Realized revenues are equal to the billed revenues. Costs follow revenues. If lower costs are already confirmed – only possible in fixed price scenario – reserves for missing costs are accrued - see figure 9
Completed contract: During the lifetime of a project, all costs and revenues are just deferred. First with status completion, all billed revenues and posted costs are realized. In the fixed-price case we additionally determine the status completed if no billing plan item is open anymore.
Manual accruals: Manual accruals can be posted by the event-based revenue recognition app. On separate G/L accounts, by providing a comment, which is stored in journal entry item text, account assigned to the WBS billing element. The manual accruals are automatically cleared with the status completed.Figure 9: Posting logic in case of revenue based revenue recognition
This realization method is used for accounting principles which do not allow to realize revenues already with cost posting.
With (1a) the actual costs are just deferred
The billed revenue is equal the realized revenue. With 2a) we post the matching cost of sales. The calculation is done on the planned values. POC = actual revenues/ planned revenues = 0,5%. realized costs are planned costs multiplied with 0,5% = 50€.
IFRS15 bundling/ revenue allocation functionality provided in event-based revenue recognition
Event-based revenue recognition covers the common IFRS15 requirements in customer project scenario:
It is provided for the following scenarios:
The following IFRS15 specific enhancements are available:
With IFRS15 functionality activated the following processes impact event-based revenue recognition:
Sales order creation/change:
Confirmation on a fixed-price project leads to following posting:
Goods issue in sell from stock scenario leads to following posting:
Invoice posting of the IFRS15 relevant sales order item:
Period-end closing enhancements in event-based revenue recognition:
Additional information regarding IFRS15: https://blogs.sap.com/2018/02/02/revenue-recognition-in-context-of-ifrs-15-with-sap-s4hana-cloud-mad...
In on premise, the event-based revenue recognition functionality is released for projects and service management. The scenarios looks different in on premise and public cloud.
The professional service customer project scenario described here is not available in on premise. To achieve event-based revenue recognition in on premise, several tasks need to be organized in the implementation project, for example assignment of sales order item to billing element, billing plan on sales order item, the derivation and storage of revenue recognition key on billing element, complete planned costs on project in case of fixed price.
In service management are additional scenarios avaiable in on premise - like the advanced execution order.
Please take a look at this note for current information Note about EBRR availability in OP 2023
comprehensive information about EBRR functionality you can get with this E Bite Introducing EBRR with S/4HANA
Event based revenue recognition is available for service: blog financials for service
Event based revenue recognition for ETO/ project based sales blog financial accounting for project based sales
Event based revenue recognition for sell from stock https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/margin-analysis-4-sell-from-s...
Event based revenue recognition cookbook on SAP Learning Hub:
https://jam2.sapjam.com/groups/5gwxDPWQPRtOvMO8Xnd32Q/documents/ZmWxs3ehEcZhqZTRovBEjy(Valid Learning Hub license required)
or here in SAP Activate https://support.sap.com/content/dam/SAAP/SAP_Activate/S4H_645%20Revenue%20Recognition%20Cookbook%20S...
Note for Account determination: https://launchpad.support.sap.com/#/notes/2778479
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
6 | |
5 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 |