A Case Study in Results Analysis: Learn What Method Brings the Best Results with the Least Time and Effort by Marco Jordy, Vice President of SAP Finance Consulting, ORBIS America, Inc. Project System

Results analysis, the SAP functionality that calculates revenue and cost of sales of projects, poses a significant task for Project System (PS) implementation teams. Most companies close contracts that are different in nature (e.g., construction vs. service) and size, and therefore call for different calculation methods. SAP's terminology and the implications of other areas of PS, such as the project structure and planning, increase the complexity. This case study of a recent implementation shows examples of effective results analysis methods.

Key Concept

Results analysis functionality supports two key US Generally Accepted Accounting Principles (US GAAP). The revenue principle requires the recognition of revenue as soon as it is realizable and earned. The matching principle demands that you record expenses in the same period as the related revenues (known as cost of sales). Both principles pose significant problems in the construction business, where projects have a long lifetime and are manufactured individually for specific customer orders. On those contracts, the amounts billed to the customer do not have to match the revenue to be recognized, and spending does not usually match the cost of sales.

Note

The values calculated in results analysis are only as good as the data on which the calculation is based. Your plan values, actuals, and PS must be up to date before each run. Using results analysis does not eliminate the task, it merely shifts it from calculating values to reviewing values calculated by the system and makes sure that all base values are updated. The completed contract method is much easier from a controlling and IT perspective. In its most basic form, it needs neither a cost estimate nor a percentage of completion.

The accounting department of any project manufacturer faces the same problems each month when preparing its profit-and-loss statement: How much revenue should it recognize for each project? Which cost of sales (COS) applies to those revenues? Results analysis automates this process. Correctly customized, it calculates the figures for you. It also can calculate reserves for unrealized costs, loss contract reserves, and warranty accruals. Results analysis is available in the R/3 Project System (PS) module as well as on sales orders in the make-to-order process. In PS, use transaction KKA2 (individual processing) to execute results analysis for a single project, or KKAJ (collective processing) to run for a range of projects. How results analysis values are calculated depends upon which results analysis method you apply to the project. There are two basic methods to account for projects: the percentage-of-completion method (POC) and the completed contract method. The POC method allows recognition of revenue throughout a project's life, based on the progress of the project expressed as a percentage. Should the recognized revenues be higher than the billings, a cost-in-excess position is created on the balance sheet. Conversely, when billings are higher than the recognized revenue, a billings-in-excess position must be created. COSs are applied based on the estimated contract costs multiplied by the percentage of completion. COSs that differ from spending result in a work-in-process position on the balance sheet or in reserves for unrealized costs. The completed contract method recognizes revenue only after the project is completed or, in the event that partial performance is contractually agreed upon, when the partial invoices are sent to the customer. COSs are applied based on the estimated profit margin. Under US GAAP, the POC method is the prescribed, preferable method of accounting for the project business. The completed contract method is allowed on short-term projects (projects of less than one year) with low contract values, as well as where reasonably dependable estimates of costs cannot be made. SAP Results Analysis Methods R/3 delivers 15 predefined results analysis methods from which to choose (Table 1). The results analysis key (RA key) that is assigned to the project in the work breakdown structure (WBS) element master data defines the results analysis method used on a project. You can carry out the customizing via transaction OKG3 for each results analysis key using either one of the Simplified Maintenance of Valuation Methods or an Expert mode. After calling transaction OKG3, you are directed to an overview screen, as shown in Figure 1. This screen indicates for each results analysis key whether Simplified Maintenance or Expert mode was used to set up the customizing. Simplified customizing, as shown in Figure 2, offers only limited options to influence the calculation, whereas Expert mode (see Figure 3) offers you a wide range of options, but is complicated and confusing. Wherever possible, stick with the SAP-standard methods and use the simplified customizing. MethodDescriptionBase method

01Revenue-based method with profit realizationCompleted contract

02Revenue-based method without profit realization if actual revenue < plan costsCompleted contract

03Cost-based POC methodPOC

04Quantity-based methodCompleted contract

05Quantity-based POC methodPOC

06POC method on basis of revenue planned by periodPOC

07POC method on basis of project progress value determinationPOC

08Derive cost of sales from "old" resource-related billing of CO line itemsCompleted contract

09Completed contract methodCompleted contract

10Inventory determination without planned costs, without milestone billingCompleted contract

11Inventory determination without planned costs, with milestone billingCompleted contract

12Inventory determination, reserve for follow-up costs, without milestone billingCompleted contract

13Inventory determination "work in process at actual costs" for objects not carrying revenueCompleted contract

14Derive cost of sales from resource-related billing of dynamic itemsCompleted contract

15Derive revenue from resource-related billing and simulation of dynamic items POC

Table 1 Standard SAP results analysis methods

Figure 1 Transaction OKG3 shows which mode was used to set up customization

Figure 2 Simplified customizing of valuation methods in OKG3

Figure 3 Customizing valuation methods using Expert mode in OKG3

Results Analysis Versions Use results analysis versions (RA Version) to calculate parallel values for multiple results analysis methods (e.g., completed contract and POC) on the same project. This is especially useful in a rollout of your system to subsidiaries in other countries. Germany is a good example. The German GAAP (known as HGB) does not allow revenue recognition before billing to the customer. Therefore, POC methods are not allowed. In that case, in your global controlling, you might want to use the same results analysis methods for all countries to make results comparable. You can run results analysis for each RA Version and, therefore, store different views of the same project. Integration into Other Modules The values calculated in results analysis affect your financial statements and your management reporting. Running results analysis, however, only stores them in the PS databases. Use transaction CJ88 (individual settlement) or CJ8G (collective settlement) to transfer them to FI, Profit Center Accounting (PCA), and Profitability Analysis (CO-PA). Settlement into FI is executed only when activated in the results analysis version. Be sure Transfer to Financial Accounting is checked, as shown in Figure 4.

Figure 4 Customizing results analysis versions in transaction OKG2

Case Study A global leader in electrical engineering undertook the project used for this case study. The ongoing SAP implementation, which involves all five divisions of the company, started with a six-month design phase followed by a first implementation phase that set live the R/3 finance modules for all divisions, as well as the logistic modules (Materials Management [MM], Sales and Distribution [SD], PS) for the first two divisions. I will focus on one of these divisions, a software company developing monitoring software for electrical equipment. The implementation phase lasted another six months before go-live and was followed by a three-month support phase. The PS team consisted of five project group members (a project manager, a project accountant, a project controller, one person responsible for master data management, and one person from IT) plus myself as the external consultant. PS was used primarily as an accounting tool. Logistical functions (e.g., networks) had not been implemented. The set-up and testing of results analysis, especially the selection of appropriate results analysis methods for the different project types, was one of the major tasks. Two project types were established: Operational projects: POC, completed contract, time and material, and straight-line accrual (projects recognizing the same amount of revenue each month, such as service contracts) Non-operational projects: proposal management, warranty, development, internal, balance sheet holding, marketing, and capital equipment Only the operational projects and balance sheet holding projects participate in results analysis. All others do not, since they do not generate revenues and their costs are recognized within the month they are incurred. The following is an overview of the valuation methods used in our implementation, including descriptions of simplified and expert customizing settings. Tip!

This customer has chosen to monitor the proposal, operational, and warranty phases as separate projects. Some customers integrate all three phases within one project structure. Doing so requires separating these three phases within the WBS element structure, since only the operational part should participate in the results analysis calculation. Proposal and warranty phases usually recognize costs in the month they occur and do not carry revenues. Therefore, they do not need to do a results analysis calculation. Nevertheless, I recommend that you set up a results analysis key that recognizes all costs as COS and, therefore, does not calculate any work-in-progress (WIP) or accruals. This 100 percent COS results analysis key should be assigned to the top element of the proposal and the warranty section of the project, whereas the operational substructure should carry the "real" results analysis key on its top element. Using a 100 percent COS key has benefits in reporting: Standard reports (e.g., project results by cost element) rely either on results analysis values or non-results analysis values, but rarely combine them. By including the proposal and warranty phase in results analysis, you will be able to state their costs in all reports and therefore have a complete cost view available for the project.

POC Projects The customer wanted to use the POC method for all fixed-price contracts involving customer-specific software development. POC projects require an up-to-date estimate of revenues and costs, since those values form the basis for revenue recognition and COS calculation. How much of those estimated revenues and costs should be recognized as actuals is based on the progress of the project, which is expressed as a percentage. This percentage is known as percentage of completion and gives the calculation method its name. Two approaches are permitted to measure progress on a contract: the input and output methods. Input measures are made in terms of effort devoted to a contract (cost-to-cost method). Output measures are made in terms of results achieved (units produced, contract milestones, etc.). My customer wanted to base the calculation on the cost-to-cost method. In that method the percentage of completion is calculated as spending (actual costs) divided by estimated total costs. Recognized revenue is based on the contract value multiplied by the percentage of completion. In this method, all costs are automatically COS, since they are the basis for POC calculation. These requirements were met in full by SAP standard results analysis method 03 Cost-based POC method. Completed Contract Projects This method is used for fixed-price contracts involving customer-specific software development. Classification of a project as POC or as completed contract is at managerial discretion. Projects with lifetimes under one year, comparatively low project values, and partial invoicing usually qualify for a valuation as completed contracts. Such projects are not completed contract projects in a strict sense, where the revenue is only recognized with a single invoice after completion of the project. Instead, partial invoicing via a billing plan might be agreed upon with the customer. Each time a partial invoice is sent to the customer, the invoice amount should be recognized as revenue and the applicable costs should be computed as COS. This method requires correct cost and revenue estimation. The percentage of completion is calculated by dividing the actual revenue by the total contract value. COSs are computed using the percentage of completion and multiplying it by the total estimated costs. The SAP-standard results analysis method matching these requirements is 01 Revenue-based method with profit realization. Do not use results analysis method 09 Completed-contract method to recognize revenues of partial invoices. Method 09 converts all revenues into a results reserve and all costs into work in process (WIP) until system technically complete status (TECO) is set on the project to indicate that the project is completed.

Figure 5 Customizing valuation method for completed contract projects in OKG3

Figure 5 shows that the customizing settings we used for completed contract projects. Results analysis method 01 Revenue-Based Method With Profit Realization was chosen from the selection list. All other values were kept as proposed by the SAP system for new entries in this customizing setting, except for the Status control. The status set on the WBS element that carries the RA key influences the results analysis. Three controls are available: Results analysis with status. The status indicated in this field is used to carry out regular results analysis with the method indicated in field Results analysis method. SAP proposes status REL Released, which can be changed in expert mode customizing only. Cancel inventory w/status. The status indicated in this field triggers the system to clear out all inventory values (e.g., WIP). Even though inventory values are zeroed out, reserves for unrealized costs are still calculated as defined in the results analysis method. Not all results analysis methods need entries in this field, but in the case of results analysis method 01 Revenue-based method with profit realization, I recommend it. For this results analysis, it makes sense to clear out WIP, in case you sent the customer the final invoice. In that case, you do not expect any additional revenue. Therefore, total spending should be shown as COS, and WIP should be zeroed out. That's why I recommend maintaining status ENFA in field Cancel inventory w/status. Usually, after the final invoice is sent to the customer, your actual revenues should equal your plan revenues, leading to a percentage of completion of 100 percent, and a WIP of zero. A POC of 100 percent will never generate WIP, since the planned costs are either higher than actual costs (which leads to accruals for unrealized costs), or the actual costs are higher than the plan costs (in which case the actual costs override the plan costs as the valuation basis and, therefore, is shown completely as COS). Still, it is advisable to set status ENFA, since plan revenue does not always equal actual revenue. This can be due to changes of conditions in the invoice that are not reflected in the sales order (which generated the plan revenue) or to exchange rate differences. Cancel inventory/reserves w/status. This status causes the system to clear out any WIP, reserves for unrealized costs, and loss contract positions. When creating a new entry in this customizing setting, SAP uses TECO as the status. This standard functionality should be retained. Each WBS element, as well as the project definition, has its own set of statuses. For results analysis, only the status maintained on the WBS element that carries the results analysis key is taken into account. Maintain this status carefully. Usually, an accountant or controller has better judgment on this status than a project manager. Tip!

Results analysis may be carried out at total or line-ID level (compare Figure 3). Calculating on total level aggregates all costs for the calculation, whereas line-ID level calculates COS, WIP, and reserves by line ID. Line IDs are defined in customizing and include multiple expense accounts. Valuation on line ID might lead to simultaneous calculation of WIP and reserves for unrealized costs on the same project. In my experience, under US GAAP, most auditors prefer either to have WIP or reserves for unrealized costs on a project, but not both. Therefore, valuation on the total level is recommended.

Time and Material Projects Time and material projects are characterized by a contractual agreement stipulating invoicing to be based on actual hours worked by the software developers and project managers. Additional expenses, such as travel or materials, are also rebilled to the customer directly. Invoicing to the customer may occur in any form (e.g., monthly, on a time lag, or at the end of the project). SAP offers a functionality called resource-related billing in its SD module. This functionality tracks all cost items on a project and is able to determine a sales price for them. Based on the determined sales prices of all cost items, a debit request is created, which is the basis of the customer invoice. My customer used this functionality for all time and material projects. The SD functionality has a seamless integration into results analysis. Using results analysis method 14 Derive cost of sales from resource-related billing of dynamic items, all expense items already billed to the customer show as COS, whereas all items not yet billed show as WIP. This results analysis method is fundamentally different from other methods that we have discussed. Even the screens shown in transaction KKA2 (results analysis individual processing) are different from the ones shown in other results analysis methods (compare previous slides with Figure 6).

Figure 6 Results analysis in KKA2 for time and material projects

All expense items are analyzed separately, whereas all other methods are based on an aggregation of costs per line ID. For an expense item, the dynamic item processor knows if the item was billed to the customer, and the expense will be classified as COS or WIP, accordingly. Results analysis method 15 Derive revenue from resource-related billing and simulation of dynamic items can also be used in connection with resource-related billing. It differs from results analysis method 14 by recognizing the revenue each unbilled cost item realizes when billed to the customer, eliminating the need for putting the expenses of those items into WIP. Straight-Line Accrual Projects My client offers extended warranty and product maintenance contracts to its customers. The periods of those contracts, as well as the payment options (up front, in installments, or at the end of warranty phase) vary widely. Expenses on these contracts can be estimated using previous contracts. The estimates, however, are much less reliable than those for other project types. For these contracts, my client recognizes revenue in equal amounts over the lifetime of the warranty agreement (hence straight-line accrual projects). COS should be applied based on the estimated profit percentage multiplied by the recognized revenue. We chose results analysis method 06 POC method on basis of revenue planned by period for these projects. This results analysis method recognizes revenue based on the planned revenue in each period. All revenue amounts planned in periods up to the period the results analysis runs in are summarized and recognized. Usually, the plan revenue is determined automatically by the system through automatic transfer of revenues planned in the SD order. Since the billing schedule in SD does not usually match the revenue you would like to recognize, we switched off the automatic transfer in the planning profile (compare Figure 7). Instead, planned revenue, just like planned costs, is entered manually in transaction CJR2 (planning cost element / activity inputs).

Figure 7 Deselecting automatic plan revenue transfer in customizing function Specify Revenue Plan Update from Sales Document

SAP also offers a function in SD called revenue recognition, which allows revenue accrual based on a revenue schedule in SD. This functionality serves the same purpose as results analysis method 06. On straight-line accrual projects, you have the choice to use one or the other. If you need to run results analysis anyway, due to projects that require different results analysis methods, I advise you to stick with this function for straight-line projects. If not, revenue recognition in SD is a good option. Other customers opted to show expenses as COS as they occur, since they were unable to estimate the costs at all. To realize this, you still base your results analysis method on standard method 06 POC method on basis of revenue planned by period, but you have to make changes to the predefined method in expert mode. The easiest way to indicate to the system not to generate any WIP or reserves for unrealized costs is to enter a minimum amount of USD 999,999,999,999 for both key figures. Balance Sheet Holding Projects My customer is a subsidiary of a large international conglomerate. Some internal development projects, as well as joint marketing expenses, will be sponsored by the parent company. On those projects, all expenses should be turned into balance sheet positions until rebilled. Rebilling is done via a financials invoice using expense accounts. Expense amounts that cannot be rebilled to the parent are reposted manually to the appropriate cost centers. Results analysis method 13 Inventory determination "Work in process at actual costs" for objects not carrying revenue was a perfect fit for those projects. This method calculates WIP equal to the accumulated expenses, as long as project status REL Released is set. As soon as the project gets TECO status, all existing WIP amounts are canceled. Tip!

To get consultants and project group members to speak the same language, start a reference list of results analysis terms used in SAP and at your company. It will save you time and will come in handy for training accountants, controllers, and project managers.

Lessons Learned This project provides two lessons that will help you with your own efforts: 1. Do not underestimate the amount of time you can spend on the definition, customizing, and testing of the results analysis methods used. Even though all of these methods are recognized standards under US GAAP, results analysis calculation in R/3 may generate slightly different results than your old system did on the same project with the same base data. 2. SAP terminology used in the results analysis methods can cause confusion. As the consultant, I spoke SAP lingo, whereas all other project group members used the terms historically used at that company and generally accepted in the US. This raised the issue of which terminology should be used after SAP went live. SAP, as a standard ERP system, shows its terms in the results analysis screen, which cannot be changed without modifying the system. The same is true for standard PS reports. Since the project group members were the ones basically responsible for period-end closing (including results analysis) and, except for a limited number of controllers and accountants, everyone used reports specifically designed for the company, we decided to keep it to the existing (non-SAP) terminology and leave the super users to bridge the gap.