US Generally Accepted Accounting Principles (GAAP) state that companies should recognize revenue when it is realized. Companies may struggle to comply with this principle when dealing with multiple-element products, as the different elements may need to be recognized at different times. Because revenue is an indicator of the financial robustness of an organization, if a company reports revenues inappropriately in its financial statements, it may paint a misleading picture to stakeholders and shareholders. Therefore, it is imperative to recognize the revenue at the correct time for legal compliance with GAAP requirements. I’ll show you a method to compute vendor-specific objective evidence (VSOE)-based fair value before carrying out revenue recognition that complies with GAAP requirements.

I’ll take you through an example in which a company creates a multiple-element product. The product in the example is software that includes an initial version, an upgrade one year later, and services such as a one-year contract for customer support. The company can recognize the revenue for the sale of the initial version of the software on the purchase date, but it can’t do the same for the version upgrade, which happens a year later, or the customer service contract, which happens throughout the year.

This process involves creating a multiple-element product in the SAP system, then computing the VSOE-based fair value for the elements of the product. After creating a multiple-element product, I’ll show you how to carry out revenue recognition for it on the basis of VSOE-based fair value. This process, which derives from my experience, is in accordance with the American Institute of Certified Public Accountants’ (AICPA) Statement of Position (SOP) 97- 2. I’ve created the model on R/3 Release 4.7, but it also works on SAP ERP Central Component (ECC) 5.0 and 6.0. You may face variations to my example at your workplace depending on the product and terms and conditions of sale, but the basic concept remains the same.

Create a Multiple-Element Product

A multiple-element product includes multiple finished products or services. You need to create a material master using transaction MM01 for the multiple- element product and its elements. The multiple-element product (D000) I use in this article has three elements: D001, D002, and D003. You need to create all of the material masters using material type DIEN, which you need to specify on the first screen in transaction MM01. Material type DIEN is used for services. I’ve used it because the product offering includes both physical products and services.

Set the Item category group in the sales view of the multiple-element product’s material master to LUMF (Figure 1). It allows for the creation of a sales bill of material (BOM) and enables the multiple-element product to explode into its component elements in a sales order. You can use NORM as the Item category group in the component element’s material master. Item category group controls several elements related to sales documents, such as whether the item should create a delivery or a billing document. Selecting NORM here ensures that the system creates a billing document (invoice) for this item.

Figure 1

Sales view of multiple-element product’s material master

Create a sales BOM for the multiple-element product using transaction CS01. Set the BOM Usage on the first screen to 5. The system uses this sales BOM to define the sub-components of the product it breaks down when creating the sales documents (Figure 2). I’ll present an example sales document later in which the system has broken down the multiple-element product into its sub- components depending on the sales BOM definition.

Figure 2

Define sales BOM

You have to define a new item category for the multiple- element product and another one for the elements. Follow menu path SPRO > Sales and Distribution > Sales > Sales Documents > Sales Document Item > Define Item Categories to define item category ZSBM for the multiple-element product. Define Structure scope as A, which controls that only the single-level sales BOM is broken down into sub-components in the sales document. The multiple- element product created in this article has a single-level sales BOM, which is the one that you want to break down into sub-components in this scenario.

I defined item category ZMVB for use with the sub-components of the multiple element product. The process for defining this is the same as what I used defining item category ZSBM, with the exception that the structure scope for ZMVB is blank. I defined the structure scope as blank because you do not need to break the elements down into further sub-components. Define Revenue Recognition and Delimit. Start Date as A. This enables time-related revenue recognition based on a contract start date. Thus, defining the contract start and end dates can control revenue recognition in the contract.

Use transaction VOV4 to assign a sales document type and an item category group for use in the contract to item categories (Figure 3). In my example, I used WV as the sales document type (SaTy) and assigned the item category group type in the material master.

Figure 3

Item category assignment

Compute VSOE-Based Fair Value of Elements

SOP 97-2 requires the use of relative fair value method for all elements of a multiple-element product in which objective and reliable evidence of fair value is present for all of the elements. You can use the residual method — finding out the fair value of the delivered product by subtracting the fair value of the undelivered product from the total value — to value the delivered product if objective and reliable evidence is available only for the undelivered elements. You cannot assign a value to any element if objective and reliable evidence is available only for the delivered elements. In such a circumstance, you can only recognize the revenue when all of the elements have been delivered.

In my example, I have created a multiple-element product priced at $1,640. It is comprised of a license for version 1.0 of the software, one-year customer support (PCS), and the right to receive version 2.0 a year from now when it becomes available. The customer downloads the software version 1.0 on 11/09/2006. Version 1.0 is sold separately in the market for $1,200. The customer can use PCS for a year at a cost of $288 separately. The company has decided to offer the upgrade to version 2.0 at a cost of $500. After purchasing, the customer cannot return version 1.0 of the software without voiding further discounts. It is expected from past experience that 80% of the users will exercise the upgrade to version 2.0. Fair value argument suggests that you should recognize $400 ($500 * 80% = $400) after a year (when version 2.0 is delivered) against the upgrade element.

You need to valuate version 1.0 of the software, recognized on the download date (in this example, 11/09/2006) at:

• Remaining amount * (VSOE of v1.0 / VSOE of remaining elements) = 1240 * [1200 / (1200 + 288)] = $1000.

The VSOE of PCS thus comes out to be (1640 - 400 - 1000) = $240 and you have to recognize this over a period of one year starting 11/09/2006.

Having computed the VSOE-based fair value of the elements, maintain the condition records for the element using transaction VK11, so that the system can use them during pricing (Figure 4).

Figure 4

Pricing condition records of elements

It is also important to assign the correct set of accounts using transaction VKOA. You use these accounts during invoicing of the contract. In Figure 5, you can see the first G/L account is the revenue account and the second G/L account is the deferred revenue account. At the time of invoicing, the net amount needs to be booked under deferred revenue (liability account). Later on, revenue recognition is carried out to make contra entries — credit entries for the same amount as debit entries — to the deferred revenue account. It is during this revenue recognition process that the amount is booked to the revenue account as well, which I’ll discuss further in the next section.

Figure 5

Account assignment

Carry Out Revenue Recognition

You’ve taken care of your master data and configuration requirements through multiple-element product creation and VSOE-based fair price condition records maintenance in the SAP system. The only task remaining is to record the transaction in the system and start with the revenue recognition process.

Create a contract using transaction VA41. Use document type WV, which is a standard document type. The process is similar to the creation of a sales order, with the difference being that you can conduct revenue recognition by using contracts. In this example, that includes the contract for the initial version purchase, the upgrade, and the one-year customer support as well.

Maintain the start date and end date of the line items as per the revenue recognition requirements. Figure 6 shows an example of this, with the dates for line items 20, 30, and 40 (containing the elements of the multiple-element product) are in sync with the period over which you need to recognize the revenue.

Figure 6

Create contract

After you save the contract, you can proceed with invoicing. The system posts the amount it calculates during sales document pricing to the deferred revenue account at the time of invoicing (Figure 7). Therefore, it is yet to be recognized as revenue.

Figure 7

Invoice from contract — bookings to deferred revenue account

Use transaction VF44 to carry out the revenue recognition. You can use your own selection criterion to select the documents as applicable for revenue recognition (Figure 8). An example of selection criterion is to run VF44 by company code, sales document type, posting period, and year. I have also used the sales document number to restrict the processing for revenue recognition to only those documents that I created.

Figure 8

Revenue recognition

After the system selects all of the items as per the selection criterion in transaction VF44, you may select all of the items for which you have to carry out the revenue recognition in this fiscal period. Click on the Collective Processing button (Figure 9) to generate the revenue recognition document (Figures 10 and 11). The status in front of the line item automatically changes from yellow to green.

Figure 9

Processing for revenue recognition

Figure 10

Document flow

Figure 11

Revenue recognition document

Revenue is recognized on the basis of number of days in the period for which VF44 is being run and the total period over which the revenue has to be recognized. For example, the PCS contract has a value of $240 and you need to recognize it over a year (365 days). The system ran the revenue recognition for period 2 in 2007, with the fiscal year being defined from October 2006 to September 2007, which has 24 days for revenue recognition perspective. The end date of period 2 in 2007 is 11/04/2006 from the fiscal year definition and the contract line item start date is 11/09/2006. So the revenue recognized for period 2 in 2007 is 24 * 240 / 365 = $15.78.

Akhilesh Mittal

Akhilesh Mittal is a lead SAP consultant at Infosys Technologies Ltd. with eight years of consulting and industry experience. He has experience in FI and CO along with exposure to SD. Akhilesh is currently a consultant in the SAP space for a leading organization in the high technology domain. He has a degree in electronics and communication engineering from IIT Guwahati and an MBA in finance and systems from IIM Lucknow.

You may contact the author at akhileshmittal@yahoo.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.