Chapter 10: Account Assignment and Revenue Recognition
After a billing document is saved, it is released to accounting, where it updates the various general ledger accounts. In this chapter, we will study how to configure SAP to determine the accounts and post the billing document automatically. Further, based on the requirements of the finance team, various pricing elements such as discounts, taxes, and price can be posted to different accounts. In this chapter, we will cover how to control the determination of various accounts.
Some organizations require that billing the customers and updating the revenue books should happen at different points in time. The revenue recognition functionality separates billing from revenue and lets you control when to recognize revenue using a separate transaction. In this chapter, we will explain the fundamental scenarios for revenue recognition.
Account determination is the procedure used to establish the correct G/L accounts for posting a billing document to accounting. Using this procedure, SAP carries out account determination for billing documents such as invoices, credit notes, debit notes, and so on. Revenue account determination provides the G/L account for revenue, discounts, surcharges, and taxes.
Account assignment uses the condition technique to determine general ledger accounts. The account determination procedure is a schema that consists of elements called condition types. An access sequence is assigned to each condition type. Following the sequence, the system searches for G/L accounts maintained in condition tables in a specific order. The condition record is the account number set up for a combination of determination criteria. The following sections describe the major steps you will use to configure account assignment.
Set Up Account Assignment
We will show the step-by-step procedure you can use to build an account determination procedure and assign the G/L accounts. Before we show you how to build the procedure, we’ll discuss some master data elements that influence account determination.
Material Account Assignment Group
The material account assignment group is used to distinguish accounts based on different materials. For example, the requirement may be to separate the revenue from the sale of finished goods from the revenue of services. You can create account groups and assign them in each material master record. You can then use this field as a key to point to different accounts.
To maintain the values in this field, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Check Master Data Relevant For Account Assignment Materials: Account Assignment Group. As shown in Figure 10-1, you can check the list of predefined account assignment groups or define a new entry by specifying a two-character alphanumeric identifier and description. In the material master, this field appears on the Sales Org 2 tab.
Figure 10-1: Material account assignment group
Customer Account Assignment Group
Use the customer account assignment group to distinguish accounts based on groups of customers. For example, one of the common requirements is to segregate revenues of domestic customers from those of foreign customers. You can create account groups and assign them in the customer master record. You can then use this field as a key to point to different accounts.
To maintain the values in this field, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Check Master Data Relevant For Account Assignment Customers: Account Assignment Group (OVK8).
As before, you can check the list of predefined account assignment groups or define a new entry, as shown in Figure 10-2. In the customer master, this field appears on the Sales Data tab.
Now let’s set up the account determination procedure following the condition technique. The following sections explain the step-by-step procedure.
Figure 10-2: Customer account assignment group
Step 1: Create Condition Tables
Condition tables specify the key combinations required for account determination. Before setting up new condition tables, check the standard tables provided by SAP.
If you have to set up a custom table, refer to the field catalog, and search for the fields you require to be part of your condition table.
The menu path is IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define Dependencies Of Revenue Account Determination Field Catalog: Allowed Fields For The Tables.
You can check the fields available in the standard field catalog. If this list does not meet your requirements, you can use function key F4 to access the full list of fields in the catalog (refer to Figure 10-3). Note that, unlike with pricing, there is a very limited set of fields to choose from.
Once you have checked the availability of required fields, pick up these fields, and create a condition table. For this step, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define Dependencies Of Revenue Account Determination Account Determination: Create Tables (transaction code V/12).
As shown in Figure 10-4, table 001 has a key consisting of the sales organization, customer and material account assignment groups, and account key.
We covered the steps to create a condition table in Chapter 4, “Partner, Text, and Output Determination,” when we discussed output determination. Please refer to that discussion for the exact steps.
Figure 10-3: Field catalog for account assignment
Figure 10-4: Defining a condition table
Step 2: Define an Access Sequence
To define an access sequence for the pricing determination, the path is as follows: IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define Access Sequence And Account Determination Types Maintain Access Sequence For Account Determination.
On the Change View: Access Sequences: Overview screen, create a new access sequence using the New Entries button. We covered the steps to create an access sequence in Chapter 4 when we covered output determination. Please refer to that discussion for the exact steps.
As shown in Figure 10-5, the access sequence KOFI has five accesses arranged in a specific sequence. The condition tables defined (or identified) in the previous step are used in the access sequence. There is a provision to attach a requirement routine to steps in the access sequence. In the case of KOFI, requirement routine 3 checks that the CO account assignment is not active. If this condition is fulfilled, it carries out the access; otherwise, it skips the step. This initial check helps improve the performance of the access sequence and prevents unnecessary steps.
Figure 10-5: Defining an access sequence
Step 3: Maintain Account Determination Types and Assign the Access Sequence
Account determination types are the condition types that you will use in the account determination procedure.
To set up condition types, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define Access Sequence And Account Determination Types Define Account Determination Types.
In this transaction, you can define a condition type. There are no other controlling parameters to be maintained here (unlike pricing condition types that required configuration using V/06, which we discussed in Chapter 5, “Pricing and Tax Determination”). You can assign the access sequence to the condition types here.
Standard SAP offers two account determination types: KOFI (standard account determination) and KOFK (account determination with costing). The access sequence KOFI (covered in step 2) is assigned to both conditions (Figure 10-6).
Figure 10-6: Defining account determination types and assigning the access sequence
Step 4: Set Up the Account Determination Procedure
The account determination procedure contains the list of condition types defined in the previous step.
To set up an account determination procedure, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define And Assign Account Determination Procedure Define Account Determination Procedure.
The Account Determination procedure has condition types linked together in a schema. Standard SAP offers the procedure KOFI00, which consists of two condition types, KOFI and KOFK, as shown in Figure 10-7.
Figure 10-7: Account determination procedure KOFI00
Step 5: Assign the Account Determination Procedure
In this step, you assign the account determination procedure to a billing document.
To assign the account determination procedure, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define And Assign Account Determination Procedure Assign Account Determination Procedure.
Select the billing document. Attach the appropriate account determination procedure to it, as shown in Figure 10-8. This setting ensures that when billing document F2 is created, the account determination will be done following the procedure KOFI00. Similarly, assign a procedure to all other billing documents (such as credit and debit memos) that you use. The CaAc column here enables you to specify a cash allocation key. With this, the system posts to a general ledger account for cash rather than to a receivables account.
Figure 10-8: Assigning an account determination procedure to the billing document
Step 6: Define and Assign an Account Key
Account keys are used to group together similar accounts in financial accounting. You can also use an account key to point to a specific account number in account determination. For example, the account key ERL is used to point to a revenue account. In the pricing procedure, you will assign this key to the pricing conditions related to the product price.
The path in SAP to define and assign account keys is as follows: IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define And Assign Account Keys Define Account Keys.
Refer to Figure 10-9, where you will see the standard account keys offered by SAP, such as ERL (Revenue), ERF (Freight), and ERS (Discounts). You can add a new account key by specifying a three-character identifier.
Figure 10-9: Defining an account assignment key
The next task is to assign the account key. Follow the menu path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Define And Assign Account Keys Assign Account Keys.
Refer to the pricing procedure that you are using. The table lists all the pricing condition types used in the procedure, as shown in Figure 10-10. You can specify an account key for each condition type.
Figure 10-10: Assigning the account assignment key
Another way to assign an account key is when you define a pricing procedure (using transaction V/08). Refer to Chapter 5 (specifically Figure 5-13), where the account key is specified in the AccK column.
Step 7: Assign G/L Accounts
In the final step, specify the actual account numbers for each combination key. Follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Account Determination Assign G/L Accounts.
You now should see a screen like that shown in Figure 10-11. That displays all the condition tables with key combinations.
Figure 10-11: Assign G/L Accounts overview screen, with tables to choose from
Select the table for which you want to maintain the account numbers and set up condition records. For example, select table 1 (customer group, material group, and account key), and go to the details screen (Figure 10-12) where you can set up condition records, specifying a G/L account for the key combination.
Figure 10-12: Assign G/L Accounts details screen to set up condition records
In Chapter 9, “Billing,” during the discussion of the rebates and payment card interface, we used account assignment and specified G/L accounts but deferred the discussion of detailed configuration to this chapter. Note that you can also follow the previous steps 1–7 in rebates and in payment card setup to control the determination of accounts.
CASE STUDY—Galaxy Musical Instruments: Account Determination Setup
Galaxy Musical Instruments has set up pricing procedure ZGALAX (discussed in Chapter 5). Now, Galaxy is designing an account determination procedure that goes hand in hand with this pricing procedure. The requirement is that when a billing document is posted to accounting, the different pricing elements in the pricing procedure—such as discounts and freight—must be posted to separate G/L accounts.
The standard account determination procedure offered by SAP (KOFI00) meets Galaxy’s requirement. It consists of two conditions, KOFI and KOFK. Galaxy will use KOFI for account determination. The access sequence attached to it is also named KOFI (shown earlier in Figure 10-5). It consists of five condition tables, from specific to generic.
The account assignment keys were previously assigned in the pricing procedure ZGALAX. The customer and material account assignment keys are also maintained in the respective master data records.
To specify account assignment for Galaxy Musical Instruments, take the example of table 1. As shown in Figure 10-12, it has a key composed of the following fields:
- Application (V for sales and distribution)
- Condition Type (KOFI)
- Chart of Accounts (INT is used by Galaxy Musical Instruments)
- Sales Organization (9090 is used by Galaxy Musical Instruments US)
- Customer Account Assignment Group
- Material Account Assignment Group
- Account Key
Galaxy Musical has specified G/L accounts for each combination of customer account assignment group, material account assignment group, and account key, such as ERL, ERF, and so on. Thus, the amounts in all the revenue conditions (such as condition PR00, with account key ERL) will be posted to G/L account 800010. Discount conditions that use account key ERS (like ZGM1 and HI01) would be directed to 221000, and so on.
Whenever a billing document is saved, you can use account determination analysis to understand which G/L accounts have been picked up and which key was used to fetch the records. To access the analysis, use the transaction VF02 or VF03, specify the billing document number and follow the menu path Environment Account Determination Analysis Revenue Accounts. Figure 10-13 shows an example from a typical billing document (Z2) for Galaxy Musical Instruments. The analysis confirms that the PR00 amount has been posted to account 800010. If there is an error in account determination, the analysis report is very helpful in finding which records are missing or could not be determined.
Figure 10-13: Account determination analysis
SAP’s revenue recognition functionality enables you to post the billing documents and recognize revenue at different points in time. In the regular process, SAP recognizes revenue as soon as the billing document is posted to accounting. The receivables account (customer account) and the revenue account are posted with this transaction. However, certain business scenarios require revenue to be recognized either before or after the invoice has been created. The revenue recognition function provides a separate transaction (VF44) to trigger the recognition of revenue. Here, two additional G/L accounts come into play: the deferred revenue and unbilled receivables accounts. If you bill the customer first and recognize revenue at a later point, the amount is classified as deferred revenue in the interim. On the other hand, if the business requires you to recognize revenue periodically but bill the customer later, then the amount is kept in the unbilled receivables account.
Suppose you have to bill the customer first and recognize revenue later. Here’s what will happen:
1. The billing document is posted: The receivables account and the deferred revenue account are updated. Thus, you are billing the customer but not realizing the revenue yet.
2. The revenue recognition is posted: This offsets the deferred revenue account with the revenue account. The revenue recognition is thus completed.
Revenue Recognition Process
The revenue recognition process has several variations. To discuss the process flow, we’ll present a simple example. Suppose a customer has purchased a one-year warranty from Galaxy for a specific musical instrument. The customer has to be billed up front, but the revenue has to be recognized on a monthly basis over the life of the contract. This is an example of time-based revenue recognition with up-front billing.
In this example, you’d set up a service contract in SAP specifying the start and end dates. (For details on contract creation, refer to Chapter 7, “Sales.”) You would also create a billing document with reference to the contract using VF01.
When it comes to revenue recognition, the system uses the contract start and end dates to create equal “buckets” in which the revenue will be recognized. If the customer is billed for $1,200, the revenue recognized per period will be $100 each, for 12 months.
The transaction that triggers the revenue recognition is VF44. You can access it from SAP Menu Logistics Sales And Distribution Billing Revenue Recognition Edit Revenue List.
Figure 10-14 shows the selection screen of VF44. In this case, we have specified the contract document number and the posting period as the entire life of the contract.
The details are displayed, as seen in Figure 10-15. The Revenues data is displayed in the upper window, and the Control Lines data appears in the lower one. The Control Lines record contains information such as the total value of the contract. The Recog. Rev. field shows the total revenue recognized until date. Unrec. Rev. is the balance, which is an unrecognized component. In this case, the customer has been invoiced for $1,200. The revenue has been deferred; hence, the unrecognized revenue is $1,200.
Figure 10-14: Revenue recognition, post revenue selection screen
Figure 10-15: Revenue recognition work list
The Revenues list shows the revenue amounts that would be recognized in the selected posting period. Since in this example we are checking data for the entire life of the contract, we can see 12 revenue buckets spread over the posting periods. The Year/Per. field shows the posting period and year. In every period, revenue will be recognized in equal amounts ($100). The corresponding G/L accounts appear in the list.
In this example, suppose at the end of first period, the user selects the first line (for period 2009/001) and clicks Collective Processing. The accounting document is generated, and revenue is recognized to the extent of the amount specified.
Figure 10-16 shows the accounting entries that are made at every step of the process. The amount billed ($1,200) is placed in the deferred revenue account. Each month, a revenue recognition entry is made for $100. It updates the revenue account and offsets the deferred revenue account. This process continues every period until the total revenue has been recognized.
Figure 10-16: Accounting view, deferred revenue scenario
If there is a mistake in recognizing revenue, you can cancel the entry using transaction VF46. Follow the path SAP Menu Logistics Sales And Distribution Billing Revenue Recognition Maintain Cancellation List (transaction code VF46).
You can derive a revenue report using transaction VF45. It lists all the details related to a given sales document. You can check all the revenue documents and cancellation documents that have been posted over a period of time. It is possible to display the accounting documents that have been created. You can access this report using the path SAP Menu Logistics Sales And Distribution Billing Revenue Recognition Revenue Report (transaction code VF45).
This was a simple example of a revenue recognition process. There can be other variations as well. For example, you can use sales orders with billing plans instead of contracts. In this case, the billing plan dates control the revenue postings.
Another variation is when the revenue is to be recognized before the customer is billed. Consider the example of Galaxy’s warranty. A variation could be that the customer is not billed up front but instead billed quarterly, as per a billing plan attached to the contract. The revenue will be recognized in each period. At the end of first period, a revenue of $100 is recognized, but it has not been billed yet. In this case, it updates the Unbilled A/R account. Figure 10-17 shows the accounting entries for this variation of the process.
Figure 10-17: Accounting view, unbilled A/R scenario
Now let’s turn to service-based revenue recognition. In this case, the revenue recognition is triggered by a specific event, such as posting a goods issue. Suppose a customer has placed an order with Galaxy for some musical instruments. As per the delivery schedule, some instruments are to be delivered in the first quarter of the year, and others in the second. The customer will be sent a combined invoice at the end. Whenever a delivery is created and a goods issue is posted, you can trigger the recognition of revenue. This ensures that revenue is recognized in each financial quarter, although the customer is billed at a later point in time.
Set Up Revenue Recognition
Configuring revenue recognition requires close coordination with your finance team and SAP FI/CO expert. Since it is complex functionality, it is not open for configuration, and you have to contact SAP through an OSS message to get it activated. Refer to SAP Service Marketplace OSS note 779366 for the initial activation.
As discussed earlier, the FI/CO experts have to set up G/L accounts to be used for deferred revenue and unbilled receivables. SAP Service Marketplace OSS note 777996 provides detailed guidance on the setup of these accounts.
Once this initial setup is completed, you can proceed with the steps in the following section.
TIP Before you proceed with configuring revenue recognition functionality, please read the SAP Service Marketplace OSS note 1256525. It contains a best-practice document and recommendations from SAP. It also covers the process variations and flow diagrams. Be advised that the content of the document is frequently updated, and new notes are often released. Please search for the latest note number in OSS Search before proceeding.
Set Up Revenue Recognition for Item Categories
Revenue recognition is controlled at the item category level.
To create the settings, follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Recognition Set Revenue Recognition For Item Categories (OVEP).
Select the item category that you plan to activate, and go to the details screen. Figure 10-18 shows this screen with the Business Data tab in it.
Figure 10-18: Maintaining item categories for revenue recognition
Let’s look at the fields in this screen:
Revenue Recognition In this field, specify the type of process you plan to use. In this field, you can specify the revenue recognition category you are using, such as time-based or service-based revenue recognition. Here are the options to choose from:
Time-based revenue recognition (A) Choose this option if your business scenario calls for revenue recognition over a period of time, usually the length of a contract or the duration of a service. The process starts with a contract document (or sales document with a billing plan). In this process, revenue is recognized in equal parts, over the duration of this contract.
Service-based revenue recognition (B) In this scenario, you carry out revenue recognition based on an event, such as rendering a service. The process starts with a contract or a sales order. As soon as a goods issue is posted for the delivery or when there is a confirmation of service, you can run VF44 to recognize revenue. It creates an accounting document that posts to the unbilled revenue account and the revenue account. When the customer is invoiced, another accounting document offsets the unbilled account and impacts the receivables account. There can be other variations of this process, such as invoicing first and then recognizing the deferred revenue later. There can also be contracts with call-off orders. In this case, the call-off order will be delivered and billed.
Time-based and invoice-related revenue recognition (D) In this scenario, the recognition of revenue is done on the basis of an invoice, over a time period. The process is triggered when the invoice is created and posted to accounting. The process is similar to a variation of option A in which the customer is billed first and deferred revenue is recognized later. The major difference is that option A allows you to either bill first or bill later. Option D limits you to billing first.
Credit/debit memo revenue recognition with reference to predecessor (F) Choose this option for credit and debit memos created with reference to documents that used revenue recognition functionality. The revenue recognition category in the preceding document should be either A or B. If the preceding document is A (time based), it is possible to recognize revenue in the credit/debit memo over the same duration of time as the original document. If it is B (service based), it is possible to recognize revenue on the basis of a specific event as in the original document.
Proposed start date for accrual period This field controls the start of the accrual-posting period. There are two options, as shown in Figure 10-19. Choose the appropriate option depending on your business requirements and whether you plan to use contract documents in the process flow.
Figure 10-19: Proposed start date for accrual period
Proposal Based On Contract Start Date The contract start date will be used as the accrual start as well.
Proposal Based On Billing Plan Start Date Use this option when you want to refer to the billing plan rather than contract dates.
Revenue Distribution This field is used to control the distribution of amounts over a certain period. It is used in conjunction with revenue recognition category A (time-based). There are various options to control how the total value and correctional value are divided over the periods, as shown in Figure 10-20. A correctional value can arise if, for example, there is a correction in the pricing of an order or contract, after revenue recognition has already been started. In this case, the correctional value has to be distributed over the remaining periods for which revenue has not been recognized as yet.
Figure 10-20: Revenue distribution type
Using the options, you can specify whether the correctional value is to be divided equally over all posting periods or is to be booked entirely in the first open posting period. Please check on the exact requirements with your FI/CO expert before making these settings.
Revenue Event This field is used only in the case of revenue recognition category B (service-based). You can leave this field blank if revenue is not event related. Choose from the events in the drop-down list. In the case of a third-party business scenario where a vendor directly delivers goods or services to your customer, you can specify that an event such as an incoming invoice (B) should trigger revenue recognition. The customer acceptance date (C) can be another such event. SAP has also provided a business add-in (BADI_SD_REV_REC_PODEV) to define custom events.
Maintain Account Determination
In this section, you will specify the G/L accounts to be used for deferred revenue and unbilled receivables, respectively. Follow the path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Recognition Maintain Account Determination Assign G/L Accounts For Revenue And Deferred Revenue (transaction code VKOA).
You can choose the appropriate table from the list, based on the key combination. In the G/L Account field, specify the revenue account. In the Provision Acc. field, specify the deferred revenue account (Figure 10-21).
The other setting you need to define is for the unbilled receivables account. Follow the menu path IMG Sales And Distribution Basic Functions Account Assignment/Costing Revenue Recognition Maintain Account Determination Assign Accounts For Unbilled Receivables (transaction code OVUR).
Figure 10-21: Assigning accounts for revenue and deferred revenue
For the chart of accounts and reconciliation account, you can specify the unbilled receivables account here (see Figure 10-22).
Figure 10-22: Assigning accounts for unbilled receivables
Item Category Settings
Besides the revenue recognition–related settings mentioned earlier, you may require other settings for an item category if you are going to use billing plans. In the definition of the item category, there are fields where you can specify billing relevance and billing plan type (Figure 10-23).
To define these settings, use the menu path IMG Sales And Distribution Sales Sales Document Item Define Item Categories (transaction code VOV7).
If you want to use a billing plan, set the Billing Relevance field to I. (Figure 10-24 shows the options to choose from.)
Then specify the type of billing plan from the list, as shown in Figure 10-25.
Figure 10-23: Item category settings for billing relevance and billing plan
Figure 10-24: Choosing billing relevance I for billing plan
Figure 10-25: Options for billing plans
CASE STUDY—Galaxy Musical Instruments: Revenue Recognition Setup
Galaxy Musical Instruments offers an extended one-year warranty on musical instruments. The company bills the customer up front for the warranty. The requirement is that the warranty charges are to be placed in a deferred revenue account. They have to be recognized in equal installments over the life of the warranty (12 months).
To map this scenario, Galaxy has chosen time-based revenue recognition (category A) in the settings for the selected item category. The Proposed Start Date field for the accrual period is set to A (proposal based on contract dates). It carries out revenue recognition in equal parts over the life of the contract, referring to the contract start and end dates.
Refer to the discussion in the “Revenue Recognition Process” section of this chapter for the steps in this business scenario.
In this chapter, we discussed a couple of topics that require close integration between SD and FI/CO. We discussed the account assignment process and the steps to set up and control account determination. We also examined the revenue recognition functionality, which allows you to bill the customer and recognize revenue at different points in time.
In Chapter 11, we will discuss the credit management functionality.