As an operational specialist, you might not have as much experience documenting internal controls as your counterparts in finance. The author of this article provides a step-by-step approach for the operational side of the business and explains the differences among the different types of controls.
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.
What Is a Control?
Preventative and detective controls typically
fall into four categories: manual procedures, monitoring procedures,
reconciliation procedures, and SAP-enabled controls. A company's
R2P business process, for example, incorporates all four categories
to monitor and direct business transactions.
Manual procedures are typically preventative
in nature and are executed, in theory, when controllable events
occur outside the automated system and require manual intervention
before processing resumes. For example, a company that has
not implemented SAP's purchase requisition release functionality
relies instead on manual procedures to authorize purchases.
In this scenario, purchasing requires an “authorized”
manual purchase requisition before creating and releasing
purchase orders. Once the purchasing organization receives
a “properly authorized” requisition, the buyer
(the control point) uses experience and judgment to validate
the purchase requisition's authenticity and either rejects
the requisition, requires modification, or continues the buying
process.
Management usually implements monitoring procedures
(typically built on top of the existing business process)
in response to an adverse event. This control category attempts
to detect process abnormalities by reporting recorded transactions
to designated users who apply personal knowledge and experience
to ascertain a transaction's validity and formulate
a response to identified anomalies. For example, many companies
require someone to review a vendor change report to help ensure
vendor additions and modifications are authorized and complete.
This individual must have current knowledge of employees authorized
to modify vendor accounts and must consistently apply analytical
procedures to be considered an effective control. This type
of control is difficult and sometimes impossible to implement
in decentralized organizations that are constantly changing.
Reconciliation procedures are special monitoring
procedures and provide compelling evidence that subsidiary
ledgers (e.g., a vendor ledger) reconcile to predefined general
ledger accounts. For example, an accountant reconciles amounts
owed vendors per a vendor detail report with the accounts-payable
balance summarized in the general ledger. Therefore, reconciliation
procedures help ensure that financially relevant R2P transactions
are summarized completely and accurately in the general ledger.
This is a critical control category in non-integrated applications,
since there is a high degree of risk that transactions initiated
in one system (e.g., a legacy A/P system) may not be transferred
to the general ledger. In a fully integrated system like SAP
R/3, however, this risk is greatly reduced, making some reconciliation
procedures superfluous.
SAP-enabled controls operate continuously
in real-time, enforcing preconfigured business rules, and
are typically the first, and sometimes only, control category
that regulates user activity. This control category divides
into two subcategories: security and configuration. Among
other things, SAP-enabled controls help ensure that:
- Transactions are executed by authorized personnel in accordance
with management policy
- Incompatible duties are logically separated
- Levels of authority are properly assigned to authorized
personnel (e.g., release procedures)
- Financially relevant transactions are booked to the proper
general ledger account
- Key financial transactions are accepted and posted based
on pre-existing rules (e.g., three-way match)
- Posted transactions do not exceed pre-authorized limits
- Data-capture rules are consistently applied across the
organization
- Additional SAP security measures are available to affect
more precise authorization
Unlike the other methods of controlling a business process
cycle, SAP-enabled controls do not require human judgment
to execute and are applied consistently across the enterprise
regardless of external factors. This automation is what makes
SAP-enabled controls unique from the other control categories.
They are applied without reference to an individual's
performance, experience, or loyalty, and they give direction
to the business cycle.
SAP-enabled controls can also generate evidence that they
are designed and operating effectively. SAP-enabled controls
are either in place or not in place. The system itself documents
the effectiveness of the control.
1
- 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.
Bryan Wilson
Bryan Wilson is president of Acumen Control ERP, which specializes in SAP risk, advisory, and forensic audit services. With more than 20 years of experience in IT risk management, he has managed SAP R/3-enabled controls design and assessment teams for both KPMG LLP and Deloitte & Touche LLP. Bryan has advised audit committees, executive teams, and audit partners at several multi-national companies of the residual risks in their SAP R/3-supported business cycles. He also helped several multi-national clients re-engineer their SAP R/3 security architecture and re-architect business processes after internal control failures or fraud were identified. He currently helps clients assess their SAP control environments using his forensic audit queries, which clients can use to enhance their own off-the-shelf audit query tools. Bryan has a B.S. degree in computer science and is a Certified Public Accountant (CPA), Certified Information System Auditor (CISA), and an active member of the Association of Certified Fraud Examiners.
You may contact the author at bwilson@acutrolerp.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.