With this blog series I shall provide an overview on different aspects of SAP’s Revenue Accounting and Reporting software. SAP’s Revenue Accounting enables an organization to adhere to the current accounting standard and realize the revenue from its operational documents.
- Revenue Accounting – Inbound Processing, Revenue Contracts and Performance Obligations
- Revenue Accounting – Price allocation and Contract Change
- Revenue Accounting – Fulfillment and Revenue Posting
- Revenue Accounting – Reconciliation and Reporting
- Revenue Accounting – Migration, Transition and Archiving
- Revenue Accounting – Administration and Extensibility
Revenue Accounting – Inbound Processing, Revenue Contracts and Performance Obligations
Inbound Processing
Revenue Accounting receives operative data from the integrated components and stores it in the form of Revenue Accounting Items (RAIs). The operative data will include orders, invoices and order fulfillment. These RAIs once processed, uses this data for creating/updating/fulfilling Performance Obligations in a Revenue Contract.
Performance Obligations can be defined as a contractual commitment of an enterprise to deliver a good or a service to a customer in exchange for a consideration. Usually a Performance Obligation corresponds to an item in the operational document, such as a sales order item.
Revenue Accounting Contract serves as a container for multiple performance obligations and represents the financial view of one or multiple operational documents, such as sales orders.
Coming back to RAIs, the technical properties of RAIs are determined from the Revenue Accounting Classes. These properties can be standard fields, custom fields, database tables, function modules that receive the RAIs and function modules that save the RAIs.
The RAIs can have 3 status - raw, processable and processed. Enhancements are available to enrich and check RAIs before they achieve the raw status and the processable status. For each status and revenue accounting class there will be 2 database tables, one for the main items and one for the pricing conditions.
The transaction FARR_RAI_MON can be used to display, analyze and process the RAIs and in case of failure in processing of RAIs, the error information can be accessed from the application log via transaction SLG1 with the object FARR. Mass processing of RAIs is also possible via transactions FARR_RAI_TRANS and FARR_RAI_PROC.
Performance Obligations(POBs)
As mentioned above, Performance Obligations represents a contractual commitment. Usually it would be explicit and distinct and posted separately for revenue recognition.
In certain cases, the company promises to deliver to the customer some items that may not be explicitly included in the operational document but they need to be included in the revenue accounting contract. In such case a linked performance obligation is created for the implicit promise and a leading performance obligation is established which refers to the item in the operational document. For example, on sale of a software, the company delivers a service to check if the software is deployed properly. In this case the software will be the leading POB and the service will be the linked POB.
It is also possible for POBs to be arranged in a hierarchy with an established relationship between the POBs. This relationship can represent a sales BOM( root POB is the finished product and lower level POB will be the components ) or can be a compound POB. The compound POB is a combination of non-distinct POBs which can't be posted separately. As a result a compound POB is required for revenue recognition.
In some cases the company promises to deliver some items that may not be included in the operational document, however it still needs to be included in the revenue accounting contract. In such cases a manual POB is created. The difference between the manual POB and linked POB is that a manual POB doesn't have a leading POB. They don't correspond to any item in the sales order and unless time based fulfillment is specified, they are fulfilled manually.
The linked POBs and manual POBs can be deleted from the UI however POBs created from operational documents can't be deleted. The deletion can be soft deletion and hard deletion.
Soft deletion is when the POB is marked deleted so that it is not available for allocation or fulfillment and fulfillments that have not been posted are deleted but other fulfillments and deferral items are retained.
Hard deletion is when the complete POB is cleaned out of the system.
If after creation of the POBs , the operational document is cancelled then a finalization date is set on the POB and the POBs are set to completed status. The invoiced amount will become the contractual price of the POB and recognized as revenue.
Revenue Accounting Contract
As mentioned above, Revenue Accounting Contract serves as a container for multiple performance obligations and represents the financial view of one or multiple operational documents, such as sales orders. The revenue accounting contract offers a single entry point for the POBs of the involved operational documents and allows the user to carry out changes to the contract from the UI like changes to POB attribute, addition of manual and linked POBs, manually fulfill the POBs, change the allocation and spreading, combine contracts, etc.
In case when something is manually changed in the contract from the UI and the back end also requests changes to the same POB , then a conflict occurs. These contracts need to be reviewed and the contract needs to be resolved via the contracts in conflict UI.
The system allows reprocessing of account determination and reprocessing of contracts. In reprocessing of account determination, the account assignment data is reevaluated while in reprocessing of contracts, the POB are regenerated and the POB attributes are rederieved.
References
