An Introduction to Event-Based Revenue Recognition with Customer Projects in SAP S/4HANA Cloud

Co-Authored by Gabi Hoffmann and Stefan Walz

In this blog we would like to give you an introduction to event-based revenue recognition, which was initially built in S/4HANA Cloud to cover the revenue recognition requirements of the professional services industry.

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 simple to use and transparent.

Many management accounting features are incorporated into event-based revenue recognition, and we give an overview of the corresponding revenue recognition capabilities – including IFRS15 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 Profitability, 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 Profitability 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

• Simplified period-end-closing, supporting fast close
• Balance sheet and income statement reporting based on individual journal entries
• WIP drill-down by market segment/project
• Enhanced analysis capabilities for revenue recognition values, for example drilldown to G/L items and reference to source documents. This provides greater transparency of calculated revenue recognition postings – as well as reduced auditing effort.
• No reconciliation between revenue recognition data and G/L is necessary
• Repeatability – for example in case of incorrect contract data at the time of revenue recognition

Controller

• Real-time margin reporting per project and multiple market segments
• Profitability views for multiple new attributes are available – such as Employee, Resource, and Service Product
• For customer project planning revenues calculated by revenue recognition, so plan revenues calculated for exact periods and available for forecast
• Target revenue is calculated and posted in fixed price scenario

Project Manager

• Real-time project margin reporting
• Always current WIP/ unbilled revenue information on project and employee level: basic information about items to be billed

Principles of Event-Based Revenue Recognition

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).

• A journal entry for the initial source document; here it is the time confirmation, the “CO” document
• The matching revenue recognition journal entry;  here the realized revenue is calculated based on the POC, “Percentage of completion”, (actual cost divided by planned cost) and posted with the revenue recognition G/L account Revenue Adjustment.

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 never real-time, only 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. We enrich the information available in 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.

• Item 1 credits the cost center with output service based on activity type T002
• Item 2 debits the project (with quantity) and partner activity type T002

The second journal entry is created by event-based revenue recognition with its own business transaction type TBRR

• Item 3 the income statement item, posting the recognized revenue to the project
• Item 4 the balance sheet item, posting the WIP

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). 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).

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

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: Overview of customer project setup in S/4HANA Cloud

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.

Management Accounting Features with Event-Based Revenue Recognition

Event-based revenue recognition covers more than balance sheets. 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-3-professional-service-industry-reporting-including-margin-per-contributing-profit-center/

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 (example see figure 4). The steps are:

1. We define the super-ordinate project billing element -> SW006.0.1
2. Since there is always exactly one sales order item assigned to a project billing element in Cloud, we can determine it -> 15804/1.
3. From the assigned sales order 15804, we derive for example the sales org and the customer “101000001”.
4. From the sales order item, we derive for example the product sold “P001”.

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.

Capabilities of event-based revenue recognition

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 functionality provided in event-based revenue recognition

Event-based revenue recognition covers the common IFRS15 requirements in customer project scenario:

• The 5-step approach
• Option for multi element arrangement within one sales order
• Differentiate accrued revenue/contract asset and deferred revenue/contract liability
• Differentiate accrued revenue by contract asset and Unbilled revenue

 It is provided for the following scenarios:

• Fixed-price projects
• Periodic service projects
• Combination fixed price + periodic service projects
• Sell from stock

The following IFRS15 specific enhancements are available:

• All contract and IFRS15 related information are stored in the sales order. In particular there are 2 pricing conditions provided by cloud content:
  • PSAS (price standalone service) as standalone selling price for customer projects
  • PSAM (price standalone material) as standalone selling price in sell from stock
• One sales order corresponds to one revenue contract and one sales order item corresponds to one performance obligation.
• A special Allocated Revenue app displays the calculated revenue amounts per performance obligation.

With IFRS15 functionality activated the following processes impact event-based revenue recognition:

Sales order creation/change:

• Option to bundle products/services (multi element arrangements)
• Determination of the transaction price
• Automatic calculation of allocated revenues based on the standalone selling price

Confirmation on a fixed-price project leads to following posting:

• Debit posting to contract asset posting based on the allocated revenue amount
• Credit posting allocated revenue

Goods issue in sell from stock scenario leads to following posting:

• Debit posting to contract asset posting based on the allocated revenue amount
• Credit posting to allocated revenue

Invoice posting of the IFRS15 relevant sales order item:

• Contract liability is recorded based on the transaction price, with a debit to revenue adjustment

Period-end closing enhancements in event-based revenue recognition:

• Clearing contract asset item posting / contract liability item posting on header level
• When billing occur in a later period as the fulfillment, while performing the period-end run the G/L account unbilled revenue is used to capture the unbilled revenue amount for the fulfillment. When the billing of the unbilled revenues is processed, the account unbilled revenue will be cleared with the next period-end run.

Additional information regarding IFRS15: https://blogs.sap.com/2018/02/02/revenue-recognition-in-context-of-ifrs-15-with-sap-s4hana-cloud-made-easy-part-22/

Availability of event-based revenue recognition in On Premise

In on premise, the event-based revenue recognition functionality is released for projects only. But the scenario looks different in on premise as the 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.

Additional information 

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%20S4HC.pdf

Note for Account determination: https://launchpad.support.sap.com/#/notes/2778479