Those of you who are grappling with Sarbanes–Oxley Act¹ (SOA) compliance have to be asking, “How do we ensure that internal controls are where they are supposed to be within our R/3 system?” Consider these two examples:

Example 1: For several years, one of my clients relied on a series of custom ABAP reports that looped on the pricing conditions contained in billing documents (table KONV). Decisions regarding pricing, discounting, rebates, freight, and postage were formed by the information in these reports. Unfortunately, there was an inconsistency between the logic contained in the reports and the configuration of the pricing procedure. Problems arose when there were duplicate pricing conditions—for example, two or more PR00 prices:

PR00 $1,000

PR00 $0

The logic in the ABAP reports retrieved the first value, in this case $1,000. However, typical SAP pricing configuration takes the “bottom” (i.e., last sequential) condition, in this case $0. As a result, the client analyzed and reported data that was inconsistent with the actual transactions that took place, and the values in accounting.

Example 2: A large multi-national company relied on a custom program to consolidate line items on an invoice printout. However, discrepancies between ABAP logic and pricing configuration caused some invoices to be processed that did not reconcile with accounts receivable. Rather than spend the time and resources to re-bill all the customers at the correct amount—and to avoid an embarrassing admission—the customer wrote off the difference as a loss.

These companies solved their financial reporting problems using controls available in their R/3 system. In both cases, ABAP control code was put in place to verify the consistency between transactional operations and financial reporting. When inconsistencies were found, an audit table was updated with transactional information including the time and the date of the transaction, the transactional amount, the reported amount, and the discrepancy value, and a message was sent by email to the appropriate financial officer. (For more information about controls, see “Controls in Your R/3 System,” below.)

How do you unearth similar risks in your financial infrastructure? In light of SOA’s mandate for an adequate control system for financial reporting, I recommend that companies deconstruct their financial statements, line by line. This involves breaking apart each number on the financial statement to its constituent elements. This is the first step in a series of steps — seven in total — that I recommend you follow to understand the building blocks that make up the numbers on your financial statements and where controls are needed in order to ensure the integrity of your statements. Then you can proceed with confidence in your compliance activities.

Step 1: Trace a financial statement line item back to the processes and procedures used in its creation. Remember that SAP R/3 is your book of record. If you extract transactional information derived in SAP to a financial reporting solution, including BW, you still must map back to the transactions created in R/3. I have come across many compliance initiatives centered on implementing BW or SEM. The perception has been that one of these tools, or an external financial reporting package, would provide the missing link in helping a company comply with Sarbanes–Oxley. These tools can assist by providing consolidated financials and tight controls over data extraction and manipulation, but if the data being extracted is not correct, all bets are off. The first place a company should focus its efforts is on the systems, process, and procedures from which it derives financial numbers.

Step 2: Document the process flows, including significant handoffs of data. It is important to understand the evolution of your financial numbers and the changes they go through before they become a component on a financial statement. Documenting the process flows reveals this path and highlights critical data handoffs—for example, the handoff between revenue numbers from a sales order to a billing document. These handoff points are good places to implement controls to ensure the data being delivered is the same as the data being received.

Step 3: Identify, test, and document existing controls. When examining your financial controls, the key criteria to look for are the moments when the financial data may be changed from what would otherwise be expected during the normal course of business. This change can result from manual or system manipulation. For instance, normal business procedures typically allow authorized users to change prices on a sales order. The inherent and repository controls provided by SAP monitor these changes and produce a sufficient audit record of what takes place. However, a user exit that changes the price during the copy from a sales order to a billing document based on programmable criteria may pose a control risk and should be documented. The documentation helps ensure that as the business changes over time and new customers, materials, or divisions within the company are added, the intended consequences of the user exit are still appropriate and applicable.

Step 4: Identify and document where controls are missing. To supplement the process described in Step 3, some companies are surveying employees. Surveys are randomly distributed throughout a company, asking for employees’ opinions about internal control risks. The survey results can help point technological control initiatives in the right direction. In addition, the surveys may also provide senior management with a means of justifying technological expenditures.

Step 5: Assess the impact of missing controls and perform a risk/reward analysis. Assessing the impact of missing controls is a somewhat subjective procedure—unless the lack of controls is causing a direct and identifiable problem in your financials. However, if your numbers appear to be correct, how do you assess the impact of missing controls? The approach I like to use has two paths.

The first is to start downstream and walk up. Start by identifying missing controls that are closest in the process flow to the financial statement. For example, say you are consolidating all the financials out of R/3 into a spreadsheet. A missing control (such as copy control validation) during this process is closer from a process-flow standpoint to the financials than a missing control during a handoff between quote and order. You could have all the financial controls in place during your process flow, but if you miss the last one, you are at greater risk than if you were missing a control further upstream. Some argue that the upstream controls are the most important, because if a problem isn’t detected early, it will flow through the system undetected. There is truth to this argument.

The second path I take is to start upstream and walk down. This process usually begins at the point when a user enters data into the system, and it typically involves security checks and data validations. Missing controls upstream pose the second greatest risk to ensuring internal control over your financial numbers. Follow the risk analysis process downstream, upstream, and eventually meet in the middle.

Step 6: Implement, test, and document new controls prescribed by the risk/reward analysis. To help with this task, I developed a control dashboard via the ABAP Workbench. This is a screen/program that I create and link to a transaction code (typically ZCONTROL). It provides a single across-the-board view of all the programmable controls that have been put in place. From the dashboard, I can activate or deactivate controls to help enable testing, while also gaining a broad view of all the programmable controls, user exits, and routines that are in place. Since it is a custom-developed screen, it can be implemented in all R/3 versions.

Step 7: Establish methods to monitor controls over time. Are the controls robust enough to remain effective as your business changes? Test the controls after upgrades and after bringing new entities (plants, divisions, countries) into R/3. Sometimes data problems can be intermittent and caused by configuration changes in your system. For example, a business had been live on R/3 for five years and recently made changes to its pricing procedure. The changes produced invoicing problems for orders created before the change, but with billing documents generated afterward. The billing department noticed these problems and took them to the SAP team on a case-by-case basis. Had an audit control table already been established verifying the consistency in order, billing, and accounting documents, the problem would have been noticed immediately and more comprehensively than with the “here-is-an-invoice-with-a-problem” method. Once controls are in place, implement methods to monitor your controls so problems are brought to your attention in a timely manner.

Taylor Erickson

Taylor Erickson has more than 12 years of experience with ERP systems. He has worked with SAP for eight years, specializing in SD/SCM, reporting, and compliance. Taylor is a member of the Institute of Internal Auditors and has facilitated global SAP system implementations and trained numerous SAP customers. He is currently a manager at BearingPoint. Prior to that, he was a consultant for SAP America, and later, practice director of corporate compliance and security for Virtuoso, LLC, an SAP FI/CO consultancy. His latest research is on the effects that Sarbanes-Oxley will have on IT departments running SAP, and leveraging existing R/3 functionality to achieve compliance.

You may contact the author at taylor.erickson@bearingpoint.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.