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.

Method Description Base method

01 Revenue-based method with profit realization Completed contract
02 Revenue-based method without profit realization if actual revenue < plan costs Completed contract
03 Cost-based POC method POC
04 Quantity-based method Completed contract
05 Quantity-based POC method POC
06 POC method on basis of revenue planned by period POC
07 POC method on basis of project progress value determination POC
08 Derive cost of sales from "old" resource-related billing of CO line items Completed contract
09 Completed contract method Completed contract
10 Inventory determination without planned costs, without milestone billing Completed contract
11 Inventory determination without planned costs, with milestone billing Completed contract
12 Inventory determination, reserve for follow-up costs, without milestone billing Completed contract
13 Inventory determination "work in process at actual costs" for objects not Completed contract
carrying revenue
14 Derive cost of sales from resource-related billing of dynamic items Completed contract
15 Derive 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).

Deselecting automatic plan revenue transfer in customizing function Specify Revenue Plan Update
Figure 7
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.