One of my clients, a software development company, offers extended warranty and product maintenance contracts for its software. The time frames of the contracts, as well as the payment options for customers, vary widely.

Depending on the contract, customers pay the full order value up front, in intervals, or at the end of the project. Independently of the invoices sent to the customer, my client wanted to recognize the contract revenue in equal amounts for each month within the time frame of the service contract.

Such service contracts recognize revenue in equal amounts over the lifetime of the warranty agreement. Customer payments have to be classified as down payments until the service is provided. The revenue recognition should offset an existing customer down payment. If the revenue recognition overruns the down payment, the remaining amount should be classified as revenue in excess of billings in the inventory section of the balance sheet.

My client wanted the system to carry out all necessary Financials (FI) entries automatically. This included finding the correct balance sheet position for the revenue in excess of billings, which proved challenging. The SAP documentation describes the possibility of finding only one account for revenue in excess, but not multiple accounts, depending upon the existence of a down payment. The project team found a way to set up an additional posting rule in the Project System (PS) customizing setting via transaction OKG8 (define posting rules for settlement to accounting) that solves the problem.

Standard Method — Basic Setup

I will first describe the basic setup of the business process in Sales and Distribution (SD) and billing plan in PS before moving on to describe the solution. You create each warranty contract in the billing plan PS as a separate project. Create an SD order based on the payment steps agreed on with the customer. This usually involves the creation of one or multiple down payment requests and a final invoice. Assign the SD order to the billing element of the project. The results analysis method used is based on SAP standard delivery method 06 (percentage of completion [POC] method on basis of revenue planned by period). This method determines the recognized revenue based on manually planned revenues entered in transaction CJR2 (planning cost element/activity inputs). Switch off the transfer of planned revenues from SD in the planning profile.

Customizing Methodology Overview

To take the down payments into account, you have to change the results analysis method. The changes trigger the system to calculate the difference between the revenue in excess of billings and the down payment amount, which is subsequently stored on a separate Controlling (CO) cost element. In the account determination of billing plan PS results analysis, you are then able to define a posting rule that triggers the system to pick up this calculated amount and generate an FI reclassification posting. This reposting transfers the amount from the inventory to the advance payment section to offset the existing customer down payment.

Let's look at an example. A customer bought a warranty contract covering its software package for a two-year period. Within the time frame of the service contract, the software provider offers free help-desk service, bug fixes, and software updates, as well as on-site service as necessary. The service fee is USD 48,000, payable at beginning of the extended warranty phase. SD invoicing generates a down payment request for USD 48,000. The subsequent customer payment generates an FI posting crediting the customer using the special G/L indicator A, identifying it to the system as a down payment.

The expected revenue of USD 48,000 is entered in revenue planning with USD 2,000 allotted to each month. Therefore, the system recognizes USD 2,000 in revenue at the end of the first month in results analysis. Settlement generates the FI entries, crediting revenue and debiting revenue in excess of billings. In the same posting, the system generates lines crediting revenue in excess of billings and debiting an account in the prepayment section of the balance sheet. Figure 1 illustrates the G/L activity.

Figure 1

Revenue recognition and customer down payments

The system carries out the same postings in each of the following months until the end of the contract lifetime. At that point, SD generates the final invoice, crediting revenue and debiting AR. In addition, SD triggers the down payment clearing, reposting the down payments to AR and clearing them against the final invoice. The next results analysis finds the SD-generated revenue and therefore zeroes out its own revenue-in-excess position, also canceling the reposting to down payments.

This is a straightforward case in which the customer paid the full contract value up front. However, the same setup also covers complex scenarios with partial down payments. The step-by-step guide that follows explains how to implement the customizing necessary for this process.

Customizing Procedure

The following guide gives five main steps for correctly stating the revenue in excess position calculated in billing plan PS on your balance sheet. It describes a hidden customizing setup that allows you to find different balance sheet positions depending on an existing customer prepayment.

Step 1. Make the down payment value known in CO by assigning a cost element. Create a dedicated cost element for customer down payments in CO. Use transaction KA01 (create primary cost element) with cost element category 11 (revenues). Assign the cost element to the controlling area via transaction OKEP (Down Payments: Default Cost Elements) (Figure 2).

Figure 2

Assign the down payment in OKEP (Down Payments: Default Cost Elements)

Step 2. Define a line ID for down payments in customizing. Define a new line ID dedicated for down payments in customizing function Define line ID. You may find the customizing functions via transaction SPRO or by following menu path Project System>Revenue and Earnings>Automatic and Periodic Allocations>Results Analysis>Edit Results Analysis Keys and Version. Then use transaction OKG5 to define assignments for results analysis (Figure 3) to assign the down payment cost element to the new line ID. Don't forget to enter A to indicate a Down Payment as Expense in the field Variable/fixed indicator.

Next, define the update of the line ID in customizing function OKG4, to update the WIP calculation and results analysis. Enter a new entry for the RA key and line ID for Down payment. Enter F for customer down payments for the field category.

Figure 3

Assign cost elements for work in process (WIP) and results analysis in OKG5

Step 3. Customize the results analysis method to take down payments into consideration. Switch to customizing transaction OKG3 to define valuation methods for results analysis (Figure 4). You must switch to Expert mode in the valuation method. For each status, assign G to Down Payments: Reduction Rev. Excess of Billings, DP Surplus in the field Commitments. At this point, the down payment amounts are recognized by the results analysis function.

Figure 4

Customizing results analysis method in OKG3 to include down payments

Step 4. Define and assign the cost element to capture the reclassification amount. Create a secondary cost element, in this example 009R0080024, with cost element category 31 (order/project results analysis) using transaction KA06.

Assign cost element 009R0080024 to the results analysis version using transaction OKG2 (results analysis version) as shown in Figure 5. Enter the cost element in field Reduct Revenue>Billng.

Figure 5

Figure 5 Customize Results Analysis Versions in OKG2

Step 5. Customize account determination for reclassification entry. Switch to transaction OKG8 to post rules in WIP calculation and results analysis. You have to add a posting rule to the ones already in the system. Enter results analysis category RRDP (reduction in revenue excess) and the cost element assigned to the results analysis version in the field Reduct. Revenue>Billng (compare to step 4).

Enter the revenue-in-excess of billings account in the BalSheetAcct column. Enter the number of the account for prepayments in column Pr/LsAcct (Figure 6).

Figure 6

Customizing account determination in OKG8

This prepayment account has to be dedicated for this sole purpose, since the prepayment account used by accounts receivable is a reconciliation account, which cannot be used in the billing plan PS settlement. Therefore, create a subaccount to the prepayment account that is not a reconciliation account and assign it in the balance sheet to the prepayment section.