PUBLIC
2017-08-24
SAP Revenue Accounting and Reporting
Content
1 SAP Revenue Accounting and Reporting.............................................9
2 What's New in Revenue Accounting and Reporting....................................10
2.1 Release 1.1................................................................... 10
Integration with SAP Billing and Revenue Innovation Management......................... 10
Enhancements in the Revenue Accounting Item Monitor.................................12
Processing of Return Orders.................................................... 13
Reconciliation of Revenue Accounting Items with Contracts..............................14
Enhancement of Account Determination............................................15
Planned Invoices for Billing Plans.................................................17
Archiving Revenue Accounting Contracts and Items....................................18
Determining Quantities and Amounts in Revenue Accounting.............................19
Migration by Package.........................................................20
Improvement in Closing Activities................................................ 22
Further Flexibility in Posting Process.............................................. 23
Prospective Change..........................................................25
Enhanced Reconciliation Functions...............................................26
2.2 Release 1.2...................................................................26
Integration with CRM......................................................... 27
Cancellation of Performance Obligation............................................29
Cost Recognition............................................................29
Enhanced CO Account Assignments.............................................. 30
Enhanced Capabilities for Contract Combination......................................31
Enhanced Conflict Handling in SAP Revenue Accounting................................32
Further Support for Disclosures..................................................33
Improvements in Contract Management............................................34
Improvements in Revenue Posting................................................34
Integration with Cost Object Controlling............................................36
Contract Change............................................................ 37
Transition to the new Revenue Standard............................................37
Free Selections in Mass Activities for RAI Transfer and Processing.........................39
2.3 Release 1.3...................................................................40
Aggregate General Ledger Postings by Debit/Credit Indicator............................40
Allow Different Currencies for Sales Order Items and Invoices.............................41
General Enhancements........................................................42
Check and Enhance Data Sources for Disclosures.....................................43
Exclude Billing Plan Items......................................................44
2
P U B LI C
SAP Revenue Accounting and Reporting
Content
Foreign Currency Handling According to IAS 21/ASC 830............................... 44
Inbound Processing: Exempt and Restore Revenue Accounting Items.......................46
Service Acceptance.......................................................... 47
Simplified Invoice Handling.....................................................48
Transfer Future Billing Data.....................................................48
3 Integration of Sender Components................................................50
3.1 SAP Sales and Distribution Integration with SAP Revenue Accounting and Reporting.............. 50
3.2 Integration with SAP Hybris Billing...................................................51
3.3 Integration with SAP CRM....................................................... 52
3.4 Integration of External Sender Components............................................53
4 Inbound Processing............................................................54
4.1 Basic Concepts of Inbound Processing...............................................54
Revenue Accounting Item......................................................54
Class for Revenue Accounting Items...............................................55
4.2 Configuration of Revenue Accounting Item Classes...................................... 55
System Landscape...........................................................57
Interfaces for Revenue Accounting Item Classes......................................58
Customer Fields in Revenue Accounting Item Classes..................................58
Interface Generation..........................................................59
4.3 Adding Accounts to Revenue Accounting Items......................................... 61
4.4 Changing of Raw Data and Error Handling.............................................62
4.5 Transfer of Revenue Accounting Items to Processable Status...............................63
4.6 Processing Revenue Accounting Items...............................................64
BRFplus Functions Executed During Processing......................................65
Determining Quantities and Amounts..............................................70
Generating Planned Invoices....................................................70
Processing of Order Items with Predecessor Items.....................................71
4.7 Displaying Revenue Accounting Items................................................72
4.8 Reconciliation of Revenue Accounting Items with Sender Component Data......................74
4.9 Reconciliation of Revenue Accounting Items with Contracts................................ 75
4.10 BRFplus Simplified User Interface...................................................75
5 Contract Management..........................................................77
5.1 Performance Obligations.........................................................77
Linked Performance Obligations................................................. 77
Performance Obligation Hierarchies...............................................78
Manual Performance Obligations.................................................79
Deletion of Performance Obligations..............................................80
Cancellation of Performance Obligations........................................... 82
Negative Performance Obligations................................................84
SAP Revenue Accounting and Reporting
Content
P U B LI C 3
5.2 Revenue Accounting Contracts.....................................................86
Creating a Contract.......................................................... 86
Changes to Contracts.........................................................86
Combination of Revenue Accounting Contracts.......................................94
Searching for and Displaying a Contract............................................97
Revenue Schedule...........................................................98
Pending Review Worklists..................................................... 102
5.3 Operational Documents.........................................................106
5.4 Rights of Return...............................................................106
5.5 Cost Recognition..............................................................108
Examples for Cost Recognition..................................................109
Contract Acquisition Cost......................................................114
5.6 Support of Multiple Accounting Principles............................................ 120
5.7 Status Management............................................................121
5.8 Support of Multiple Currencies....................................................124
Define Relevant Currency Type..................................................125
Fixed Exchange Rate Method...................................................126
Actual Exchange Rate Method..................................................129
5.9 Reprocessing.................................................................131
6 Price Allocation..............................................................132
6.1 Price Determination............................................................132
Condition Exclusion List.......................................................132
Contractual Price........................................................... 132
6.2 Standalone Selling Price-Weighted Allocation..........................................133
6.3 Standalone Selling Price Tolerances................................................ 134
6.4 Residual Price Allocation.........................................................135
6.5 Performance Obligations Excluded from Allocation......................................138
6.6 Customized Allocation..........................................................139
6.7 Allocation Effect...............................................................139
6.8 Price Allocation for Structured Performance Obligations..................................140
7 Contract Change.............................................................143
7.1 Invoicing....................................................................144
7.2 Change of Estimates........................................................... 146
7.3 Contract Modification...........................................................148
Applying a Prospective Change................................................. 149
Retrospective Changes.......................................................154
Mixed Changes.............................................................156
7.4 Attributes Change from Inception Date.............................................. 158
7.5 Determination of Contract Change Type............................................. 158
8 Fulfillment of Performance Obligations............................................160
4
P U B LI C
SAP Revenue Accounting and Reporting
Content
8.1 Event-Based Fulfillment.........................................................160
8.2 Time-Based Fulfillment..........................................................160
Spreading.................................................................161
Duration of Fulfillment........................................................165
8.3 Fulfillment by Percentage of Completion............................................. 167
8.4 Manual Fulfillment.............................................................169
8.5 Compound Structure Fulfillment...................................................173
Distribution from High-Level Performance Obligation..................................173
Minimum Fulfilment Percentage from Low-Level Performance Obligation....................175
Distribution Method Takes Priority over the Minimum Fulfillment Percentage.................177
9 Invoicing...................................................................180
9.1 Simplified Invoice Handling.......................................................180
10 Integration with Cost Object Controlling...........................................186
11 Revenue Posting.............................................................189
11.1 Revenue Posting in Three Steps................................................... 193
11.2 Transfer Revenue..............................................................195
11.3 Calculation and Distribution of Contract Liability/Asset or Unbilled Receivable/Deferred Revenue
.......................................................................... 195
Calculating Contract Liability and Contract Asset.....................................196
Distributing Contract Liability and Asset (Unbilled Receivable and Deferred Revenue) to
Performance Obligation Level.................................................. 198
11.4 Start a Revenue Posting Run..................................................... 200
11.5 Job Monitor................................................................. 204
11.6 Reversing a Revenue Posting.....................................................206
11.7 Account Determination......................................................... 207
11.8 Revenue-Related Events and Postings...............................................211
11.9 Revenue Accounting Close.......................................................216
11.10 Shifting Contracts with Failed Postings to the Next Period.................................217
11.11 Integration with the Financial Closing Cockpit..........................................218
12 Reconciliation...............................................................219
12.1 Reconciliation: Revenue Accounting Subledger and General Ledger..........................219
12.2 Reconciliation: Revenue Accounting Items and Revenue Accounting..........................221
13 Reporting.................................................................. 226
13.1 Reconciliation for Accountants....................................................226
13.2 Sample Reports...............................................................229
Sample Reports: Disaggregation of Revenue and Posted Amounts........................230
Sample Report: Contract Balance............................................... 230
How to Create a Report for Transaction Price Allocated to the Remaining Performance
Obligations................................................................231
SAP Revenue Accounting and Reporting
Content
P U B LI C 5
13.3 DataSources.................................................................236
Revenue Analysis by Posting Item............................................... 239
Allocated Price Change of Performance Obligation................................... 242
Revenue Forecast...........................................................244
Revenue Object Attribute..................................................... 246
Revenue Contract...........................................................247
Performance Obligation...................................................... 249
Reconciliation Key...........................................................251
Contract Status Text.........................................................253
Reconciliation Key Status Text..................................................254
Contract Category Text.......................................................255
Event Type Text............................................................256
Performance Obligation Type text............................................... 257
Fulfill Type Text............................................................ 258
Performance Obligation Role Text...............................................259
Performance Obligation Status Text..............................................260
Post Category Text..........................................................261
Start Date Type Text.........................................................262
Distinct Type Text...........................................................263
Performance Obligation Special Indicator Text......................................264
Review Reason Text.........................................................265
Validation Result Text........................................................266
14 Administration and Maintenance................................................ 268
14.1 Roles......................................................................268
Revenue Accountant.........................................................268
Revenue Accounting Administrator..............................................268
Revenue Accounting Auditor...................................................269
Revenue Accounting RFC User..................................................269
14.2 Migration from a Legacy System...................................................270
15 Extensibility.................................................................271
15.1 Field Extensibility..............................................................271
Field Extensibility in Revenue Accounting Item Processing..............................273
Field Extensibility for Revenue Accounting Contracts..................................274
Field Extensibility for Revenue Reporting.......................................... 276
15.2 Business Add-Ins..............................................................278
Validation of Status Change....................................................278
Enhance Revenue Accounting Items (Raw Items).................................... 279
Enhance Revenue Accounting Items (Processable Items).............................. 280
Combination of Contracts.....................................................281
Price Allocation............................................................ 282
6
P U B LI C
SAP Revenue Accounting and Reporting
Content
Deferral Method............................................................282
Account Assignment Derivation.................................................283
Custom Validations..........................................................283
Posting Enhancements.......................................................284
Compound Fulfillments.......................................................284
Review Worklist Enhancements.................................................284
Change Mode Determination of Performance Obligations...............................285
RAI Reconciliation with non-SAP Sender Components.................................285
Add Customer Fields for Comparative Report of Transition............................. 286
Distributing Contract Liability/Asset and Unbilled Receivable/Deferred Revenue into POB Level
........................................................................287
Deriving Duration of Performance Obligation for Capitalized.............................288
Distribute Invoice to Performance Obligation Level...................................288
Check if table FARR_D_DELDEFITM should be cleared.................................289
16 Migration.................................................................. 290
16.1 Overall Approach..............................................................290
Data Migration Overview......................................................290
Details Regarding the Migration Steps............................................294
16.2 Supported Scenarios...........................................................303
Sales and Distribution........................................................303
Customer Relationship Management, Service Application..............................305
Hybris Billing..............................................................309
Hybris Billing with Sales and Distribution...........................................312
Third Party Sender..........................................................314
16.3 Migration for Integration with Cost Object Controlling....................................314
17 Transition.................................................................. 316
17.1 Transition Process for IFRS 15.....................................................316
Date of Initial Adoption....................................................... 316
Full Retrospective and Modified Retrospective Transition...............................317
Comparative Period......................................................... 319
Cumulative Catch-Up........................................................320
17.2 Transition with SAP Revenue Accounting.............................................321
Supported Capabilities for Data Transfer to Transition.................................321
Parallel Accounting - Overview..................................................324
Assign Company Codes to Accounting Principles.................................... 328
Authorization..............................................................329
17.3 Transition Process.............................................................330
Operational Load...........................................................330
Initial Load Processing........................................................331
Reprocess Revenue Accounting Items for new Accounting Principle....................... 331
SAP Revenue Accounting and Reporting
Content
P U B LI C 7
Clean-up Transition data......................................................333
Contracts Created after Migration or Reprocessing of Revenue Accounting Items............. 333
Calculate Deferred and Unbilled Amount Under Status Migration.........................335
Change to Transition under New Accounting Standard.................................336
Reverse Migrated Unbilled Receivable and Deferred Revenue............................336
Cumulative Catch-Up........................................................337
Prepare and Analyze Comparative Report..........................................339
Calculate Time-Based Revenues................................................340
Calculate Contract Liability and Contract Asset......................................340
Post Revenues.............................................................340
Integration with Cost Object Controlling...........................................341
17.4 Use Case Example.............................................................342
18 Archiving...................................................................349
18.1 Archiving of Revenue Accounting Contracts (FARR_CONTR)...............................349
Checks (FARR_CONTR).......................................................351
Application-Specific Customizing (FARR_CONTR)....................................351
Variant Settings for Archiving (FARR_CONTR).......................................351
Displaying Archived Revenue Accounting Contracts (FARR_CONTR)...................... 352
18.2 Archiving of Revenue Accounting Items (FARR_RAI).....................................353
Checks (FARR_RAI)......................................................... 355
Application-Specific Customizing (FARR_RAI).......................................355
Variant Settings for Archiving (FARR_RAI)......................................... 355
Displaying Archived Revenue Accounting Items (FARR_RAI)............................ 356
8
P U B LI C
SAP Revenue Accounting and Reporting
Content
1 SAP Revenue Accounting and Reporting
Product Information
Table 1:
Product SAP Revenue Accounting and Reporting
Release 1.3 SP03
Based On SAP EHP 5 for SAP ERP 6.0
Documentation Published August 2017
Use
Revenue Accounting and Reporting enables you to manage revenue recognition in a process that involves the
following high-level steps:
● Identify contracts
In this step, you create revenue accounting contracts corresponding to operational documents that are
created on a back-end operational system.
● Identify performance obligations
In this step, you identify the performance obligations included in each contract. You create performance
obligations for items in the operational document and manage their relationships with one another.
● Allocate the transaction price
In this step, you determine the total price by aggregating the pricing conditions passed from the back-end
operational system, and then allocate the total price among the performance obligations.
● Manage fulfillment of performance obligations
In this step, you recognize revenue for performance obligations as they are fulfilled.
● Make revenue postings
In this step, you make postings to the general ledger regularly to reflect revenue-related transactions.
SAP Revenue Accounting and Reporting
SAP Revenue Accounting and Reporting
P U B LI C 9
2 What's New in Revenue Accounting and
Reporting
Use
This section contains all release notes. You can use the navigation structure on the left to find a specific release
note.
2.1 Release 1.1
Use
This section contains all release notes. You can use the navigation structure on the left to find a specific release
note.
2.1.1 Integration with SAP Billing and Revenue Innovation
Management
Use
You can connect SAP Billing and Revenue Innovation Management (BRIM) with Revenue Accounting.
Technical Details
Table 2:
Technical Name of Product Feature
FIRA_BRIM_INTEGRATION
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
10 P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
The prerequisites for this integration are:
● You are using Contract Accounts Receivable and Payable (FI-CA) as part of one of the following industry
components, and you are using SAP Convergent Invoicing and provider contracts:
○ Contract Accounts Receivable and Payable
○ Telecommunications
○ Utility industry
● If you are using SAP Customer Relationship Management, you have activated business function
CRM_PROVORDERINT_3_9 (Integration of SAP CC and SAP CI with Provider Order for EHP3 SP09).
● You have activated the business function FICA_EHP7_RA (Integration with Revenue Accounting) (in SAP
ERP).
If you have integrated SAP Customer Relationship Management (SAP CRM), SAP Convergent Invoicing (in SAP
ERP) and SAP Convergent Charging (SAP CC) in the Offer-to-Cash end-to-end process, the integration with
Revenue Accounting takes place solely by means of the ERP system. The ERP system transfers all necessary data
to Revenue Accounting.
Affects on Customizing Settings
SAP provides the sender component CA (SAP O2C) with Revenue Accounting.
You make the following system settings in Customizing for Revenue Accounting under Inbound Processing.
1. Under Revenue Accounting Item Management, define logical systems and assign them to sender component
CA (SAP O2C) in the Define Sender Components customizing activity.
2. Under Revenue Accounting Items create revenue accounting item classes CA01, CA02, and CA03, and
generate them.
The technical names are set by SAP. This ensures that the system automatically provides the required
settings for each class when it is generated.
The revenue accounting item class CA01 defines the technical properties of order items. Class CA02 defines
the technical properties of fulfillment items, and class
CA03 defines those of invoice items.
You activate the integration with Revenue Accounting and configure the RFC destination to the revenue
accounting system, meaning the system, in which SAP Revenue Accounting and Reporting is running, in
Customizing for Contract Accounts Receivable and Payable.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 11
Additional Information
See the information about integration in the documentation for Contract Accounts Receivable and Payable under
Integration Revenue Accounting .
Also see the documentation of the business functions CRM_PROVORDERINT_3_9 and FICA_EHP7_RA.
2.1.2 Enhancements in the Revenue Accounting Item Monitor
Use
In the revenue accounting item monitor, you can now:
● Display legacy data
● Process data from the initial load
Technical Details
Table 3:
Technical Name of Product Feature
FIRA_RAI_MONITOR
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
Displaying Legacy Data
On the initial screen of the revenue accounting item monitor (transaction FARR_RAI_MON), you can specify in your
personal settings that the monitor also displays legacy data (from previous systems). Choose the Personalize
pushbutton, and select one of the following settings:
● No Legacy Data
This is the default setting. The monitor does not select any legacy data, if you choose this setting.
12
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
● Allow Display of Legacy Data in Item Display
If you choose this setting, the monitor does not select legacy data automatically. However, if you choose the
(+) Legacy Data (Display Legacy Data) pushbutton in the item list, you can show legacy data.
● Always Display Legacy Data
If you choose this setting, the monitor always selects legacy data. You can hide the legacy data by choosing
the (-) Legacy Data (Hide Legacy Data) pushbutton in the item list.
The system saves your settings in the FARR_MON_SEL user parameter and uses them the next time you call the
monitor.
If you display legacy data, the monitor shows a new tab for each of the following: legacy data for main items,
legacy data for condition items, and legacy data for planned fulfillment items.
Processing Data from the Initial Load
Up to now you could only process items with field value 1 in INITIAL_LOAD (Initial Load Due to New Co. Code or
Migr. Package
) using transaction FARR_RAI_PROC_LOAD (Initial Load: Process Rev Acc Items).
Once you have selected items from the initial load, the Process Initial Load pushbutton now appears in the display
of processable items.
Items that were generated by an initial load due to a new company code or migration package can only be
processed if you choose the Process Initial Load pushbutton. All other items can be processed only by choosing
the Process pushbutton.
2.1.3 Processing of Return Orders
Use
Order items now have the following fields as references to their predecessor items:
● Predecessor Item Sender Component
● Logical System of the Predecessor Item
● Predecessor Item Type
● Predecessor Item ID
The fields are contained in interface component BASIC_MI01 and are therefore available in all order items.
If an order item is related to a predecessor item, the system does not treat the order item as a separate and
independent item. Instead the system aggregates its quantities and amounts with those of the predecessor item.
When the revenue is posted, the system treats the aggregated data as a change to the predecessor item.
Multiple revenue accounting items are allowed to refer to the same predecessor item. However, the total quantity
and total amount are not allowed to take on a negative value after all the items are aggregated.
Each of the items and its predecessor item must have the same company code, currencies, units of measure, and
setting for its value relevance.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 13
Technical Details
Table 4:
Technical Name of Product Feature
FIRA_RETURN_ORDER_HNDLG
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
The following example illustrates how the fields are used during processing of order items, based on a return in
Sales and Distribution (SD).
Example
1. A customer orders three televisions for 500 each.
2. Revenue Accounting creates a revenue accounting item for this order with a quantity of 3 and an amount of
1500, and generates the revenue postings.
3. One of the televisions is damaged in transport.
4. Revenue Accounting creates an additional order item with a quantity of -1 and an amount of -500. This item
refers to the original (predecessor) order item.
5. Revenue Accounting offsets the item for the return against the original order item.
6. When the revenue posting is made, the system takes the change of the original order item into account
with a newly calculated quantity of 2 and an amount of 1000.
2.1.4 Reconciliation of Revenue Accounting Items with
Contracts
Use
There is a program (transaction FARR_RAI_RECON) you can use to ensure data consistency between revenue
accounting items and revenue accounting contracts. You do so by reconciling the processed revenue accounting
items with the determined performance obligations. The system checks if the amounts and quantities are the
same in both. If the program determines there are differences in the quantity or amount, the system saves these
14
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
performance obligations. The next time a reconciliation is performed, the program checks these saved
performance obligations first.
Technical Details
Table 5:
Technical Name of Product Feature
FIRA_RAI_CONTR_RECONCILIATION
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Affects on Customizing Settings
The report parallelizes the selected data during processing. You specify the number of jobs that can be executed
in parallel in SAP Customizing under Cross-Application Components General Application Functions Parallel
Processing and Job Control Parallel Processing Maintain Job Distribution .
2.1.5 Enhancement of Account Determination
Use
You can completely move the determination of G/L accounts to Revenue Accounting. Then sender systems no
longer have to provide the accounts.
Revenue Accounting determines the G/L accounts to be posted for order items using Customizing rules from the
transferred revenue accounting items. The system derives the G/L accounts for fulfillment items and invoice
items using the reference to the order item.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 15
Technical Details
Table 6:
Technical Name of Product Feature
FIRA_ACCT_DETERMINATION
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
Up to now, you could determine the target accounts that are to be posted by using Customizing rules from
reference accounts that the sender system transfers in order items and invoice items. The target accounts are
used, for example, for posting recognized revenue or for adjusting receivables.
This function remains unchanged.
However, as a separate option, you can now determine G/L accounts completely within Revenue Accounting,
using characteristics of order items.
To derive the G/L accounts from characteristics of order items, the sender system has to set the Determine
Revenue Accounts with BRFplus indicator in main conditions. The sender system must also set the Determine P+L
Accounts with BRFplus indicator in condition records.
If these indicators are set, then the system derives the G/L accounts during the processing of order items in a
step that comes before the account determination used up to now. After that, the system processes the enriched
items exactly as if the sender system had transferred them with G/L accounts.
This ensures compatibility between the solution used until now and the new solution.
You define in Customizing for each revenue accounting item class which characteristics Revenue Accounting uses
to derive which G/L accounts.
The system derives the G/L accounts for fulfillment items and invoice items using the reference to the order item.
Affects on Customizing Settings
You make settings for deriving G/L accounts from reference accounts (provided by SAP) in Customizing for
Revenue Accounting under
Revenue Accounting Revenue Accounting Postings Configure Account
Determination for Specific Transactions .
16
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
To derive the G/L accounts from order items:
1. Enter the derivation rules for G/L accounts in Customizing for Revenue Accounting under Inbound
Processing Revenue Accounting Item Management Assign BRFplus Applications to Revenue Accounting
Item Classes
, by assigning BRFplus applications to the revenue accounting item class of the Order Item
class type.
2. For each order item class, enter an ABAP structure that references the BRFplus application. In Customizing
for Revenue Accounting, choose Inbound Processing Revenue Accounting Item Management Maintain
BRFplus Structure
.
In this way, you can derive the G/L accounts from any characteristics of order items.
Note
If you want to derive G/L accounts based on customer fields, you have to define the BRFplus structure first in
Customizing. Then you can add the fields to the revenue accounting item class and generate the class. Once
this is done, the fields are available when you define your BRFplus application.
2.1.6 Planned Invoices for Billing Plans
Use
During processing of revenue accounting items, you can automatically generate invoices for items of a billing plan.
For this to take place, the sender system has to fill the Invoice Category attribute on the invoice items accordingly.
Technical Details
Table 7:
Technical Name of Product Feature
FIRA_PLANNED_INVOICES
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 17
Additional Details
In Revenue Accounting, the total amount and total quantity of billing plans are represented by an order item that
is valid for the entire duration of the payment plan. In addition to this, information about the due dates and
amounts of the billing plan is stored in invoice items. If a payment plan date is invoiced, then the sender system
has to forward an additional invoice item with the billing document data to Revenue Accounting.
You can now also generate the actual invoice items in Revenue Accounting. This is to support scenarios in which
actual invoicing usually corresponds to the billing plan, and therefore you do not want to connect the billing
system to Revenue Accounting (or it might not be possible).
If you want the system to generate an actual invoice from a planned invoice item of a billing plan on the posting
date, then the invoice must have invoice category 2. In addition, the Invoice Corrections from Billing Plan
(BILLING_PLAN_INV) indicator has to be set on the order item of the billing plan.
Invoice items of invoice category 2 keep the status Processable until their posting date is reached. If they are
processed after their posting date has been reached, then actual invoices are created from them. These invoices
then result in postings. When the actual invoice items are generated, the values in foreign currency are updated.
You can change invoice items of invoice category 2 until their posting date is reached. After the posting date is
reached, changes are no longer possible, since it could be the case that postings were already made based on this
data. Therefore, after the posting date is reached, you have to reverse these invoices and create new ones to
make a change, the same as you would for actual invoices.
2.1.7 Archiving Revenue Accounting Contracts and Items
Use
You can archive revenue accounting items and revenue accounting contracts.
Technical Details
Table 8:
Technical Name of Product Feature
FIRA_ARCHIVING
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
18 P U B L I C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Required Business Functions
None
Additional Details
Archiving of revenue accounting contracts takes place using the archiving object FARR_CONTR. You can archive
revenue accounting contracts if the following applies for the revenue accounting contracts to be archived:
● They have the contract status Closed.
● The date on which they were closed is entered in the contract.
● They are updated.
In addition, the date on which the contract was closed must be further in the past than the amount of time
specified by the residence time.
Archiving of revenue accounting items takes place using the archiving object FARR_RAI. You can archive a
revenue accounting item, if the revenue accounting contract, to which the revenue accounting item relates, is
deleted.
Effects on Customizing Settings
You define the residence time for revenue accounting contracts and activate the archive information structure in
Customizing for Revenue Accounting under
Revenue Accounting Revenue Accounting Contracts
Archiving .
You activate the archive information structure for revenue accounting items in Customizing for Revenue
Accounting under Revenue Accounting Inbound Processing Archiving .
2.1.8 Determining Quantities and Amounts in Revenue
Accounting
Use
Sender systems can transfer revenue accounting items that do not contain a quantity and do not contain an
amount. Revenue Accounting determines quantities and amounts when it processes revenue accounting items.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 19
Technical Details
Table 9:
Technical Name of Product Feature
FIRA_ESTIMATED_QUANTITIES
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
For determining quantities and amounts (prices) per unit, SAP provides the BRFplus function
FC_RAI_EST_QUAN_DET.
Example
You provide services to customers.
The performance obligation is consumption-based.
The price of the performance obligation depends on how many units the customer consumes until the duration
of the performance obligation ends.
Based on the data transferred in the revenue accounting items, you use the BRFplus function
FC_RAI_EST_QUAN_DET to estimate the amount consumed and to determine the average price per unit of
measure.
The amount of the performance obligation is determined by multiplying the estimated quantity by the average
price per unit.
2.1.9 Migration by Package
Use
Up to now, it was only possible to perform initial load for a complete company code.
Now you can load revenue accounting items to Revenue Accounting with finer granularity than an entire company
code and already use the company code productively.
20
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
To load data to already productive company codes, you define migration packages.
Technical Details
Table 10:
Technical Name of Product Feature
FIRA_PACKAGE_MIGRATION
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 110
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.1
Required Business Functions
None
Additional Details
Example
You want to migrate a very large company code to Revenue Accounting.
As the first step, you transfer the data of a particular customer group to Revenue Accounting and set the
company code to productive. Later, you gradually transfer additional customer groups of the company code
and thereby set the company to productive over time.
A migration package contains all data for a certain customer group in a company code.
You set the status of an individual migration package in a company code to Migration or Productive. The
prerequisite for this is that the combination of company code and accounting principle without a migration
package is already productive, and that the transfer date of the new migration package is after the transfer date of
the already productive migration packages.
During the transfer of revenue accounting items, the sender system transfers the migration package in the
MIG_PACKAGE field to the main items of order items.
In transaction FARR_RAI_PROC_LOAD, you can start the processing of revenue accounting items from the initial
load for individual migration packages. The system only processes revenue accounting items from migration
packages that have the status
Migration and that have a posting date (event date) before the transfer date of the
migration package.
If problems occur during the migration of a package, you can delete the data transferred in the package. To do so,
you use transaction FARR_IL_CLEANUP. This is only possible as long as the package has the status Migration and
no postings have been made.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 21
Effects on Customizing Settings
You define migration packages in Customizing for Revenue Accounting under Revenue Accounting Contracts
Define Migration Packages .
You set the status of migration packages in Customizing for Revenue Accounting under Revenue Accounting
Contracts Assign Company Codes to Accounting Principles in the Assignment of Migration Packages group
box.
2.1.10 Improvement in Closing Activities
Use
We enhance revenue accounting close for granular posting and add new check logic for revenue accounting close.
Revenue accounting period (RA period) has a new status In Closing. In this status, new business will result in the
next RA period while the accountant can still conduct accrual run for the current RA period.
You can shift an error contract to the next period and close the current RA period in order to process your
businesses. We enhance three granular posting transactions, namely Calculate Liability and Asset, Calculate
Time-based Revenue, and Revenue Posting, to support SAP Financial Closing Cockpit.
Technical Details
Table 11:
Technical Name of the Product Feature
FIRA_CLOSING
The product feature is Enhanced
Country Dependency Valid for all countries
Software Component Version REVREC 110
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.1
Prerequisite Business Functions N.A.
Additional Details
In Revenue Accounting 1.0, you can set two statuses in a revenue accounting period, that is, Open and Close,
controlled by period. In Revenue Accounting 1.1, we have a new status.
22
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
● Open: Events can still request a reconciliation key in a certain period and are included in revenue posting in
the period.
● Close: When events request a reconciliation key in a certain period, if you set the Close status, the system
provides an open key in the next period. You cannot run revenue posting when the revenue accounting period
is closed.
● In Closing: When events request a reconciliation key in a certain period, the system provides an open key in
the next period, but you can still run revenue posting in this certain period.
To close the RA period, you can choose close revenue accounting period when conducting revenue posting. Then
you can shift contracts to the next period only when the current RA period is in the In Closing status. Once the
contracts have been shifted to next RA period, you are not able to re-open the closed period unless you register
the three revenue accounting programs in SAP Financial Closing Cockpit.
2.1.11 Further Flexibility in Posting Process
Use
The Revenue Accounting system manages revenue recognition using objects such as revenue accounting
contracts and performance obligations. The system receives events that relate to revenue recognition and tracks
the fulfillment of performance obligations. However, revenue postings do not occur at the times of those events.
The accountant performs revenue posting jobs regularly to post FI documents to the general ledger. For example,
the accountant may run a revenue posting job at the end of each accounting period to transfer revenue
recognition transactions to the general ledger.
Technical Details
Table 12:
Technical Name of the Product Feature
FIRA_POSTING_IMPROVE
The product feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 110
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.1
Prerequisite Business Functions N.A.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 23
Additional Details
The general task of revenue posting is divided into three steps. The accountant runs three separate programs to
complete these steps: calculating time-based revenue, calculating contract liability and asset, and performing the
revenue posting run.
In Revenue Accounting and Reporting 1.1, you can post revenue using a single revenue posting run instead of
reconciliation keys.
Effects on Existing Data
Compared to Revenue Accounting and Reporting 1.0, the purpose of the reconciliation key in Revenue Accounting
and Reporting 1.1 has changed. In Revenue Accounting and Reporting 1.0, the reconciliation key works as a
posting bucket for one company code and one accounting principle. It also connects revenue accounting and FI. In
Revenue Accounting and Reporting 1.1, on the other hand, to achieve postings with the same granularity (that is,
postings on the contract level), the reconciliation key works as an event counter for each contract. The length of
the reconciliation key has been extended from 10 digits to 14.
The general task of posting revenue is divided into three steps. The accountant runs three separate programs to
complete these steps:
1. Calculating time-based revenue
2. Calculating contract liabilities and assets
3. Performing the revenue posting run
Revenue Accounting and Reporting 1.1 offers two new UIs for calculating time-based revenue and calculating
contract liabilities and assets.
The system allows you to simulate a revenue posting run in simulation mode. You can use the simulated results to
verify account determination, account assignments, debit/credit side, and posting amounts. Additionally, the
simulation mode allows you to select specific contracts and performance obligations to simulate postings. The
simulation mode provides three views for simulation: You can simulate the results by accounts, by performance
obligations, and by postings.
In a revenue posting run, you can simulate postings using transaction RWIN (General Ledger Posting) to check
whether errors occur in this transaction, such as when the posting period is closed or an account number is not
valid. You can check the result of a test run in the job monitor.
When the posting check is selected in revenue posting run, the program checks the contracts one by one to verify
the possibility of making a revenue posting for that contract. If any contract fails the check, the contract is rolled
back in the actual postings.
Effects on Data Transfer
In Revenue Accounting and Reporting 1.1, postings with greater granularity is supported, which leads to changes
in the data structure and the business process model. Data created in Revenue Recognition 1.0 is supported in the
new version.
24
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Effects on System Administration
The revenue posting user interfaces do not provide options for you to schedule a recurring job. However, the three
programs for revenue posting are all available as ABAP programs. The ABAP programs provide more flexibility,
and you can schedule recurring jobs by using the ABAP built-in scheduling framework.
2.1.12 Prospective Change
Use
Contract modifications that have resulted from changes to scope or price (or both) lead to either a prospective
change or a retrospective change.
Retrospective changes apply the modification to both fulfilled and unfulfilled parts in a revenue accounting
contract. Prospective changes only apply the modification to unfulfilled parts.
Technical Details
Table 13:
Technical Name of the Product Feature N.A.
The product feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 110
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.1
Prerequisite Business Functions N.A.
Additional Details
By default, the system uses standard rules to determine whether a change is prospective or retrospective. You
can enhance the BAdI ( FARR_CHANGE_MODE_DETERMINATION) by defining your own rules.
To define your rules, go to Customizing and choose Financial Accounting Revenue Accounting Revenue
Accounting Contracts Business Add-Ins BAdI: Determination of Contract Modification for Performance
Obligations
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 25
2.1.13 Enhanced Reconciliation Functions
Use
Revenue Accounting receives data from different components, such as SD or CRM, and then posts documents
into General Ledger Accounting (FI-GL) and Profitability Analysis (CO-PA). The system logs any errors that occur
in the communication between the components and processing in the Adapter Reuse Layer (ARL).
Consequently, you need to reconcile data until the data processed in ARL and data finalized in the revenue
accounting engine are consistent. You still need a summary report to reconcile data between revenue accounting
items and the revenue accounting engine. You need to perform the reconciliation regularly.
Technical Details
Table 14:
Technical Name of the Product Feature
FIRA_RECONC_ENHANCE
The product feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 110
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.1
Prerequisite Business Functions N.A.
Additional Details
In Revenue Accounting and Reporting 1.1, we have enhanced reconciliation for performance obligations with bills
of material.
2.2 Release 1.2
Use
This section contains all release notes. You can use the navigation structure on the left to find a specific release
note.
26
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
2.2.1 Integration with CRM
Use
You can connect SAP Customer and Relationship Management (CRM) to Revenue Accounting.
Technical Details
Table 15:
Technical Name of Product Feature
CRM_SRV_REVACC_4 in CRM
CRM_SRV_REVACC_ERP_8 in ERP
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
BBPCRM Enhancement Package 4
SAP_APPL Enhancement Package 8
REVREC 120
REVRECSD (in case of billing in ERP SD)
Application Component
CRM-BTX (Business Transaction)
Available As Of
CRM 7.14 SP02
ERP 6.18 SP02
REVREC 1.20
REVRECSD 1.00 SP 06
Required Business Functions
None
Additional Details
The prerequisites for this integration are:
● You utilize the CRM Service Application and use business transactions of the following types:
○ Service contract
○ Service order and service confirmation
○ Product bundle service order quotation
● See documentation of busniess functions CRM_SRV_REVACC_4 (CRM Service: Revenue Accounting in
enhancement package 4) in the CRM system and
CRM_SRV_REVACC_ERP_8 (CRM Service: Revenue
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 27
Accounting in Enhancement Package 4) in the ERP system. (CRM Service: Revenue Accounting Integration)
activiated in the ERP system.
● You have set up accounting integration for CRM service business transactions in ERP.
● You bill CRM service business transactions (by means of the Billing Engine) and have set up the
corresponding accounting interface in ERP.
Or you bill CRM service business transactions in ERP SD and set up this interface in ERP.
The integration takes place from CRM via ERP to Revenue Accounting.
If you bill the CRM service business transaction in ERP SD, the SD integration components must then be installed
for revenue accounting (add on component REVRECSD) in the ERP system.
Effects on Customizing Settings
SAP provides the sender component CRS (SAP CRM Service) with Revenue Accounting. You make the following
system settings in Customizing for Revenue Accounting under
Inbound Processing.
1. Under Revenue Accounting Item Management, define logical systems and assign them to sender component
CRS (SAP CRM Service) in the Define Sender Components IMG activity.
2. Under Revenue Accounting Items create revenue accounting item classes CS01, CS03 and generate them.
The technical names are set by SAP. This ensures that the system automatically provides the required
settings for each class when it is generated.
The revenue accounting item class CS01 defines the technical characteristics of the order items and the class
CS03 those of the invoice items of CRM billing.
The class SD03 defines the technical properties of the invoice items from ERP SD.
You activate the integration with Revenue Accounting in Customizing for CRM Service Business Processes in the
CRM system. Choose the following path in SAP Customizing for Customer Relationship Management
Transactions Settings for Service Transactions Integration Revenue Accounting Integration .
You configure the RFC destination to the Revenue Accounting system, which is the system that runs the SAP
Revenue Accounting and Reporting, in SAP Customizing in the ERP System under
Integration with Other SAP
Components CRM Settings for Service Processing .
More Information
See documentation of busniess functions CRM_SRV_REVACC_4 (CRM Service: Revenue Accounting in
enhancement package 4) in the CRM system and CRM_SRV_REVACC_ERP_8 (CRM Service: Revenue Accounting
Integration) in the ERP system.
28
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
2.2.2 Cancellation of Performance Obligation
Use
The operational system may pass the finalization date as a sign to terminate performance obligations in Revenue
Accounting, and to lock the operational order with the “Rejection” status. An unblocked delivery or invoice can still
be processed and then passed down to Revenue Accounting.
Revenue Accounting processes performance obligations with a finalization date and an “In Process” status. After
this process, these performance obligations are set to “Complete.” Meanwhile their cumulative amount and
quantity are changed according to the invoice amount. If the finalization date is earlier than the system date, the
performance obligation fulfillment will be adjusted to 100%. The system otherwise submits a report to scan and
process such performance obligations with a finalization date and an “In Process” status, and sets these
performance obligations to “Complete” on the finalization date.
If the operational system changes the order and removes the “Rejection” status afterwards, the operational
system passes an empty “Finalization date” to Revenue Accounting. The system changes the performance
obligation back to “In Process” and adjusts the cumulative amount and quantity accordingly.
Technical Details
Table 16:
Technical Name of the Product Feature
FIRA_POB_CANCEL
Content of the product feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.3 Cost Recognition
Use
Cost of sold goods (COGS) is now managed in revenue accounting. Cost is recognized together with revenue, at
the same time as when the performance obligation is fulfilled and then transferred to COPA.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 29
Technical Details
Table 17:
Technical Name of the Product Feature
FIRA_POB_CANCEL
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.4 Enhanced CO Account Assignments
Use
Additional account assignments are supported by Revenue Accounting.
Additional Details
The following account assignments can be forwarded to revenue accounting:
● an internal order
● a sales order item with make-to-order production
● a work breakdown structure element
● a cost center
You can’t change the account assignment if revenue is posted in revenue accounting. Otherwise values on the
controlling object would be inconsistent. As a result, the new account assignments can‘t be added to performance
obligations created in Revenue Accounting 1.1 or 1.0
The cost center can only be a statistical account assignment, as it doesn’t manage revenues.
30
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Technical Details
Table 18:
Technical Name of the Product Feature
FIRA_CO_ASSIGN
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.5 Enhanced Capabilities for Contract Combination
Use
In Revenue Accounting 1.2, revenue contracts can be combined even if their revenue has already been recognized
or invoiced. Performance obligations can also be reassigned from one revenue contract to another when revenue
has been recognized and an invoice has been issued.
When performing the combination or reassignment, you can specify whether this change is a Change of
Estimates or Contract Modification. If a change of estimates is specified, cumulative catch-up will be calculated
from the earliest period and posted to the current open period. If a contract modification is specified, the change
will only affect revenues that will be recognized in the future. Meanwhile you need to specify a date for revenue
accounting contract change. The date is used to determine unfulfilled revenue and to reallocate prices.
Note: Historical information relating to combined contracts is available for reporting.
Technical Details:
Table 19:
Technical Name of the Product Feature
FIRA_CONTRACT_COMB
Content of the Product Feature Changed
Country Dependency Valid for all countries
Software Component Version REVREC 120
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 31
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.6 Enhanced Conflict Handling in SAP Revenue Accounting
Use
In Revenue Accounting 1.2, conflict handling of revenue accounting contracts has been enhanced in the following
ways:
● The manually changed performance obligation attribute is always preserved, even if the operational
document is updated. Any manual changes to the spreading of a performance obligation will therefore always
be maintained, even if the allocated price of the performance obligation is changed. Users can correct the
revenue schedule manually based on the previous manual change.
● There are three update modes for the performance obligation attributes: Always Check Conflict, Always
Update from Operational Documents, and Always Keep Manually Changed Value. You can choose any mode. If
you choose the first mode, the conflicts always go to the conflict worklist. If you choose the second mode, the
system always maintains values from the operational documents. If you choose the third mode, the system
always maintains manually changed values. The change mode of each attribute can be configured at
company code level in Customizing.
● It is no longer regarded as a conflict if you add or remove a performance obligation manually. This change
reduces unnecessary conflicts.
Technical Details
Table 20:
Technical Name of the Product Feature
FIRA_CONFLICT_HANDLING
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
32 P U B L I C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Effects on existing data
The table FARR_C_CONFLI_EX is extended using column UPDATE_MODE, as well as maintenance view
FARR_C_CONFLI_EX.
If you already have customized entries in table FARR_C_CONFLI_EX, you need to maintain the entries that already
exist and then set the update mode to Always Update from Operational Documents.
Effects on existing Customizing
If the performance obligation attributes are not defined in this Customizing, they will have the default update
mode Always Check Conflict. You can switch to another mode according to your needs.
You can find the description of the Customizing activity under Revenue Accounting Revenue Accounting
Contracts Define default value for Update Mode of POB attributes .
Note
The title of the Customizing activity has been changed from “Configure Automatic Overriding for Conflict
Resolution is changed to Revenue Accounting” to “Define default value for Update Mode of POB attributes”.
2.2.7 Further Support for Disclosures
Use
The data source has been optimized: posting table FARR_D_POSTING has been extended with a new field GJAHR/
POPER. This change enables you to aggregate the posted data by period in the posting table which results in faster
data aggregation than in the memory.
Technical Details
Table 21:
Technical Name of the Product Feature
FIRA_DISCLOSURES_2
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 33
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.8 Improvements in Contract Management
Use
The improvements allow you to:
● Change the fulfillment type after posting.
● Check and report warning messages when you suspend revenue posting.
● Have a BAdI to validate contracts and performance obligations.
● Have an application interface for manual allocation.
● Add a new authorization object in status management.
● Set a status and review the reason for performance obligations.
Technical Details
Table 22:
Technical Name of the Product Feature
FIRA_CONTRACT_MMGT
The product feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
2.2.9 Improvements in Revenue Posting
Use
Revenue Accounting 1.2 provides new Customizing activities which allow you to select different aggregation levels
for revenue posting. To improve posting performance, the system also supports parallel processing. The contract
34
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
liability and contract asset can also be calculated and posted to performance obligation level. By using a Business
Add-In (BAdI), you can define rules for distributing the contract liability and contract asset to performance
obligation level. You need to enter the following:
● Contract liability and contract asset balance, as per IFRS 15, provided by a standard logic
● Information of performance obligations
Technical Details
Table 23:
Technical Name of the Product Feature
FIRA_REV_POSTING
Content of the Product Feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
Additional Details
To enable posting optimization, go to Customizing and choose Financial Accounting (New) Revenue
Accounting Revenue Accounting Postings Switch on Posting Optimization .
To change standard fields during posting to financial accounting, go to Customizing and choose Financial
Accounting (New)
Revenue Accounting Revenue Accounting Postings Business Add-Ins BAdI: Changing
Standard Fields during Posting to Financial Accounting .
To assign an additional revenue posting aggregation dimension, go to Customizing and choose Financial
Accounting (New) Revenue Accounting Revenue Accounting Postings Business Add-Ins BAdI: Assigning
Additional Revenue Posting Aggregation Dimensions
.
To check revenue contracts with your own logic, go to Customizing and choose Financial Accounting (New)
Revenue Accounting Revenue Accounting Postings Business Add-Ins BAdI: Validation and Filter of Revenue
Posting Programs
.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 35
2.2.10 Integration with Cost Object Controlling
Use
Cost object controlling is integrated with revenue accounting.
Additional Details
Integrated cost objects are either a work breakdown structure element, a sales order item with make-to-order or
an internal order.
Effects on Customizing settings
The related sales order item is marked as relevant for revenue accounting. The results analysis version and
currency type are assigned to the company code and accounting principle. The results analysis key and results
analysis version are marked as relevant for revenue accounting.
Line IDs can be defined, as follows:
For percentage of completion methods: the cost elements (accounts), which are used for the revenue correction
postings (revenue adjustments), must be assigned to a separate line ID using category ‘R’.
For revenue-based methods: all cost elements for revenues must be assigned to line IDs using category ‘E’.
Technical Details
Table 24:
Technical Name of the Product Feature
FIRA_COSTOBJECTCONTROLLING
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
36 P U B L I C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
2.2.11 Contract Change
Use
Contract change will result in either a change of estimates or a contract modification. A change of estimates
applies from the inception date, which leads to cumulative catch-up. Contract modification applies to the open
part of a contract depending on whether its performance obligation is unit-distinct. For detailed rules, refer to
Contract Modification [page 148].
Technical Details
Table 25:
Technical Name of the Product Feature
FIRA_PROSPECTIVE
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
Additional Details
The system has default rules to determine whether a change is a contract modification or a change of estimates.
You can also apply your own rules in the following activity:
Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Business Add-Ins
BAdI: Determination of Contract Modification for Performance Obligations .
2.2.12 Transition to the new Revenue Standard
Use
In Revenue Accounting 1.2, the system supports the transition process from a source accounting principle to a
target accounting principle with the new revenue recognition standard.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 37
The process is as follows:
1. Create a new accounting principle from an existing accounting principle.
2. Adjust the performance obligation attributes according to the rules, or manually for:
○ A combination of contracts
○ Linked performance obligations
○ Additional performance obligations
○ An historic standalone selling price (SSP) in case there are differences between the old and new
standards
○ A fulfillment event type changed from invoice to goods issue
○ Other performance obligation attributes similar to creating new performance obligations
3. Calculate the cumulative catch-up of the historic values according to the new attributes.
4. Make a comparative report between the accounting principles for the old and new standard.
Technical Details
Table 26:
Technical Name of the Product Feature
FIRA_TRANSITION
Content of the Product Feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 120
Application Component FI-RA
Availability Revenue Accounting and Reporting 1.2
Prerequisite Business Functions N.A.
Effects on Existing Customizing
You can define which company codes are supported under which accounting principles in Customizing activity:
Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Assign Company Codes
to Accounting Principles
.
For each company code and accounting principle combination, you can specify a legacy data transfer date and a
migration status to indicate the date on which Revenue Accounting should be productive for this combination.
The following fields are also relevant in transition:
● Transfer Date: The transfer date of legacy data specifies the date on which you switch from your legacy
revenue accounting system to Revenue Accounting. This means that revenue is managed in your legacy
system up until this date and all revenue that occurs after this date is managed in Revenue Accounting. You
set the transfer date to the last day of the last period covered by your legacy revenue accounting system. For
38
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
all documents that are posted on or before this date, the initial load function of Revenue Accounting expects
to receive legacy data, for example, posted revenue. The transfer date always has to mark the end of a period,
as only a complete period can be closed. Revenue Accounting can only start at the beginning of a new period.
The first period after the legacy data transfer date is also the first period during which revenue is managed by
Revenue Accounting.
● Date of Adoption: Date as of which a company adopts a new standard for revenue recognition in its published
financial statement.
● Source Accounting Principle: In the transition phase, the source accounting principle is used as a basis to
copy data into the new accounting principle.
● External Source Accounting Principle: You tick the checkbox to indicate that the source accounting principle
is an external one, for example, when it is not managed in Revenue Accounting.
2.2.13 Free Selections in Mass Activities for RAI Transfer and
Processing
Use
It is now possible to use the free selections in the mass activities for the transfer (transaction FARR_RAI_TRANS)
and processing (transaction FARR_RAI_PROC). This also enables you to restrict the revenue accounting items to
be transferred and processed according to customer-specific fields.
Technical Details
Table 27:
Technical Name of Product Feature
Not available
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 120
Application Component
FI-RA (Revenue Accounting)
Available As Of
Release 1.2
Required Business Functions
None
Additional Details
You can choose the new action “free selections” in the application toolbar in both transactions. For more
information, see the documentation for the respective transactions.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 39
2.3 Release 1.3
This section contains all release notes. You can use the navigation structure on the left to find a specific release
note.
2.3.1 Aggregate General Ledger Postings by Debit/Credit
Indicator
Use
You want to continue to use the benefits of having detailed posting records in the Revenue Accounting subledger
table. However, you only need the posting of revenue adjustments and contract asset amortization (or contract
liability) in the general ledger.
In this case, you have the option to aggregate the postings from the subledger table to the general ledger when
you use the Revenue Posting program.
Features
A new Customizing option is used which allows you to decide whether you want to aggregate the general ledger
posting lines by debit/credit indicator. This Customizing is based on the company code and accounting principle.
Note
This Customizing should not be changed frequently.
In Customizing, choose: SAP Customizing Implementation Guide Financial Accounting (New) Revenue
Accounting Revenue Accounting Postings Switch on Posting Optimization .
If you trigger this new functionality when all fields listed have the same value, the general ledger posting lines will
be aggregated. Even if they have a different debit/credit indicator, the posting lines are still netted.
You can still continue to use the revenue accounting subledger to provide detailed posted data.
Technical Details
Table 28:
Technical Name of the Product Feature
FIRA_AGGREGATE_BY_DC_INDICATOR
40 P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 130
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.3
Prerequisite Business Functions N.A.
2.3.2 Allow Different Currencies for Sales Order Items and
Invoices
Use
In Revenue Accounting, the system supports different invoice transaction currencies from that of the referenced
sales order. Also, a different currency in a credit or debit memo is supported if the referenced credit or debit
memo request is set up to a referenced sales order item (revenue accounting type relevance type ‘M’).
Technical Details
Table 29:
Technical Name of the Product Feature
FIRA_DIFF_CURR_ORD_INV
Content of the Product Feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 130
Application Component FI-RA
Availability Revenue Accounting and Reporting 1.3
Prerequisite Business Functions N.A.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 41
2.3.3 General Enhancements
Use
Several Revenue Accounting functions have been enhanced, as follows:
● Inbound Processing: New selection parameters for initial load.
For testing purposes, it can be helpful to execute the initial load (transaction FARR_RAI_PROC_LOAD) only for
a subset of order items that belong to a company code. Selecting such a subset can be made by using the
parameters Reference Type for Order and Reference ID for Order. After processing the subset, you can load
the related fulfillment and invoice items by selecting the two new checkboxes Select related fulfillments and
Select related invoices.
● Inbound Processing: Prevent deletion of test data after import method to generate revenue accounting item
classes.
The configuration of revenue accounting item classes with the configuration Transportable or Released as
Productive status can be transported to another system. When you press the Transport pushbutton, the
configuration is added to a transport request. You can decide whether that class is automatically generated in
the target system. Up to now, all test data was deleted by the import after generating a revenue accounting
item class. All test data is now kept during the import after generation, even in non-productive classes, unless
you press 'Yes' in the new pop up Automatic Deletion.
● Add indicator to shift posting on revenue schedule user interface.
● Enable cumulative manual fulfillment.
● Reverse posting entries after revenue posting is suspended.
● Set the status of the revenue accounting period to In Closing for a batch of company codes.
Technical Details
Table 30:
Technical Name of the Product Feature
FIRA_CONTRACR_MMGT
The product feature is New
Country Dependency Valid for all countries
Software Component Version REVREC 130
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.3
Prerequisite Business Functions N.A.
42 P U B L I C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
2.3.4 Check and Enhance Data Sources for Disclosures
Use
In Revenue Accounting, new sample reports have been provided:
Disaggregation of Revenue: By Multiple Dimensions
Contract Balance
A new Business Add-In (BAdI) for the data source is also provided: Check if table FARR_D_DELDEFITM should be
cleared.
Features
Disaggregation of Revenue: By Multiple Dimensions (New Sample Report)
● Analyze revenue by different dimensions
● Fields in the Revenue Accounting subledger can be used and defined as dimensions for the nature, timing and
uncertainty of the revenue
● Customized fields in the Revenue Accounting subledger can be used and defined as dimensions
Contract Balance (New Sample Report)
● Display the opening and closing balances for either receivables, contract liability and contract asset, or
deferred revenue and unbilled receivables from the Revenue Accounting subledger.
New BAdI: Check if table FARR_D_DELDEFITM should be cleared: This BAdI is used in the Revenue Accounting
(FI-RA) component. You can use this BAdI to decide whether table FARR_D_DELDEFITM needs to be cleared in
each process of data source extraction (0FARR_RA_20 and 0FARR_RA_30).
Technical Details
Table 31:
Technical Name of the Product Feature FIRA_FOREIGN_CURR
Content of the Product Feature New
Country Dependency Valid for all countries
Software Component Version REVREC 130
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.3
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 43
Prerequisite Business Functions N.A.
2.3.5 Exclude Billing Plan Items
Technical Details
Table 32:
Product Feature Is
New
Country Dependency
Valid for all countries
Application Component
FI-RA
Available As Of
REVRECSD SP10
Use
You assign a new attribute Exclude from Revenue Accounting to billing blocks in Customizing under Sales and
Distribution Revenue Accounting and Reporting Exclude Billing Plan Items .
Features
If you set a blocking reason with attribute Exclude from Revenue Accounting for a billing plan item, the item is not
included in the calculation of the contractual value of the performance obligation. For example, if the value of a
sales order item is $100 and a billing plan item with a value of $30 is excluded from revenue accounting, the value
of the corresponding performance obligation is $70. Also, no planned invoice revenue accounting item is created
and sent to revenue accounting for billing plan items excluded form revenue accounting.
You use this functionality when a billing plan item will not be billed, for example, when the first month is free. If the
billing plan item is billed despite the blocking reason, it will be included in the calculation of the contractual value
the next time you change this sales order. Setting a billing block reason with attribute Exclude from Revenue
Accounting in a sales order item or sales order header has no effect.
2.3.6 Foreign Currency Handling According to IAS 21/ASC 830
Use
In Revenue Accounting, a foreign currency can be translated into local currencies with actual rates.
44
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
If a revenue accounting contract is in a foreign currency, Revenue Accounting recognizes revenue with actual
rates as follows:
● If a revenue accounting contract has deferred revenue or a contract liability balance, revenue will be
recognized at the average rate of historical liability.
● If the revenue contract has no liability balance, revenue will be recognized at the spot rate when you execute
the Transfer Revenue program.
Note
The revenue accounting contracts that are calculated with fixed rate before Revenue Accounting 1.3 will keep
using Fixed Exchange Rate Method even though the corresponding accounting principle is specified to use
Actual Exchange Rate Method after you have upgraded to Revenue Accounting 1.3. Migration cannot switch
from Fixed Exchange Rate Method to Actual Exchange Rate Method.
Features
Realized Exchange Rate Difference Gain/Loss is adjusted by Revenue Accounting when a monetary asset item
such as Unbilled Receivable or Contract Asset is cleared by billing.
Revenue Accounting calculates the invoiced amount (invoice due amount) and revenue amount, and transfers the
balance to the contract liability and contract asset account with the actual rate of billings and revenue recognition.
You can use BAdI FARR_DISTRIBUTE_INVOICE to distribute the invoiced amount, or invoice due amount, to
performance obligations within a contract, if the revenue contract is in the multi-element- arrangement scenario.
Prerequisites
In Revenue Accounting, the amount in transaction currency and the 1st local currency (company code currency)
is always calculated within Revenue Accounting, and the FI document generated will use the amount calculated in
Revenue Accounting in transaction currency and local currency.
You can define whether the amount in the 2nd local currency and the 3rd local currency are to be calculated in
Revenue Accounting or they are calculated by the standard FI interface to determine the amount.
Technical Details
Table 33:
Technical Name of the Product Feature
FIRA_FOREIGN_CURR
Content of the Product Feature New
Country Dependency Valid for all countries
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 45
Software Component Version REVREC 130
Application Component FI-RA
Availability SAP Revenue Accounting and Reporting 1.3
Prerequisite Business Functions N.A.
2.3.7 Inbound Processing: Exempt and Restore Revenue
Accounting Items
Use
You can now exempt revenue accounting items from transferring or processing. This prevents repeated
processing of corrupt items until the errors are resolved and allows a comprehensible cleanup of corrupt data.
Technical Details
Table 34:
Technical Name of Product Feature
Inbound Processing: Exempt and Restore Revenue Accounting Items
Product Feature Is
New
Country Dependency
Valid for all countries
Software Component Version
REVREC 130
Application Component
FI-RA-IP
Available As Of
Release 1.3
Required Business Functions
None
Additional Details
By using the monitor (transaction FARR_RAI_MON), you can exempt revenue accounting items and save them in
the Raw – Exempted status or the Processable – Exempted status. Items with these two new statuses are no
longer considered in the respective processing steps. Exempted items can be restored when the settings of the
selected exemption reason allow restoration, for example when the error is resolved. An exemption history is
created for each exempted and restored revenue accounting item. Exempted items can be deleted after a certain
residence time, which can be determined depending on the type of exemption reason.
46
P U B LI C
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Effects on Customizing
You can configure the following system settings in Customizing for Revenue Accounting under Inbound
Processing.
1. Under Revenue Accounting Item Management, you can define the exemption and restoration reasons in the
following IMG activities: Define Exemption Reasons for Revenue Accounting Items and Define Restoration Reasons
for Revenue Accounting Items.
2. Under Archiving/Deletion, you can maintain the residence time in the IMG activity: Maintain Residence Time for
Exempted Revenue Accounting Items.
2.3.8 Service Acceptance
Technical Details
Table 35:
Product Feature Is
New
Country Dependency
Valid for all countries
Application Component
FI-RA
Available As Of
REVRECSD SP10
Use
You create a service acceptance for non-stock materials without goods movement or an FI document with the
delivery transaction.
Features
This service acceptance creates fulfillment revenue accounting items (RAI). These revenue accounting items
trigger the fulfillment of performance obligations (POB) if the performance obligation is customized to have
event-based fulfillment with event type Goods Issue.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 47
2.3.9 Simplified Invoice Handling
Use
You can derive the invoice amount from the original price condition of the order revenue accounting item. In this
case, you will not need to provide invoice revenue accounting items to calculate contract assets and contract
liabilities.
More Information
The prerequisites for this integration are:
● You have included the field SIMPLIFY_INVOICE in the configuration of your order revenue accounting item
class. The field indicates whether simplified invoice handling is applied for a performance obligation.
● You have to provide the indicator for simplified invoice handling in the inbound processing interface for your
order revenue accounting item.
Technical Details
Table 36:
Technical Name of Product Feature
FIRA_SIMPLIFY_INV
Product Feature Is New
Country Dependency Valid for all countries
Software Component Version REVREC 130
Application Component FI-RA (Revenue Accounting)
Available As Of REVREC 1.30
2.3.10 Transfer Future Billing Data
Technical Details
Table 37:
Product Feature Is
New
Country Dependency
Valid for all countries
48 P U B L IC
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
Application Component
FI-RA
Available As Of
REVRECSD SP10
Use
You pass future billing information from Sales and Distribution to SAP Revenue Accounting and Reporting.
Features
Milestone and periodic billing plan items create planned invoice revenue accounting items (RAI). The planned
invoice items point to the performance obligation (POB) for which they are created. Invoice revenue accounting
items that are created when the billing plan item is billed point to the planned invoice items.
The planned invoice information is displayed in the revenue schedule in column Planned Invoice Amount in the
respective period.
SAP Revenue Accounting and Reporting
What's New in Revenue Accounting and Reporting
P U B LI C 49
3 Integration of Sender Components
The following sections provide information about the integration of components that transfer operative data
(such as orders, invoices, and order fulfillments) to Revenue Accounting.
3.1 SAP Sales and Distribution Integration with SAP Revenue
Accounting and Reporting
Prerequisites
You activated the integration component and maintained your RFC destination. If you use the same system,
select None.
Features
Revenue Accounting Item Settings
You activate revenue accounting for sales order items based on these:
● Sales Organization
● Sales Document Type
● Sales Document Item Category
● Distribution Channel
● Division
● Company Code to be Billed
● Material Number
Condition type values and standard fields are passed to revenue accounting for active sales order items.
Program Enhancements
Standard Fields
You change the following standard fields with a business add-in:
● Start Date
● End Date
● Inception Date
● Reference Type
● Reference ID
50
P U B LI C
SAP Revenue Accounting and Reporting
Integration of Sender Components
Note
Items with the same reference type and reference ID are bundled into one revenue accounting contract. By
default, the reference ID is filled with the sales order number.
Customer Fields
You may add fields that aren't standard and then they are passed to revenue accounting.
More Information
For more information, see Customizing under Revenue Accounting and Reporting .
3.2 Integration with SAP Hybris Billing
Use
You can connect SAP Hybris Billing (previously BRIM) with Revenue Accounting SAP provides the sender
component CA (SAP O2C) with Revenue Accounting.
If you have integrated SAP Customer Relationship Management (SAP CRM), SAP Convergent Invoicing (in SAP
ERP) and SAP Convergent Charging (SAP CC) in the Offer-to-Cash end-to-end process, the integration with
Revenue Accounting takes place solely by means of the ERP system. The ERP system transfers all necessary data
to Revenue Accounting.
Prerequisites
The prerequisites for this integration are:
● You are using Contract Accounts Receivable and Payable (FI-CA) as part of one of the following industry
components, and you are using SAP Convergent Invoicing and provider contracts:
○ Contract Accounts Receivable and Payable
○ Telecommunications
○ Utilities
● If you are using SAP Customer Relationship Management, you have activated business function
CRM_PROVORDERINT_3_9 (Integration of SAP CC and SAP CI with Provider Order for EHP3 SP09).
● You have activated the business function FICA_EHP7_RA (Integration with Revenue Accounting) (in SAP
ERP).
SAP Revenue Accounting and Reporting
Integration of Sender Components
P U B LI C 51
Activities
To set up the integration, you make the following system settings in Customizing for Revenue Accounting under
Inbound Processing:
1. Under Revenue Accounting Item Management, define logical systems and assign them to sender component
CA (SAP O2C) in the Define Sender Components IMG activity.
2. Under Revenue Accounting Items create revenue accounting item classes CA01, CA02, and CA03, and
generate them.
The technical names are set by SAP. This ensures that the system automatically provides the required
settings for each class when it is generated.
The revenue accounting item class CA01 defines the technical properties of order items. Class CA02 defines
the technical properties of fulfillment items, and class CA03 defines those of invoice items.
You then activate the integration with Revenue Accounting and configure the RFC destination to the revenue
accounting system, meaning the system, in which SAP Revenue Accounting and Reporting is running, in
Customizing for Contract Accounts Receivable and Payable.
More Information
Also see the information on integration in the documentation of Contract Accounts Receivable and Payable under
Integration Revenue Accounting and the documentation of business functions CRM_PROVORDERINT_3_9
and FICA_EHP7_RA.
3.3 Integration with SAP CRM
Use
You can connect the SAP Customer and Relationship Management (CRM) to Revenue Accounting.
SAP provides the sender component CRS (SAP CRM Service) with Revenue Accounting.
The integration takes place from CRM via ERP to Revenue Accounting. If you bill the CRM service business
transaction in ERP SD, the SD integration components must then be installed for revenue accounting (add on
component REVRECSD in the ERP system.
Prerequisites
The prerequisites for this integration are:
● You utilize the CRM Service Application and use business transactions of the following types:
○ Service contract
52
P U B LI C
SAP Revenue Accounting and Reporting
Integration of Sender Components
○ Service order and service confirmation
○ Product package service order quotation
● You have activated business functions CRM_SRV_REVACC_4 (CRM Service: Revenue Accounting in
enhancement package 4) in the CRM system and CRM_SRV_REVACC_ERP_8 (CRM Service: Revenue
Accounting Integration) in the ERP system.
● You have set up accounting integration for CRM service business transactions in ERP.
● You bill CRM service business transactions (by means of the Billing Engine) and have set up the
correspronding accounting interface in ERP.
Or you bill CRM service business transactions in ERP SD and set up this interface in ERP.
Features
To set up integration, you make the following system settings in Customizing for Revenue Accounting under
Inbound Processing:
1. Under Revenue Accounting Item Management, define logical systems and assign them to sender component
CRS (SAP CRM Service) in the Define Sender Components IMG activity.
2. Under Revenue Accounting Items create revenue accounting item classes CS01, CS03 and generate them.
The technical names are set by SAP. This ensures that the system automatically provides the required
settings for each class when it is generated.
The revenue accountung item class CS01 defines the technical characteristics of the order items and the
class CS03 those of the invoice items of CRM billing.
The class SD03 defines the technical properties of the invoice items from ERP SD.
You activate the integration with Revenue Accounting in Customizing for CRM Service Business Processes in the
CRM system.
You configure the RFC destination to the revenue accounting system, which is the system that runs the SAP
Revenue Accounting and Reporting, in SAP Customizing in the ERP System under
Integration with Other SAP
Components CRM Settings for Service Processing .
More Information
See documentation of busniess functions CRM_SRV_REVACC_4 (CRM Service: Revenue Accounting in
enhancement package 4) in the CRM system and CRM_SRV_REVACC_ERP_8 (CRM Service: Revenue Accounting
Integration) in the ERP system.
3.4 Integration of External Sender Components
For information about connecting to external sender components, see SAP Note 2392956 .
SAP Revenue Accounting and Reporting
Integration of Sender Components
P U B LI C 53
4 Inbound Processing
Revenue accounting receives operative data from the components integrated with it (orders, invoices and order
fullfullments, such as goods issues) and stores this in the form of Revenue Accounting Items [page 54]. The
technical properties of the revenue accounting items are determined by the Revenue Accounting Item Classes
[page 55]. You define these technical properties by undertaking the Configuration of Revenue Accounting Item
Classes [page 55]. You process revenue accounting items for revenue accounting contracts, performance
obligations, and order fulfillments. The status of a revenue accounting item reflects its processing status. You can
monitor this centrally.
In Customizing of Revenue Accounting under Inbound Processing Revenue Accounting Item Management
Define Program Enhancements , there are business add-ins available that enable you to influence inbound
processing. Here you can:
● Enrich and check revenue accounting items before these are created with the status Raw
● Enrich and check revenue accounting items if these are transferred to the status Processable
● Determine a revenue accounting ID for every revenue accounting item, in order to group all items that belong
together.
4.1 Basic Concepts of Inbound Processing
The following sections give you an overview of the concepts and parameters:
● That define and control inbound processing
● With which you can design the processes and adjust them to your requirements
In addition to the most important concepts, the following sections also explain the usage of the individual
elements, and the settings in Customizing are discussed.
4.1.1 Revenue Accounting Item
Revenue recognition-relevant transactions result in the creation of revenue accounting items. Revenue
accounting items contain source information about these transactions that result in the creation of revenue
accounting contracts, performance obligations, and order fulfillment in Revenue Accounting.
The class for revenue accounting items [page 55] determines the technical properties of revenue accounting
items.
The following statuses are possible for a revenue accounting item:
● Raw
● Processable
● Processed
54
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
The various statuses of revenue accounting items are reflected on a technical level using different database
tables. For each status and revenue accounting item class, there are two database tables one for main items and
one for conditions (one for each record type).
4.1.2 Class for Revenue Accounting Items
The class for revenue accounting items determines the technical properties of a revenue accounting item. These
technical properties include:
● Basic fields delivered by SAP that you have added by selecting interface components
● Customer-specific fields that you have added by selecting customer fields
● Database tables, in which the system stores the revenue accounting items based on their status
● Function modules (RFC-enabled) that receive revenue accounting items
● Function modules that save the revenue accounting items in the appropriate database tables
4.2 Configuration of Revenue Accounting Item Classes
Use
By configuring revenue accounting item classes, you specify the technical properties that suit your needs for
revenue accounting items. The settings determine the structures of the database tables as well as the interfaces
for the data transfer.
Prerequisites
To be able to select customer fields in a class, you must fill the corresponding enhancement includes. For more
information, see Customer Fields in Revenue Accounting Item Classes [page 58].
Process
You create and configure new classes in Customizing of Revenue Accounting under Inbound Processing
Revenue Accounting Items Maintain Revenue Accounting Item Class .
Once you have completely defined a revenue accounting item class and set the configuration and activation
status, you generate the interfaces (see Interface Generation [page 59]).
You configure revenue accounting item classes in the following steps:
1. Selecting interface components
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 55
SAP supplies interface components that you can activate for each class. There are interface components for
which particular class types are mandatory. The system automatically activates them depending on which
class type you choose.
2. Selecting customer fields
You can include customer-defined fields in the interface and data store.
3. Administering indexes for database tables
To optimize performance, you can choose the pushbutton to create your own indexes in database tables.
The customer fields and also the fields of the active interface components are available for use in the index
fields.
4. Display table structure
You can display the structure for revenue accounting items by choosing the pushbutton.
5. Changing the configuration status
After creation, the class has the configuration status In Processing. You can change a class with this status as
you like. If you activate the class, the system does not include it in a transport order. The system is only able
to include the class in a transport request if you have set the status to Transportable. You can also make as
many changes as you like in this status. When you set the configuration status to Released as Productive, you
can only make the following compatible changes:
○ Selecting additional interface components that are not yet active
○ Selecting additional customer fields that are not yet active
○ Creating, displaying, and changing indexes
Note
Remember that this can result in conversions of table content already present.
6. Activating the configuration
You can only activate a class if it is thoroughly consistent. In particular, this means that it must be without
errors.
At a given time, there can only ever be one active version of a revenue accounting item class. If you make
changes to the active version of a class without activating it, the system creates a working version in addition
to the active version. When you activate the configuration, the working version becomes the active version.
You can also return to the last active version of the configuration from the working version. To determine
differences between the working version and the active version, you can compare these versions.
When you activate the configuration, the system checks the completeness of the work structures for revenue
accounting items used in the processing programs. The system can then automatically add fields of the class
that are are not already contained in the work structures. These fields are added in the related customer
includes of the work structures.
As soon as there is a class with the Productive configuration status, the system writes a history of the active
versions. This allows you to track when changes were made to the configuration. If you activate a class with
the configuration status Transportable or Released as Productive, the system creates a transport request for
the class, with which you can transport the active status of the class to follow-on systems. You can also
decide if the class is automatically generated in the target system. When it is transported to the target
system, the revenue item class is then automatically generated by the after-import method
FARR_RAIC_GEN_AFTER_IMP. If you transport the test configuration, the test data will not be deleted during
the generation as long as you do not actively select it.
You can only generate classes if the customer includes have the same status in the source and target system.
56
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
Caution
When you update the profitability analysis and transfer the characteristics for the derivation of the
profitability segment COPA_MI01, the structure of the characteristics for profitability analysis (COPACRIT)
have to be identical in the Customizing system and target system.
4.2.1 System Landscape
The configuration and generation of revenue accounting item classes are based on a three-level system landscape
as can be seen in the following figure.
Figure 1: System landscape structure
You configure your revenue accounting item classes in your Customizing system. The system saves the
configuration as Customizing data. You can transport this Customizing data into a test system as soon as you
change the status of the configuration to Transportable. The transport connection is integrated in the transaction
for the configuration of revenue accounting item classes in the standard system. The system ensures that only
complete and consistent configurations are transported. Use transport object FARR_RAI_CONF for the transport.
Taking the transported Customizing data as a basis, you can generate the corresponding workbench objects
(such as RFC function modules for the data transfer and database tables for data storage) for the classes in the
test system. Then you can test the classes with test data.
Once you have successfully concluded your tests, you can transport the Customizing data to the production
system to generate objects for the classes there.
Caution
You can change the configuration of revenue accounting item classes. This gives you the option of regenerating
workbench objects for classes in the test and production system.
However, as soon as you wish to use a class in the production system for production data, you should set the
configuration status for the class to Released as Productive in the Customizing system. This status only
permits compatible changes to the configuration of the class in the Customizing system. This means that you
are allowed to insert a new field in the table for example, however, you are not allowed to delete fields. During
the regeneration in the production system, this ensures that no production data is lost.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 57
4.2.2 Interfaces for Revenue Accounting Item Classes
The system generates a separate RFC function module for every revenue accounting item class. With this RFC
function module, you transfer revenue accounting items for a class to Revenue Accounting (FI-RA). The naming
convention for the function modules is /1RA/xxxx_RAI_CREATE_API, where xxxx stands for the four-character
name of the class.
The generated RFC function module is adapted to the structure of the revenue accounting item class with its
parameters.
In the standard system, a COMMIT WORK (or ROLLBACK WORK in the case of an error) occurs every time the RFC
function module is called. This means that every RFC function module represents a logical unit of work (LUW) as
standard. You can override this in the IV_TEST parameter. See the documentation in the system.
If the RFC function module is called, the system writes an application log for the processing of the transferred
revenue accounting items. You can display this application log with the transaction SLG1 for the object FARR and
the subobject CREATE.
Caution
When you update the profitability analysis and transfer the characteristics for the derivation of the profitability
segment COPA_MI01, the structure of the characteristics for profitability analysis (COPACRIT) have to be
identical in the Customizing system and target system.
4.2.3 Customer Fields in Revenue Accounting Item Classes
Use
You can include customer-specific fields in the interface and data store of revenue accounting item classes.
Activities
For you to be able to use customer fields when configuring revenue item classes, you have to add these fields to
one of the following enhancement includes:
● INCL_EEW_FARR_ARL
This include is used for fields that are only used in revenue accounting items.
● INCL_EEW_FARR_POB
This include is used for fields that are also needed in the performance obligations in contract management.
● INCL_EEW_FARR_REP
This include is used for fields that you also want to use in evaluations.
Note
To ensure that customer fields are taken into account during the processing of revenue accounting items, the
system checks the completeness of the work structures when the configuration of the revenue accounting item
58
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
class is activated. The system automatically adds any missing customer fields to these structures. These fields
are added in the related Customer include of the work structure.
When you add customer fields to a revenue accounting item class, please note that the system only passes on
fields of the order item class type to contract management. As a consequence, you can only use fields of this
class type for reporting.
Customer fields of the fulfillment item and invoice item class types are not passed on to contract management
and cannot be used for reporting.
When you add fields of these class types to a revenue accounting item class, you can only use them for
customer-specific changes and checks during the creation and transfer of revenue accounting items.
4.2.4 Interface Generation
Use
From revenue accounting item classes, you generate the interfaces for the transfer of revenue accounting items
as well as the data storage for the revenue accounting items.
Prerequisites
You have configured classes and activated their configuration in Customizing activity Maintain Revenue
Accounting Item Class under Inbound Processing Revenue Accounting Items . In order to be able to generate
interfaces for a revenue accounting item class, the configuration of the class must be active.
Features
You generate intefaces for revenue accounting item classes in Customizing of revenue accounting under
Inbound Processing Revenue Accounting Items Generate Interfaces for Revenue Accounting Item Classes .
In order to generate the interface and data storage for a revenue accounting item class, you select the class in the
list and choose the pushbutton
in the toolbar. Generation is possible when a corresponding generation status
exists.
Note
During generation, the system deletes existing generated objects if necessary. That means that you can lose
the data. The system behavior is according to the configuration status of the class:
● In Processing
You can choose whether to delete existing objects and generate them again, or whether to retain existing
data. In the first case, you lose the data.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 59
● Transportable
You can choose whether to delete existing objects and generate them again, or whether to retain existing
data. In the first case, you lose the data.
● Released as Productive
If you generate a class for the first time in the Released as Productive status, the system deletes all existing
objects and regenerates them. You lose data in this case.
For all other generations for a class in the Released as Productive status, the system only regenerates
objects that either did not yet exist or that need to be adjusted. All of the data that existed up to that point
remains.
The technical names of all generated objects begin with /1RA/ and contain the technical name of the revenue
accounting item class that they relate to. You can display the complete object names for a revenue accounting
item class in transaction FARR_RAI_GEN under Generated Objects (or using the service function module
FARR_RAI_GEN_OBJNAMES).
In the context of generation, the following functions are available in the toolbar. In order to use one of the
functions, select a revenue accounting item class and choose a pushbutton:
● Checking generation
When you call up the transaction, the system checks the entries that were already made in the configuration,
including additions to interface components, customer fields, and indexes. A detailed comparison based on
changes of the generated function modules only occurs if you explicitly check the generation by choosing the
pushbutton.
● Deleting generated objects
If objects already exist and the configuration status of the interface is not Released as Productive, you can
delete these objects. To do so, choose the pushbutton.
● Displaying generated objects
In order to display generated objects and to navigate to the objects, select the pushbutton .
● Displaying the generation history
The generation history provides an overview of the executed generations. You can display the respective
generation log and the generated configuration for a generation. To do so, choose the pushbutton .
● Displaying the generation log
The generation log shows the activities that the system executed during the generation. Call up the log using
the pushbutton .
● Displaying the generated configuration
Using the pushbutton , you can display the configuration of the class that you most recently generated.
● Compare configuration generated with the active version
By choosing the pushbutton , you can compare the configuration version of the class with the current
active version. You receive a detailed list of the differences for each status and record type. The system also
shows whether the generated function modules would have been changed in the case of new generation.
● Releasing and locking classes for use
You use the release status of the interface of a class to control whether data for this class can or cannot be
transferred. The following statuses are possible:
○ __ Not released for use
○
A class can only contain this status if its configuration has also been released for productive use.
60
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
○
A class can contain this status in the development or test system only if the status of the configuration is
In Processing or Transportable. This gives you the option of testing a class in advance.
If you execute generation for a revenue accounting item class, the interface is released for the transfer of revenue
accounting items by default. If you would like to temporarily lock the transfer of revenue accounting items for a
class on a technical basis, choose the pushbutton . If you want the class to be available again for data transfer,
choose the pushbutton .
4.3 Adding Accounts to Revenue Accounting Items
Use
If a sender component transfers reference accounts in order items and invoice items, Revenue Accounting
determines the target accounts for posting based on Customizing rules (for example, for posting recognized
revenues or for receivables adjustments) as described under “Revenue Posting” in Account Determination [page
207].
If the sender components do not transfer any G/L accounts with the operative data, then Revenue Accounting
determines the G/L accounts for posting order items by using Customizing rules from the transferred revenue
accounting items. The system derives the G/L accounts for fulfillment items and invoice items using the reference
to the order item.
To derive the G/L accounts from characteristics of order items, the sender system has to set the Determine
Revenue Accounts with BRFplus indicator in main conditions. The sender system must also set the Determine P+L
Accounts with BRFplus indicator in condition records.
If these indicators are set, then the system derives the G/L accounts during the processing of order items in a
separate step that comes before the account determination when a G/L account is already entered. After that,
the system processes the enriched items exactly as if the sender system had transferred them with G/L
accounts.
You define in Customizing for each revenue accounting item class which characteristics Revenue Accounting uses
to derive which G/L accounts.
The system derives the G/L accounts for fulfillment items and invoice items using the reference to the order item.
Activities
To derive G/L accounts from order items:
1. Enter the derivation rules for G/L accounts in Customizing for Revenue Accounting under Inbound
Processing Revenue Accounting Item Management Assign BRFplus Applications to Revenue Accounting
Item Classes , by assigning BRFplus applications to the revenue accounting item class of the Order Item
class type.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 61
2. For each order item class, enter an ABAP structure that references the BRFplus application. In Customizing
for Revenue Accounting, choose Inbound Processing Revenue Accounting Item Management Maintain
BRFplus Structure .
In this way, you can derive the G/L accounts from any characteristics of order items.
Note
If you want to derive G/L accounts based on customer fields, you have to define the BRFplus structure first in
Customizing. Then you can add the fields to the revenue accounting item class and generate the class. Once
this is done, the fields are available when you define your BRFplus application.
The function is available both in mass processing for revenue accounting items (transaction FARR_RAI_PROC)
and in the monitor for revenue accounting items (transaction FARR_RAI_MON), when you choose .
4.4 Changing of Raw Data and Error Handling
Use
In the monitor for revenue accounting items, you can do the following in case of error:
● Manually change the contents of individual fields
● Use mass change to manually change multiple field values for multiple items at the same time
Prerequisites
You have specified which fields can be changed in Customizing for Revenue Accounting under Inbound
Processing
Revenue Accounting Items Define Modifiable Fields for Revenue Accounting Items . (In the
standard system, you are not permitted to modify any fields.)
You need authorization for authorization object F_RRRAIADM.
Features
If you change values for a raw data item, the system updates the change history. In the change history, all item
changes are listed chronologically.
62
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
Activities
To change billable items and resolve errors, choose transaction FARR_RAI_MON (Display of Revenue Accounting
Items).
For more information, see the program documentation.
4.5 Transfer of Revenue Accounting Items to Processable
Status
Use
For the processing of revenue accounting items to be able to start, the items delivered must have the status
Processable.
Features
During the transfer the system checks the items contained in the sales order of a sender component. If the check
is successful, the system saves the items as processable items. If the check finds an error, the items remain in the
raw data. The system checks all the items of a sales order document (HEADER_ID) in a logical unit. An error in one
item causes the check to terminate for all the other items in the document.
During the transfer of data from feeder systems, the system normally stores the data as processable items in
revenue accounting. Then you can process these items. However, for the following reasons, the system first saves
the data as raw data:
● In Customizing for the upload rule, you specified that the items are to be added as raw data (see Customizing
for Revenue Accounting under
Inbound Processing Revenue Accounting Items Assign Upload Rules to
Revenue Accounting Item Classes ).
● The system was unable to check some of the field values or determine them uniquely. The item was added to
the raw data as a result. Possible reasons for this:
○ The company code, the currency or the reference type is not known.
○ The assigned order item could not be determined for a delivery or invoice item. The order item must have
already been saved as Processable.
○ The sales organization, distribution channel, division, item category, material number or plant could not
be determined for the integration with an SD system.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 63
Activities
To transfer raw data to the processable status, you have two options:
● Mass Processing
1. For the transfer of mass data, choose transaction FARR_RAI_TRANS (Transfer Revenue Accounting
Items).
2. Make your selection under Selection Data.
3. Schedule the program run. Choose .
The system transfers the items matching the selection from the status Raw to the status Processable.
Note
The parallel processing is based on the subarea (KEYPP). This makes sure that the system transfers all of
the revenue accounting items of an order for a sender component together in the same interval.
When transferring items from sales orders to the status Processable, the system determines the subarea
for the parallel processing based on the reference.
When transferring delivery and invoice items to the status Processable, the system determines the items
assigned in the sales order first. The system derives the subarea for the parallel processing from the order
item.
● Dialog Processing
You can transfer individual items manually in transaction FARR_RAI_MON (Display of Revenue Accounting
Items
), see Displaying Revenue Accounting Items [page 72].
4.6 Processing Revenue Accounting Items
Use
You use transaction Process Revenue Accounting Items (FARR_RAI_PROC) to process large volumes of data in
parallel.
Schedule the program run at regular intervals, at least once for each period, but not more often than is really
necessary. If you schedule the program run more frequently, you increase the workload on the subsequent
process, as the following example illustrates.
Example
1. You create the order item 4711 on January 1.
2. On January 2, you change the order item for the first time.
3. On January 3, you change the order item again.
You transfer the order items on a daily basis.
Both when you create and each time you change the order item, the sender system generates a separate
revenue accounting item.
64
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
However, revenue accounting only ever processes the most current revenue accounting item.
If you carry out processing daily, revenue accounting processes all of the items generated. If you carry out
processing only on January 4, the program discards the revenue accounting items generated on January 1 and
2, and only processes the most current item from January 3.
Features
The program selects the revenue accounting items present in the system with status Processable, and transfers
these to the status Processed.
Activities
Specify the required company code and start the program direct using , or else schedule the program run.
If you choose the Job Distrib. pushbutton, you can distribute the load explicitly to server groups.
4.6.1 BRFplus Functions Executed During Processing
Use
SAP delivers the following BRFplus application templates:
● FARR_AP_SD_PROCESS_TEMPLATE
You use this template for revenue accounting item classes used for the integration with Sales and Distribution
(SD).
● FARR_AP_CA_PROCESS_TEMPLATE
You use this template for revenue accounting item classes used for the integration of SAP Hybris Billing
(sender component CA).
● FARR_AP_CRM_PROCESS_TEMPLATE
You use this template for revenue accounting item classes used for the integration of SAP Customer
Relationship Management (CRM).
● FARR_AP_PROCESS_TEMPLATE
You use this template for revenue accounting item classes used for the integration of any other sender
component.
You create your own BRFplus application by copying the appropriate template application delivered by SAP. You
implement your installation-specific logic by maintaining the appropriate decision table entries or adapting the
rule sets in your copy. You can find more detailed information about creating and modifying BRFplus applications
and functions under
help.sap.com Technology Platform SAP NetWeaver SAP NetWeaver 7.0 EHP2
Application Help Function-Oriented View (English) Application Platform by Key Capability Business Services
Business Rule Framework plus (BRFplus) .
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 65
Caution
To make sure that the consistency of system data is not compromised, you have to consider some restrictions
during the implementation of BRFplus functions. You are not allowed to use one of the following language
elements or perform the following actions:
● COMMIT WORK
● ROLLBACK WORK
● CALL FUNCTION 'DEQUEUE ALL'
● Deletion of locks that you have not set yourself
● Implicit database commits triggered by RFC calls or by a MESSAGE or WAIT statement
Each template includes BRFplus functions that the system executes during the processing of revenue accounting
items.
Caution
When you copy an application template, do not change the names of the BRFplus functions provided with the
template.
The system executes the following BRFplus functions once for each revenue accounting item:
Table 38:
BRFplus Function The function is used to determine:
FC_RAI_AD_REC_ACCOUNT
The receivables account
This function is executed once for each order item.
If a receivables account can be determined, the account is
stored in the processed revenue accounting item as well as in
the related performance obligation(s).
If no receivables account can be determined, the system tries
to determine the receivables account using the customer.
If this option does not yield any result either, the revenue ac
counting item cannot be processed and remains in status
Processable.
FC_RAI_AD_ACCOUNT_ASSIGNMENT
Account assignments, such as business area, profit center,
segment, functional area
This function is executed once for each order item.
The account assignments that are determined are stored in
the processed revenue accounting item, as well as in the re
lated performance obligation(s).
66 P U B L I C
SAP Revenue Accounting and Reporting
Inbound Processing
BRFplus Function The function is used to determine:
FC_RAI_AD_REV_ACCOUNT
The revenue account
This function is executed once for each non-statistical price
condition of an order item.
If a revenue account can be determined, this revenue account
is stored in the processed revenue accounting item.
If no revenue account can be determined, the revenue ac
counting item cannot be processed and remains in status
Processable.
FC_RAI_AD_COS_ACCOUNT
The cost account
This function is executed once for each non-statistical cost
condition of an order item.
If a cost account can be determined, this cost account is
stored in the processed revenue accounting item.
If no cost account can be determined, the revenue accounting
item cannot be processed and remains in status Processable.
FC_RAI_EST_QUAN_DET
The estimated quantity and price per unit
This function is executed once for each main price condition
of an order item.
If an estimated quantity and price per unit can be determined,
this information is stored in the processed revenue account
ing item.
The quantity is stored in the main item.
The price (estimated quantity x price per unit) is stored in the
main price condition.
If either the estimated quantity or the price per unit cannot be
determined, the revenue accounting item cannot be proc
essed and remains in status Processable.
The system executes the following BRFplus functions once for each revenue accounting item and accounting
principle. The values determined are not stored in the revenue accounting items.
In Customizing for Revenue Accounting under Revenue Accounting Contracts Define Performance Obligation
Types you can also define the default attributes of a performance obligation type. If no attributes are derived in
BRFplus functions, they are filled with these default attributes.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 67
Table 39:
BRFplus Function The function is used to derive:
FC_PROCESS_COMPOUND
Compound Group Component
The compound group component determines whether non-
bills of material are managed as distinct or non-distinct per
formance obligations. This function is executed for order
items which are non-bills of material.
FC_PROCESS_BOM
This function determines whether bills of material are man
aged as distinct or non-distinct performance obligations. This
function is executed for order items which are bills of material.
FC_PROCESS_POB
This function contains several components, including, but not
limited to, the following:
● Performance obligation name
● Performance obligation type
● Residual performance obligation
● Fulfillment type
● Event type
● Start and end dates
● Status
FC_PROCESS_POB_ADD
Links to implicit performance obligations. This function is exe
cuted for order items.
FC_PROCESS_SSP
Standalone Selling Price (SSP)
The standalone selling price can either be determined in
BRFplus or you can send it with special conditions from the
operational application. This function contains the following
components:
● SSP
● Tolerance range
● Calculation type
This function is executed for order items.
FC_PROCESS_DEFERRAL (defferrals) Additional performance obligations from defined special con
dition types (for example, right of return). This function con
tains the following components:
● Category
● Method
● Percentage
● Duration
● Event type
● Fulfillment type
● Start and end dates
68 P U B L I C
SAP Revenue Accounting and Reporting
Inbound Processing
BRFplus Function The function is used to derive:
FC_PROCESS_HEADER
Contract header attributes, such as contract category and de
scription.
This function is executed for order items.
Activities
In Customizing for Revenue Accounting under Inbound Processing Revenue Accounting Item Management :
1. Assign your BRFplus application (copy) to your revenue accounting item classes.
2. Maintain the structures that are used in BRFplus functions as input structures (activity Maintain BRFplus
Structure).
When you generate interfaces for revenue accounting item classes (using transaction FARR_RAI_GEN), the
installation-specific fields you appended to your revenue accounting item classes are automatically appended
to the BRFplus structures that you enter in this Customizing activity. This means that you can easily make
installation-specific fields available as input parameters in BRFplus.
Features
If a compound group is created for performance obligations, it supports the following features:
● The standalone selling price of the performance obligations is aggregated to the compound group and can be
allocated to other performance obligations.
● If the fulfillment applies for the compound group, the revenue is distributed to the individual performance
obligations of the compound group according to their standalone selling price.
● If the fulfillment applies to a performance obligation within a compound group, the lowest fulfillment of all
performance obligations in the compound group is applied as the fulfillment of the compound group.
Note
If a compound group is created for performance obligations receiving a percentage of completion from cost
object controlling, the fulfillment is directed to the compound group. There can only be one controlling object
number other than the initial one in such a compound group. If further performance obligations are included in
the compound group, the fulfillment is applied to those performance obligations, as well.
More Information
Upgrade Information
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 69
You can find further information about adjusting your BRFplus application after a software version upgrade in the
Administrator's Guide under help.sap.com Financial Management SAP Revenue Accounting and Reporting
SAP Revenue Accounting and Reporting 1.2 System Administration and Maintenance Information
4.6.2 Determining Quantities and Amounts
Use
Sender systems can transfer revenue accounting items that do not contain a quantity and do not contain an
amount. In that case, Revenue Accounting determines quantities and amounts when it processes revenue
accounting items.
For determining quantities and amounts (prices) per unit, SAP provides the BRFplus function
FC_RAI_EST_QUAN_DET. The system processes this BRFplus function during processing.
Example
You provide services to customers.
The performance obligation is consumption-based.
The price of the performance obligation depends on how many units the customer consumes until the duration
of the performance obligation ends.
Based on the data transferred in the revenue accounting items, you use the BRFplus function
FC_RAI_EST_QUAN_DET to estimate the amount consumed and to determine the average price per unit of
measure.
The amount of the performance obligation is determined by multiplying the estimated quantity by the average
price per unit.
The function is available both in mass processing for revenue accounting items (transaction FARR_RAI_PROC)
and in the monitor for revenue accounting items (transaction
FARR_RAI_MON), when you choose .
4.6.3 Generating Planned Invoices
Use
During processing of revenue accounting items, you can automatically generate invoices for items of a billing plan.
For this to take place, the sender system has to fill the Invoice Category attribute on the invoice items accordingly.
In Revenue Accounting, the total amount and total quantity of billing plans are represented by an order item that
is valid for the entire duration of the payment plan. In addition to this, information about the due dates and
amounts of the billing plan is stored in invoice items. If a payment plan date is invoiced, then the sender system
has to forward an additional invoice item with the billing document data to Revenue Accounting.
70
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
You can also generate the actual invoice items in Revenue Accounting. This is to support scenarios in which actual
invoicing usually corresponds to the billing plan, and therefore you do not want to connect the billing system to
Revenue Accounting (or it might not be possible).
If you want the system to generate an actual invoice from a planned invoice item of a billing plan on the posting
date, then the invoice must have invoice category 2. In addition, the Invoice Corrections from Billing Plan
(BILLING_PLAN_INV) indicator has to be set on the order item of the billing plan. In that case, the system does
not transfer any invoice items for revenue accounting items with Processed status. The system reports an error.
Invoice items of invoice category 2 keep the status Processable until their posting date is reached. If they are
processed after their posting date has been reached, then actual invoices are created from them. These invoices
then result in postings. When the actual invoice items are generated, the values in foreign currency are updated.
You can change invoice items of invoice category 2 until their posting date is reached. After the posting date is
reached, changes are no longer possible, since it could be the case that postings were already made based on this
data. Therefore, after the posting date is reached, you have to reverse these invoices and create new ones to
make a change, the same as you would for actual invoices.
The function is available both in mass processing for revenue accounting items (transaction FARR_RAI_PROC)
and in the monitor for revenue accounting items (transaction FARR_RAI_MON), when you choose .
4.6.4 Processing of Order Items with Predecessor Items
Order items have the following fields as references to their predecessor items:
● Predecessor Item Sender Component
● Logical System of the Predecessor Item
● Predecessor Item Type
● Predecessor Item ID
The fields are contained in interface component BASIC_MI01 and are therefore available in all order items.
If an order item is related to a predecessor item, the system does not treat the order item as a separate and
independent item. Instead the system aggregates the quantities and amounts of the order item with those of the
predecessor item when the item is being processed. When the revenue is posted, the system treats the
aggregated data as a change to the predecessor item.
Multiple revenue accounting items are allowed to refer to the same predecessor item. However, the total quantity
and total amount are not allowed to take on a negative value after all the items are aggregated.
Each of the items and its predecessor item must have the same company code, currencies, units of measure, and
setting for its value relevance.
The following example illustrates how the fields are used during processing of order items, based on a return in
Sales and Distribution (SD).
Example
1. A customer orders three televisions for 500 each.
2. Revenue Accounting creates a revenue accounting item for this order with a quantity of 3 and an amount of
1500, and generates the revenue postings.
3. One of the televisions is damaged in transport.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 71
4. Revenue Accounting creates an additional order item with a quantity of -1 and an amount of -500. This item
refers to the original (predecessor) order item.
5. Revenue Accounting offsets the item for the return against the original order item.
6. When the revenue posting is made, the system takes the change of the original order item into account
with a newly calculated quantity of 2 and an amount of 1000.
4.7 Displaying Revenue Accounting Items
Use
Using transaction FARR_RAI_MON, you can display, analyze, and process revenue accounting items based on your
selection criteria, regardless of their processing status.
Features
You can restrict the selection to order items, fulfillment items, invoice items, or all items belonging to order items
and their item status.
The system displays the revenue accounting items that match your selection criteria in the form of an ALV list.
You can use the following functions in the list:
Table 40:
Pushbutton Choose the pushbutton to
Transfer revenue accounting items from status Raw to status
Processable
Simulate the transfer of revenue accounting items from status
Raw to status Processable
Process revenue accounting items in status Processable
By being processed, the items receive the status Processed.
72 P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
Process items from the initial load with field value 1 in the
INITIAL_LOAD field (initial load due to a new company code
or migration package
)
Note
Items that were generated by an initial load due to a new
company code or migration package can only be proc
essed if you choose . All other items can be processed
only by choosing the Process pushbutton.
Make emergency corrections
Note
To be able to make changes, you require the special au
thorization for authorization object F_RRRAIADM. The
change is updated in a history that you display in the list by
choosing the pushbutton.
Exemption of Revenue Accounting Items from Transfer or
Processing
Note
After exempting a revenue accounting item in status
“Raw”, the item has the status “Raw - Exempted”. After ex
empting a revenue accounting item in status “Processa
ble”, the item has the status “Processable - Exempted”. Ex
empted revenue accounting items can be deleted with the
transaction
Delete Exempted Items (FARR_RAI_DELETE).
Restoration of Exempted Revenue Accounting Items
Note
After restoring a revenue accounting item in status “Raw -
Exempted”, the item has the status “Raw” again. After re
storing a revenue accounting item in status “Processable -
Exempted”, the item has the status “Processable” again.
Note
The following transactions are provided for processing mass data:
● Initial Load: Process Revenue Accounting Items (FARR_RAI_PROC_LOAD)
● Transfer Revenue Accounting Items (FARR_RAI_TRANS) (see Transfer of Revenue Accounting Items to
Processable Status [page 63])
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 73
● Process Revenue Accounting Items (FARR_RAI_PROC) (see Processing Revenue Accounting Items [page
64])
Displaying Legacy Data
On the initial screen, you can specify in your personal settings that the monitor also displays legacy data (from
previous systems). Choose the pushbutton, and select one of the following settings:
● No Legacy Data
This is the default setting. The monitor does not select any legacy data, if you choose this setting.
● Allow Display of Legacy Data in Item Display
If you choose this setting, the monitor does not select legacy data automatically. However, if you choose the
(+) Legacy Data (Display Legacy Data) pushbutton in the item list, you can show legacy data.
● Always Display Legacy Data
If you choose this setting, the monitor always selects legacy data. You can hide the legacy data by choosing
the (-) Legacy Data (Hide Legacy Data) pushbutton in the item list.
The system saves your settings in the FARR_MON_SEL user parameter and uses them the next time you call the
monitor.
If you display legacy data, the monitor shows a new tab for each of the following: legacy data for main items,
legacy data for condition items, and legacy data for planned fulfillment items.
For more information, see the program documentation.
4.8 Reconciliation of Revenue Accounting Items with Sender
Component Data
Use
Revenue accounting receives data from different source components and posts documents to FI-GL and CO-PA.
Communication between the source components and revenue accounting can cross system boundaries. In this
respect, errors may occur.
With the help of the data consistency check, you can determine whether the source items of the sender
components have been successfully transferred to Revenue Accounting. To do this, you execute the transaction
FARR_CHECK_CONS to search for inconsistencies between revenue accounting items and data from sender
component systems. The report is executed, when the posting period has been closed. You should however
execute the report regularly at shorter intervals independently from the booking period so that inconsistencies
are found as early as possible.
Completeness, when transferring the revenue accounting items, especially the fulfillment and invoice items, has
an effect on the correct determination of the revenues that have not been billed in Revenue Accounting and
Reporting.
The report processes the selected data in parallel. You specify the number of jobs that can be executed in parallel
in SAP Customizing under
Cross-Application Components General Application Functions Parallel
Processing and Job Control Parallel Processing Maintain Job Distribution . For more information, see the
program documentation.
74
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
More Information
Also see RAI Reconciliation with non-SAP Sender Components [page 285].
4.9 Reconciliation of Revenue Accounting Items with
Contracts
You can use transaction FARR_RAI_RECON to check for data inconsistencies between revenue accounting items
and revenue accounting contracts. You do so by reconciling the processed revenue accounting items with the
determined performance obligations.
During this reconciliation, the system checks if the amounts and quantities are the same in both. If the program
determines there are differences in the quantity or amount, the system saves these performance obligations. The
next time a reconciliation is performed, the program checks these saved performance obligations first.
The report parallelizes the selected data during processing. You specify the number of jobs that can be executed
in parallel in SAP Customizing under Cross-Application Components General Application Functions Parallel
Processing and Job Control
Parallel Processing Maintain Job Distribution .
For more information, see the program documentation.
4.10 BRFplus Simplified User Interface
Definition
The BRFplus simplified user interface (UI) is an alternative to the standard BRFplus UI. You use the simplified
BRFplus UI to maintain decision tables used in Revenue Accounting and Reporting.
Features
When you open the BRFplus simplified UI, a link to the available decision tables appears. You maintain the data of
the decision table by clicking the link. The screen is divided into sections: the top displays the name and the mode
of the decision table in which you are working as well as the search options for the decision fields of the table; the
bottom shows the table data. Decision fields and result fields are in different colors, whereby green represents the
result fields.
Note
The evaluation logic of BRFplus is row-based. When you use a decision table to evaluate some values, the first
entry that matches your criterion is considered independent if a closer match exists further down the table.
You place the most specific criteria at the top of the table and the less specific criteria further down.
SAP Revenue Accounting and Reporting
Inbound Processing
P U B LI C 75
In edit mode, you may
● Add new lines
● Delete lines
● Copy and paste lines
● Move lines up or down
You also have an option to navigate to related decision tables. The relationships are maintained in Customizing. If
no relationship is maintained, the button isn't visible. When you choose the Navigate to Related Decision Table
button, the values of the decision fields of the selected line are used as filters with which to call up the related
decision table. When the decision fields are the same, the decision tables are maintained. If there's no match, all
entries of the related decision table are shown.
Time Dependency is a special mode that maintains time-dependent entries. The Time Dependency and Add
Interval buttons are visible if the decision table contains a decision field based on the data element
FARR_BRF_UI_EVALUATION_DATE. After you select Time Dependency, all entries are sorted by the decision fields
and then by the evaluation date, so you can maintain entries that differ by date.
The Add Interval button creates a new entry with the same values for the decision fields as the selected row. The
system avoids gaps by proposing start and end dates when you insert a new line in an existing interval.
Note
SAP recommends that you maintain all entries in sequential rows if you have a time-dependent decision table.
76
P U B LI C
SAP Revenue Accounting and Reporting
Inbound Processing
5 Contract Management
Revenue Accounting allows you to recognize contract management either by managing performance obligations
or managing contracts directly. For performance obligations, this includes manually adding, deleting and
cancelling performance obligations. For contracts, you can create, change, search, or display a contract, as well
as combine contracts. You can also calculate and distribute contract liability and contract asset, manage cost
recognition, manage the status, and reprocess objects with existing performance obligations or contracts.
5.1 Performance Obligations
A performance obligation represents the contractual commitment of an enterprise to deliver a good or a service
to a customer in exchange for a consideration.
Use
A performance obligation usually corresponds to an item in an operational document, such as a sales order item.
Therefore, a performance obligation is not necessarily a distinct performance obligation that stands on its own for
revenue recognition.
5.1.1 Linked Performance Obligations
Use
Some items that your company promises to deliver to your customer may not be explicitly included in the
operational document. However, you may want to include them in the revenue accounting contract. In this case,
you can configure Revenue Accounting to add those implicitly promised items as linked performance obligations,
and specify which is the “leading” item of these linked items.
To indicate a leading-linked relationship, you can use the following configuration:
● A performance obligation whose Leading/Linked attribute is set to Leading.
● One or more performance obligations whose Leading/Linked attribute is set to Linked.
● The “linked” performance obligations point to the “leading” performance obligation with the attribute Leading
Performance Obligation.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 77
Example
Your company promises to deliver a software product to a customer in exchange for a consideration. For each
purchase, your company promises to deliver a technical service to make sure that the software is properly
deployed. It is an important part of your company’s delivery, even though it is not explicitly listed as a line item in
the sales order. In this case, the following performance obligations can be created to address this scenario:
Table 41:
Performance Obligation Leading/Linked Leading Performance Obli
gation
Sales Order Item
001 - Software Leading None Software License
002 - Service Linked 001 - Software None
5.1.2 Performance Obligation Hierarchies
Performance obligations in a contract are organized in a hierarchy to represent their relationships with one
another. The hierarchy can be considered a tree structure, if you think of the contract as a virtual root. A
performance obligation can have other performance obligations as its lower-level items. This relationship can
represent the following business scenarios:
● A bill-of-material structure
● A compound performance obligation that represents multiple non-distinct performance obligations
5.1.2.1 Sales Bill of Material Structures
You can use this feature to include bill of material (BOM) structures in a revenue accounting contract. When a
sales representative creates a sales order, the sales order can include a sales BOM that represents both the
finished product and its components. When the system creates a revenue accounting contract for the sales order,
it can bring over the sales BOM structure. Consequently, the system organizes the performance obligations in the
same structure as they appear in the sales order.
5.1.2.2 Compound Performance Obligations
Use
Certain items in a contract with your customer are not distinct items and cannot be posted separately for revenue
recognition. These items are identified as non-distinct performance obligations and must be combined with other
non-distinct items to form a distinct performance obligation. The performance obligation that results from the
combination is called a compound performance obligation. The system supports non-distinct performance
obligations with all fulfillment types, that is, event-based, time-based, and overtime.
78
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Note
Overtime fulfilment usually occurs with project-related performance. The overtime performance is planned for
a certain duration while the fulfilment of overtime performance obligation depends on Percentage of
Completion (POC).
Example
RR’s Software Ltd. sells business software. One of her best-selling products is an accounting tool. In a contract
with a customer, RR’s Software Ltd. promises to deliver a software license for 15 users and a maintenance service
to make sure that the software is properly installed and running.
Neither the software nor the service can work on its own, so the accountant decides that the software and service
are not distinct items. The software and service must be combined for revenue recognition even though they are
separate items on the sales order created for the transaction.
In this case, the revenue accounting contract includes the following performance obligations:
● A non-distinct performance obligation that corresponds to the software license
● A non-distinct performance obligation that corresponds to the maintenance service
● A compound performance obligation that represents the combination of the two items
5.1.3 Manual Performance Obligations
Revenue Accounting allows you to manually create a performance obligation that does not correspond to any
item in the sales order.
Use
Some items that your company promises to deliver to your customer may not be explicitly included in the
operational document. However, you may want to include them in the revenue accounting contract and allocate
some of the transaction price to them. In this case, you can manually add performance obligations for these
items.
Unlike a linked performance obligation, a manual performance obligation does not have a leading performance
obligation. In the hierarchy of performance obligations, the manually added performance obligation is always
added to the root of the structure.
Manual performance obligations do not correspond to any items in the sales order. Therefore, unless you specify
a time-based fulfillment, these manual performance obligations can only be fulfilled manually.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 79
Activities
You can perform the following maintenance tasks for manual performance obligations:
● Add manual performance obligations
● Edit manual performance obligations
● Delete manual performance obligations
5.1.4 Deletion of Performance Obligations
Use
You can manually delete performance obligations from the operational system or a contract UI, but you cannot
delete performance obligations created from operational documents. The system allows you to delete the
following types of performance obligation:
● Linked performance obligations
For more information, see Linked Performance Obligations [page 77].
● Manual performance obligations
For more information, see Manual Performance Obligations [page 79].
Prerequisites
● There is no fulfilled performance obligation or invoiced performance obligation.
● All fulfilled performance obligations have been reversed.
Features
Types of Deletion
The system applies one of the following types of deletion when you delete performance obligations:
● Soft deletion
With a soft deletion, the system marks the performance obligation as deleted so that it is no longer available
for price allocation or fulfillment. In this case, fulfillments that have not been posted are deleted. The other
fulfillments and deferral items are retained. The flags for all obligations, such as error, conflict, and block, are
removed.
● Hard deletion
With a hard deletion, the performance obligation is actually cleaned out of the system. All fulfillments, deferral
items, deferrals, notes, and attachments are deleted.
80
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
The system follows the following rules when processing requests to delete performance obligations:
Table 42:
Scenario Processing
A distinct performance obligation, regardless of whether it
was manually created, is deleted.
● If postings have occurred for this performance obligation,
the system applies a soft deletion.
● If postings have not occurred for this performance obliga
tion, the system applies a hard deletion.
A leading performance obligation is deleted.
● The system deletes the linked performance obligation as
well.
● Whether a soft deletion or a hard deletion is applied, the
same type of deletion is applied to both the leading per
formance obligation and the linked performance obliga
tion. Specifically, the following rules apply:
○ If the linked performance obligation can only be soft-
deleted (because postings occurred or for other rea
sons), then the system cannot hard-delete the lead
ing performance obligation.
○ If the leading performance obligation can only be
soft-deleted (because postings already occurred),
then the system cannot hard-delete the linked per
formance obligation.
● If the leading performance obligation is deleted after the
linked performance obligation is soft-deleted, both the
leading and the linked performance obligations are hard-
deleted.
A linked performance that was created by BRF+ rules is de
leted.
If the leading performance obligation is not soft-deleted, and it
is possible for the BRF+ rules to create a linked performance
obligation again, then the system soft-deletes the perform
ance obligation to prevent a new linked performance obliga
tion from being created by the BRF+ rules.
A linked performance that was manually created is deleted.
● If postings have occurred for this performance obligation,
the system applies a soft deletion.
● If postings have not occurred for this performance obliga
tion, the system applies a hard deletion.
A performance obligation that is a lower-level performance
obligation in a BOM structure is deleted.
● If postings have occurred for this performance obligation,
the system applies a soft deletion.
● If postings have not occurred for this performance obliga
tion, the system applies a hard deletion.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 81
Scenario Processing
A performance obligation that is a higher-level performance
obligation in a BOM structure is deleted.
● The system ensures that all lower-level performance obli
gations are either soft-deleted or hard-deleted.
● If lower-level performance obligations have been soft-de
leted, then the higher-level performance obligation can
not be hard-deleted.
A performance obligation that is a lower-level performance
obligation in a compound group (a “compound and non-dis
tinct” structure) is deleted.
The system ensures that at least two lower-level (non-dis
tinct) performance obligations remain in the structure.
A compound performance obligation that was created by BRF
+ rules is split.
The system soft-deletes the compound performance obliga
tion.
A compound performance obligation that was manually cre
ated is split.
The system hard-deletes the compound performance obliga
tion.
All lower-level performance obligations in a compound group
(a “compound and non-distinct” structure) are deleted.
The entire structure is either soft-deleted or hard-deleted.
5.1.5 Cancellation of Performance Obligations
Use
After sales orders have been passed to Revenue Accounting and revenue accounting contracts have been
created, you may need to cancel the contracts for some reasons. As soon as the cancellation is performed in
sender components, a finalization date will be passed down to revenue accounting engine as the sign to terminate
performance obligations. In the meanwhile, the operational document is locked with status “rejection” and thus
canceled. In such a case, only processable fulfilled revenue accounting item and processable invoice revenue
accounting item can be processed and passed to Revenue Accounting.
Note
Cancellation is performed on performance obligation. Only after all performance obligations have been
cancelled can the revenue accounting contract be cancelled.
82
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Example
There is a sales order as follows:
Table 43:
Contractual Price Invoiced Amount Recognized Amount Fulfillment (Percent
age)
Unbilled Receivable
EUR 1000 EUR 900 EUR 980 98% EUR 80
For some reasons, you decide to cancel this order, so you perform the cancellation in Sales and Distribution
(SD) and SD passes a finalization date to Revenue Accounting. In Revenue Accounting and Reporting, the
contract is adjusted as follows:
● Contractual price is set to invoiced amount. The invoiced amount is the total amount in billing, credit
memo, and debit memo documents that are posted. The amounts in documents with future posting dates
are also included in the calculation.
● The fulfillment is set to 100%.
● The unbilled receivables amount is set to 0.
Table 44:
Contractual Price Invoiced Amount Recognized
Amount
Fulfillment (Per
centage)
Unbilled Receiva
ble
Finalization Date
EUR 900 EUR 900 EUR 900 100% EUR 0 The day you per
form the cancella
tion.
Prerequisites
You have defined reasons for rejection in the following Customizing:
Sales and Distribution Sales Sales Documents Sales Document Item Define Reasons for Rejection
Features
Complete Performance Obligations after Cancellation
Revenue Accounting and Reporting searches for cancelled performance obligations. Usually these performance
obligations have a finalization date and their statuses are “in process”. Then the system changes their statuses to
“completed” if the finalization date is earlier than the date when the search takes place. In the meanwhile
cumulative amount and quantity for these performance obligations are adjusted according to the invoiced
quantity and processed amount.
Future Cancellation
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 83
If you specify a current or past finalization date, the cancellation is processed immediately. However if you specify
a future finalization date, you need to run program FARR_POB_CANCELLATION when the date comes. Therefore
we suggest you to run this program regularly if you have specified a future finalization date.
Cancellation of Time-based Performance Obligation
For a time-based performance obligation,
● if the finalization date is in the past and the date is earlier than the start date, then its end date will be changed
to the start date; if the date is later than the start date, then the finalization date will be set as the end date.
● if the finalization date is in the future and the finalization date is earlier than the end date, its end date is set to
the finalization date. At same time, deferral method of the time-based performance obligation will be set to
method 1 Linear Distribution, Day-Specific, 365/366 Basis whatever it originally was.
Cancellation of Linked Performance Obligations
When a leading performance obligation is cancelled, its linked performance obligation will also be cancelled.
Cancellation of Performance Obligation in Pending Review Worklists
Performance obligations whose statuses are Pending Review go to pending review worklists, either worklist for
regular monitoring, worklist for contracts with errors, or worklist for contracts with conflicts. When these
performance obligations are cancelled, the cancellation is not performed immediately. Even when they have been
removed from pending review worklists, the system does not automatically perform the cancellation. You need to
run program FARR_POB_CANCELLATION manually.
Change Finalization Date
You can set or change finalization date with method ORDER_DATA_TO_ARL of BAdI FARRIC_BADI_ORDER.
Reverse Cancellation
You can recover contracts that were cancelled in the past. After you reverse cancellation in operational system,
Revenue Accounting and Reporting removes the finalization date and changes the status of performance
obligations back in process. Cumulative amount and quantity is also adjusted accordingly.
5.1.6 Negative Performance Obligations
A negative performance obligation is a performance obligation with a negative transaction price. The negative
performance obligation is transferred from the sender components, either as a credit memo or a return order.
According to IFRS 15, a negative performance obligation will not be accounted for as a performance obligation in
the financial statement. It is only applied in Revenue Accounting when you want to include a negative item to
reduce the contractual price.
Note
Once a performance obligation has been flagged as a negative performance obligation, it can only be negative
even if you change it to zero or positive in sender components afterwards.
84
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Feature
Price Allocation
As with normal performance obligations, you can choose to perform price allocation for negative performance
obligations. For more information, please refer to Price Allocation [page 132].
Note
The standalone selling price (SSP) of a negative performance obligation can only be non-negative.
Example
Assume that there are two performance obligations as follows:
Table 45:
Performance Obliga
tion
Transaction Price Negative Performance
Obligation
Exclude from Al
location
SSP Allocated Price
1 EUR 10 No EUR 50
EUR -45d
2 EUR -100 Yes No EUR 50 EUR -45
After price allocation, the allocated price for performance obligation 1 is EUR -45. The allocation price for
performance obligation 2 is EUR -45.
Fulfillment
You can set a negative performance obligation to any fulfillment type and event type in Revenue Accounting.
Invoice Processing
A negative performance obligation must also have a negative invoiced amount.
Contract Liability and Contract Asset (Unbilled Receivable and Deferred Revenue)
Revenue accounting calculates contract liability and contract asset (unbilled receivable and deferred revenue) as
normal performance. For the calculation, please refer to Calculation of Contract Liability and Contract Asset [page
195].
Example
Contract Liability and Contract Asset
Assume that a negative performance obligation has a transaction price of EUR -100. If it is fully recognized
while no invoice amount is due, the contract liability is calculated as follows:
Contract liability= max ((invoice due amount – recognized revenue), 0) = 100
If it is fully recognized with the allocated price of EUR 0, and the invoice amount due is EUR -50, the contract
asset is calculated as follows:
Billable Amount = Recognized Revenue/Allocated Price * Transaction Price= 0
Receivable Amount=Invoice Due Amount = -50
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 85
Contract Asset = max (Recognized Revenue - Receivable Amount) = 50
Unbilled Receivable and Deferred Revenue
Assume that a negative performance obligation has a transaction price of EUR -100.
If it is fully invoiced but unrecognized, the unbilled receivable is calculated as follows:
Unbilled Receivable= max ((Recognized Revenue - Invoiced Amount), 0) = 100
If it is fully recognized but unbilled, the deferred revenue is calculated as follows:
Deferred Revenue= max ((Invoiced Amount - Recognized Revenue), 0) = 100
5.2 Revenue Accounting Contracts
A revenue accounting contract is an object that consists of performance obligations that belong together.
Use
A revenue accounting contract represents the financial view of an operational document, such as a sales order. A
revenue accounting contract serves as a container for performance obligations. It typically represents an
operational document that originates on the back-end operational system, such as a sales order created on a
Sales and Distribution system. However, it can also represent an aggregate of multiple operational documents in
certain business scenarios.
5.2.1 Creating a Contract
Revenue Accounting creates a revenue accounting contract based on the operational document from the
operational system.
When an operational document is created in the back-end operational system, the back-end system can request
to create revenue accounting contracts.
5.2.2 Changes to Contracts
Use
Revenue accounting contracts and performance obligations can be changed after they have been created.
Changes can be triggered following certain changes made to the operational documents. Additionally, users can
also manually edit contracts and performance obligations.
86
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Features
The system allows two types of changes to be made to contracts
● Manual changes made by the accountant
The system allows you to perform manual tasks to change revenue accounting contracts after they have been
created with default configurations.
● Automatic changes requested by the back-end operational system
After creating a contract and its performance obligations, the back-end operational system can request more
changes. For example, after renegotiating certain terms of the contract with the customer, a sales
representative may change the price of the sales order. In this case, the back-end operational system can
request a change to the revenue accounting contract, and the transaction price is reallocated.
● Deletion of performance obligations
You can delete performance obligations. When you delete a performance obligation, depending on individual
cases, the system may process the deletion as a “hard delete”, where the object is removed directly, or as a
“soft delete”, where the object is only marked as deleted. For more information, see Deletion of Performance
Obligations [page 80].
5.2.2.1 Making Manual Changes
You can manually edit revenue accounting contracts and performance obligations after they have been created
automatically at the request of the back-end operational system.
Activities
The manual changes supported address the following typical scenarios:
● Edit performance obligation attributes
You can edit certain performance obligation attributes.
● Add linked performance obligations
You can manually add linked performance obligations for items that are committed but are not included in the
operational document.
● Add manual performance obligations
You can add manual performance obligations for items that are committed but are not included in the
operational document. Manual performance obligations do not point to other performance obligations as the
leading performance obligation.
● Change price allocation
You can change the default price allocation applied by the system.
● Reorganize performance obligations in the contract
○ Split a compound performance obligation
You can split a compound performance obligation into several distinct performance obligations. When
you perform this operation, the existing non-distinct performance obligations are converted into distinct
performance obligations, and the existing compound performance obligation is removed.
○ Merge distinct performance obligations
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 87
You can also merge multiple distinct performance obligations into a compound performance obligation.
When you perform this operation, the existing distinct performance obligations are converted into non-
distinct performance obligations, and a compound performance obligation is created.
● Change the spreading for time-based performance obligations
You can change the default spreading applied by the system.
● Add rights of return
You can manually add rights of return.
● Edit the description of the contract
You can edit the description of the contract.
● Move performance obligations across contracts
You can move performance obligations across contracts. The system allows you to restructure the
performance obligations using cut and paste operations.
● Move performance obligations within the contract
You can move performance obligations within the same contract. The system allows you to restructure the
performance obligations using cut and paste operations.
● Combine contracts
You can combine multiple contracts into one contract. The system allows you to restructure the performance
obligations using cut and paste operations.
● Delete performance obligations
You can delete performance obligations. When you delete a performance obligation, depending on individual
cases, the system may process the deletion as a “hard delete”, whereby the object is removed directly, or as a
“soft delete”, whereby the object is only marked as deleted. For more information, see Deletion of
Performance Obligations [page 80].
5.2.2.1.1 Changing Price Allocation
You can manually change price allocation.
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Contract Management Contract Search .
3. Use the search function to find the contract for which you want to perform manual price allocation.
4. Select and open the contract and choose Price Allocation Change Allocated Amount .
5. The Allocated Amount field displays the amount of the transaction price that is currently allocated to each
performance obligation. In the
New Allocated Amount field or the Difference field, you can change the value
allocated to the performance obligation. If you update one field, the other field is updated automatically.
○ In the New Allocated Amount field, you can specify the amount that you want to allocate to the
performance obligation.
○ In the Difference field, you can specify the differential amount that you want to add to or deduct from the
current amount.
6. After you have changed the allocated transaction price, choose Check Allocated Amount or press enter to
check the allocated amounts.
○ If the values in the Transaction Price and Total Allocated Amount fields are equal, the Amount Not
Allocated entry is marked with a green traffic light. In this case, you have allocated the entire transaction
price to the performance obligations in the contract.
88
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
○ If the values in the Transaction Price and Total Allocated Amount fields are not equal, the Amount Not
Allocated entry is marked with a red traffic light. In this case, either you have not allocated the entire
transaction price to the performance obligations, or the total amount that you have allocated to the
performance obligations exceeds the total transaction price.
7. Choose Save.
5.2.2.1.2 Converting a BOM Structure to a Compound
Structure
You can convert a BOM-structured performance obligation into a compound performance obligation.
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Contract Management Contract Search .
3. Use the search function to find the contract for which you want to merge distinct performance obligations.
4. Select and open the contract, and switch to the hierarchical view. The performance obligations that you want
to merge must be part of a bill of material (BOM) structure.
5. Choose any performance obligation of the BOM structure, and then choose Distinct <-> Non-Distinct. After
you apply this change, the higher-level performance obligation in the BOM structure is converted into a
compound performance obligation that represents an aggregate of multiple non-distinct items. All lower-level
performance obligations under the higher-level performance obligation are converted into non-distinct
performance obligations.
6. Choose Save.
5.2.2.1.3 Changing the Spreading for Time-Based
Performance Obligations
You can change the spreading for time-based performance obligations.
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Contract Management Contract Search .
3. Use the search function to find the contract that includes the performance obligation for which you want to
manually change the spreading.
4. Select and open the contract.
5. Select the time-based performance obligation and choose Revenue Schedule.
6. Select the performance obligation and choose Change Spreading.
7. The Initial Revenue field displays the revenue amount that is currently distributed to each accounting period.
In the New Revenue field, you can change the value distributed to a specific accounting period.
8. After you have changed the revenue distributed, choose Check Spreading or press enter to check the
spreading.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 89
○ If the values in the Total Revenue to Be Distributed and Total Revenue Distributed fields are equal, the
Remaining entry is marked with a green traffic light. In this case, you have distributed the entire revenue
amount to the accounting periods.
○ If the values in the Total Revenue to Be Distributed and Total Revenue Distributed fields are not equal, the
Remaining entry is marked with a red traffic light. In this case, either you have not distributed the entire
revenue amount to the accounting periods, or the total amount that you have distributed to the
accounting periods exceeds the total revenue.
9. Choose Save.
5.2.2.1.4 Move Performance Obligations
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Contract Management Contract Search .
3. Use the search function to find the contracts among which you want to move performance obligations.
4. Select the contracts and choose Perform Contract Combination.
5. In the Work Area, select the performance obligations or operational documents that you want to move, and
then choose Cut. The cut operation marks the selected items so that they can be moved when you perform a
paste operation. If the selection is on an operational document, all the performance obligations that are
associated with this operational document are selected.
6. Select the contract to which you want to move the performance obligations that were selected in the previous
cut operation, and choose Paste.
7. Choose Simulate to preview the new contract-level allocation effect that would occur if you save the change.
8. You can use the Search area to search for more contracts and add them to the Work Area and move
performance obligations among them.
9. Choose Save.
5.2.2.2 Resolving Conflicts
You can review contract conflicts on the Contracts with Conflicts user interface (UI).
Use
You can manually change certain fields of performance obligations after they have been created automatically.
However, the back-end operational system may still request more changes to the performance obligations after
the manual change. For example, this may occur when a change is made to the corresponding sales order. If you
and the back-end system have changed the same attribute, a conflict occurs. In this case, the system puts the
contract with conflicting changes on the Contracts with Conflicts user interface. You can review the list and
resolve the conflicts.
90
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
The worklist displays conflicting changes in the following areas:
● Changes Made to Attributes
The system lists the attributes that have conflicting changes. For each attribute, you can decide which version
of the change is kept.
● Changes Made to Price Allocation
If you have manually changed the price allocation and then the system has changed something relating to the
price, you have to reapply your manual price allocation. This area tracks only changes made directly to the
price allocation. Changes that have been made to other attributes and that may affect price allocation are
always considered attribute changes instead of price allocation changes.
● Added or Removed Performance Obligations
Items listed in this area do not require that you make any changes. Instead, the system only lists all added and
removed performance obligations for your information.
● Revenue Schedule
This area lists all the performance obligations in the contract, with a comparison of the old and new
transaction prices. Additionally, it allows you to navigate to the revenue schedule user interface.
5.2.2.2.1 Resolving Conflicts for Attribute Changes
You can resolve conflicts for attribute changes on the Contracts with Conflicts user interface (UI).
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Pending Review Worklists Contracts with Conflicts .
3. The default query lists all contracts that involve conflicts. You can create your own query to apply additional
filtering.
4. Select and open a contract.
5. Choose Edit to switch to the edit mode.
6. On the Attributes Conflicts tab, the list shows all conflicts in the selected contract. For each item, you can use
the Use Value From field to specify which version of the change is kept.
○ Current Value: the new value applied by the back-end system
○ Last Manually Changed Value: the value that you have manually applied
The following key fields describe the change conflict:
○ Field Name: the field on which the conflict occurs
○ Current Value: the new value applied by the back-end system
○ Last Manually Changed Value: the value that you have manually applied
7. To apply the same change to multiple items, select the items, choose Mass Update, and then choose an
option for all selected items.
8. Save the changes.
○ To save the changes, choose Save.
○ To save the changes and allow the system to accept all future changes that come from the back-end
system for this contract, choose Save and Always Update Contract Automatically. If you choose this save
option, the system automatically accepts all future changes that come from the back-end system until
you make another manual change on this contract.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 91
5.2.2.2.2 Resolving Conflicts for Price Allocation Changes
You can resolve conflicts for price allocation changes on the Contracts with Conflicts user interface (UI).
Proceed as follows:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Pending Review Worklists Contracts with Conflicts .
3. The default query lists all contracts that involve conflicts. You can create your own query to apply additional
filtering.
4. Select and open a contract.
5. Choose Edit to switch to the edit mode.
6. On the Price Allocation Conflicts tab, the list shows price-related changes that occur after your manual price
allocation. For each item, you can perform manual allocation again according to the new price.
The following key fields describe the price allocation status of each performance obligation:
○ Old Contractual Price: the contractual price at the time when you made your previous manual allocation;
for more information, see Contractual Price [page 132].
○ Old Allocated Amount: the amount that you have allocated to this performance obligation in your previous
manual allocation
○ Old Allocation Effect: the allocation effect calculated according to your previous manual allocation; for
more information, see Price Allocation [page 132].
○ Contractual Price: the latest contractual price
○ Allocated Amount: the default price allocation applied by the system
○ Allocation Effect: the allocation effect calculated according to the default price allocation
You can specify the new price allocation in the following fields:
○ New Allocated Amount: Use this field to enter the amount of transaction price that you want to allocate to
this performance obligation.
○ Difference: The entry in this field is used to calculate the differential that your allocation represents.
Note
When you enter a value in either of these fields, the other field is automatically updated. If values are
entered in both fields, the value in the New Allocated Amount field is used.
7. Save the changes.
○ To save the changes, choose Save.
○ To save the changes and allow the system to accept all future changes that come from the back-end
system for this contract, choose Save and Always Update Contract Automatically. If you choose this save
option, the system automatically accepts all future changes that come from the back-end system until
you make another manual price allocation on this contract.
92
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
5.2.2.3 Change History
Use
The system tracks changes that occur on certain fields of revenue accounting contracts and performance
obligations.
Features
● Grouping
The system groups changes into transactions. In the list of transactions, each item represents a transaction
that is saved to the corresponding database table. For example, if you change several attributes of a
performance obligation and save the changes, these changes are considered one transaction.
● Filtering
You can filter changes using the following categories.
○ Manual Changes
Changes that you make to attributes on contracts or performance obligations
○ Price Allocation
Manual price allocations that you apply to the contract
○ Operation Changes
Changes that are requested by the back-end operational system
○ Invoice Changes
Changes that are triggered by incoming invoices
● Price Allocation Changes
In a separate area, the system indicates how other changes affect the price allocation of the contract. The
information listed in this area is relevant to the transaction that you have selected.
● Revenue Schedule Changes
In a separate area, the system indicates how other changes affect the revenue schedule and spreading of the
contract. The information listed in this area is relevant to the transaction that you have selected. The revenue
and cost for each relevant accounting period are displayed, with a comparison of the old and new values.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 93
5.2.2.4 Subsequent Changes
The Revenue Accounting system applies some automatic changes following changes made to revenue accounting
contracts.
Features
After you have made manual changes to revenue accounting contracts, Revenue Accounting processes the
following automatic changes:
● Price reallocation
The system triggers a price reallocation if the changes affect price allocation. For example, if you change the
standalone selling price of a performance obligation (POB), the system performs price allocation again for the
contract according to the new standalone selling price (SSP).
● Revenue schedule changes
If fulfillments have already occurred on the contract that has been updated and if the fulfillments have not
been posted, the system automatically updates the revenue schedule to accommodate the changes.
● Retrospective adjustments
If fulfillments have already occurred on the contract that has been updated and if the fulfillments have already
been posted, the system automatically performs retrospective adjustments. The actual adjustment postings
are created when you run a revenue posting job.
5.2.3 Combination of Revenue Accounting Contracts
Use
Revenue Accounting and Reporting enables you to combine multiple contracts with the same accounting principle
and company code. You can combine contracts by taking the following step:
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
2. Choose Contract Management Contract Search .
3. Select two contracts you want to combine, then choose Perform Contract Combination or Quick Combine.
4. If you choose Performance Contract Combination, you can combine contracts by moving performance
obligations to a target contract or reassign performance obligations to another contract.
5. If you choose Quick Combine, you need to specify a contract change type and an effective date. You can also
perform quick combination through Pending Review Worklists Regular Monitoring Quick Combine .
Note
The following contracts cannot be combined:
● Contract of which validation result is error or conflict
● Contract of which contract status is pending review
94
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Features
Contracts with different customers
The system allows contracts with different customers to be combined by default. If you want to disable the
functionality, you need to set messages in the following Customizing activity:
Choose Revenue Accounting Revenue Accounting Contracts Change Message Control
Determination of Source and Target Contracts
You can decide which contract is source contract and which one is target contract. When choosing several
contracts to be combined manually, the first one is target contract by default. But if you choose Select All, you
need specify whether use the first contract in the selected contracts or create a new contract as the target
contract.
Handling Revenue Posting of Source Contract
Before source contracts and target contracts are combined, posted revenue of source contracts, including that
has already been transferred to FI and still in posting table, will be reversed and then posted to target contracts.
Afterwards source contracts will be marked as Soft Delete. Invoice and fulfillment that are assigned to source
contracts originally will be reassigned to target contracts. Note: You can view historical values of source contracts
and target contracts by a report. Additionally you can see balance of source contracts and target contracts before
and after contract combination on UI.
Contract Change
Contract combination can be regarded as a kind of contract change: target contracts are changed and source
contracts are softly deleted. Therefore when performing contract change, you need to specify a contract change
type, either Change of Estimates or Contract Modification.
Price Reallocation
When revenue contracts are combined, contract price of target contracts will be reallocated in appropriation to
new standalone selling prices of each performance obligation. For the calculation of new standalone selling prices,
refer to Contract Change [page 143].
Reversal of Source Contracts
In combination of contracts, source contracts will be reversed. Reversed posting of source contracts include
revenue, invoice correction, contract asset and contract liability of last period , and loss and gain resulted from
exchange rate difference.
Note
Postings for future periods will also be reversed.
Determination of Adjustment Period
Adjustment period is a period when adjustment posting and retrospective posting is made.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 95
Table 46:
Contract Change Type Adjustment Period
Change of estimates Latest open period when both target contracts and source
contracts exist
Retrospective change of contract modification
Prospective change of contract modification Each unfulfilled period
Note
Catch-ups will be added to each unfulfilled period.
5.2.3.1 Contract Change after Contract Combination
When contracts are combined, contracts are to be changed. Performance obligations of source contracts will be
moved to target contracts . If source contracts and targets are all unfulfilled, contract combination is mere
addition of performance obligations. But in most cases, source and target contracts are partially fulfilled. Then
you need to specify a change type for the contract combination, either change of estimate or contract
modification.
Change of Estimates After Contract Combination
If you choose change of estimates, the change is applied to the earliest open period when both source contract
and target contract both exist. As for the calculation, refer to Change of Estimates [page 146].
Contract Modification After Contract Combination
If you choose contract modification, you also need to specify an effective date. As for the calculation, refer to
Contract Modification [page 148].
96
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
5.2.4 Searching for and Displaying a Contract
You can use the search function to start most of the management tasks concerning revenue accounting contracts
and performance obligations.
Features
Search Criteria
You can search for revenue accounting contracts using attributes on contracts and performance obligations. The
search function addresses the following typical scenarios:
● Searching for contracts that have specific attributes
For example, you can search for revenue accounting contracts of a certain company code that were created
later than a specific date.
● Searching for contracts that are associated with specific operational documents
For example, you can search for revenue accounting contracts associated with a certain sales order.
● Searching for contracts that contain specific performance obligations
For example, you can search for revenue accounting contracts that contain performance obligations with a
certain performance obligation name.
Result Views
You can display search results using the following views:
● General view
This view is a plain list of revenue accounting contracts.
● Grouping by contract and then operational document
This view is a two-level hierarchical list. The first level lists groupings by contract. The second level lists
operational documents associated with each contract. This view also allows you to jump to the corresponding
operational document.
● Grouping by operational document and then contract
This view is a two-level hierarchical list. The first level lists groupings by operational document. The second
level lists contracts associated with each operational document.
Management Views
When you open a revenue accounting contract to view its details, the system provides the most important
information about the current contract and the performance obligations contained in the contract. In addition, the
system provides several perspectives with which you can manage the performance obligations in the contract:
● Performance Obligation Structure
In this perspective, you typically perform tasks that involve managing the structure of performance
obligations and their relationships with one another.
● Price Allocation
In this perspective, you typically perform tasks that involve managing price allocation. You can view and
rearrange the price allocation of the contract.
● Revenue Schedule
In this perspective, you typically perform tasks that involve managing the fulfillment of performance
obligations. You can view and manage the fulfillment progress of the performance obligations. By default,
fulfillment data is listed by accounting period. You can view the fulfillment details of each accounting period.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 97
● Comprehensive View
This perspective is integrated with many functions that are available in other perspectives. This typically
allows you to perform different types of task from a single user interface.
Performance Obligation List
When a list of performance obligations is displayed on a user interface, you have several options for organizing the
performance obligations:
● Standard view
This view is a plain list of the performance obligations contained in the contract.
● Hierarchical view: grouping by operational document and then performance obligation type
This view is a three-level hierarchical list of the performance obligations contained in the contract. The first
level is a grouping by operational document. The second level is a grouping by performance obligation type.
The third level lists all performance obligations in a specific grouping.
● Hierarchical view: grouping by performance obligation type and then operational document
This view is a three-level hierarchical list of the performance obligations contained in the contract. The first
level is a grouping by performance obligation type. The second level is a grouping by operational document.
The third level lists all performance obligations in a specific grouping.
Activities
You can perform the following tasks:
● Search for contracts
● Display contracts in different views
● Display performance obligations in different views
● Display details of a specific contract
● Display details of a specific performance obligation
● Edit contracts
● Edit performance obligations
● Navigate to other editing options
As an entry point, the search function allows you to navigate to other options for performing specific tasks. For
more information, see the following topics:
● Manual Changes [page 87]
● Manual Performance Obligations [page 79]
5.2.5 Revenue Schedule
Revenue Schedule UI are mainly consist of the following sections:
● Revenue Schedule Summary [page 99]
● Revenue Schedule Details [page 99]
● Fulfillment Details [page 101]
● Fulfillment Details for Non-distinct Performance Obligations [page 101]
98
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
5.2.5.1 Revenue Schedule Summary
With this section, you can have a big picture of revenue schedule and fulfillment progress with the following
information:
● Recognized and posted revenue (cost)
You can see how much revenue (cost) has been transferred to accounting sub-ledger and how much revenue
has been posted to FI.
● Planned and unscheduled revenue (cost)
You can see how much revenue has been scheduled for future fulfillment and how much has not been
scheduled for future fulfillment.
● Total Revenue (cost)
You can see total revenue (cost) to be fulfilled in Revenue Accounting, including recognized revenue (cost),
planned revenue (cost), and unscheduled revenue (cost).
● Fulfilled progress
You can see the percentage of fulfilled revenue (cost).
5.2.5.2 Revenue Schedule Details
With this section, you can see how revenue is scheduled with the following information:
● Revenue
With field Revenue, you may see different revenue, such as recognized revenue, planned revenue, or
unscheduled revenue according to its status.
Table 47:
Light Color Status Revenue
No light Only have a billing plan The revenue comes from billing plan in
voice.
Orange Recognized and completely posted on
the legacy system
The revenue has been recognized and
posted in legacy system. It is transfer
red from initial load.
Gray Recognized but not completely posted The revenue has been recognized, but
has not been completely posted yet.
Yellow To be recognized in the future The revenue has not been recognized.
Red Recognized but posting failed The revenue has been recognized, but
its posting has failed.
Green Recognized and completely posted All revenue of the period are recog
nized and posted successfully.
● Price
You can see different prices in this section, such as allocated amount, posting price, and unit price.
Allocated amount is the amount of performance obligation after price allocation.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 99
Posting price is the revenue that has been transferred to accounting sub-ledger.
Unit price is the price per unit. It is calculated as follows:
Unit price=Effective remaining amount/Effective remaining quantity
● Quantity
You can see effective quantity and quantity for a specific period in field Effective Quantity and Quantity
respectively.
Effective quantity is the total quantity that is fulfilled in Revenue Accounting. The effective quantity may not
be equal to quantity from operational document. If invoiced quantity is greater than the order quantity,
Revenue Accounting updates the effective quantity with the invoiced quantity.
● Fulfillment progress
You can see fulfillment progress with the field Fulfillment Progress (By Quantity) and Cumulative Fulfillment
Progress (By Quantity).
Fulfillment progress indicates how significantly the quantity has been fulfilled for a specific period. It is
calculated as follows:
Fulfillment progress=Quantity/Effective quantity
Cumulative fulfillment progress indicates how significantly the quantity has been fulfilled up to the current
period. It is calculated as follows:
Cumulative fulfillment progress=Cumulative quantity/Effective quantity
● Revenue catch-up
You can see how much revenue has been fulfilled in the current period with the field Revenue Catch-up. It is
calculated as follows:
Revenue catch-up = Allocated price/ Total quantity * Cumulative fulfilled quantity up to the end of the last
period – Cumulative recognized revenue up to the end of the last period
● Effective remaining quantity and amount
You can see the remaining quantity and amount to be recognized after a contract modification with the fields
Effective Remaining Quantity and Effective Remaining Amount.
Effective remaining quantity is the remaining quantity after performing a contract modification. It is
calculated as follows:
Effective remaining quantity=Effective quantity-Cumulative fulfilled quantity
Effective remaining amount is the remaining amount after performing a contract modification. It is calculated
as follows:
Effective remaining amount = Contractual price – Cumulative recognized revenue up to the end of the last
period that contract modification occurred
● Planned invoice
You can forecast future invoices with the field Planned Invoice. The amount of planned invoice is the amount
that is planned to be invoiced for the period according to the billing plan. The amount comes from planned
invoice revenue accounting items with the status Processable or Processed.
When the billing plan is just a reference and real invoice will come in the future, the amount of the planned
invoice comes from processable or processed revenue accounting Items.
When the billing plan will automatically become real invoice, the amount of the planned invoice comes from
processable revenue accounting item. Then when the billing date comes, the processable revenue accounting
items will be processed and set to status Processed.
● Fulfillment and event Type
You can see the revenue’s fulfillment and event types in the field Fulfillment Type and Event Type. If you have
changed the fulfillment and event type in a period after the revenue is posted, the two fields display Multiple; if
you have changed the fulfillment and event type in a period before the revenue is posted, the two fields only
display the latest fulfillment and event type.
● Contract modification
100
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
You can see whether a revenue entry has been applied contract modification. When you apply prospective
change, which is one kind of contract modification, the checkbox Had Contract Modification is selected. For
more information about contract modification, please refer to Contract Modification [page 148].
● Shift Revenue
You can see how the revenue has been shifted. With the field Shift Revenue, you can see the revenue is shifted
in the following ways:
○ The revenue is shifted to another period.
○ The revenue is shifted from another period.
○ Some revenue is shifted to another period and some is shifted from another period.
5.2.5.3 Fulfillment Details
With this section, you can see the revenue schedule based fulfillment events:
● Fulfillment date
You can see the date when revenue is fulfilled.
● Shifted revenue
If there is revenue shifted from one period to another, you can see to or from which period it is shifted with the
field Shift from/to.
● Deferral category
With the field Deferral Category, you can see whether the event is for a right of return.
5.2.5.4 Fulfillment Details for Non-distinct Performance
Obligations
With this section, you can see the revenue schedule of non-distinct performance obligation based on fulfillment
events:
● Quantity
You can see how many non-distinct performance obligations have been fulfilled.
● Actual fulfilled quantity
You can see how many non-distinct performance obligations have actually fulfilled. For more information, you
can refer to Compound Structure Fulfillment [page 173].
● Actual delivered percentage
You can see the percentage of delivered quantity. It is calculated as follows:
Actual delivered percentage=Actual fulfilled Quantity / Effective quantity
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 101
5.2.6 Pending Review Worklists
Use
When a contract is created or modified, validation is performed to verify that attributes of the contract and its
performance obligations are correct. If any errors or conflicts occur with this process, Revenue Accounting and
Reporting provides the following worklists to review:
● Worklist for regular monitoring
● Worklist for contracts with errors
● Work list for contract with conflicts
Features
● Worklist for regular monitoring
The worklist allows you to review revenue accounting contracts and performance obligations that are newly
created or modified and require review from revenue accountants.
● Worklist for contracts with errors
The worklist allows you to identify errors and make corrections.
● Worklist for contracts with conflicts
The worklist allows you to review and resolve conflicts.
● Customizable messages and severity levels
Some of the messages reported by Revenue Accounting and Reporting can be customized. Each message
indicates an exception scenario, not necessarily an error, that occurs during revenue accounting transactions.
You can configure whether this message is ignored, handled as a warning, or handled as an error.
● Reprocessing contracts
After you have corrected error and resolved conflicts, you can chose Reprocess Contract to get the latest-
derived attributes. By doing this, you can correct erroneous contracts by correcting rules in BRFplus.
5.2.6.1 Worklist for Regular Monitoring
Use
The accountant may be particularly interested in certain contracts after they have been created or updated.
Therefore, you may want to save these contracts in a review worklist so they can be monitored regularly.
Examples
● You want to review all newly created performance obligations.
● You want to review performance obligations that have been manually changed.
● You want to review performance obligations that have large amounts (greater than a threshold amount).
● You want to review time-based performance obligations that do not have a start date specified.
● You want to review all changes made to prices and quantities.
102
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
● You want to monitor certain performance obligations regularly.
Note
The regular monitoring worklist tracks both the contract status and the performance obligation status. If any of
the performance obligations have the status Pending Review, the status of the contract is set to Pending
Review.
Review Reasons
Each scenario that requires review can be associated with a review reason. The review reason identifies why this
performance obligation is sent to the worklist for review. The review reason also determines whether revenue
postings must be suspended for this performance obligation until it has been reviewed and confirmed.
Prerequisites
This feature requires that the referenced review reasons are defined in the following Customizing activity:
Financial Accounting Revenue Accounting Revenue Accounting Contracts Define Review Reasons
Activities
The regular monitoring worklist allows you to perform the following maintenance tasks:
● Define queries that help you locate contracts
● Mark contracts as reviewed
● Open contracts for editing
● Add contracts or performance obligations to the worklist
5.2.6.2 Worklist for Contracts with Errors
Use
If errors occur during the creation of a contract and its performance obligations, the contract is saved in this
worklist for review. For example, if the operational system provides some invalid attribute values when creating a
contract, the contract is saved in the error worklist. In this case, the accountant can identify the errors in the
worklist and correct the invalid attributes so that the contract can continue to be processed towards its
fulfillment.
Note
There are some errors that cannot be fixed neither by correcting revenue accounting contracts nor rules in
BRFplus. These corresponding revenue accounting items will be rejected by Revenue Accounting and
Reporting.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 103
Performance obligations with errors are blocked from posting. To correct these errors, an end user can take the
following measures:
● Change revenue contracts or performance obligations manual in Revenue Accounting and Reporting.
● Reprocess these revenue contracts to update BRFplus setting.
● Change operational documents and make the information of revenue accounting items right.
Note
However, invoice and cost correction posting of erroneous performance obligation are not blocked.
There are some errors that cannot be fixed neither by correcting revenue accounting contracts nor rules in
BRFplus, such as technical errors, condition type errors, and currency errors. Their corresponding revenue
accounting items will be rejected by Revenue Accounting and Reporting. These error shall not enter into worklist
for contract with errors and can be viewed in revenue accounting item monitor. To correct these errors, an end
user need to change operational documents or BRFplus and then reprocess revenue accounting items again.
Activities
The worklist for contract with errors allows you to perform the following maintenance tasks:
● Review contracts and performance obligations that have errors
● Manually correct certain attributes
5.2.6.3 Worklist for Contracts with Conflicts
Use
Contracts will be put into this worklist in the following scenarios:
● A contract receives changes from different sources and these changes conflict with each other. For example,
a revenue accountant changes standalone selling price (SSP) of a performance obligation in Revenue
Accounting and Reporting; later the SSP is changed to another value in operational documents.
● A contract's price allocation has been manually changed and then its price is changed by operational
documents.
● A performance obligation's revenue spreading is changed manually.
Prerequisites
● When conflicts occur to some attributes, you can configure which changes to accept in the following
Customizing activity:
Choose Financial Accounting Revenue Accounting Contracts Define Default Value for Update Mode of
POB Attributes .
104
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
● For each performance obligation, you can specify update mode on Details page. The update mode defines
how attributes of a performance obligation is updated, either from operational documents or manual change
on UI.
Activities
The worklist for contracts with conflicts allows you to perform the following maintenance tasks:
● Review contracts with conflicts
● Manually resolve conflicts
5.2.6.4 Suspending Revenue Posting
Use
A performance obligation can be marked as Suspend Revenue Posting so that all revenue-related postings for this
performance obligation are suspended until it is unmarked. For example, you can suspend revenue postings for
performance obligations that are pending review. When you run a revenue posting job, the system skips postings
relating to performance obligations that have this attribute enabled.
While revenue postings are suspended, the system can still receive fulfillment events from the operational system
as usual, except that the corresponding postings are not made to the general ledger. When the performance
obligation is reopened for revenue postings, fulfillments pending posting are then posted to the original
accounting period in which the fulfillments occurred if that period is still open. If the original period is not open, the
system selects the earliest period thereafter that is open.
When a performance obligation is created, this attribute is initially determined as follows:
● If the newly created performance obligation contains errors and does not pass the validation (with the
validation result set to Error), it is automatically marked as Suspend Revenue Posting.
● If the newly created performance obligation contains no errors (with the validation result set to Warning or
Success) but is pending review, this attribute is set to the default value associated with the review reason. For
more information, see Regular Monitoring [page 102].
Example
On January 5 (in the first accounting period of the year), when a performance obligation is created, it is sent to the
review worklist to be manually reviewed and confirmed because it involves a large amount. The performance
obligation is marked as Suspend Revenue Posting, which is the default setting associated with the review reason.
While revenue postings are suspended, the performance obligation is eventually delivered to the customer and
the fulfillment event is passed to the Revenue Accounting system.
For various reasons, the accountant does not have a chance to review the contract by the end of that period. On
February 10, the accountant reviews the contract and marks it as reviewed so that it is reopened for revenue
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 105
postings. At this time, the previous accounting period is already closed. When the accountant runs a revenue
posting job at the end of the period, the postings for the performance obligation are posted to the second
accounting period of the year.
5.3 Operational Documents
Revenue accounting contracts are derived from operational documents in the back-end system. An operational
document represents a contract that an enterprise has with a customer. For example, when a sales representative
creates a sales order on a Sales and Distribution system, the revenue accounting contract that is created for this
transaction refers to the sales order as the operational document.
5.4 Rights of Return
Use
If your company expects to refund some or all of the amount of a sales item to a customer, you may have to
specify an estimated percentage of the total amount and post it as a refund liability.
Performance Obligations Applicable for Rights of Return
Rights of return can be applied at performance obligation level. Additionally, the following restrictions apply:
● Linked performance obligations are not allowed to have rights of return. A linked performance obligation is
not an independent performance obligation. Therefore, the return of a leading performance obligation always
results in the return of its linked performance obligations. The customer cannot cancel linked performance
obligations without canceling the leading performance obligation.
● Time-based performance obligations and percentage-of-completion performance obligations are not allowed
to have rights of return.
● Non-distinct performance obligations are not allowed to have rights of return.
● One performance obligation can have up to one right of return.
Example
The following are some example scenarios of rights of return applied to performance obligations:
Table 48:
Performance obligation Composition Fulfillment Type Right of Return %
1 Leading Event-Based 5%
1a Linked Time-Based Not allowed
2 Compound Event-Based 10%
106 P U B L IC
SAP Revenue Accounting and Reporting
Contract Management
Performance obligation Composition Fulfillment Type Right of Return %
2.1 Non-Distinct Event-Based Not allowed
2.2 Non-Distinct Event-Based Not allowed
3 Distinct Event-Based Not specified
4 Distinct Time-Based Not allowed
5 Distinct Event-Based Not specified
5.1 Distinct Event-Based 6%
5.2 Distinct Event-Based 7%
Duration of the Right of Return
A right of return lasts for a specified period of time, which can be specified with combinations of the start date, the
end date, and the duration time. Typically, the system supports the following two scenarios:
● A fixed time period, with a start date and an end date
This can be specified with a valid combination of start date, end date, and duration. For example, it can be
specified with a start date and a duration.
● Only a duration but no start date or end date
This represents a right of return that lasts for a fixed length of time but has a variable start date. When part of
the performance obligation is delivered, the right of return of the delivered part starts. If the performance
obligation is delivered in several installments, the one right of return is actually split into multiple de facto
rights of return, each starting from its own delivery date and lasting for the specified length of time.
Amounts of Rights of Return
The following amounts are relevant to rights of return:
● Revenue Adjustment for Right of Return: right of return percentage * total recognized price
This amount is also the amount that is recognized as revenue when the right of return expires.
For a leading performance obligation, the total recognized price also includes the recognized price of its linked
performance obligations.
For performance obligations that have a sales bill-of-material structure, the right of return percentage applied on
the higher-level performance obligation is automatically brought down to its lower-level performance obligations.
If the lower-level performance obligations have their own percentages of right of return, the rights of return are
calculated with those percentages respectively. The system tracks the revenue adjustment for rights of return at
the lower level.
For a compound performance obligation that represents multiple non-distinct performance obligations, the right
of return percentage is always applied on the compound performance obligation. This percentage is automatically
distributed across its non-distinct performance obligations. The system tracks the revenue adjustment for rights
of return at the non-distinct performance obligation level.
Changes Resulting from Contract Modifications
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 107
Modifications made to the revenue accounting contract can result in retrospective adjustments towards the
recognized price, which is determined by the allocated price. The amount of the right of return is calculated based
on the recognized price. Therefore, retrospective adjustments are also performed for the right of return.
Fulfillment in Last Period
The right of return is fulfilled in the last accounting period of its duration. For example, a performance obligation of
right of return has a duration of 4 periods. In the first three periods, it does not has any fulfillment. In the last
period, the performance obligation is fulfilled 100%.
Prerequisites
The system tracks the revenue adjustment and cost for right of return with two reserved condition types.
Therefore, you must define these condition types in the following Customizing activity: Financial Accounting
Revenue Accounting Revenue Accounting Contracts Condition Types Define Reserved Condition Types
Activities
You can perform the following maintenance tasks for rights of return:
● Manually add rights of return
● Edit rights of return
5.5 Cost Recognition
Use
Revenue Accounting manages cost recognition by using objects such as revenue accounting contracts and
performance obligations (POBs).
The system handles cost recognition by taking the following steps:
1. If non-accrued costs of goods sold (COGS) are transferred to Revenue Accounting, they are regarded as
planned costs. When a fulfillment event occurs, these planned costs are used to calculate the recognized
cost.
2. The COGS is posted to FI-GL and account-based profitability analysis (CO-PA) when the goods issue is
posted. At the same time, Revenue Accounting makes a cost correction to reverse the recognized costs that
have been posted to FI-GL and account-based CO-PA from Sales and Distribution (SD).
Note
If the average costs in the goods issue differ from those in the order, the total cost will be adjusted
according to the new average costs.
108
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
3. An invoice with cost conditions is sent to Revenue Accounting. The system uses it to post cost corrections to
cost-based CO-PA.
4. Recognize the cost together with its corresponding revenue. Also refer to Fulfillment of Performance
Obligations [page 160].
5. Post the recognized cost to both FI-GL and CO-PA when you post its corresponding revenue. Also refer to
Revenue Posting [page 189].
Prerequisites
To enable cost posting, you need to perform the following Customizing activities:
● You have defined accounting principles and enabled company codes for cost recognition.
Revenue Accounting Revenue Accounting Contracts Configure Accounting Principle-specific Setting
● You have defined account determination for deferred cost and recognized cost.
Revenue Accounting Revenue Accounting Postings Configure Account Determination for Specific
Transaction
● You have defined performance obligation types for cost recognition.
Revenue Accounting Revenue Accounting Contracts Define Performance Obligation Types
● You have deselected the Transfer +/- flag for the cost condition type.
Controlling Profitability Analysis Flows of Actual Values Transfer of Incoming Sales Orders Assign
Value Fields
Note
If you want to prevent specific performance obligations from cost posting, you can go to the Details of these
performance obligations and deselect the Cost Recognition checkbox.
5.5.1 Examples for Cost Recognition
Here are five examples for cost recognition.
Example
Example 1
There is a sales order which contains the following information:
Table 49:
Total Cost Quantity
EUR 1,000 10 units
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 109
When a goods issue is posted, one item is delivered and its cost condition value is adjusted to EUR 110. The
posting entry in FI-GL and CO-PA is displayed as follows:
Table 50:
FI-GL CO-PA
Costs of Sales Material
Account-Based CO-PA
EUR 110 EUR 110
EUR 110
In the meantime, Revenue Accounting makes a cost correction.
Table 51:
FI-RA CO-PA
Recognized Cost Deferred Cost
Account-Based CO-PA
EUR 110 EUR 110 EUR -110
When the item is 40% fulfilled in Revenue Accounting, the posting entry in FI-RA and CO-PA is displayed as
follows:
Table 52:
FI-RA CO-PA
Recognized Cost Deferred Cost Account-Based CO-PA
EUR 440
EUR 440 EUR 440
Example 2
There is a sales order which contains the following information:
Table 53:
Total Cost Quantity
EUR 1,000 10 units
The performance obligation (POB) is manually fulfilled 40% in Revenue Accounting as follows:
Table 54:
FI-RA CO-PA
Recognized Cost Deferred Cost Costing-Based
CO-PA
EUR 400 EUR 400 EUR 400
At goods issue, an item is delivered at a price of EUR 110.
110
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Table 55:
FI-GL CO-PA
Costs of Sales Material Costing-Based
CO-PA
EUR 110 EUR 110
In the meantime, Revenue Accounting makes a cost correction.
Table 56:
FI-RA CO-PA
Recognized Cost Deferred Cost Costing-Based CO-PA
EUR 110 EUR 110
Revenue Accounting makes the following delta posting:
Table 57:
FI-GL CO-PA
Recognized Cost Deferred Cost Costing-Based
CO-PA
EUR 40 EUR 40
EUR 40
Example 3
There is a sales order which contains the following information:
Table 58:
Total Cost Quantity
EUR 1,000 10 units
When a goods issue is posted, one item is delivered and its cost condition value is adjusted to EUR 110. The
posting entry in FI-GL and CO-PA is displayed as follows:
Table 59:
FI-GL CO-PA
Costs of Sales
Material Costing-Based
CO-PA
EUR 110
EUR 110
In the meantime, Revenue Accounting makes a cost correction.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 111
Table 60:
FI-RA CO-PA
Recognized Cost Deferred Cost Costing-Based
CO-PA
EUR 110 EUR 110
When an invoice with cost is sent to Revenue Accounting, the system uses it to post a cost correction to
costing-based COPA.
Table 61:
Costing-based
CO-PA
EUR 110
In the meantime, Revenue Accounting make a correction.
Table 62:
Costing-based
CO-PA
EUR -110
Then the item is 40% fulfilled in Revenue Accounting.
Table 63:
FI-RA CO-PA
Recognized Cost Deferred Cost Costing-Based
CO-PA
EUR 440 EUR 440 EUR 440
Example 4
There is a sales order which contains the following information:
Table 64:
Total Cost Quantity
EUR 1,000 10 units
112 P U B L I C
SAP Revenue Accounting and Reporting
Contract Management
When a goods issue is posted, one item is delivered and its cost condition value is adjusted to EUR 100. The
posting entry in FI-GL is displayed as follows:
Table 65:
FI-GL
Costs of Sales
Material
EUR 100
EUR 100
In the meantime, Revenue Accounting makes a cost correction.
Table 66:
FI-RA
Recognized Cost
Deferred Cost
EUR 100 EUR 100
Then the item is 40% fulfilled in Revenue Accounting.
Table 67:
FI-RA
Recognized Cost
Deferred Cost
EUR 400 EUR 400
At the end, you change the price of the order to EUR 1,100. But no correction of recognized cost is required
because the average cost, which is based on the cost correction amount, remains unchanged.
Example 5
There is a sales order which contains the following information:
Table 68:
Total Cost Quantity
EUR 1,000 10 units
When a goods issue is posted, eight items are delivered and its cost condition value is adjusted to EUR 880. The
posting entry in FI-GL and CO-PA is displayed as follows:
Table 69:
FI-GL CO-PA
Costs of Sales
Material Account-Based
CO-PA
EUR 880 EUR 880 EUR 880
In the meantime, Revenue Accounting makes a cost correction.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 113
Table 70:
FI-RA CO-PA
Recognized Cost Deferred Cost Account-Based
CO-PA
EUR 880 EUR 880 EUR -880
Then the item is 100% fulfilled in Revenue Accounting and the status of the performance obligation is set to
Completed. When a performance obligation is completed, the total recognized cost is adjusted to the cost
correction amount from the goods issue.
Table 71:
FI-RA CO-PA
Recognized Cost Deferred Cost Costing-Based
CO-PA
EUR 880 EUR 880 EUR 880
5.5.2 Contract Acquisition Cost
Use
Contract acquisition cost is transferred from sender components such as the commission system. Revenue
Accounting manages contract acquisition cost with the following objects:
● Contract acquisition cost condition
Contract acquisition cost condition is a condition type that represents a contract acquisition cost. You can
define contract acquisition cost conditions in Customizing. Once contract acquisition cost conditions have
been defined, you can neither change nor delete them afterwards.
● Contract acquisition cost performance obligation
Contract acquisition cost performance obligation is a performance obligation that represents a contract
acquisition cost. The contract acquisition cost performance obligation can only contain contract acquisition
cost conditions.
Contract acquisition costs can be processed in Revenue Accounting at the following levels:
● Contract Acquisition Costs at Contract Level [page 115]
At this level, contract acquisition costs are represented by performance obligations. The system manages
contract acquisition costs with contract acquisition cost performance obligations. These performance
obligations can only contain contract acquisition cost conditions.
● Contract Acquisition Costs at Performance Obligation Level [page 116]
At this level, contract acquisition costs are represented by the condition. A performance obligation that
contains a contract acquisition cost condition can still have other conditions, such as PR00 and VPRS.
114
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Note
When creating a performance obligation, the system checks whether contract acquisition cost conditions of
the performance obligation have been predefined in Customizing. If not, Revenue Accounting rejects the
corresponding revenue accounting item (RAI) and reports an error message.
Prerequisites
You have enabled cost recognition in Customizing: Revenue Accounting Revenue Accounting Contracts
Configure Accounting Principle-specific Settings .
You have defined condition type roles in Customizing: Revenue Accounting Revenue Accounting Contracts
Condition Types Define Roles for Condition Types .
5.5.2.1 Contract Acquisition Costs at Contract Level
When contract acquisition cost is attached to a sales order, it is usually processed as a performance obligation.
The contract acquisition cost is sent to the Adapter Reuse Layer (ARL) as a revenue accounting item. The revenue
accounting item only consists of contract acquisition cost conditions.
Note
COGS refers to the cost of goods sold.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 115
A contract acquisition cost performance obligation has the following features:
● It is not attached to any other performance obligations.
● It is derived from your operational system instead of BRFplus.
● Its conditions can only consist of contract acquisition cost conditions.
Note that the performance obligation category is a field that distinguishes a contract acquisition cost
performance obligation from a standard performance obligation. A standard performance obligation cannot
only contain contract acquisition conditions.
● It is always excluded from price allocation.
● Its fulfillment type can only be time-based or a percentage of completion (POC).
● It cannot be a linked performance obligation.
● It cannot have a right of return.
● It cannot be handled via the simplified invoice process.
Duration of Time-based Contract Acquisition Cost at Contract Level
If the contract acquisition cost performance obligation is time-based, its duration can either be sent from external
sender components or determined in Revenue Accounting. In Revenue Accounting, the duration is derived from
the contract: the performance obligation copies the earliest start date and the latest end date from the contract.
You can also define your own rule in the BAdI: Deriving Duration of Performance Obligation for Contr. Acquisi. Cost.
As long as the BAdI is implemented, the duration sent from sender components will be overridden by the result
determined in the BAdI.
Note
For a contract acquisition cost with time-based fulfillment, the start date type must not be type 3 - Is Always the
Event Date.
If the fulfillment type is not time-based, Revenue Accounting displays a warning message. If you are certain that
the fulfillment type should not be time-based, you can skip the warning message in Customizing:
Revenue
Accounting Revenue Accounting Contracts Change Message Control .
Full Fulfillment of Contract Acquisition Cost at Contract Level
A contract acquisition cost performance obligation is fully fulfilled when all time-based fulfillments have occurred
or the percentage of completion is 100%.
5.5.2.2 Contract Acquisition Costs at Performance
Obligation Level
When a contract acquisition cost, such as commission cost, is attached to a sales order item, it is usually
processed as a cost condition. The contract acquisition cost is sent to the Adapter Reuse Layer (ARL) as a cost
116
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
condition together with other condition types, such as PR00 and VPRS. These conditions are processed and
attached to a performance obligation.
Note
For such a performance obligation, there is no restriction on its fulfillment type. You can specify any fulfilment
type, event type, and condition type when it is created.
Right of Return
The performance obligation can contain a right of return. However, the right of return cannot deduct contract
acquisition cost. For example, there is a performance obligation with a right of return that has both COGS and
contract acquisition costs. The right of return can only deduct the amount of COGS.
5.5.2.3 Fulfillment of Contract Acquisition Cost
When contract acquisition cost is sent to Revenue Accounting, the system posts a cost correction. The system
then checks whether condition types of the event have been defined in Customizing. If so, the system recognizes
the cost; if not, the system reports an error message.
Note
The contract acquisition cost, no matter at contract or performance obligation level, is calculated with the
cumulative correction amount.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 117
Example
A performance obligation is created in Revenue Accounting with a total quantity of 10 units. It contains three
condition types, among which COAC and COAB are used to present contract acquisition costs.
Table 72:
Condition Amount
COAC EUR 100.00
COAB EUR 200.00
VPRS EUR 500.00
Then the first event delivers 2 units of goods. The event contains the following conditions:
Table 73:
Condition Amount
COAC EUR 120.00
COAB EUR 150.00
COAX EUR 100.00
VPRS EUR 50.00
As COAX has not been maintained in Revenue Accounting, the system reports an error message and rejects
the event. Then the second event delivers 2 units of goods. This time the event contains the following
conditions:
Table 74:
Condition Correction Amount
COAC EUR 120.00
COAB EUR 150.00
VPRS EUR 50.00
For condition types such as VPRS, the cumulated amount is calculated as follows:
Cumulated Amount = Correction Amount / Correction Quantity * Total Quantity=50/2*10 =500
For condition types such as COAB and COAC, the cumulated amount is calculated as follows:
Cumulative Amount = Sum (Current Correction Amount + historical Correction Amount)
118
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Revenue Accounting adjusts these conditions as follows:
Table 75:
Condition Cumulative Amount
COAC EUR 120.00
COAB EUR 150.00
VPRS EUR 250.00
5.5.2.4 Over-fulfillment for Contract Acquisition Cost at
Performance Obligation Level
If the total fulfilled quantity sent by the Adapter Reuse Layer (ARL) is greater than the quantity defined when a
performance obligation is created, the recognized contract acquisition cost is the amount in the corresponding
revenue accounting item.
In this case, the difference for the recognized amount of contract acquisition cost needs to be adjusted in the final
invoice processing and the delta amount is also posted to FI-GL.
Example
A performance obligation is created with the following conditions. The event type is a goods issue.
Table 76:
Condition type Amount Quantity
COAC EUR 100 10 units
VPRS EUR 200 10 units
Then the performance obligation is fully fulfilled with a quantity of 11 units.
Table 77:
Condition
Type
Correction
Amount
Delivered
Quantity
Cumulative
Amount
Effective
Quantity
Recognized
Amount
Fulfillment
Quantity
COAC EUR 110 11 units EUR 110 10 units EUR 121 11 units
VPRS EUR 220 11 units EUR 200 10 units EUR 220 11 units
Note that when the contract acquisition cost is updated with the correction amount, the recognized amount is
calculated as follows:
Cumulative Amount/Effective Quantity*Fulfillment Quantity=110/10*11=121
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 119
For the final invoice, the effective quantity is changed to fulfillment quantity and the recognized amount is
adjusted accordingly as follows:
Recognized amount = Cumulative Amount / Effective Quantity * Fulfillment Quantity = 110/11 * 11 = 110
The delta amount of EUR -11 is then posted to FI-GL.
Table 78:
Condition
Type
Correction
Amount
Delivered
Quantity
Cumulative
Amount
Effective
Quantity
Recognized
Amount
Fulfillment
Quantity
COAC EUR 110 11 units EUR 110 11 units EUR 110 11 units
VPRS EUR 220 11 units EUR 220 11 units EUR 220 11 units
5.6 Support of Multiple Accounting Principles
Use
Your company’s sales with customers may require that you recognize revenue in compliance with different
accounting principles. The system allows you to specify the accounting principles that your company uses and
customize certain processes and calculations of revenue recognition for each of those accounting principles.
Prerequisites
The contract liabilities and contract assets feature requires that you make the settings in the following
Customizing activity:
Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Configure Accounting
Principle-Specific Settings
.
Features
The system provides the following support for revenue accounting with multiple accounting principles:
● Contract liabilities and contract assets
The system allows you to apply different methods for booking contract liabilities and contract assets,
depending on the accounting principle applied. The system provides the following calculation methods:
○ Invoice Due Date-Based Calculation
This method is typically used when the applicable accounting principle requires that you book contract
liabilities and contract assets, based on the invoice due amount.
120
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
○ Invoice Date-Based Calculation
This method is typically used when the applicable accounting principle requires that you book unbilled
receivable and deferred revenue, based on the invoiced amount.
○ None
This method is typically used when the applicable accounting principle does not require that you book any
contract liabilities and contract assets.
For more information, see the documentation provided with the following Customizing activity:
Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Configure
Accounting Principle-Specific Settings .
Note
Different accounting principles may use different terms to refer to the concept of contract liabilities and
contract assets.
● Contract splitting on creation
Depending on the configuration, the back-end operational system may request the creation of a contract with
performance obligations that involve different accounting principles. In this case, the system automatically
splits the contract into several contracts, each for a specific accounting principle.
● Account determination
The system allows you to determine the accounts that are relevant to revenue postings based on the
corresponding accounting principle.
○ For both classic General Ledger Accounting and new General Ledger Accounting:
When you plan your account arrangement, you can reserve account ranges for individual accounting
principles. That will make it easier for you to manage your accounts.
○ For new General Ledger Accounting:
If your system has new General Ledger Accounting enabled, you can post to the same account number in
different ledgers, corresponding to their accounting principles. Accounting principles can be assigned to
ledger groups in the Parallel Accounting settings in Customizing. The system then posts to the
corresponding ledger group associated with the accounting principle.
● Revenue posting for multiple accounting principles
When you make revenue postings to the general ledger, the system requires that you select one accounting
principle at a time.
5.7 Status Management
A status field is available for performance obligations and revenue accounting contracts respectively. Either a
performance obligation or a contract can have one of the following statuses:
● In Process
● Pending Review
● Completed
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 121
Performance Obligation Statuses
Table 79:
Status Details
In Process This is the normal status of performance obligations. Per
formance obligations with this status can be processed in all
processes of Revenue Accounting. You can change the status
In Process to the following:
● Pending Review
● Completed
Pending Review Performance obligations can have the status Pending Review
and a corresponding review reason. For more information, see
Regular Monitoring [page 102].
122 P U B L I C
SAP Revenue Accounting and Reporting
Contract Management
Status Details
Completed A performance obligation with this status meets either of the
following criteria:
● The performance obligation is fully fulfilled and its in
voiced amount is equal to contractual price from opera
tional documents.
● The performance obligation is deleted.
Normally, The system automatically sets performance obliga
tion to Completed if the above mentioned criteria are met.
You can also set the status to Completed in the following
ways:
● Manually set it on contract UI if the performance obliga
tion is value-relevant.
● Run a collective program to set migrated contracts to
Completed.
You can also change the status from Completed to In Process
to reopen the performance obligation.
When the status is set to Completed, the system uses one of
the following dates as its completion date:
● The date when the performance obligations is fully fulfil
led or final invoice is issued. The final invoice date is when
price of the performance obligation is changed to the
amount of contractual price from its operational docu
ment.
Note
The system uses the latest date, either full fulfillment
date or final invoice date.
● The system date when the performance obligation is de
leted.
● The system date when the performance obligation is
manually completed.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 123
Contract Statuses
Table 80:
Status Details
In Process A revenue accounting contract has the status In Process if all
of its performance obligations have the status In Process.
Specifically, the following conditions are true:
● No performance obligations have the status Pending
Review
.
● Not all performance obligations have the status
Completed.
Pending Review This status is derived from the performance obligations. The
contract has the status Pending Review if any performance
obligation in the contract has the status Pending Review.
Completed This status indicates that the contract is completed. You can
set a contract to this status with T-code
FARR_CONTR_COMPLETE if the following conditions are true:
● All performance obligations are completed.
● The total invoiced amount, the recognized revenue, and
the contractual price are equal.
● No balance amount is left in the deferred revenue, unbil
led receivable, and receivable adjustment accounts for
this contract.
You are allowed to set revenue accounting contracts of spe
cific company codes, accounting principles, and contract
numbers to the status. Also you can either schedule time to
run the program or run it immediately.
When the status is set to Completed, the system uses the lat
est completion date of performance obligation as completion
date of the contract.
5.8 Support of Multiple Currencies
Use
When Revenue Accounting creates a contract, it specifies a company code currency or transaction currency,
typically a document currency of the operational document such as a sales order. The transaction currency is
used to allocate transaction price to performance obligations, recognize revenues, and post revenues to the
general ledger.
In a foreign currency contract, the contract currency is different from the company code currency. When
transferring revenue postings to the general ledger, Revenue Accounting supports multiple currencies that are
124
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
predefined for the company code as local currencies. For each company code, you can define a maximum of three
parallel currencies:
● The first local currency, which is also company code currency, is defined in the company code master data.
● The second and third local currencies are defined in the additional local currencies data of the company code
using transaction code OB22.
The first local currency of a non-leading ledger is always the company code currency of the leading ledger. For the
second and third local currencies of a non-leading ledger, you can only use currency types that you have specified
for the leading ledger.
To handle multiple currencies, for each accounting principle you can choose either fixed or actual exchange rate
method to transfer contract currency to local currencies:
● Fixed exchange rate method
With this method, revenue is realized at a fixed rate over the lifecycle of the contract.
● Actual exchange rate method
With this method, revenue is realized with average historical exchange rate of contract liability or spot rate if
there is no liability.
Prerequisites
This feature has the following prerequisites:
● You have defined the local currencies for the corresponding company codes with transaction code OB22.
● You have defined the exchange difference account with transaction code OB09.
5.8.1 Define Relevant Currency Type
By default, Revenue Accounting calculates the amount in transaction currency and the first local currency
(company code currency) and generates FI documents accordingly. However, you need to decide whether second
and third local currencies will be calculated in Revenue Accounting through the following steps:
● Define second and third local currencies in OB22.
● Exclude local currencies from revenue accounting in Customizing: Revenue Accounting (New) Revenue
Accounting
Revenue Accounting Contracts Exclude Local Currency Calculation from Revenue
Accounting .
If Revenue Accounting calculates the second and third local currencies, it applies the respective exchange rates
on the posting date, the date on which program “Revenue Posting” is run, to calculate the amounts in second and
third currencies.
Note
If your second and third local currencies are translated from your first local currency on reporting date, we
suggest you to exclude second and third local currencies from revenue accounting. Then you only need to
make sure the amount in the first local currency is correctly calculated.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 125
If the second and third local currencies are not translated from the first local currency on reporting date, and
are directly using the amount from the posting amount in FI, we suggest you to include second and third local
currencies revenue accounting so that your three local currencies follow the same calculation logic.
5.8.2 Fixed Exchange Rate Method
With the fixed exchange rate method, Revenue Accounting calculates currency exchanges for all revenue
postings.
Use
Revenue is realized at a fixed rate over the lifecycle of the contract. The rate is fixed for all contract events, such
as setting up and clearing contract liability and contract asset (unbilled receivable and deferred revenue) and
contract fulfillment.
Revenue Accounting determines the exchange rate as the exchange rate on the day of the first event. For
example, if a contract is invoiced before delivery, all of the subsequent currency exchanges are calculated based
on the exchange rate of the day on which the invoice is issued. Therefore, when the contract is delivered, the
exchange rate used is the exchange rate of the day when the invoice is issued.
5.8.2.1 Post Exchange Difference
Revenue Accounting calculates and posts exchange difference in the following scenarios:
● Exchange difference is posted when processing invoice correction.
● Exchange difference is posted when processing recognized revenue in migration phase.
Before SAP Revenue Accounting and Reporting 1.2, the exchange differences are posted at contract level. Since
SAP Revenue Accounting and Reporting 1.2, the exchange differences can be saved at performance obligation
level, so that they can be posted to Profitability Analysis (COPA) for profit center accounting. You can also filter
posting entries by performance obligation.
Exchange difference when processing invoice correction
The first event, either goods issue or invoice or execution of program “Transfer Revenue”, determines the fixed
exchange rate for all future fulfillments of that contract. When future contract events are posted with different
exchange rates, the corresponding invoice correction posting for the revenue account is transferred with the
exchange rates of the future contract events, while the correction posting for receivable adjustment is transferred
with the fixed exchange rate. The difference of exchange rates between the future contract events and the first
contract event is posted to exchange difference account as gain or loss.
126
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Note
Once the fixed exchange rate is determined, the exchange rate is fixed for all local currencies. If the 2nd or 3rd
local currencies are based on the 1st local currency, then the exchange rate of the 2nd and 3rd local currencies
are fixed to the 1st local currency instead of the transaction currency.
Exchange difference when recognizing revenue in migration mode
When a legacy system is migrated to Revenue Accounting, the invoice or revenue is transferred with the original
exchange rate from the legacy system and this exchange rate may differ from the fixed exchange rate in Revenue
Accounting, hence the exchange difference in migration mode.
Note
If the legacy system transfers invoiced amounts and recognized revenue in foreign currencies with different
exchange rates to local currency, the aggregated difference between the invoiced amounts and recognized
revenue in local currency may deviate from the account balance of the deferred revenue and unbilled
receivables in local currency. So if you want to transfer currency at fixed exchange rate in migration mode,
make sure that the account balance of deferred revenue and unbilled receivable corresponds to the aggregated
balances of the corresponding contracts in local currency.
5.8.2.1.1 Special Condition Type of Exchange Difference
The exchange difference is posted on performance obligation condition type level since the release of Revenue
Accounting 1.2. In order to post exchange difference to COPA, you need to specify a special condition type. For
customizing path, you can choose
Revenue Accounting Revenue Accounting Contracts Define Performance
Obligation Types Condition Types Define Reserved Condition Types . In the change view of “Reserved
Condition Types”, you can specify the condition type of “Exchange Difference” as “EXDF”.
5.8.2.1.2 Configuration for Exchange Difference
You can configure the account determination and account assignment for exchange difference.
Account determination of exchange difference
You can configure the exchange difference account via OB09 by inputting currency type and receivable
adjustment account.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 127
Note
As exchange difference account is determined by receivable adjustment account on currency type level, you
should maintain different exchange difference accounts for different currency types with the same receivable
adjustment account.
Account assignment of realized exchange difference account
As the exchange difference account is a P/L account, it requires a CO account assignment when it is posted. You
can configure the account assignment by the transaction code OBK9.
5.8.2.1.3 Rounding Handling
With actual exchange rate method, barring in migration and when invoices are issued, there should be no
exchange difference. This is because revenue is fulfilled with a fixed exchange rate. Except for the differences in
migration period and when invoices are issued, all differences of local currencies are caused by rounding. The
rounding occurs in the following scenarios:
● Clear contract liability and contract asset (unbilled receivable and deferred revenue).
When revenue is posted, Revenue Accounting will check whether there is a remainder on the balance of
receivable adjustment account in local currencies. If there is any, the remainder amount will be posted as a
rounding amount.
● Sender components and Revenue Accounting handle rounding differently.
During invoice correction, there may be rounding issues if sender components, such as sales and distribution
(SD), have a different rounding handling method from Revenue Accounting.
When there are differences caused by different rounding methods, Revenue Accounting adjusts the posting as
follows:
● If several fulfillments or invoices correction happen at the same time, the rounding is adjusted to the
conditions with the biggest amount in document currency.
● For invoice correction, we directly adjust the invoice correction posting.
● For revenue posting, we directly adjust the revenue posting.
Note
As long as the amounts in transaction currency are consistent, Revenue Accounting ignores difference
amounts in second and third local currencies if the difference is insignificant. Also Revenue Accounting do not
post rounding difference if receivable adjustment account has balance in transaction currency left.
128
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
5.8.3 Actual Exchange Rate Method
Use
Revenue accounting contracts can be recorded in a foreign currency. Therefore its revenue and invoice are first
recorded in the foreign currency and transferred to local currencies with a specific exchange rate.
With actual exchange rate method, Revenue Accounting transfers fulfillment to local currencies at exchange rate
of the recognition date if recognized revenue is equal to invoiced amount. However more often than not
recognized revenue is not equal to invoiced amount. If there is contract liability and contract asset (unbilled
receivable and deferred revenue), Revenue Accounting recognizes revenue as follows:
Contract Liability and Contract Asset
Contract liability is recognized and transferred to local currencies with exchange rate on the invoice due date;
contract asset is recognized and transferred to local currencies with spot exchange rate when revenue is
recognized.
Deferred Revenue and Unbilled Receivable
Deferred revenue is recognized and transferred to local currencies with exchange rate of the invoice date; unbilled
receivable is recognized and transferred to local currencies with spot exchange rate when revenue is recognized.
More Information
Revenue Accounting handles the historical rate as a weighted average rate. It is calculated by the following
formula:
Weighted average rate=Sum of historical amounts in local currency / Sum of historical amounts in transaction
currency
Example
Revenue Accounting recognizes revenue of a performance obligation on three days. The recognized amounts
in transaction amounts are EUR 100, EUR 150, and EUR 100 respectively. Exchange rates from euro to dollar of
the three days are 1.2, 1.3, and 1.25 respectively. The weighted average rate is calculated as follows:
Table 81:
Day Exchange Rate Amounts in Transaction
Currency
Amounts in Local Currency
Day 1 1.2 EUR 100 USD 120
Day 2 1.3 EUR 150 USD 195
Day 3 1.25 EUR 100 USD 125
Weighted average rate= (120+195+125)/(100+150+100)=1.26
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 129
5.8.3.1 Calculate Foreign Currencies with Actual Rate
With Revenue Accounting, transactions and events are recognized in local currencies in program “Transfer
Revenue”.
Note
Program “Transfer Revenue” is used to be called “Calculate Time-based Revenue”. For more information, refer
to Transfer Revenue.
The program “Transfer Revenue” calculates a foreign currency into local currencies as follows:
● If the cumulative invoiced amount or invoice due amount exceeds recognized revenue up to the execution of
this program, then revenue will be recognized by using the average exchange rate of the exceeding part of
cumulative invoiced (invoice due amount).
● If the cumulative recognized revenue exceeds the cumulative invoice (invoice due amount) up to the
execution of this program, then the exceeding part of revenue will be recognized using the exchange rate of
the current date in this period when the program is executed. If the period you specify is in the past, then the
last day of the period is used to determine the exchange rate.
5.8.3.2 Correct Exchange Difference
With Revenue Accounting, there are exchange differences due to time difference of calculating a foreign currency
into local currencies. In actual exchange rate method, exchange differences are corrected in the following
scenarios:
● Transferring unbilled revenue or contract asset to billing
When billing is issued, if there are outstanding unpaid revenue or unbilled receivable, it shall use the rate of
outstanding unpaid revenue or unbilled receivable. However, FI-AR module uses the spot rate, instead of the
rate of contract asset on the revenue contract. As a result, when the receivable is cleared, Revenue
Accounting posts the realized exchange rate gain or loss so that cash, revenue and realized exchange rate
gain/loss are all correct. However, Revenue Accounting has not yet been integrated with payment and FI-AR .
So the correction of realized gain or loss of exchange rate difference can only be posted on invoice due date
as an approximation, which is the closest time to payment clearing.
As a result, when invoice clears unbilled revenue or contract asset, Revenue Accounting uses the rate of
invoice date to calculate the realized exchange difference, and post in the period when invoice is due.
● Transferring contract liability
When invoice is due, contract liability and receivable is recognized on the due date in Revenue Accounting.
Revenue Accounting calculates amounts in local currencies for contract liability and receivable with the
exchange rate on the invoice due date. So if cash is received on the same day, there should be no realized loss
or gain as there is no difference between the rate of cash and receivable. However, FI-AR first creates
receivable with the exchange rate the invoice issurance , and when cash is received and billing is cleared, FI-
AR posts the realized gain or loss based on the difference of exchange rate at payment and invoice issuance.
So Revenue Accounting will post a correction of the exchange difference between exchange rate at invoice
issuance and on invoice due date.
As Revenue Accounting is not integrated with Payment and AR Clearing in FI-AR, it can only post the
correction of realized gain or loss of exchange rate difference on invoice due date, which is the closest time to
payment.
130
P U B LI C
SAP Revenue Accounting and Reporting
Contract Management
Note
If you select to post with the contract balance presentation of contract liability and contract asset, instead
of unbilled receivable and deferred revenue, when invoice is due and contract liability is recognized,
exchange difference is determined, because contract liability is recognized at the due date.
If you select unbilled receivable and deferred revenue, deferred revenue is recognized on invoice date,
instead of invoice due date, no exchange difference should be posted.
5.9 Reprocessing
In some scenarios, you have to reprocess certain objects following changes that have been made to
configurations or to the logistics application. For example, after applying correct configurations, you have to
regenerate certain objects that already have incorrect attributes. Revenue Accounting supports the following
types of reprocessing:
● Reprocessing account determination
The reprocessing of account determination works as follows:
○ The system reprocesses account determination using the account on the latest condition types passed
from the logistics application.
○ This process only updates the accounts and account assignment data determined. It does not derive the
attributes of performance obligations again.
○ Reprocessing updates only items for which revenue postings have not been made. It does not update
items for which revenue postings have already been transferred to the general ledger.
○ You can use this function to fix accounts that have been determined incorrectly for the contract.
● Reprocessing contracts
The reprocessing of contracts works as follows:
○ The system regenerates certain objects, such as performance obligations.
○ The system retrieves all condition types, including new condition types, to address the changes made to
the operational document.
○ The system re-derives attributes of performance obligations and updates the performance obligations.
○ You can use this function to fix attributes that have been derived incorrectly for performance obligations
in the contract.
SAP Revenue Accounting and Reporting
Contract Management
P U B LI C 131
6 Price Allocation
Revenue Accounting allows you to allocate the transaction price among the performance obligations in a revenue
accounting contract. The standard price allocation is based on standalone selling prices. However, the system
allows you to specify other methods of price allocation to address your specific business scenarios.
6.1 Price Determination
When determining the transaction price of a revenue accounting contract, Revenue Accounting applies the pricing
conditions passed from the back-end operational system. Then, Revenue Accounting aggregates all pricing
conditions to determine the transaction price of the contract.
However, Revenue Accounting does not include the following condition types when calculating the transaction
price of a contract:
● Non-pricing condition types, such as costing condition types
Each condition entry includes a Pricing/Costing attribute that indicates whether the condition is a pricing or
costing condition.
● Statistical condition types
Each condition entry includes a Statistical attribute that indicates whether the condition a statistical or non-
statistical condition.
The amounts on these condition types are not added to the transaction price and therefore are not allocated.
6.1.1 Condition Exclusion List
You can maintain an exclusion list of condition types that you want to exclude from price allocation. Conditions of
these types are added to the total transaction price. However, they are not included in the price allocation.
Amounts on these condition types are added back to the allocated prices after the allocation is performed.
The exclusion list is available in the following Customizing activity:
Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Condition Types Define
Condition Types Not Requiring Allocation
6.1.2 Contractual Price
Use
After a performance obligation has been created, its original price can be changed multiple times over the lifecycle
of its fulfillment. For example, the price can be changed on the sales order after the sales order has been created
132
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
initially. The price of a sales order item can be changed when it is invoiced. The contractual price is the final price
that has all price changes consolidated but is the transaction price before allocation occurs. Therefore, the
contractual price is the effective price of the performance obligation before price allocation.
Example
Assume that your company sells 10 articles of product A at EUR 400 each and 10 articles of product B at EUR 600
each to a customer. When a revenue accounting contract is created, it includes two performance obligations: A
and B. Then the transaction price is calculated and allocated between these two performance obligations, for
example, according to their standalone selling prices.
Table 82:
Performance Obligation Contractual Price Allocated Price
A EUR 4,000 EUR 5,000
B EUR 6,000 EUR 5,000
Later, when 5 articles of product A are invoiced, the invoice changes the price of product A to 350 EUR each (for
the 5 articles being invoiced). In this case, the contractual prices and price allocation are as follows:
Table 83:
Performance Obligation Contractual Price Allocated Price
A EUR 3,750 EUR 4,875
B EUR 6,000 EUR 4,875
Note
In this example, the price change applies only to the 5 articles of product A being invoiced. Therefore, the price
of the remaining 5 articles remains unchanged. In this case, the total price of performance obligation A
becomes EUR 3,750, and the transaction price of the entire contract becomes EUR 9,750. The contractual
price is the effective price at which the product is sold. The allocated price determines how much revenue can
be recognized when the performance obligation is fulfilled.
6.2 Standalone Selling Price-Weighted Allocation
Use
The standard price allocation among performance obligations is based on standalone selling prices. The system
calculates the transaction price by consolidating the amounts on all pricing conditions that require allocation.
Then it redistributes the transaction price to performance obligations in proportion to their standalone selling
SAP Revenue Accounting and Reporting
Price Allocation
P U B LI C 133
prices. A performance obligation may represent multiple units of a sold item. Therefore, the amount allocated to
the performance obligation is in proportion to its standalone selling price multiplied by the quantity.
The standalone selling price is the “fair value” selling price of a distinct good or service if it is sold on its own.
Note
Currently negative standalone selling price is not allowed in Revenue Accounting and Reporting.
Example
RR’s Software Ltd. sells business software. One of her best-selling products is an accounting tool. In a contract
with a customer, RR’s Software Ltd. promises to deliver a software license for 15 users and maintenance service
for 12 months in exchange for a total of EUR 4,000. When sold separately, a license for one user sells for EUR 200,
and maintenance service for every 12 months sells for EUR 2,000.
The sales order includes 15 software licenses billed at EUR 200 each and one unit of maintenance service billed at
EUR 1,000 each period.
Allocation based on standalone selling prices produces the following result:
Table 84:
Index Performance Obli
gation
Standalone Sell
ing Price
Quantity Original PR00
Amount
Allocated PR00
Amount
1 Software License EUR 200 15 PC EUR 200 * 15 EUR 2,400
2 Maintenance Serv
ice
EUR 2,000 1 Period EUR 1,000 EUR 1,600
6.3 Standalone Selling Price Tolerances
Use
Sometimes, the transaction prices of your sold items are not exactly the same as, but are very close to, their
standalone selling prices. In this case, your items are sold almost at fair value, and therefore you do not want to
perform price allocation on this contract.
The standalone selling price tolerance allows you to specify , instead of a single value, a range of standalone
selling prices. The system performs price allocation only when at least one of the items in the contract is sold at a
price beyond its specified price range.
The tolerance can be specified either as an amount or as a percentage.
134
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
Example
Example 1:
Assume that you have a revenue accounting contract that resembles the following:
Table 85:
Performance Obli
gation
Transaction Price Standalone Sell
ing Price (SSP)
SSP Tolerance SSP Tolerance
Percentage
Price Within
Specified Range?
POB1 EUR 18 EUR 20 EUR 2 Not applicable Yes
POB2 EUR 20 EUR 20 EUR 2 Not applicable Yes
In this case, price allocation is not performed on the contract.
Example 2:
Assume that you have a revenue accounting contract that resembles the following:
Table 86:
Performance Obli
gation
Transaction Price Standalone Sell
ing Price (SSP)
SSP Tolerance SSP Tolerance
Percentage
Price Within
Specified Range?
POB1 EUR 17 EUR 20 EUR 2 Not applicable No
POB2 EUR 20 EUR 20 EUR 2 Not applicable Yes
POB3 EUR 32 EUR 30 EUR 3 Not applicable Yes
In this case, the transaction price of POB1 is beyond the range of EUR 18 to EUR 22. Therefore, price allocation is
performed on the contract.
6.4 Residual Price Allocation
Use
Usually sold items have standalone selling prices, but some do not, such as items that are never sold separately.
In this case, you can configure the system to mark the performance obligation as Residual when the system is
generating a performance obligation for the item.
Performance obligations are organized in a tree structure. For performance obligations under the same branch or
root, those that lose standalone selling prices are marked as Residual .
When the residual performance obligation is involved in allocation, the following rules apply:
● When the system allocates the transaction price, it aggregates amounts of all pricing condition types and
allocates the total amount down the hierarchy of performance obligations.
SAP Revenue Accounting and Reporting
Price Allocation
P U B LI C 135
● All performance obligations other than the ones marked as residual must have standalone selling prices.
● The performance obligations marked as residual do not have standalone selling prices, but they contain
transaction prices.
● If the sum of the standalone selling prices is less than the amount that is to be allocated, performance
obligations with standalone selling prices use their standalone selling prices as the allocated amounts. After
these performance obligations have claimed their portions, the remainder is allocated to performance
obligations marked as residual according to the following methods:
Table 87:
Scenario Allocation Method
Only one performance obligation marked as residual The remainder is assigned to the performance obligation
that is marked as residual. See example 1.
Two or more performance obligations marked as residual The remainder is assigned to the performance obligations
that are marked as residual. The remaining amount is allo
cated to all the performance obligations marked as residual
in proportion to their transaction prices. See example 2.
● If the sum of the standalone selling prices exceeds the amount that is to be allocated, a zero amount is
assigned to the performance obligations marked as residual. The total amount is allocated to the other
performance obligations in proportion to their standalone selling prices. See example 3.
Prerequisites
You can set a performance obligation to Residual in the following ways:
● Set a performance obligation type to Residual in Customizing: Revenue Accounting Revenue Accounting
Contracts Define Performance Obligation Types .
● Mark a performance obligation as Residual in BRFplus. You can maintain your rules in decision tables such as
decision table DT_PROCESS_POB.
Example
Example 1:
Assume that your company sells a bundle for EUR 50. The bundle is composed as follows:
● Two pieces of product A that sell for EUR 10 each
● One piece of product B that sells for EUR 20
● One piece of product C that does not have a standalone selling price
You have configured the system to create a performance obligation for each product in the bundle, and to mark
the performance obligation for product C as residual. In this case, the sum of standalone selling prices is less than
the amount that is to be allocated. So performance obligations with standalone selling prices use their
136
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
corresponding standalone selling prices as their allocated prices and the remaining amount is allocated to the
residual performance obligation. The allocation result is shown in the following table:
Table 88:
Performance obliga
tion
Sales Order Item Standalone Selling
Price
Quantity Allocated Amount
POB1 Product A EUR 10 2 PCS EUR 20 = 10*2
POB2 Product B EUR 20 1 PCS EUR 20 = 20*1
POB3 Product C None 1 PCS EUR 10 = 50-20-20
Example 2:
Assume that your company sells a bundle for EUR 70. The bundle is composed as follows:
● Two pieces of product A that sell for EUR 10 each
● One piece of product B that sells for EUR 20
● Three pieces of product C, product D, and product F (one for each) that do not have a standalone selling price
You have configured the system to create a performance obligation for each product in the bundle, and to mark
the performance obligations for product C, product D, and product F as residual. In this case, the sum of
standalone selling prices is less that the amount to be allocated. So performance obligations with standalone
selling prices use their corresponding standalone selling prices as their allocated prices and the remaining amount
is allocated to residual performance obligation in proportion to their corresponding transaction prices. The
allocation result is shown in the following table:
Table 89:
Performance obliga
tion
Sales Order Item Standalone Selling
Price
Quantity Allocated Amount
POB1 Product A EUR 10 2 PCS EUR 20 = 10*2
POB2 Product B EUR 20 1 PCS EUR 20 = 20*1
POB3 Product C None 1 PCS EUR 30 =70-20-20
POB4 Product D None 1 PCS
POB5 Product F None 1 PCS
Within the three performance obligations marked as residual, the remaining amount is allocated in proportion to
their transaction prices.
Table 90:
Performance obliga
tion
Sales Order Item Transaction Price Quantity Allocated Amount
POB3 Product C EUR 10 1 PCS EUR 5=30*[10/
(10*1+20*1+15*2)]
SAP Revenue Accounting and Reporting
Price Allocation
P U B LI C 137
Performance obliga
tion
Sales Order Item Transaction Price Quantity Allocated Amount
POB4 Product D EUR 20 1 PCS EUR 10=30*[20/
(10*1+20*1+15*2)]
POB5 Product F EUR 15 2 PCS EUR 15=30*[(15*2)/
(10*1+20*1+15*2)]
Example 3:
Assume that your company sells a bundle for EUR 30. The bundle is composed as follows:
● Two pieces of product A that sell for EUR 10 each
● One piece of product B that sells for EUR 20
● One piece of product C that does not have a standalone selling price
You have configured the system to create a performance obligation for each product in the bundle, and to mark
the performance obligation for product C as residual. In this case, the allocated amount for the residual
performance obligation is zero and the total amount is allocated to non-residual performance obligations in
proportion to their corresponding standalone selling prices. The allocation result is shown in the following table:
Table 91:
Performance obliga
tion
Sales Order Item Standalone Selling
Price
Quantity Allocated Amount
POB1 Product A EUR 10 2 PCS EUR 15 = 30*[(10*2)/
(10*2+20*1)]
POB2 Product B EUR 20 1 PCS EUR 15 = 30*[(20*1)/
(10*2+20*1)]
POB3 Product C None 1 PCS EUR 0
6.5 Performance Obligations Excluded from Allocation
For each revenue accounting contract, you can exclude certain performance obligations from price allocation.
Consequently, these performance obligations neither take any value from nor give any value to other performance
obligations in the contract. The allocated prices of these performance obligations are always the same as they
appear in the operational document.
138
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
6.6 Customized Allocation
Use
Revenue Accounting provides Business Add-Ins (BAdIs) that allow you to implement your own logic for allocating
transaction prices.
The following BAdIs suit your specific needs of price allocation:
● BAdI: Price Allocation (from Single Node Down)
● BAdI: Price Allocation (Flexible Allocation)
Prerequisites
● Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Business Add-Ins
Price Allocation BAdI: Price Allocation (from Single Node Down) .
● Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Business Add-Ins
Price Allocation BAdI: Price Allocation (Flexible Allocation) .
6.7 Allocation Effect
Use
Revenue Accounting can represent the effect of price allocation on a differential basis. Allocation effect indicates
how much the allocated prices differ from their transaction prices. When the system performs price allocation, it
aggregates the transaction prices of all performance obligations and distributes the total amount among the
performance obligations. In this redistribution process, some performance obligations gain value while other
performance obligations lose value in their allocated prices.
Performance obligation-level allocation effect
This amount indicates the difference effected on a specific performance obligation as a result of price allocation. A
positive amount indicates that the allocated price is greater than its transaction price. A negative amount
indicates that the allocated price is less than its transaction price.
Contract-level allocation effect
This amount indicates how significantly price allocation has occurred in the contract. This amount is the total
amount of value that has flowed from some performance obligations to others in the contract.
SAP Revenue Accounting and Reporting
Price Allocation
P U B LI C 139
Prerequisites
The system requires that a reserved condition type is defined for representing performance obligation-level
allocation effect amounts. This condition type is reserved for Revenue Accounting, and it must differ from any
other condition type used in the operational system. We recommend that you configure a condition type in the
operational system to make sure no other condition type uses the same name.
This setting is available in the following Customizing activity: Financial Accounting (New) Revenue Accounting
Revenue Accounting Contracts Condition Types Define Reserved Condition Types
Example
Assume that your company sells a bundle for EUR 50. The bundle is composed as follows:
● One pieces of Product A that sell for EUR 15
● One piece of Product B that sells for EUR 8
● One piece of Product C that sells for EUR 13
● One piece of Product D that sells for EUR 14
Price allocation is performed as follows:
Table 92:
Performance Obli
gation
Sales Order Item Transaction Price Standalone Sell
ing Price
Allocated Amount Adjustment
POB 1 Product A EUR 15 EUR 22 EUR 20 EUR +5
POB 2 Product B EUR 8 EUR 11 EUR 10 EUR +2
POB 3 Product C EUR 13 EUR 11 EUR 10 EUR -3
POB 4 Product D EUR 14 EUR 11 EUR 10 EUR -4
In this case, the allocation effect of the entire contract is EUR 7.
Note
The adjustment in the table is price allocation effect at performance obligation level.
6.8 Price Allocation for Structured Performance Obligations
Performance obligations in a contract can be structured hierarchically to address specific business scenarios.
Price allocation considers the structure as follows:
● From the top down
140
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
When allocating the transaction price, the system passes the transaction price down the tree structure. The
system first splits the transaction price among the performance obligations that do not have a higher-level
performance obligation (A, D, and E in the diagram). These performance obligations are at the root of the tree
structure. Then, for each of these performance obligations, the system passes the distributed amount further
down to its lower-level performance obligations (from A to B and C in the diagram). The system continues this
process until it walks through the entire tree.
The system treats performance obligations that have the same higher-level performance obligation (B and C
in the diagram) or no performance obligation (A and B) should be a group (A, D, and E). Allocation occurs
among the group first, and then for each group member.
● Fair value check
The standalone selling price can be a price range (set by a standalone selling price tolerance) as opposed to a
single value. Before splitting an amount among a group of performance obligations, the system checks
whether the price originally assigned is within the boundaries set by the standalone selling price tolerance. If
the price exceeds the range, the system splits the amount among the group. If the price does not exceed the
range, the members of this group keep their original amounts, but these amounts can be passed down for
further allocation.
● Linked performance obligations
A leading performance obligation is considered to be at the same level as its linked performance obligations
(D and E in the diagram). However, a leading performance obligation and its linked performance obligations
are always paired together in terms of fair value check. When checking the fair value of a leading performance
obligation, the system first aggregates the standalone selling prices on both the leading performance
obligation and its linked performance obligations ($60+$40 in the diagram). The system then compares the
original price of the leading performance obligation with the total of the standalone selling prices ($100 in the
diagram).
If the combination of leading and linked performance obligations is verified as sold at fair value and if all the
other performance obligations in the same group are verified as sold at fair value, the price is not split among
the group (A, D, and E in the diagram). However, price allocation must occur between the leading
performance obligations and its linked performance obligations (between D and E in the diagram).
If the combination of leading and linked performance obligations is verified as not sold at fair value or if any of
the other performance obligations in the same group is verified as not sold at fair value, price allocation
occurs among all performance obligations in the group (A, D, and E in the diagram).
● Sales BOM structures
For a sales BOM structure, the system always allocates the price down to the item level of the BOM structure,
regardless of where the pricing conditions are assigned.
● Compound performance obligations
For a compound performance obligation, the system proceeds as follows:
○ If the transaction price is calculated from the pricing conditions assigned on those non-distinct
performance obligations, the system allocates the price down to the level of the non-distinct performance
obligations.
○ If the transaction price is calculated from the pricing conditions assigned on the compound performance
obligation, the system allocates the price only down to the compound performance obligation.
SAP Revenue Accounting and Reporting
Price Allocation
P U B LI C 141
Figure 2: Example: Price Allocation in a Hierarchy
142
P U B LI C
SAP Revenue Accounting and Reporting
Price Allocation
7 Contract Change
The Revenue Accounting and Reporting system can perform contract change. The changes may come from the
following sources:
● Operational documents, such as sales order, invoice, and contract
● BRFplus
Note
Usually the change is triggered by changes of performance obligation attributes.
● UI
Contract change is a change of contractual price and condition. There are three types of contract change:
● Change of estimates
● Contract modification
● Attributes change from inception date
The Revenue Accounting system determines whether the change is change of estimates or contract modification
or attributes change from inception date. Change of estimates can change the price and quantity of all the
performance obligations no matter how much they have been fulfilled. However, Contract modification may only
change the total price and quantity of a contract after it has been partially fulfilled. Contract modification may
change the value of the part that remains to be fulfilled. Different change types of contract modification have
different ways of handling the part that has already been fulfilled before the change.
Additionally, you can apply your own logic through a Customizing activity. Choose Financial Accounting
Revenue Accounting Revenue Accounting Contracts Business Add-Ins BAdI: Determination of Contract
Change for Performance Obligation .
Note
Changes occur in a same period are consolidated.
Example
In operational documents, there are two changes applied to a performance obligation in a same period. The
details are in the following table:
Table 93:
Transaction Date Accounting Period Changed Attributes
of the Performance
Obligation
Before the Change After the Change
2015-08-03 2015008 New Performance Ob
ligation
No Standalone Selling
Price
Standalone Selling
Price =EUR 1,000
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 143
Transaction Date Accounting Period Changed Attributes
of the Performance
Obligation
Before the Change After the Change
2015-08-19 2015008 Standalone Selling
Price of the New Per
formance Obligation
Standalone Selling
Price =EUR 1,000
Standalone Selling
Price =EUR1,2000
However, our system only handle one change in the same period as follows:
Table 94:
Accounting Period Changed Attributes of the
Performance Obligation
Before the Change After the Change
2015008 New Performance Obligation Standalone Selling Price
=EUR 1,200
7.1 Invoicing
The back-end operational system can pass customer invoices to the Revenue Accounting system. Each invoicing
event can modify the revenue accounting contract or report a fulfillment event.
Contract Modification
An invoice passed to the Revenue Accounting system can trigger contract modifications as follows:
● Modifying the contractual price:
The amount of a condition on the invoice can differ from the amount of the same condition on the original
contract. The system handles this difference as a price change. The price change applies only to the part that
is being invoiced. For example, if a sales order includes 10 units of a product at a price of EUR 10 each and an
invoice is issued that includes a quantity of 2 and a price of EUR 15 each, the 2 units being invoiced have the
new price of EUR 15 each and the remaining 8 units still have the old price of EUR 10 each.
● Modifying the conditions:
An invoice passed to the Revenue Accounting system can have different condition types to the condition
types on the original contract. If the invoice includes condition types that are not included in the original
contract, the system handles this difference as a price change. If some condition types that are included in the
original contract are missing from the invoice, the system assumes that those condition types are also
included in the invoice but have an amount of zero.
● Preventing changes from being made to account determination:
The conditions in an invoice can have different accounts to the accounts assigned in the sales order. However,
the system always uses the accounts originally assigned in the sales order instead of the new accounts in the
invoice.
144
P U B LI C
SAP Revenue Accounting and Reporting
Contract Change
Note
A price change can be made through condition type changes made directly to the sales order instead of
through invoicing. The system handles the addition of condition types as a general change to the price.
However, if the change involves removing condition types, the system handles this situation differently
depending on whether any part of the condition type has been invoiced. If the condition type has not been
invoiced, the condition type is removed directly. If part of the condition type has been invoiced, the system
retains the removed condition type with an amount that is the same as the invoiced amount.
Marking an Invoice as Final
When the back-end system passes an invoice to the Revenue Accounting system, it indicates whether the invoice
is final for the contract. If the invoice is marked as final, the system assumes that no more invoices are to be
issued for this contract and that the totally invoiced amount is the final price of the contract. In this case, a
contract modification is triggered.
Due Date of Invoice
The back-end system can specify an invoice due date when issuing an invoice to the Revenue Accounting system.
The invoice due date is important for the calculation of contract liabilities and contract assets. For more
information, see Support of Multiple Accounting Principles [page 120].
Credit Memos and Debit Memos
The back-end operational system can pass credit memos and debit memos to the Revenue Accounting system as
a special type of invoice. With this type of invoice, the invoice quantity is ignored. In some rare scenarios, the
credit memo amount can exceed the original invoiced amount.
Invoicing for Milestone Billing Plans
The back-end operational system can pass invoices to the Revenue Accounting system for the scenario of
milestone billing plans, which can be defined with several billing items, each with an invoice date and an invoiced
amount that represents a percentage of the contract. Each sales order item with a milestone billing plan is
processed as a separate performance obligation.
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 145
Invoicing for Time-and-Material Projects
For a time-and-material (T&M) project, the sales order does not contain the price and is not relevant to price
allocation in the beginning. Invoicing is based on resources and materials that are actually consumed and revenue
is recognized accordingly. T&M items addressed by each invoice may vary. Each T&M item is processed as a
performance obligation with a quantity of 1. The T&M items do not have a price in the beginning. Therefore,
performance obligations are created with an amount of zero. Every time that a T&M item is invoiced, a contract
modification is triggered that increases the contractual price. Typically, a T&M item is invoiced with a debit memo.
Planned Invoices
If a performance obligation involves a billing plan, the performance obligation is invoiced according to the
schedule defined in the billing plan instead of according to the invoicing events that actually occur in the
operational application. The planned invoice amount is fixed when the performance obligation is created. The
integration component calculates the amount to be invoiced for each specific period and passes the planned
invoices to the Revenue Accounting system for processing. When calculating contract liabilities and assets, the
system performs the calculation according to the billing plan. In the Revenue Schedule user interface, the planned
invoice amount calculated according to the billing plan is displayed under Planned Invoice, and the actually
invoiced amount calculated according to invoicing events is displayed under Invoiced Amount.
Example
The billing plan starts from January 1, 2014 for 5 periods (each period with EUR 100) and invoices are passed to
Revenue Accounting for period 1 and period 2. In this case, the Revenue Schedule displays the following
amounts:
Table 95:
Period Invoiced Amount Planned Invoice
Period 1 EUR 100 EUR 100
Period 2 EUR 100 EUR 100
Period 3 EUR 0 EUR 100
Period 4 EUR 0 EUR 100
Period 5 EUR 0 EUR 100
7.2 Change of Estimates
When processing a change made to contracts and performance obligations, Revenue Accounting may determine
the change is handled as change of estimates. The total price and quantity of a contract may change no matter
146
P U B LI C
SAP Revenue Accounting and Reporting
Contract Change
whether it has been partially fulfilled. Therefore, this type of change does not only change the part that remains to
be fulfilled, but also those have been fulfilled. The system reallocates contractual prices among performance
obligations in a contract from inception date of the contract and add catch-ups to the originally allocated price.
When performance change of estimates, the system recalculates allocated prices and make up with catch-ups.
The catch-ups are calculated as follows:
Catch-up= (Updated Allocated Price-Original Allocated Price)*Fulfillment Percentage
Example
There is a contract that contains three performance obligations. Hereafter, POB and SSP in tables refer to
performance obligation and standalone selling price respectively. Detailed information of the contract is in the
following table:
Table 96:
Fulfillment (%)
POB 1 (software) 100%
POB 2 (maintenance) 20%
POB 3 (implementation) 30%
Before change of estimates, the system distributes the transaction price to performance obligations in
proportion to their standalone selling prices and corresponding calculates recognized revenues. The result is
showed in the following table:
Table 97:
Contractual Price SSP Allocated Price Fulfillment (%) Recognized Reve
nue
POB 1 (software) EUR 2000 EUR 2000 EUR 2000 100% EUR 2000
POB 2 (mainte
nance)
EUR 200 EUR 200 EUR 200 20% EUR 40
POB 3 (implemen
tation)
EUR 500 EUR 500 EUR 500 30% EUR 150
Sum EUR 2700 EUR 2700 EUR 2700 EUR 2190
Then the contractual price and standalone selling price of performance obligation 2 are raised to EUR 290 and
EUR 300 respectively. The system applies a change of estimates: it redistributes the transaction price to
performance obligations in proportion to their new standalone selling prices and recalculates corresponding
recognized revenues by adding catch-ups. The catch-ups are calculated in the following way:
Catch-up= (Updated Allocated Price-Original Allocated Price)*Fulfillment Percentage
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 147
The result is showed in the following table:
Table 98:
Contractual
Price
SSP Allocated Price Fulfillment (%) Recognized
Revenue
Catch-up
POB 1 (soft
ware)
EUR 2000 EUR 2000 EUR 1992.86 100% EUR
1992.86=2000-
7.14
-7.14
POB 2 (mainte
nance)
EUR 290 EUR 300 EUR 298.93 20% EUR
59.79=40+19.7
9
19.79
POB 3 (imple
mentation)
EUR 500 EUR 500 EUR 498.21 30% EUR
149.46=150-0.5
4
-0.54
Sum EUR 2790 EUR 2790 EUR 2790 EUR 2202.11
7.3 Contract Modification
According to IFRS 15 Revenue from Contracts with Customers, a contract modification is a change in the scope or
price (or both) of a contract that is approved by the parties to the contract. When the system performs contract
modification, the modification only applies to partially fulfilled performance obligations. There are three types of
contract modification:
● Prospective Change
● Retrospective Change
● Mixed Change
The system checks all open performance obligations and determines change type according to the following
table:
Table 99:
POB Change Type
Unit-distinct Prospective Change
None-unit-distinct Retrospective Change
Note
Unit-distinct fulfillments are distinct with each other at unit level.
148
P U B LI C
SAP Revenue Accounting and Reporting
Contract Change
7.3.1 Applying a Prospective Change
How a prospective change is calculated.
Use
Prospective change is a change that occurs on partially fulfilled performance obligations (POB). The fulfillments
are unit-distinct. When you apply a prospective change, the system will perform the following calculations:
Table 100:
Calculated Object Formula
Remaining SSP
Remaining Standalone Selling Price =
Standalone Selling Price*(1-Fulfillment
Percentage)
OR
Remaining Standalone Selling Price =
Standalone Selling Price*(1-Fulfilled
Period/Duration)
Note
In some cases, the remaining standalone selling price
(SSP) is calculated with both of the formulas.
Example
There is a leading performance obligation (A) and a linked
performance obligation (B). The following table provides
the details of the two performance obligations:
Table 101:
Fulfill
ment
Type
or
Event
Type
Effec
tive
Quan
tity
Dura
tion
SSP Con
trac-
tual
Price
Allo
cated
Price
POB A
(Lead
ing)
Goods
issue
3 EUR
2,000
EUR
2,000
EUR
1,600
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 149
Calculated Object Formula
POB B
(Linke
d)
Time-
based
(start
date
type
3)
1 10 EUR
500
0 EUR
400
When 2 units of leading performance obligation A are fulfil
led when the goods are issued, its linked performance obli
gation B is triggered to start fulfillment during the same pe
riod. Here is the fulfillment plan:
Table 102:
POB A POB B
Pe
riod
Fulfil
led
Quan
tity
Fulfill
ment
(%)
Fulfill
ment
Quan
tity
Fulfill
ment
(%)
SSP Rec
og-
nized
Reve
nue
1 2 67% 0.067 6.7% EUR
33.5
EUR
26.8
2 0.067 6.7% EUR
33.5
EUR
26.8
3 0.067 6.7% EUR
33.5
EUR
26.8
4 0.067 6.7% EUR
33.5
EUR
26.8
5 0.067 6.7% EUR
33.5
EUR
26.8
6 0.067 6.7% EUR
33.5
EUR
26.8
7 0.067 6.7% EUR
33.5
EUR
26.8
8 0.067 6.7% EUR
33.5
EUR
26.8
9 0.067 6.7% EUR
33.5
EUR
26.8
150 P U B L I C
SAP Revenue Accounting and Reporting
Contract Change
Calculated Object Formula
POB A POB B
Pe
riod
Fulfil
led
Quan
tity
Fulfill
ment
(%)
Fulfill
ment
Quan
tity
Fulfill
ment
(%)
SSP Rec
og-
nized
Reve
nue
10 0.067 6.7% EUR
33.5
EUR
26.8
Then in period 5, the duration of the performance obliga
tion is changed to 14 months. The calculation of perform
ance obligation B after the change is shown in the following
table:
Table 103:
POB A POB B
Pe
riod
Fulfil
led
Quan
tity
Ful
fill-
ment
(%)
Fulfill
ment
Quan
tity
Fulfill
ment
(%)
SSP Rec
og-
nized
Reve
nue
1 2 67% 0.067 6.7% EUR
33.5
EUR
26.8
2 0.067 6.7% EUR
33.5
EUR
26.8
3 0.067 6.7% EUR
33.5
EUR
26.8
4 0.067 6.7% EUR
33.5
EUR
26.8
5 0.040
2 =
(0.67-
0.067
*4)/1
0
4.02% EUR
20.1
EUR
16.08
6 0.040
2
4.02% EUR
20.1
EUR
16.08
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 151
Calculated Object Formula
POB A POB B
Pe
riod
Fulfil
led
Quan
tity
Ful
fill-
ment
(%)
Fulfill
ment
Quan
tity
Fulfill
ment
(%)
SSP Rec
og-
nized
Reve
nue
7 0.040
2
4.02% EUR
20.1
EUR
16.08
8 0.040
2
4.02% EUR
20.1
EUR
16.08
9 0.040
2
4.02% EUR
20.1
EUR
16.08
10 0.040
2
4.02% EUR
20.1
EUR
16.08
11 0.040
2
4.02% EUR
20.1
EUR
16.08
12 0.040
2
4.02% EUR
20.1
EUR
16.08
13 0.040
2
4.02% EUR
20.1
EUR
16.08
14 0.040
2
4.02% EUR
20.1
EUR
16.08
Remaining Price
Remaining Price = Total Contractual Price
- Recognized Revenue of Unit-distinct
Performance Obligation
152 P U B L I C
SAP Revenue Accounting and Reporting
Contract Change
Example
There is a contract that contains three performance obligations. The following table provides the details of the
contract:
Table 104:
Unit-distinct Fulfillment(%)
POB 1 (Software 1) Yes 100%
POB 2 (Software 2) Yes 20%
POB 3 (Software 3) Yes 30%
Before a prospective change, the system distributes the transaction price to performance obligations in
proportion to their standalone selling prices and calculates the corresponding recognized revenues. The result is
shown in the following table:
Table 105:
Contractual Price SSP Allocated Price Fulfillment (%) Recognized Reve
nue
POB 1 (Software 1) EUR 2,000 EUR 2,000 EUR 2,000 100% EUR 2,000
POB 2 (Software 2) EUR 200 EUR 200 EUR 200 20% EUR 40
POB 3 (Software 3) EUR 500 EUR 500 EUR 500 30% EUR 150
Total EUR 2,700 EUR 2,700 EUR 2,700 EUR 2,190
Then the contractual price and standalone selling price of performance obligation 2 are raised to EUR 300 and
EUR 300, respectively. The system applies a prospective change: the system calculates the remaining standalone
selling prices and uses them to reallocate the prices of the remaining contractual price to the performance
obligations. The remaining standalone selling prices are calculated as follows:
Remaining Standalone Selling Prices = Standalone Selling Price*(1-Fulfillment
Percentage)
The system redistributes the remaining price to performance obligations in proportion to their remaining
standalone selling prices. The result is showed in the following table:
Table 106:
Contractual
price
SSP Allocated
Price
Fulfillment
(%)
Recognized
Revenue
Remaining
Price
Remaining
SSP
Remaining
Allocated
Price
POB 1 (Soft
ware 1)
EUR 2,000 EUR 2,000 EUR 2,000 100% EUR 2,000
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 153
POB 2
(Software
2)
EUR 300 EUR 300 EUR 288.14 20% EUR 40 EUR 240 EUR 248.14
POB 3
(Software
3)
EUR 500 EUR 500 EUR 511.86 30% EUR 150 EUR 350 EUR 361.86
Total EUR 2,800 EUR 2,800 EUR 2,800 EUR 2,190 EUR 610 EUR 590 EUR 610
7.3.2 Retrospective Changes
Retrospective change is a change occurs on partially fulfilled performance obligations of which fulfillments are not
unit-distinct. When there is no performance obligations with unit-distinct fulfillment or all performance obligations
with unit-distinct fulfillment are fully fulfilled, the system applies retrospective change to the contract. When
applying prospective change, the system will perform the following calculations:
Table 107:
Calculated Object Formula
Remaining Standalone Selling Price Remaining Standalone Selling Price=Standalone Selling Price
Remaining Price Remaining Price=Total Contractual Price
Catch-up Catch-up= (Allocated Price-Allocated Remaining Price)*Ful
fillment Percentage
Example
There is a contract that contains three performance obligations. Detailed information of the contract is in the
following table:
Table 108:
Unit-distinct Fulfillment (%)
POB 1 (Software) Yes 100%
POB 2 (Maintenance) No 20%
POB 3 (Implementation) No 30%
154 P U B L I C
SAP Revenue Accounting and Reporting
Contract Change
Before retrospective change, the system distributes the transaction price to performance obligations in
proportion to their standalone selling prices and corresponding calculates recognized revenues. The result is
showed in the following table:
Table 109:
Contractual price SSP Allocated Price Fulfillment (%) Recognized Reve
nue
POB 1 (Software) EUR 2000 EUR 2000 EUR 2000 100% EUR 2000
POB 2 (Mainte
nance)
EUR 200 EUR 200 EUR 200 20% EUR 40
POB 3 (Implemen
tation)
EUR 500 EUR 500 EUR 500 30% EUR 150
Sum EUR 2700 EUR 2700 EUR 2700 EUR 2190
Then the contractual price and standalone selling price of performance obligation 3 are raised to EUR 600 and
EUR 600 respectively. The system applies retrospective change: the system calculates remaining standalone
selling prices and uses them to reallocated prices of the remaining contractual price. The remaining standalone
selling prices are calculated in the following way:
Remaining Standalone Selling Prices=Standalone Selling Price
Since performance obligation 2 and 3 cannot be fulfilled at unit level, all of the two performance obligations
should be included in reallocation. Therefore, remaining price is the contractual price of all partially fulfilled
performance obligation of which fulfillment is not unit-distinct. The system redistributes the remaining price to
performance obligations in proportion to their remaining standalone selling prices. The catch-up is calculated
in the following way:
Catch-up= (Allocated Price-Allocated Remaining Price)*Fulfillment Percentage
The result is showed in the following table:
Table 110:
Contrac
tual Price
SSP Allocated
Price
Fulfill
ment (%)
Recog
nized
Revenue
Remain
ing Price
Remain
ing SSP
Allocated
Remain
ing Price
Catch-up
POB 1
(Soft
ware)
EUR 2000 EUR 2000 EUR 2000 100% EUR 2000 0
POB 2
(Mainte
nance)
EUR 200 EUR 200 EUR 200 20% EUR 40 EUR 200 EUR 200
POB 3
(Imple
menta-
tion)
EUR 600 EUR 600 EUR 600 30% EUR 150 EUR 600 EUR 600 EUR 30
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 155
Contrac
tual Price
SSP Allocated
Price
Fulfill
ment (%)
Recog
nized
Revenue
Remain
ing Price
Remain
ing SSP
Allocated
Remain
ing Price
Catch-up
Sum EUR 2800 EUR 2800 EUR 2800 EUR 2190 800 EUR 800 EUR 800 EUR 30
7.3.3 Mixed Changes
Mixed change, name both prospective change and retrospective change, occurs when there are partially fulfilled
performance obligations of which some fulfillments are unit-distinct and some are not. When applying prospective
change, the system will perform the following calculations:
Table 111:
Calculated Object Formula
Remaining Standalone Selling Price Remaining Standalone Selling Price of Unit-distinct Perform
ance Obligation=Standalone Selling Price*(1-fulfillment per
centage)
Remaining Standalone Selling Price of None-Unit-distinct Per
formance Obligation=Standalone Selling Price
Remaining Price Remaining Price =Total Contractual Price - recognized Reve
nue of Unit-distinct Performance Obligation
Example
There is a contract that contains three performance obligations. Detailed information of the contract is in the
following table:
Table 112:
Unit-distinct Fulfillment (%)
POB 1 (Software 1) Yes 100%
POB 2 (Software 2) Yes 20%
POB 3 (Implementation) No 30%
156 P UB L I C
SAP Revenue Accounting and Reporting
Contract Change
Before mixed change, the system distributes the transaction price to performance obligations in proportion to
their standalone selling prices and corresponding calculates recognized revenues. The result is showed in the
following table:
Table 113:
Contractual Price SSP Allocated Price Fulfillment (%) Recognized Reve
nue
POB 1 (Software 1) EUR 2000 EUR 2000 EUR 2000 100% EUR 2000
POB 2 (Software
2)
EUR 200 EUR 200 EUR 200 20% EUR 40
POB 3 (Implemen
tation)
EUR 500 EUR 500 EUR 500 30% EUR 150
Sum EUR 2700 EUR 2700 EUR 2700 EUR 2190
Then the contractual price and standalone selling price of performance obligation 3 are raised to EUR 600 and
EUR 600 respectively. The system applies mixed change: the system calculates remaining standalone selling
prices and uses them to reallocated prices of the remaining contractual price. The remaining standalone selling
prices are calculated in the following way:
Table 114:
Remaining Standalone Selling Price
POB 2 (Unit-distinct) Standalone Selling Price * (1-Fulfillment Percentage)
POB 3 (Not Unit-distinct) Standalone Selling Price
Remaining price is calculated in the following way:
Remaining Price = Total Contractual Price – Recognized Revenue of Unit-distinct Performance Obligation
The system redistributes the remaining price to performance obligations in proportion to their remaining
standalone selling prices. The catch-up is calculated in the following way:
Catch-up= (Allocated Price-Allocated Remaining Price)*Fulfillment Percentage
The result is showed in the following table:
Table 115:
Contrac
tual price
SSP Allocated
Price
Fulfill
ment (%)
Recog
nized
Revenue
Remain
ing Price
Remain
ing SSP
Allocated
Remain
ing Price
Catch-up
POB 1
(Software
1)
EUR 2000 EUR 2000 EUR 2000 100% EUR 2000 0
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 157
Contrac
tual price
SSP Allocated
Price
Fulfill
ment (%)
Recog
nized
Revenue
Remain
ing Price
Remain
ing SSP
Allocated
Remain
ing Price
Catch-up
POB 2
(Software
2)
EUR 200 EUR 200 EUR 200 20% EUR 40 EUR 160 EUR 160
POB 3
(Imple
menta-
tion)
EUR 600 EUR 600 EUR 600 30% EUR 150 EUR 600 EUR 600 EUR 30
Sum EUR 2800 EUR 2800 EUR 2800 EUR 2190 EUR800 EUR 760 EUR 760 EUR 30
7.4 Attributes Change from Inception Date
When performing contract change, you cannot only change quantity and amount, but also some attributes of a
contract from its inception date, such as performance obligation type, fulfillment type, event type, and deferral
method. Among those changes of attributes, there are some that will not result in price reallocation.
Table 116:
Reallocation Changes
Yes Deferral method, start date, SSP, Residual price allocation
No Performance obligation type, fulfillment type, event type
7.5 Determination of Contract Change Type
As soon as the changes enter into Revenue Accounting and Reporting, the system determines types of contract
change by the following steps:
Step 1: The system checks change types in regards to each accounting principle in a Customizing activity:
Choose Financial Accounting Revenue Accounting Contracts Configure Accounting Principle-specific
If you do not enable contract modification, the change will be applied with change of estimates; otherwise, the
system determines change type in second step.
Step 2: The system checks change types on UI.
For performance obligations included in allocation, you can specify fiscal year, posting period, and change type;
for performance obligations excluded from allocation, you can specify performance obligation ID, performance
158
P U B LI C
SAP Revenue Accounting and Reporting
Contract Change
obligation name, fiscal year, posting period, and change type. The system keeps manual change no matter what is
resulted from BAdI.
Step 3: The system checks change type from BAdI if only the first two steps fail to determine change type. You
can find rules of BAdI in the document of BAdI: Determination of Contract Change for Performance Obligation.
Note
Current output of BAdI always override last one.
SAP Revenue Accounting and Reporting
Contract Change
P U B LI C 159
8 Fulfillment of Performance Obligations
Revenue Accounting manages the fulfillment statuses of performance obligations on its own. When a
performance obligation qualifies as fulfilled, it is tracked as fulfilled in Revenue Accounting. The corresponding
revenues and costs are then recognized in a revenue posting job, typically performed at the closing of an
accounting period. Therefore, the data tracked in Revenue Accounting may be inconsistent with the general
ledger until a revenue posting job is performed.
Revenue Accounting supports various calculations of performance obligation fulfillment. For example,
performance obligations can be fulfilled in the following ways:
● On the occurrence of a certain event
● Over a period of time
● Over a period of time that starts with an event
● Manually managed
8.1 Event-Based Fulfillment
Use
A performance obligation can be fulfilled on the occurrence of a certain event, such as a goods issue. In this
scenario, you can set the fulfillment type to Event-Based and define the appropriate type of event that triggers the
fulfillment of the performance obligation.
Prerequisites
This system tracks fulfillment against event types that are defined in the following Customizing activity:
Financial Accounting Revenue Accounting Revenue Accounting Contracts Define Fulfillment Event
Types
8.2 Time-Based Fulfillment
A performance obligation can be fulfilled over a period of time. That period can be specified by a start date in
combination with either a length of time or an end date. The fulfillment of the performance obligation can be
distributed over the duration in many ways. For example, you can fulfill the performance obligation by the end of
the last accounting period of the duration. Or you can distribute the fulfillment evenly among the accounting
periods within the duration.
160
P U B LI C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
8.2.1 Spreading
Spreading determines how the entire fulfillment of a performance obligation is distributed over the specified
period of time. Revenue Accounting provides several ways of determining the spreading of a performance
obligation.
Deferral Methods
Using deferral methods is one of the ways of determining how the fulfillment of a performance obligation is spread
over a period of time. In the standard system, the following deferral methods are available:
Table 117:
Deferral Method Description
Deferral method 1: Linear Distribution, Day-Specific, 365/366
Basis
The fulfillment of the performance obligation is evenly distrib
uted over the number of days in the duration. Therefore, the
revenue or cost recognized for each accounting period is in
proportion to the number of days that fall in that accounting
period.
When you use this deferral method, the total number of days
is calculated at 365 or 366 days per year, depending on
whether it is a leap year.
Deferral method 2: Linear Distribution, Day-Specific, 360 Basis The fulfillment of the performance obligation is evenly distrib
uted over the number of days in the duration. Therefore, the
revenue or cost recognized for each accounting period is in
proportion to the number of days that fall in that accounting
period.
When you use this deferral method, the total number of days
is calculated at 360 days per year and every month is re
garded as having 30 days in total, including February. The
number of days that falls in the first period is calculated as fol
lows:
Days in the first period=30-days not in
the first period
Deferral method 3: Linear Distribution, Day-Specific, 360 Basis
(with rounding in the last period)
The calculation of fulfillment is similar to deferral method 2,
except that it applies a different rounding calculation that
makes sure that all periods other than the first and last peri
ods have identical amounts.
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 161
Deferral Method Description
Deferral method 4: Linear Distribution, Day-Specific The fulfillment of the performance obligation is evenly distrib
uted over the number of periods in the duration. Therefore,
the revenue or cost recognized for each accounting period is
in proportion to the number of periods that fall in that ac
counting period.
When you use this deferral method, the quantity of an ac
counting period is the number of days that falls in the period
divided by total calendar days in that period.
Deferral method F: Recognition in First Period The fulfillment of the performance obligation is distributed to
the first accounting period of the duration.
Deferral method L: Recognition in End Period The fulfillment of the performance obligation is distributed to
the last accounting period of the duration.
Deferral method S: Linear Distribution, Period-Specific The fulfillment of the performance obligation is distributed
over the number of accounting periods in the duration, re
gardless of the number of days that fall in each period.
If the duration is not aligned to periods, and if the part that
falls in the last period does not fill up the entire period, no part
of the fulfillment is distributed to the last period.
Example scenario:
Your company sells to a customer a unit of equipment and a maintenance service that is good for three months of
the delivery of the equipment. The allocated price for the maintenance service is EUR 1000. Your company
delivers the equipment on January 5, 2014. You want the performance obligation for the equipment to be fulfilled
immediately on delivery, and want the performance obligation for the maintenance service to be fulfilled over
three months thereafter.
In this scenario, different deferral methods cause the performance obligation for the maintenance service to be
fulfilled as follows:
Table 118:
Deferral Method Period Fulfilled quantity Fulfilled revenue
Deferral method 1: Linear
Distribution, Day-Specific,
365/366 Basis
Period 1 (Jan 5 – Jan 31, 27
days)
27/90=0.300000 EUR 1000*27/90=EUR 300
Period 2 (Feb 1 – Feb 28, 28
days)
27/90+28/90-0.3=0.311111 EUR
1000*(27/90+28/90)-300=E
UR 311.11
Period 3 (Mar 1 – Mar 31, 31
days)
27/90+28/90+31/90-0.3-0.3
11111=0.344445
EUR
1000*(27/90+28/90+31/90)
-300-311.11=344.45 EUR
162 P U B L I C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
Deferral Method Period Fulfilled quantity Fulfilled revenue
Period 4 (Apr 1 – Apr 4, 4
days)
1-0.3-0.311111-0.344445=0.0
44444
EUR
1000-300-311.11-344.45=
EUR 44.44
Note: The total number of days is 90 days (27+28+31+4).
Deferral method 2: Linear
Distribution, Day-Specific,
360 Basis
Period 1 (Jan 5 – Jan 31, 26
days)
26/90=0.288889 EUR 1000*26/90=EUR
288.89
Period 2 (Feb 1 – Feb 28, 30
days)
26/90+30/90-0.288889=0.3
33333
EUR
1000*(26/90+30/90)-288.8
9=EUR 333.33
Period 3 (Mar 1 – Mar 31, 30
days)
26/90+30/90+30/90-0.288
889-0.333333=0.333334
EUR
1000*(26/90+30/90+30/90
)-288.89-333.34=EUR 333.34
Period 4 (Apr 1 – Apr 4, 4
days)
1-0.288889-0.333333-0.3333
34=0.044444
EUR
1000-288.89-333.34-333.33
=EUR 44.44
Note: The total number of days is 90 days (26 + 30 +30 + 4). The number of days in the first
period is calculated as 30 minus the number of days not in the period (4 days in this example),
down to 0. The number of days in the last period is calculated as the number of days that fall in
that period (4 days in this example), up to 30.
Deferral method 3: Linear
Distribution, Day-Specific,
360 Basis (with rounding in
the last period)
Period 1 (Jan 5 – Jan 31, 26
days)
26/90=0.288889 EUR 1000*26/90=EUR
288.89
Period 2 (Feb 1 – Feb 28, 30
days)
30/90=0.333333 EUR 1000*(26/90+30/90)-
288.89=EUR 333.33
Period 3 (Mar 1 – Mar 31, 30
days)
30/90=0.333333 EUR
1000*(26/90+30/90+30/90
)-288.89-333.33=EUR 333.34
Period 4 (Apr 1 – Apr 4, 4
days)
1-0.288889-0.333333-0.3333
33=0.044445
EUR
1000-288.89-333.33-333.34
=EUR 44.44
Note: The calculation applies a rounding calculation that makes sure that all periods other
than the first and last periods have identical amounts.
Deferral method 4: Linear
Distribution, Day-Specific
Period 1 (Jan 5 – Jan 31, 27
days)
(27/31)/
(27/31+1+1+4/30)=0.28990
7
EUR 1000*(27/31)/
(27/31+1+1+4/30)=EUR
289.91
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 163
Deferral Method Period Fulfilled quantity Fulfilled revenue
Period 2 (Feb 1 – Feb 28, 30
days)
1/
(27/31+1+1+4/30)=0.332856
EUR 1000*(27/31+1) /
(27/31+1+1+4/30)-289.91=E
UR 332.85
Period 3 (Mar 1 – Mar 31, 30
days)
1/
(27/31+1+1+4/30)=0.332856
EUR 1000*(27/31+1+1) /
(27/31+1+1+4/30)-289.91-33
2.85=EUR 332.86
Period 4 (Apr 1 – Apr 4, 4
days)
(4/30)/
(27/31+1+1+4/30)=0.044381
EUR
1000-289.91-332.85-332.86=
EUR 44.38
Note: The total number of periods is the sum of 27/31, 1, 1, and 4/30. Therefore, the revenue
for period 1 can be calculated as follows: Revenue for period 1= Revenue*(27/31)
(27/31+1+1+4/30)
Deferral method F:
Recognition in First Period
Period 1 (Jan 5 – Jan 31) 1 EUR 1000
Period 2 (Feb 1 – Feb 28) 0 0
Period 3 (Mar 1 – Mar 31) 0 0
Period 4 (Apr 1 – Apr 4) 0 0
Deferral method L:
Recognition in End Period
Period 1 (Jan 5 – Jan 31) 0 0
Period 2 (Feb 1 – Feb 28) 0 0
Period 3 (Mar 1 – Mar 31) 0 0
Period 4 (Apr 1 – Apr 4) 1 EUR 1000
Deferral method S: Linear
Distribution, Period-Specific
Period 1 (Jan 5 – Jan 31) 1/3=0.333333 EUR 1000*1/3=EUR 333.33
Period 2 (Feb 1 – Feb 28) 1/3=0.333334 EUR
1000*(1/3+1/3)-333.33=EUR
333.34
Period 3 (Mar 1 – Mar 31) 1/3=0.333333 EUR
1000-333.33-333.34=EUR
333.33
Period 4 (Apr 1 – Apr 4) 0 0
Note: The part that falls in the last period (period 4) does not fill up the entire period.
Note
This example assumes that each accounting period spans from the first day to the last day of each month.
164
P U B LI C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
Customized Deferral Methods
You may need to spread the fulfillment in a way that is not addressed by any of the default deferral methods. The
following Business Add-In (BAdI) allows you to develop your own deferral methods: Financial Accounting (New)
Revenue Accounting Revenue Accounting Contracts Business Add-Ins
Manual Spreading
In addition, Revenue Accounting allows you to manually arrange the fulfillment over the specified duration. In this
operation, you can specify how much revenue is distributed to each accounting period within the duration. The
system provides you with the spreading applied by default, and your values override the existing spreading
arrangement.
The number of periods to which you allocate the time-based revenue depends on the deferral method that is
assigned to the performance obligation.
For example, your performance obligation is to be fulfilled over a 3-month duration that runs across 4 accounting
periods. The total revenue of that performance obligation amounts to EUR 500. If the deferral method is “Linear
Distribution, Day-Specific, 360 Basis”, the system allows you to specify how this amount is split among the 4
accounting periods. If the deferral method is “Linear Distribution, Period-Specific”, the system allows you to
specify how this amount is split among the first 3 accounting periods.
8.2.2 Duration of Fulfillment
The duration over which a performance obligation is fulfilled is determined by combinations of start date, end
date, and duration.
Start Date
This specifies the start date of the duration over which the performance obligation is to be fulfilled.
End Date
This specifies the end date of the duration over which the performance obligation is to be fulfilled.
Duration
This specifies the length of the period during which the performance obligation is to be fulfilled.
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 165
Start Date Type
When the back-end operational system requests the creation of a time-based performance obligation, it can
specify how the start date is determined by using the Start Date Type attribute.
● 1 - Available on Creation of Performance Obligation
This indicates that the start date must be specified when the performance obligation is created. The system
issues an error message if the start date is missing.
● 2 - Available After Creation of Performance Obligation
This indicates that the start date does not have to be specified when the performance obligation is created.
Until the start date is specified later, the fulfillment of the performance obligation does not proceed.
● 3 - Is Always the Event Date
This option allows for two scenarios. If the performance obligation is a linked performance obligation, the start
date of the duration is always the date of the fulfillment event that occurs on its leading performance
obligation. If the performance obligation is not a linked performance obligation but its time-based fulfillment
starts from an event that occurs on that performance obligation, the start date is always the date of its own
fulfillment event.
Scenarios
The following scenarios are typical scenarios with different combinations of start date, end date, duration, and
start date type.
Table 119:
Scenario Start Date End Date Duration Start Date Type Description
1 x x 1 Fulfilled over a pe
riod, starting from
a specified date to
a specified date.
2 x x 1 Fulfilled over a pe
riod of a specified
length, starting
from a specified
date
3 2 Fulfilled over a pe
riod that cannot be
determined at the
time of contract
creation.
166 P U B L I C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
Scenario Start Date End Date Duration Start Date Type Description
4 x 3 Fulfilled over a pe
riod of a specified
length. The fulfill
ment starts from
the occurrence of
an event.
5 x 3 Fulfilled over a pe
riod that ends on a
specific date, with
its start date to be
specified later. This
scenario is rare.
Unless customized
otherwise, the sys
tem by default is
sues a warning
when the back-end
system requests
the creation of
such a perform
ance obligation.
8.3 Fulfillment by Percentage of Completion
Use
Your contracts with customers may involve a project to which quantities do not apply. The revenue is recognized
according to the percentage of the project that has been completed. In this scenario, you can fulfill relevant
performance obligations by percentage of completion. This scenario requires the following configurations on the
performance obligations:
● Fulfillment type: Percentage of Completion
● Event type: Manual
To fulfill a performance obligation of this kind, the accountant manually enters the progress into the Revenue
Accounting system by specifying the percentage that has been completed.
Activity: Quantity Change
Case 1
If you only change the total quantity of the performance obligation without fulfillment type modification, then the
fulfilled quantity is recalculated with the percentage of the new total quantity completed.
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 167
Before:
Fulfillment type of performance obligation 1 is percentage of completion.
Table 120:
Performance Obliga
tion
Fulfillment Type Total Quantity Fulfilled Quantity Percentage
1 Percentage of comple
tion
10 units 5 units 50%
After:
The total quantity is changed to 8 units. Then its fulfilled quantity is recalculated with percentage of completion of
8 units.
Table 121:
Performance Obliga
tion
Fulfillment Type Total Quantity Fulfilled Quantity Fulfillment Percentage
1 Percentage of comple
tion
8 units 4 units 50%
Case 2
If you change fulfilment type from other types such as event-based, time-based, or manual to percentage of
completion, then the fulfilled quantity is recalculated with percentage of completion of the total quantity.
Before:
Fulfillment type of performance obligation 2 is event-based.
Table 122:
Performance Obliga
tion
Fulfillment Type Total Quantity Fulfilled Quantity Fulfillment Percentage
2 Event-based 10 units 5 units 50%
After:
The fulfillment type is changed to percentage of completion and the total quantity is changed to 8 units. Then its
fulfilled quantity is recalculated with percentage of completion of 8 units .
Table 123:
Performance Obliga
tion
Fulfillment Type Total Quantity Fulfilled Quantity Fulfillment Percentage
2 Percentage of comple
tion
8 units 4 units 50%
Case 3
168
P U B LI C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
If you change fulfillment type from percentage of completion to other types such as event-based, time-based, and
manual, then the fulfilled quantity remains without change.
Before:
Fulfillment type of performance obligation 3 is percentage of completion.
Table 124:
Performance Obliga
tion
Fulfillment Type Total Quantity Fulfilled Quantity Percentage
3 Percentage of comple
tion
10 units 5 units 50%
After:
The fulfillment type is changed to event-based and the total quantity is changed to 8 units. Its fulfilled quantity
does not change.
Table 125:
Performance Obligation Fulfillment Type Total Quantity Fulfilled Quantity
3 Event-based 8 units 5 units
More Information
For more information about manual fulfillment, see Manual Fulfillment [page 169].
8.4 Manual Fulfillment
Use
Certain business scenarios require that performance obligations can only be fulfilled manually. For example, the
revenue can be recognized only when the company receives a confirmation letter from the customer.
Manual fulfillment of performance obligations is also a type of event-based fulfillment. The only difference is that
the fulfillment is not automatically triggered by incoming events. Instead, the accountant manually specifies how
much of a performance obligation is delivered. The system then calculates how much of that performance
obligation is actually fulfilled, based on its dependency on other performance obligations.
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 169
Prerequisites
For a performance obligation to be fulfilled manually, the following settings are required:
● The fulfillment type is either event-based (E) or the percentage of completion (O).
● The event type is Manual (MA).
Even though you can define your own event types that progress performance obligations toward their fulfillment,
Manual (MA) is a predelivered event type that indicates that the performance obligation is to be fulfilled manually.
Features
● Manual fulfillment at contract level
You can manually fulfill performance obligations across multiple revenue accounting contracts at the same
time. The search function allows you to find contracts that contain performance obligations to be manually
fulfilled. When you select multiple contracts to be fulfilled, the system fulfills the relevant performance
obligations in those contracts to 100%. The system only processes performance obligations that require
manual fulfillment, ignoring performance obligations that do not require manual fulfillment.
● Manual fulfillment at performance obligation level
You can fulfill a specific performance obligation by a specified quantity. For example, this allows you to
manually report a delivery for a performance obligation. You manually specify how much of a performance
obligation is delivered, and the system then calculates how much of that performance obligation is actually
fulfilled, based on its dependency on other performance obligations. In this case, the actually fulfilled quantity
is simulated before the change is saved.
Depending on the fulfillment type, either a quantity or a percentage of completion can be specified.
You can manually fulfill a performance obligation (POB) by delta value or cumulative value. For example, if you
have fulfilled a performance obligation to 30%, and now you want to fulfill that performance obligation up to
50%. You have two options to achieve this:
1. You can select the Fulfill By Delta Value push button and enter 20% as the delta value.
2. Alternatively, you can select the Fulfill By Cumulative Value push button and enter 50% as the cumulative
value.
○ Performance obligation manual fulfillment by delta value
Table 126:
Field Name Description Field Type
Quantity to Be Delivered This field is available when the per
formance obligation can be fulfilled
by quantity, which illustrates the
number of pieces to be delivered.
Input field
170 P U B L I C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
Reported Quantity Not Delivered This field shows the quantity of a per
formance obligation that has not
been transferred into revenue. This
helps you to enter the available quan
tity in the ‘Quantity to Be Delivered’
field.
Read-only field
Actual Quantity Not Delivered This field shows the quantity of a per
formance obligation that has not
been physically fulfilled. This helps
you to enter the available quantity in
the ‘Quantity to Be Delivered’ field.
Read-only field
Percentage to Be Delivered (%) This field is available when the per
formance obligation can be fulfilled
by percentage. It illustrates the per
centage of the performance obliga
tion to be delivered.
Input field
Reported Percentage Not Completed
(%)
This field shows the percentage of a
performance obligation that has not
been transferred into revenue. This
helps you to enter the available per
centage in the ‘Percentage to Be De
livered (%)’ field.
Read-only field
Actual Percentage Not Completed
(%)
This field shows the percentage of a
performance obligation that has not
been physically fulfilled. This helps
you to enter the available percentage
in the ‘Percentage to Be Delivered
(%)’ field.
Read-only field
Note
If the contract contains a bill of material performance obligation or a compound performance obligation,
the fields ‘report quantity not delivered’ and ‘actual quantity not delivered’, or ‘report percentage not
completed and ‘actual percentage not completed’, are displayed.
○ Performance obligation manual fulfillment by cumulative value
Table 127:
Field Name Description Field Type
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 171
Cumulative Fulfilled Quantity This field is available when the per
formance obligation can be fulfilled
by quantity. It illustrates the number
of pieces to be delivered cumula
tively.
Input field
Reported Fulfilled Quantity This field shows the quantity of a per
formance obligation that has been
transferred into revenue. This helps
you to enter the available quantity in
the ‘Cumulative Fulfilled Quantity’
field.
Read-only field
Actual Fulfilled Quantity This field shows the quantity of a per
formance obligation that has been
physically fulfilled. This helps you to
enter the available quantity in the
‘Quantity to Be Delivered’ field.
Read-only field
Cumulative Percentage of Comple
tion (%)
This field is available when the per
formance obligation can be fulfilled
by percentage. It illustrates the per
centage of the performance obliga
tion to be delivered cumulatively.
Input field
Reported Percentage of Completion
(%)
This field shows the percentage of a
performance obligation that has been
transferred into revenue. This helps
you to enter the available percentage
in the ‘Cumulative Percentage of
Completion (%)’ field.
Read-only field
Actual Percentage of Completion (%) This field shows the percentage of a
performance obligation that has been
physically fulfilled. This helps you to
enter the available percentage in the
‘Cumulative Percentage of Comple
tion (%)’ field.
Read-only field
Note
If the contract contains a bill of material performance obligation, or a compound performance obligation,
the fields ‘report quantity not delivered’ and ‘actual quantity not delivered’, or ‘report percentage not
completed and ‘actual percentage not completed’, are displayed.
● Reverse fulfillment
For a performance obligation, you can perform a reverse fulfillment to deduct a quantity from the completely
fulfilled quantity. For example, you can use this feature to report a goods return. When you specify a negative
number as the quantity to be delivered, the system assumes that you are performing a reverse fulfillment.
172
P U B LI C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
8.5 Compound Structure Fulfillment
With Revenue Accounting, you can fulfill the compound structure of performance obligations as follows:
● Distribution from high-level performance obligation
● Minimum fulfilment percentage from low-level performance obligation
● Distribution method takes priority over minimum percentage
Note
There is a difference between the reported quantity and the actual quantity. The reported quantity refers to the
fulfilment quantity calculated in the compound structure according to the distribution method, whereas the
actual quantity is the real fulfilment quantity of performance obligations.
8.5.1 Distribution from High-Level Performance Obligation
When you fulfill the compound performance obligation with an event, the fulfillment is distributed to low-level
performance obligations according to the fulfillment percentage of the compound performance obligation.
Example
You have a compound structure that is consist of 1 event-based compound performance obligation and 2
event-based performance obligations. Two goods issues deliver 5 and 2 units of compound performance
obligation in sequence as follows:
Table 128:
Compound Struc
ture
Total Quantity Fulfillment Type Event Type Fulfillment 1 Fulfillment 2
Performance obli
gation 1
10 units Event-Based Goods Issue 5 units 2 units
Performance obli
gation 1.2
10 units Event-Based Goods Issue
Performance obli
gation 1.3
20 units Event-Based Goods Issue
Revenue Accounting calculates fulfillment of the structure by the following steps:
1. Calculate the fulfillment percentage of compound performance obligation with the following formula:
Fulfillment percentage = Fulfillment quantity / Total quantity
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 173
Table 129:
Compound
Structure
Total Quantity Fulfillment 1 Fulfillment Per
centage 1
Fulfillment 2 Fulfillment Per
centage 2
Performance obli
gation 1
10 units 5 units 50% 2 units 20%
Performance obli
gation 1.2
10 units
Performance obli
gation 1.3
20 units
2. Distribute fulfillment percentage of the compound performance obligation to low-level performance
obligations with the following formula:
Fulfillment of low-level performance obligations = Total quantity of low-level performance obligation *
Fulfillment percentage of the high-level performance obligation
Table 130:
Compound
Structure
Total Quantity Fulfillment 1 Fulfillment Per
centage 1
Fulfillment 2 Fulfillment Per
centage 2
Performance obli
gation 1
10 units 5 units 50% 2 units 20%
Performance obli
gation 1.2
10 units 5 units 2 units
Performance obli
gation 1.3
20 units 10 units 4 units
3. Update the fulfillment quantity of each performance obligation.
The first fulfillment quantity is updated as:
Table 131:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 5 units 5 units
Performance obligation 1.2 5 units 0
Performance obligation 1.3 10 units 0
The second fulfillment quantity is updated as shown in the following table:
Table 132:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 2 units 2 units
174 P U B L IC
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1.2 2 units 0
Performance obligation 1.3 4 units 0
8.5.2 Minimum Fulfilment Percentage from Low-Level
Performance Obligation
When you fulfill the low-level performance obligations with events, the fulfillment percentage of each low-level
performance obligation is calculated and the minimum fulfilment percentage is applied to the compound
performance obligation.
Example
You have a compound structure which is consist of 1 event-based compound performance obligation and 2
event-based performance obligations. The first goods issue delivers 2 units of performance obligation 1.2 and 3
units of performance obligation 1.3; the second goods issue only delivers 2 units of performance obligation 1.3
as shown in the following table:
Table 133:
Compound Struc
ture
Total Quantity Fulfillment Type Event Type Fulfillment 1 Fulfillment 2
Performance obli
gation 1
10 units Event-Based Goods Issue
Performance obli
gation 1.2
10 units Event-Based Goods Issue 2 units 0
Performance obli
gation 1.3
20 units Event-Based Goods Issue 3 units 2 units
Revenue Accounting calculates fulfillment of the structure by the following steps:
1. Calculate the fulfilment percentage of low-level performance obligation.
The fulfilment percentage of each low-level performance obligation is calculated as follows:
Low-level performance obligation fulfillment percentage = Cumulative fulfillment / Total quantity of low-
level performance obligation
Table 134:
Compound
Structure
Total Quantity Fulfillment 1 Fulfillment Per
centage 1
Fulfillment 2 Cumulative Per
centage 2
Performance obli
gation 1
10 units
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 175
Compound
Structure
Total Quantity Fulfillment 1 Fulfillment Per
centage 1
Fulfillment 2 Cumulative Per
centage 2
Performance obli
gation 1.2
10 units 2 units 20% 0 20%
Performance obli
gation 1.3
20 units 3 units 15% 2 units 25%
2. Apply the minimum fulfillment percentage to all performance obligations in the structure.
The minimum fulfillment percentage of the low-level performance obligations is used for all performance
obligations in the compound structure. The second fulfillment percentage is calculated as the difference
between the minimum fulfilment percentage of the second event and the first event:
The second fulfillment percentage = Minimum fulfillment percentage of the second event – Minimum
fulfillment percentage of the first event
Table 135:
Compound
Structure
Total Quantity Fulfillment Per
centage 1
Fulfillment 1 Fulfillment Per
centage 2
Fulfillment 2
Performance obli
gation 1
10 units 15% 5%
Performance obli
gation 1.2
10 units 1.5 units 0.5 units
Performance obli
gation 1.3
20 units 3 units 1 unit
3. Update the fulfillment quantity of each performance obligation.
The reported quantity of high-level performance obligation is calculated using the following formula:
High-level performance obligation reported quantity = Total quantity of the high-level performance
obligation * Minimum fulfillment percentage
The first fulfillment quantity is updated as shown in the following table:
Table 136:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 1.5 units 0
Performance obligation 1.2 1.5 units 2 units
Performance obligation 1.3 3 units 3 units
176 P U B L I C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
The second fulfillment quantity is updated as shown in the following table:
Table 137:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 0.5 units 0
Performance obligation 1.2 0.5 units 0
Performance obligation 1.3 1 units 2 units
8.5.3 Distribution Method Takes Priority over the Minimum
Fulfillment Percentage
If you fulfill low-level performance obligations and high-level performance obligation with events in consequence,
the distribution method takes priority over the minimum fulfillment percentage. The result of distribution from
high-level performance obligation overwrites the minimum fulfillment percentage from low-level performance
obligations.
Note
The priority is invalid if the event type of the two-level performance obligations is manual fulfillment and you
want to manually fulfill performance obligations on the UI. In this case, if there is cumulative fulfillment of either
high-level or low-level performance obligations, you can only enter the manual fulfillment for performance
obligations on the UI.
Example
You have a compound structure which is consist of 1 compound performance obligation by percentage of
completion and 2 event-based performance obligations. The first event fulfills 2 units of performance obligation
1.2 and 3 units of performance obligation 1.3. The second event manually fulfills 40% of the compound
performance obligation 1.
Table 138:
Compound Struc
ture
Total Quantity Fulfillment Type Event Type Fulfillment 1 Fulfillment 2
Performance obli
gation 1
1 unit Percentage of
Completion
Manual Fulfillment 40%
Performance obli
gation 1.2
10 units Event-Based Goods Issue 2 units
Performance obli
gation 1.3
20 units Event-Based Goods Issue 3 units
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 177
Revenue Accounting calculates fulfillment of the structure by the following steps:
Event 1
1. Calculate the fulfillment percentage of low-level performance obligations in the first event.
Table 139:
Compound Structure Total Quantity Fulfillment 1 Fulfillment Percentage 1
Performance obligation 1 1 unit
Performance obligation 1.2 10 units 2 units 20%
Performance obligation 1.3 20 units 3 units 15%
2. Apply the minimum fulfillment percentage to all performance obligations in the structure.
Table 140:
Compound Structure Total Quantity Fulfillment 1 Fulfillment Percentage 1
Performance obligation 1 1 unit 15%
Performance obligation 1.2 10 units 1.5 units
Performance obligation 1.3 20 units 3 units
3. Update the fulfillment quantity of each performance obligation in the first event.
The first fulfillment quantity is updated as shown in the following table:
Table 141:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 15% 0
Performance obligation 1.2 1.5 units 2 units
Performance obligation 1.3 3 units 3 units
Event 2
1. Calculate the fulfillment percentage high-level performance obligation in the second event.
Table 142:
Compound Structure Total Quantity Fulfillment 2 Fulfillment Percentage 2
Performance obligation 1 1 unit 40% 40%
Performance obligation 1.2 10 units
Performance obligation 1.3 20 units
2. Distribute fulfillment percentage to low-level performance obligations.
178
P U B LI C
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
As the distribution method takes priority over the minimum fulfillment percentage from low-level
performance obligations, the final fulfillment percentage for the second event is 40% for the compound
structure.
Table 143:
Compound Structure Total Quantity Fulfillment 2 Fulfillment Percentage 2
Performance obligation 1 1 unit 40% 40%
Performance obligation 1.2 10 units 2.5 units
Performance obligation 1.3 20 units 5 units
3. Update the final fulfillment quantity of each performance obligation in the second event. This is the
cumulative fulfillment quantity of event 1 and 2.
The final fulfillment quantity is updated as shown in the following table:
Table 144:
Compound Structure Reported Quantity Actual Quantity
Performance obligation 1 40% 40%
Performance obligation 1.2 2.5 units 0
Performance obligation 1.3 5 units 0
SAP Revenue Accounting and Reporting
Fulfillment of Performance Obligations
P U B LI C 179
9 Invoicing
The back end operational system can transfer customer invoices to the Revenue Accounting system. Invoice
information is used to determine the receivables amount when calculating contract asset and contract liability.
You can also use the invoice information to report a fulfillment event, such as a percentage of completion (PoC)
using event type CI (Customer Invoice). In addition, each invoicing event can modify the revenue accounting
contract. For invoicing and contract modifications, you can refer to Invoicing [page 144] for more information.
SAP Revenue Accounting supports different invoicing scenarios, such as:
● Delivery related invoicing
● Periodic billing plans
● Milestone billing plans.
Simplified Invoice Handling [page 180] presents a specific process for invoicing.
9.1 Simplified Invoice Handling
Use
For some customer groups, such as telecommunications, certain areas of their business are quite uniform in
terms of invoice processing, for example, flat rate contracts. This means that the recurring billing amount is the
same each month. Any changes to the billing amount are usually made by changing the contract.
In contrast to the uniform invoice processing, the revenue accounting engine is designed to consider events for
orders, fulfillments and invoices that are flexible in terms of amount and timing. These events are set up by
different revenue accounting item classes for the different sets of data. However, this also means that a separate
record needs to be stored for each individual event.
For invoice events in particular, this approach may represent a challenge in terms of the volume, as well as the
total cost of implementation if these invoice events cannot be provided by the operational system, such as
through SAP Sales and Distribution or SAP Hybris Billing.
Simplified Invoice Handling allows you to derive the invoice amount from the revenue that is realized from the
consideration to which the entity is entitled − either as part of a fulfillment of an event-based, or a percentage of
completion (PoC) based performance obligation (POB), or as a result of a time-based performance obligation.
This amount of consideration is usually available when you create or change a contract.
Example
The following example illustrates the effects of simplified invoice handling.
In this scenario, you have a contract with 2 performance obligations. POB1 is set up as an event-based
performance obligation with a delivery of 8 units. POB2 is set up as a time-based performance obligation with 2
units provided. After allocation, revenue for POB1 is EUR 625 per unit delivered, and revenue for POB2 is EUR
208.33 per unit and period.
180
P U B LI C
SAP Revenue Accounting and Reporting
Invoicing
The table below shows the price allocation after an order has been created.
Table 145:
Quantity Transaction
Price
Total Price SSP SSP Total Allocated
Amount
Allocation
Effect
Revenue Per
Unit/Period
8 EUR
1,000.00
EUR
8,000.00
EUR 50.00 EUR 400.00 EUR
5,000.00
- EUR
3,000.00
EUR 625.00
2 EUR
1,000.00
EUR
2,000.00
EUR 200.00 EUR 400.00 EUR
5,000.00
+ EUR
3,000.00
EUR 208.33
10 EUR
10,000.00
EUR 800.00 EUR
10,000.00
The overall revenue for the contract in period 1 is EUR 1,666.67.
For receivables, the system uses the corresponding consideration which is EUR 1,000 per unit for POB1 and
EUR 83.33 per unit and period (EUR 2,000/2 units/12 periods) for POB2.
In simplified invoice handling, the system derives the relevant receivables amount from the main price
conditions. This means that the overall receivables amount for period 1 is assumed to be EUR 2,166.67.
Table 146:
First Period
Quantity Delivered POB1 2
POB2 2
Revenue Recognized POB1 EUR 1,250.00
POB2 EUR 416.67
Total EUR 1,666.67
Receivables POB1 EUR 2,000.00
POB2 EUR 166.67
Total EUR 2,166.67
Contract Liability - EUR 500.00
Prerequisites
The field SIMPLIFY_INVOICE has been added to interface components and standard order revenue accounting
item classes to indicate whether you need to apply Simplified Invoice Handling to a performance obligation.
SAP Revenue Accounting and Reporting
Invoicing
P U B LI C 181
Features
Certain performance obligations of a contract may be flagged for simplified invoice handling. For example, a time-
based performance obligation for a flat rate service, versus other performance obligations within this contract
that are not flagged. This is known as a mixed scenario.
Note
The indicator can be displayed on the performance obligation attributes. However, once the indicator has been
set, you can no longer change it.
The sender component has to provide the attribute for simplified invoice handling in the order revenue accounting
item. This means that the indicator is available at the raw, raw exceptions, processable, processable exceptions
and processed RAIs (RAI0, RAI1, RAI2, RAI3 and RAI4) levels.
Only the sender component can provide the indicator. It cannot be set, nor changed, via any method other than
the sender component. That means that using BRFplus or configuring the performance obligation type, or
changes on the performance obligation user interface, are not supported.
You can use the simplified invoice handling feature for event-based, time-based, and percentage of completion-
based performance obligations. If the feature is used for a performance obligation, you will receive order revenue
accounting items, and (if configured) fulfillment revenue accounting items for this performance obligation, but no
invoice revenue accounting items.
Note
Revenue accounting item processing will reject any invoice revenue accounting items for performance
obligations that are flagged for simplified invoice handling.
Note
You cannot edit the contracts from the error worklist, as you can do in other error scenarios.
An invalid revenue accounting item can be moved to RAI1/RAI3 status which can then be archived.
As invoice revenue accounting items are not processed, credit memos and debit memos are also not processed.
The system prevents performance obligations of event type Customer Invoice (CI) from being flagged for
simplified invoice handling. Vice versa, the system prevents you from setting the performance obligation to
Customer Invoice if the performance obligation is already flagged for simplified invoice handling.
Simplified invoices are allowed for a bill of material but all performance obligations of a bill of material must have
the same flag value (so either all, or none, work with Simplified Invoice Handling). The system checks if the
Simplified Invoice flag has been set by the sender component for all of the items in a bill of material structure.
Note
Simplified invoices are also allowed for performance obligations of a compound group.
The system prevents a right of return (ROR) if such a performance obligation has been flagged for simplified
invoice handling. This means that when a right of return is defined, the revenue on the performance obligation is
deducted and the invoice amount is equal to the revenue amount.
182
P U B LI C
SAP Revenue Accounting and Reporting
Invoicing
If a performance obligation is processed with the simplified invoice handling, it cannot have a finalization date.
As a contract has been created and a performance obligation has been modified (for example, a change in service,
reallocation, or early termination), the system will update the corresponding invoice lines.
Example
Following the above example, a contract modification is triggered in period 2 with a new target quantity of 20
units for POB1.
If there is a contract modification, the system calculates the following:
Effective Remaining Price as Total Transaction Price minus Realized Revenue
= EUR 20,000 – EUR 1,250 = EUR 1,875.00 for POB1
= EUR 2,000 – EUR 416.67 = EUR 1,583.30 for POB2
Effective Remaining Standalone Selling Price (SSP) as Total SSP * (1 fulfilled)
= EUR 1,000 - (1-(2/20) = EUR 900 for POB1
= EUR 400 - (1-(1/12) = EUR 366.67 for POB2
Effective Remaining Amount
(EUR 900/EUR 1,266.67) * EUR 20,333.33 = EUR 14,447.37
(EUR 366.67/EUR 1,266.67) * EUR 20,333.33 = EUR 5,885.96
Allocated amount as Effective Remaining allocated Price + Revenue Recognised
EUR 14,447.37 + EUR 1,250 = EUR 15,697.37
EUR 5,885.96 + EUR 416.67 = EUR 6,302.63
Table 147:
Quantity Transac
tion
Price
Total
Price
SSP SSP To
tal
Allo
cated
Amount
Alloca
tion Ef
fect
Effective
Remain
ing Price
Effective
Remain
ing SSP
Effective
Remain
ing
Amount
Revenue
Per
Unit/
Period
20 EUR
1,000.00
EUR
20,000.
00
EUR
50.00
EUR
1,000.00
EUR
15,697.3
7
- EUR
4,302.63
EUR
18,750.0
0
EUR
900.00
EUR
14,447.3
7
EUR
802.63
2 EUR
1,000.00
EUR
2,000.0
0
EUR
200.00
EUR
400.00
EUR
6,302.63
+ EUR
4,302.63
EUR
1,583.00
EUR
366.67
EUR
5,885.96
EUR
535.09
22 EUR
22,000.0
0
EUR
1,400.00
EUR
22,000.0
0
EUR
20,333.3
3
EUR
1,266.67
EUR
20,333.3
3
SAP Revenue Accounting and Reporting
Invoicing
P U B LI C 183
As the consideration that the entity is entitled to has not changed, the invoice amount assumed will also not
change. In this instance, receivables is EUR 10,000 for POB1 with a further delivery of 10 units:
Table 148:
First Period Second Period
Quantity Delivered POB1 2 10
POB2 2
Revenue Recognized POB1 EUR 1,250.00 EUR 8,026.32
POB2 EUR 416.67 EUR 535.09
Total EUR 1,666.67 EUR 8,561.40
Receivables POB1 EUR 2,000.00 EUR 10,000.00
POB2 EUR 166.67 EUR 166.67
Total EUR 2,166.67 EUR 10,166.67
Contract Liability - EUR 500.00 - EUR 1,605.26
Note
Initial load and transition are not currently supported for simplified invoice handling.
Activities
The functionality covers the following areas:
1. The system allows you to set up a performance obligation for simplified invoice handling whereby a contract
can hold performance obligations that are flagged for this special procedure, as well as performance
obligations that follow the normal procedure.
2. The system allows you to derive the invoice amount from the revenue. This is triggered when you create or
change a performance obligation that is flagged for simplified invoice handling, without having to upload an
invoice revenue accounting item (RAI). This is the amount resulting from the main price condition for a
performance obligation.
Note
Revenue Accounting allows you to individually report the revenue resulting from the main consideration
that is invoiced to the customer and the revenue from the allocation effect. For simplified invoice handling,
the invoiced amount is derived from the revenue resulting from the main price condition.
3. The system calculates contract liability and contract asset without the need for existing invoice revenue
accounting items to reflect the receivables part.
184
P U B LI C
SAP Revenue Accounting and Reporting
Invoicing
4. When you transfer revenue with the corresponding program, the system uses the current currency
translation.
5. Although the contract shows that invoice information exists, the reconciliation between the revenue
accounting items and contracts assumes that no invoice revenue accounting items exist for certain
performance obligations.
6. Reporting uses invoice information.
SAP Revenue Accounting and Reporting
Invoicing
P U B LI C 185
10 Integration with Cost Object Controlling
Use
With Integration with Cost Object Controlling, you can transfer revenue that is calculated in revenue accounting
for controlling objects which are then processed in results analysis. You can also transfer the percentage of
completion to revenue accounting.
These objects are account assignments in a sales order item. They are assigned to a results analysis key and can
be any of the following:
● a work breakdown structure element
● a sales order (make-to-order)
● an internal order.
Results analysis selects the actual and planned costs, as well as the revenues, which have been posted on the
controlling object and calculates the valuated revenues, the work in progress, and the cost of sales, among other
categories. The calculations depend on the Customizing of the valuation method in results analysis. Settlement
then settles these calculated values, not the actual costs and revenues.
There are two integration scenarios with a different sequence of activities in results analysis and revenue
accounting. This is documented by a new performance obligation attribute called Integration Type with Results
Analysis:
1. A percentage of completion is used as a valuation method in results analysis, as follows:
1. Perform the results analysis which transfers a percentage of completion to revenue accounting. The
valuated revenues, cost of sales, work in progress, and so on, are also calculated and posted. You can
identify each line item by business transaction KABG.
2. Perform a posting run in revenue accounting. This will post actual revenue adjustments in controlling and
automatically update the valuated revenues for results analysis. The adjustment for the valuated
revenues is posted. You can identify each line item by business transaction KABE.
3. Perform a settlement.
2. A revenue-based valuation method is used in results analysis, as follows:
1. Perform a posting run in revenue accounting. This will post actual revenue adjustments in controlling.
2. Perform the results analysis. All actual revenues, that is, standard invoices and revenue adjustments from
revenue accounting, are taken into account for the valuated revenues. All valuated revenues are posted.
You can identify each line item by business transaction KABG.
3. Perform a settlement.
Note
Revenue accounting manages revenues and posts revenue to FI; Results analysis manages costs and receives
revenue from revenue accounting; Results analysis posts costs, work in progress and reserves to FI, and costs
and revenues to CO-PA for the results analysis version that is relevant for settlement (usually version 0).
186
P U B LI C
SAP Revenue Accounting and Reporting
Integration with Cost Object Controlling
Note
Percentage of completion can be either a cost-based percentage of completion or a completed contract.
Prerequisites
You have maintained the following Customizing activities in Revenue Accounting under Financial Accounting
(New) Revenue Accounting Integration with Cost Object Controlling :
Assign RA version and currency type to company code and acct. principle.
Specify RA keys and RA versions that will integrate with revenue acct.
You have also maintained the following activities in Customizing:
Under the Revenue Accounting Administrator role: BRF plus Workbench Function FC_PROCESS_COMPOUND
Where Used Ruleset Change ET_COMPOUND_GRP_BRF after processing expression
DT_PROCESS_COMPOUND , you can define the compound group in Business Rule Framework plus which
contains all performance obligations that relate to the same controlling object and receive the same percentage of
completion. This is necessary if revenues are allocated to other performance obligations from this compound
group.
You can define the performance obligation types in Business Rule Framework plus in Customizing: Financial
Accounting (New)
Revenue Accounting Revenue Accounting Contracts Define Performance Obligation
Types . Ensure that the event type Manual Fulfill is set and that Cost Recognition is switched off for the
performance obligations that receive a percentage of completion.
In results analysis, you can define new rules for the percentage of completion calculation, if required for the new
accounting principle.
In results analysis, you can define the new results analysis version: Controlling Product Cost Controlling
Cost Object Controlling Product Cost by Period Period-End Closing Work in Process Define Results
Analysis Versions
, if the parallel accounting principle will be supported.
In results analysis, you can define the line item IDs so that revenue is not posted by results analysis: Controlling
Product Cost Controlling Cost Object Controlling Product Cost by Period Period-End Closing Work in
Process
Define Line IDs
● For percentage of completion methods: the cost elements (accounts), which are used for the revenue
correction postings (revenue adjustments), must be assigned to a separate line item ID using category 'R'.
● For revenue-based methods: all cost elements for revenues, including revenue adjustments from revenue
accounting, must be assigned to line item IDs using category 'E'.
● For existing sales order items: Perform migration for sales order items that relate to results analysis keys
which are relevant for revenue accounting.
SAP Revenue Accounting and Reporting
Integration with Cost Object Controlling
P U B LI C 187
Features
Results analysis keys can be marked as relevant for revenue accounting.
Revenue corrections, which are calculated in revenue accounting, are transferred to controlling objects which
have a matching results analysis key.
A percentage of completion is transferred to revenue accounting during the results analysis for controlling objects
that have a suitable integration method in the results analysis key. The percentage of completion can be changed
manually in revenue accounting.
Compound groups can be defined in Business Rule Framework plus for performance obligations that receive a
percentage of completion from results analysis. Additional performance obligations, that receive the same
percentage of completion, can be assigned to the compound group. The assigned controlling object, which has a
percentage of completion, must be unique within a compound group. You can use the new performance obligation
attributes, the controlling object number, and the integration method to define the compound group.
Operational load and transition are supported. For sales order items with results analysis keys that are relevant
for the percentage of completion, the operational load follows a specific logic. While for sales order items with
revenue-based results analysis keys, the general logic applies.
Note
Sales order items in a bill of material, which contain a controlling object that is integrated with cost object
controlling, are only transferred to revenue accounting if they are relevant for billing and delivery. The bill of
material hierarchy is ignored by revenue accounting in this case.
Linked performance obligations are not allowed for performance obligations that are integrated with cost
object controlling.
Only results analysis keys with a percentage of completion can be assigned to integration method 1 (which
transfers the percentage of completion to revenue accounting).
The calculation of imminent loss in results analysis is not changed as a result of this integration.
If you use an accounts approach, the revenue adjustment account of only one accounting principle (which is
the leading accounting principle) can be defined as the cost element (except when business function FIN-CO-
COGM is active).
If you use a ledger approach, only the revenue postings to the leading ledger update the controlling version 000
and the related results analysis version (except when business function FIN-CO-COGM is active).
188
P U B LI C
SAP Revenue Accounting and Reporting
Integration with Cost Object Controlling
11 Revenue Posting
Revenue Posting details how to enable revenue postings, the features available to you, and the accounting tasks
that you can perform for revenue postings.
Use
The Revenue Accounting system manages revenue recognition by using objects such as revenue accounting
contracts and performance obligations. The system receives events that relate to revenue recognition and tracks
the fulfillment of performance obligations. However, revenue postings are not made at the times of those events.
The accountant performs revenue posting jobs regularly to post FI documents to the general ledger. Before the
postings are made, the accountant can choose to calculate time-based revenue, contract liabilities, and contract
assets. For example, after calculating time-based revenue, contract liabilities, and contract assets, the accountant
can perform a revenue posting run at the end of each accounting period to transfer revenue recognition
transactions to the general ledger.
Prerequisites
To enable revenue postings, you need to perform the following Customizing activities:
● You have defined accounting principles and enabled company codes for Revenue Accounting.
Choose Financial Accounting Revenue Accounting Revenue Accounting Contracts Configure
Accounting Principle-Specific Settings .
● You have configured parallel processing for the posting of revenue.
Choose Financial Accounting Revenue Accounting Revenue Accounting Postings Configure Parallel
Processing for Revenue Posting
.
● You have defined the transfer account, posting keys, document type, and account assignments.
Choose Financial Accounting Revenue Accounting Revenue Accounting Postings Define Posting
Specifications for General Ledger Transfer
.
Note
Unless otherwise specified in this Customizing activity, the system uses SA as the document type, 40 as
the debit posting key, and 50 as the credit posting key, by default.
● You have configured account determination.
Choose Financial Accounting Revenue Accounting Revenue Accounting Postings Configure Account
Determination for Specific Transactions .
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 189
Features
Revenue posting in three steps
You can perform a revenue posting in three steps:
● Calculate time-based revenue
● Calculate contract liabilities and contract assets
● Perform revenue posting run
Before you make actual postings, you need to calculate all data and transfer it to a posting table, which can be
regarded as a subledger in the accounting engine. You can also calculate and transfer time-based revenue,
contract liabilities, and contract assets separately.
Posting by accounting period
You can post revenue for one accounting period at a time. Before the posting, you must make sure that the period
is Open or In Closing.
Posting for individual contracts
In each of the three programs for revenue posting, you can select individual revenue accounting contracts for
processing.
Simulation mode
The system allows you to simulate a posting job in simulation mode. You can use the simulated results to verify
the account determination, account assignments, debit/credit side, and posting amounts.
In simulation mode, the system performs some basic checks. For example, the system checks whether the
selected company codes exist in the simulation mode. However, it does not check against issues that can only be
detected while the job is running. The simulation result can be displayed by account, performance obligations, or
posting.
Test mode
The system allows you to test postings in background jobs to detect any possible posting errors. You can specify
the company code, accounting principle, fiscal year, posting period, revenue accounting contract, and
performance obligation to perform the testing.
Choose Revenue Posting Run Revenue Posting Run Run Mode Test Only
Running as background jobs
The system can run three background jobs:
● Calculation of time-based revenue
● Calculation contract liabilities and contract assets
● Revenue posting run
After the jobs have been completed, the job monitor displays the results of the three jobs to indicate whether they
have been successful.
You can monitor the status of the three jobs, such as the run ID, planned start date/time, start date/time, and end
date/time. The results of posting jobs can be displayed with different statuses, such as in process, scheduled,
canceled, and finished. Also, the results can be sorted by category: time-based revenue calculation, contract
liabilities and contract assets calculation, revenue posting, and reverse posting. You can view the job details of the
posting jobs, such as the application log, search criteria, and message list.
190
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
Posting optimization
To avoid a system dump when the data volume is overwhelmingly large, the system can optimize posting by
dividing the data into batches. You can enable the posting optimization in the following Customizing activity:
Choose Financial Accounting Revenue Accounting Revenue Accounting Postings Switch on Posting
Optimization
Scheduling
To run the posting job once, you can schedule it to run either immediately or at a specified time, using the options
provided in the revenue posting user interfaces. For a scheduled posting job, the system performs basic checks
on your posting options to prevent you from running a job that will eventually fail. However, it does not check
against issues that can only be detected while the job is running.
The revenue posting user interfaces do not provide options for you to schedule a recurring job. However, the three
programs for revenue posting are all available in ABAP programs. The ABAP programs provide more flexibility,
and you can schedule recurring jobs for these ABAP programs by using the ABAP built-in scheduling framework.
For more information, see Start a Revenue Posting Run [page 200].
Specifying a posting date
You are prompted to specify a posting date for the posting job. The specified date must fall in the accounting
period.
Posting check
When you start a revenue posting job, the system checks all selected contracts one by one and then performs
revenue postings. The contracts that are posted successfully are entered into the general ledger, while the
contracts with errors are skipped.
Supporting General Ledger Accounting (New)
If you have activated General Ledger Accounting (new), all postings are made to the relevant ledger group,
depending on the accounting principle.
Line item aggregation and splitting
To reduce the total number of line items in the posted documents, the system aggregates the line items using a
combination of several fields, such as the G/L account, account assignment attributes, and condition type.
Therefore, any line items that have identical values for all of these fields are merged into one line item.
In some rare scenarios, the amount of a single line item exceeds 99,999,999,999. In this case, the system splits
the line item into several line items.
FI document splitting
Typically, the system creates one FI document for each posting job. However, the system splits the document into
several documents in the following scenarios:
● More than 900 line items are to be included.
● The transactions to be posted involve different document currencies.
Including account assignment data
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 191
You can include account assignment data (segment, profit center, business area, and functional area) in FI
documents posted to the general ledger. This can be customized at company code level in the following
Customizing activity:
Choose Financial Accounting Revenue Accounting Revenue Accounting Postings Define Posting
Specifications for General Ledger Transfer .
Reversal
You can reverse the postings made by a previous revenue posting job. Since the reversal is based on the Run ID,
which is generated based on a whole revenue posting, you will reverse all of the posted contracts in the previous
revenue posting job.
Navigating to the original document from the FI document
The revenue posting will aggregate the contracts and performance obligation line items that are to be posted into
one general ledger document. The “Original Document” from the revenue postings is a group of revenue contracts
and performance obligations. The report FI Documents: By Contract can display the group situation of revenue
contracts and performance obligations from the Revenue Posting Run.
You can now view the original documents. The system will navigate to the report FI Documents: By Contract. The
related company code, accounting principle, fiscal year, posting period and general ledger document number will
be transported to the selection criteria of the report and the report is executed automatically.
In the transaction for Display FI Document: FB03, choose Environment Document Environment Original
Document
Reconciliation key
The system allows you to generate a reconciliation key at contract level so that revenue can be posted at various
levels of granularity. You can use a reconciliation key to reconcile postings between the general ledger and
revenue accounting. For example, you can post revenue to the general ledger from revenue accounting using a
reconciliation key.
The reconciliation key consists of 14 digits that represent the fiscal year (4 digits), posting period (3 digits), and
series number (7 digits). It has the following statuses:
● M (Migration) This status can only be used in migration.
● O (Open) This status is used to mark any action in revenue accounting, such as creating a contract, fulfilling a
performance obligation, and combining contracts.
● P (Transferred) This status is used when the Transfer Revenue program has been executed.
● F (Failed) This status is used when the system fails to post entries to FI.
● C (Closed) This status is used when the revenue posting program has been performed successfully.
● S (Simulation) This status is used when the posting simulation has been performed.
● A (Canceled) This status is used when a posting has been reversed.
● R (Replaced) This status is used when contracts have been shifted to the next period.
Note
The status R can only be requested when a posting fails.
192
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
Activities
You can perform the following accounting tasks:
● Schedule a revenue posting job to run immediately
● Schedule a revenue posting job to run later
● Simulate a revenue posting job
● Monitor the statuses of revenue posting jobs and tasks
● Review the results of revenue posting jobs
● View the posted documents of a revenue posting job
● Reverse the postings made by a previous revenue posting job
11.1 Revenue Posting in Three Steps
The general task of revenue posting is divided into three steps. The accountant runs three separate programs to
perform these steps.
Table 149:
Program Name Description Frequency Simulation Available Granularity
Transfer Revenue This program prepares
the data required for a
subsequent revenue
posting run. The pro
gram processes trans
actions and events that
occurred for perform
ance obligations and
calculates revenue for
performance obliga
tions. Before an actual
revenue posting run is
performed, this pro
gram calculates and
transfers all revenue
for performance obliga
tions to a posting table,
which is regarded as a
subledger in the reve
nue accounting engine.
Usually daily, depend
ing on data volume.
You can schedule a re
curring job for this task.
No You can select specific
revenue accounting
contracts.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 193
Program Name Description Frequency Simulation Available Granularity
Calculate Contract
Liabilities and Assets
This program prepares
the data required for a
subsequent revenue
posting run. The pro
gram calculates con
tract liabilities and con
tract assets. The con
tract liabilities and as
sets to be posted are
pre-staged in the post
ing table in the Revenue
Accounting component
so that they can be
transferred to the tar
get ledgers in a revenue
posting run.
Usually daily, depend
ing on data volume.
You can schedule a re
curring job for this task.
No You can select specific
revenue accounting
contracts.
Revenue Posting Run This program transfers
revenue postings to the
general ledger and
other corresponding
ledgers.
Regularly. For example,
at the end of the period.
Attention always needs
to be paid to data vol
ume.
Yes. Among other
search criteria, the user
can select specific con
tracts to simulate.
You can select specific
revenue accounting
contracts.
Background Programs
In addition to the Web interfaces available in the NetWeaver Business Client, the three steps can also be
performed using ABAP programs and assigned with transaction codes. The ABAP programs provide the same
functions as in the Web interfaces, providing technical users with more flexibility. The following table lists the
details:
Table 150:
Program Name ABAP Program Transaction Code
Transfer Revenue
FARR_REV_TRANSFER FARR_REV_TRANSFER
Calculate Contract Liabilities and Assets
FARR_CONTRACT_LIABILITY FARR_LIABILITY_CALC
Revenue Posting Run
FARR_REVENUE_POSTING FARR_REV_POST
194 P U BL I C
SAP Revenue Accounting and Reporting
Revenue Posting
11.2 Transfer Revenue
With the Transfer Revenue program, you can transfer revenue and cost to the revenue accounting subledger.
Use
You can transfer revenue and cost to the revenue accounting subledger, and also calculate the exchange rate
difference from the foreign currency revaluation which generates invoice records from the simplify invoice
process.
This program must be run before the revenue posting run.
Note
Transfer Revenue performs a check, while the program is running, before transferring revenue and cost to the
revenue accounting subledger.
● If the system is in Production mode, the program cannot run for future periods.
● If the accounting principle is configured so that the foreign currency is revaluated at the actual rate, the
program is run period by period.
Note
For revenue contracts that are processed using simplify invoice handling, this program generates invoice
records and transfers invoice correction postings to the revenue accounting subledger.
Activities
You can run this program manually, if necessary. For example, if you need to make an urgent contract change,
you can transfer revenue immediately. You can also schedule a background job periodically and define the
recurrence according to your business needs and data volume.
11.3 Calculation and Distribution of Contract Liability/Asset
or Unbilled Receivable/Deferred Revenue
Revenue Accounting can calculate contract liability and contract asset, or unbillable receivables and deferred
revenue at performance obligation level. The calculation result can be posted either at performance obligation, or
contract level. If contract liability and contract asset have been aggregated at contract level, you can also
distribute them at performance obligation level by implementing a BAdI.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 195
11.3.1 Calculating Contract Liability and Contract Asset
Revenue Accounting can calculate contract liability and contract asset in the back end system.
Use
Revenue Accounting can calculate the following two combinations in the back end system:
● Contract liability and contract asset
● Unbillable receivable and deferred revenue
Contract Liability: If a customer pays consideration, or an amount of consideration is due before a company
transfers goods or services, the entity presents the contract as a contract liability. A contract liability is an entity’s
obligation to transfer goods or services to a customer for which the entity has received consideration from the
customer.
Contract Asset: If a company transfers goods or services to a customer before the customer pays consideration,
the entity presents the contract as either a contract asset or as a receivable, depending on the nature of the
entity’s right to consideration for its performance.
Contract liability and contract asset are required by the International Financial Reporting Standard (IFRS 15).
Nevertheless, customers may also need to disclose and post the following accounts for local GAAP requirements,
such as GAAP:
Unbilled Revenue: This revenue has been recognized but has not yet been billed. The difference between unbilled
revenue and contract asset is that the unbilled revenue calculation always compares the invoiced amount with the
revenue, while the contract asset calculation compares the billable amount with the revenue.
Deferred Revenue: The invoice amount has been issued to the customer but cannot be recognized as revenue.
The difference between the deferred revenue and contract liability is that the contract liability compares the
invoiced due amount with the revenue, while the deferred revenue compares the invoice amount with the revenue.
Contract liability and contract asset are calculated when you apply the invoice due date. Unbillable receivable and
deferred revenue are calculated when you apply the invoice date. You can configure this setting in the following
Customizing activity:
Choose Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Configure
Accounting Principle-specific Settings .
Features
● Fixed Rate
This program provides the BAdI Distributing Contract Liability and Contract Asset (Unbilled Receivable and
Deferred Revenue) [page 198] with contract liability and contract asset which is posted at performance
obligation level. The revenue amount, billable amount and invoice amount of each performance obligation is
distributed.
196
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
The local amount is determined by the exchange rate of the first event, that is, the fulfillment or invoice. The
formula is:
Local amount of CL/CA or UR/DR = Transaction amount of CL/CA or UR/DR * fixed
foreign rate
● Actual Rate
For foreign currency handling with the actual rate, you use the BAdI Distributing Invoices at Performance
Obligation Level [page 288] for invoice distribution to distribute the contract liability and contract asset.
Activities
The calculation is performed at performance obligation level.
1. Calculate the balance of the contract liabilities and contract assets for each performance obligation,
according to the following formulas:
Contract Liability/Contract Asset
○ Contract Liability = Max {(Payment Due - Fulfilled Revenue), 0}
○ Contract Asset = Max {(Fulfilled Revenue - Receivable), 0}
○ Receivable = Max {Billable Amount, Invoice Due Amount}
○ Billable Amount = Original Amount * Fulfillment Revenue/Total Allocated Revenue
Unbilled Revenue/Deferred Revenue
○ Unbilled Revenue Per Performance Obligation = Max {(Recognized Revenue –
Invoiced Amount), 0}
○ Deferred Revenue Per Performance Obligation = Max {(Invoiced Amount – Recognized
Revenue), 0}
2. Calculate the balance of the contract liabilities and contract assets for each performance obligation and
transfer the amount of contract liabilities and contract assets to be posted to contract level.
3. Specify where the amount of contract liabilities and contract assets is to be posted at contract level or
performance obligation level by reading the configuration.
If you configure the system to post at contract level, this program will calculate the net balance of the contract
liability and contract assets calculated in Step 2, and it becomes the posted amount for contract liability and
contract assets.
If you configure the system to post at performance obligation level, this program behaves according to the
foreign currency calculation methods.
Restrictions
1. Calculate Contract Liability and Contract Asset cannot run in a future period in the productive system.
In the productive system, which relies on the system’s configuration (not Revenue Accounting configuration),
Calculate Contract Liability and Contract Asset must be run in the current period.
Example
If the current period is 02/2017, an error message will appear if you have entered a period and
corresponding date that is later than 02/2017. This restriction is only applied in productive systems. This
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 197
means that you can run Calculate Contract Liability and Contract Asset for a future period in testing and
development systems.
2. Actual rate contracts, which are handled by fixed rate contracts, must be processed period by period.
Calculate Contract Liability and Contract Asset filters out unqualified fixed rate contracts and displays an error
message. If you have assigned both actual rate and fixed rate contracts, assuming that all other checks, for
example there is a valid company code, have been completed, all actual rate contracts and fixed rate
contracts that do not have uncalculated contract liability or contract asset in the previous periods will be
processed.
3. If you have uploaded contracts from the legacy system in the same period, you must set the period to In-
Closing or Open in FARR_IMG.
Example
If you first launch the system and upload contracts from the legacy system in December, you must set the
December period to In-Closing if all related contracts are Migration contracts, or to Open if it contains non-
migration contracts.
Note
You can set any month as the open period for Revenue Accounting.
4. If you have revenue contracts from the legacy system in the current period, you have to set the revenue
accounting period to In-Closing or Open in FARR_IMG.
Example
December is the current revenue accounting period. If you upload revenue contracts from the legacy
system and there are no newly created revenue contracts in December, you have to set the revenue
accounting period for December to In-Closing. If you upload revenue contracts from the legacy system and
also create new revenue contracts in December, you have to set the revenue accounting period for
December to Open.
11.3.2 Distributing Contract Liability and Asset (Unbilled
Receivable and Deferred Revenue) to Performance
Obligation Level
The calculation result of contract liability and asset (unbilled receivable and deferred revenue) can be posted
either at performance obligation or contract level. You can configure the setting in the following Customizing
activity:
Choose Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Configure
Accounting Principle-specific Settings
.
If contract liability and asset (unbilled receivable and deferred revenue) are to be posted at contract level, the
system sums up contract liability and asset (unbilled receivable and deferred revenue) of all performance
obligations in the contract.
198
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
If contract liability and asset (unbilled receivable and deferred revenue) are to be posted at performance
obligation level, you can redistribute them by implementing BAdI: Distributing Contr. Liab./Ass. and Deferred/
Unbilled into POB level.
Note
Contract liability and asset (unbilled receivable and deferred revenue) will not be distributed to performance
obligations that meet the following condition:
● These performance obligation is not the source of prices. Usually these performance obligations sum up
prices of their lower level performance obligations instead of having their own prices.
● These performance obligation is a header performance obligation or non-district performance obligation.
Distribute contract liability and asset
By default, the BAdI distributes contract liability and asset as follows:
Step 1: The system sums up contract liability and asset of all performance obligations to contract level.
Step 2: The system redistributes contract liability and asset to performance obligation level in proportion to each
standalone selling price.
Example
There are four performance obligations in a contract, performance obligation 1, 2, 3, and 4.
Table 151:
POB SSP
POB 1 EUR 700
POB 2 EUR 200
POB 3 EUR 400
POB 4 EUR 300
Note
In the table, POB refers to performance obligation and SSP to Standalone Selling Price.
Contract liability of POB 1= Contract liability of the contract*700 / (700+200+400+300)
Contract asset of POB 1= Contract asset of the contract*700 / (700+200+400+300)
Distributes unbilled receivable and deferred revenue
By default, the BAdI distributes unbilled receivable and deferred revenue as follows:
Step 1: The system divides all performance obligations into the following two types:
● Sending type
For a performance obligations of this type, its allocated price is less than transactional price.
● Receiving type
For a performance obligation of this type, its allocated price is more than transaction price.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 199
Step 2: Invoices of sending type performance obligations are split to the following two parts:
● Retained invoice value
Retained invoice amount = invoice * allocated amount / transaction amount
● Distributed invoice value
Distributed invoice = invoice - retained invoice
Step 3: Distributed invoice value is added to receiving type performance obligations. If there are several receiving
performance obligations, distributed invoice amount is added to each receiving performance obligation in
proportion to their respective allocation effect.
Step 4: The system uses reallocated revenue and invoice to calculate contract liability and asset at performance
obligation level.
Example
There are four performance obligations in a contract. Performance obligation 1 and 2 are sending performance
obligations; performance obligation 3 and 4 are receiving performance obligations.
Table 152:
POB Transaction
Amount
SSP Allocated
Amount
Invoice
Amount
Retained In
voice
Distributed
Invoice
Reassigned
Invoice
Sending
POBs
POB 1 EUR 1000 EUR 700 EUR 700 EUR 70 EUR
49=70*700
/1000
EUR 21 EUR
49=70-21
POB2 EUR 200 EUR 200 EUR 200 EUR 20 EUR 20 0 EUR 20
Receiving
POBs
POB 3 EUR 200 EUR 400 EUR 400 EUR 30 EUR
44=30+21*
200/
(200+100)
POB4 EUR 200 EUR 300 EUR 300 EUR 40 EUR
47=40+21*
100/
(200+100)
11.4 Start a Revenue Posting Run
Procedure
1. In the NetWeaver Business Client, select a role that allows you to perform revenue accounting tasks.
200
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
2. Choose Revenue Posting Run Revenue Posting Run .
3. If you want to simulate posting jobs before making any actual postings, you can perform the simulation with
data in the Company Code, Accounting Principle, Fiscal Year, Posting Period, Revenue Accounting Contract,
and Obligation Performance fields. You can display the results using the options By Account, By Performance
Obligations, or By Posting.
Note
○ With the By Account option, you can display simulated data by general ledger account.
○ With the By Performance Obligations option, you can display simulated results by revenue accounting
contract and performance obligation.
○ With the By Posting option, you can display simulated results by posting pair（debit and credit）.
4. Choose Switch to Posting Mode to switch to the posting mode
5. Enter the company codes for which you want to perform revenue postings.
Note
○ You can add additional search criteria to select multiple company codes.
○ You can also select a range of company codes. The system interprets ranges of company codes on an
alphanumeric basis. For example, if you use the Is Between operator and enter A000 and A099, the
posting job includes company codes A000 through A099.
6. Enter a fiscal year and a posting period. You can perform revenue postings for only one period at a time. Make
sure that the revenue accounting period is set to Open or In Closing.
7. Enter a fiscal year and a posting period. Make sure that the revenue accounting period that you enter is set to
Open or In Closing. You can perform revenue postings for only one period at a time.
8. You can use the Contract search criterion to specify the contracts for which you want to make revenue
postings.
9. When the Posting Check indicator is selected, the program checks the contracts one by one to verify whether
it's possible to make a successful a revenue posting for that contract. If a contract fails the check, that
contract is skipped in the actual postings. When the Posting Check indicator is not selected and a contract
fails the check, all the contracts are skipped in the actual postings.
Note
As Posting Check checks the contracts one by one, the performance of the revenue posting is impacted.
10. To close the revenue accounting period once the posting is complete, select the Close Period for Rev option.
You can refer to Revenue Accounting Close [page 216] for more information.
11. In the Job Name text box, enter a job name that describes the current posting job.
12. Enter a posting date. The posting date must fall in the posting period that you have selected.
13. By using the Posting Mode setting, you can choose either to perform the actual posting or to just simulate the
posting.
Note
If you choose the Test Only option, the system simulates the posting to detect any possible posting errors
in a background job. You can view the result of the test in the job monitor. The result includes posting
errors and the reasons for them. However, if you want to review and check the result of the revenue posting
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 201
with the line items that are to be posted, you have to choose Switch to Simulation Mode and run a
simulation on the same screen.
As the simulation mode is run online, the user interface session may time out and the simulation may fail if
the simulation posting involves large volumes of data. You can enter reasonable selection criteria before
you run the simulation to ensure that the result is readable.
14. To execute the run immediately, choose Schedule to Start Immediately.
15. The Number of Intervals option is a technical parameter that controls the parallel processing of the posting
job. In most scenarios, you can leave the default value unchanged.
Note
This setting allocates the number of parallel jobs that the system runs to perform revenue postings. For
systems that have large numbers of processing units, you can increase the value to improve the
performance.
16. Choose Post.
Results
Default Aggregation Method
During the general ledger posting, the posted line items that are detailed in the revenue accounting subledger are
aggregated based on account assignments. If all fields listed below have the same value, the general ledger
posting lines are aggregated during the revenue posting. If one of these fields has a different value, line items that
are posted are not aggregated.
Table 153:
Field Name Data Element Short Description
COMPANY_CODE BUKRS Company Code
ACCT_PRINCIPLE ACCOUNTING_PRINCIPLE Accounting Principle
POST_CAT FARR_POST_CATEGORY Category for Posting Document
SHKZG SHKZG Debit/Credit Indicator
GJAHR GJAHR Fiscal Year
POPER POPER Posting period
WAERS WAERS Currency Key
HWAER HWAER Local Currency
HWAE2 HWAE2 Currency Key of Second Local Currency
HWAE3 HWAE3 Currency Key of Third Local Currency
202 P U B L I C
SAP Revenue Accounting and Reporting
Revenue Posting
HKONT SAKNR General Ledger Account Number
STATISTIC KSTAT Condition is used for statistics
SHKZG_VA FARR_SHKZG_VA Returns Item
.INCLUDE INCL_EEW_FARR_REP Enhancement Include Postings
FKBER FKBER Functional Area
GSBER GSBER Business Area
SEGMENT FB_SEGMENT Segment for Segmental Reporting
PRCTR PRCTR Profit Center
PAOBJNR RKEOBJNR Profitability Segment Number (CO-PA)
KOSTL KOSTL Cost Center
AUFNR AUFNR Order Number
KDAUF KDAUF Sales Order Number
KDPOS KDPOS Item Number in Sales Order
PS_POSID PS_POSID Work Breakdown Structure Element
(WBS Element)
Aggregation by Debit/Credit Indicator
A new Customizing option is used which allows you to decide whether you want to aggregate the general ledger
posting lines by debit/credit indicator. This Customizing is based on the company code and accounting principle.
This Customizing should not be changed frequently.
In Customizing, choose: SAP Customizing Implementation Guide Financial Accounting (New) Revenue
Accounting Revenue Accounting Postings Switch on Posting Optimization
If you trigger this new functionality when all fields listed above have the same value, the general ledger posting
lines will be aggregated. Even if they have a different debit/credit indicator, the posting lines are still netted.
You can still continue to use the revenue accounting subledger to provide detailed posted data.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 203
11.5 Job Monitor
The job monitor displays the results of the background jobs to indicate whether they have been successful.
Use
The system can run the following background jobs:
● Transfer Revenue
● Calculate Contract Liability and Contract Asset
● Revenue Posting Run
After the jobs have been completed, the job monitor displays the results of the jobs to indicate whether they have
been successful.
You can monitor the status of the jobs, such as run ID, planned start date/time, and end date/time. The results of
the jobs are displayed with different statuses, such as In Process, Scheduled, Canceled, and Finished.
The results can also be displayed according to the job categories Revenue Transfer, Calculate Contract Liabilities
and Contract Assets, Revenue Posting, and Reverse Posting and Reposting. You can view the job details of the
posting jobs, such as the application log, search criteria, and message list.
Features
Job List Block
This block is used to display the basic job information for Revenue Transfer, Calculate Liability and Asset, Revenue
Posting, Revenue Posting Reversal and Revenue Posting Repost.
The status of the jobs is determined according to the status of the main and all sub jobs, the parallel processing
and the application log. The status of an existing job entry in the job list will only be set to green if all three statuses
are highlighted in green.
With this functionality, you can also:
● delete the selected job entry.
● refresh all data in the job list.
● select which type of jobs will be displayed.
● navigate to the reconciliation reports FI documents and Revenue Accounting Contracts.
Job Detail Block
Parallel Processing Status
This block is used to display the basic information (status, description, name and number) of the parallel
processing job that is started by one of the jobs. If the parallel processing job is successfully completed, the
Parallel Processing Status icon is set to green. If the icon is set to red, it means that a dump occurred in one of the
subordinate processes.
204
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
Application Log
The application log is used to show the status of the main and subordinate jobs, and displays the processing of
jobs, all success messages or error messages.
There are two types of log: Main Logs and Subordinate Logs. The Main Logs show the information of the Main Job,
while the Subordinate Logs show the information of the Subordinate Jobs.
Each log entry has an icon which indicates the status of the log:
● If an error message is displayed, the icon of the relevant log entry is set to red.
● If no error message is displayed but there is a warning message, the icon of the relevant log entry is set to red.
● If no error message or warning message is displayed, the icon of the relevant log entry is set to green.
Application log messages
When you click on a specific log entry, a list of messages will be shown in the Message List field. You can click on
the Long Text Information link to see the long text of this log.
Search Criteria
This list is used to show the selection criteria of the specific job selected from the Job List block.
G/L Documents
This tab is used to show the information of the G/L Documents. If the Revenue Posting job or Revenue Posting
Reverse job finished successfully, one or more G/L Documents will be created.
All Documents
This tab contains the list of accounting document types created by the Revenue Posting job or Revenue Posting
Reverse Job.
When you click the Run ID button, a window will appear containing the Accounting Documents list. If the list
contains multiple reference keys, the Accounting Documents list will consist of reference keys, in this case, on top
of the reference key list. The Filter button is used to filter the reference keys by contract ID. If the reference key is
found for the contract, you can click on the reference key to navigate to the document or document list pop-up
window.
When you click the Reversal or Repost button, you can automatically navigate to the Reversal program or Repost
program using all of the related parameters (company code, accounting principle, fiscal year, posting period, run
ID and reversed run ID).
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 205
11.6 Reversing a Revenue Posting
You can reverse the documents that are generated by a previous Posting job (Revenue Posting and Revenue
Repost).
Use
As the reversal is based on the Run ID, you will reverse all of the posted contracts of the previous revenue posting
job.
The Run ID is generated based on a full revenue posting.
Features
Search Criteria
● Company code (required): You can only choose one company code.
● Accounting principle (required): You can only choose one accounting principle.
● Fiscal year and period (required): You can run this report for only one period at a time.
● Run ID: You can run this report for only oneRun ID at a time.
Activities
● You can navigate to the Revenue Posting Jobs Monitor to check the relevant job information by clicking the
Run ID.
● You can navigate to the Document Overview - Display to check all of the documents generated by the previous
Posting job (Revenue Posting and Revenue Repost) by clicking the G/L documents link in the results list.
● The Reverse function is triggered when you press the Reverse button.
206
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
11.7 Account Determination
Revenue Accounting allows you to specify the accounts that are used for the revenue postings made to the
general ledger.
Features
Account Determination Rules
You can define rules for determining the accounts used for posting certain transactions. Your rules can use
certain fields as the input, such as the accounting principle and company code, to determine which G/L account
to use for each specific transaction. The rules then output the account that is to be used.
● Evaluation Order
You can define multiple rules for determining an account. The system evaluates the rules from the top down.
Once the system finds a rule that returns an account, it does not continue to evaluate other rules.
● Required Fields
Certain fields are required when you choose the input fields for determining the account. For example, for
determining the Receivable Adjustment account, the accounting principle and company code fields are
required. Therefore, you have to specify an account for each combination of an accounting principle and a
company code.
● Copying the Reference Account
You can configure the rule to copy the reference account by setting the derived account to * (asterisk). Such a
rule indicates that the derived account is the same as the reference account if the rule matches the specified
criteria.
Reference Accounts
For each revenue-related posting, the system provides a reference account as the starting point of the account
determination process. The reference account is provided as the input of your determination rules. This account
usually comes from outside Revenue Accounting and varies depending on the type of account that needs to be
determined. For example, when determining the account of the Receivable Adjustment account, the system uses
the Accounts Receivable account (defined in the master data of the customer record) as the reference account, so
your determination rules can use that account to derive the account that will eventually be used. Your rules can
disregard the reference account and use other fields as the criteria.
G/L Accounts and Determination Settings
The following table lists the G/L accounts to be determined and the settings that determine these accounts.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 207
Table 154:
Account Reference Account Remarks
Recognized Revenue The Billed Revenue account. This is the
source account on the main pricing con
dition.
Note
● Each main condition that is
transferred from the logistics
system contains a profit and loss
account. The account is deter
mined by the account determi
nation of the logistics system.
● The price of an item can be ag
gregated from multiple pricing
conditions. Only one of the con
ditions is marked as the main
condition.
This is determined by the rules in the
Recognized Revenue section.
Receivable Adjustment The Accounts Receivable account.
The Accounts Receivable account can
be determined in the corresponding rev
enue accounting items (RAI) and in
cluded as a field when creating perform
ance obligations. The system performs a
check to make sure that all performance
obligations in a contract must reference
the same Accounts Receivable account.
The error handling of this check can be
customized in the Message Control Cus
tomizing activity.
If the Accounts Receivable account is
not specified on any of the performance
obligations in the contract, the system
then uses the reconciliation account de
fined in the company code segment of
the customer master record.
This is determined by the rules in the Re
ceivable Adjustment section.
Revenue Adjustment The Recognized Revenue account. This
is the account determined by the rules in
the Recognized Revenue section.
This is determined by the rules in the
Revenue Adjustment for Allocation Ef
fect section.
You must define rules for determining
the target account for each accounting
principle.
208 P UB L I C
SAP Revenue Accounting and Reporting
Revenue Posting
Account Reference Account Remarks
Recognized Revenue (for Linked Per
formance Obligations)
The Recognized Revenue account deter
mined for its leading performance obli
gation. This is the account determined
by the rules in the Recognized Revenue
section.
This is determined by the rules in the
Revenue Adjustment for Linked Per
formance Obligations section.
Revenue Adjustment for Right of Return The Recognized Revenue account. This
is the account determined by the rules in
the Recognized Revenue section.
This is determined by the rules in the
Right of Return section that have an Ac
count Category of Revenue Adjust
ment.
Refund Liability The Recognized Revenue account. This
is the account determined by the rules in
the Recognized Revenue section.
This is determined by the rules in the
Right of Return section that have an Ac
count Category of Refund Liability.
Refund Asset Recognized COGS account. This is the
source account on the main cost condi
tion.
This is determined by the rules in the
Right of Return section that have an Ac
count Category of Refund Asset.
COGS Adjustment for Right of Return Recognized COGS account. This is the
source account on the main cost condi
tion.
This is determined by the rules in the
Right of Return section that have an Ac
count Category of COGS Adjustment.
Deferred Revenue The Recognized Revenue account deter
mined for its leading performance obli
gation. This is the account determined
by the rules in the Recognized Revenue
section.
This is determined by the rules in the De
ferred Revenue section.
Unbilled Receivable The Accounts Receivable account.
The Accounts Receivable account can
be determined in the corresponding rev
enue accounting items (RAI) and in
cluded as a field when creating perform
ance obligations. The system performs a
check to make sure that all performance
obligations in a contract must reference
the same Accounts Receivable account.
The error handling of this check can be
customized in the Message Control Cus
tomizing activity.
If the Accounts Receivable account is
not specified on any of the performance
obligations in the contract, the system
then uses the reconciliation account de
fined in the company code segment of
the customer master record.
This is determined by the rules in the De
ferred Revenue section.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 209
Account Reference Account Remarks
Contract Liability The Accounts Receivable account.
The Accounts Receivable account can
be determined in the corresponding rev
enue accounting items (RAI) and in
cluded as a field when creating perform
ance obligations. The system performs a
check to make sure that all performance
obligations in a contract must reference
the same Accounts Receivable account.
The error handling of this check can be
customized in the Message Control Cus
tomizing activity.
If the Accounts Receivable account is
not specified on any of the performance
obligations in the contract, the system
then uses the reconciliation account de
fined in the company code segment of
the customer master record.
This is determined by the rules in the
Contract Liability section.
Contract Asset The Accounts Receivable account.
The Accounts Receivable account can
be determined in the corresponding rev
enue accounting items (RAI) and in
cluded as a field when creating perform
ance obligations. The system performs a
check to make sure that all performance
obligations in a contract must reference
the same Accounts Receivable account.
The error handling of this check can be
customized in the Message Control Cus
tomizing activity.
If the Accounts Receivable account is
not specified on any of the performance
obligations in the contract, the system
then uses the reconciliation account de
fined in the company code segment of
the customer master record.
This is determined by the rules in the
Contract Asset section.
Account Determination Configuration Tool
Revenue Accounting uses Business Rule Framework Plus (BRF+) to process account determination. However,
you do not have to handle objects directly in BRF+. A tool is available in the following Customizing activity:
Revenue Accounting Revenue Accounting Postings Configure Account Determination for Specific
Transactions
210
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
Note
● The tool allows you to copy and paste rules.
● Complex expressions supported in BRF+, such as the Greater Than operator, are not supported in this tool.
If you have defined lines with complex expressions, the tool skips those lines when displaying rules.
However, those lines still exist in the back-end BRF+ and are always evaluated as valid rules. In this case,
the display in the tool is not consistent with the actual rules in the back-end BRF+.
Reprocessing Account Determination
The system allows you to reprocess account determination to retrieve the accounts depending on the latest
account determination settings. You can either open specific contracts and start account determination
reprocessing for that contract, or search for specific contracts and select multiple contracts to reprocess.
Note
Redetermination of balance sheet accounts is not allowed after corresponding FI documents are created.
11.8 Revenue-Related Events and Postings
The following section lists the activities that involve revenue postings, typical postings that are made outside
Revenue Accounting for those activities, and corresponding corrective postings made by Revenue Accounting.
Note
Cost recognition is not currently supported by Revenue Accounting. The system does not make cost-related
postings.
When an invoice is issued:
Table 155:
Posting Made By Posting
The logistics system Dr: Accounts Receivable
Cr: Billed Revenue
(For price discounts)
Dr: Billed Revenue
Cr: Accounts Receivable
Revenue Accounting Dr: Recognized Revenue
Cr: Receivable Adjustment
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 211
Posting Made By Posting
(For price discounts)
Dr: Receivable Adjustment
Cr: Recognized Revenue
When a goods issue is created:
Table 156:
Posting Made By Posting
The logistics system Dr: Cost of Goods Sold
Cr: Inventory
To recognize revenue when a (non-linked) performance obligation is fulfilled:
Table 157:
Posting Made By Posting
Revenue Accounting Dr: Receivable Adjustment
Cr: Recognized Revenue
(For price discounts)
Dr: Recognized Revenue
Cr: Receivable Adjustment
To recognize revenue when a linked performance obligation is fulfilled:
Table 158:
Posting Made By Posting
Revenue Accounting Dr: Receivable Adjustment
Cr: Recognized Revenue (for linked performance obligations)
To recognize the difference resulting from price reallocation when a (non-linked) performance obligation is
fulfilled:
Table 159:
Posting Made By Posting
Revenue Accounting Dr: Receivable Adjustment
Cr: Revenue Adjustment
212 P U B L I C
SAP Revenue Accounting and Reporting
Revenue Posting
To recognize a right of return when a performance obligation is fulfilled:
Table 160:
Posting Made By Posting
Revenue Accounting Dr: Revenue Adjustment for Right of Return
Cr: Refund Liability
At the same time, the corresponding cost is fulfilled:
Table 161:
Posting Made By Posting
Revenue Accounting Dr: Revenue Asset
Cr: Recognized Cost
To recognize the expiration of a right of return:
Table 162:
Posting Made By Posting
Revenue Accounting Dr: Refund Liability
Cr: Revenue Adjustment for Right of Return
At the same time, the corresponding cost is fulfilled:
Table 163:
Posting Made By Posting
Revenue Accounting Dr: Recognized Cost
Cr: Refund Asset
To recognize contract liabilities at the close of the accounting period if the invoice due amount is positive
(according to the invoice due date-based calculation):
Table 164:
Posting Made By Posting
Revenue Accounting Dr: Receivable Adjustment
Cr: Contract Liability
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 213
When revenue is recognized and the contract still has a balance in contract liability (according to the invoice due
date-based calculation):
Table 165:
Posting Made By Posting
Revenue Accounting Dr: Contract Liability
Cr: Receivable Adjustment
To recognize contract assets at the close of the accounting period if the recognized revenue exceeds the invoice
amount or the billable amount (according to the invoice due date-based calculation):
Table 166:
Posting Made By Posting
Revenue Accounting Dr: Contract Asset
Cr: Receivable Adjustment
At the close of the accounting period if the contract still has a balance in contract asset and the invoice is issued
(according to the invoice due date-based calculation):
Table 167:
Posting Made By Posting
Revenue Accounting Dr. Receivable Adjustment
Cr. Contract Asset
At the close of the accounting period if the total recognized revenue exceeds the total invoiced amount up to this
period for that contract (according to the invoice date-based calculation):
Table 168:
Posting Made By Posting
Revenue Accounting Dr. Unbilled Receivable
Cr. Receivable Adjustment
Note: The amount in excess of the total invoiced amount is
posted as Unbilled Receivable.
214 P U B L IC
SAP Revenue Accounting and Reporting
Revenue Posting
At the close of the accounting period if the total invoiced amount exceeds the total recognized revenue within this
period and the balance is positive on the debit side of Unbilled Receivable (according to the invoice date-based
calculation):
Table 169:
Posting Made By Posting
Revenue Accounting Dr. Receivable Adjustment
Cr. Unbilled Receivable
Note: The debit side of Unbilled Receivable is cleared.
At the close of the accounting period if the total invoiced amount exceeds the total recognized revenue up to this
period for that contract (according to the invoice date-based calculation):
Table 170:
Posting Made By Posting
Revenue Accounting Dr. Receivable Adjustment
Cr. Deferred Revenue
Note: The amount in excess of the recognized revenue is
posted as Deferred Revenue.
At the close of the accounting period if the total recognized revenue exceeds the total invoiced amount within this
period and the previous balance is positive on the credit side of Deferred Revenue:
Table 171:
Posting Made By Posting
Revenue Accounting Dr. Deferred Revenue
Cr. Receivable Adjustment
Note: The credit side of Deferred Revenue is cleared.
If the contract involves foreign currencies and the balance of the Receivable Adjustment account is changed as a
result of postings made to certain accounts (such as the Recognized Revenue, Contract Liability, Contract Asset,
and other accounts involved in invoicing), the exchange difference is posted as follows:
If the Receivable Adjustment account has a positive balance on the credit side:
Table 172:
Posting Made By Posting
Revenue Accounting Dr. Receivable Adjustment
Cr. Gain from Exchange Rate Difference
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 215
If the Receivable Adjustment account has a positive balance on the debit side:
Table 173:
Posting Made By Posting
Revenue Accounting Dr. Loss from Exchange Rate Difference
Cr. Receivable Adjustment
Note
The Exchange Rate Difference account is configured in transaction OB09.
11.9 Revenue Accounting Close
Use
In addition to the functions for opening and closing posting periods provided in FI, Revenue Accounting provides
you with a revenue accounting level of control for your posting periods. After the accountant completes revenue
postings for an accounting period, including the posting of contract liabilities and assets, the accountant can mark
that period as closed so that new revenue-related transactions can be posted to the next open period.
This feature addresses certain issues occurring when an FI posting period is open but certain revenue-related
accounts are closed for that period. In such cases, without a revenue accounting level of control, Revenue
Accounting would assume that the revenue postings for that period can proceed, thereby creating certain posting
entries that are missing in those closed accounts.
Prerequisites
● Before you close any future revenue accounting periods, make sure that all the reconciliation keys in those
closing periods are closed and that the calculations of contract liabilities, contract asset, and time-based
revenue are completed.
● Before you open any past revenue accounting periods, make sure that there are no reconciliation keys to be
shifted from an opened period to the current period.
For example, if you open period 05 when the current period is 07, then make sure there is no reconciliation
key to be shifted from 05 to 07.
Features
Statuses of revenue accounting periods
216
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
Revenue accounting periods can have one of the following statuses:
Table 174:
Status Description
Open All transactions, such as goods issues, time-based revenue
calculations, contract liability and asset calculations, can re
quest new reconciliation keys for the current period. There
fore, these transactions are ready to be posted to the current
period.
In-Closing New transactions cannot request new reconciliation keys for
the current period. However, time-based revenue calculations
and contract liability and asset calculations can still request
new reconciliation keys for the current period. This status is
intended for scenarios when you are preparing your revenue
postings and you are ready to prevent new transactions from
being posted to the current period.
Close New transactions cannot request new reconciliation keys for
the current period. All subsequent transactions are ready to
be posted to a later period that is open.
Opening and closing revenue accounting periods
You have the following options for managing the statuses of revenue accounting periods:
● Opening and closing revenue accounting periods in Customizing
You can set the status for each revenue accounting period in the following Customizing activity. For a
combination of company code and accounting principle, the accountant can specify a starting period
(included) from which all the following periods are open for revenue accounting.
Revenue Accounting Revenue Accounting Contracts Open and Close Revenue Accounting Periods
● Closing the revenue accounting period after posting
When you run the Revenue Posting Run program to transfer revenue postings nto the general ledger and CO-
PA, you have then option of closing the corresponding revenue accounting period after a successful revenue
posting job.
11.10 Shifting Contracts with Failed Postings to the Next
Period
When an accountant runs revenue postings at the end of an accounting period, some issues may prevent the
postings from being successfully transferred to the corresponding ledgers. If the accountant cannot solve the
issues immediately and has a very small time window for period-end closing, they can choose to shift unfinished
postings for specific contracts into the next accounting period.
● Shifting contracts multiple times
After shifting a contract into the next period, the accountant can still choose to shift the contract to the next
period afterward if certain impediments still persist.
SAP Revenue Accounting and Reporting
Revenue Posting
P U B LI C 217
● Tracking shifting history
For each shifting operation, the accountant specifies a predefined reason code that indicates the reason for
performing this operation. The history of contract shifting is maintained for later review and audit.
11.11 Integration with the Financial Closing Cockpit
Use
The three ABAP programs for revenue posting can be scheduled in the SAP Financial Closing cockpit (FCc).
Prerequisites
If you run background jobs with parallel processing enabled, you must run the corresponding ABAP program in
synchronous mode for the statuses to be correctly reported back to FCc.
Features
Revenue Accounting allows you to schedule background jobs for revenue posting in the following ways:
● You can include the three steps for revenue posting in a closing template for them to run at specified times.
● FCc allows you to plan a dependency by specifying the predecessor and successor for a background job. A job
starts running only if the specified predecessor job has been completed with a certain status.
● Revenue Accounting reports the statuses of revenue posting jobs back to FCc so that the accountant can
monitor the job statuses in FCc.
Each posting job triggers multiple subordinate tasks to perform different kinds of processing. Revenue
Accounting only reports a general status for each posting job, as an aggregate of all subordinate tasks, to FCc.
These statuses are displayed as Finished Without Error, Finished with Error, and Finished with Warning. When
errors or warnings are issued for a job, the accountant can use transaction SLG1 to check details in the FARR
application log.
● FCc supports running background jobs with selection criteria specified in variants. You can create transaction
variants by using transaction SHD0 and then use the variants in FCc. All custom fields supported by Revenue
Accounting can be included in the variants used in FCc.
218
P U B LI C
SAP Revenue Accounting and Reporting
Revenue Posting
12 Reconciliation
Revenue Accounting provides the following reports for reconciliation:
● Revenue Posting and General Ledger
● Revenue Accounting Items and Revenue Accounting
12.1 Reconciliation: Revenue Accounting Subledger and
General Ledger
Technical users, such as a system administrator, can use reports to identify technical issues that cause data
inconsistencies between the revenue accounting subledger and the general ledger.
Revenue Postings and General Ledger
Table 175:
Item Details
Report name Revenue Postings and General Ledger
Intended users System administrator
Selection criteria
● Company code (required): You can only select one com
pany code.
● Accounting principle (required): You can only select one
accounting principle.
● Fiscal year and posting period (required): You can only
perform reconciliation for one period at a time.
● Run ID (optional): You can select one run ID or a range of
run IDs. The run ID is unique for each successful posting
run.
● Run Date (optional): You can select one run date.
Technical parameters
● Result view mode: You can choose to display the result
in the summary view or the detail view.
● Synchronous: If you set the Synchronous indicator, the
system processes the batch jobs synchronously in the
background.
SAP Revenue Accounting and Reporting
Reconciliation
P U B LI C 219
Item Details
Comparison for reconciliation This report compares the revenue accounting subledger and
the FI documents posted to the general ledger. The report
matches records from both sides, by general ledger account
and amount. If the records have the same general ledger ac
count but have different amounts, they are identified as a dif
ference. Similarly, if a record from one side does not have a
match from the other side, it is also identified as a difference.
Indication of differences The report displays a line for each difference. Only differences
are displayed in the report.
For each difference, items from the two sides are paired to
gether. Performance obligations are listed for the revenue ac
counting subledger. The corresponding line item in the FI
document is displayed for the general ledger. A difference line
is displayed that indicates the difference amount.
Reconciliation action This type of difference may occur due to technical issues. If
this is the case, you can perform a reversal posting job against
the previous posting job, correct the account assignment,
trigger the reprocessing of the account assignment, and then
perform a revenue posting job again. Alternatively, you can do
manual postings to fix the differences.
Revenue Accounting Subledger
Before posting FI documents to the general ledger for revenue-related transactions, the system tracks these
transactions and prepares the revenue posting data in a table, known as the revenue accounting subledger. The
revenue accounting subledger represents the revenue accounting perspective of the posting data. Each record
includes information extracted from the revenue accounting data, such as a posting category which indicates
where this posting comes from, the general ledger account used for the posting, and the account assignments.
Note
● This reconciliation report is typically scheduled for the end of the posting period when the operational
system stops processing any more events for that period. While this report is running, make sure that no
further revenue-related events are transferred from the operational system.
● This reconciliation report runs as a background job by default. You can view the job details to see the report
results.
● There is one Customizing configuration that can influence the results of the reconciliation report:
In Customizing, choose: SAP Customizing Implementation Guide Financial Accounting (New) Revenue
Accounting Revenue Accounting Postings Switch on Posting Optimization
Aggregate by D/C indicator: If you switch this configuration on while running the Run Revenue Posting
program, but switch it off while running this reconciliation report, a difference will appear. In order to get the
correct reconciliation result, you therefore have to use the same configuration between posting and
reconciliation. Also, if you switch this configuration on, this reconciliation report will compare the netting of the
debit/credit indicator between the revenue accounting subledger and the general ledger.
220
P U B LI C
SAP Revenue Accounting and Reporting
Reconciliation
12.2 Reconciliation: Revenue Accounting Items and Revenue
Accounting
Revenue Accounting receives data from different components, such as Sales and Distribution (SD) or Customer
Relationship Management (CRM), and posts documents to General Ledger Accounting (FI-GL) and Profitability
Analysis (CO-PA). The system logs any errors that occur in the communication between the components and
processing in the Adapter Reuse Layer (ARL). Consequently, you need to reconcile data until the data processed
in ARL and the data finalized in the Revenue Accounting are consistent. You need a summary report to reconcile
data between revenue accounting items and the Revenue Accounting, and you need to perform reconciliation
regularly. You can reconcile values from sales order items, original prices from sales orders, goods issues, and
invoices that have been processed in ARL with the values in corresponding performance obligations and related
tables in the Revenue Accounting.
Table 176:
Item Details
Report name Revenue Accounting Items and Revenue Accounting
Intended user System administrator
Selection criteria
● Company Code: You can perform reconciliation for spe
cific company codes.
● Accounting Principle: You can perform reconciliation ac
cording to a specific accounting principle.
● Start Date of Reconciliation: This reconciliation report
checks data from the specified date to the present time.
By default, the report starts from the point where last
reconciliation occurred. You can specify a date earlier
than the date when last reconciliation occurred. However,
you cannot specify a start date in simulation mode.
● Performance Obligation: You can specify performance
obligations to run the reconciliation only in simulation
mode.
SAP Revenue Accounting and Reporting
Reconciliation
P U B LI C 221
Item Details
Technical parameters
● Number of Intervals: The number must not exceed 1000
as there are only 1000 subareas available for paralleliza
tion.
● Size of the Selection Blocks: The block size controls how
many selected items are held in the main memory. Too
few items cause the database to be accessed more fre
quently; too many items increases the load on the system
caused by the management of the data. Reconcile the
block size with the size of the interval.
● Simulation Mode: When the parallelized report is started
in simulation mode, no database updates are performed.
● Dialog Mode: If the Dialog Mode indicator is not set, the
framework processes the data in batch mode and inter
vals are processed in parallel batch jobs. If the Dialog
Mode indicator is set, the framework processes the data
in dialog mode (without creating batch jobs). Intervals
are processed sequentially in one dialog process. In dia
log mode, the Synchronous Call indicator is set automati
cally by the system and cannot be changed.
● Synchronous Call: If you do not set the Synchronous Call
indicator, the system processes the batch jobs asynchro
nously in the background. Immediately after you have
started the program, the system displays the batch job
monitor. If you set the Synchronous Call indicator, you
can display the application log in transaction SLG1 after
processing has finished, regardless of whether you have
used dialog or batch mode.
222
P U B LI C
SAP Revenue Accounting and Reporting
Reconciliation
Item Details
Comparison for reconciliation The system compares data for reconciliation as follows:
● Latest original price and cost from sales order per condi
tion type
The system compares the current original price and cost
from the sales order per condition type in Revenue Ac
counting against the latest order item of processed ac
counting items. The system does not reconcile adjust
ments of the transaction price and cost from invoices
with deviating conditions.
● Invoice total amount per performance obligations
The system compares invoice total amount per perform
ance obligation.
● Invoiced amount per condition type of both price and
cost
The system compares the invoiced amount of price and
cost in processed revenue accounting item and deferral
items per condition type.
● Fulfilled quantities
The system compares actual fulfilled quantities per per
formance obligation. The system does not compare cal
culated quantities in Revenue Accounting. For those per
formance obligations with a change history of event and
fulfillment type, the report puts an indicator flag on
header. The system displays difference by total quantity
instead of every goods issue.
● Recognized cost
The system compares recognized cost per performance
obligation excluding that of compound performance obli
gations.
SAP Revenue Accounting and Reporting
Reconciliation
P U B LI C 223
Item Details
Indication of differences The report displays compared results by performance obliga
tion. The results are listed in different check item sections.
The system highlights quantities of differences in red.
● Performance obligations in a bill of materials
The system displays the whole structure of performance
obligations if any of the performance obligations com
pared, be they high-level or low-level, are different.
● Performance obligations for which the validation results
are Warning or OK
The system compares all figures from processed ac
counting items with those from the Revenue Accounting.
● Performance obligations for which the validation results
are Error
The system does not create deferral items for some of
these performance obligations. As a result, the system
does not compare performance obligations for which the
validation results are Error. The system compares
these performance obligations again in the next run.
Reconciliation action If this reconciliation detects any inconsistencies, you need to
take measures, such as reprocess certain revenue accounting
items or edit some performance obligations manually.
If a performance obligation has been fulfilled and the system
displays the total quantity, you need to check changing his
tory of events and fulfillments type. Then you can make an ad
justment, such as manual fulfillment, until there is no differ
ence.
Exception of reconciliation
When performing reconciliation, the system ignores some items listed in the table below.
Table 177:
Ignored Items Reasons
Linked performance obligations The data of linked performance obligations is not located in
processed revenue accounting items.
Fulfillment quantity of manually fulfilled performance obliga
tions
The data of fulfillment is not located in processed revenue ac
counting items.
Fulfillment quantity of performance obligations that are fulfil
led by invoice
The data of fulfilled quantity is not located in fulfillment table
for processed revenue accounting items.
224 P U B L I C
SAP Revenue Accounting and Reporting
Reconciliation
Ignored Items Reasons
Performance obligations handled with simplified invoice proc
ess
ARL does not transfer any invoice information of performance
obligations handled with simplified invoice process to Reve
nue Accounting.
SAP Revenue Accounting and Reporting
Reconciliation
P U B LI C 225
13 Reporting
With data sources, you can create analytics and reporting for revenue recognition to gain a sound understanding
of the details of FI documents, and also to monitor, review, and predict the revenues and costs.
13.1 Reconciliation for Accountants
An Accountant, such as a Revenue Specialist, can use several reports to understand the details of FI documents
created in revenue posting runs and to identify differences between Revenue Accounting and the general ledger.
Report A
The following table details how to use report A.
Table 178:
Item Details
Report name FI Documents and Revenue Accounting Contracts
Intended users Accountants
226 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Item Details
Selection criteria
● Company code (required): You can only choose one
company code.
● Fiscal year and period (required): You can only run this
report for one period at a time.
● Accounting principle (required): You can only choose
one company code.
● Revenue reconciliation key: You can run this report
against data that is associated with specific revenue rec
onciliation keys. Revenue reconciliation keys are part of
the technical implementation of the Revenue Accounting
system. For more information, see the Revenue
Reconciliation Keys section.
● G/L document: You can run this report against data that
is associated with specific G/L documents.
● G/L account: You can run this report against data that is
associated with specific G/L accounts.
● Revenue accounting contract: You can run this report
against data that is associated with specific revenue ac
counting contracts.
● Posting category: You can use this option to select
posted items that relate to a certain category, such as
Revenue Adjustment.
Comparison for reconciliation Typically, the accountant uses this report to display posting
details instead of identifying differences. This report displays
the corresponding line items in the posted FI documents. The
accountant can see which contracts are included in this post
ing and which performance obligations are included in each
contract.
A total line is displayed which indicates the value of a G/L
document line item that has been posted to a certain G/L ac
count.
Indication of differences Not applicable
Reconciliation action Not applicable
Report B
The following table details how to use report B.
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 227
Table 179:
Item Details
Report name Accounts Between Revenue Accounting and G/L
Intended users Accountants
Selection criteria
● Company code (required): You can only choose one
company code.
● Fiscal year and period (required): You can only run this
report for one period at a time.
● Accounting principle (required): You can only choose
one company code.
● G/L account: You can perform reconciliation against
data that is associated with specific G/L accounts.
● Has difference: You can choose this option to only dis
play items that have differences.
● Run in background: You can choose this option to run
the reconciliation in the background.
Comparison for reconciliation This report compares the posted amounts by period between
Revenue Accounting and the general ledger. If the amount
posted by Revenue Accounting under the specific account dif
fers from the amount actually posted in the general ledger, it's
identified as a difference.
Indication of differences The report result displays postings made to the revenue-re
lated accounts. Items that have differences are indicated with
a red traffic light. Items that do not have differences are indi
cated with a green traffic light.
Reconciliation action This type of difference typically occurs because a user has
made postings to the general ledger manually. You can check
the posting history to identify the issue.
Example
The revenue-related accounts are determined as follows:
Table 180:
Revenue-Related Account G/L Account
Account for Receivable Adjustment 300001 (Receivable Adjustment Service)
Account for Unbilled Revenue 300002 (Unbilled Revenue Service)
Account for Deferred Revenue 300003 (Deferred Revenue Service)
228 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
After the accountant has performed the revenue posting run for the period 2014001, the system transfers the
following postings to the general ledger. In this case, the first two accounts have amounts but the third account
has a zero amount.
Table 181:
G/L Account Posted Amount in Revenue Accounting
300001 (Receivable Adjustment) 100
300002 (Unbilled Revenue) 200
300003 (Deferred Revenue) 0
The accountant then runs this reconciliation report and receives a result that resembles the following:
Table 182:
Period G/L Account Amount Posted by
Revenue Accounting
Posted Amount in
G/L
Difference
201401 300001 (Receivable
Adjustment)
100 100 0
201401 300002 (Unbilled Rev
enue)
200 200 0
201401 300003 (Deferred
Revenue)
0 50 -50
The report result indicates that Revenue Accounting does not post any amount to account 300003 (Deferred
Revenue) but an amount of 50 is posted to the account. In this case, a difference of 50 occurs. This situation
typically occurs because a user has made postings in the general ledger manually.
13.2 Sample Reports
Analytics and reporting of revenue recognition is necessary for users and stakeholders to monitor, review, and
forecast their revenues and costs. Some accounting principles require that the company provides certain
analytics reports in its disclosure of revenue. Additionally, analytics reports may help you with strategic decisions.
Several reports are available that address the most typical reporting scenarios. Additionally, you can use these
reports as samples for developing your own reports.
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 229
13.2.1 Sample Reports: Disaggregation of Revenue and Posted
Amounts
Posted amounts
Reports are available that display the original prices, allocated prices, posted revenue, invoiced amount, and other
important amounts for contracts and performance obligations of each period. The resulting items are aggregated
by the following dimensions:
● Contract
● Performance obligation type
Disaggregation of revenue
Your company may have to disaggregate revenue into different categories, such as the performance obligation
type. The sample reports allow you to display revenue data of a specific accounting period, aggregated by the
following dimensions:
● Customer
● Customer group
● Performance obligation type
Disaggregation of revenue by multiple dimensions
This sample report is designed to show posted revenue by different dimensions in each period. The report
includes a series of analytics reports. It shows the posted revenue in both the transaction currency and the local
currency by different dimensions in selected periods. The different dimensions include standard fields and
customized fields in the revenue accounting subledger.
In International Financial Reporting Standard 15 (IFRS 15), several types of dimensions are proposed for a
company. In Revenue Accounting, you can assign some useful fields in the revenue accounting subledger and use
these fields in the same way as the dimensions described in IFRS 15. You can display some fields in the revenue
accounting subledger in the report. These fields can also be used as selection criteria. Any customized fields that
you add to the revenue accounting subledger are also included in the selection criteria. You can define your own
view by clicking the Filter Settings button. You can also hide or unhide any useful fields according to your own
requirements.
13.2.2 Sample Report: Contract Balance
Your company may be required to disclose closing balances of receivables, either contract assets and contract
liability, or unbilled receivables and deferred revenues. You can show aggregated balances from different
dimensions so that they can be reconciled with the balance of general ledger accounts. In this sample report, the
230
P U B LI C
SAP Revenue Accounting and Reporting
Reporting
contract balance will display the balance of receivables, either contract assets and contract liability, or unbilled
receivables and deferred revenues. In the IMG, you can choose to post either on contract assets and contract
liability or on unbilled receivables and deferred revenues.
Contract Balance is designed to show the key figures (opening balance, posted amount, and closing balance)
according to the company code, accounting principle, revenue contracts, or other dimensions in each period. In
the contract balance report, all key figures are the cumulative amount for the total value up until the chosen
period. This report focuses on the revenue accounting subledger, rather than the general ledger. This means that
this report handles posted data created by the revenue accounting subledger. The report will be used at the
period end closing once all data to be posted from revenue accounting is successfully posted to the general
ledger. The three programs Calculate time-based revenue, Calculate contract liability and assets, and Revenue
posting run are therefore complete.
Selection Criteria:
● Posting Period: The posting period of the performance obligations’ posted revenue and invoice amount is
derived by the posting date. You can select a range of posting periods by choosing ‘is between’ from the drop
down list and entering the dates in the corresponding fields.
If you select a range of posting periods (in between), the report will show the aggregated value from those
periods.
For example, if you want to see the value from January to June, then you enter “from January to June”. The
report will display the starting balance as 1 January, the aggregated posted amount from January to June, and
the closing balance as 30 June.
● Posting Category: You can select either receivables, contract liability and contract assets, or deferred
revenue and unbilled receivables.
You can display some fields in the revenue accounting subledger in the report, and you can also select these
fields as selection criteria.
If you add customized fields to the revenue accounting subledger, they are also included in the selection
criteria.
Results List:
You can define your own view by clicking the Filter Settings button. You can hide or unhide useful fields according
to your own requirements.
The report displays the opening balance, posted amount and closing balance of receivables, contract liability and
contract assets, or unbilled receivables and deferred revenue according to different dimensions.
13.2.3 How to Create a Report for Transaction Price Allocated
to the Remaining Performance Obligations
According to International Financial Reporting Standard 15 (IFRS 15) , an entity is required to disclose the
aggregated amount of the transaction price allocated to the performance obligations that are unsatisfied, or
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 231
partially unsatisfied, at the end of the reporting period. An entity is also required to provide an explanation on a
quantitative basis using the time bands that would represent the duration of the remaining performance
obligations.
This documentation is provided to help you create a report for the Transaction Price Allocated to the Remaining
Performance Obligations.
The following example is provided as guidance only:
This example shows you unfulfilled revenue for performance obligations on a yearly basis. The transaction price
allocated to the remaining performance obligations can be calculated as unfulfilled revenue to remaining
performance obligations.
This example is to display unfulfilled revenue that will be recognized in one year, or in two years. In the current
Revenue Accounting solution, only time-based performance obligations can be analyzed by time band. For
performance obligations which will be fulfilled by events or the percentage of completion, only the total value for
the unfulfilled revenue can be displayed.
The user interface for this example could display:
Table 183:
Revenue ex
pected to be
recognized on
the contracts
relating to the
revenue line
items as of 31
December 20X8
20X9 20X0 Unfulfilled reve
nue for time-
based perform
ance obligation
Unscheduled
revenue (unful
filled revenue
for event/
percentage of
completion-
based perform
ance obligation
Pending reve
nue
Total unfulfilled
revenue
Cloud subscrip
tion and sup
port
Software licen
ces
Software sup
port
Software licen
ces and support
Total
Details:
Table 184:
Item Details
Report name Transaction Price Allocated to the Remaining Performance
Obligations
232 P U B LI C
SAP Revenue Accounting and Reporting
Reporting
Item Details
Intended user Accountants
Main selection criteria
● Company code
● Accounting principle
● Fiscal year and period
Other selection criteria
● Performance obligation type: You can obtain results by
specifying the performance obligation type.
● Revenue contract ID: You can obtain results by specifying
the revenue contract ID.
● Performance obligation ID: You can obtain results by
specifying the performance obligation ID.
● Customer ID: You can obtain results by specifying the
customer ID.
● Business partner: You can obtain results by specifying
the business partner.
● Sales organization: You can obtain results by specifying
the sales organization.
● You can also obtain results by specifying the field in the
Account Assignment Fields in the
FARR_S_POST_ACCT_ASSIGNMT structure, the perform
ance obligation enhanced structure
INCL_EEW_FARR_POB and the posting enhanced struc
ture INCL_EEW_FARR_REP.
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 233
Item Details
Result column description This example will show unfulfilled revenue for all types of re
maining performance obligations.
● Future year 1 (time band 1):
As a legal requirement, you have to disclose unfulfilled
revenue for any remaining performance obligations with
a time band. In this example, you can display unfulfilled
revenue for time-based performance obligations which
will be recognized in the next fiscal year. In your own re
port, you can use your own time band. For example, you
can display unfulfilled revenue which will be recognized in
one month’s time.
● Future year 2 (time band 2):
As a legal requirement, you have to disclose unfulfilled
revenue for any remaining performance obligations with
a time band. In this example, you can display unfulfilled
revenue for time-based performance obligations which
will be recognized in the next two fiscal years. In your own
report, you can use your own time band. For example,
you can display unfulfilled revenue which will be recog
nized in two months’ time.
● Pending revenue:
This column is used to display aggregated pending reve
nue.
● Unfulfilled revenue for time-based performance obliga
tions:
This column is used to display the total unfulfilled reve
nue of time-based performance obligations without a
Pending status.
● Unscheduled revenue:
This column is used to show the aggregated unfulfilled
revenue of performance obligations which will be fulfilled
by events or the percentage of completion.
● Total unfulfilled revenue:
This column is used to show the whole aggregated unful
filled revenue.
When performing this report, the system ignores some items listed in the table below:
Table 185:
Ignored Items Reasons
Fully fulfilled performance obligations This report will not show fully fulfilled performance obligations
because they do not have any unfulfilled revenue.
234 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data processing for this report
1. Get current period status
According to the user input for the fiscal year and posting period, you need to check whether the input year
and posting period are in the future. If not, the starting period will always be one period after the current
period. If they are, the starting period will be the same as the input condition.
2. Get performance obligation ID list to calculate future revenue
This step is relevant to database table FARR_D_POB. You don’t need to select the fully fulfilled performance
obligation, as it no longer has any future revenue. So you have to add the condition for FULLY_FULFILLED
which is not Initial while fetching data from the database table. Meanwhile, you also need to get information
for fields FULFILLMENT_TYPE, VALIDATE_RESULT, PENDING_CONFLICT, and REV_REC_BLOCK. The field
FULFILLMENT_TYPE is used to distinguish time-based revenue and unscheduled revenue. The fields
VALIDATE_RESULT, PENDING_CONFLICT, and REV_REC_BLOCK are used for pending revenue. If the field
VALIDATE_RESULT <> “E” AND PENDING_CONFLICT = ABAP_FALSE AND REV_REC_BLOCK = ABAP_FALSE
AND FULFILL_TYPE = “T”, then it means this performance obligation is a time-based performance obligation
without a Pending status.
3. Get revenue information
All revenue information in this report comes from database table FARR_D_DEFITEM. 3.1 and 3.2 provide
definitions for the different revenue columns used in this report.
1. Revenue without a time band
This kind of revenue is needed to calculate all types of performance obligations. All data entries are
selected under the following conditions:
○ category = “P”
○ statistic = ABAP_FALSE
○ Latest_Defitem = ABAP_TRUE
The formula is: Revenue = Total Document Amount – Posted Amount.
From a database field perspective, it should be: Revenue = DOC_AMT_CUMULUTE +
PRO_AMT_CUMULUTE – REV_AMT_POSTED.
For a pending performance obligation, this part of the revenue is calculated in the Pending Revenue
column.
For a normal time-based performance obligation, this part of the revenue is calculated in the Unfulfilled
Revenue for Time-based Performance Obligation column.
For a normal event-based or percentage of completion performance obligation, this part of the revenue is
calculated in the Unscheduled Revenue column.
All types of revenue mentioned previously are calculated in the Total Unfulfilled Revenue column.
2. Revenue with a time band
This kind of revenue is specified for a normal time-based performance obligation. All data entries should
be selected under the following conditions:
○ category = “P”
○ statistic = ABAP_FALSE
Meanwhile, you also need to consider the fiscal year and posting period from a selection screen, as time
band information can be taken from the RECON_KEY field. The first four digits in the reconciliation key
field refer to the fiscal year, and the last three digits refer to the posting period.
According to this rule, you can get revenue information directly without using a previously mentioned
formula. The logic in the current topic is: Revenue in one specific year/period = aggregation of
REV_AMT_DELTA according to the time information in the reconciliation key.
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 235
13.3 DataSources
Use
An entity shall disclose sufficient information to users of financial statements. These information helps them
understand the nature, amount, timing, and uncertainty of revenue from contracts with customers.
To satisfy the requirement of disclosure, you can use data source to create analytical reports.
Example
Example 1
Entity A shall disclose opening and closing balances of receivables, contract assets and contract liabilities from
contracts with customers.
The following report shows the cumulative balance amount of opening balance, closing balance in both document
currency and local currency in a chosen period, including receivable, contract liability and contract asset. It can be
displayed by contract, performance obligation type, or other dimension.
In this report, all key figures are cumulative amount for all the value in each chosen period.
Table 186:
Fiscal Year Period Posting Cate
gory
POB Type Beginning Bal
ance
Additions Closing Bal
ance
2015 1 RV
2015 2 RV
2015 3 RV
Note
Hereafter, performance obligation in tables is written as POB and RV to Revenue.
To build the report, you need to take data from posting table FARR_D_POSTING. This posting table provides all
value in the different posting category by fiscal year or period.
Table 187:
Contract POB Posting
category
POB Type Fiscal Year Period Reconcilia
tion Key
Amount Currency
1 1001 RV A 2014 011 2014011 100 EUR
1 1001 RV A 2014 012 2014012 50 EUR
236 P UB L I C
SAP Revenue Accounting and Reporting
Reporting
Contract POB Posting
category
POB Type Fiscal Year Period Reconcilia
tion Key
Amount Currency
1 1001 RV A 2015 001 2015001 50 EUR
1 1001 RV A 2015 002 2015002 150 EUR
1 1001 RV A 2015 003 2015003 60 EUR
1 1002 RV B 2014 012 2014012 50 EUR
1 1002 RV B 2015 003 2015003 100 EUR
Note
The last 3 periods can be derived by analyzing customer’s input. For example, if customer enter 2015/003,
then 2015/001 and 2015/002 will be derived. For performance optimization, SAP suggests you do not fetch all
data from database and perform aggregation in memory. Instead you can to aggregate the database as much
as possible. Two data bases are needed to fetch the data.
Then you can take the following steps:
1. Select from database 0FARR_D_POSTING with the restriction that reconciliation key should be smaller than
20150019999999. Here you can take the reconciliation key as a binding field of fiscal year or posting period.
This step we need to get the aggregation value before the first period. POB type, fiscal year, and period
posting category should be used as selection fields.
Note
Value of different periods is not necessary, so you do not need to extract value of period.
Table 188:
Posting Category POB Type Amount Currency
RV A 150 EUR
RV B 50 EUR
2. Select from database 0FARR_D_POSTING with restriction that fiscal year should be 2015/001/002/003. So
you need to get detailed value of period.
Table 189:
Fiscal year Period POB Type Amount Currency
2015 001 A 50 EUR
2015 002 A 150 EUR
2015 003 A 60 EUR
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 237
Fiscal year Period POB Type Amount Currency
2015 003 B 100 EUR
3. Then you can combine the result in the step 2 and 3 to build the result as follows:
Table 190:
Fiscal Year Period Posting Cat
egory
POB Type Beginning
Balance
Additions Closing Bal
ance
Currency
2015 1 RV A 150 50 200 EUR
2015 2 RV A 200 150 350 EUR
2015 3 RV A 350 60 410 EUR
2015 3 RV B 50 100 150 EUR
4. You are recommended to call datasource 0FARR_RA_10 with your specified selection criteria and request
fields. The datasource 0FARR_RA_10 have provided dynamic aggregation on database 0FARR_D_POSTING.
Example 2
Entity B shall disclose information about its remaining performance obligation. The information includes
aggregated transaction price allocated to performance obligations that are unsatisfied or partially unsatisfied as
of the end of reporting period.
There are two parts of data need to be consolidated.
● The allocated price from performance obligations aggregated by period
● The fulfilled amount from performance obligation aggregated by period
You need to get cumulative value from farr_d_defitem table based on the fiscal year or period which end users
input. Reconciliation key in farr_d_defitem table can be used as selection criteria.
Then you can take the following steps:
1. Aggregate the column doc_amt_delta in farr_d_defitem with restriction that category should be “P”. For
example, you can input fiscal year period 2016/001, then the reconciliation key should be restricted as
smaller than 20160019999999.
Table 191:
Fsical Year/Period POB Allocated Amount Currency
2016/001 1 150 EUR
2016/001 2 100 EUR
2016/001 3 120 EUR
The change of allocated amount is displayed in deferral item table.
238
P U B LI C
SAP Revenue Accounting and Reporting
Reporting
2. Select from database 0FARR_D_POSTING with the restriction that reconciliation key should be smaller than
20160019999999 and posting category is “RV”.
Note
You can take the reconciliation key as a binding field of fiscal year or posting period since it is useful to
restrict value.
Table 192:
Fsical year/Period POB Posted Amount Currency
2016/001 1 150 EUR
2016/001 2 50 EUR
2016/001 3 10 EUR
3. Combine the two parts of data.
Table 193:
Fsical year/
Period
POB Allocated
Amount
Posted Amount Unfilled Amount Currency
2016/001 1 150 150 0 EUR
2016/001 2 100 50 50 EUR
2016/001 3 120 10 110 EUR
13.3.1 Revenue Analysis by Posting Item
DataSource Transactional Data 0FARR_RA_10
Use
This DataSource extracts posted items from the posting table. Each amount is specific to a posting category.
Direct Access: Supported (without preaggregation)
Real-Time Enabled: No
Released for Data Services: No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 239
Technical Data
Table 194:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable Yes
Extraction from Archives No
Verifiable No
Data Modeling
Delta Update
This DataSource supports delta processing. The timestamp field from database table FARR_D_POSTING is for
delta calculation.
Fields of Origin for the Extraction Structure
Table 195:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
GJAHR
Fiscal Year
POPER
Posting Period
FISCVAR
Fiscal Year Variant
COMPANY_CODE
Company Code
FARR_D_POSTING COMPANY_CODE
ACCT_PRINCIPLE
Accounting Principle
FARR_D_POSTING ACCT_PRINCIPLE
RECON_KEY
Reconciliation Key
FARR_D_POSTING RECON_KEY
CONTRACT_ID
Revenue Recognition Con
tract ID
FARR_D_POSTING CONTRACT_ID
POB_ID
Performance Obligation ID
FARR_D_POSTING POB_ID
CONDITION_TYPE
Condition Type
FARR_D_POSTING CONDITION_TYPE
POST_CAT
Category for Posting Docu
ment
FARR_D_POSTING POST_CAT
HKONT
G/L Account Number
FARR_D_POSTING HKONT
GUID
Replacement of FARR_POST
ING_GUID with Char16 (Char
32) in BW
FARR_D_POSTING GUID
240 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
SHKZG
Debit/Credit Indicator
FARR_D_POSTING SHKZG
BETRW
Amount in Transaction Cur
rency
FARR_D_POSTING BETRW
WAERS
Currency Key
FARR_D_POSTING WAERS
BETRH
Amount in Local Currency
FARR_D_POSTING BETRH
HWAER
Local Currency
FARR_D_POSTING HWAER
BETR2
Amount in Second Parallel Lo
cal Currency
FARR_D_POSTING BETR2
HWAE2
Currency Key of Second Local
Currency
FARR_D_POSTING HWAE2
BETR3
Amount in Third Parallel Local
Currency
FARR_D_POSTING BETR3
HWAE3
Currency Key of Third Local
Currency
FARR_D_POSTING HWAE3
STATISTIC
Condition is used for statistics
FARR_D_POSTING STATISTIC
POB_TYPE
Performance Obligation Type
FARR_D_POSTING POB_TYPE
SPEC_INDICATOR
Deferral Item Special Indica
tor
FARR_D_POSTING SPEC_INDICATOR
.INCLUDE
PAOBJNR
Profitability Segment Number
(CO-PA)
FARR_D_POSTING PAOBJNR
FKBER
Functional Area
FARR_D_POSTING FKBER
GSBER
Business Area
FARR_D_POSTING GSBER
SEGMENT
Segment for Segmental Re
porting
FARR_D_POSTING SEGMENT
PRCTR
Profit Center
FARR_D_POSTING PRCTR
KOKRS
Controlling Area
KOKRS
TIMESTAMP
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_POSTING TIMESTAMP
Extractor Logic
● The basis of extraction is the FARR_D_POSTING table.
● The time (changed/created) of the transaction data record is set in the TIMESTAMP field in the extractor.
● This DataSource provides information about object numbers in Revenue Accounting and this information is
used for maintaining time-dependent relationships of contracts and performance obligations.
● Posted values are categorized by posting category.
CL: Contract Liability
CA: Contract Asset
RA: Receivable Adjustment
RV: Revenue
CC: Cost Correction
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 241
DR: Deferred Revenue
UR: Unbilled Receivable
IC: Invoice Correction
CO: Cost
CJ: Cost Adjustment
ED: Exchange Rate Diff.
● The fiscal year and posting period have been enhanced in the database table FARR_D_POSTING, so this
DataSource can make data selection based on these fields directly. You need to execute report
FARR_RECONKEY_TO_GJAHR_POPER to perform data migration.
● This DataSource supports dynamic aggregation on the database level according to the information of
requested fields. At the same time, this DataSource can also support dynamic filter if you enhance the
database table FARR_D_POSTING. For example, if you enhance the structure INCL_EEW_FARR_REP with the
new fields, then the extractor logic regards these new fields as selection fields automatically.
13.3.2 Allocated Price Change of Performance Obligation
DataSource Transactional Data 0FARR_RA_20
Use
This DataSource extracts items from the deferral items table.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 196:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable Yes
Extraction from Archives No
Verifiable No
242 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Delta Update
The DataSource extracts items from database table FARR_D_DEFITEM. Delta processing is supported by the
timestamp field of the table.
Fields of Origin for the Extraction Structure
Table 197:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
GJAHR
Fiscal Year
POPER
Posting Period
FISCVAR
Fiscal Year Variant
RECON_KEY
Reconciliation Key
FARR_D_DEFITEM RECON_KEY
POB_ID
Performance Obligation ID
FARR_D_DEFITEM POB_ID
CONDITION_TYPE
Condition Type
FARR_D_DEFITEM CONDITION_TYPE
DEFERRAL_CAT
Deferral Category
FARR_D_DEFITEM DEFERRAL_CAT
EVENT_TYPE
Fulfillment Event Type
FARR_D_DEFITEM EVENT_TYPE
FULFILL_TYPE
Fulfillment Type
FARR_D_DEFITEM FULFILL_TYPE
COMPANY_CODE
Company Code
FARR_D_DEFITEM COMPANY_CODE
STATISTIC
Condition is used for statistics
FARR_D_DEFITEM STATISTIC
CATEGORY
Condition Is Pricing or Cost
ing
FARR_D_DEFITEM CATEGORY
SPEC_INDICATOR
Deferral Item Special Indica
tor
FARR_D_DEFITEM SPEC_INDICATOR
DOC_AMT_DELTA
Amount of Revenue Account
ing Item
FARR_D_DEFITEM DOC_AMT_DELTA
DOC_QTY_DELTA
Quantity
FARR_D_DEFITEM DOC_QTY_DELTA
QUANTITY_UNIT
Quantity Unit
FARR_D_DEFITEM QUANTITY_UNIT
AMOUNT_CURK
Currency Key
FARR_D_DEFITEM AMOUNT_CURK
RECODE_MODE
BW Delta Process: Record
Mode
TIMESTAMP
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_DEFITEM TIMESTAMP
Extractor Logic
● The basis of extraction is the FARR_D_DEFITEM table.
● The time (changed/created) of the transaction data record is set in the TIMESTAMP field in the extractor.
● This extractor supports delete operation in the database table. Table FARR_D_DELDEFITM stores all deletion
entries (entries that represent deletions).
● This DataSource provides information about object numbers in Revenue Accounting and this information is
used for linking time-dependent relationships of contracts and performance obligations.
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 243
● Restrictions apply to certain key figures.
1. Allocated Price
STATISTIC =“ ”
CATEGORY =“P”
2. Original Price
STATISTIC = “ ”
CATEGORY = “P”
SPEC_INDICATOR <> “D”
● This DataSource supports dynamic aggregation on the database level according to the information of
requested fields.
13.3.3 Revenue Forecast
DataSource Transactional Data 0FARR_RA_30
Use
This DataSource extracts items from the deferral items table.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 198:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable Yes
Extraction from Archives No
Verifiable No
244 P U B LI C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Delta Update
The DataSource extracts items from database table FARR_D_DEFITEM. Delta processing is supported by the
timestamp field of the table.
Fields of Origin for the Extraction Structure
Table 199:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
GJAHR
Fiscal Year
POPER
Posting Period
FISCVAR
Fiscal year variant
RECON_KEY
Reconciliation Key
FARR_D_DEFITEM RECON_KEY
CONTRACT_ID
Contract ID
FARR_D_DEFITEM CONTRACT_ID
POB_ID
Performance Obligation ID
FARR_D_DEFITEM POB_ID
CONDITION_TYPE
Condition Type
FARR_D_DEFITEM CONDITION_TYPE
DEFERRAL_CAT
Deferral Category
FARR_D_DEFITEM DEFERRAL_CAT
EVENT_TYPE
Fulfillment Event Type
FARR_D_DEFITEM EVENT_TYPE
FULFILL_TYPE
Fulfillment Type
FARR_D_DEFITEM FULFILL_TYPE
COMPANY_CODE
Company Code
FARR_D_DEFITEM COMPANY_CODE
STATISTIC
Condition is used for statistics
FARR_D_DEFITEM STATISTIC
CATEGORY
Condition is Pricing or Costing
FARR_D_DEFITEM CATEGORY
SPEC_INDICATOR
Deferral Item Special Indica
tor
FARR_D_DEFITEM SPEC_INDICATOR
REV_AMT_DELTA
Forecast Revenue Amount
FARR_D_DEFITEM REV_AMT_DELTA
REV_QTY_DELTA
Forecast Quantity
FARR_D_DEFITEM REV_QTY_DELTA
QUANTITY_UNIT
Quantity Unit
FARR_D_DEFITEM QUANTITY_UNIT
AMOUNT_CURK
Currency Key
FARR_D_DEFITEM AMOUNT_CURK
RECODE_MODE
BW Delta Process: Record
Mode
TIMESTAMP
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_DEFITEM TIMESTAMP
Extractor Logic
1. Revenue Accounting prepares data of all time-based revenue. This data is the basis of revenue forecast.
2. Datasources 0FARR_RA30extract deleted items from the FARR_D_DELDEFITM table.
3. This DataSource extracts deferral items for all times so that you can rebuild any future revenue data.
4. This DataSource supports delta extraction by using the timestamp in the deferral items table
(FARR_D_DEFITEM).
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 245
13.3.4 Revenue Object Attribute
DataSource Attributes 0FARR_OBJNR_ATTR
Use
The DataSource is used to build time-dependent relationships of performance obligations and contracts.
Direct Access: Supported (without preaggregation)
Real-Time-Enabled: No
Released for Data Services: No
Technical Data
Table 200:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable Yes
Extraction from Archives No
Verifiable No
Data Modeling
Delta Update
The DataSource extracts items from database table FARR_D_POB_HIS. Delta processing is supported by the
timestamp field of the table.
This DataSource provides information about object numbers of Revenue Accounting objects, such as contracts
and performance obligations. The object number is a technical field for BI modeling. Keyfigures such as revenue
and liablity can be posted either on contract or performance obligation level. Therefore, you need information that
maintains time-dependent relationships between contracts and performance obligations. Additionally, object
number information is also available in transaction-related DataSources, such as 0FARR_RA_10, 0FARR_RA_20,
and
0FARR_RA_30.
246
P U B LI C
SAP Revenue Accounting and Reporting
Reporting
Fields of Origin for the Extraction Structure
Table 201:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
OBJNR
Revenue Object Number
POB_ID
Performance Obligation ID
FARR_D_POB_HIS POB_ID
DATE_TO
Valid-To Date
FARR_D_POB_HIS DATE_TO
DATE_FROM
Valid-From Date
FARR_D_POB_HIS DATE_FROM
CONTRACT_ID
Revenue Recognition Con
tract ID
FARR_D_POB_HIS CONTRACT_ID
CREATED_BY
Name of Person Who Created
Object
FARR_D_POB_HIS CREATED_BY
CREATED_ON
Date on Which Record Was
Created
FARR_D_POB_HIS CREATED_ON
TIMESTAMP
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_POB_HIS TIMESTAMP
13.3.5 Revenue Contract
DataSource Attributes 0FARR_CONTRACT_ATTR
Use
The DataSource extracts contract data from the FARR_D_CONTRACT table.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 202:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 247
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
Data Modeling
Fields of Origin for the Extraction Structure
Table 203:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
CONTRACT_ID
Revenue Recognition Con
tract ID
FARR_D_CONTRACT CONTRACT_ID
CONTRACT_CAT
Contract Category
FARR_D_CONTRACT CONTRACT_CAT
CUSTOMER_ID
Customer Number
FARR_D_CONTRACT CUSTOMER_ID
CUSTOMER_GRP
Group key
FARR_D_CONTRACT CUSTOMER_GRP
ACCT_PRINCIPLE
Accounting Principle
FARR_D_CONTRACT ACCT_PRINCIPLE
DESCRIPTION
Description of Revenue Ac
counting Items
FARR_D_CONTRACT DESCRIPTION
ADAPTER_ID
Logistics Adapter ID
FARR_D_CONTRACT ADAPTER_ID
PARTNER
Business Partner Number
FARR_D_CONTRACT PARTNER
CONTR_CREATED_ON
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_CONTRACT CONTR_CREATED_ON
NUM_OF_POB
Number of Performance Obli
gations
FARR_D_CONTRACT NUM_OF_POB
TRX_PRICE
Transaction Price
FARR_D_CONTRACT TRX_PRICE
TRX_PRICE_CURK
Currency Key
FARR_D_CONTRACT TRX_PRICE_CURK
STATUS
Contract Status
FARR_D_CONTRACT STATUS
VALIDATE_RESULT
Validate result
FARR_D_CONTRACT VALIDATE_RESULT
MANUAL_CREATED
Manually Created
FARR_D_CONTRACT MANUAL_CREATED
MANUAL_CHANGED
Manually Changed
FARR_D_CONTRACT MANUAL_CHANGED
MANUAL_DELETED
Manually Deleted
FARR_D_CONTRACT MANUAL_DELETED
PRICE_ADJUSTED
Price Adjustment Occurred
on the Contract
FARR_D_CONTRACT PRICE_ADJUSTED
COMPANY_CODE
Company Code
FARR_D_CONTRACT COMPANY_CODE
ALLOC_DIFFER
Adjustment Amplitude
FARR_D_CONTRACT ALLOC_DIFFER
248 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
CREATED_BY
Name of Person who Created
the Object
FARR_D_CONTRACT CREATED_BY
CREATED_ON
Date on Which Record Was
Created
FARR_D_CONTRACT CREATED_ON
LAST_CHANGED_BY
Name of Person Who
Changed Object
FARR_D_CONTRACT LAST_CHANGED_BY
LAST_CHANGED_ON
Date on Which Record Was
Changed
FARR_D_CONTRACT LAST_CHANGED_ON
LAST_CHANGED_BY
Name of Person Who
Changed Object
FARR_D_CONTRACT LAST_CHANGED_BY
13.3.6 Performance Obligation
DataSource Attributes 0FARR_POB_ATTR
Use
The DataSource extracts attributes of performance obligation from the FARR_D_POB table.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 204:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 249
Data Modeling
Fields of Origin for the Extraction Structure
Table 205:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
POB_ID
Performance Obligation ID
FARR_D_POB POB_ID
POB_NAME
Performance Obligation
Name
FARR_D_POB POB_NAME
POB_ROLE
Leading/Linked
FARR_D_POB POB_ROLE
POB_TYPE
Performance Obligation Type
FARR_D_POB POB_TYPE
ACCT_PRINCIPLE
Accounting Principle
FARR_D_POB ACCT_PRINCIPLE
COMPANY_CODE
Company Code
FARR_D_POB COMPANY_CODE
SSP
Standalone Selling Price
FARR_D_POB SSP
SSP_CURK
Currency Key
FARR_D_POB SSP_CURK
QUANTITY
Quantity
FARR_D_POB QUANTITY
QUANTITY_UNIT
Quantity Unit
FARR_D_POB QUANTITY_UNIT
DURATION
Duration
FARR_D_POB DURATION
DURATION_UNIT
Duration Unit
FARR_D_POB DURATION_UNIT
EVENT_TYPE
Fulfillment Event Type
FARR_D_POB EVENT_TYPE
FULFILL_TYPE
Fulfillment Type
FARR_D_POB FULFILL_TYPE
DEFERRAL_METHOD
Deferral Method
FARR_D_POB DEFERRAL_METHOD
START_DATE
Start Date
FARR_D_POB START_DATE
END_DATE
End Date
FARR_D_POB END_DATE
START_DATE_TYPE
Indicator denoting whether
start date can be provided
later
FARR_D_POB START_DATE_TYPE
NO_START_DATE
Indicator denoting whether
start date can be provided
later
FARR_D_POB NO_START_DATE
DISTINCT_TYPE
Performance Obligation Com
position
FARR_D_POB DISTINCT_TYPE
DISTINCT_FULFILL
Indicator denoting whether
POB can be fulfilled distinctly
FARR_D_POB DISTINCT_FULFILL
VALUE_RELEVANT
Indicator identifying whether
milestone billing plan POB
FARR_D_POB VALUE_RELEVANT
STATUS
Performance Obligation Sta
tus
FARR_D_POB STATUS
REVIEW_REASON
Review Reason
FARR_D_POB REVIEW_REASON
REVIEW_DATE
Review Date
FARR_D_POB REVIEW_DATE
250 P U B L IC
SAP Revenue Accounting and Reporting
Reporting
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
PAOBJNR
Profitability Segment Number
(CO-PA)
FARR_D_POB PAOBJNR
FKBER
Functional Area
FARR_D_POB FKBER
GSBER
Business Area
FARR_D_POB GSBER
SEGMENT
Segment for Segmental Re
porting
FARR_D_POB SEGMENT
PRCTR
Profit Center
FARR_D_POB PRCTR
HI_LEVEL_POB_ID
Higher-Level Performance
Obligation ID
FARR_D_POB HI_LEVEL_POB_ID
LEADING_POB_ID
Leading Performance Obliga
tion ID
FARR_D_POB LEADING_POB_ID
BOM_POB_ID
POB ID of the Root POB in the
BOM Structure
FARR_D_POB BOM_POB_ID
CONTRACT_ID
Revenue Recognition Con
tract ID
FARR_D_POB CONTRACT_ID
CUSTOMER_ID
Customer Number
FARR_D_POB CUSTOMER_ID
PARTNER
Business Partner Number
FARR_D_POB PARTNER
ADAPTER_ID
Logistics Adapter ID
FARR_D_POB ADAPTER_ID
VALIDATE_RESULT
Validate Result
FARR_D_POB VALIDATE_RESULT
SOFT_DELETED
Soft-Deleted
FARR_D_POB SOFT_DELETED
TRX_PRICE
Transaction Price
FARR_D_POB TRX_PRICE
FINAL_INVOICE
Indicator for Final Invoice
FARR_D_POB FINAL_INVOICE
FULLY_FULFILLED
Fully Fulfilled
FARR_D_POB FULLY_FULFILLED
CREATED_BY
Name of Person Who Created
the Object
FARR_D_POB CREATED_BY
CREATED_ON
Date on Which Record Was
Created
FARR_D_POB CREATED_ON
LAST_CHANGED_BY
Name of Person Who
Changed Object
FARR_D_POB LAST_CHANGED_BY
LAST_CHANGED_ON
Changed On
FARR_D_POB LAST_CHANGED_ON
13.3.7 Reconciliation Key
DataSource Attributes 0FARR_RECKEY_ATTR
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 251
Use
This DataSource extracts reconciliation key attributes.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 206:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.1
Content Versions RA110
RemoteCube-Capable Yes
Delta-Capable Yes
Extraction from Archives No
Verifiable No
Data Modeling
Fields of Origin for the Extraction Structure
Table 207:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
COMPANY_CODE
Company Code
FARR_D_RECON_KEY COMPANY_CODE
RECON_KEY
Reconciliation Key
FARR_D_RECON_KEY RECON_KEY
Contract_ID
Contract ID
FARR_D_RECON_KEY_ID Contract ID
ACCT_PRINCIPLE
Accounting Principle
FARR_D_RECON_KEY ACCT_PRINCIPLE
STATUS
Status of Revenue Reconcilia
tion Key
FARR_D_RECON_KEY STATUS
GJAHR
Fiscal Year
FARR_D_RECON_KEY GJAHR
POPER
Posting Period
FARR_D_RECON_KEY POPER
CREATED_BY
Name of Person Who Created
the Object
FARR_D_RECON_KEY CREATED_BY
252 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
CREATED_ON
UTC Time Stamp in Short
Form (YYYYMMDDhhmmss)
FARR_D_RECON_KEY CREATED_ON
13.3.8 Contract Status Text
DataSource Texts 0FARR_CONTR_STATUS_TEXT
Use
This DataSource extracts the texts for contract statuses.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 208:
Application Component
0FARR-IO
Exchange Available as of Release SAP APPL 605
Shipment SAP Revenue Accounting and Reporting 1.1
Content Versions RA110
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 253
Data Modeling
Delta Update
Fields of Origin for the Extraction Structure
Table 209:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGU
LANGU
KEY1
ROTEXTKEY1
TXTMD
Medium description
13.3.9 Reconciliation Key Status Text
DataSource Texts 0FARR_RECKEY_STAT_TEXT
Use
This DataSource extracts the texts for reconciliation key statuses.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 210:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
254 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 211:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.10 Contract Category Text
DataSource Texts 0FARR_CONTR_CAT_TEXT
Use
This DataSource extracts the texts for contract categories.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 212:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 255
Data Modeling
Fields of Origin for the Extraction Structure
Table 213:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
CONTRACT_CAT
Contract Category
DESCRIPTION
Description
13.3.11 Event Type Text
DataSource Texts 0FARR_EVT_TYPE_TEXT
Use
This DataSource extracts the texts for event types.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 214:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
256 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 215:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
FARR_C_EVNT_TY_T LANGUAGE
EVENT_TYPE
Event type code
FARR_C_EVNT_TY_T EVENT_TYPE
DESCRIPTION
Description
FARR_C_EVNT_TY_T DESCRIPTION
13.3.12 Performance Obligation Type text
DataSource Texts 0FARR_POB_TYPE_TEXT
Use
This DataSource extracts the texts for performance obligation types.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 216:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 257
Data Modeling
Fields of Origin for the Extraction Structure
Table 217:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
FARR_C_POB_TYP_T LANGUAGE
POB_TYPE
POB type code
FARR_C_POB_TYP_T POB_TYPE
DESCRIPTION
Description
FARR_C_POB_TYP_T DESCRIPTION
13.3.13 Fulfill Type Text
DataSource Texts 0FARR_FULFILL_TYPE_TEXT
Use
This DataSource extracts the texts for fulfillment types.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 218:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
258 P U B L IC
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 219:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.14 Performance Obligation Role Text
DataSource Texts 0FARR_POB_ROLE_TEXT
Use
This DataSource extracts the texts for the Leading/Linked attribute.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 220:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 259
Data Modeling
Fields of Origin for the Extraction Structure
Table 221:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.15 Performance Obligation Status Text
DataSource Texts 0FARR_POB_STAT_TEXT
Use
This DataSource extracts the texts for performance obligation statuses.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 222:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
260 P U B LI C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 223:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.16 Post Category Text
DataSource Texts 0FARR_POST_CAT_TEXT
Use
This DataSource extracts the texts for posting categories.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 224:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 261
Data Modeling
Fields of Origin for the Extraction Structure
Table 225:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.17 Start Date Type Text
DataSource Texts 0FARR_ST_DAT_TYP_TEXT
Use
This DataSource extracts the texts for start date types.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 226:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
262 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 227:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.18 Distinct Type Text
DataSource Texts 0FARR_DIST_TYP_TEXT
Use
This DataSource extracts the texts for composition types (the Composition attribute).
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 228:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 263
Data Modeling
Fields of Origin for the Extraction Structure
Table 229:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.19 Performance Obligation Special Indicator Text
DataSource Texts 0FARR_DEF_S_IND_TEXT
Use
This DataSource extracts the texts for special indicator values (main price, main cost, or allocation difference).
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 230:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
264 P U B L I C
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 231:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.20 Review Reason Text
DataSource Texts 0FARR_REV_RSN_TEXT
Use
This DataSource extracts the texts for review reasons.
Direct Access: Supported (without preaggregation)
Real-time Enabled: No
Released for Data Services: No
Technical Data
Table 232:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 265
Data Modeling
Fields of Origin for the Extraction Structure
Table 233:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
13.3.21 Validation Result Text
DataSource Texts 0FARR_VAL_RES_TEXT
Use
This DataSource extracts the texts for validation results.
Direct Access: Supported (without preaggregation)
Real-Time-Enabled: No
Released for Data Services: No
Technical Data
Table 234:
Application Component
0FARR
Exchange Available as of Release ERP 605
Shipment SAP Revenue Accounting and Reporting 1.0
Content Versions RA100
RemoteCube-Capable Yes
Delta-Capable No
Extraction from Archives No
Verifiable No
266 P U B L IC
SAP Revenue Accounting and Reporting
Reporting
Data Modeling
Fields of Origin for the Extraction Structure
Table 235:
Fields in the Extraction
Structure
Description of the Field in
the Extraction Structure
Table of Origin Field in the Table of Origin
LANGUAGE
Language
KEY1
Key
TXTMD
RSTXTMD
SAP Revenue Accounting and Reporting
Reporting
P U B LI C 267
14 Administration and Maintenance
Revenue Accounting allows users to perform different tasks and to maintain the system.
14.1 Roles
Different revenue accounting roles have different authorizations and can therefore perform different tasks.
14.1.1 Revenue Accountant
SAP_SR_FARR_REV_ACCOUNTANT_A
Use
This role can perform the following tasks:
● Display all details of revenue accounting contracts and performance obligations
● Allocate transaction prices
● Change the start date and end date of revenue accounting contracts
● Combine revenue accounting contracts
● Change account determination
● Review revenue accounting contracts in worklists
● Add manual performance obligations
● Enter manual fulfillments
● Simulate and post revenue in posting runs
● Run reconciliation and analytics reports
Note
Relevant role SAP_SR_FARR_REV_ACCOUNTANT does not include any authorization data. Instead, it only
provides the role menu for the Revenue Accountant role.
14.1.2 Revenue Accounting Administrator
SAP_SR_FARR_REV_ADMIN_A
268
P U B LI C
SAP Revenue Accounting and Reporting
Administration and Maintenance
Use
This role can perform the following tasks:
● Configure, monitor, change, and process revenue accounting items that are sent from various sender
systems and applications
● Check and change relevant Customizing settings and business rules to make sure that all configurations are
correct.
● Schedule posting runs and check logs
This role is typically intended for IT administrators and power users.
Note
Relevant role SAP_SR_FARR_REV_ADMIN does not include any authorization data. Instead, it only provides the
role menu for the Revenue Accounting Administrator role.
14.1.3 Revenue Accounting Auditor
SAP_SR_FARR_REV_AUDITOR_A
Use
This role can view revenue accounting items, revenue accounting contracts, and disclosure data for specific
company codes.
A time-based restriction may apply whereby the role can only view the data of a specific fiscal year. Therefore, it is
possible that this role can only see a fragment of a contract instead of the entire lifecycle of the contract.
Note
Relevant role SAP_SR_FARR_REV_AUDITOR does not include any authorization data. Instead, it only provides
the role menu for the Revenue Accounting Auditor role.
14.1.4 Revenue Accounting RFC User
SAP_SR_FARR_REV_RFCUSER_A
SAP Revenue Accounting and Reporting
Administration and Maintenance
P U B LI C 269
Use
This authorization role for revenue accounting RFC users allows users to send Revenue Accounting Items (RAIs)
from non-SAP source systems. The role must be adjusted to cover the allowed authorization objects and assigned
to an RFC user only.
14.2 Migration from a Legacy System
Use
You may be using a legacy application for revenue recognition and want to migrate to SAP Revenue Accounting
and Reporting.
General Process
Revenue recognition data that resides in the legacy system must be transferred to the new Revenue Accounting
system. This data migration also involves a shift in the accounting method for revenue recognition. Therefore, it is
necessary that historical accounting data can be explained by the old accounting method and that accounting
data occurring after the migration can be explained by the new accounting method. Transactions that occur after
the migration are based on historical data before the migration. Therefore, you must make sure that no more
revenue postings are made to accounting periods before the migration. One way of ensuring this is to close all
periods pre-dating the migration.
Timing of the Migration
The new revenue accounting method is effective on a specific date, known as the takeover date. As of the
takeover date, your company uses the new revenue accounting method for revenue recognition. The revenue
accounting data after the migration is based on the revenue accounting data before the migration. Therefore, the
actual migration can start sometime after the takeover date, when no more revenue postings are made to the old
accounting periods.
As the migration cannot occur until after the takeover date, it must treat documents that are posted before and
after the takeover date differently. Documents that are posted before the takeover date are posted by the legacy
system. Even though these documents are transferred to Revenue Accounting, they must not trigger further
postings. However, the data in these documents forms the basis for further (delta) revenue calculation.
Documents that are posted after the takeover date but prior to the actual migration must be handled by the new
Revenue Accounting system as if the new accounting system had been active when this document was posted.
More Information
For more information about migration from a legacy system, see the SAP Revenue Accounting and Reporting
Administrator’s Guide.
270
P U B LI C
SAP Revenue Accounting and Reporting
Administration and Maintenance
15 Extensibility
The SAP Revenue Accounting and Reporting solution can be enhanced in the following ways:
● Field Extensibility
This solution provides an end-to-end field extensibility. You can route fields from operational documents
(such as sales orders) through various components of this solution up to the final general ledger postings.
This section describes the different types of field extensibility that are supported and the steps to implement
them.
● Business Add-Ins
This solution provides several Business Add-Ins (BAdI) that allow you to change the default behavior. This
section describes the Business Add-Ins that are available.
15.1 Field Extensibility
SAP Revenue Accounting and Reporting provides an end-to-end (field) extensibility. End-to-end means that
information entered in a sales order can be passed to SAP Revenue Accounting and Reporting and used there for
several purposes. The field extensibility concept of SAP Revenue Accounting and Reporting assigns each
customer field to one of the following categories, depending on where the field is actually needed in the solution:
● Fields that are only needed in revenue accounting item processing
These are typically fields needed to define rules for contract combinations or contract composition in BRF+
(such as defining performance obligations and standalone selling prices) but do not need to be displayed in
revenue accounting contracts. These fields only extend the Revenue Accounting Item tables.
● Fields that are also needed in revenue accounting contracts (on performance obligation level)
These fields can be added to the contract user interface and are available to various Business Add-Ins (such
as the BAdI for price allocation). These fields extend Revenue Accounting Item tables as well as the
performance obligation table.
● Fields that are also needed for reporting purposes
These fields extend the Revenue Accounting Item tables, the performance obligation table, and the Revenue
Accounting postings table. These fields can also be passed to general ledger documents.
● Fields on contract (header) level
These fields can be derived in BRF+ and be displayed in the contract user interface. They can also be made
available in several Revenue Accounting applications such as Contract Search, Time-Based Revenue
Calculation, and Revenue Posting Run.
The extensibility concept of SAP Revenue Accounting and Reporting is based on the extensibility concept of the
SAP Easy Enhancement Workbench (EEW), which uses so-called extension include structures to provide field
extensibility. These include structures are included in all relevant tables and internal structures. Therefore, a field
added to one of the structures is automatically made available in all relevant components. Customer fields are
added by creating append structures to the extension includes.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 271
Depending on the categories mentioned above, each field needs to be added to one of following extension include
structures:
● INCL_EEW_FARR_ARL for fields only used in revenue accounting item processing
● INCL_EEW_FARR_POB for fields also used in revenue accounting contracts
● INCL_EEW_FARR_REP for fields also used in reporting
● INCL_EEW_FARR_CONTRACT for fields on contract header level
The first three includes extend performance obligations. The fourth include extends revenue accounting contract
headers. The three-tier design of the performance obligation extension helps you minimize data volume, to avoid
information redundancy, and improve performance and memory consumption. Therefore, you must consider
which fields are needed for a specific purpose:
Fields in theINCL_EEW_FARR_ARL include are available in BRF+ rules after configured as custom-specific fields in
the RAI configuration (see Field Extensibility in Revenue Accounting Item Processing [page 273] for more
details). They are not available for display in the Performance Obligation UI or available for reporting.
Fields in theINCL_EEW_FARR_POB include are available in BRF+ rules and also extend the Performance Obligation
table (FARR_D_POB). Therefore, these fields can be displayed and changed when necessary in the Performance
Obligation user interface. However, they are not available for reporting. For more information about how to extend
the Contract and Performance Obligation UI, see Field Extensibility for Revenue Accounting Contracts [page
274].
Fields in the INCL_EEW_FARR_REP include are available in BRF+ rules, in performance obligations, and in all
Revenue Accounting postings (table FARR_D_POSTING). These fields are available in Revenue Accounting data
sources and can be passed to FI-GL and CO (see Field Extensibility for Revenue Reporting [page 276] for more
details).
Fields in the INCL_EEW_FARR_CONTRACT include can be displayed in the contract (header) user interface and are
available in various reports as selection criteria. These fields have to be derived in BRF+ depending on the line
item information (see the Add Contract Fields to Selection Criteria [page 276] for more details).
Though it would be safe to add all item fields toINCL_EEW_FARR_REP (because then they were available all over
the solution), it is recommended to really think about where the fields are needed and where not – because for
example the posting table will become very big and unnecessary fields will have a negative effect with regards to
performance and memory consumption.
If a field is assigned to the wrong include, you can move it to another include. However, to avoid database
conversions, you must make the move operation only in one direction. Specifically, none of the tables should have
less fields after the move. For example, it is possible to delete a field from INCL_EEW_FARR_ARL and add it to
INCL_EEW_FARR_POB.
Note
Make sure that the fields stored in the above extension includes are not more than 50.
272
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
15.1.1 Field Extensibility in Revenue Accounting Item
Processing
You can add customer fields to revenue accounting items. If you enhance revenue accounting items, the interface
for creating revenue accounting items is enhanced. In addition, the database tables that store revenue accounting
items are enhanced.
To do so, you first have to add the customer fields to the INCL_EEW_FARR_ARL, INCL_EEW_FARR_POB or
INCL_EEW_FARR_REP extension include). After the fields are added, they are available for Revenue Accounting
Item class configuration. The fields should only be added to order item classes, as they are currently not
supported for other class types. (You can add them to classes of other class types anyway. However, they are
neither filled nor evaluated in Revenue Accounting.
By using the Configuration of Revenue Accounting Item classes (transaction FARR_RAI_CONF), you can add and
activate the customer specific fields for status raw and/or status processable and processed. Always select both
statuses, to make the fields available in the following components (BRF+, performance obligations, and so on)
1. Select the Revenue Accounting Item class to which you want to add the fields.
2. Choose Customer Fields and select the fields that you want to add.
3. Mark them for use for items in status raw or items in status processable or processed.
4. Save and activate your changes.
5. Generate the Revenue Accounting Item class by using transaction FARR_RAI_GEN or by using the menu
option Environment Generation .
After you have completed this procedure, the custom fields are part of all internally used structures and the
database tables that store revenue accounting items. The fields may be displayed in the monitor for revenue
accounting items. In the layout of the list, add the custom fields to the list of displayed fields in the respective
layout.
15.1.1.1 Field Extensibility for Rules (BRF+)
After customer fields are configured for the order item RAI class, such as RAI class SD01 for SD, they are also
available in BRF+. All functions, such as Process POB, provide a structure parameter, such as IS_SD01_BRF for
the SD Application Template. The structure is bound to a DDIC structure that already contains the customer
fields. To make the fields available in the BRF+ structure, you must update its DDIC binding. To do this, maintain
your application that was copied from the template delivered by SAP (for example, template
FARR_AP_SD_PROCESS_TEMPLATE for the SD-specific application) and select one of the functions (for example,
FC_PROCESS_POB). On the Signature tab, select the input structure (for example, IS_SD01_BRF), choose Edit
and then choose Refresh Binding. The structure now contains the configured customer fields, which can be used
in the assigned rules and decision tables.
With function Process Header (FC_PROCESS_HEADER ), you can derive fields appended to the
INCL_EEW_FARR_CONTRACT include. These fields are then available on contract header level. To do this, update
the binding of BRF+ structure ES_HEADER (can be found as the result structure of function
FC_PROCESS_HEADER).
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 273
15.1.2 Field Extensibility for Revenue Accounting Contracts
For Revenue Accounting Contracts, both contract and performance obligation can have customer fields.
● For fields on contract level, add the customer fields to theINCL_EEW_FARR_CONTRACT include.
● For fields on performance obligation level, add the customer fields to the INCL_EEW_FARR_POB or
INCL_EEW_FARR_REP include.
You can add customer fields to the user interface using the following mechanism:
● Application Customizing
Application customizing is client-specific. You can transport the customizing to target systems like normal
IMG customizing. It is simpler than Application Configuration.
● Application Configuration
Application Configuration is cross-client. You can also transport the configuration. It involves more steps.
For more information, see the following help documentation:
https://help.sap.com/saphelp_nw73ehp1/helpdata/en/b1/74386acf234d539b4022e23822025f/frameset.htm
You can find all customizing and configuration by using the Web Dynpro application WD_ANALYZE_CONFIG_USER.
15.1.2.1 Add Customer Fields to the Contract and Performance
Obligation UI by using Customizing
In Revenue Accounting, the following Web Dynpro applications or application configurations can be customized to
add customer fields on the UI:
● Account Determination (FARR_ACCT_DETERMINATION_OVP/FARR_ACCT_DETERMINATION_OVP)
● Add Contracts to Review List (FARR_ADD_CONT_TO_REVIEW_LIST/FARR_ADD_CONT_TO_REVIEW_LIST)
● Price Allocation (FARR_ALLOC_PRICE_OVP/FARR_ALLOC_PRICE_OVP)
● Resolve Change Conflicts (FARR_CONFLICT_OVP/FARR_CONFLICT_OVP_AC)
● Contract Comprehensive View (FARR_CONTRACT_ALL_OVP/FARR_CONTRACT_ALL_OVP)
● Manual Fulfillments (FARR_CONTRACT_MAN_FULFILL_OVP/FARR_CONTRACT_MAN_FULFILL_OVP)
● Contract Standard View (FARR_CONTRACT_MGMT_OVP/FARR_CONTRACT_MGMT_OVP)
● Contract Search (FARR_CONTRACT_SEARCH_OVP/FARR_CONTRACT_SEARCH_OVP)
● Contract Combination (FARR_MANUAL_COMBINE_OVP/FARR_MANUAL_CONTRACT_COMBINE_OVP)
● Performance Obligation Detail (FARR_POB_DETAIL_OVP/FARR_POB_DETAIL_OVP)
● Performance Obligation Overview (FARR_POB_MGMT_OVP/FARR_POB_MGMT_OVP)
● Add Manual Performance Obligation (FARR_POB_MGMT_OVP/FARR_POB_MGMT_OVP)
Choose POPUP_ADD_POB in Navigation and then choose the Form UIBB whose configuration name is
FARR_POB_MGMT_DETAIL_EDIT_CC to perform the configuration.
● Revenue Schedule (FARR_POB_REV_RECOG_OVP/FARR_POB_REV_RECOG_OVP)
● Change Revenue Schedule (FARR_SPREADING_CHANGE_OVP/FARR_SPREADING_CHANGE_OVP)
● Revenue Posting and Simulation (FARR_ACCR_RUN/FARR_ACCR_RUN_AP)
● Shift Contracts to next period (FARR_CONTRACT_SHIFT/FARR_CONTRACT_SHIFT_AP)
274
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
● Job Monitor (FARR_JOB_MONITOR/FARR_JOB_MONITOR)
● Contract Liability Posting (FARR_LIAB_RUN/FARR_LIAB_RUN_AP)
● Revenue Transfer to GL/CO Schedule (FARR_PERIODIC_RUN/FARR_PERIODIC_RUN)
● Reconciliation for G/L Accounts Between RA and GL (FARR_RECON_ACCOUNT_RA_GL/
FARR_RECON_ACCOUNT_RA_GL_AP)
● Reconciliation Contracts/FI Documents (FARR_RECON_FI_USER/FARR_RECON_FI_USER_CON)
● Reconciliation RA Postings and GL Totals (FARR_RECON_POSTING_GL/FARR_RECON_POSTING_GL_CC)
● Revenue Posting Reversal (FARR_RECON_KEY_STATUS/FARR_RECON_KEY_STATUS)
● Contract Shift History (FARR_SHIFT_HISTORY_AUDIT/FARR_SHIFT_HISTORY_AUDIT_AC)
● Time-based Revenue Calculation (FARR_TM_REV_RUN/FARR_TM_REV_RUN_AP)
● Disaggregation of Revenue by Customer (FARR_DISAGGR_REVENUE_CUSTOMER/
FARR_DISAGGR_REVENUE_CUSTOMER)
● Disaggregation of Revenue by Customer Group (FARR_DISAGGR_REVENUE_CUST_GRP/
FARR_DISAGGR_REVENUE_CUST_GRP)
● Disaggregation of Revenue by POB type (FARR_DISAGGR_REVENUE_POB_TYPE/
FARR_DISAGGR_REVENUE_POB_TYPE)
● Posted Amount by Contract (FARR_POSTED_AMOUNT_CONTRACT/FARR_POSTED_AMOUNT_CONTRACT_CC)
● Posted Amount by POB type (FARR_POSTED_AMOUNT_POB_TYPE/FARR_POSTED_AMOUNT_POB_TYPE_CC)
You can find all relevant application configurations in the package FARR_CONTRACT_UI and FARR_ANALYTICS, in
the following folders:
● Web Dynpro Web Dynpro Applicat. (up to SAP SAP NetWeaver 7.3)
● Web Dynpro FPM Application ( SAP NetWeaver 7.4 or higher)
To customize a Web Dynpro application, perform the following steps:
1. Start transaction SE80.
2. Choose Workbench Edit Object (Shift-F5)
3. For a system based on SAP NetWeaver 7.4 or higher, choose Enhanced Options first
4. On the Web Objects tab, enter the Web Dynro Application Configuration of one of the applications mentioned
above into the Application Configuration field.
5. From the menu, choose Web Dynpro ConfigurationTest Execute in Administration Mode
6. Click Adapt Configuration in the upper-right corner.
7. An error message appears that reads “The specified configuration does not yet exist”. Choose Create to
continue to create the Component customizing
8. Enter a Description for the customizing on the dialog box that appears.
9. Specify a customizing request if needed from the Select Transport Request dialog box.
10. Now you can repeat the same procedure recursively to customize the current configuration and the
configurations of the contained child components.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 275
15.1.2.2 Add Contract Fields to Selection Criteria
In the following applications and application configurations, custom-specific information on contract header level
can be used for the selection of contracts to be processed:
● Contract Search UI (FARR_CONTRACT_SEARCH_OVP/FARR_CONTRACT_SEARCH_OVP)
● Revenue Posting and Simulation (FARR_ACCR_RUN/FARR_ACCR_RUN_AP)
● Revenue Transfer to GL/CO Schedule (FARR_PERIODIC_RUN/FARR_PERIODIC_RUN)
● Time-Based Revenue Posting (FARR_TM_REV_RUN/FARR_TM_REV_RUN_AP)
● Contract Liability Posting (FARR_LIAB_RUN/FARR_LIAB_RUN_AP)
● Shift Contracts to Next period (FARR_CONTRACT_SHIFT/FARR_CONTRACT_SHIFT_AP)
To make the custom specific fields available for selection, perform the following steps:
1. Customize the component of the selection component (as described earlier in this document) or create a new
Web Dynpro application configuration and assign it to a custom-specific role.
2. Change the configuration of the FPM_SEARCH_UIBB component.
3. Choose Edit Search Attributes. The custom-specific fields are available in the Available Search Criteria
section in the dialog box.
4. From the Available Search Criteria list on the left side, choose the customer fields that you want to add, and
then choose Add Search Criteria to add them to the Selected Search Criteria on the right side.
5. The customer fields are available for selection.
15.1.2.3 Customer Field Validation
Customer fields that can be changed by the user must be validated. You can validate customer fields by using
enhancement spot FARR_POB_CUST_VALIDATION, Business Add-In FARR_BADI_POB_CUST_VALIDATION, and
method POB_VALIDATION.
The importing parameter IS_POB_DATA_BUFFER contains all fields of one performance obligation (not only the
customer fields). You can write code to validate any field on performance obligations by using this BAdI.
The importing parameter IO_MSG_HANDLER is an instance of a message handler. You can add your validation
result as standard ABAP messages to the message handler. To understand adding messages to the message
handler, you can refer to method CL_FARR_CONTRACT_CHECKER ->CHECK_POB_COMPANY_CODE.
15.1.3 Field Extensibility for Revenue Reporting
Fields needed for reporting must be added to structure INCL_EEW_FARR_REP. This include also extends the
Revenue Accounting Posting table (FARR_D_POSTING).
276
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
15.1.3.1 Passing Information to General Ledger Documents
To include customer fields in the general ledger documents that are created by Revenue Accounting and
Reporting, you must extend the Revenue Accounting and Reporting (INCL_EEW_FARR_REP) and General Ledger
(CI_COBL) structures with the same set of fields (the field names must be the same). To extend the general
ledger document and ledgers, define customer fields in the following Customizing activity:
Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers Fields Customer
Fields . All fields that are included in both CI_COBL and INCL_EEW_FARR_REP are automatically transferred
into general ledger documents.
To change standard general ledger document fields (fields that are not in the CI_COBL structure), you must
complete the following tasks:
1. Enhance structure INCL_EEW_FARR_POSTING.
2. Implement BAdI FARR_POSTING_ENHANCEMENT in Enhancement Spot FARR_ES_POSTING.
The BAdI FARR_POSTING_ENHANCEMENT provides a method PROCESS_CUST_FIELDS. You can use this method
to set non-customer fields in general ledger documents.
Caution
Be careful when you change standard fields. Changing standard fields may cause incorrect general ledger
documents. You may make these changes at your own risk.
Method PROCESS_CUST_FIELDS has two parameters:
● IS_RR_LINE_ITEM contains all information for a Revenue Accounting posting item (including customer fields
defined in INCL_EEW_FARR_REP)
● CS_ACC_IT contains all fields of the corresponding general ledger document item.
15.1.3.2 Activate Enhanced Fields in Datasources
The datasource 0FARR_RA_10, which is based on the Revenue Accounting posting data (table
FARR_D_POSTING), automatically includes all fields defined in the INCL_EEW_FARR_REP structure. Therefore, the
datasource automatically fetches the fields that you have appended to this structure. Check the availability and
visibility of your fields by using transaction RSA6. After running the transaction, select node 0FARR / Financial
Accounting Revenue Recognition in the hierarchy. The datasource 0FARR_POB_ATTR, which is based on
performance obligation data, automatically includes all fields defined in the INCL_EEW_FARR_POB structure.
Therefore, the datasource automatically fetches the fields that you have appended to this structure. Check the
availability and visibility of your fields by using transaction RSA6.
After you have made these changes, the enhanced fields in the datasources become visible to BW objects, such
as Infoproviders and online data providers (ODP). For the data extraction to work, you must refresh the
corresponding BI modeling.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 277
15.1.3.3 Add Customer Fields for Comparative Report of
Transition
You perform transition by copying data from an existing accounting principle which has already been managed by
Revenue Accounting and Reporting to a new accounting principle via transaction FARR_RAI_PROC_NEWACP. After
the transition process is finished or even after both accounting principles are switched to productive mode, you
can run the transaction FARR_PREPARE_COMP to perform the comparison of allocated amount, recognized
revenue/cost, invoice correction between the two accounting principles. Then you can use the report Display the
Result of Comparative Report in Reporting of the Netweaver Business Client (NWBC) menu to display the
comparison result.
To add customer fields or fields that already exist in the performance obligation table (FARR_D_POB) to this
comparative report table FARR_D_COMP_TRAN, you need to take the following steps:
1. Create an append structure for the structureINCL_EEW_FARR_TRANSITION and then add fields to this new
append structure.
Note
○ If the added fields exist in FARR_D_POB but do not exist in FARR_D_COMP_TRAN (names of these field
do not start with YY or ZZ), the system reports a warning message when you activate the structure. If
you really want to add them, just ignore the warning.
○ If the added fields come from FARR_D_POB, then the data of all the added fields will be automatically
put into the result table FARR_D_COMP_TRAN. Internally, SAP code uses MOVE-CORRESPONDING
statement to do it.
2. If you add other customer fields which do not exist in FARR_D_POB, then you can implement the Business
Add-In (BAdI)FARR_BADI_COMP_TRAN_ADD_STRUC to write the data to the result table FARR_D_COMP_TRAN.
All fields added into the structure INCL_EEW_FARR_TRANSITIONwill be automatically available in the report
Display the Result of Comparative Report.
● For the Search part, just click on the dropdown list box of the existing selection criteria, then you can see the
customer fields listed at the end of the list.
● For the Result list, just click on the Settings link on the right-top of the list, then you can see the customer
fields are listed in the Hidden Columns area.
15.2 Business Add-Ins
Besides field extensibility, Revenue Accounting can also be enhanced by providing several Business Add-Ins
(BAdI) that allow you to change the default behavior. This section describes the Business Add-Ins that are
available.
15.2.1 Validation of Status Change
With Enhancement Spot ES_FARR_FOUNDATION, BAdI FARR_ACPR_BUKR_CHECKS you can define custom-
specific checks to validate the status switch for a company code / accounting principle combination. The BAdI
278
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
has only one method, CHECK, with parameters IT_ACPR_BUKRS_OLD and IT_ACPR_BUKRS_NEW which denote
the old and new status and transfer date for the selected company codes and accounting principles. Parameter
CS_ERROR_MESSAGE is used to pass error messages that should prevent the status switch. See the
documentation of
BAdI FARR_ACPR_BUKR_CHECKS.
15.2.2 Enhance Revenue Accounting Items (Raw Items)
By using enhancement spot FARR_ARL and BAdI FARR_BADI_RAI0, you can fill additional attributes of Revenue
Accounting Items with status raw (RAI0 ) depending on the Revenue Accounting Item class. You can also
introduce additional checks that you want to perform before the raw items are saved to the database.
The IF_FARR_BADI_RAI0 interface for this BAdI is used for Business Add-In (BAdI) implementation
FARR_BADI_RAI0 of enhancement spot FARR_ARL. It provides two methods:
● ENRICH
This method is executed before the enrichment functionality that SAP delivers for each interface component
is executed.
You can implement checks for the Revenue Accounting Items per Revenue Accounting Item class in this
method. It contains the following parameters:
Table 236:
Parameter Type Data Type Description
IV_RAIC Importing Type FARR_RAIC Revenue Accounting Item
Class
CT_RAI0_MI Changing Type
FARR_TT_RAI0_MI_ALL
Table Type for
FARR_S_RAI0_MI_ALL
CT_RAI0_CO Changing Type
FARR_TT_RAI0_CO_ALL
Table Type for
FARR_S_RAI0_CO_ALL
CT_MESSAGES Changing Type FARR_TT_RAI_MSG Table Type for
FARR_S_RAI_MSG
● CHECK_BEFORE_SAVE
This method is executed before raw Revenue Accounting Items (RAI0) are saved to the database. It contains
the following parameters:
Table 237:
Parameter Type Data Type Description
IV_RAIC Importing Type FARR_RAIC Revenue Accounting Item
Class
IT_RAI0_MI Importing Type
FARR_TT_RAI0_MI_ALL
Table Type for
FARR_S_RAI0_MI_ALL
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 279
Parameter Type Data Type Description
IT_RAI0_CO Importing Type
FARR_TT_RAI0_CO_ALL
Table Type for
FARR_S_RAI0_CO_ALL
CT_MESSAGES Changing Type FARR_TT_RAI_MSG Table Type
forFARR_S_RAI_MSG
Note
In case of errors, the changing parameter CT_MESSAGES has to be filled. The message structure contains
attributes for the error message, as well as the key fields for the Revenue Accounting Item. It is crucial for
the correct processing of the erroneous Revenue Accounting Items that these key fields are filled in the
message structure.
Important: This BAdI is intended for custom Revenue Accounting Item classes only. The enrichment and
checks of raw revenue accounting data that are delivered by SAP are implemented in class
CL_FARR_RAI_IFCOMP.
For more information, see the documentation of BAdI FARR_BADI_RAI0.
15.2.3 Enhance Revenue Accounting Items (Processable Items)
By using enhancement spot FARR_ARL and BAdI FARR_BADI_RAI2, you can fill additional attributes of Revenue
Accounting Items with status raw (RAI2) depending on the Revenue Accounting Item class. You can also
introduce additional checks you want to perform before the raw items are saved to the database.
The IF_FARR_BADI_RAI2interface for this BAdI is used for Business Add-In (BAdI) implementation
FARR_BADI_RAI2 of enhancement spot FARR_ARL. It provides two methods:
● ENRICH
This method is executed before the enrichment functionality that SAP delivers for each interface component
is executed.
You can implement checks for the Revenue Accounting Items per Revenue Accounting Item class in this
method. It contains the following parameters:
Table 238:
Parameter Type Data Type Description
IV_RAIC Importing Type FARR_RAIC Revenue Accounting Item
Class
CT_RAI2_MI Changing Type
FARR_TT_RAI2_MI_ALL
Table Type for
FARR_S_RAI2_MI_ALL
CT_RAI2_CO Changing Type
FARR_TT_RAI2_CO_ALL
Table Type for
FARR_S_RAI2_CO_ALL
280 P UB L I C
SAP Revenue Accounting and Reporting
Extensibility
Parameter Type Data Type Description
CT_MESSAGES Changing Type FARR_TT_RAI_MSG Table Type for
FARR_S_RAI_MSG
● CHECK_BEFORE_SAVE
This method is executed before processable Revenue Accounting Items (RAI2) are saved to the database. It
contains the following parameters:
Table 239:
Parameter Type Data Type Description
IV_RAIC Importing Type FARR_RAIC Revenue Accounting Item
Class
IT_RAI2_MI Importing Type
FARR_TT_RAI2_MI_ALL
Table Type for
FARR_S_RAI2_MI_ALL
IT_RAI2_CO Importing Type
FARR_TT_RAI2_CO_ALL
Table Type for
FARR_S_RAI2_CO_ALL
CT_MESSAGES Changing Type FARR_TT_RAI_MSG Table Type for
FARR_S_RAI_MSG
Note
In case of errors, the changing parameter CT_MESSAGES has to be filled. The message structure contains
attributes for the error message, as well as the key fields for the Revenue Accounting Item. It is crucial for
the correct processing of the erroneous Revenue Accounting Items that these key fields are filled in the
message structure.
For more information, see the documentation of BAdI FARR_BADI_RAI2.
15.2.4 Combination of Contracts
By using enhancement spot FARR_ARL and BAdI FARR_BADI_CONTRACT_COMBINATION, you can determine how
Revenue Accounting Items are grouped into revenue accounting contracts. For all Revenue Accounting Items that
belong to the same contract, the same contract ID needs to be set.
This BAdI is executed during processing of Revenue Accounting Items. It is only called for order item RAIs and
only as long as no performance obligation exists in the RA-engine that represents this order item.
The IF_FARR_RAI2_CONTR_COMB interface for this BAdI is used for Business Add-In (BAdI) implementation
FARR_BADI_CONTRACT_COMBINATION of enhancement spot FARR_ARL. It provides the method
COMBINE_CONTRACT.
This method is executed before Revenue Accounting Items of the order item type are processed. By default the
example class implementation combines the contract by reference ID and reference type fields.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 281
You can implement your own combination logic in this method.
The method contains the following parameters:
Table 240:
Parameter Type DataType Description
IT_RAW_POB
Importing Type FARR_TT_RAW_POB Raw Data for Performance
Obligation Creation
ET_COMBINED_CONTRACTS
Exporting Type
FARR_TT_CONTR_MAPPING
Table of Mapping entries of
contract combination
In case of errors, the exception CX_FARR_MESSAGE has to be raised.
For more information, see the documentation of BAdI FARR_BADI_CONTRACT_COMBINATION.
15.2.5 Price Allocation
SAP Revenue Accounting and Reporting provides two BAdIs for processing price allocation.
Enhancement spot FARR_ALLOCATION_ENGINE and BAdI FARR_BADI_ALLOCATION_ENGINE are defined to
perform price allocation. The interface method IF_FARR_ALLOCATION_ENGINE~PROCESS_ALLOCATION has
importing parameter IT_POB_DATA, which contains all performance obligation information (including the
customer fields). You can write your own BAdI implementation to perform price allocation based on any
information available in the performance obligations. The standard SAP implementation for price allocation is
implemented in class CL_FARR_ALLOCATION_ENGINE. For more information about the method
PROCESS_ALLOCATION, see the BAdI documentation ofFARR_BADI_ALLOCATION_ENGINE.
Enhancement spot FARR_ALLOCATION_METHOD and BAdI FARR_BADI_ALLOCATION_METHOD allow you to define
your own processes and calculations of price allocation at the level of a group (sub-structure) of performance
obligations. Interface method
IF_FARR_ALLOCATION_METHOD~ALLOCATE_COND_TYPES is used to allocate
condition types from nodes to subnodes. The implementation determines how an amount on a node is allocated
to its subnodes, and the process is repeated for each node of the tree. For more information about method
ALLOCATE_COND_TYPES and its parameters, see the BAdI documentation.
The BAdI FARR_BADI_ALLOCATION_METHOD is called in the standard implementation of BAdI
FARR_ALLOCATION_ENGINE. You can also use it in your own implementation of this BAdI to allocate amounts
down the hierarchy.
See the BAdI documentation FARR_BADI_ALLOCATION_METHOD.
15.2.6 Deferral Method
By using enhancement spot FARR_DEFERRAL_METHOD and BAdI FARR_BADI_DEFERRAL_METHOD, you can
define your own spreading of revenue for time-based performance obligations. The BAdI provides method
GENERATE_FULFILL_ENTRY to allocate the amount provided in parameter IS_DEFERRAL_METHOD to the periods
282
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
in the duration. You must provide a value for each period of the contract lifecycle (the time between START_DATE
and END_DATE.
For more information about how to implement the BAdI, see the BAdI documentation and example
implementations, such as FARR_DEFERRAL_METHOD_S.
Note
● If performance obligation with period-related deferral method is defined, the duration must not be less
than one period.
● If performance obligation with date-related deferral method is defined, the duration must be greater than
one day.
15.2.7 Account Assignment Derivation
By using enhancement spot FARR_DERIVE_ACCT_ASSIGNMT and BAdI FARR_BADI_ACCT_ASSIGNMT you derive
account assignments for manually created performance obligations. The BAdI provides two methods:
● DERIVE_DEFAULT_ACCT_ASSIGNMENT:
This method is called when the system displays a dialog box for the user to create a new performance
obligation. Here you can specify default account assignments based on other account assignments in the
contract. Therefore, all contract data, including all performance obligations, is provided in this method.
● DERIVE_PAOBJNR:
This method is called when the user changes attributes of the manually created performance obligation that
might affect the Profitability Segment of the performance obligation. In that case, the method should return a
new Profitability Segment from the relevant characteristics. Additionally, all contract information is passed
into the method.
For more information, see the documentation of documentation of BAdI FARR_BADI_ACCT_ASSIGNMT.
15.2.8 Custom Validations
By using enhancement spot FARR_POB_CUST_VALIDATIONand BAdI FARR_POB_CUST_VALIDATION, you can
add your own validations for performance obligations. The BAdI provides method POB_VALIDATION with the
following parameters:
● IS_POB_DATA_BUFFER: the performance obligation to be checked
● IO_MSG_HANDLER: a reference to a message handler object
To understand adding messages to the message handler, you can refer to method
CL_FARR_CONTRACT_CHECKER CHECK_POB_COMPANY_CODE .
For more information, See the documentation of BAdI FARR_POB_CUST_VALIDATION.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 283
15.2.9 Posting Enhancements
Enhancement spot FARR_POSTING_ENHANCEMENT contains BAdI FARR_POSTING_ENHANCEMENT and its method
PROCESS_CUST_FIELDS. You can use this BAdI to set standard fields, such as material number and transaction
type, from other fields available in SAP Revenue Accounting and Reporting or available in include
INCL_EEW_FARR_REP.
Be careful when you change standard fields. Changing standard fields may cause incorrect general ledger
documents. You may make these changes at your own risk.
Method PROCESS_CUST_FIELDS has two parameters:
● IS_RR_LINE_ITEM
This parameter contains all information for a Revenue Accounting posting item (including customer fields
defined in INCL_EEW_FARR_REP.
● CS_ACC_IT
This parameter contains all fields of the corresponding general ledger document item.
For more information, See the documentation of BAdI FARR_POSTING_ENHANCEMENT.
15.2.10 Compound Fulfillments
By using enhancement spot FARR_COMPOUND_FULFILLMENT and BAdI FARR_BADI_COMPOUND_FULFILLMENT,
you can create fulfillment entries for fulfillment events that occur on non-distinct performance obligations.
Fulfillment events that occur on non-distinct performance obligations can only be accounted for on their
corresponding compound performance obligations. This BAdI lets you apply your own logic to assess the
completion of the compound performance obligation when events occur on its non-distinct Performance
Obligations. For example, when a fraction of a non-distinct performance obligation is fulfilled, you can determine
how this "partial" fulfillment should progress the compound performance obligation toward its completion.
The BAdI provides method DERIVE_FULFILLMENT to create the fulfillment for the compound performance
obligation. Input parameters include the triggering event on the non-distinct performance obligation, the
performance obligations of the contract, and the fulfillment history of the compound performance obligation. The
method has to return the calculated fulfillment entries for the compound performance obligation.
For more information, see the BAdI documentation.
15.2.11 Review Worklist Enhancements
By using enhancement spot FARR_BADI_SET_REVIEW_WORKLIST and BAdI
FARR_BADI_SET_REVIEW_WORKLIST, you can perform additional checks when the user chooses Mark as
Reviewed on the Regular Monitoring Worklist. You can also use this BAdI to define additional selection criteria for
the worklist. The BAdI provides the following methods:
● SET_CUSTOMER_FIELDS:
This method is called when the user chooses Mark as Reviewed on the Regular Monitoring Worklist. You can
add your own checks. The Input parameter is the ID of the corresponding performance obligation and output
284
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
parameters include a table of messages and information about whether the review status has to be kept or
can be changed to processable as requested by the user.
● SET_CUSTOMER_SEL_CRITERIA
In this method, you can specify additional selection criteria for the Review Worklist.
15.2.12 Change Mode Determination of Performance
Obligations
By using Enhancement Spot FARR_CHANGE_MODE_DETERMINATION and BAdI
FARR_CHANGE_MODE_DETERMINATION, you can determine the change mode (Retrospective or Prospective) of
specific performance obligations in one contract during contract modification.
The BAdI provides two methods:
● DETERMINE_CHANGE_MODE:
This method determines the change mode (Retrospective or Prospective) for performance obligations that
are included in the allocation of the transaction price (excluding performance obligations marked as “Exclude
from Allocation” and lower-level performance obligations under such performance obligations) in the
contract. It returns only one value for the Change Mode parameter for all involved performance obligations. In
this way, the change mode can only be determined for the complete set of performance obligations, instead
of for each individual performance obligation.
● DETERMINE_CHANGE_MODE_EX_ALLOC:
This method determines the change mode for those performance obligations that are marked as Exclude
from Allocation. It returns different change modes for individual performance obligations.
For more information, see the documentation of BAdI FARR_CHANGE_MODE_DETERMINATION.
15.2.13 RAI Reconciliation with non-SAP Sender Components
Transaction FARR_CHECK_CONS provides some functionality to reconcile RAIs between SAP Revenue Accounting
and Reporting and sender systems. Native support is available only for SAP sender components, such as Sales
and Distribution (SD) and Contract Accounting (CA). Within the end-to-end extensibility of SAP Revenue
Accounting and Reporting, you can use transaction FARR_CHECK_CONS to address reconciliation needs for non-
SAP RAI sender components.
To integrate with a non-SAP RAI sender component, you can implement the two BAdIs of enhancement spot
FARR_CHECK_ES. The implementation of the BAdIs enables a generic SAP framework to:
● Establish technical communications with a non-standard SAP sender component.
● Pull reconciliation relevant data from the sender component.
○ Phase 1: Request IDs of Revenue Accounting-relevant operational documents that meet certain selection
criteria.
○ Phase 2: Reconciliation-relevant RAI attributes to a set of operational document IDs as a sender
component supposedly has sent to SAP Revenue accounting and Reporting.
This section only addresses the part of BAdI implementation that resides in Revenue Accounting. Corresponding
functionality must be available in the sender component in order to deliver the requested data. By using the BAdI
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 285
implementations, you can control how communications from Revenue Accounting to the sender component are
established. You can use RFC or any other protocol supported by SAP.
From the enhancement spot FARR_CHECK_ES, you must implement interface IF_FARR_CHECK_SELECTION
(BAdI FARR_BADI_CHECK_SELECTION) for Phase 1 and IF_FARR_CHECK (BAdI FARR_BADI_CHECK) for Phase
2.
Method IF_FARR_CHECK_SELECTION~SELECT_DOCUMENTS is called during Phase 1 for the determination of the
reconciliation pool (operational document IDs meeting the selection execution parameters of transaction
FARR_CHECK_CONS). During Phase 2, only RAI attributes to these operational documents are accessed on both
sides for detailed reconciliation. The implementation of the method must call function module
FARR_CHECK_SET_OBJKEYS_STATUS or any wrapper of this method that is appropriate for the RAI sender
platform (such as a Web service) to send back the results.
Method IF_FARR_CHECK~GET_DOCUMENT is called many times during Phase 2, always with a package of
operational document IDs. From the document key information sent in parameterIT_CHECK_SIM determine all
related documents (like orders, fulfillments, etc.) and provide the information in the corresponding change
parameters.
The SAP sender components CA and SD rely on the same framework for RAI reconciliation between the Revenue
Accounting and Sender Component. Therefore, it is recommended that you learn how transaction
FARR_CHEC_CONS works for SAP sender components, including required technical configurations. However, note
that the communications with a non-SAP system or via a non-SAP communication protocol require a different
configuration that must be performed outside the SAP landscape. You may examine the SAP implementation of
the above-mentioned BAdI methods to learn how to do the same for your own sender components.
For example, the BAdI implementations for the supported SAP sender components are FARR_RAI_CHECK_SD
and FARR_BADI_CHECK_SELECTION_SD.
15.2.14 Add Customer Fields for Comparative Report of
Transition
By using enhancement spot FARR_COMP_TRAN_ADD_STRUC and BAdI FARR_BADI_COMP_TRAN_ADD_STRUC,
you can write the customized field data which does not exist in FARR_S_POB_TRAN_COMP_ENH to result table
FARR_D_COMP_TRAN.
The BAdI provides one methods:
● APPEND_EXTRA_COLUMN
In this method, you can select value for customized field data and write them to enhance structure for result
table INCL_EEW_FARR_TRANSITION.
This method contains following parameters:
● IS_UNION
This parameter provides mapping relationship of performance obligation/contract ID between Accounting
Principles with group ID. The group ID is an identification to show a closure relationship of contracts between
old and new account principles during transition.
● IS_TRAN_COMP_ENH
This parameter provides information of collected performance obligations.
286
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
● IS_COMP_TRAN
This parameter provides value in result list without extension include.
● CS_RESULT
This parameter changes calculated value of standard or customer-specific fields existing in extension include
INCL_EEW_FARR_TRANSITION into result list.
15.2.15 Distributing Contract Liability/Asset and Unbilled
Receivable/Deferred Revenue into POB Level
By using Enhancement spot FARR_DIST_NET_CLCA_AMT_TO_POB and BAdI
FARR_DIST_NET_CLCA_AMT_TO_POB, you can distribute contract liability/asset and unbilled receivable/deferred
revenue at performance obligation level. This BAdI also supports gross case in which contract liability and asset of
performance obligations in the same contract are all displayed.
The BAdI provides the following two methods:
● DISTRIBUTE_LIABILITY_ASSET
This method is used to distribute contract liability and asset.
● DISTRIBUTE_DEFERRED_UNBILLED
This method is used to distribute deferred revenue and unbilled receivable.
The method DISTRIBUTE_LIABILITY_ASSET contains the following parameters:
● IS_CONT_AMT_LIABILITY_ASSET
This parameter provides all information of contract liability at contract level. You can compare the value
inside when calculating contract liability and asset at performance obligation level.
● IT_POB_DATA_AMT
This parameter provides all the details which you need to distribute contract liability and asset at
performance obligation level.
● ET_POB_AMT_LIABILITY_ASSET
This parameter contains the final result after you distributed the contract liability and asset on performance
obligation level.
The method DISTRIBUTE_DEFERRED_UNBILLED contains the following parameters:
● IS_CONTRACT_AMT_DEFER_UNBILLED
This parameter provides all the information of deferred revenue and unbilled receivable at contract level. You
can compare the value inside when calculating deferred revenue and unbilled receivable at performance
obligation level.
● IT_POB_DATA_AMT
This parameter provides all the details which you need to distribute deferred revenue and unbilled receivable
on performance obligation level.
● ET_POB_AMT_DEFER_UNBILLED
This parameter contains the final result after you distribute the deferred revenue and unbilled receivable on
performance obligation level.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 287
15.2.16 Deriving Duration of Performance Obligation for
Capitalized
By using enhancement spot FARR_COAC_DERIVE_TM_ATTR and BAdI FARR_BADI_COAC_DERIVE_TM_ATTR, you
can apply your own processing logic when you need to derive duration of performance obligation for capitalized
cost. The implementation of the BAdI is optional.
A Performance obligation for capitalized cost has the following features:
● It is not attached to any other performance obligations.
● It is derived from an operational document item.
● It only contains capitalized cost conditions.
● It is always excluded from price allocation.
You can use the method DERIVE_COAC_ATTR to derive attributes of a performance obligation for capitalized cost.
The attributes include the following fields:
● Duration
● Duration unit
● Deferral method
● Start date
● End date
● Indicator defining how the start date is calculated
This method contains the following parameters:
● IS_CONTRACT_HEADER
This parameter provides a contract that contains performance obligations for capitalized cost.
● IT_POB_DATA_BUFFER
This parameter provides attributes of all performance obligations in the contract.
● ES_COAC_TM_ATTR
This parameter returns attributes including duration, duration unit, deferral method, start date, end date and
indicator that defines how the start date is calculated.
15.2.17 Distribute Invoice to Performance Obligation Level
By using enhancement spot FARR_DISTRIBUTE_INVOICE and BAdI FARR_BADI_DISTRIBUTE_INVOICE, you
can distribute the invoiced amount at performance obligation level.
The BAdI provides the method DISTRIBUTE_INVOICE_TO_POB. This method is used to distribute the invoices to
each performance obligation. It contains the following parameters:
● ITS_ORIGINAL_INVOICE
This parameter provides the original invoices which have been distributed beforehand. We provide this
information in case these invoices need to be re-distributed. For example, when the price has been
reallocated in a contract, the redistribution should be performed again.
● ITS_DISTRIBUTED_INVOICE
This parameter provides the distributed amount at performance obligation level as a result of having executed
this BAdI last time. The total value of the invoice amount in ITS_DISTRIBUTED_INVOICE and
ITS_ORIGINAL_INVOICE should be equal at contract level.
288
P U B LI C
SAP Revenue Accounting and Reporting
Extensibility
● ITS_NON_DISTRIBUTED_INV
This parameter is the invoice which has not yet been distributed.
● ITS_POB_DATA
This parameter provides all of the information relating to the performance obligations that you need to
perform the distribution.
● ITS_CONTRACT_DATA
This parameter provides all of the information relating to the contracts that you need to perform the
distribution.
● ETS_DISTRIBUTED_INVOICE
This parameter contains the final result once you have distributed the invoice amount at performance
obligation level. This is the total amount of the distributed invoice.
15.2.18 Check if table FARR_D_DELDEFITM should be cleared
By using enhancement spot FARR_DS_CLEAR_DELDEFITM and FARR_BADI_CLEAR_DELDEFITM, you can check
whether table FARR_D_DELDEFITM should be cleared.
This BAdI provides the method DECIDE_DELDEFITM. The method contains the following parameters:
● IV_DS_NAME
This parameter provides the name of the data source.
● EV_DELETE
This parameter is a type of bool. If the return value is true, then table FARR_D_DELDEFITM is cleared. If the
return value is false, then table FARR_D_DELITM is kept.
Note
If the BAdI is not implemented, then the data source never clears the table. This is default behavior.
SAP Revenue Accounting and Reporting
Extensibility
P U B LI C 289
16 Migration
After you have installed all of the required components of the SAP Revenue Accounting and Reporting solution,
you have to transfer data from your existing open contracts to the new system. This process is referred to as
migration.
This chapter describes how to transfer data in existing contracts from operational applications and legacy
revenue accounting systems to Revenue Accounting.
16.1 Overall Approach
After you have installed all of the required components of the Revenue Accounting and Reporting solution, you
have to transfer data from your existing open contracts to the new system. This process is referred to as
migration.
This chapter describes how to transfer data in existing contracts from operational applications and legacy
revenue accounting systems to Revenue Accounting. A typical setup of your system landscape may have one or
more operational applications that manage the operational processes for delivery and billing of goods or services
to customers.
You may have one or more legacy systems where you manage valuation for revenue recognition.
Data from both operational applications and the legacy revenue accounting system must be migrated to Revenue
Accounting.
16.1.1 Data Migration Overview
Revenue Accounting manages data for contracts with customers and their performance obligations (POBs). Data
from operational contracts and operational contract items in operational applications are transferred to Revenue
Accounting in order to create revenue accounting contracts and performance obligations within Revenue
Accounting.
You can start using Revenue Accounting at the start of a defined financial period. Then you have to transfer data
from all relevant contracts that are still open at the end of the previous period or for which further business is
expected. The last date of the previous period is the transfer date. You can transfer independent contract
packages on a step-by-step basis and on different transfer dates.
See information about packaged migration in the chapter Migration by Package [page 292].
The migration to Revenue Accounting is divided into two steps:
1. Operational Load
The operational load transfers information about operational documents and posted revenue from a sender
system to Revenue Accounting.
290
P U B LI C
SAP Revenue Accounting and Reporting
Migration
It selects all operational contracts and their related documents which still have an impact on revenue
recognition and passes them to Revenue Accounting by creating revenue accounting items (RAIs).
The operational load also evaluates which revenue has already been posted in the general ledger up to the
transfer date. The result of this evaluation is transferred by using a separate interface. This interface is a
legacy data interface.
Revenue accounting items and legacy data are input for step 2, the initial load.
If Revenue Accounting is used with a different or third party operational system, you need to implement a
dedicated operational load to create revenue accounting items.
2. Initial Load
A special transaction FARR_RAI_PROC_LOAD in Revenue Accounting processes revenue accounting items
and legacy data and creates corresponding contracts and performance obligations, in the same way as during
normal document processing with FARR_RAI_PROC.
The data that you have to transfer from the operational applications to Revenue Accounting includes the
following:
● Order items. The same attributes are also transferred for new and updated order items.
● Invoice items related to these order items. All invoice items up to the transfer date may also be cumulated
into one single invoice item per order item.
● Fulfillment items related to these order items. All fulfillment items up to the transfer date may also be
cumulated into one single fulfillment item per order item.
If attributes have already been maintained for revenue recognition in your legacy revenue accounting system,
such as standalone selling prices (SSPs) and allocated prices, and if recognized revenue has been calculated, then
this data also has to be transferred to Revenue Accounting.
The initial load determines which period that the information belongs to by using the customized transfer date
and the posting dates of the documents transferred to Revenue Accounting. All figures that belong to periods up
to the transfer date, known as the migration period, are aggregated and this period represents the starting point
of future revenue recognition. Each time that Revenue Accounting calculates the amount to be posted in the
SAP Revenue Accounting and Reporting
Migration
P U B LI C 291
current period, it considers the figures from the migration period, such as revenue, that has already been posted
through a legacy revenue recognition system. These values can therefore never be changed in Revenue
Accounting. For this reason, the migration period has to be closed in the operational application before the
operational load starts. The period in Revenue Accounting must also be closed before revenue accounting items
from operational load are processed.
Note
Please make sure that you have closed the migration period in General Ledger before the operational load
starts. Also you need to make sure that you have set the migration period in Revenue Accounting to status
Closed or In-Closing before revenue accounting items (RAIs) from operational load are processed. However, in
the case of Result Analysis migration, the migration period in Revenue Accounting should only be set to status
In-Closing.
Closing a period usually takes some time in order to allow data for new contracts, contract changes, fulfillment
events and invoices to be created in the operational applications between the transfer date and execution date of
the operational load. Any changes to operational items between the transfer date and execution of the operational
load will be taken into account as if they had already occurred before the transfer date.
Revenue Accounting assigns fulfillments and invoices with an event or posting date to the respective period
defined for this event or posting date after the transfer date. So they will be handled as if Revenue Accounting
were active when they were posted.
The complete migration, consisting of operational load and initial load, usually takes some time. Revenue
Accounting integration has to be activated as soon as the operational load starts. Revenue Accounting does not
require a downtime.
Information created by the operational load, such as orders, fulfillments, and invoices, that does not belong to the
migration period, such as a date after the transfer date, will first be suspended and processed later on when the
company code or migration package is set to Production.
As long as the company code or migration package is not yet set to Production, all new documents and any
changes made to existing documents belonging to this company code or migration package will also not be
processed. This means that they will remain, but are suspended, in Revenue Accounting.
You therefore have to reconcile the cumulated values that have been transferred during the migration period with
the balances in the general ledger from postings that have been created from the operational application and the
legacy revenue accounting system up until the transfer date.
The transfer date is usually defined according to the level of company code so that all documents belonging to the
same company code can be loaded in one single step. This means that the complete company code starts its
revenue accounting with Revenue Accounting for the period that follows the transfer date.
This approach is not always feasible. If, for example, a company code has a large data volume or different complex
sales scenarios, it will be too time-consuming to execute and reconcile the complete migration in between two
closings. So the concept of a packaged migration has been introduced. This enables you to perform migration for
one (or several) company codes in several steps. You can do this if operational data, such as contracts, can be
split into several disjoint classes, for example, different businesses, which can then be migrated separately.
16.1.1.1 Migration by Package
You can either perform migration for a complete company code, or you can load revenue accounting items (RAIs)
to Revenue Accounting with finer granularity than an entire company code. This means that you can already start
292
P U B LI C
SAP Revenue Accounting and Reporting
Migration
to use the company code. To load data to company codes that are already productive, you have to define
migration packages in Customizing: Revenue Accounting Revenue Accounting Contracts Define Migration
Packages
Example
You want to migrate a very large company code to Revenue Accounting.
First, you transfer the data of a particular customer group to Revenue Accounting and set the company code to
Productive. You can then gradually transfer additional customer groups of the company code and set the
company code to Productive over time. A migration package contains all data for a certain customer group in a
company code.
You set the status of individual migration packages in a company code to Migration or Productive in
Customizing:
Revenue Accounting Revenue Accounting Contracts Assign Company Codes to Accounting
Principles . As a prerequisite, the combination of the company code and accounting principle, without a
migration package, must be productive, and the transfer date of the new migration package must be the same
or later than the transfer date of the migration packages that are already productive.
The transfer date of a migration package has to be the same for all accounting principles of the company code.
Also, only one package in each company code can be set to Migration.
The sender component transfers the migration package from the MIG_PACKAGE field of the main items of the
order items to Revenue Accounting.
Inbound processing of Revenue Accounting determines the migration package for the invoice items and
fulfillment items internally from the order items to which they belong.
Note
In the initial load TA FARR_RAI_PROC_LOAD, you cannot combine performance obligations (POBs) resulting
from revenue accounting items from different migration packages in one revenue accounting contract. You can
manually combine performance obligations in the Revenue Accounting as soon as both migration packages are
set to Productive.
To reconcile between migrated data and general ledger accounts, SAP recommends that you define the
migration packages so that revenue from different packages can be posted to different general ledger
accounts.
Note
There are scenarios that only allow the migration by package, for example, scenarios that include SAP Hybris
Billing.
There are other scenarios that allow the migration for a complete company code, in addition to the migration
by package, for example, SAP Sales and Distribution (SD).
Further details are available in the Supported Scenarios chapter.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 293
16.1.2 Details Regarding the Migration Steps
16.1.2.1 Prerequisites for Migration
Some prerequisites must be completed before you run the initial load to transfer existing contracts to Revenue
Accounting.
16.1.2.1.1 Migration to New Operational System
If you want to migrate a legacy operational system to a new operational system, and migrate revenue accounting
data to this new operational system, you must first migrate the operational data. Then you can start the migration
to Revenue Accounting.
For example, you have a single legacy system that handles both operational processes and revenue accounting,
and you want to switch operations to SAP ERP Sales and Distribution (SAP SD). In this scenario, you must first
load data that is relevant to operations from the legacy system to SAP SD. You can then load operational data
from SAP SD and revenue recognition data from the legacy system to Revenue Accounting.
When it comes to the scope of migration, you have to take into account that the contracts for which events are
still expected to occur after the migration are also migrated, including reversal of complete fulfillment.
16.1.2.1.2 Consistency before Initial Load
You must ensure that the following data is consistent before the migration:
● Fulfilled quantity in operational application and legacy system, and recognized revenue in the legacy system
● For time-based fulfillment, the recognized revenue must match the elapsed duration up to the transfer date.
Revenue Accounting calculates revenue for time-based fulfillment for every period based on the following
formula:
Revenue for Time-based Fulfillment for Current Period = (Elapsed Duration / Total
Duration) * Allocated Price – Historic Recognized Revenue
If the historic recognized revenue does not correspond to the relation of previously expired duration and
complete duration, then Revenue Accounting calculates and posts a backlog correction. You can avoid such a
backlog correction by implementing a specific deferral method in BAdI FARR_BADI_DEFERRAL_METHOD.
● Invoiced amount in operational application and general ledger
● Recognized revenue in the legacy system and general ledger
● Aggregated negative differences for each contract of recognized revenue minus invoiced amount must be
equal to the balance of corresponding deferred revenue accounts in the general ledger
● Aggregated positive differences for each contract of recognized revenue minus invoiced amount must be
equal to the balance of corresponding unbilled receivable accounts in the general ledger
Even if the aggregated difference between recognized revenue minus invoiced amount for each contract is equal
to the balance of the corresponding accounts for deferred revenue and unbilled receivables in the contract
294
P U B LI C
SAP Revenue Accounting and Reporting
Migration
currency, deviations may exist in the local currency if the legacy system has transferred invoiced amounts and
revenue in foreign currencies with different exchange rates to the local currency. For example, this situation may
occur if your legacy revenue accounting system is based on SD Revenue Recognition. You must either adjust the
historic recognized revenue in local currency and the historic invoice amount in local currency, or post
adjustments to the affected general ledger accounts of deferred revenue and unbilled receivables. Otherwise,
future fulfillments and invoices posted by Revenue Accounting do not clear the existing balance in local currency.
If you do not want to manage all contracts within Revenue Accounting and therefore do not load all of the existing
contracts to the Revenue Accounting system, the balances of the accounts for deferred revenue and unbilled
receivables may not match the aggregated balances of the contracts that are loaded to Revenue Accounting. In
this case, you must separate the aggregated balances of those contracts that are loaded to Revenue Accounting
from those that are not loaded in order to reconcile balances after the initial load.
In general, we recommend that you use separate accounts for revenue, deferred revenue and unbilled receivables
for contracts that are managed by Revenue Accounting, and for those that are not.
SAP does not offer any special reports or tools to check consistency of revenue data in a legacy revenue
accounting system and general ledger before the initial load, but only offers reports to explain the relevant
amounts in Revenue Accounting.
16.1.2.1.3 Testing
The migration needs to be tested completely and thoroughly.
We recommend that you test the operational load, as well as the initial load with a complete set of productive data
in a test system.
For further details, please check chapter 1.2.6.
16.1.2.1.4 Settings in the Revenue Accounting and Reporting
You can perform migration for one or several company codes at a time.
The general configuration of Revenue Accounting must be finalized for each company code to be loaded. All
accounting principles that are relevant for these company codes must be completely implemented.
SAP highly recommends that you define all BRFplus rules before executing the initial load. Any changes made to
operational items after executing the initial load will also trigger new derivation of performance obligation
attributes by BRFplus. So if BRFplus rules have already been tested in the initial load, you can detect any
undesired results of the defined rules beforehand.
Once you have assigned supported company codes to accounting principles in Customizing: Financial
Accounting (New) Revenue Accounting Revenue Accounting Contracts Assign Company Codes to
Accounting Principles , you can define which accounting principles are relevant to a company code. Although
you can maintain the transfer date when you assign each accounting principle to a company code, the transfer
date of all accounting principles of a company code must be identical.
To execute the operational load and initial load, the status of the company codes has to be set to Migration in all
accounting principles. You can only process events that belong to a period after the transfer date when the status
is no longer set to Migration.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 295
You may want to transfer independent packages of contracts to Revenue Accounting on different transfer dates
because it is impossible to manage a complete transfer on the same transfer date. For every transfer date, you
have to define a separate migration package. Also see information about packaged migration in the chapter
Migration by Package. When you assign company codes to accounting principles, the transfer date and the status
can then be defined for each company code and migration package.
16.1.2.1.5 Settings in the Sender System
You have to activate the integration of the sender component with Revenue Accounting before executing the
operational load. By doing this, you can ensure that any event that occurs for a document after it has been
processed by the operational load, is transferred to Revenue Accounting.
When you activate the integration, new documents are also transferred immediately to Revenue Accounting.
None of these documents are processed in Revenue Accounting while the status of the company code and
migration package is set to Migration.
16.1.2.2 Operational Load in Sender System
16.1.2.2.1 Creating Revenue Accounting Items
The operational load creates revenue accounting items (RAIs) that can then be processed with transaction
FARR_RAI_PROC_LOAD. You have to ensure that every relevant document in the sender component is selected.
If open contracts are to be migrated to Revenue Accounting, you have to create similar revenue accounting items
for normal document processing at a later stage. The following points need to be considered:
● There should be an operational load program which selects documents that are relevant to revenue
recognition and transfers them to Revenue Accounting. The parameter iv_initial_load must be set when
revenue accounting items are created with the generated RFC-enabled function modules for creating revenue
accounting items.
● For order items that will be migrated, the timestamp needs to be set to the date on which the order was
created.
● The conditions defined in the revenue accounting items represent the order item amount without allocation. If
an allocation effect exists in the sender system, it needs to be passed with the legacy data (see the next
chapter).
● The operational load must select and transfer all related documents such as invoices, credit memos, debit
memos, and fulfillments. You must ensure that all documents contributing to the contract in Revenue
Accounting will be selected by the operational load.
● If all historic fulfillment events, such as goods issues and invoices, are loaded to Revenue Accounting with
separate revenue accounting items, an audit trail can still be carried out for the entire history of a contract.
● For event-based and manual fulfillments, the corresponding fulfillment revenue accounting items must be
created. The fulfilled quantity of a performance obligation on the transfer date is determined by all fulfillment
entries that have an event date earlier than or on the transfer date. If the history of events is not important,
296
P U B LI C
SAP Revenue Accounting and Reporting
Migration
you can also create one cumulative event with an event date earlier than or on the transfer date which then
represents the quantity that is already fulfilled in the legacy revenue accounting system.
● Invoices with a posting date earlier than or on the transfer date are assumed to be posted in the legacy
revenue accounting system. Revenue Accounting will not create invoice correction postings for the invoices.
● If the operational load supports packaged migration, it must define unique and disjoint sets of document
items and assign migration package IDs to them.
● The operational load program, or an additional program, also needs to calculate and transfer the legacy data
as described in the following chapter.
16.1.2.2.2 Creating Legacy Data
Legacy data needs to be created for each revenue accounting item (RAI) that represents an order item with a
revenue accounting item timestamp before or on the transfer date.
Legacy data information
The most important legacy data information is as follows:
● Fulfilled quantity on transfer date for event-based fulfillment
● Invoiced amount on transfer date
Additional data that may exist in a separate or legacy revenue accounting system is listed as follows:
● Standalone selling price (SSP)
● Allocated price
● Recognized revenue on transfer date
Linked performance obligations (POBs) cannot be transferred from a legacy system.
Note
Do not maintain the decision tables DT_PROCESS_POB_ADD and DT_PROCESS_DEFERRAL during migration.
If you do so, the migration may fail.
You have to create legacy data for all active accounting principles. You can obtain the relevant accounting
principles of a company code by calling the remote-enabled function module
FARR_INITIAL_LOAD_STATUS_API.
Operational load programs for SAP-supported scenarios usually already offer the possibility to create the legacy
data. If the operational load does not support the automatic creation of legacy data, or if the legacy data created
by the operational load does not contain all the information from your legacy revenue accounting system, you
need to create your own legacy data.
You can transfer legacy data for the revenue accounting items that have been created by the operational load by
calling function module FARR_LEGACY_DATA_CREATE_API in remote function call (RFC) mode.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 297
The interface has three parameters which are described in the following sections:
● IT_LEGACY_MAIN: line type FARR_S_LEGACY_API
● IT_LEGACY_COND: line type FARR_S_LEGACYC_API
● IT_LEGACY_SF: line type FARR_S_LEGACYSF_API
The RAI monitor can display legacy data. To enable it, you have to personalize the monitor by choosing the
Personalize button in the toolbar on the selection screen. You can choose whether to enable the display with
legacy data. The display with legacy data must be activated manually, as the legacy data is only relevant in the
migration phase. The display is no longer useful after the migration phase.
Data in IT_LEGACY_MAIN: main legacy data information
You can only deliver one entry in IT_LEGACY_MAIN for each revenue accounting item and accounting principle.
The standard interface cannot create linked performance obligations. If no legacy revenue data exists for an item,
a dummy entry needs to be sent. This dummy entry must contain the key fields SRCDOC_* and ACCT_PRINCIPLE,
as well as the company code. By sending this dummy entry, Revenue Accounting is explicitly informed that no
legacy data exists and that no legacy data is missing. The key fields SRCDOC_COMP, SRCDOC_LOGSYS,
SRCDOC_TYPE and SRCDOC_ID have to be identical to the corresponding revenue accounting item created by the
operational load.
In IT_LEGACY_MAIN, you can transfer nearly every performance obligation attribute. Many of these attributes can
also be populated in BRFplus. You should therefore ensure that the performance obligation is created as
expected, as BRFplus is called during initial load and may fill fields that are not specified in the legacy data.
Information that you deliver directly in the legacy data will overwrite the fields that will be determined in BRFplus.
In general, it is recommended to derive the attributes in BRFplus rather than filling them in the legacy interface.
The fields QUANTITY_FULFILL and QUANTITY_UNIT allow you to specify a percentage of completion (PoC) for
time-based performance obligations that does not match the time passed from the start date of the performance
obligation to the transfer date. For example, if the performance obligation has a runtime of 12 months and 3
months have passed by the transfer date, but the legacy system calculated a percentage of completion of 30%,
you can enter 30% of the performance obligation quantity into this field. The fields can usually be left blank as
Revenue Accounting calculates the percentage of completion according to the time passed until the transfer date.
For performance obligations with event-based fulfillment, the fulfilled quantity will be delivered by the operational
load in the form of fulfillment revenue accounting items. For performance obligations with manual fulfillment, you
have to create fulfillment revenue accounting items for the historic fulfillments in the legacy system.
The NO_RECOG field should not be set. It should only be used after consulting with SAP.
The ALLOC_DIFFERENCE field must contain the difference between the allocated price from the legacy system
and the contractual price from the operational system. If you want to prevent Revenue Accounting from
automatically recalculating the allocated price for a future contract change, then you should set the
MANUAL_ALLOCATION field. When you set this field, any change from the operational system that would trigger a
recalculation of the allocated price will put the contract into a work list to be manually checked.
To transition smoothly from a legacy revenue accounting system to Revenue Accounting with regards to local
currency handling, you have to provide the correct exchange rate information in the legacy data (fields
EXCHANGE_RATE, EXCHANGE_RATE2, and EXCHANGE_RATE3 in parameter IT_LEGACY_MAIN of function module
FARR_LEGACY_DATA_CREATE_API).
298
P U B LI C
SAP Revenue Accounting and Reporting
Migration
The objective is to provide Revenue Accounting with the information it needs to continue with the local currency
calculation in a way that the balance sheet accounts (such as the unbilled receivables account or the deferred
revenues account) have a balance in local currencies at the end.
The legacy data does not contain information about the local currency balances of these accounts. Instead, these
figures are calculated within Revenue Accounting. To calculate these figures, Revenue Accounting needs an
exchange rate which represents the balance between all posted revenues and all posted invoices in the local
currencies.
Revenue Accounting 1.2, as well as lower releases, only support fixed exchange rates. This means that each
contract has its own exchange rate and all revenues for the contract are posted with that exchange rate. To set
the contract exchange rate, you have to use the same exchange rate for all items that belong to the same
operational document.
Example
A sales order, which is relevant for Revenue Accounting, has 2 items. The first item posted an invoice of
100/110, the second 100/120. The first item posted revenue of 80/90.
From this data, revenue accounting calculates a deferred balance of (100+100-80)/(110+120-90) = 120/140.
The exchange rate is 1.167. The respective EXCHANGE_RATE fields need to be filled with this value in the legacy
data in Revenue Accounting if the legacy system did not post any exchange rate differences.
Revenue Accounting will then use this rate to recognize future revenues and will therefore ensure that the
deferred account will have a balance of 0 at the end in both the transaction and local currency.
Example
As above, except that the legacy Revenue Accounting system (for example, SD Revrec) is configured to use the
FASB52 approach which ensures a fixed rate for the deferred revenue account with the same event. You can
assume that the first invoice comes first with the rate 1.1, which fixes the rate on the deferred revenue account.
When the second invoice comes in, the deferred revenue account will be 200/220 and the difference of 10 is
posted to the exchange rate differences (gain). When the revenue is posted, deferred revenue will be reduced
by 80/88 – the difference of 2 will be posted again to the exchange rate differences (which adds up to 8). In
this case, the exchange rate to be transferred to Revenue Accounting is 1.1, as it reflects the revenue that still
needs to be recognized (120/132).
It could also be calculated in the following way: all invoices + exchange rate differences – all revenue postings:
200/230 + 0/-8 - 80/90 = 120/132.
The same is true if the contract is in an unbilled position (revenue > invoice). If the contract is balanced
(revenue = invoice), the exchange rate for the contract can be chosen freely or simply left empty.
Note
Important: to calculate the exchange rate, it is important to only take the documents (revenue, invoice) posted
before the transfer date into account, in other words, those that are part of the legacy data. The exchange rate
can also be left empty if the deferred/unbilled accounts do not need to have a zero balance in local currencies
once the contract has been finalized.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 299
Data in IT_LEGACY_COND: Legacy Data for Conditions
This interface should deliver the historic, cumulated recognized revenue on the transfer date in contract currency
and local currency for each condition type. The local currency amounts must not be zero.
Note
The foreign currency amount is nonzero.
If the ALLOC_DIFFERENCE field in IT_LEGACY_MAIN is not zero, the recognized revenue must be split between
the original condition and the allocation effect (or allocation difference). The recognized allocation effect has to be
delivered with the condition type that is defined in Customizing: Financial Accounting (New) Revenue
Accounting
Revenue Accounting Contracts Condition Types Define Reserved Condition Types .
Data in IT_LEGACY_SF: Legacy Data for Scheduled Fulfillments
This interface is only required if you have already defined special revenue schedules for time-based fulfillments
after the transfer date in your legacy system and you want to continue to use them. The revenue amounts to be
recognized have to be delivered in contract currency. The sum of all amounts, plus the historic recognized
revenue, must add up to the allocated price of the performance obligation.
Note
Do not use the quantity field because it is ignored.
16.1.2.3 Initial Load in Revenue Accounting
After creating revenue accounting items (RAIs) with operational load and delivering corresponding legacy data,
you can start processing the loaded data separately for each accounting principle, company code, and migration
package using transaction FARR_RAI_PROC_LOAD. Only those revenue accounting items that have been created
by operational load with the date (see table below) up to the transfer date are processed. Other revenue
accounting items created via the normal integration, or with a date later than the transfer date, are not processed.
They are processed via transaction FARR_RAI_PROC as soon as the migration package for the company code is
no longer in
Migration.
In order to differentiate revenue accounting items that belong to the period up to, or after, the transfer date, an
initial load indicator INITIAL_LOAD is set before these revenue accounting items are processed:
Table 241:
RAI class type Process that sets the initial load indi
cator
Date used to set the initial load indica
tor
Order Item RAI-Creation Timestamp
300 P U B L I C
SAP Revenue Accounting and Reporting
Migration
RAI class type Process that sets the initial load indi
cator
Date used to set the initial load indica
tor
Fulfillment Item RAI-Transfer Event Date
Invoice Item RAI-Transfer Posting Date
If the date used to set the initial load indicator is before or on the transfer date, the initial load indicator is set to
“Initial Load Due to New Co. Code or Migr. Package”(INITIAL_LOAD = 1). If the date used to set the initial load
indicator is after the transfer date, the initial load indicator is set to “No Initial Load”(INITIAL_LOAD = space).
When the initial load processes revenue accounting items of revenue accounting item class type “order item”, the
corresponding legacy data is taken into account and is required if the INITIAL_LOAD field is set to 1. In this case,
the corresponding legacy data has to be transferred prior to processing using function module
FARR_LEGACY_DATA_CREATE_API.
The revenue accounting items are processed in almost the same way as revenue accounting items that are
created via the usual integration. BRFplus rules are used to derive the performance obligation (POB) attributes
from attributes in the operational data. In BRFplus, you can define special rules for revenue accounting items that
have the INITIAL_LOAD indicator set. If the legacy interface has delivered deviating attributes, a warning
message is issued in the message log and the data from the legacy interface is used in the performance
obligation.
Note
The initial load TA FARR_RAI_PROC_LOAD only supports the creation of new Revenue Accounting contracts.
The initial load does not support changes to Revenue Accounting contracts that already exist.
In the initial load TA FARR_RAI_PROC_LOAD, you cannot combine performance obligations (POBs), resulting
from revenue accounting items from different migration packages, in one revenue accounting contract.
You can manually combine performance obligations in Revenue Accounting, as soon as the migration packages
are set to Productive.
16.1.2.4 Reconciliation of Loaded Data
Once all revenue accounting items (RAIs) of a migration package and company code up to the transfer date have
been processed, the balances of the loaded contracts have to be reconciled with the balances of general ledger
accounts of deferred revenue and unbilled receivables:
● Aggregated negative differences for each contract of recognized revenue minus the invoiced amount, must
be equal to the balance of the corresponding deferred revenue accounts in FI-GL
● Aggregated positive differences for each contract of recognized revenue minus the invoiced amount, must be
equal to the balance of the corresponding unbilled receivables accounts in FI-GL
The absolute amounts of historic recognized revenue and historic invoiced amounts can be reconciled with the
corresponding amounts in your legacy system only if the legacy system offers a report with a selection of
contracts that should have been transferred to Revenue Accounting.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 301
Note
SAP does not deliver a report of cumulated amounts from the initial load. So you have to create your own
report.
16.1.2.5 Marking Company Codes or Migration Packages as
Productive
Once all revenue accounting items (RAIs) from the operational load with a posting date up to the transfer date (for
a migration package or even a complete company code) have been processed successfully, and cumulated values
have been reconciled successfully for an accounting principle, you can set the migration package for the company
code, or even the complete company code, to Productive.
This should be done for all accounting principles at the same time.
When a company code or migration package has been set to productive, new revenue accounting items from
events that have occurred before the transfer date can no longer be processed.
When the status is Productive, you can start processing revenue accounting items from events that have occurred
after the transfer date by using transaction FARR_RAI_PROC. From now on, the accrual run can be run in posting
mode. Contracts and performance obligations (POBs) from the initial load are now managed in the same way as
newly created contracts and performance obligations are transferred via the normal integration.
16.1.2.6 Testing Migration
Operational load and initial load need to be tested completely and thoroughly. We recommend testing the
migration in a Revenue Accounting test system with a complete set of productive data.
Operational load in simulation mode only performs technical checks of data that will be loaded. Complete testing
therefore requires data to be loaded into a test system. You should then start the initial load in this test system.
Processing events from the operational application between the transfer date and execution date of the
operational load, and events after the execution date, must also be tested. In a test system, you can also execute
an accrual run for a company code that is in Migration. You must test the accrual run for at least the first period
after the transfer date to make sure that valuation in Revenue Accounting is consistent with valuation in legacy
systems. If there is a discrepant valuation, the first accrual run can post corresponding positive or negative
backlog of revenue from old contracts.
If the operational load has created revenue accounting items that cannot be processed without errors and that
should not have been created in the first place, you have to delete all data for the loaded migration package of a
company code with transaction FARR_IL_CLEANUP and rerun the complete initial load for the migration package
or company code. If only a few revenue accounting items need to be deleted, you can also use the single header ID
selection in transaction FARR_IL_CLEANUP. You can no longer delete initial load data once a package or company
code has been set to Productive.
It is possible to set a migration package or a company code back to Migration in test systems to repeat an initial
load if serious issues are found. Before doing so, all accrual runs that have been posted to the general ledger must
be reversed.
302
P U B LI C
SAP Revenue Accounting and Reporting
Migration
After the cleanup in Revenue Accounting, you can correct faulty source data in the sender system or faulty
configurations. To do this, you may need to reset data in the sender system, for example a special indicator marks
documents which are relevant for Revenue Accounting. This indicator has to be cleared to enable a new
operational load for this document. After this reset, you can rerun operational load, as well as initial load.
16.2 Supported Scenarios
16.2.1 Sales and Distribution
Use
In the “Sales and Distribution” scenario, all order, fulfillment and invoice items that belong to a revenue
accounting contract in Revenue Accounting originate in SAP Sales and Distribution (SD).
You don’t need to define a migration package for the first transfer. This means that you can set a company code in
Revenue Accounting to Productive and decide later whether, or when, you want to transfer additional migration
packages.
Packaged migration is optional for the sender component SD. Assigning order items to a migration package can
either be done in the revenue accounting item (RAI) settings in Customizing:
Sales and Distribution Revenue
Accounting and Reporting Maintain Revenue Accounting Item Settings or in method
DETERMINE_MIG_PACKAGE of BAdI FARRIC_BADI_ORDER.
Prerequisites
The following settings are relevant for integration to Revenue Accounting in SD:
● Revenue accounting item settings
Revenue accounting item settings are maintained in Customizing: Sales and Distribution Revenue
Accounting and Reporting
Maintain Revenue Accounting Item Settings .
These settings determine which items are relevant to Revenue Accounting. Operational load only selects
relevant items according to this configuration.
If you want to use a migration package, you have to enter it here as “package ID”. The first operational load
can also take place without using a migration package. In this case, the package ID is blank. If additional
migration packages are migrated after the first operational load, you have to maintain the relevant migration
package.
● If the criteria in the above-mentioned setting such as sales organization, sales document type, and item
category are insufficient for determining the migration package, you can implement additional rules in
method DETERMINE_MIG_PACKAGE of BAdI FARRIC_BADI_ORDER to exclude items from a migration
package.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 303
● Integrate with Revenue Accounting
The SD integration component has to be activated before executing the operational load. This ensures that
any event that occurs for an SD document after it has been processed by operational load is transferred to
Revenue Accounting by the integration component. New documents are transferred immediately to Revenue
Accounting when you activate the SD integration component in Customizing: Sales and Distribution
Revenue Accounting and Reporting Integrate with Revenue Accounting . New documents are not
processed while the company code is in Migration.
Activities
Operational Load
The operational load of data from SD is performed with transaction FARRIC_OL. It creates revenue accounting
items that can then be processed in Revenue Accounting with transaction FARR_RAI_PROC_LOAD (prior to the
transfer date) or transaction FARR_RAI_PROC (after the transfer date).
You can run the operational load for specific company codes and migration packages at the same time. The
program provides additional selection criteria so that you can run the load on a step-by-step basis, particularly for
testing purposes. If you use this additional selection criteria for the migration, you have to ensure that each
relevant sales document is only selected once.
The operational load from SD loads all historic fulfilment and invoice events, and transfers them to Revenue
Accounting where they are processed separately. A separate load of order items with related fulfillment and billing
documents for test purposes is only possible with transaction FARRIC_OL_EXPERT.
If you have used SD Revenue Recognition, the operational load will transfer recognized revenue from SD Revenue
Recognition. If you want to transfer historic recognized revenue or other data from a legacy system other than SD
Revenue Recognition, you have to use transaction FARRIC_OL_EXPERT and switch off the checkbox Create
Legacy Data. Then legacy data must be delivered for each operational item selected with the legacy interface
described in the Creation of Legacy Data [page 297] chapter.
Note
You need to run transaction FARRIC_OL_EXPERT carefully. Consider cases where not all information comes
from SD. Some information may not exist or be reliable. In such cases, the corresponding data has to be loaded
by using custom revenue accounting item classes. In expert mode, you can suppress processing of invoices,
goods issues and legacy data. Before you use this transaction, please contact SAP to verify whether the
migration will work correctly and thoroughly.
To enhance performance, the Synchronous Online Processing checkbox should only be set for test runs with a
small number of sales documents for different purposes, such as debugging.
Testing
As already described in the Testing Migration chapter, you should thoroughly test the operational load in SD.
After a cleanup in Revenue Accounting, you can use transaction FARRIC_OL to reset orders, goods issues, and
invoices to the state they were in before the operational load. The revenue accounting relevance indicator, as well
as the migration package, are deleted from the loaded SD documents.
You can start the operational load again afterwards.
304
P U B LI C
SAP Revenue Accounting and Reporting
Migration
16.2.2 Customer Relationship Management, Service
Application
Use
In scenario “Customer Relationship Management” (Sender Component “CRS”) all order and invoice items that
belong to a revenue accounting contract in SAP Revenue Accounting and Reporting (Revenue Accounting)
originate in SAP Customer Relationship Management (CRM).
For the first takeover, you do not need to define a migration package. So you can set a company code in Revenue
Accounting to the status Productive and later decide whether or when you want to take over additional migration
packages.
Packaged migration is optional for sender component CRS. The assignment to a migration package can be done in
the revenue accounting item (RAI) settings in CRM Customizing under Customer Relationship Management
Transactions Settings for Service Transactions Integration Revenue Accounting Integration :
● Define Relevance Type for Revenue Accounting
● BAdI: Determine Relevance Type and Reference for Revenue Accounting
In method GET_RELEVANCE_TYPE of enhancement spot CRM_SRV_REVACC_REL
Prerequisites
The following settings are relevant to the migration of CRM data to Revenue Accounting:
● Revenue accounting item settings
RAI settings are maintained in CRM Customizing under Customer Relationship Management
Transactions Settings for Service Transactions Integration Revenue Accounting Integration Define
Relevance Type for Revenue Accounting .
These settings determine which items are relevant to Revenue Accounting. Operational load only selects
relevant items according to this configuration.
If you want to use a migration package, you have to enter in this Customizing activity under Package ID. The
first operational load can also take place without using a migration package. In this case, the Package ID
remains empty.
In case you want to migrate additional migration packages after the first operational load, you have to enter
the relevant migration package.
Note
If the criteria in the before mentioned setting such as service organization, sales organization, business
transaction type, and item category are insufficient for determining the migration package, you can
implement additional rules in method EXCLUDE_TRANSACTION_ITEMS of enhancement spot
CRM_SERVICE_REVACC_RELEVANCE to exclude items from a migration package in CRM Customizing
under
Customer Relationship Management Transactions Settings for Service Transactions
Integration Revenue Accounting Integration Business Add-Ins for Revenue Accounting Integration
BAdI: Exclude Transaction Items from Operational Load .
SAP Revenue Accounting and Reporting
Migration
P U B LI C 305
● SAP ERP (ERP) Customizing settings
You make the following settings in the enhancement spot CRM_SRV_ACC_REV in ERP Customizing under
Integration with Other SAP Components Customer Relationship Management Settings for Service
Processing Revenue Accounting Integration BAdI: Mapping of Data to Revenue Accounting :
○ Revenue accounting order items of the operational load can be enriched or changed by implementing
method MAP_SRV_TO_ACCOUNT_REVENUE.
○ Revenue accounting invoice items of the operational load can be enriched or changed by implementing
method MAP_BILL_TO_ACCOUNT_REVENUE.
○ Legacy data can be enriched or changed by implementing method MAP_LEGACY_DATA_TO_ACC_REV.
● Integration with Revenue Accounting
Activate the CRM integration before productive execution of the operational load so that any event that
occurs for a CRM document after it has been processed by operational load is transferred to Revenue
Accounting.
New documents will be transferred immediately to Revenue Accounting by activating the CRM integration
with the following Customizing activities in ERP Customizing under
Integration with Other SAP Components
Customer Relationship Management Settings for Service Processing Revenue Accounting Integration :
○ Define RFC Destination
○ Activate Integration to Revenue Accounting
Note
New documents will not be processed as long as the company code is in status Migration in Revenue
Accounting Customizing activity Assign Company Codes to Accounting Principles.
● Implement the SAP Note 2341693 to prevent inconsistencies during the migration of your CRM
documents.
Activities
Operational Load
The operational load of data from CRM is performed in several steps. The steps have to be executed in a fixed
sequence:
1. In your CRM system, choose transaction CRM_SRV_REVACC_ER to enrich your CRM service transactions with
reference type and reference ID.
2. In your CRM system, choose transaction CRM_SRV_REVACC_ERSD to enrich your follow-up documents in ERP.
These are debit memo requests which are used for billing in SAP Sales and Distribution (SD) of CRM service
transactions and sales orders which result from CRM bundle package quotations. This step can be skipped if
service transactions are not billed in SD or package quotations with sales orders are not used.
3. In your CRM system, choose transaction CRM_SRV_REVACC_OL to set the relevance type for CRM service
contracts and service orders, and service confirmation according to Customizing. For follow-up billing
documents and due list items in CRM, the relevance type is passed on. It creates RAIs for orders and invoices
and transfers legacy data.
4. In your ERP system, choose transaction FARRIC_OL to load RAIs for debit memo requests and sales orders
which are created from CRM.
This step can be skipped if service transactions are not billed in SD or package quotations with sales orders
are not used.
306
P U B LI C
SAP Revenue Accounting and Reporting
Migration
5. In your Revenue Accounting system, choose the following transactions to process an initial load of the RAIs in
Revenue Accounting:
○ FARR_RAI_PROC_LOAD (prior to transfer date)
○ FARR_RAI_PROC (after transfer date)
You can run the operational load for specific company codes and migration packages at a time. The program
provides additional selections so that you can run the load step-wise particularly for testing purposes. If you use
these additional selections for a productive migration, you have to make sure that every relevant document is
selected only once.
The operational load from CRM loads all historic billing documents in CRM and transfers them as legacy data to
Revenue Accounting where they are processed separately. If billing in SD is used or if SD sales orders are created
from CRM bundle package quotations, the operational load in SD has to be executed for these documents.
For a better performance of your CRM system the Synchronous Processing indicator should only be set for test
runs with a selection of a small number of documents for some purposes such as debugging.
Testing
You have to test the operational load in CRM (and SD) thoroughly. For more information, see Testing of Migration
[page 302].
After a cleanup in Revenue Accounting, you can use transaction CRM_SRV_REVACC_OL in your CRM system to
reset business transactions, billing documents and due list items to the state they had before the operational load.
The Revenue Accounting Relevance indicator is deleted from the loaded CRM documents. The reset of SD orders
and invoices can be done with transaction FARRIC_OL in SD.
Reference IDs and types that were written into CRM business transactions cannot be reset. But it is possible to
repeat data enrichment and to overwrite the references with new values. Afterwards you can start the operational
load again.
16.2.2.1 SAP CRM: Revenue Recognition Migration
Use
In SAP Customer Relationship Management (CRM), you can use two different solutions for the revenue
recognition of your sales and service business transaction data:
● Revenue recognition based on the results analysis
● Revenue recognition based on SAP Revenue Accounting and Reporting (Revenue Accounting)
Integration
The following processes are supported.
Existing Service Contracts
SAP Revenue Accounting and Reporting
Migration
P U B LI C 307
To migrate from your current revenue recognition process based on the results analysis for existing service
contracts to the revenue recognition process integrated with Revenue Accounting, you have to follow these
steps:
1. During the posting period, until the transfer date is reached, perform your usual revenue recognition process
one more time followed by the usual order settlement process.
2. Change your existing revenue recognition process to the final results analysis. Usually, the final results
analysis is only used for completed internal orders, but for the switch to revenue recognition integrated with
Revenue Accounting, you have to do the final result analysis for each of your relevant internal orders
independent of their status (such as status open). You set this switch to the final result analysis by modifying
the results analysis key (RA key) which is part of the internal order Customizing in your Controlling system
under
Controlling Product Cost Controlling Cost Object Controlling Product Cost by Sales Order
Period-End Closing Results Analysis Define Valuation Methods for Results Analysis .
Note
In this Customizing setting, you do not change the RA key itself, but you set the RA key that is used for the
internal order under Valuation Final RA to X for each status.
3. Set up Revenue Accounting with the revenue-based integration to the results analysis by maintaining the
following views in your Revenue Accounting system using transaction SM30:
○ V_TKKA_RR_AC
○ V_TKKA_RR_ME
For more information, see documentation in Customizing under Financial Accounting Revenue
Accounting
Integration with Cost Object Controlling :
○ Assign RA Version and Currency Type to Company Code and Acct. Principle
○ Specify RA Keys and RA Versions that will Integrate with Revenue Acct.
4. Perform the operational load in your CRM system and inital load in your Revenue Accounting system.
Fore more information, see Customer Relationship Management, Service Application [page 305].
5. For all following period-end closing processes, you have to first perform the accrual in Revenue Accounting
including the posting for the internal order. Then, you perform the final results analysis including results
analysis and the order settlement processes.
Note
Continue this process until all your existing migrated service contracts have expired and are completed.
During this contract duration, you have to run both revenue recognition processes in parallel.
Parallel Process During Contact Duration
When you use the revenue recognition process based on the results analysis for your CRM sales and service
business transaction data and the integration with Revenue Accounting in parallel, the following priority rule
applies, depending on your system setup:
○ Relevance Set During Creation of Service Contract Item
If you have set up revenue recognition based on the result analysis and based on Revenue Accounting for
an item category of a service contract, the following rule applies when you create a new item: the
relevance type is set and the revenue recognition type is ignored. The process for Revenue Accounting
has priority over the process for results analysis.
Set up the following:
○ A revenue recognition type for revenue recognition based on the result analysis
308
P U B LI C
SAP Revenue Accounting and Reporting
Migration
You have set the revenue recognition type SCN CRM Service Contract Item in Customizing for CRM
under Transactions Basis Settings Define Item Categories .
○ A relevance type for revenue recognition based on Revenue Accounting
You have set the relevance type in Customizing for CRM under Transactions Settings for Service
Transactions
Integration Revenue Accounting Integration Define Relevance Type for Revenue
Accounting .
○ Relevance Set During Operational Load
If the relevance type for the item has been set by operational load, the revenue recognition type is not
ignored. It gets sent to both the results analysis and Revenue Accounting.
Note
If you want to use this process, you have to set up Revenue Accounting using the revenue based
integration with results analysis for your performance obligation. For service contracts that were
loaded using operational load, you can only run a final results analysis.
New Service Contracts
When you already use the revenue recognition process based on the results analysis for new contracts and
migrate to the revenue recognition process integrated with Revenue Accounting, set up Customizing as described
above in section for Existing Service Contracts, but without setting up the revenue-based integration with the
results analysis. The process for Revenue Accounting has priority over the process for results analysis.
Note
This process only works for mass controlling, meaning without internal order, but with a profitability segment
instead.
16.2.3 Hybris Billing
Use
In an SAP Hybris Billing or Billing and Revenue Innovation Management (BRIM) scenario, all order, fulfillment and
invoice items that belong to a revenue accounting contract in Revenue Accounting originate from SAP Convergent
Invoicing (services and hardware).
In this scenario, a hardware sale is modelled in such a way that one-off charges are created in Convergent
Invoicing.
Note
Only packaged migration is supported for Hybris Billing. As a prerequisite, the company code and accounting
principle combination, without a migration package, must be productive, and the transfer date of the migration
packages must be the same, or later than, the transfer date of the company code and accounting principle
combination that is already productive.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 309
Note
The time-based, as well as event-based, deferred revenues in FI-CA are not considered during the operational
load.
Prerequisites
Before starting with the operational load for Hybris Billing, you have to maintain all the necessary Customizing
activities in Convergent Invoicing:
● Define Service Types
Define the service types that are relevant in the context of your provider contracts in Customizing: Financial
Accounting (New) Contract Accounts Receivable and Payable Integration Revenue Accounting Define
Service Types
. In addition, set the indicators for order item, one-off charge, fulfillment item, and invoice
item to specify which types of revenue accounting items (RAIs) are to be created for each service type.
● Assign Service IDs to Service Types
SAP Customer Relationship Management (CRM) does not recognize service types. Instead, it deals with
Service IDs. You have to assign the service IDs to service types so that the relevant service types of a provider
contract item can be determined when a provider contract is replicated from SAP CRM. Determination also
takes place when provider contracts are enriched to prepare for the operational load. You perform the
assignment in Customizing: Financial Accounting (New) Contract Accounts Receivable and Payable
Integration Revenue Accounting Assign Service IDs to Service Types .
● Since service types are not currently known in the system, it is essential to maintain how those would be
determined in future. We recommend that you determine a maximum of one service type per combination for
the main and sub transaction. This can be done separately for one-off charges, as well as billable items in
general:
○ For one-off charges, maintain Customizing in Financial Accounting (New) Contract Accounts
Receivable and Payable
Integration Customer Relationship Management Transfer of One-Off
Charges Define Main Transactions and Subtransactions .
○ For billable items in general, maintain Customizing in Financial Accounting (New) Contract Accounts
Receivable and Payable Convergent Invoicing Basic Functions Billable Items Billable Item Transfer
Account Assignment Derivation Define Main and Subtransactions for Items with Product Account
Assignment
.
The service type is not yet available in existing billable items and billing documents. For operational load, the
two settings mentioned above are interpreted to find the right service type. If the system cannot determine
the service type unambiguously during the operational load, you will receive an error message.
● Activate provider contract items for Revenue Accounting
You can maintain which provider contract items are considered relevant for revenue accounting In
Customizing:
Financial Accounting (New) Contract Accounts Receivable and Payable Integration
Revenue Accounting Activate Provider Contract Items for Revenue Accounting . If the key fields of the
posting area provided are not sufficient, you can also use FI-CA event 0558 for implementing your logic. In a
full Hybris Billing scenario, the reference ID of a provider contract item is replicated from SAP CRM. You
should make sure that only provider contract items, in which the reference ID is already available, are
considered relevant to revenue accounting by appropriately implementing event 0558. If you do not ensure
310
P U B LI C
SAP Revenue Accounting and Reporting
Migration
this via event 0558, it can happen that revenue accounting relevance is already set and thus revenue
accounting items are created even though the full information is not yet presented in the provider contract.
● Define number ranges for revenue accounting item IDs
You need to define number ranges for revenue accounting item IDs. The numbers from the number range
form part of an ID that is created by a program.
● Activate integration with Revenue Accounting
You have to activate the integration with Revenue Accounting, before executing the operational load, in
Customizing: Financial Accounting (New) Contract Accounts Receivable and Payable Integration
Revenue Accounting Activate Integration with Revenue Accounting . New provider contracts and their
related documents will then automatically be considered for creating revenue accounting items. The
corresponding revenue accounting items are not processed while the migration package is in Migration.
Activities
Operational Load
Before you can start the operational load in Convergent Invoicing, you must enrich the provider contracts in
Convergent Invoicing with information that is relevant for revenue accounting from SAP CRM. For this purpose,
there are two reports in SAP CRM:
1. Report CRM_ISX_REVACC_MIG_ENRICH_CRM2
This report enriches the existing provider sales orders and provider contracts in SAP CRM. It also determines
the relevant enrichment data for provider contracts in Convergent Invoicing. This data is written to an
enrichment database that is considered in the next report.
2. Report CRM_ISX_REVACC_MIG_ENRICH_FICA
This report needs to be executed in FI-CA mode: It enriches the provider contracts in Hybris Billing with the
data from the previously populated enrichment database. Function module FKK_VT_MIG_RA_ENRICH is used
to enrich the data in the provider contract in SAP CI.
Once the enrichment has been finished successfully for all relevant provider contracts, you can start the
operational load in Convergent Invoicing. To achieve this, you can call up transaction FP_RAI_OL. The operational
load is divided into two steps which can be found under the Loading of Provider Contracts mode.
1. Create migration package
You have to enter the migration package that will be used in this operational load run. In this step, all the
provider contract items that meet the selection criteria and that are not yet marked as relevant for revenue
accounting, will be checked to see if they are relevant for revenue accounting. Newly created provider
contract items that meet the same selection criteria will not end up in the same migration package. The
company code and accounting principle combination without a migration package must therefore be
productive.
Note
Cancelled provider contract items are not taken into account.
If a provider contract item is determined as relevant for revenue accounting (posting area 0510 and FI-CA
event 0558 are considered for the determination), it will be updated accordingly: Field RAREL is set to value X
and the migration package is transferred. In addition to the update of the provider contract item,
corresponding order item revenue accounting items will be created.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 311
Furthermore, an entry is written in the migration status table DFKKRA_MIG so that the subsequent step can
continue from there.
If you want to adapt the order item revenue accounting items, you can do so when they are created using FI-
CA event 8205.
Note
This event is also processed when normal order item revenue accounting items are created. Although in
this case the revenue accounting items do not contain a value for the migration package. The event can
also be used if you want to inform other components or processes once order item revenue accounting
items are created by sender component CA as part of the migration.
2. Create follow-on document item
After the migration package has been created in the previous step, you can continue to create the follow-on
document items. The follow-on document items are order item revenue accounting items for one-off charges,
fulfillment item revenue accounting items and invoice item revenue accounting items. You can choose
whether legacy data will be created by marking the appropriate checkbox. If legacy data shall be created but
no invoices exist for a provider contract item from which the legacy data can be derived, a dummy legacy data
entry will be created when the revenue accounting items are transferred to Revenue Accounting using
transaction FP_RAI_TRANSF.
You can see operational load revenue accounting items that have been created by transaction FP_RAI_OL in the
revenue accounting item monitor with transaction FP_RAI_MON.
With transaction FP_RAI_TRANSF, you transfer the operational load as well as normal revenue accounting items
to Revenue Accounting. You can only transfer operational load revenue accounting items to Revenue Accounting
if you have successfully executed all the steps of the operational load (“create migration package” and “create
follow-on document item”).
Testing
As already described in the Testing chapter, you should thoroughly test the operational load in Hybris Billing.
After a cleanup in Revenue Accounting, you can use transaction FP_RAI_OL (Reset Transfer Date mode) to reset
the transfer date of the operational load revenue accounting items in Convergent Invoicing.
After you have reset the transfer date, it is possible to transfer the revenue accounting items to Revenue
Accounting again using transaction FP_RAI_TRANSF.
16.2.4 Hybris Billing with Sales and Distribution
Use
In a Hybris Billing with Sales and Distribution (SD) scenario:
● Order, fulfillment and invoice items for the service are created in Hybris Billing.
● Order, fulfillment and invoice items for the hardware sale are created in SD.
Service and hardware belong to the same revenue accounting contract in Revenue Accounting.
312
P U B LI C
SAP Revenue Accounting and Reporting
Migration
It may also be the case that only orders and fulfillments for the hardware sale that belong to one revenue
accounting contract in Revenue Accounting originate from SD but the invoicing takes place in Hybris Billing,
namely via SAP Convergent Invoicing.
The following sections describe aspects that are specific to the mixed “Hybris Billing and Sales and Distribution”
scenario. See the chapters regarding the scenario “Hybris Billing” and “Sales and Distribution” for information
regarding the standalone scenarios which is also true for the mixed scenario described here.
Note
Only packaged migration is supported for scenarios including Hybris Billing. As a prerequisite, the company
code and accounting principle combination, without a migration package, must be productive, and the transfer
date of the migration packages must be the same, or later than, the transfer date of the company code and
accounting principle combination that is already productive.
Prerequisites
Perform all of the necessary steps listed in the prerequisites section of the standalone scenarios “Hybris Billing”
and “Sales and Distribution”.
Activities
Operational Load
Before you can start the operational load in Convergent Invoicing and SD respectively, you must enrich provider
contracts in Convergent Invoicing and sales documents in SD with information relevant for revenue accounting,
such as reference type and ID from SAP Customer Relationship Management (CRM). There are two reports in
SAP CRM for this purpose:
1. Report CRM_ISX_REVACC_MIG_ENRICH_CRM2
This report enriches the existing provider sales orders and provider contracts in SAP CRM. It also determines
the relevant enrichment data for provider contracts in Convergent Invoicing. This data is written to an
enrichment database that will be considered in the following report.
2. Report CRM_ISX_REVACC_MIG_ENRICH_FICA
This report needs to be executed for the following two modes:
○ FI-CA: It enriches the provider contracts in Convergent Invoicing with the data from the previously
populated enrichment database.
○ SD: It enriches the sales orders in SD with the data from the previously populated enrichment database.
Execute the operational load for Hybris Billing and SD as outlined in the specific chapters.
When hardware from SD is invoiced in Convergent Invoicing, the SD operational load will create trigger records in
Convergent Invoicing. These triggers are then processed with transaction FP_RAI_OL usign theLoading of SD
Orders mode.
Testing
SAP Revenue Accounting and Reporting
Migration
P U B LI C 313
As already described in the Testing Migration chapter, you should thoroughly test the operational load in Hybris
Billing, as well as SD.
Please refer to the testing section of the “Hybris Billing” and “Sales and Distribution” scenarios for specific details.
16.2.5 Third Party Sender
With Revenue Accounting, it is also possible to connect third party or custom-specific operational applications
with custom-specific revenue accounting item (RAI) classes. You can generate interfaces and remote function call
(RFC) function modules to process your specific order item, fulfillment item, and invoice item revenue accounting
items. For more details, see SAP note 2196907.
If Revenue Accounting is used with a different or a third-party operational system, you need to implement a
dedicated operational load which creates revenue accounting items that are similar to what has been described in
the previous chapters.
To transfer data from a legacy revenue recognition system, you have to develop a custom-specific program to
create legacy data.
16.3 Migration for Integration with Cost Object Controlling
Use
The migration for Integration with Cost Object Controlling follows a modified logic for controlling objects and
related sales order items if results analysis forwards a percentage of completion to revenue accounting. This logic
acts like a new valuation method in results analysis where the historic values (in table COSP) need to be adapted,
as if the logic were in place from the beginning. Otherwise the historic values are incorrect.
This is achieved through the following activities:
Prerequisites
See Prerequisites under the General Description of Integration with Cost Object Controlling.
Activities
● The migration period must be set to in closing so that further reconciliation keys can be created and, at the
same time, to prevent (manual) contract changes ending up in the migration period
● Perform the initial load for sales order items which relate to results analysis keys that are relevant for revenue
accounting
314
P U B LI C
SAP Revenue Accounting and Reporting
Migration
● Run the results analysis during the migration period to transfer a percentage of completion to revenue
accounting. During the migration period, the status must be set to in closing and postings need to go to a
separate reconciliation key
● Calculate the revenue and contract asset/contract liability in revenue accounting and perform a posting run.
Note
Results analysis must not be executed until the initial load has been completed for all sales order items.
SAP Revenue Accounting and Reporting
Migration
P U B LI C 315
17 Transition
17.1 Transition Process for IFRS 15
Transition is the process of switching from an existing accounting standard to a new one, for example, IFRS15.
The process involves the following steps:
● Creating a new accounting principle in the SAP system
● Adjusting contracts according to the new accounting principle
● Calculating the cumulative catch-up between the operative revenue recognition standard and the new
policies. Revenue Accounting allows you to compare the old and new accounting principles.
In the following, we will introduce some general terms and concepts relating to transition to the new revenue
accounting standard under IFRS15. Each topic is addressed at a high level to the extent required for better
understanding and to provide an overview. Further reading of the sources provided is recommended.
17.1.1 Date of Initial Adoption
An entity shall apply the new standard for annual reporting periods beginning on, or after, January 1 2018, though
an earlier application is permitted.
Refer to: Effective Date of IFRS 15: http://www.ifrs.org/Current-Projects/IASB-Projects/Revenue-Recognition/
Documents/IFRS-15/Effective-Date-of-IFRS-15.pdf.
In paragraphs C3 to C8 of staff paper“ “Accounting for completed contracts on transition to IFRS 15— issues
emerging from TRG discussions” ”the date of initial application is addressed.
“"For the purposes of the transition requirements in paragraphs C3–C8:”
“a) the date of initial application is the start of the reporting period in which an entity first applies this Standard.””
Source: IFRS 15 REVENUE FROM CONTRACTS WITH CUSTOMERS - Appendix C – C2 (page 15) through the
following link: http://www.ifrs.org/Meetings/MeetingDocs/IASB/2015/September/AP07-Revenue-from-
Contracts-with-Customers.pdf
The date of initial application or adoption is the date on which the entity first applies this standard. In other words,
the date from which the new legislation is the basis for the published financial statements.
Contracts with their historic amounts need to be restated and a cumulative catch-up needs to be posted in the
system.
As of this date, revenue is recognized according to the new accounting principle.
316
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.1.2 Full Retrospective and Modified Retrospective
Transition
The staff paper discusses the following two scenarios for the transition process:
● Full retrospective transition method where IFRS 15 is applied retrospectively to each prior reporting period
with a calculation of the cumulative catch-up at the start of the comparative period.
● Modified retrospective transition method where the cumulative catch-up is calculated at date of adoption.
Example
Example 1: Full retrospective method
In the scenario below, a customer has a fiscal year starting January 1.
For the full retrospective method and date of adoption as January 1, 2018, the comparative period starts on
January 1, 2016.
Within this time frame, an entity has to report based on the old standard and provide comparative figures for
the new accounting standard. The financial statements published are based on the old accounting standard.
The cumulative catch-up is calculated at the transfer date and posted to the leading ledger or general ledger
accounts at the date of adoption.
After the date of adoption, the entity will only need to continue reporting based on the new accounting
standard.
Note that the full retrospective transition method requires the transfer of data at the date of transfer to keep
track of all change events, for example, SD order change.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 317
Example 2: Modified retrospective method
The entity will continue to publish financial results based on the old accounting standard for the modified
retrospective transition method.
With the date of adoption as January 1, 2018, the entity will add the new accounting standard. Portrayal of the
new accounting standard is either based on data in the leading ledger or in the general ledger accounts
referring to this accounting principle depending on which parallel accounting approach has been chosen.
The cumulative catch-up is calculated and posted at the date of adoption on January 1, 2018.
The comparative time frame, during which financial data on both accounting standards needs to be provided, is
one year.
318
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.1.3 Comparative Period
A comparative period is a period of time for which a company publishes figures of its financial statement
according to the old and new accounting standards in parallel.
During this period, an entity that applies the full retrospective method needs to publish financial figures according
to the new standard for periods before actual adoption of the new standard. While an entity that applies the
modified retrospective method needs to publish financial figures according to the old standard for periods after
adoption of the new standard.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 319
17.1.4 Cumulative Catch-Up
The cumulative effect of a new revenue recognition standard is the difference between cumulated, historically-
recognized revenue at a defined date and the cumulative revenue that would have been recognized at this date by
applying the new standard from the start of all (open) contracts.
The cumulative effect has to be calculated at the start date of a retrospective comparative period or at the date of
adoption. Then it has to be posted at the date of initial adoption against the general ledger account of retained
earnings.
Effectively the last day before the start of the comparative period (for example, 2015-12-31) is equivalent to the
start date of the comparative period (for example, 2016-01-01)
320
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.2 Transition with SAP Revenue Accounting
The following chapter describes the process of transition to the new IFRS standard with SAP Revenue Accounting
and Reporting. You will be able to understand different use cases of the transition process in SAP and differentiate
between the portrayals based on additional accounts versus ledgers.
17.2.1 Supported Capabilities for Data Transfer to Transition
Revenue Accounting supports the following use cases:
● Use Case 1: A customer runs their operative system without Revenue Accounting and wants to migrate the
data to both the old and new standard for comparative reporting.
● Use Case 2: A customer runs their operative system with Revenue Accounting and wants to copy data to the
new standard.
● Use Case 3: A customer may want to continue to run their operative system without Revenue Accounting and
to simply introduce the new standard in Revenue Accounting.
The following overview highlights the different use cases:
Grey boxes indicate legacy data that has not yet been migrated to Revenue Accounting.
Orange boxes refer to revenue accounting data according to the source accounting principle of the old standard.
Blue boxes refer to revenue accounting data according to the target accounting principle of the new standard.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 321
17.2.1.1 Supported Capabilities for Data Transfer to Transition
- Use Case 1
Revenue Accounting supports different scenarios for transition. In this use case, the entity ran their operative
system without Revenue Accounting and wants to migrate the data to both the old and new standard for
comparative reporting.
This means that the operational load should be performed with two accounting principles: One accounting
principle is customized for the old standard, and the other one for the new standard.
The transfer date is the same for both accounting principles, as the legacy data is transferred at the time of the
operational load.
The standards are compared within Revenue Accounting.
322
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.2.1.2 Supported Capabilities for Data Transfer to Transition
- Use Case 2
In this use case, the entity ran their operative system, or parts of their operative system, with Revenue Accounting
and wants to copy data to the new standard.
The old standard has already been migrated to Revenue Accounting, and is used productively.
The new standard is customized and the contracts are created by reprocessing the revenue accounting items
(RAIs) again, which already exist according to the new standard.
Legacy data, for example fulfilled parts up until the transfer date, is determined using the related contract in the
old standard during reprocessing.
The transfer date is later than the transfer date of the old standard.
After reprocessing, the cumulative catch-up effect, and the subsequent comparison, can be determined by an
SAP standard report.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 323
17.2.2 Parallel Accounting - Overview
For transition, you have to either set up or extend your existing settings for parallel accounting.
You can portray parallel accounting in your SAP system using different options. This enables you to perform
valuations and closing preparations for a company code according to the accounting principles of the group
company, as well as other accounting principles such as local accounting principles.
In the transition phase, comparative data reporting is required for the old and new standard. Financial data is
stored in SAP in ledgers. The comparative data reporting can either be based on dedicated ledgers or dedicated
general ledger accounts within one ledger. In order to reflect the requirement to report data for comparative
reasons versus the actual financial results, accounts or ledgers can either be reported statistically or as real data
published in the financial results.
The assumption is that customers may prefer a solution based on additional general ledger accounts due to the
effort it takes to implement a completely new ledger.
You can use one of the following approaches to portray parallel accounting in the SAP system:
● Portrayal Using Additional Accounts: You can portray parallel accounting in your SAP system by creating
additional accounts. For detailed information, refer to https://help.sap.com/saphelp_erp60_sp/
helpdata/en/96/177752a9d07154e10000000a44176d/content.htm
● Portrayal Using Parallel Ledgers: In General Ledger Accounting, you can perform parallel accounting by
running several parallel ledgers or general ledgers for different accounting principles. For detailed
information, refer to https://help.sap.com/saphelp_erp60_sp/helpdata/en/
f9/4fd7531a4d424de10000000a174cb4/content.htm
324
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.2.2.1 Portrayal Using Additional Accounts
You can portray parallel accounting in your SAP system by creating additional accounts. This means that you
have two different account areas:
● One joint account area for postings that are the same for both accounting principles.
● One area with specific accounts for each accounting principle. Each business transaction is posted to the
specific account area depending on the accounting principle.
When you perform closing according to a specific accounting principle, the common accounts and the specific
accounts for this accounting principle are evaluated.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 325
You need to set up specific account determination in the following Customizing activity: Choose Financial
Accounting (New) Revenue Accounting Revenue Accounting Postings Configure Account Determination for
Specific Transactions
:
17.2.2.2 Portrayal Using Parallel Ledgers
In General Ledger Accounting, you can perform parallel accounting by running several parallel ledgers or general
ledgers for different accounting principles. During posting, you can post data to all ledgers, a specified selection of
ledgers, or a single ledger.
The data, required according to the accounting principle, for the consolidated financial statements is managed in
the leading ledger of the general ledger. This leading ledger is integrated with all subsidiary ledgers and is updated
in all company codes. This means that it is automatically assigned to all company codes.
For each additional (parallel) accounting principle, you have to create an additional (non-leading) ledger in
General Ledger Accounting.
SAP usually recommends that you implement this parallel ledger approach if the number of general ledger
accounts would be unmanageable for the scenario in question using additional accounts.
326
P U B LI C
SAP Revenue Accounting and Reporting
Transition
You can define ledgers in the following Customizing activity:
Choose Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers Ledger
Define Ledgers for General Ledger Accounting .
In this IMG activity, you define the ledgers that you use in General Ledger Accounting. The ledgers are based on a
totals table. SAP recommends using the delivered standard totals table FAGLFLEXT.
There are two types of ledger available:
● Leading Ledger: The leading ledger is based on the same accounting principle as that of the consolidated
financial statement. It is integrated with all subsidiary ledgers and is updated in all company codes. You have
to designate one ledger as the leading ledger. In each company code, the leading ledger automatically applies
the settings that apply to that company code: the currencies, the fiscal year variant, and the variant of the
posting periods.
● Non-Leading Ledger: The non-leading ledgers are parallel ledgers to the leading ledger. They can be based,
for example, on local accounting principles or can refer, as in this case, to the target accounting principle. You
must activate a non-leading ledger by company code. For each ledger that you create, a ledger group of the
same name is automatically created.
In IMG activity Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers Ledger
Define and Activate Non-Leading Ledgers , you configure the following settings of the non-leading ledgers for
each company code:
● You activate the non-leading ledgers in the company code.
● You can define additional currencies beyond that of the leading ledger. The first currency of a non-leading
ledger is always the currency of the leading ledger (and hence that of the company code). For the second and
third currencies of a non-leading ledger, you can only use currency types that you have specified for the
leading ledger.
● You can define a fiscal year variant that differs from that of the leading ledger. If you do not enter a fiscal year
variant, the fiscal year variant of the company code is used automatically.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 327
● You can specify a variant for the posting periods. If you do not enter a variant, the variant of the company
code is used automatically.
In IMG activity Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers Ledger
Define Ledger Group you can define ledger groups. A ledger group is a combination of ledgers for the purpose
of applying the functions and processes of General Ledger Accounting to the group as a whole. When posting, for
example, you can restrict the update of individual postings to a ledger group so that the system only posts to the
ledgers in that group.
You can combine any number of ledgers in a ledger group. In this way, you simplify the tasks in the individual
functions of General Ledger Accounting.
When a ledger is created, the system automatically generates a ledger group with the same name. This means
that you can also post data to an individual ledger or access it when using functions where you can only enter a
ledger group instead of a ledger.
Note
● You can change the name of the ledger group that was taken from the ledger.
● You only have to create those ledger groups in which you want to combine several ledgers for joint
processing in a function.
● You do not need to create a ledger group for all ledgers because the system automatically posts to all
ledgers when you do not enter a ledger group in a function.
Representative Ledger of a Ledger Group
The system uses the representative ledger of a ledger group to determine the posting period and to check
whether the posting period is open. If the posting period for the representative ledger is open, the system posts to
all ledgers of the group even though the posting period of the non-representative ledgers is closed. Each ledger
group must have only one representative ledger. For further details, please refer to the online documentation.
You can define your accounting principles in Customizing activity Financial Accounting (New) Financial
Accounting Global Settings (New) Ledgers Parallel Accounting Define Accounting Principles .
The accounting principles that you have defined are available in various functions in Financial Accounting, such as
in the report for foreign currency valuation in Manual Accruals. SAP therefore advises you not to delete the
accounting principles.
As a requirement, you have created a ledger. You then assign the desired ledger group to the accounting
principles under
Financial Accounting (New) Financial Accounting Global Settings (New) Ledgers
Parallel Accounting Assign Accounting Principle to Ledger Groups .
17.2.3 Assign Company Codes to Accounting Principles
You can define which company codes are supported under which accounting principles in Customizing activity
Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Assign Company Codes to
328
P U B LI C
SAP Revenue Accounting and Reporting
Transition
Accounting Principles . For each company code and accounting principle combination, you specify a legacy data
transfer date and a migration status to indicate the date on which Revenue Accounting should be productive for
this combination.
The following fields are relevant for transition:
● Transfer Date: The legacy data transfer date specifies the switch from your old revenue accounting system to
Revenue Accounting. This means that revenue is managed in your legacy system up until this date and that all
revenue that occurs after this date is managed in Revenue Accounting. You set the legacy data transfer date
to the last day in the last period covered by your legacy revenue accounting system. For all documents that
are posted on or before this date, the initial load function of Revenue Accounting expects to receive legacy
data, such as posted revenue. The transfer date always has to mark the end of the period, as only complete
periods can be closed. Revenue Accounting can only start at the beginning of a new period. The first period
after the legacy data transfer date is also the first period during which revenue is managed by Revenue
Accounting.
● Date of Adoption: The date as of which a company adopts a new standard for revenue recognition in its
published financial statement.
● Source Accounting Principle: In the transition phase, the source accounting principle is used as a basis to
copy data to the new accounting principle.
● External Source Accounting Principle: You tick the checkbox to indicate that the source accounting principle
is an external one, for example when it is not managed in Revenue Accounting.
For use case 1, where data is transferred to both accounting principles prior to the transition phase, you will have
to set up your accounting principles according to the old and new standards. Your source accounting principle
needs to be set up according to the old standard. The target accounting principle must be set up prior to the
beginning of the migration process according to the new rules, such as BRFplus rules.
Both accounting principles need to be in migration. The target accounting principle has the source accounting
principle of the old standard and is flagged as the External Accounting Principle.
The “Migration” status can only be set when the last period up to the transfer date is Closed or In Closing in the
source accounting principle (Customizing table FARR_C_ACPR_BUKR).
For use case 2, where the entity is already productive with Revenue Accounting and plans to reprocess the
revenue accounting items (RAIs), the transfer date of the target accounting principle in a company code
(migration package is initial) has to be the same or a later date than the transfer dates defined in the existing
productive accounting principles of the company code.
The date of adoption must be the first day of a period and can only be set to a date on or after which no events
have been processed.
You have also configured additional rules in BRFplus for the new accounting principle.
17.2.4 Authorization
You will need roles SAP_SR_FARR_REV_ACCOUNTANT and SAP_SR_FARR_REV_ADMIN for the transition process.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 329
17.3 Transition Process
The transition process may vary depending on whether the entity is already using revenue accounting or plans on
migrating from the operational system prior to transition.
In general, the process can be separated into the following steps:
Target accounting principle and company code combination in migration:
1. Perform operational load or reprocess revenue accounting items (RAIs) for new accounting principle.
2. Process initial load.
3. Calculate unbilled or deferred amount for both accounting principles.
Target accounting principle and company code combination in transition:
1. Reverse unbilled or deferred amount for target accounting principle.
2. Calculate cumulative catch-up.
3. Calculate time-based revenue for target accounting principle.
4. Calculate contract liability and contract asset for target accounting principle.
5. Perform comparative report.
6. Post revenue for target accounting principle.
17.3.1 Operational Load
If you are not currently using Revenue Accounting, you first need to migrate your data.
You can migrate data either from SAP operational components, such as SD, or any other legacy application. For
further details, please refer to the migration guide.
If you migrate from the operational component SD, you use transaction FARRIC_OL to perform the operational
load of existing documents in a system that marks customized document items as relevant for revenue
accounting.
Only customized sales order lines that are relevant for revenue accounting are loaded. Subsequent documents,
such as goods issued or billing relevant for revenue accounting, are also loaded.
If the sales order item is processed by SD-Revenue Recognition, the recognized revenue is calculated and
transferred as legacy data to the inbound processing of the revenue accounting module. After the item is loaded,
the SD-Revenue Recognition type is removed and the item is no longer processed by SD-Revenue Recognition.
The detail lines for SD-Revenue Recognition, that are used to post revenues, are set to Inactive. Otherwise, all SD-
Revenue Recognition tables remain available for reporting or audit purposes. If the sales order item is not relevant
for SD-Revenue Recognition, the billed value is transferred as legacy data. Once sales order items that use SD-
Revenue Recognition have been migrated, revenue recognition for the old standard, as well as new standard,
needs to be managed with Revenue Accounting.
In general, the transition process considers all contracts including completed contracts. IFRS 15 states that “ a
completed contract is a contract for which the entity has transferred all of the goods or services identified in
accordance with IAS 11 Construction Contracts, IAS 18 Revenue and related Interpretations.”
A contract is regarded as open at the date of adoption or at the start date of the comparative period, when it has
not yet been completely fulfilled and invoiced at that date.
330
P U B LI C
SAP Revenue Accounting and Reporting
Transition
It depends on specific regulations as to whether a contract is regarded as open. This means that it is completely
fulfilled according to the old standard but not according to the new standard at that date. For example, options for
material rights may still be open according to the new standard but not relevant according to the old standard.
You can skip the migration of completed contracts using BAdI definition FARRIC_BADI_ORDER, and method
CLEAR_RELTYPE_FLAG (clear the FARR_RELTYPE indicator for the selected item), which allows you to override
the relevance of a line item for revenue accounting.
17.3.2 Initial Load Processing
After the operational load, you process the revenue accounting items (RAIs) from the initial load which then
changes the status of the revenue accounting items from processable (2) to processed (4).
The processed revenue accounting items must have the initial load indicator set to 1 (Initial Load Due to New Co.
Code or Migr. Package) and can only be processed for accounting principles and migration packages that are in
Migration.
You can process the revenue accounting items from transaction Initial Load: Process Revenue Accounting Items
FARR_RAI_PROC_LOADor transaction Revenue Accounting Item Analysis FARR_RAI_MON. In Revenue Accounting
Item Analysis, you can display additional legacy information which can be activated in the personalization settings
of the report.
The corresponding contracts in the source accounting principle and target accounting principle are created
through the initial load
17.3.3 Reprocess Revenue Accounting Items for new
Accounting Principle
If you are already using Revenue Accounting productively with a combination of accounting principles and
company codes, you have to reprocess existing revenue accounting items (RAIs) under the source accounting
principle using transaction FARR_RAI_PROC_NEWACP. This step is in alternative to the operational load for use
case 1. For further details, please refer to the report documentation.
As a prerequisite, you introduced a new accounting principle for a company code in Customizing. The data for the
new (target) accounting principle should be created based on the revenue accounting information that is already
available in the system for a specified source accounting principle.
You use the report for reprocessing revenue accounting items for the new accounting principle before starting the
transition phase for the new accounting principle.
The report selects all processed revenue accounting items of the given company code. Revenue accounting items
before the transfer date are reprocessed for the target accounting principle and revenue accounting items after
the transfer date are copied back to the processable status. The latter items can be processed in the revenue
accounting item monitor (transaction FARR_RAI_MON) or with transaction FARR_RAI_PROC once the target
accounting principle is set to the Adoption Preparation status. Transaction FARR_RAI_PROC should be default.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 331
The date that is relevant for comparison with the transfer date differs for the different revenue accounting item
class types:
● Order items: If the inception date is maintained, this date decides whether the revenue accounting item is
immediately reprocessed or copied back to processable. Otherwise the field start date is evaluated. If neither
the inception date nor the start date are filled, the creation date for the performance obligation (POB) of the
source accounting principle is taken into account. The start date or performance obligation creation date is
stored in the inception date field in the revenue accounting item if this field was initial beforehand.
● Fulfillment items: Transfer date is compared to event date.
● Invoice items: Transfer date is compared to posting date.
Reprocessing revenue accounting items with this report for the new target accounting principle will update the
processing timestamp for the selected items. These revenue accounting items will therefore be taken into
account again for reconciliation between the Adapter Reuse Layer and Revenue Accounting Contract
Management.
Before introducing the new accounting principle in Customizing, you have to ensure that all revenue accounting
items of the company code, or at least those before the transfer date, are successfully processed. Otherwise
reprocessing revenue accounting items with this report cannot be executed, as this would lead to incorrect
postings later on.
In IMG Activity Assign Company Codes to Accounting Principles, you have to set the target accounting principle to
Migration. The source accounting principle needs to be maintained and its status set to productive for all
migration packages.
The graphic below outlines the general process for reprocessing revenue accounting items. You have processed
revenue accounting items which resulted in contracts according to the old revenue recognition standard. With the
program Reprocess Revenue Accounting Items for new Accounting Principle, these revenue accounting items are
reprocessed according to the new revenue recognition standard. Checks are performed against the transfer date
according to the logic outlined above. Based on the check, the revenue accounting item is either immediately
reprocessed or copied back to processable.
332
P U B LI C
SAP Revenue Accounting and Reporting
Transition
All existing revenue accounting contracts of the source accounting principle are reprocessed resulting in
contracts in the target accounting principle. The existing contracts of the source accounting principle remain
unchanged.
17.3.4 Clean-up Transition data
The data for the new accounting principle is created by reprocessing the revenue accounting item information by
applying the rules of the new accounting principle.
If the data has been created erroneously, for example the BRFplus rules were not set up appropriately or the
contract combination was not set up correctly, you can use report Clean-up Transition Data
(transactionFARR_NEWACP_CLEANUP) to reset the new accounting principle, either as a whole or for specific
source contracts. A source contract belongs to the source accounting principle. A similar function is available for
the initial load clean-up (transaction FARR_IL_CLEANUP). For further details, refer to the report documentation
and the migration guide.
Note
Data that is reset needs to be copied again afterwards.
The clean-up can only be performed while the new accounting principle status is set to Migration for this
company code and if transition is planned for the particular accounting principle.
As a prerequisite for this report, there must be revenue accounting data for the source accounting principle
and this accounting principle must be in productive use. The target accounting principle has been customized
in the SAP Reference IMG Assign Company Codes to Accounting Principles as being in Migration and having a
source accounting principle assigned. This source accounting principle is not external. Data of an existing
accounting principle has been copied.
The company code and the accounting principle, for which the transition has been performed, are mandatory
selection criteria for the report.
You can choose to only clean up items related to certain source contracts. If a contract refers to several
revenue accounting items (RAIs) which relate to more than one contract in the new accounting principle, these
contracts will all be removed, if possible. There may also be cases where the contracts for the new accounting
principle are not yet created. In this case, only the revenue accounting item data needs to be reset.
The Maximum Block Size parameter defines the maximum number of order items that the program processes
before the data changes are written to the database. The parameter can be used for performance tuning.
17.3.5 Contracts Created after Migration or Reprocessing of
Revenue Accounting Items
So far, the contracts under the old accounting standard show the same allocation results as under the new
accounting standard. If the corresponding policies have already been configured, the contracts in the target
accounting principle could contain additional performance obligations. However, the effects of this adjustment
will only be applied either once the contract has been reprocessed or once the cumulative catch-up has been run.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 333
Note
According to policies in the new accounting standard, you may have to update contracts or combine existing
contracts. In the simplest case, a contract with one performance obligation under the source accounting
principle is mapped to a contract or performance obligation under the target accounting principle. In other
more complex scenarios, you may need to add additional performance obligations, either automatically or
manually, to the new revenue accounting contract.
If you have added performance obligations manually to the source accounting principles, which are copied to the
target accounting principle with a new performance obligation ID, they are tracked in table FARR_D_MAPPING_M.
Note
This is only relevant for performance obligations that are added manually which are copied from the source
accounting principle to the target accounting principle. If you add a performance obligation manually after the
copy, in either the source or target accounting principle, it will not be tracked in any of the tables.
You may also want to combine contracts or performance obligations in the target accounting principle. Revenue
Accounting allows you to combine contracts. This usually happens when processing revenue accounting items
(RAIs) using the Initial Load Process.
You can also combine contracts if you reprocess revenue accounting items from an existing accounting principle.
In both cases, this is enabled through BAdI FARR_BADI_CONTRACT_COMBINATION. As a result of the
combination, you will find a mapping to several pairs of contracts and performance obligations for the same
revenue accounting item in different accounting principles in table FARR_D_MAPPING. Revenue Accounting also
allows you to manually combine contracts. This step has to be done after the status for the accounting principle
and company code combination has been set to Transition.
334
P U B LI C
SAP Revenue Accounting and Reporting
Transition
Note
If the combination of accounting principle and company code is still in migration, contracts cannot be changed
or combined.
17.3.6 Calculate Deferred and Unbilled Amount Under Status
Migration
After the initial load, you have to calculate deferred revenue and unbilled receivables for both of your accounting
principles. You can find the Calculate Contract Liabilities and Assets report under Revenue Posting Run in the SAP
Business Client for the Revenue Accountant role.
Note
This is only for information purposes and would not lead to additional FI postings. However, the Revenue
Accounting subledger posting table FARR_D_POSTING is updated and can be used to reconcile your migrated
data.
When running the Calculate Contract Liabilities and Assets report, you have to use the last period before transition
and the date should be the last date of that period. The program updates posting table FARR_D_POSTING under a
reconciliation key that is marked for migration in the reconciliation key table FARR_D_RECON_KEY.
In the example below, the source accounting principle is IFR1 and the target accounting principle is IFR2.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 335
17.3.7 Change to Transition under New Accounting Standard
In the next step after MIGRATION, you have to change the status to TRANSITION for your target accounting
principle in Customizing under
Revenue Accounting Revenue Accounting Contracts Assign Company
Codes to Accounting Principles .
There can be only one accounting principle for a company code in Transition or Adoption preparation.
All reconciliation keys in the migration period must be processed first (for example, contract asset/liability has
been calculated and closed), if the status is changed from Migration to Transition, from Transition to Adoption
preparation, or from Migration to Productive.
If a new migration package is created for a company code and accounting principle combination and its status is
set to Transition, the transfer date of the new package must be the same as the transfer date of the company
code and accounting principle combination.
You then change the settings for the accounting principle of the new standard to the new settings in Customizing
Revenue Accounting Revenue Accounting Contracts Configure Accounting Principle-specific Settings .
17.3.8 Reverse Migrated Unbilled Receivable and Deferred
Revenue
The target accounting principle has to post information according to the new accounting standard and, as a
result, deferred revenue and unbilled receivables that have already been calculated need to be reversed.
336
P U B LI C
SAP Revenue Accounting and Reporting
Transition
These transactions will not only update the posting table FARR_D_POSTING but will also update the FI general
ledger under the new accounting principle. This is usually posted to a special period for FI.
To reverse these items, you can run transaction FARR_TRANS_REV_URDR or program
FARR_REVERSE_LIAB_4_CHG_ACTPR. Enter your accounting principle for the new standard (IFR2 in the example
below). You can initially run the program in test mode. The job log will appear where you can check that the
program would have reversed your deferred and unbilled entries, as well as corresponding receivable adjustments
for the target accounting principle.
17.3.9 Cumulative Catch-Up
Once the accounting principle is switched to transition, the contracts under the target accounting principle need
to be restated. It is still possible to add performance obligations (POBs), contract combinations and any further
changes. For example, during transition it is possible to change the fulfillment event type from invoice to goods
issue, or the fulfillment type from event-based to percentage of completion (PoC) manually or by Business Rule
Framework plus (BRFplus) derivation for performance obligations with fulfillment.
● For the new goods issues event type, fulfilled quantities up to the transition date must have been transferred
from an operational application, a legacy system, or the old accounting principle. The cumulative catch-up
determines the fulfilled quantity at the transition date from the historic goods issue events.
● For the new percentage of completion event type, a percentage of completion must have been transferred
from an operational application, a legacy system, or the old accounting principle. The percentage of
completion can also be maintained manually in the new accounting principle.
Manual changes are possible in transition status in the same way as they are in productive status. For example,
the partially fulfilled contracts can be combined, additional performance obligations can be created, and price
changes can be allocated. You can edit performance obligations as you would usually in Revenue Accounting, and
you can also change the fulfillment event type as described above.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 337
If an accounting principle and company code combination is in transition, then any manual change or manual
combination is considered as a retrospective change with cumulative catch-up from contract inception.
The cumulative catch-up effect is calculated from the changes between the source and target accounting
principles. This means the effect on the accounts for receivables, unbilled receivable or deferred revenue, and
contract asset or liability from the difference between the historic, cumulative recognized revenue at transition
date, and the recalculated recognized revenue up until that date according to the new performance obligation
attributes. It contains:
● Effects from any changes due to BRFplus derivations or manual changes in the transition phase. These
effects can be calculated for each change and stored separately. They could also be recalculated when the
report is executed.
● Contract asset and liability (or deferred revenue and unbilled receivable) which is recalculated.
● Time-based revenue which is recalculated if the start date, end date, deferral method, or allocated price has
been changed.
You can use transaction FARR_TRANS_CATCHUP to reprocess your contracts under the target accounting
principle. The effect of recalculation is stored under a specific reconciliation key that is marked for transition.
If changes to time-based performance obligations, for which future revenue has been maintained manually, lead
to a change in allocated price or to a cumulative catch-up of recognized revenue, their manual spreading is
invalidated and time-based revenue is recalculated.
The Revenue Accounting will keep the manual allocation result that is calculated in the old accounting principle,
if possible.
When a contract is created in transition, contract management will first check if the input allocation result is valid:
● If yes, no new automatic default allocation is needed.
● Otherwise, the system displays a warning message during migration and the contracts are marked with an
error status and put in the conflict worklist.
338
P U B LI C
SAP Revenue Accounting and Reporting
Transition
17.3.10 Prepare and Analyze Comparative Report
After the legacy data has been transferred to Revenue Accounting for the target accounting principle, the system
provides the Web Dynpro application Comparative Report for Source and Target Accounting Principle. The
application compares the main differences according to the posting category, and by groups of contracts and
performance obligations (POBs).
The comparison follows a two-step approach:
1. Execute a parallelized job to prepare reporting data.
2. Analyze comparative data that is summarized, or comparative data detailed by grouping ID.
You can run transaction FARR_PREPARE_COMP to prepare data for the comparison between the source and target
accounting principles regarding allocated amount, recognized revenue or cost, and invoice correction. The report
stores comparative data by grouping ID in table FARR_D_COMP_TRAN.
The grouping ID groups the contracts and performance obligations of the source accounting principle together
with the contracts and performance obligations of the target accounting principle (see earlier example).
You can extend the comparative result table FARR_D_COMP_TRAN with additional fields, for example, sales
organization.
To add customer fields, or fields that already exist in the performance obligation table FARR_D_POB, to this
comparative report table FARR_D_COMP_TRAN, you need to do the following:
1. Create an append structure for the structure INCL_EEW_FARR_TRANSITION, and then add fields to this new
append structure.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 339
Note
1. If you add fields which exist in FARR_D_POB but do not exist in FARR_D_COMP_TRAN (these field names
do not start with YY or ZZ), a warning message will appear when you activate it. If you want to add
them, just ignore this warning.
2. If you only add fields from FARR_D_POB, the data of all the added fields will automatically be put into
the results table FARR_D_COMP_TRAN (SAP code uses the MOVE-CORRESPONDING statement
internally).
2. If you add other customer fields which do not exist in FARR_D_POB, then you can implement the Business
Add-In (BAdI) FARR_BADI_COMP_TRAN_ADD_STRUC to write the data to the results table
FARR_D_COMP_TRAN.
All fields added to the structure INCL_EEW_FARR_TRANSITION will automatically be available in the report
Display Result of Comparative Report.
● For the Search part, click the dropdown box of the existing selection criteria. Then you can see the customer
fields at the end of the list.
● For the Result list, click the Settings link on the top-right hand side of the list. Then you can see the customer
fields are listed in the Hidden Columns area.
17.3.11 Calculate Time-Based Revenues
To reflect the changes for time-based performance obligations (POBs) between the source and target accounting
principles, you need to run the program for time-based revenue calculation (transaction FARR_TM_TRANSFER)
after the calculation of the cumulative catch-up effect. The program transfers the effect on time-based revenues
to the Revenue Accounting posting table.
If changes to time-based performance obligations, for which future revenue has been maintained manually, lead
to a change in allocated price or to a cumulative catch-up of recognized revenue, their manual spreading is
invalidated and time-based revenue is recalculated.
17.3.12 Calculate Contract Liability and Contract Asset
In the next step, the new contract asset/liability balances need to be calculated using the Calculate Contract
Liabilities and Assets program (transaction FARR_LIABILITY_CALC). The new balances are calculated depending
on the current settings of the accounting principle and posted against the receivable adjustment.
17.3.13 Post Revenues
You can use transaction FARR_REV_POST to post the effects of the cumulative catch-up.
This is the difference between recalculated cumulative recognized revenue up to the transfer date according to
new attributes and the recognized revenue that has been transferred as posted recognized revenue up to the
340
P U B LI C
SAP Revenue Accounting and Reporting
Transition
transfer date. This means that the program clears the balances of unbilled receivables and deferred revenue
against receivable adjustment, and builds up contract asset and contract liability. Revenue adjustment is posted
automatically for the new standard for each dedicated revenue account.
To run the post revenue transaction, you select data based on the period referring to the transfer date. Once you
switch to the posting mode, you can enter a special FI period, for example 13 to 16.
As a follow-on process, the cumulative catch-up needs to be posted against retained earnings.
17.3.14 Integration with Cost Object Controlling
Use
For controlling objects with a results analysis key that is relevant for revenue accounting, the transition follows the
following logic:
For controlling objects, for which results analysis forwards a percentage of completion, no work in process needs
to be adjusted as costs are still managed in cost object controlling. The standard cumulative catch-up in revenue
accounting will perform reallocations and other adjustments, and monitors the differences in a special
reconciliation key. The existing revenue and cost accounts will update the related controlling objects.
For controlling objects with a revenue-based results analysis method, the cumulative catch-up will change costs
and work in progress in cost object controlling.
Transition postings for revenue accounting and results analysis need to be done in a special period. The valuation
difference, as a result of the cumulative catch-up, can be reported from this special period. The retained earnings
need to be posted manually.
Note
Revenue and cost accounts must not be changed to a retained earning account to ensure that the controlling
objects are updated correctly.
Note
Cumulative catch-up is only supported if values relate to two accounting principles in revenue accounting.
Prerequisites
Special period is available for postings to results analysis and revenue accounting.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 341
Activities
In addition to other activities in transition:
Post the retained earnings manually based on value differences which were tracked by cumulative catch-up in the
special period.
17.4 Use Case Example
The following example will help you to gain a sound understanding of the transition process in Revenue
Accounting.
The example is based on using the parallel accounting approach with additional accounts. The opening balance
for the source accounting principle indicates a cash balance of 10,000 and an equity of 10,000 as the opening
balance. The transfer date is 31.12.2015.
Under the old accounting standard, the entity can report profits of 2,005, receivables of 2,305 and deferred
revenues of 300. An update on the cash position is not considered in order to simplify the above example. Equally,
other positions such as contract asset, and so on, are not taken into account. However, they follow the same logic
as described below.
In the following scenario, the transition process is outlined based on four contracts in set ups.
In the first contract, there is one performance obligation (POB) for providing a smartphone to the customer.
The smartphone has been delivered and invoiced. The total amount is EUR 800. This means that the contract is
completely fulfilled and invoiced under the policy of the old standard.
342
P U B LI C
SAP Revenue Accounting and Reporting
Transition
Under the legislation of the new accounting standard, a new performance obligation (POB) shall be added for a
specific care program assuming that the entity did not have to be accounted for under the old accounting
standard.
This performance obligation is time-based starting with the inception date of the overall contract, which is before
the transfer date.
However, based on the nature of the contract, this time-based performance obligation extends into the
comparative period after the adoption date.
There are also allocation effects between the performance obligation for the device and the performance
obligation for the care program which need to be reallocated under the target accounting principle revenue in
contrast to the source accounting principle.
This means that the contract under the new accounting standard is actually in a contract liability status, as it has
been fully invoiced but not fully fulfilled.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 343
In the second contract, a subscription order has been partly fulfilled and invoiced. Revenue is recognized monthly,
while the invoicing is performed quarterly. The contract under the old legislation is not in a deferred state.
Under the new accounting standard, a free service needs to be included in the allocation. The service is also time-
based but is provided over a time frame of 24 months. Revenue recognition continues monthly, and invoicing
quarterly.
Allocations effects need to be considered under the new accounting standards. This means that only 362,26 are
allocated to the service and the residual amount to the service for the overall contract. As both performance
344
P U B LI C
SAP Revenue Accounting and Reporting
Transition
obligations are time-based, the allocation is split up according to the duration of the performance obligation. By
reallocating the costs, the contract is in a contract liability state at the end of FY15.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 345
The third contract deals with a compound contract for hardware, including a smartphone and a USB stick. The
contract has been fulfilled and invoiced, however it needs to be included in the transition process.
Under the new legislation for the contract, the allocation effects that lead to a reallocation of revenue at the end of
FY15 need to be considered.
The last contract is an event-based contract for delivering a material with a quantity of 10. At the end of FY15, 2
units have been delivered and 5 units invoiced. This means that the contract is in a deferred state of 300.
346
P U B LI C
SAP Revenue Accounting and Reporting
Transition
No reallocation is required. However, the deferred amount needs to be transferred to contract liability.
First, the accounts used for parallel accounting need to be prepared. The postings below describe a typical
scenario. However, they may differ from customer to customer. To set up the specific accounts as part of the
preparation tasks, as in the example below of deferred revenue, the entity posts from the common accounts
against an IFRS adjustment account, and vice versa, and the adjustment effects against the specific accounts for
the old and new accounting standard.
Second, the cumulative catch-up is posted by the Revenue Accounting engine. This results in a debit of 300 to
reverse deferred revenue (from Contract Example 4), and a credit of contract liability of 376 (from Contract
Example 1 (66,67), 2 (9,43) and 4 (300,00)).
Revenue adjustments are posted with a debit of 419 and a credit of 343 through the allocation effects.
The cumulative catch-up effect on equity in this example is -76 and needs to be posted by the entity against
retained earnings as a follow-on step.
SAP Revenue Accounting and Reporting
Transition
P U B LI C 347
348 P U B L I C
SAP Revenue Accounting and Reporting
Transition
18 Archiving
You can remove data that you no longer require operatively from the database and store it in archive files. The
data archiving concept is based on the Archive Development Kit (ADK).
The following provides information on the archiving objects provided by SAP.
For more information, see the documentation on data archiving in the SAP NetWeaver Library (on the SAP Help
Portal at http://help.sap.com/nw SAP NetWeaver Platform Application Help Function-Oriented View
Solution Life Cycle Management ).
18.1 Archiving of Revenue Accounting Contracts
(FARR_CONTR)
Use
To reduce the load on your database, you can archive revenue accounting contracts that are no longer needed.
Archiving of revenue accounting contracts takes place using the archiving object FARR_CONTR.
Features
Tables
The archiving object FARR_CONTR archives data from the following tables:
Table Reference
Table 242:
Structure Structure Name
FARR_D_CONTRACT
Contracts (headers)
FARR_D_CONT_ERR
Log messages for contract errors
FARR_D_DEFITEM
Accrual items
FARR_D_EV_CONTR
Events that arose for contracts
FARR_D_FULFILLMT
Fulfillment entries
SAP Revenue Accounting and Reporting
Archiving
P U B LI C 349
FARR_D_POB_HIS
Histories for changes to performance obligations/contract
structures
FARR_D_POB
Performance obligations
FARR_D_POSTING
Postings
FARR_D_RECON_KEY
Reconciliation keys
FARR_D_DEFERRAL
Accruals
FARR_D_INVOICE
Invoice entries
FARR_D_MANL_CHNG
Manual Changes
You can display a list of the generated database tables that the archiving object FARR_CONTR accesses. To do so,
in archive administration, choose the Database Tables pushbutton. From these generated tables, you can write
data to archive files and, in the deletion phase, you can remove this data from the database. Subsequently, the
entries in the tables can also be restored.
Data Object
The data object contains all important data for a contract. The system writes the data objects sequentially to an
archive file. They all have the same structure in accordance with the description in the archiving object.
Programs
The archiving object FARR_CONTR uses the following programs:
Table 243:
Program Function
RFARR_CONTR_AR01
Archiving program:
RFARR_CONTR_AR02
Deletion program
RFARR_CONTR_AR03
Reload program
For the deletion program, SAP provides the standard variants SAP&PROD (update mode) and SAP&TEST (test
mode).
Call
You archive (and also delete) using the SAP standard tool for archiving, the Archive Development Kit. Call Archive
Administration (transaction
SARA on the SAP Easy Access screen under Tools Administration
Administration Data Archiving ) and enter archiving object FARR_CONTR.
Note for Integration with SAP NetWeaver Information Lifecycle Management
The current archiving object is integrated with SAP NetWeaver ILM.
350
P U B LI C
SAP Revenue Accounting and Reporting
Archiving
If you have configured SAP NetWeaver ILM and this archiving object accordingly, the write program that
generates the archive files displays the ILM Actions group box. In this group box, you can choose one of the
following radio buttons:
● Archiving
● Data Destruction
For more information, see the documentation for these radio buttons in the system and in the application help for
SAP NetWeaver ILM.
18.1.1 Checks (FARR_CONTR)
You can archive a revenue accounting contract if the following applies for the revenue accounting contracts to be
archived:
● They have the contract status Concluded (signed).
● The date on which they were signed is entered.
● They are updated.
18.1.2 Application-Specific Customizing (FARR_CONTR)
You define the residence time for revenue accounting contracts and activate the Archive Info Structure in
Customizing for Revenue Accounting under Revenue Accounting Revenue Accounting Contracts
Archiving .
Note
You are allowed to archive revenue accounting contracts only if the date, on which the contract was signed, is
further in the past than the residence time.
18.1.3 Variant Settings for Archiving (FARR_CONTR)
Use
The variant contains the selection criteria for the revenue accounting contracts that you want to archive.
SAP Revenue Accounting and Reporting
Archiving
P U B LI C 351
Activities
You schedule the write program as follows:
1. Enter an already existing variant or create a new variant.
2. Enter the start date and the spool parameters.
3. Restrict the selection of the revenue accounting contracts using the date on which the contract was signed
and using additional selection criteria.
4. If you want the write program to only run a simulation for the revenue accounting contracts you selected,
choose Test Mode.
The system then reads the data, but does not create an archive file. The system issues a statistic about the
number of data records read during the test run.
5. If you want the write program to create an archive file for the revenue accounting contracts you selected,
choose Production Mode.
If you chose the option Start Automatically for the deletion program in Customizing for the archiving object
FARR_CONTR, and you choose a productive variant for the archiving program, then the deletion program also
starts with a productive variant following the archiving program. That means that after archiving, the system
deletes the data from the database.
If you do not set the Detailed Log indicator, you receive only a summarized log of the processed objects without
success messages.
If you set the Detailed Log indicator, the write program outputs a detailed log with success messages. The detailed
log also contains, in addition to the information contained in the compact log, all processed objects including the
messages belonging to them.
If you set the Log Output indicator, the system writes the log both in the spool list and in the application log.
In the comment for the archiving run, you can enter a text that describes the contents of the archive files of the
archiving run.
18.1.4 Displaying Archived Revenue Accounting Contracts
(FARR_CONTR)
Use
You can display archived table entries in the Archive Explorer in the Archive Information System (transaction
SARI).
Prerequisites
● For the archiving object FARR_CONTR there is at least one information structure; you have created this
information structure on the basis of the standard field catalog SAP_FARR_CONTR provided by SAP. SAP
provides the archive information structure SAP_FARR_CONTR for field catalog SAP_FARR_CONTR.
352
P U B LI C
SAP Revenue Accounting and Reporting
Archiving
● The information structure is activated and structured.
● The information structure contains the fields CONTRACT_ID (Contract) and POB_ID (Performance Obligation)
as key fields.
● The information structure contains the fields Company_Code (Company Code) and Accounting_principle
(Accounting Principle) as additional fields.
18.2 Archiving of Revenue Accounting Items (FARR_RAI)
Use
To reduce the load on your database, you can archive revenue accounting items that are no longer needed.
Archiving of revenue accounting items takes place using the archiving object FARR_RAI.
Note
A revenue accounting item can have various statuses. The system manages the various statuses of revenue
accounting items from a technical perspective by using different database tables. Archiving takes into account
only those revenue accounting items with the status Processed.
You store revenue accounting items in various database tables. When a revenue accounting class is created, the
system generates the tables for data storage of revenue accounting items separately for each class. In relation to
the database tables used, the system also differentiates based on the following record types:
● Main items
These represent the actual accounting items.
● Condition Items
These represent supplements to the main items.
The system stores the main items and condition items in separate database tables. Using the archiving object
FARR_RAI, you archive processed revenue accounting items of revenue accounting class type 01 (order items),
including the related processed revenue accounting items of revenue accounting class type 02 (fulfillment items)
and revenue accounting class type 03 (invoice items), from all database tables used for data storage.
Structure
The archiving object has the following structure:
Table 244:
Structure Structure Name
FARR_S_RAI4_HEAD_ARCH
Archiving structure for revenue accounting items (header)
FARR_D_COMP
Archiving structure for combined contract items
FARR_D_RAI_CH
Archiving structure for change items
FARR_D_LEGACY
Legacy data from the initial load for revenue accounting items
SAP Revenue Accounting and Reporting
Archiving
P U B LI C 353
FARR_D_LEGACYC
Legacy data from the initial load for conditions for revenue ac
counting items
FARR_D_LEGACYSF
Legacy data for planned order fulfillment
FARR_D_RAI_HIST
History table for excepted revenue accounting items.
Tables
You can display a list of the generated database tables that the archiving object FARR_RAI accesses. To do so, in
archive administration, choose the Database Tables pushbutton. From these generated tables, you can write data
to archive files and, in the deletion phase, you can remove this data from the database.
Data Object
The data object contains all processed items of revenue accounting class type 01 (order items), including the
related processed revenue accounting items of revenue accounting class type 02 (fulfillment items) and revenue
accounting class type 03 (invoice items), The system writes the data objects sequentially to an archive file. They
all have the same structure in accordance with the description in the archiving object.
Programs
The archiving object FARR_RAI uses the following programs:
Table 245:
Program Function
RFARR_RAI_AR01
Write program for archiving processed revenue accounting
items
RFARR_RAI_AR02
Deletion program
RFARR_RAI_AR03
Read program
For the deletion program, SAP provides the standard variants SAP&PROD (update mode) and SAP&TEST (test
mode).
Call
You archive (and also delete) using the SAP standard tool for archiving, the Archive Development Kit. Call Archive
Administration (transaction
SARA on the SAP Easy Access screen under Tools Administration
Administration Data Archiving ) and enter archiving object FARR_RAI.
Note for Integration with SAP NetWeaver Information Lifecycle Management
The current archiving object is integrated with SAP NetWeaver ILM.
If you have configured SAP NetWeaver ILM and this archiving object accordingly, the write program that
generates the archive files displays the ILM Actions group box. In this group box, you can choose one of the
following radio buttons:
● Archiving
● Data Destruction
354
P U B LI C
SAP Revenue Accounting and Reporting
Archiving
For more information, see the documentation for these radio buttons in the system and in the application help for
SAP NetWeaver ILM.
18.2.1 Checks (FARR_RAI)
You can archive revenue accounting items, if the revenue accounting contract to which the revenue accounting
item relates was deleted (see Archiving of Revenue Accounting Contracts (FARR_CONTR) [page 349]).
18.2.2 Application-Specific Customizing (FARR_RAI)
You activate the archive information structure in Customizing for Revenue Accounting under Revenue
Accounting Inbound Processing Archiving .
18.2.3 Variant Settings for Archiving (FARR_RAI)
Use
The variant contains the selection criteria for the revenue accounting items that you want to archive.
Activities
To schedule the write program:
1. Enter an already existing variant or create a new variant.
2. Enter the start date and the spool parameters.
3. Enter the revenue accounting item class that contains the processed items you want to archive.
4. Restrict the selection of the revenue accounting items to be archived using the date of creation of the revenue
accounting item they belong to.
5. If you want the write program to only run a simulation for the revenue accounting items you selected, choose
Test Mode.
The system then reads the data, but does not create an archive file. The system issues a statistic about the
number of data records read during the test run.
6. If you want the write program to create an archive file for the revenue accounting items you selected, choose
Production Mode.
If you chose the option Start Automatically for the deletion program in Customizing for the archiving object
FARR_RAI, and you choose a productive variant for the archiving program, then the deletion program also starts
with a productive variant following the archiving program. That means that after archiving, the system deletes the
data from the database.
SAP Revenue Accounting and Reporting
Archiving
P U B LI C 355
If you do not set the Detailed Log indicator,
you receive only a summarized log of the processed objects, without success messages. If you set the Detailed
Log indicator, the write program outputs a detailed log with success messages. The detailed log also contains, in
addition to the information contained in the compact log, all processed objects including the messages belonging
to them.
If you set the Log Output indicator, the system writes the log both in the spool list and in the application log.
In the comment for the archiving run, you can enter a text that describes the contents of the archive files of the
archiving run.
18.2.4 Displaying Archived Revenue Accounting Items
(FARR_RAI)
Use
You can display archived table entries in the Archive Explorer in the Archive Information System (transaction
SARI).
Prerequisites
● For the archiving object FARR_RAI there is at least one information structure; you have created this
information structure on the basis of the standard field catalog
SAP_FARR_RAI provided by SAP. SAP
provides the archive information structure SAP_FARR_RAI for field catalog SAP_FARR_RAI.
● The information structure is activated and structured.
● The information structure contains the following fields as key fields:
○ RAIC (Revenue Accounting Item Class)
○ SRCDOC_COMP (Sender Component of Original Item)
○ SRCDOC_LOGSYS (Logical System of Original Item)
○ SRCDOC_TYPE (Type of Original Document Item)
○ SRCDOC_ID (ID of Original Item)
○ BUKRS (Company Code)
356
P U B LI C
SAP Revenue Accounting and Reporting
Archiving
Important Disclaimers and Legal Information
Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.
Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a
binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does
not apply in cases of willful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.
Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales
person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not
exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not
warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages
caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency
(see: http://help.sap.com/disclaimer).
SAP Revenue Accounting and Reporting
Important Disclaimers and Legal Information
P U B LI C 357
go.sap.com/registration/
contact.html
© 2017 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any
form or for any purpose without the express permission of SAP SE
or an SAP affiliate company. The information contained herein may
be changed without prior notice.
Some software products marketed by SAP SE and its distributors
contain proprietary software components of other software
vendors. National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company
for informational purposes only, without representation or warranty
of any kind, and SAP or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only
warranties for SAP or SAP affiliate company products and services
are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein
should be construed as constituting an additional warranty.
SAP and other SAP products and services mentioned herein as well
as their respective logos are trademarks or registered trademarks
of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the
trademarks of their respective companies.
Please see http://www.sap.com/corporate-en/legal/copyright/
index.epx for additional trademark information and notices.
