The inspection and testing of internal controls required by Section 404 of the Sarbanes-Oxley Act of 2002 involves vigorous reviews of extensive audit trails. It also means logging changes to records of critical business data to detect any errors or fraud that could result in material misstatement of the financial information.

With Sarbanes-Oxley compliance as a pressing concern, many companies are left without sufficient time to plan implementation and testing, let alone to identify new or untested suites of comprehensive testing tools. One testing tool that's readily avail-able and can be easily leveraged, however, is the extensive body of change documents already found in R/3.

Change documents are R/3 documents that detail changes to master records, tables, documents, and so on, when certain conditions are met. R/3 automatically logs who made what changes to business data objects in these change documents. I'll cover standard change document reports, how to retrieve change document information from areas not covered by the standard reports, and the change document programs included in R/3 that I've found most useful.

Change Document Reports for Specific Areas

R/3 comes with a few standard change document reports for specific areas. They are:

• RFBABL00 (display of changed documents — accounting documents)
• RFDABL00 (display changes to customers)
• RFKABL00 (display changes to vendors)
• RFSABL00 (display changes to G/L accounts)
• RFDKLIAB (display changes to credit management)

All five reports are collected in the online information system of each respective R/3 module. For example, RFBABL00 (Figure 1) and RFDABL00 are part of the general ledger (G/L) information system; RFDKLIAB is part of information system for credit management.

Figure 1

Viewing RFBABL00, a standard change document

Preventive Control of Changes for Specific Areas

In addition to these change document reports for tracking changes, R/3 provides preventative controls in its configuration to govern the scope of the changes. For example, you can define document change rules to limit the change scope for both general and subledgers (using transaction OB32). The scope determines whether a field is modifiable and, if so, under what conditions (for example, if the period is not closed).

With R/3 version 4.5, SAP released a new functionality called dual control of sensitive master data, for both the customer and vendor masters. This, like document change rule, represents another upstream preventative control for tracking changes. To put it briefly, it allows you to define a number of critical fields on customer or vendor master data, and requires all changes to these critical fields to be confirmed by another person. Failure to confirm the change could cause the payment to be blocked for the changed vendor. It will not, however, stop incoming payments from the changed customer. Taking advantage of this functionality can help tighten the control of the master data maintenance area. For more information on dual control functionality, see the article, "Monitor Sensitive Fields with R/3's Dual Control Functionality," by Drs. Stef Cornelissen.

At this point, you are probably thinking that the Section 404 testing scope is so comprehensive that the data offered by these five reports amounts to a mere drop in the ocean. This is very true. For this reason, you need to look deeper into the change records tables. This way, if necessary in the course of testing, you can dig into the database tables directly to extract the change history data you need.

For example, Sarbanes-Oxley testing often requires verification of controls in place for upstream logistics processes. A sales order, for example, affects booking figure and billing information, which affect revenue and A/R. Even if you lack tailor-made reports for these applications, you still have the option to retrieve the data from change document tables.

Change Document Tables

Business data objects are changed frequently. The R/3 system logs changes to business data objects in change documents. During Sarbanes-Oxley testing, you will find it necessary to be able to trace or reconstruct such changes later for investigating or auditing purposes.

A change document object captures changes to fields within a given transaction and writes this information to a unique record. The record is date-and time-stamped and maintains the old and new values for each of the fields that have been changed, as well as the user ID of the person who made the change. You can execute a report to query and display the audit trail record. R/3 categorizes different types of changes under different change object classes. These object classes may be active in R/3 or may require configuration for activation. Object classes are required to execute an effective search in change document tables.

Prior to Release 4.6B, you could access change object class and additional programs via transaction SCD0 (change document tool). However, SCD0 was only a test transaction for SAP development class TZD prior to R/3 Release 4.6B. Since 4.6B, it is considered a home development class only and is no longer released to R/3 customers. For details, see SAP note 830551.

You can still access the change document object class and its maintenance tools via transaction SCDO, or table TCDOB for the content of object class and TCDOBT for the text name of object class. Change object class table TCDOB stores the change object classes that track changes for different R/3 business object tables. If you are unsure of which change document object class is used for a given type of change, you can search the change object class tables TCDOB by entering the R/3 tables containing the data on which you need change records.

For example, you can find BELEG is the change object class for accounting document (using table BKPF, etc.), DEBI for customer master (using KNA1 and related tables, shown in Figure 2), KRED for vendor master (using LFA1 and related tables), KLIM for credit master (using KNKK and related tables), VERKBELEG for sales document (using VBAK and related tables). A special function module for each change document object class (for example, DEBI_WRITE_DOCUMENT, or VERKBELEG_WRITE_DOCUMENT) is called in the corresponding application program and logs the changes at runtime.

Figure 2

TCDOB change object class and its content (e.g., coverage of tables) for DEBI (customer)

Additionally, logging only takes place if the fields in which contents were changed refer to data elements that are flagged as relevant for the change document. The changes are then logged into tables CDHDR (change document header) and CDPOS (change document items). These two tables key for retrieval of the change documents.

Examples of Sarbanes-Oxley Testing

Sarbanes-Oxley compliance testing often requires evidence of a specific activity that is related to distinct business objects. For example, if you are assigned to extract all sales orders that were credit released or blocked manually from year 2003 to the current date, you can go about performing this data mining the following way. Before you begin, you need to know that the change document class for sales order is VERKBELEG (as I mentioned earlier) and that transaction code to release/block sales orders manually is VKM1. Auditors can obtain the transaction codes for the key business activities in R/3 from the business users whose activities they are auditing.

Step 1. Browse table CDHDR. Use transaction SE16 to browse table CDHDR, as shown in Figure 3.

Figure 3

Selection screen of CDHDR to retrieve sales orders that were credit released/blocked

Step 2. Enter the criteria for the document you need. Input the change document class VERKBELEG, transaction VKM1, and the desired time range. Figure 4 shows the output screen for CDHDR. As you can see, only the change document header data, in this case, tells you by whom and when the credit release/block transaction VKM1 was executed on which sales orders.

Figure 4

Output screen of CDHDR to retrieve sales orders (object value) that were credit released/blocked

In another example, the task is to find out who changed the credit master of any customer and what the changes were from 2003 to the current date. First, you need to know that the change object class for credit master is KLIM and the transaction to change the credit limit is FD32.

Step 1. Find the credit master records. Go to data browser SE16 to search change document header CDHDR. See Figure 5 for the screen.

Figure 5

Selection screen of CDHDR to retrieve credit master charges

Step 2. Find what specific fields and values were changed on the credit masters. Browse the change document line item table CDPOS with the change document number (circled in Figure 6). You may also search using other specific fields and values. For a second example, see Figures 10 and 11 as downloads attached at the bottom of this article. You will be glad to find that you can have all the data and records you've ever wanted!

Figure 6

Output screen of CDHDR to retrieve credit master (object value) changes

Generic Change Document Report

Lastly, SAP released a set of change document programs under the package SZD. Using transaction SE80 (object navigator) you find 38 programs developed around change document tools. However, the functionalities of some of these 38 programs seem redundant. Report RSSCD100 (display change documents), in particular, is quite useful and functions similarly to the search processes shown above. Figures 7, 8, and 9 show an example in which all changes against customer 300719 were retrieved.

Figure 7

Selection screen of change document report for object class DEBI

Figure 8

First part of the output screen of change document report for object class DEBI

Figure 9

Second part of output screen: change document report for object class DEBI