Public companies registered with the Securities and Exchange Commission (SEC) and their external auditors are developing action plans to comply with pending regulations brought on by the Sarbanes-Oxley Act (SOA) of 2002. However, the SOA's long-term effects rest upon recent and future regulations issued by the SEC and the newly created Public Company Accounting Oversight Board (PCAOB).

Complying with provisions associated with Section 404 of the SOA will probably be the most costly to implement. Section 404 requires management to create, maintain, and report on a system of internal controls, which will include operational as well as financial processes. (If you aren't familiar with internal controls, read the sidebar, “What Is a Control?”)

These controls help provide reasonable assurance that the financial statements filed with the SEC are reliable and comply with Generally Accepted Accounting Principles (GAAP). Furthermore, your external auditor must attest to the validity of management's assertion.
A critical dimension of SOA compliance activity is documenting, identifying, and testing relevant controls found in financially critical business cycles. For example, one key business cycle that affects financial statements (e.g., liabilities, cash, fixed assets or expense) is requisition-to-pay (R2P).

I have helped a number of companies and external auditors document, identify, and test SAP-enabled internal controls over financial reporting. I will use this experience to outline a general process for documenting internal controls over financial reporting.

Documenting Internal Controls

The entire SOA project should first have an executive sponsor to help ensure the SOA project's success and that appropriate resources are applied. The sponsor sees that project objectives, milestones, and issues are communicated effectively with the audit committee, executive team, external auditor firm, and internal auditors. Most companies also establish an SOA project management office (PMO) to coordinate project execution.

As depicted in Figure 1, documenting, identifying, and testing internal controls that “provide reasonable assurance” over financial reporting involves the following steps:

Figure 1

The eight steps of an SOA project methodology: 1. The PMO identifies critical business cycles. 2. Choose a suitable control framework. 3. Establish business cycle teams. 4. Identify objectives and risks. 5. Document business cycles and identify controls. 6. Map and assess critical controls. 7. Evaluate and report on controls effectiveness. 8. Maintain internal control documentation.

Step 1. Identify critical business cycles by division and location. The project sponsor and PMO with input from the audit committee, executive management, external audit, and internal audit must identify the critical divisions, locations, and third-party service providers that will be subject to SOA compliance activities. Decentralized IT environments and autonomous management structures require exponentially more SOA project effort than companies that have consolidated their information and communication structures into a single SAP platform.

After the critical divisions, locations, and third-party service providers have been identified, the PMO needs to identify critical business cycles that affect financial reporting. Critical business cycles are industry-dependent, but those usually considered critical to the operational side include:

• R2P
• Order-to-cash
• Manufacturing and inventory
• Project Systems and Plant Maintenance

Step 2. Select and communicate a suitable control framework. In the U.S., the Committee of Sponsoring Organizations (COSO) of the Treadway Commission framework appears to be the control framework of choice. The SEC did not specify or mandate a particular framework, since several other control frameworks have been developed throughout the world. It did, however, specify that the chosen control framework meet specific criteria before it can be used to evaluate internal controls under the SOA.

Regardless of the framework chosen, the PMO should see that all project team members are trained on the framework's requirements. This training step helps ensure that autonomous business process teams are driving toward the same goal and evaluating internal controls consistently across the enterprise. A small training investment now will continually pay future dividends.

Step 3. Establish business cycle teams. Identifying, assigning, and coordinating resources becomes increasingly challenging as the number of decentralized IT environments and autonomous divisions increases. Other factors to consider are resource constraints, SOA compliance deadlines (December 31, 2004, for most U.S. companies), and other business objectives and strategies. However, an SOA business cycle team requires a multitude of skills and responsibilities that are typically shared by several team members. A business cycle team member needs to contribute some or all of the following knowledge:

• Business process procedures (BPPs)
• Business process accounting impact
• SAP configuration
• SAP security assessment
• Business process internal controls
• SAP-enabled controls

The first three attributes are typically found in business process specialists or SAP configuration personnel. SAP security assessment knowledge can be found in either the SAP security organization, internal auditors, or an external consulting firm. The last two attributes should be some combination of internal auditors, external consultants, and business-process personnel working together.

Step 4. Document and communicate objectives and requirements. A critical step in the SOA project is documenting and communicating entity and business-cycle control objectives. It is only after the company identifies these control objectives that material risks can be identified and mitigated. Several companies begin internal control documentation activities based on a pre-defined catalog of risks without first knowing their required financial reporting control objectives. This approach typically results in increased costs to correct perceived “control deficiencies” that are either immaterial or have been mitigated had the objective been known. The risk-only approach can also lead to business-cycle inefficiencies if duplicate and unnecessary controls are forced into an existing process.

• Initiating, recording, processing, and reconciling account balances, classes of transactions and disclosure, and related assertions included in the
  financial statements
• The initiation and processing of non-routine and non-systematic transactions
• The selection and application of appropriate accounting policies
• The prevention, identification, and detection of fraud

These control-assessment requirements (or business cycle objectives) force companies to identify, document, and test a mix of preventative and detective controls in the context of the business process cycle. The last three requirements are straightforward and can be used directly when assessing internal controls. The first requirement, however, imposes on the SOA project a multitude of control requirements that are not evident in the prescribed regulatory guidance.

When the audit profession speaks about “related assertions included in the financial statements,” it is referring to, among other things, the validity, completeness, and accuracy of each line item and disclosure reported on the financial statements (i.e., balance sheet, income statement, cash flow statement, etc.). By implication, the assertions made by management in the financial statements extend to the underlying account balances and classes of transactions. For example, the financial statements typically assert that “trade accounts payable” is complete, which declares all applicable account balances (e.g., A/P, GR/IR) have been included in the financial statement and all pertinent transactions (e.g., purchasing events MIGO, MIRO, FB60) affecting A/P account balances have been properly classified and summarized.

Step 5. Document business cycles and identify controls. I have found that resurrecting integration test scripts developed during implementation is an excellent place to begin the documentation process. The integration test scripts identify critical business-cycle steps and typically do not change dramatically over time. In reviewing the test scripts, you should be able to identify the critical transactions, responsible organizations/
groups, and events that trigger financial transactions. If test scripts are not available, then key IT and business process specialists can usually provide the information you need about the business cycle. Other documentation sources that may prove useful are:

• Corporate policies
• Business process procedures manuals
• Training material
• System flow diagrams

These sources should provide a foundation for the documentation process. However, each business-cycle narrative or flowchart should be concise, well-documented, and control-focused. In documenting the business cycle, project personnel (business, IT, and audit) should be aware of how events interact with and affect subsequent events. This awareness helps the team identify critical controls that either direct/regulate (prevent) transactions or detect (monitor) anomalies resulting from process events.

The process documentation helps the team communicate to executive management its basis for obtaining reasonable assurance by relating relevant controls to the objectives documented and communicated in the previous step. For example, you might state that limiting access to the vendor master file to authorized personnel “helps provide reasonable assurance regarding prevention of unauthorized acquisition of company assets.” You would have to identify, document, and test several more internal controls before making such an assertion, but the identification and association of internal controls to objectives is critical to the assertion process.

Step 6. Map and assess critical controls. Mapping controls to objectives and requirements allows you to identify and focus on critical controls that provide the greatest “assertion” value. For example, many SAP-enabled controls can and do help satisfy multiple objectives. This should result in fewer controls selected for testing. A fully integrated R/3 R2P cycle can have more than 350 potential R/3 security, segregation of duties, configuration, manual, and monitoring controls. Testing the design and operating effectiveness of each identified control is not cost-effective and probably does not provide any additional assurance than selecting the 70 to 90 most critical controls. Less effort is required to ensure the continued effectiveness of these fewer controls, and they are less confusing to those responsible for the assertion.

The SEC regulations also require you to retain evidential material to “prove” that an identified control was designed and operates effectively. Inquiry alone is not generally acceptable. In other words, the SEC specifies your control testing documentation should support:

• Whether the control is designed to prevent or detect material misstatements or omissions
• The conclusion that the tests were appropriately planned and performed
• The test results were appropriately considered

Assessing a control's design requires you to gather evidence that the control is likely to achieve its objectives. The “design” evidence gathered varies based on the control being assessed, and may include evidence related to the control's application, timeliness, execution, follow-on action, and supervision. Assessing a control's operating effectiveness requires you to gather evidence that the control is operating as designed throughout the intended period of reliance. The evidence should support that the control executes in a timely manner (account mapping), operates continuously throughout the period (SAP security), results in actionable steps (release procedures), or is properly monitored (change control, security administration, management review,
and so on).

Of the four types of controls — manual procedures, monitoring procedures, reconciliation procedures, and SAP-enabled — the SAP-enabled controls provide the best opportunities for efficient control assessment activities. Also, SAP-enabled controls are self-documenting when proving their effectiveness.

Step 7. Evaluate and report on control design and operation effectiveness. The effective design and operation of internal controls help reduce the risks of material misstatement in the financial statements, and in associated account balances and classes of transactions. In other words, they help provide management with “reasonable assurance” that account balance and related transactions do not contain material misstatements.

Some of your controls might not operate effectively despite good design. For example, you may identify a configuration control that requires management to authorize the release of vendor invoices that fall outside three-way match criteria. This control helps you achieve the SOA objective “that policies and procedures provide reasonable assurance that expenditures are being made only in accordance with authorizations of management and directors.” However, when testing R/3 security, you found that unauthorized individuals can and do release these blocked vendor invoices. The ineffective operation of this control potentially means you cannot rely on it to meet the SOA objective.

When evaluating the design and operating effectiveness, you should take into consideration all the selected controls identified and tested for the business cycle. By mapping internal controls to SOA objectives and requirements, you should identify and test multiple controls embedded throughout the business cycle that help you meet a particular objective or requirement. This should limit your reliance on any one control and allows you to “assert” a controlled business process based on the totality of controls. However, the consistent failure of a control category such as security may constitute a significant deficiency or material weakness.

Your controls documentation and testing results should support a positive assurance report to management. A negative assurance report (i.e., nothing came to our attention) is not acceptable. The SOA internal controls report should identify by SOA objective and requirement the effective internals controls management intends to rely on for asserting “reasonable assurances.” Your report should also identify and group control testing failures, since these failures may represent a significant deficiency in the design or operation of internal control over financial reporting. You should not be in the business of identifying a significant control and then discounting it because it fails.

Since management has to “positively assert” in its report, I caution you against selecting controls to support year one's assertion and then selecting a substantially different set of controls in subsequent years if no major changes occur in the business process cycle (e.g., reorganization or a new system). I would not want to explain how, for example, year one's assertion is based primarily on manual and monitoring controls, and year two's assertion is based primarily on SAP-enabled controls.

Step 8. Maintain internal control documentation. After you complete the initial SOA project, maintain the business-cycle documentation, controls identified for testing, and test results for next year. This is a critical step, since this year's identification and testing of internal controls will be repeated in subsequent years. If the documentation is saved and carried forward, the testing and assertion process should be more efficient in subsequent years if no significant changes occur.

I suggest you either develop or purchase a tool that will help you maintain internal controls documentation and testing results that is tailored to SOA requirements. This will save time and money in subsequent years and provide a foundation for other control assessment activities and
communications.

Modify your change-control, security administration, and other IT procedures to incorporate an SOA review. For example, if a change request modifies the R2P process, change-control procedures should help ensure the modifications do not invalidate previously identified and tested internal controls that management relies on for financial reporting.