Principles of Event-Based Revenue Recognition (EBRR) in SAP S/4HANA

Event-based revenue recognition (EBRR) in SAP S/4HANA has its origins in the public cloud and thus naturally follows cloud principles.

Thus, SAP has ensured easy setup, simplified period-end closing, and a high level of transparency and traceability through integration into the Universal Journal. These properties are applied in all business scenarios and are available on-premise too.

Real-Time Matching Principle for Cost of Sales and Revenues

Revenue recognition postings are generated simultaneously with the source documents account assigned to the customer project and directly stored in the Universal Journal. In this way, a real-time matching principle is provided for cost of sales and revenues. This allows you to always have up-to-date margin reporting for revenue-generating cost objects such as customer projects or sales orders. Because market segment attributes are derived and stored in the journal entry too, you also get market segment margin reporting that is always current.

The figure below illustrates the general posting logic of EBRR with the example of the time confirmation on customer project. The source document—here, a time confirmation—creates two separate journal entries: one journal entry for the initial source document (here, the time confirmation posted as the management accounting document), and a second for the matching revenue recognition journal entry.

The revenue recognition method is derived depending on the contract type. Here, the revenue is calculated based on the selling price of the provided service—Platinum Consulting.

The calculated realized revenue is posted to the Revenue Adjustment P&L account and activated on the Accrued Revenue balance sheet account.

A posting overview based on a graphical t-accounts representation for the single process steps on a customer project is shown in the next figure. The general ledger accounts that are account assigned to the project are tagged with “PRO”.

This posting logic is the same for a cost-based POC method in a fixed-price contract type and time and material billing when revenues are recognized already with the confirmation.

Now, let’s discuss each of the three steps:

1. With time confirmation, revenues are realized on the Revenue Adjustment income statement account and capitalized in the balance sheet with the Accrued Revenue general ledger account.
2. The customer invoice posts billed revenue on the income statement account. In this case, the revenue needs to be event-based deferred because revenue realization already took place with the confirmation. The Deferrals Revenue balance sheet general ledger account is credited. Debiting the Revenue Adjustment general ledger account with 120 EUR takes its balance to zero on the customer project. The realized revenue of the project is now shown on the Billed Revenue
3. The accrued and deferred revenue will be balanced at period-end. Because balance sheet corrections don’t influence profitability reporting, they are only made with the period-end run and are not event based.

The revenue adjustment is a P&L general ledger account on which recognized revenues are shown temporarily. When the project is completed, this general ledger account will be balanced to zero—just like the balance sheet accounts for accrued and deferred revenue.

Now let’s turn to the next principle of EBRR.

Universal Journal Integration

EBRR is fully integrated with the general ledger, and the revenue recognition data is stored in the Universal Journal, just as cost and revenue data is. Thanks to this integration, you’re free of the limitations imposed by periodic processes and different table structures for the applications.

This principle avoids the need for any reconciliation between revenue recognition data and the general ledger. Regardless of which day of the month it is, cost and revenue information are reconciled and up to date. The same entities and semantics are used, such as the general ledger account, the ledger, or the currency fields. This also greatly simplifies the period-end close process.

As revenue recognition data is stored in the general ledger, the data inherits its functionality and its line item attributes (e.g., ledger, currency, and profitability segment), enabling new reporting insights.

Now let’s look at the figure below, which shows some revenue recognition postings created on the T&E contract type. The first journal entry is the manual accrual, the second is the reaction of the write-off, and the third is the EBRR journal entry for the time confirmation.

Let’s direct our attention to some key Line Items attributes:

• Business Transaction Type: As already mentioned, there is a separate business transaction type used for event-driven revenue recognition to identify these documents easily (TBRR).
• Reference document/Ref. Doc type: For every revenue recognition journal entry, you get the reference document and the reference document type. This provides a link from the revenue recognition journal entry to the source document, and vice versa, which simplifies tracing and reviewing.
• Posting Date: The posting date is the same as the posting date of the referenced business transaction. For manual accruals—first journal entry—and period-end postings, the posting date is the last day of the period.
• Account Assignment Type: This field in the Universal Journal qualifies the real account assignment. It’s needed because the system now provides multiple account assignments in parallel in one journal entry item for some scenarios. The real account assigned cost object is only relevant for follow-up processes such as revenue recognition, overheads, and settlement. Here, PR indicates assignment to a project/WBS element.
• WBS Element/Sales Order Item: In this example, these are both provided in one journal entry. The real account assignment in all revenue recognition lines is defined with PR, the project WBS element. Therefore, the revenue recognition postings—including the balance sheet journal item—are real accounts assigned to the WBS element. The assigned sales order item is just an additional attribute, which you need to derive the additional profitability attributes and to determine the contract data.
• Profit Center: The profit center is derived from the project billing element master and applied to all assigned postings, including the revenue recognition balance sheet accounts.
• Journal Entry Item Text: This text can be filled with a note for the manual accruals. In the T&E scenario, it covers the note of the employee or the information of the write-off.

Note: Controlling account assignments relevant for EBRR are, for example, WBS element, sales order item, and market segment. Controlling account assignments are mandatory for P&L accounts, for which a cost element has been defined. For EBRR balance sheet journal entry items, we also set a controlling account assignment, which, in this example, is the WBS element. The account assignment to a controlling object is the prerequisite for margin reporting on this object. In addition to the controlling account assignment, there can be additional (attributed) controlling objects in parallel added in a journal entry. In this example, the sales order item and the market segment are attributed.

In our example, margin analysis is activated, thus market segment attribution is applied for the EBRR journal entry items, causing the EBRR journal entries to be part of the margin reporting.

Parallel Valuation

By being integrated into the general ledger, EBRR inherits another capability to update parallel ledgers with the option of different calculated values based on the ledger’s assigned accounting principle.

Let’s apply different EBRR revenue recognition methods per ledger:

• In ledger 0L, we applied the cost-based POC revenue recognition method.
• In ledger 2L, we’ll apply the revenue-based POC method.

When we now post, for example, a time sheet entry on the project, both ledgers are updated with the journal entries, but with different values in EBRR:

• In ledger 0L, we realized revenue of 600 EUR based on the cost-based POC.
• In ledger 2L, where revenue-based POC is applied, the EBRR journal entry items are different (see figure below).

In the revenue-based POC method, revenues are first realized with billing. Thus, the 500 EUR costs posted from the time sheet needs to be deferred and posted on a WIP general ledger account instead of accrued revenue. EBRR uses a different P&L general ledger account too: instead of revenue adjustment, now Adjustment to Reserves for Unrealized Costs is used.

There is an IMG activity available to activate the parallel valuation. You get to the configuration shown in the next figure via menu path Controlling > Product Cost Controlling > Cost Object Controlling > Product Cost by Sales Order > Period-End Closing > Event-Based Revenue Recognition > Define Replacement Rules of Recognition Keys.

The replacement rules are defined per accounting principle. In our example, the following rules apply:

• Ledger 0L is the local ledger with German GAAP applied.
• For ledger 2L, the IFRS accounting principle is applied.

For the accounting principle IFRS, the revenue recognition method cost-based POC—reflected with key SPFC—is replaced with key SPFCR, revenue-based POC.

Note: Additionally, EBRR supports universal parallel accounting. Universal parallel accounting enables end-to-end parallel value flows, including EBRR.

Multiple Currencies

A further advantage of the integration into the general ledger is the support for parallel currencies. In the next figure, we analyze the time confirmation on the project with its EBRR journal entry.

You see five columns for amounts in different currencies for the revenue recognition postings: the company code currency, global currency, object currency (defined in the customer project header), transaction currency, and a freely defined currency, which needs to be activated in configuration.

Now let’s move on to the next principle, where you’ll see that EBRR is highly integrated into logistics processes.

Integration into Logistics

We always take the contract data from the corresponding logistics object: the sales order item, service order item, or service contract item. There is no separate EBRR persistence. This is especially valid for the billing data:

• For the customer project scenario, as shown already in this section, the billing method, planned revenues, and billing plan details with its time frames are defined in the Billing
• In the sell-from-stock scenario, the product sold and the selling price are stored in the sales order item.
• In the service order, the billing method is defined as fixed price or confirmation based. This influences the EBRR methods. The planned revenue values can be found in service order item pricing.
• The service contract contains a detailed billing plan with time frame, which is relevant for EBRR revenue realization. Although this isn’t shown here, you can get more information at http://s-prs.co/v569802.

Let’s review the most important points of how logistics integration plays out in a public cloud customer project scenario:

• First, the logistics object setup provided is optimized to support simple and transparent revenue recognition and margin analysis. A sales order is assigned to every customer project, and a sales order item is assigned to every WBS billing element. The sales order item defines the customer contract, where the billing method, billing plan, pricing, and revenue recognition key are defined. Thus, all contract-related information is stored in the sales order. There is no separate contract data persistency for revenue recognition purposes, which avoids redundancy and thus reconciliation issues. The required data for revenue recognition is provided already when the sales order item or contract is created.
• The Billing tab reflects the view of the assigned sales order items. There are three items with different Contract Types assigned, which reflect the sales order items. The Contract Type is identical to the sales order item category and determines the billing method. Contract Type and Product derive the revenue recognition key.
• The values in a billing plan are the basis for revenue recognition in a fixed-price scenario and periodic service scenario.
• The sales pricing conditions, including project-specific prices, are the basis for the realized revenue related to T&E.
• For a fixed-price contract type, the planned costs are taken from the resource planning on the customer project work package, and the planned revenues are taken from the billing plan.
• For the customer project, there is only one status available (in the Stage field), which you maintain on the customer project header. No additional statuses in parallel are maintainable in other applications, especially not in accounting. This customer project status is relevant for revenue recognition. With the Completed status, all posted costs and revenues of assigned project elements are realized, and all balance sheet values are cleared.
• On the other hand, the logistics application (here, sales and project management) needs to ensure correct financial data and especially revenue recognition. As mentioned, SAP S/4HANA Cloud provides clear guidance and subsequent checks for completeness in the customer project setup to allow complete financial data and especially real-time revenue recognition postings and profitability segment enablement. Note the following:
  • A customer project can only be released when all work packages are assigned to a project billing element. This guarantees that all data is available for revenue recognition when a posting is done on the work package.
  • Another important aspect is the 1:1 relationship between a sales order item and a WBS billing element. This allows a clear definition of the revenue recognition key and method based on the sales order item. This can’t be changed.
• In SAP S/4HANA Cloud, public edition, four contract types are delivered to which unique business functionality is assigned by default. This ensures that, for these contract types, correct end-to-end processing is available out of the box by all involved applications. In particular, the correct revenue recognition methods are assigned.

Editor’s note: This post has been adapted from a section of the book Financial Accounting with SAP S/4HANA: Business User Guide by Jonas Tritschler, Stefan Walz, Reinhard Rupp, and Nertila Mucka.