Financial Accounting for Hierarchical Setup in Item-Based Services

[Artem_Boitsov]

1 Overview

Dear Colleagues, 

I would like to present a new hierarchical setup in item-based services. We will explore the financial integration of a service contract and service orders with advanced execution. This scenario applies only to on-premise / private cloud environments. The integration with classical item-based service items will be available in future releases. The screenshots below are taken from the OP2023 FP2 system. 

I begin with a business example and provide a functional overview, followed by an end-to-end process demonstration of the system. I will highlight the differences between the service contract root item (new in OP2023 FP2) and non-root items (attribution only) in the service contract/order financial hierarchy. Finally, I will conclude with deeper insights into process control and system configuration.

This blog is the follow-up blog to the next two blogs:

• New Financial Accounting for Service Management in S/4HANA Cloud by Stefan Walz (https://community.sap.com/t5/financial-management-blogs-by-sap/new-financial-accounting-for-service-...
• Financial Accounting 4 Advanced Execution Service Scenario in SAP S/4HANA By Stefan Walz and Gabi Hoffmann (https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/financial-accounting-4-advanc...

I highly recommend reviewing these blogs first. Also, you can take a look at the SAP help page (https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/c9b5e9de6e674fb99fff88d72c352291/cd63e0856e1d458499e...

2 Business Scenario Overview

Business Example: SmartFix Maintenance Services

Industry: HVAC, home appliances, or industrial equipment maintenance

Business Model Overview:

SmartFix provides preventive and on-demand maintenance services for residential and commercial clients. Customers pay a monthly or annual subscription fee, while actual service costs are incurred only when maintenance or repair is performed.

Revenue Model (Subscription-Based)

Customers subscribe to a tiered maintenance plan:

1. Basic Plan ($1200/month per device) – Covers monthly/quaterly inspections and minor fixes.
2. Standard Plan ($1500/month per device) – Includes preventive maintenance and priority scheduling.
3. Premium Plan ($3000/month per device) – Covers full maintenance, labor, and minor parts replacement.

The revenue is managed by the SAP S4HANA Service Contract.

Cost Structure (Service Orders-Based)

SmartFix incurs costs only when maintenance or repair work is actually performed, such as:

• Technician labor costs (hourly wage + travel costs).
• Replacement parts/materials (if not included in the plan).
• Operational expenses (vehicle costs, tools, etc.).

Each service request triggers a service order, which is an operational cost to the business.

Example Scenario:

1. A customer subscribes for 3 months (2 months and 30 days) to the Basic Plan for 1 HVAC units → Pays $1200/month -> totalling $3560 of total income ($1200 + $1200 + $1160). The Basic Plan has a fixed scope of work with total planned costs of $2834,00
2. After 1 month, one unit requires a repair, generating a service order. SmartFix incurs costs for the technician visit, which includes:

• Labor: $1660,08
• Parts: $40,5
• Total Cost: $1700,58

1. After 2 months, another unit requires a repair, generating the second service order. SmartFix incurs costs for the technician visit, which includes:

• Labor: $1106,72
• Parts: $27
• Total Cost: $1133,72

1. Over 3 months, SmartFix received $3560 in subscription revenue but only incurred $2834 in costs, maintaining profitability.

Why Does This Model Work?

• Predictable cash flow: Subscription revenue ensures consistent income.
• Optimized service costs: Only incurred when necessary, reducing unnecessary expenses.
• Scalability: More subscribers increase revenue, while efficient service management keeps costs controlled.
• Customer stickiness: Subscriptions encourage long-term customer relationships.

 

3 Functional Overview

First, let’s understand the difference between a hierarchical setup with root and non-root service contract items.

3.1 Service Contract Item as an attribution parameter only (non-root item)

In the basic hierarchical item-based services setup the service contract item is not marked as a "root" item. The service contract item serves only as an attribution parameter. Each service order and service contract item has independent billing and revenue recognition postings.

Figure 1. Financial Process Flow - Service Contract is an Attribution Parameter Only (Non-Root)

You can find the revenue recognition rules for this setup below.

• Service Contracts: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f63dd39a28bb4b90adbf9e608aff58ea/d372d2199d084b3f9d2...
• Service Orders with Advance Execution: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f63dd39a28bb4b90adbf9e608aff58ea/3034581971d94efa831...

In the current blog, I will not focus on this scenario. The non-root scenario was introduced some time ago and well explained in the blog of Stefan Walz (https://community.sap.com/t5/financial-management-blogs-by-sap/new-financial-accounting-for-service-...).

3.2 Service Contract Item as a Root Item in Finance Hierarchy

This is a scenario where a service contract item is created as a root item. You can see that there is no revenue recognition on the service order level.

Figure 2. Financial Process Flow - Service Contract as a Root Object in the Hierarchy

Below, you can see how the postings are recorded in the Universal Journal (ACDOCA).

Figure 3. Hierarchical Setup: Service Contract Item as Root Object – Financial Transactional Data Overview

The service orders have no revenue recognition key assigned.

Figure 1. Hierarchical Setup: Service Contract Item as Root Object – Financial View of Service DocumentFigure 4. Hierarchical Setup: Service Contract Item as Root Object – Financial View of Service Document

In the example above, no revenues are posted to the service order because its billing relevance is set to “N – Not Relevant for Billing.” In OP2023 FP3, billing relevance "billing on completion" for the service order is allowed.

Please also have a look at the field "Hierarchy Processing Indicator". It is filled with the value "01" for all service contract and order items if the service contract item category is marked as a "root item". 

3.3 Item-Based Services Hierarchical Setup: Difference between “root” and “non-root” service contract items

Please see the hierarchy integration in the item-based services comparison matrix for “root” and “non-root” below.

Table 1. Non-Root & Root Service Contract Item Hierarchical Setup Comparison Table

Where

• OR - Order
• SO - Service Order
• SC – Service Contract
• AA – Accounting Assignment

4 System Walkthrough

Now, I will present an end-to-end process for basic attribution (non-root) and root service contract items, using two different revenue recognition approaches.

4.1 Service Contract & Service Order Creation

4.1.1 Financials View for Service Documents

At first, we create a service contract, item 100 is a non-root item (item category is “SCN”) and item 200 is a root item in the finance hierarchy (item category is “YCNH”).

Figure 5. Service Contract Creation

In addition, several service orders are created and assigned to service contract items according to the financial process flow diagrams in Figures 1 and 2.

Figure 6. Financial View of Service Document

You can see that all service objects assigned to the basic (non-root) service contract item 100 have a revenue recognition key (Column “RA Key”, field “REV_REC_KEY”) assigned.

In the setup with a root service contract item (HIER_PROCG_IND = "01"), only the service contract has a revenue recognition key. All service orders are not relevant for billing (SERVICE_DOC_BILLING_RELEVANCE = "N") and revenue recognition (REV_REC_KEY is empty).

4.1.2 Plan Data Update

4.1.2.1 Plan Revenues for Service Contracts

Planned revenue is calculated as the sum of all billing plan amounts for the service contract item. For example, item 200 has three billing plan items.

Figure 7. Service Contract Billing Plan

If we sum up all three billing plan items, we receive 3.865,67 EUR in total.

Now, let’s look at the plan data table (ACDOCP). The output is filtered by the relevant service objects and ongoing plan data categories. In our case, these are "PSERV02" and "PMORDER02". For more details, please refer to the customizing section.

Figure 8. Plan Data Overview for Service Contracts

*The plan revenues are updated for both items (root and non-root ).

Note: You can see the same data in standard Fiori Apps like “Service – Plan/Actuals” or “Financial Plan Data Analysis”.

Figure 9. Service - Plan/Actuals Report

4.1.2.2 Plan Data Update for Service Orders

The difference between root and non-root setup in the plan data update for service orders is that in setup with “root” flagged service contract item service orders are not relevant for billing (FPS2). It means no plan revenues to be updated for such orders.

Figure 10. Service Orders Plan Data Overview

In OP2023 FP3 a service order can be relevant for billing in both options (root, non-root). Please see an example of the Financial View of Service Document from OP2023 FP3. Currently, only "Billing on completion" billing relevance is supported in OP2023 FP3 for the root item. 

Figure 11. Financial View of Service Hierarchy Setup with Root Item in OP2023 FP3

In this case, the plan data is updated, and plan revenues from service orders are included in the revenue recognition percentage-of-completion calculation.

Figure 12. Service - Plan/Actuals Report (OP2023 FP3 System)

 

4.2 Actual Postings

4.2.1 Actual Postings Difference (Root vs Non-Root Setup)

In the example below, a one-hour cost consumption posting takes place. The main difference is that for a service contract (SC) root item (blue box), revenue recognition postings (business transaction type = "TBRR") are executed at the service contract level rather than at the service order level, which is relevant for a non-root item (red box).

Figure 13. PM Order Cost Confirmations & Real-Time EBRR Postings

Revenue recognition posting amounts differ due to different revenue recognition methods assigned to service orders and contracts.

4.2.2 Cost Consumption Postings

In our example, we use the Cost-Based POC revenue recognition key for the root item hierarchy setup.

The planned costs are 2834,30

Figure 14. Total Plan Costs for Percentage Of Completion Calculation

The planned revenue is 3560,00:

Figure 15. Total Plan Revenues for Percentage Of Completion Calculation

• Cost-based POC: 69,17/2834,30 = 2,44%
• EBRR Posting: EUR 3560,00 * 2,44% = EUR 86,88

In document 2300000006, business transaction type “RMRU”, 1 hour of the agreed service is confirmed. Costs are posted from the cost center to the service order. Consequently, the account, order, and cost center are updated by EUR 69,17. In the document 100000026 business transaction type “TBRR”, the corresponding revenue is recognized based on the POC (in this case 2,44%). Hence, the Event-Based Revenue Recognition posting debits the Accrued Revenue account and credits the Revenue Adjustment account by EUR 86,88.

Figure 16. Activity Allocation & Real-Time EBRR Postings

4.2.3 Revenue Postings

Let’s post partial revenue posting (EUR 1200). The revenue is fully deferred.

Figure 17. Partial Revenue Posting & Real-Time EBRR Posting

Billing takes place in the document 9400000018 business transaction type “SD00”. The invoice refers to the first billing plan item. The whole revenue amount is deferred with the document 10000030 business transaction type “TBRR”.

 

4.2.4 EBRR Closing Run

After real-time confirmation and billing postings, we see deferred and accrued revenue balances in the Event-Based Revenue Recognition - Service Documents Fiori App.

Figure 18. Event-Based Revenue Recognition - Service Documents: Overview

In the period-end closing, which can be done in the Run Revenue Recognition – Service Documents app, Event-Based Revenue Recognition revalues the balance sheet position of the selected service contract item. During this calculation, POC is limited to 100%. The actual POC is calculated based on the total costs incurred up to the calculation period and the actual plan costs. Furthermore, the balance of Accrued Revenue and Deferred Revenue is cleared up during period-end closing.

Figure 19. Event-Based Revenue Recognition - Service Documents Fiori App: Simulation

Figure 20. Period-End Event Based Revenue Recognition Posting

4.3 Technical Completion

After all confirmation and billing documents are posted, you can set the status to “completed” to the service order and execute the CRMS4_SRV_TECH_COMPL transaction to set the status to technically completed.

Figure 21. Set Technically Completed Status for Service Orders

The program can be executed manually. However, the general idea is to schedule the periodic program execution. 

Now, the service contract can also be set to technically complete.

Figure 22. Set Technically Completed Status for Service Contract

All EBRR adjustments are reversed during the EBRR closing run.

Figure 23. Event-Based Revenue Recognition - Service Documents Fiori App: Simulation

 

4.4 Manual Costs Planning Use Case

You can also consider external cost planning. Let’s look at an example:

You create a contract for a specific period. Each month, you bill your customer according to your billing plan (100 EUR). However, you cannot predict all maintenance events (planned costs) in advance. You also don’t know when maintenance will be needed for this specific contract.

Table 2. Use Cases - Actual Costs & Revenues Distribution Per Period

For example, in Contract 1, you have two maintenance events, requiring two service orders. The first repair was executed in April for 310 EUR, and the second repair took place in August for 700 EUR.

For Service Contract 2, there is only one repair in November for 300 EUR.

For Service Contract 3, there are two repairs totalling 1,900 EUR.

Since maintenance events occur unpredictably, it is impossible to create all service orders in advance and have planned costs updated automatically.

However, you do know the average margin per contract type. Let’s assume it is 20 percent. In this case, you can calculate planned costs externally and upload them using the "Financial Data Upload" Fiori app or SAC.

In EBRR customizing, you can select externally planned costs instead of automatically updated.

 

5 System Configuration

In the section below, I provide a full set of customizing activities to prepare the system for a hierarchical setup (root service contract item), including the introduction of a new service contract item category, new plan categories, and a complete EBRR setup.

If you have advanced configuration knowledge of hierarchical item-based services integration, please refer to 4.1.1 New Hierarchical Item Category Definition and 4.3.3 Maintain Settings for Event-Based Revenue Recognition – Recognition Keys. These configuration steps are new.

5.1 Customizing – Service Contracts

5.1.1 New Root Service Contract Item Category Definition

IMG Path	SAP Customizing Implementation Guide -> Service -> Transactions -> Basic Settings -> Define Item Categories -> Assignment of Business Transaction Categories -> BUS2000112 Service Contract
IMG Object	CRMV_ITEM_MA
Transaction Code	S_AEC_66000039
Table/View/ViewCluster	CRMC_SRV_CONT_I

A new item category must be defined for the hierarchical integration setup as a "root" item. The standard item category "SCN" can be used as a base for copying. The only difference from the "SCN" standard service contract item category is that the item must be marked as a "Root Item."

Figure 24. Service Contract Item Configuration - Root Item Flag

You can see the new hierarchical parameter “IS_HIER_PROC_ACTIVE” in the table CRMC_SRV_CONT_I.

5.1.2 Update Item Category Determination

The newly created item category must be assigned to the service contract type and item category group.

IMG Path	SAP Customizing Implementation Guide -> Service -> Transactions -> Basic Settings -> Define Item Category Determination
IMG Object	CRMV_IT_ASSIGN
Transaction Code	S_AEC_66000040
Table/View/ViewCluster	CRMC_IT_ASSIGN

Figure 25. Item Category Determination Update

Afterwards, you should be able to choose your item category in the service contract.

Figure 26. Service Contract Creation – New Item Category is added to the Dropdown List

 

5.1.3 Assign Service Transaction Type to Billing Document Request Types

IMG Path	SAP Customizing Implementation Guide -> Service -> Basic Functions -> Billing -> Assign Service Transaction Types to Billing Document Requests
IMG Object	CRMS4VC_BILL_PRTY_MAP
Transaction Code	S_AG9_66000013
Table/View/ViewCluster	CRMS4VC_BILL_PRTY_MAP (View)

Figure 27. Service Contract Item Configuration – Item Mapping to Sales Document Type

5.1.4 Assign Billing Plan to Item Category

IMG Path	SAP Customizing Implementation Guide -> Service -> Transactions -> Basic Settings -> Billing Plan -> Assign Billing Plan Type to Item Category
IMG Object	CRMV_BILP_BT_IT
Transaction Code	S_A2C_40000042
Table/View/ViewCluster	CRMC_BILP_BT_IT

Figure 28. Service Contract Item Configuration – Mapping to Billing Plan Type

 

5.1.5      Copy Control Customizing

IMG Path	SAP Customizing Implementation Guide -> Service -> Transactions -> Basic Settings -> Copying Control for Business Transactions -> Define Copying Control for Item Categories
IMG Object	CRMV_IT_COPY_MA
Transaction Code	S_A2C_40000015
Table/View/ViewCluster	CRMC_IT_COPY_MA

Figure 29. Service Contract Item Configuration - General Control Data

5.1.6 CRMS4C_PM_OT_MAP Table Clearance

When releasing a service order item, you may encounter the CRMS4_SRV_MAINT 060 error message. As a result, the maintenance order has not been created.

To resolve this issue, check the entries in the CRMS4C_PM_OT_MAP table. This table should be empty.

Figure 30. CRMS4C_PM_OT_MAP Table Check

You can check the 3433802 note (https://me.sap.com/notes/3433802/E) for additional details.  

 5.2 Customizing – Plan Categories (CO)

You may have already defined the necessary plan categories. For example, you can use service orders with advanced execution and percentage-of-completion revenue recognition methods. In this case, there is no need to duplicate your entries.

If the plan category has not been defined, please ensure it is maintained.

 

5.2.1 Check Plan Category for Maintenance Orders

IMG Path	SAP Customizing Implementation Guide -> Controlling -> General Controlling -> Planning -> Application-Specific Categories -> Maintain Categories for Maintenance Orders
IMG Object	FCOMV_CATEGORY_E
Transaction Code	S_E91_86000108
Table/View/ViewCluster	FCOMC_CATEGORY

Figure 31. Plan Categories for Maintenance Order

This plan category is used to update plan data for service orders with advanced execution in the Plan Data Line Items table (ACDOCP).

• "PMORDER02" plan data is updated each time the service execution order is changed or saved.
• "PMORDER03" plan data is updated at the moment of the service execution order release.

The planned cost data for the execution item is calculated in the execution order:

• Planned activities = planned cost rate × planned working hours

Planned components = material net price × planned quantity

5.2.2 Check Plan Category for Service Orders

IMG Path	SAP Customizing Implementation Guide -> Controlling -> General Controlling -> Planning -> Maintain Categories for Service Documents
IMG Object	FCOMV_CATEGORY_F
Transaction Code	S_ER9_11001495
Table/View/ViewCluster	FCOMC_CATEGORY

Figure 32. Plan Categories for Service Order / Service Contract

In our case, the plan categories are used to update planned revenues for the service contract in the Plan Data Line Items table (ACDOCP).

• "PSERV01" plan data is updated at the moment of the service order release.
• "PSERV02" plan data is updated each time the service order is changed or saved.

5.2.3      Check / Maintain Virtual Category for Planning

IMG Path	SAP Customizing Implementation Guide -> Controlling -> General Controlling -> Planning -> Maintain Category for Planning
IMG Object	FCOMV_CATEGORY
Transaction Code	S_E91_86000108
Table/View/ViewCluster	FCOMC_CATEGORY

The application type of the item category should be “8 – Virtual Plan Category”. In this case you can sum up several plan categories together. In our case, it is mandatory.

Figure 33. Plan Category EBRR_SC_A Basic Configuration

IMG Path	SAP Customizing Implementation Guide -> Controlling -> General Controlling -> Planning -> Assign Plan Categories to a Virtual Category
IMG Object	FCOMV_CAT_ASSGMT
Transaction Code	S_ER9_11002399
Table/View/ViewCluster	FCOMC_CAT_ASSGMT

Figure 34. Plan Category EBRR_SC_A - Assignment to Source Plan Categories

 

5.2.4 Manual Cost Planning – Alternative Set Up (Optional)

Precise cost planning is essential, and having the correct revenue recognition adjustment postings is equally crucial. Some customers have long-term contracts and cannot accurately predict the exact amount of work required over the contract duration.

As a result, creating all service orders in advance is not feasible due to the uncertainty in volume and timing of maintenance. However, customers typically have an estimate of their average costs and margins per contract type. In such cases, it makes sense for them to plan costs externally.

External cost planning is possible with a standard “PLN Plan” plan category.

Figure 35. Plan Category PLN

You can also define a separate plan category.

Figure 36. Plan Category for External Costs Upload

The important parameter is that you allow the import of plan data. In addition, you must define a separate virtual plan category to be used later in EBRR customizing.

IMG Path	SAP Customizing Implementation Guide -> Controlling -> General Controlling -> Planning -> Assign Plan Categories to a Virtual Category
IMG Object	FCOMV_CAT_ASSGMT
Transaction Code	S_ER9_11002399
Table/View/ViewCluster	FCOMC_CAT_ASSGMT

Figure 37. Virtual Plan Category (Costs - External Upload, Revenues - Billing Plan)

5.3 Customizing – Event-Based Revenue Recognition

EBRR (Event-Based Revenue Recognition) postings are triggered by CO (COIN) of FI (RWIN) source documents only. Please find examples of such documents below:

• COIN – CO Document
  • Activity Allocation (KB21n, IW41)
• RWIN – FI Document
  • FI document (like FB01, FB60)
  • SD Billing (VF01)
  • Material Consumption (MIGO, 261 Movement Type)

5.3.1 Maintain Settings for Event-Based Revenue Recognition – Sources

The first check/filter is the relevance of a document item GL account for EBRR post-processing.

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Maintain Settings for Event-Based Revenue Recognition -> Sources
IMG Object	FINS_TRR
Transaction Code	S_ER9_11000209
Table/View/ViewCluster	FINS_TRR_SOURCE

In our example, I simplify the setup because it is not specific to our particular use case. If you are looking for more advanced knowledge, please refer to the following resources:

• SAP Note 2778479
• SAP Note 3259335
• Configuration of G/L Accounts in Event-Based Revenue Recognition

Figure 38. EBRR Source Configuration for Costs Selection

Figure 39. EBRR Source Configuration for Revenues Selections

5.3.2 Maintain Settings for Event-Based Revenue Recognition – Assignment Rules

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Maintain Settings for Event-Based Revenue Recognition -> Assignment Rules
IMG Object	FINS_TRR
Transaction Code	SM34 (FINS_TRR)
Table/View/ViewCluster	FINS_TRR_ASS

You can reuse already existing rules or create a new one.

Figure 40. EBRR GL Posting Rules Configuration

You can see the relevant GL accounts with descriptions below:

Table 3. List of Relevant EBRR GL Accounts

5.3.3 Maintain Settings for Event-Based Revenue Recognition – Recognition Keys

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Maintain Settings for Event-Based Revenue Recognition -> Recognition Keys
IMG Object	FINS_TRR
Transaction Code	S_ER9_11000209
Table/View/View Cluster	FINS_TRR_VAL

Figure 41. EBRR Revenue Recognition Key Configuration - General Data

• The key is activated for the necessary company codes and accounting principles.
• The field Revenue Recognition method is “3 – Cost Based POC”.
• Please use your customized assignment rule and plan category.
• The source for plan values should be “500 :Cost and revenue planning of all objects from ACDOCP ”
• The field “Billable Determination method” is always empty (not relevant for services).

Figure 42. EBRR Revenue Recognition Key Configuration - Company Code & Accounting Principle Specific Data

 

5.3.4 Maintain Settings for Event-Based Revenue Recognition – Document Types

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Maintain Settings for Event-Based Revenue Recognition -> Document Types
IMG Object	FINS_TRR
Transaction Code	S_ER9_11000209
Table/View/ViewCluster	FINS_TRR_ACP

Figure 43. EBRR - Document Types Configuration

Fields Description:

• Plan Category - Plan Category for history of plan used by EBRR.
  • Description: The values for this Plan Category display the history of plan values used by the closing or re-evaluation of Event-Based Revenue Recognition.
  • Use: The history is recorded with respect to the financial period and the cost elements for the adjustment postings of recognized COGS and revenue.
  • Dependencies: A Plan category of the application type 03, Revenue Recognition should be used here. 

• IFRS 15-Indicator (Not Relevant for Current Use Case) – No impact on our use case, not supported for Service Documents. 

• Currency Handling (Not Relevant for Current Use Case)  - The various possibilities of currency handling offer to choose the
  • principal currency, which is the main currency of the closing run of revenue recognition.
  • currency calculations, which allow to evaluate the total balance sheet amounts and to separate currency effects.
  • base currency of currency calculations, which is the starting point of the currency translations for the currency calculations.
  • document currency of closing, which is the document currency used for the financial documents created by the closing run of event-based revenue recognition.
  • valuation date, which is the suggested valuation date for all financial documents of event-based revenue recognition.
• Loss handling (Not Relevant for Current Use Case) - This function determines the loss handling for POC-type recognition methods. If a plan loss is expected, the planned loss should be posted as a loss provision into the income statement immediately.

5.3.5 Maintain Settings for Event-Based Revenue Recognition – Evaluation Scope

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Maintain Settings for Event-Based Revenue Recognition -> Evaluation Scope incl. Financial Statement
IMG Object	FINS_TRR
Transaction Code	S_ER9_11000209
Table/View/ViewCluster	FINS_TRR_EVA

For our use case, the scope is 2: Realtime evaluation and re-evaluation at closing.

Figure 44. EBRR - Evaluation Scope incl. Financial Statement Configuration

5.3.6 Derivation of Recognition Key for Service Documents

The revenue recognition key derivation is based on the table below. We need to add our new service contract "root" item category to the list. 

IMG Path	SAP Customizing Implementation Guide -> Controlling -> Product Cost Controlling -> Cost Object Controlling -> Product Cost by Sales Order -> Period-End Closing -> Event-Based Revenue Recognition -> Derivation of Recognition Key for Service Documents
IMG Object	FINS_TRR_DRK_CRM
Transaction Code	S_ER9_11001107
Table/View/ViewCluster	FINS_TRR_DRK_CRM

Figure 45. Revenue Recognition Derivation Configuration