Evaluating Internal Controls - SOXRightsoxright.com/downloads/EY2EvaluatingInternalControls.pdf · in evaluating internal controls. ... Transaction, or Application Level Significant

AS S U R A N C E A N D ADV I S O RY

BU S I N E S S SE RV I C E S

Evaluating InternalControlsConsiderations for Documenting Controls atthe Process, Transaction, or Application Level

!@#

a3

T he Sarbanes-Oxley Act of 2002 (the Act) makes reporting on internalcontrols mandatory for SEC registrants

and their independent auditors. Section 404 ofthe Act directs the SEC to adopt rules requiringannual reports of public companies to includean assessment, as of the end of the fiscal year,of the effectiveness of internal controls andprocedures for financial reporting. Section 404also requires the company’s independentauditors to attest to and report on management’sassessment. The SEC issued its proposed rulesin October 2002 and, if adopted as proposed,they will be effective for companies with fiscalyears ending on or after September 15, 2003.Companies should be getting ready now for thecomprehensive documentation and evaluationof internal control that will be needed to supportmanagement’s assessment and the auditors’attestation report. Our publication, Preparingfor Internal Control Reporting—A Guide forManagement’s Assessment under Section 404 ofthe Sarbanes-Oxley Act (the Guide) (Ernst &Young SCORE Retrieval File No. EE0677),provides a methodology and framework forcompleting the evaluation.

The methodology outlined in the Guide includes five phases:

1 Understand the Definition of Internal Control

1 Organize a Project Team to Conduct the Evaluation

1 Evaluate Internal Control at the Entity Level

1 Understand and Evaluate Internal Control at theProcess, Transaction, or Application Level

1 Evaluate Overall Effectiveness, Identify Matters forImprovement, and Establish Monitoring System

Guidance on the first two phases of the methodology isprovided in the Guide. Detailed guidance on the third phase isprovided in the Ernst & Young publication, EvaluatingInternal Controls—Considerations for Evaluating InternalControl at the Entity Level (Ernst & Young SCORE RetrievalFile No. EE0687). We will be providing more informationabout the overall evaluation—the last phase—in a futurepublication. This document is a tool to assist management inperforming the fourth phase: understanding and evaluatinginternal control at the process, transaction, or application level.

Internal control at the entity level can have a pervasiveinfluence on internal control at the process, transaction, orapplication level. However, unlike the evaluation of entity-level controls, documenting and evaluating controls at thisdetailed level will be far more specific and likely willrequire significantly more time to complete.

Evaluating process, transaction, or application level-controlsprovides a good deal of the evidence management will needto support its overall assessment of the effectiveness ofinternal control over financial reporting. Management willneed to consider controls, including information technology(IT) controls, that serve to prevent or detect errors ofimportance relating to each significant account.

To Our Clients and Other Friends

EVA L UAT I N G IN T E R NA L CO N T RO L S

TO OU R CL I E N T S A N D OT H E R FR I E N D S

Management also will need to consider controls thataddress each of the five components of internal control:

1 Control Environment

1 Risk Assessment

1 Information and Communication

1 Control Activities

1 Monitoring

Controls relating to several of these components—controlenvironment, risk assessment, and monitoring —often areat a higher level and must be evaluated carefully to determinewhether the controls are sensitive enough to prevent ordetect errors of importance or fraud relating to eachsignificant account. Many of the more detailed controlsthat management will identify to support its assessment willbe from the information and communication and/or controlactivities components and primarily relate to specificprocesses and applications.

Companies with multiple locations, business segments, orreporting units likely will need to sponsor multiple,concurrent documentation efforts to adequately address allsignificant aspects of the system(s) of internal control in atimely manner. The broader documentation and evaluation

efforts required in these situations make it incumbent onmanagement to invest appropriate time in building aproject team, developing an approach for identifying anddocumenting controls, determining the types and amountof required documentation, training all team members,developing appropriate timelines for completing all phasesof the work, and developing appropriate two-waycommunication plans so all project team members areadequately informed about project requirements and issuemanagement and resolution procedures.

Like our previous publications, this document is designedto assist management in transforming COSO’s conceptualframework into a detailed evaluation of internal controlover financial reporting. Ernst & Young developed thisdocument based on our extensive knowledge and expertisein evaluating internal controls. While no methodology canconsider all possible issues related to an assessment of acompany’s internal control, we believe this documentprovides a useful methodology and framework to assistmanagement in its evaluation.

We would be pleased to discuss the evaluation of internalcontrol over financial reporting with you, and offer ouradvice and assistance to you.

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

A Word About Materiality. . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Identify Significant Accounts . . . . . . . . . . . . . . . . . . . . . . . . 5

Additional Considerations for Companies with Multiple Locations or Reporting Units . . . . . . . . . . . . . . 6

Identify the Major Classes of Transactions and RelatedProcesses That Influence the Significant Accounts . . . . . 9

Documentation Considerations for Major Classes of Routine Transactions . . . . . . . . . . . . . 12

Documentation Considerations for Major Classes of Estimation Transactions . . . . . . . . . . . . . . . . . . . . . . . 13

Documentation Considerations for Major Classes of Non-Routine Transactions . . . . . . . . . . . . . . . . . . . . . 13

Documentation Considerations for the Financial Statement Close Process . . . . . . . . . . . . . . . . . 13

Ask “What Can Go Wrong” Questions. . . . . . . . . . . . . . . . 15

Identify Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Types of Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Considerations for Documenting Controls . . . . . . . . . . . . . 20

Perform Walk-Throughs to Confirm Understanding of Process and Controls . . . . . . . . . . . . 21

Perform Walk-Throughs of IT General Controls . . . . . . . . 22

Considerations for Documenting Walk-Throughs. . . . . . . . 22

Controls Residing Outside the Company . . . . . . . . . . . . . . 22

Finalizing the Documentation of Controls . . . . . . . . . . . . . 23

Company Policies and Procedures RegardingAuthorization, Safeguarding of Assets, andAsset Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Appendix A — Example Significant Accounts andProcesses for Selected Industries . . . . . . . . . . . . . . . . 27

Appendix B — Example Risk and Control Documentation for Cash Disbursements Process. . . 34

Appendix C — Common IT General Controls . . . . . . . . . . . 36

IT Program Acquisition, Implementation and Maintenance Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . 36

IT Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Appendix D — Example Segregation of Duties Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Contents

EVA L UAT I N G IN T E R NA L CO N T RO L S

OV E RV I E W

Processes That Influence the Significant Accounts:1 Flows of transactions

— Routine— Non-Routine— Estimation

1 IT processes1 Financial Statement Close Process

Documenting Controls at the Process, Transaction, or Application Level

SignificantAccounts

ManagementAssertions

What CanGo Wrong?

Controls

Evaluate/Monitor

Report

SignificantProcesses

Inherent and KeyBusiness Risks

Financial Statements

BalanceSheet

?

ManagementReport onInternalControl

Financial Statement Assertions:1 Existence or Occurrence1 Completeness1 Valuation or Measurement1 Rights and Obligations1 Presentation and Disclosure

Significant Accounts Selected Based Upon:1 Errors of importance*1 Size and composition1 Susceptibility to loss or fraud1 High transaction volume1 Transaction complexity1 Subjectivity in determining account balance1 Nature of the account

For Each Assertion Ask:1 Where are the points in the flow of transactions where

errors can occur? 1 Example:

Accounts: Cash or PayablesProcess: DisbursementsAssertion: ValuationWhat are the manual and programmed procedures to ensure thatthe amount of a check or transfer agrees with the amountapproved for payment?

Controls That Prevent or Detect Errors of Importance* or Fraud:1 Who Performs?

— Segregation of duties1 Control Dependent on IT?

— Programmed control— Electronic evidence

1 Company policies and procedures for:— Authorization of transactions— Safeguarding of assets— Asset accountability

Next Steps

* Errors that individually or collectively could have amaterial effect on the financial statements

Process Implications Financial Implications

{

1

Some companies already have

extensive documentation of their

accounting procedures and internal

control, such as accounting policy and

procedures manuals, information system

manuals, and job descriptions. However,

most companies likely have not completed a

comprehensive documentation and evaluation

of the effectiveness of their internal control

either as contemplated by the 1992 Report of

The Committee of Sponsoring Organizations

of the Treadway Commission (COSO) or as

required by the Act. Internal audit departments

often have documentation of companies’

internal controls and procedures and have

tested whether selected controls are operating

effectively. Independent auditors also evaluate

controls in specific areas. However, prior to

the Act the focus of an audit of the financial

statements has been to provide an opinion on

a company’s financial statements and not to

report on internal control. Therefore, it is

unlikely companies already will possess

sufficient, organized documentation to support

management’s assessment of the effectiveness

of internal control.

The approach outlined in our publication, Preparing forInternal Control Reporting—A Guide for Management’sAssessment under Section 404 of the Sarbanes-Oxley Act(the Guide), suggests forming a committee or project teamto plan and supervise the development, staffing, andexecution of the company’s evaluation of internal control.

Once the project team is identified, the first step in evaluatinginternal control is assessing internal control at the entitylevel. Additional guidance on this phase is provided in ourpublication, Evaluating Internal Controls—Considerationsfor Evaluating Internal Control at the Entity Level.

After that assessment is completed, the project team gainsan understanding of the processes and related controlsinvolved in generating financial statement information.The documentation approach described herein foraccomplishing this understanding focuses on:

(1) Determining significant accounts or groups of accounts,beginning at the financial statement caption or footnotedisclosure level, that can contain errors of importanceor that should be evaluated based on other factors (e.g.,susceptibility to loss or fraud),

Overview

2 EVA L UAT I N G IN T E R NA L CO N T RO L S

OV E RV I E W

(2) Identifying the major classes of transactions andrelated processes, including information technology(IT) processes, that influence the significant accounts,

(3) Determining the types of errors that can occur ininitiating, recording, processing, and reportingtransactions, and

(4) Identifying controls, including IT controls, that serveto prevent or detect and correct errors of importanceon a timely basis, as well as to prevent and detect fraud.

The completion of these phases—evaluating internalcontrol at the entity level and then understanding andevaluating internal control at the process, transaction, orapplication level—will provide the project team withinformation necessary to evaluate the overall effectivenessof controls in the final phase of the methodology. In thefinal phase, the project team also will perform proceduresto determine that the controls are in fact operating asdesigned. Additional information about evaluating theoverall effectiveness of internal control, including strategiesfor determining that controls are operating as designed, willbe provided in a future publication.

We anticipate management for some public companies willchoose to incorporate its documentation and evaluation ofinternal control over financial reporting with broader riskmanagement programs that also may address the other aspectsof the COSO definition of internal control (i.e., effectivenessand efficiency of operations, compliance with laws andregulations), and/or other aspects of enterprise riskmanagement. Whether performed as part of a broaderprogram, or as a stand-alone project, management’sdocumentation and evaluation will need to address all five interrelated components of internal control at a level sufficient to support management’s assertion on theeffectiveness of internal control over financial reportingand the independent auditors’ attestation report thereon.

A Word About MaterialityCurrent attestation standards indicate an assertion thatinternal control over financial reporting is “effective” impliesthat controls are effective in preventing and detecting errorsof importance (i.e., errors that individually or collectivelycould have a material effect on the financial statements).

It currently is not clear whether the final rules issued by theSEC to implement the requirements of Section 404 of theAct or the standards adopted by the Public CompanyAccounting Oversight Board (the Board) will specificallydiscuss the thresholds that management should establish fordetermining significant deficiencies and material weaknessesin order to fulfill their reporting responsibilities. Regardlessof whether the final rules and standards will specify orrequire public companies to develop materiality thresholds,the project team should consider materiality concepts indeveloping a strategy and approach for documenting andevaluating internal control over financial reporting.

Management generally designs its system of internal controlto prevent or detect and correct all errors in financialreporting or otherwise establishes relatively low thresholdsfor errors it is willing to tolerate in the initiating, recording,processing and reporting of transactions. The project teamgenerally will establish higher materiality thresholds todocument and evaluate internal controls for purposes of itsassessment. However, those materiality thresholds shouldnot be set so high that the team fails to adequately addressall significant aspects of the system(s) of internal control.

Materiality should be considered at two levels: at theoverall level, as it relates to the financial statements takenas a whole; and at the individual account level. At thefinancial level, materiality is used in considering whether a material weakness in internal control exists. A materialweakness in internal control is defined as a significantdeficiency in which the design or operation of one or moreof the internal control components does not reduce to arelatively low level the risk that misstatements, whethercaused by error or fraud, in amounts that would be materialin relation to the financial statements, may occur and not bedetected within a timely period by employees in the normalcourse of performing their assigned functions.

Materiality at the individual account level should be sufficiently low to identify a significant deficiency ininternal control over the individual account or group ofaccounts. A significant deficiency is a deficiency that couldadversely affect the organization’s ability to initiate, record,process, or report financial data consistent with theassertions of management, explicit or otherwise, with regardto the financial statements. The lower threshold at the

account level generally would provide the project team theopportunity to consider whether the significant deficienciesidentified, when considered in the aggregate, could rise tothe level of a material weakness. When establishing thelower threshold, management also may wish to considerthe ability to identify control matters that individually donot rise to the level of significant deficiencies. Applyingmateriality concepts at the individual account level is furtherdescribed in the next section, Identify Significant Accounts.

For companies with multiple locations, business segments,or reporting units, the project team likely will need toemploy materiality concepts to make sure the controldocumentation and evaluation efforts adequately addressall significant aspects of the system(s) of internal control.Additional considerations for these types of companies areprovided in the next section.

3








ID E N T I F Y SI G N I F I C A N T AC C O U N T S


SignificantAccounts


What CanGo Wrong?

Controls

Evaluate/Monitor

Report




BalanceSheet

?










Next Steps{

5

Identify Significant Accounts

The starting point for identifying

the significant processes over

which internal controls are applied

is to identify significant accounts at the

consolidated financial statement caption or

footnote disclosure level. This section discusses

the process for identifying significant accounts

or groups of accounts.

An account (or group of accounts) is significant if it cancontain errors of importance or, in management’s judgment,should be evaluated because of one or more other factors.Factors to consider in determining whether an account orgroup of accounts is significant or otherwise should beevaluated include:

1 Size and composition of the account, including itssusceptibility to loss or fraud

1 Volume of activity and the size, complexity andhomogeneity of the individual transactions processedthrough the account

1 Subjectivity in determining the account balance (i.e., theextent to which the account is affected by judgments)

1 Nature of the account (e.g., suspense accounts generallywarrant greater attention)

1 Accounting and reporting complexities associated withthe account

1 Existence of related party transactions

1 Changes in account characteristics (e.g., theintroduction of new complexities or subjectivities, newtypes of transactions)

After identifying the significant accounts at the consolidatedfinancial statement level, the project team should considerseparating the components of an account or group of accountsto the extent the components are subject to differing risks(and/or different controls). For example, the allowance fordoubtful accounts generally is considered a significantaccount separate from accounts receivable since the allowanceis more subjective and the transactions that affect the balanceare driven by management estimation processes rather thanroutine transaction processing (e.g., sales, cash receipts).

Organizational structure might be another reason forseparating components of an account. For example, if acompany has five separate business units, each with uniquemanagement and accounting processes, it generally will benecessary to identify and evaluate processes and controlsover the significant accounts or groups of accounts of eachseparate business unit. Likewise, the project team maydetermine that other segmentation (e.g., business segment,location, country, operating system) will be necessary toefficiently and effectively identify, document and evaluatecontrols. Generally, when the components comprising theaccount or group of accounts are subject to different riskprofiles and control environments, they should be consideredseparately when documenting and evaluating the controlsthat mitigate the risk of material misstatements.

Illustration 1 depicts example significant accounts for amedium-sized manufacturing company operating in onebusiness segment with three significant manufacturinglocations, three significant sales locations, and highlycentralized corporate accounting and administrativefunctions. The areas noted with a (✔ ) indicate significant


ID E N T I F Y SI G N I F I C A N T AC C O U N T S

Significant Accounts to DocumentManufacturing Locations Sales Locations

Corporate A B C A B C

Cash and Cash Equivalents ✖

Accounts Receivable and Related Income Statement Activity ✖ ✖ ✖

Allowance for Doubtful Accounts and Bad Debt Expense ✖ ✔ ✔ ✔

Inventories and Related Income Statement Activity ✖ ✖ ✖

Inventory Reserves and Related Income Statement Activity ✖ ✔ ✔ ✔

Prepaids, Other Current Assets and Related Income Statement Activity ✖

Property, Plant and Equipment and Depreciation Expense ✖

Intangible Assets and Related Amortization ✖

Accounts Payable and Related Income Statement Activity ✖

Income Taxes (Current, Deferred) and Related Income Statement Activity ✖

Accrued Liabilities and Related Income Statement Activity ✖

Debt and Related Interest Expense ✖

Pension, OPEBs and Related Income Statement Activity ✖

Commitments, Contingencies and Related Expense ✖

Stockholders’ Equity and Stock Compensation Expense ✖

Payroll Expense and Related Accrued Liabilities ✖ ✔ ✔ ✔

Illustration 1—Medium-Sized Manufacturing Company

Example Significant Accounts or Groups of Accounts

accounts or groups of accounts that, under the scenarioillustrated, also might need to be evaluated in part at themanufacturing or sales locations.

Illustration 1 shows how significant asset, liability, orshareholders’ equity accounts are grouped with thecorresponding income or expense accounts that are affectedby the same classes of transactions. For example, bothaccounts receivable and the corresponding sales account areaffected by a sales transaction. Appropriate grouping ofaccounts at the outset will streamline the documentationprocess and reduce potential documentation redundancy.Appendix A provides additional illustrations of significantaccount groupings for selected industries.

We encourage project teams for larger, decentralizedorganizations to pay particular attention to the accountgroupings of the various business units to help limitunnecessary variations in documentation approaches thatmay be difficult to aggregate in later stages of the project.The project team also should document at this point thespecific general ledger accounts included in each grouping ofsignificant accounts. This will aid the team in determining thatthere are no unintended gaps in the subsequent documentationprocess and also will limit possible duplication of work.

This also is an appropriate time for the project team todocument the financial statement assertions that arerelevant to each of the significant accounts or groups ofaccounts identified. Financial statement assertions aredescribed and discussed in a later section of this publication,Ask “What Can Go Wrong” Questions, where the projectteam utilizes the assertions to identify controls that areneeded to prevent or detect errors of importance or fraud.Project team members not familiar with this conceptshould refer to that section. An understanding of therelevant assertions for a particular account or group ofaccounts will assist the project team in identifying themajor classes of transactions and related processes andaccounting activities that influence the significant accountsin the next step of the documentation process.

Additional Considerations for Companies withMultiple Locations or Reporting UnitsThe project team for companies with operations in multiplelocations or comprised of several reporting units will needto develop an efficient and effective approach that, at aminimum, identifies significant deficiencies across thevarious locations and reporting units that alone or in theaggregate may be material weaknesses. The factors the

7

project team will need to consider, and the approach it willmost likely develop, are similar to the factors and approachused by auditors in performing an audit of the financialstatements of a company with multiple locations orreporting units. It may not be necessary to document andevaluate controls at each location or for each reportingunit. However, those locations or reporting units excludedshould not be capable of being material in the aggregate.

Some factors the project team should consider in developingits approach to selecting locations or reporting unitsinclude the following:

1 The similarity of business operations and internalcontrol at the various locations or reporting units

1 The degree of centralization of records

1 The effectiveness of the control environment,particularly management’s direct controls over theexercise of authority delegated to others

1 The nature and amount of transactions executed andrelated assets at the various locations or reporting unitsand to what degree the location or reporting unit couldcreate an obligation to the entity

1 The nature and extent of monitoring controls over thevarious locations or reporting units

Determining the overall scope of the documentation andevaluation effort for companies with multiple locations orreporting units will require the project team to apply thesefactors to the significant accounts identified. The projectteam generally will find it easier to scope the project whenthe balances or activities comprising a significant accountare concentrated in one or a small number of locations orreporting units. In these instances, the project team likelywill focus its efforts on those locations or reporting unitsand conclude that the other locations or reporting units arenot significant to management’s assessment of controls.

More judgment will be required in situations where thebalances or activities comprising significant accounts aredispersed throughout numerous locations or reporting unitswith no one location or reporting unit being significant tomanagement’s assessment. In these instances, the projectteam will need to apply the factors listed above in determiningthe overall project scope. The project team may be able to

streamline the documentation and evaluation effort if thevarious locations or reporting units are subject to commonprocessing, thus allowing the project team to evaluate controlsover those processes centrally.

Additionally, if aspects of the processing for the variouslocations or reporting units are decentralized but followstandardized procedures and processing controls, the projectteam may be able to document and evaluate those processesand controls once and then limit the onsite procedures toconfirming that the controls were implemented across thevarious locations or reporting units. In contrast, where theoperations of the various locations or reporting units are notstandardized or the processing is not centralized, the projectteam will need to document and evaluate processes andcontrols for a sufficient number of the individual locationsor reporting units so that those locations or reporting unitsexcluded are not capable of being material in the aggregate.

The project team may wish to use scope designations todescribe the levels of documentation and evaluation effortrequired for locations or reporting units. For example:

1 Comprehensive—Location or reporting unit is amaterial component of the company and the projectteam will need to document and evaluate processes andcontrols for all significant accounts of the location orreporting unit

1 Limited —Specific accounts of the location or reportingunit are significant and the project team will need todocument and evaluate processes and controlsassociated with those accounts

1 Excluded —Location or reporting unit is not significantto the overall assessment of internal control

The documentation and evaluation effort for locations or reporting units designated as limited scope will vary depending on the significance of the location tomanagement’s assessment and its evaluation of the risk oferrors of importance or fraud. We encourage project teamsto provide specific direction on which accounts to documentto ensure that the effort is consistent with management’soverall approach to the assessment of internal control.








SignificantAccounts


What CanGo Wrong?

Controls

Evaluate/Monitor

Report


?



ID E N T I F Y T H E MA J O R CL A S S E S O F

TR A N S AC T I O N S A N D RE L AT E D PRO C E S S E S

TH AT IN F L U E N C E T H E SI G N I F I C A N T AC C O U N T S








Next Steps{



BalanceSheet


9

Identify the Major Classes ofTransactions and Related ProcessesThat Influence the Significant Accounts

After identifying the significant

accounts, the project team will

identify the major classes of

transactions, significant processes, and related

accounting activities and controls that affect

those accounts. Significant processes and

related accounting activities are those that

are involved in processing major classes of

transactions (e.g., sales, purchases of goods

or services, recording depreciation expense)

affecting significant accounts or groups of

accounts. Accounting activities also include

activities to develop and record key accounting

estimates or to complete the financial

statement close process at the end of an

accounting period.

Companies might define or label processes differently.Some companies have a stronger focus on managing the business from a process perspective, while othercompanies have a more traditional view of accountingprocesses separate from the operational aspects of the

business. Irrespective of the approach used, the objective is to document how the major classes of transactions areinitiated, recorded, processed, and reported.

We anticipate that project teams of many companies willfind that major classes of transactions affecting thesignificant accounts or groups of accounts rarely areencompassed within a single process. In these situations theproject team may conclude it is more effective to focus onsignificant transaction flows and related accounting activitiesand controls to understand the major classes of transactions.

When starting with processes, we suggest the project teamfirst correlate business processes to significant financialstatement accounts. An efficient way to make this correlationis to consider the accounts at a sufficient level of detail. Anexample of this is segregating inventories between (a) rawmaterials (purchasing), (b) work in progress (manufacturing),(c) finished goods (distribution), and (d) consumables(maintenance). The project team can then link the majorclasses of transactions that are embedded in these processesto the significant accounts or groups of accounts.

Different types of transactions have different levels ofinherent risk associated with them and require differentlevels of management supervision and involvement. Foreach process identified, we recommend categorizing theprocesses using three transaction types—routine, non-routine, and estimation—for the same reason.

Routine transactions are frequently recurring financialactivities reflected in the books and records in the normalcourse of business (e.g., sales, purchases, cash receipts,cash disbursements, payroll). Non-routine transactions arefinancial activities that occur only periodically (e.g., takingphysical inventory, calculating depreciation, adjusting forforeign currencies). A distinguishing feature of non-routine

transactions is that data involved generally are not part ofthe routine flow of transactions. Estimation transactions arefinancial activities that involve management judgments orassumptions in formulating an accounting balance in theabsence of a precise means of measurement (e.g., determiningthe allowance for doubtful accounts, establishing warrantyreserves, assessing assets for impairment).

Another important attribute to consider for each significantprocess is its dependence on IT. The project team generallywill need to document the IT system used to process themajor classes of transactions (e.g., data center, mainframe,client/server, personal computers). Further, in today’s highlyautomated business environments, flows of transactionstypically are automated and management often relies onprogrammed controls (i.e., programmed control proceduresover transaction data subject to computer processes at theapplication level) to ensure the accuracy and completenessof data.

Because many companies have a high volume oftransactions, programmed controls typically are a keycomponent of the design of processes over routine andnon-routine transactions. In addition, even thoughprocesses over estimation transactions generally aremanual operations involving significant managementjudgment, normally their accuracy depends indirectly ondata elements generated via other computerized processes.The project team therefore may require the skills of ITspecialists to understand the flows of transactions throughthe significant processes and to identify, document andevaluate relevant programmed controls.

The level of understanding and corresponding documentationof the major classes of transactions and the processes thatsupport them should be at a level sufficient to understandthe flow of each major class. The objective of this step is toidentify and document the significant records, documents,and basic processing procedures in use, and to identify anddocument the personnel and functional areas that performthe various processing activities. This documentationserves as a basis for identifying where errors or fraud canoccur, which is discussed in the next section.

Most processes involve a series of tasks such as capturinginput data, sorting and merging data, making calculations,updating transactions and master files, generatingtransactions, and summarizing and displaying or reportingdata. The processing procedures relevant to the project teamin understanding the flow of transactions generally are thoseactivities required to initiate, record, process, and reporttransactions. Such activities include, for example, initiallyrecording sales orders, preparing shipping documents andinvoices, and updating the accounts receivable master file.The relevant processing procedures also include proceduresfor correcting and reprocessing previously rejectedtransactions and for correcting erroneous transactionsthrough adjusting journal entries.

In the course of documenting the processing procedures, theproject team may identify many of the controls in use. Thus,while the emphasis during this phase of documentation is notnecessarily to identify the presence or absence of controls,the project team should be alert to the possible absence ofcontrols, and to the points where errors can occur and controlsare needed. Also, this step often identifies programmedcomputer routines and data files that may require furtherreview when the project team identifies and documents therelevant IT controls.

Documenting how transactions are initiated, recorded,processed, and reported in a more complex process frequentlywill require collaboration among various company personnelinvolved in the process (users) and IT personnel, since usersare less likely to have a sufficient understanding of all relevantaspects of processing transactions. In a more complexenvironment, many processes can be supported by the samecomputer application. These situations may require the projectteam to consider in more detail access controls and/or systemprivilege settings for the application, which are discussed inmore detail in the section entitled, Identify Controls.

Illustration 2 depicts a typical interaction of significantaccounts and processes for a medium-sized manufacturingcompany operating in one business segment. As depicted inIllustration 1 in the previous section, Identify SignificantAccounts, there might be multiple components of anaccount or group of accounts, each affected by uniqueprocesses (e.g., accounts receivable and related processes,





11

Cash Receipts Routine ✖ ✖ ✖

Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Payroll Routine ✖ ✖ ✖ ✖

Purchase and Pay for Assets and Expenses Routine ✖ ✖ ✖ ✖

Inventory Costing and Cost of Sales Routine ✖

Sales and Accounts Receivable Routine ✖

Account for Stock Options Non-Routine ✖

Adjust for Foreign Currencies Non-Routine ✖

Amortize Prepaid and Intangible Assets Non-Routine ✖ ✖

Assess Assets for Impairment Estimation ✖ ✖

Calculate Income Taxes Non-Routine ✖

Depreciate Property, Plant, and Equipment Non-Routine ✖ ✖

Estimate Commitments and Contingencies Estimation ✖ ✖

Estimate Excess and Obsolete Inventory Reserves Estimation ✖

Estimate Pension and OPEB Liabilities and Expense Estimation ✖

Estimate Allowance for Doubtful Accounts and Bad Debt Expense Estimation ✖

Estimate Warranty Reserve and Expense Estimation ✖ ✖

Lower of Cost or Market Calculation Estimation ✖

LIFO Calculation Non-Routine ✖

Physical Inventory (Count and Compilation) Non-Routine ✖

Record and Monitor Debt Non-Routine ✖

Example Significant Accounts

Example Processes TypesTransaction

Illustration 2—Medium-Sized Manufacturing Company

Cash

and

Cash

Equiv

alent

sAc

coun

tsRe

ceiva

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Allow

ance

for D

oubt

ful A

ccou

nts

and

Bad

Debt

Expe

nse

Inven

torie

san

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Inven

tory

Rese

rves

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Prep

aids,

Othe

r Cur

rent

Asse

tsan

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Prop

erty,

Plan

t and

Equip

men

t and

Depr

eciat

ionEx

pens

e

Intan

gible

Asse

tsan

dRe

lated

Amor

tizat

ion

Acco

unts

Paya

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Accr

ued

Liabi

lities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Debt

and

Relat

edInt

eres

t Exp

ense

Pens

ion,

OPEB

san

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Stoc

khold

ers’

Equit

y and

Stoc

k Com

pens

atio

nEx

pens

e

Payro

ll Exp

ense

and

Relat

edAc

crue

dLia

bilit

ies

inventories and related processes) for companies operatingfrom multiple locations or engaged in multiple lines ofbusiness. Likewise, similar-sized manufacturing companiesmay identify different or additional significant accounts andprocesses unique to their business profile. For example,some manufacturing companies may have large investment

portfolios with complex financial instruments and derivatives,while others may have little or no foreign currency or otherderivatives exposure. In addition, some manufacturingentities have significant pension and other postemploymentbenefit (OPEB) liabilities, while others have a limitednumber of or no pension or OPEB plans.





Appendix A provides additional examples of the typicalinteraction of significant accounts and processes for otherindustries (e.g., banks and savings institutions, technologyand communications companies, retail companies).

As depicted in Illustration 2, a significant process thatshould be considered for all companies is the financialreporting process—the process of “closing the books” andpreparing the financial statements (also referred to as thefinancial statement close process). The understanding ofthe company’s significant processes and how they interrelatewith the company’s financial reporting process will providethe project team with a basis for what additional informationis required to understand the financial reporting process.

The financial reporting process typically includes:

1 The procedures used to enter transaction totals into thegeneral ledger.

1 The procedures used to initiate, record, and processjournal entries in the general ledger.

1 Other procedures used to record recurring andnonrecurring adjustments to the financial statements,such as consolidating adjustments, report combinations,and reclassifications.

1 The procedures for drafting financial statements andrelated footnote disclosures.

Documentation Considerations for Major Classes ofRoutine TransactionsThe project team should examine or prepare and, asappropriate, retain copies of documentation that is helpful inproviding a basic understanding of the flow of transactions.This documentation should include how transactions areinitiated, recorded, processed, and reported. The projectteam also should consider other existing documentation(e.g., process models, flowcharts, procedural manuals, jobdescriptions, documents, forms).

The documentation reflects, to the extent practicable, all therelevant processing procedures, whether performed manuallyor automated. The project team generally obtains copies of orprepares certain information technology documentation,such as systems narratives, systems diagrams, and flowcharts

(showing the sequence of significant programs, transactionfiles, and master files involved in the application, but notthe detailed program logic).

The project team does not need to obtain or preparedocumentation about every detail of the flow or followevery typical data element (e.g., sales invoice updates thecustomer relationship management system) from initiationto its final recording. However, the project team shoulddocument enough information about the flow of transactionsto assist in identifying where errors of importance can occur.Thus, the documentation generally shows those activitieswithin a process where data is initiated, transferred, orotherwise changed.

Since the primary purpose of this documentation is to helpidentify where errors or fraud can occur, the project teamcan concentrate on documenting:

1 Major input sources

1 Important data files (e.g., customer and price masterfiles), documents, and records

1 Significant processing procedures, including on-lineentry and updating processes

1 Important output files, reports, and records

1 Functional segregation of duties (i.e., showing theprocessing by department)

A lack of segregation of duties exists if any individualperforms incompatible activities or if access controls of acomputer application grant users inappropriate or excessiveaccess to functionality (e.g., if an individual is in a positionto both perpetrate and conceal fraud in the normal courseof performing his or her duties). Thus, the project teamshould consider whether any individuals (1) performprocessing procedures that are incompatible with each other,(2) perform both processing procedures and related controls,or (3) have inappropriate access to the accounting recordsand related assets. We recommend project teams developmethods for identifying inadequacies in the segregation ofduties for each major class of transactions. Appendix Ddisplays an example segregation of duties template for thecash disbursements process. The project team can obtainsegregation of duties templates for other classes of routinetransactions from their Ernst & Young engagement team ora local Ernst & Young representative.

13

Documentation Considerations for Major Classes ofEstimation TransactionsThe project team should document the understandingobtained from discussions with process owners, review ofdocumentation, and observation of the process. The projectteam should retain, as appropriate, copies of the relevantdocumentation, and consider preparing narratives, diagrams,and/or flowcharts to document the process. Specifically,the project team should document:

1 The data used to make the estimate (e.g., the agedlisting of accounts receivable may be used to identifypotential bad debts)

1 The relevant factors and assumptions that companypersonnel consider in making the estimate, including thereasons for the particular assumptions

1 The techniques (i.e., the models) company personneluse to apply the assumptions to the data, including theprocedures to collect, calculate, and aggregate therelevant data

1 The frequency with which the estimation transaction occurs

1 The degree of subjectivity involved

1 The company personnel (or third party specialists)involved in making the estimate

Documentation Considerations for Major Classes ofNon-Routine Transactions The project team should document the understandingobtained from discussions with process owners, review of documentation, and observation of the process. Theproject team should retain, as appropriate, copies of thedocumentation, and consider preparing narratives,diagrams, and/or flowcharts to document the process.Specifically, the project team should document:

1 The procedures or forms the company uses (e.g., thewritten instructions used in a physical inventory)

1 Any computer applications the company uses in theaccounting activities (e.g., applications, purchased orinternally-developed, used to calculate depreciation or to capture the physical inventory counts through bar-code scanning)

1 The assumptions, if any, employed in the transaction(e.g., the average useful lives employed in calculatingdepreciation)

1 The frequency with which the non-routine transactionoccurs

1 The company personnel involved in the accountingactivities

Documentation Considerations for the FinancialStatement Close ProcessThe project team should document each significantcomponent (e.g., consolidation procedures, preparation ofelimination entries) of the overall process, including anunderstanding of the inputs, procedures performed, flow of activities, and outputs of each component of the overallprocess used to produce the financial statements anddisclosures. The documentation may include copies ofexisting documentation, or the project team may need tohave the responsible process owners prepare narratives,diagrams, and/or flowcharts to document the process.









BalanceSheet



SignificantAccounts


What CanGo Wrong?

Controls

Evaluate/Monitor

Report


?



AS K “WH AT CA N GO WRO N G” QU E S T I O N S








Next Steps{

15

Considering the types of errors that

can occur at the process, transaction,

or application level is a key step for

assuring that the project team appropriately

focuses on those controls that are both relevant

and effectively designed to prevent and detect

errors of importance or fraud. The project

team will need to determine the level of detail

that is appropriate based on its knowledge of

the financial reporting risks associated with

each significant process being evaluated and

their relative importance to the overall

financial statements (relatively small errors in

enterprise-wide processes could have

potentially pervasive effects, whereas

potentially larger errors in isolated or less

significant processes may not).

In identifying the types of errors that can occur, the projectteam considers the relevant financial statement assertionsfor the significant accounts. Financial statement assertionsare representations by company management, explicit orotherwise, that are embodied in the financial statements.These assertions are:

Financial Statement Assertions Explanation

Existence An assertion that an asset or a liability exists ata point in time.

Controls exist that ensure only valid assets and liabilities are recorded, assets are appropriatelysafeguarded, and that periodic accountability ismaintained.

Occurrence An assertion that a recorded transaction orevent actually took place during the period.

Controls exist to ensure fictitious or duplicatetransactions are not included in the records.

Valuation or Measurement An assertion that an asset or liability is recordedat an appropriate amount.

An assertion that a transaction or event isrecorded at the proper amount and revenue orexpense is allocated to the proper period.

Controls exist to ensure that transactions arerecorded at correct monetary amounts.

Completeness An assertion that there are no unrecordedassets, liabilities, transactions or events, orundisclosed items.

Controls exist to ensure actual transactions are not omitted from the records, all transactions are reflected in the proper accounting period,transactions are recorded in the correct accounts,all charges and credits in the underlying recordsare accumulated correctly, and accumulated totalsare correctly transferred to the general ledger.

Rights and Obligations An assertion that an asset or a liability pertainsto the company at a point in time.

Controls exist to ensure that the entity has legaltitle to recorded assets and rights to assets areonly assigned with appropriate authorization, andonly liabilities of the company are recorded.

Presentation and Disclosure An assertion that an item is properly classified,described, and disclosed in the financial statements.

Ask “What Can Go Wrong” Questions

The financial statement assertions are considered at theprocess, transaction, or application level. However, formost accounts the “presentation and disclosure” assertionis considered in connection with the financial statementclose process or at the overall entity level.

For each significant process, the project team shouldidentify the points within the flow of transactions wheredata is initiated, transferred, or otherwise changed andwhere there can be a failure (including a failure due tofraud) to achieve the financial statement assertions; that is,identify “what can go wrong” in the processing stream.These are the points where controls are needed.

Asking “what can go wrong” questions will assist theproject team in:

1 Identifying the points within the flow of transactionswhere there can be failures to achieve the financialreporting objectives (i.e., the points where errors canoccur that can result in inaccurate assertions in thefinancial statements)

1 Formulating the additional questions the project teamwill need to answer to identify the appropriate controls

Illustration 3 provides example “what can go wrong”questions for a cash disbursements process.

An important consideration in evaluating financialstatement assertions is whether there are controls in placeto identify and reject erroneous data and, when applicable,to correct and resubmit the data in the normal processingstream. To identify and understand controls, the projectteam should use the financial statement assertions togetherwith their understanding of the company’s significantprocesses to:

1 Identify what can go wrong in the processing stream(i.e., identify where data errors can occur)

1 Determine whether the company/reporting unit hasprescribed controls to prevent or detect and correct errorsin a timely manner as well as to prevent or detect fraud

Processes over non-routine and estimation transactionsoften involve higher risk because they are more likely to beinfluenced by business risks and management decisions. Inparticular, when considering the types of errors that canoccur in a process over estimation transactions anddeveloping “what can go wrong” questions, the projectteam may need to consider:

1 Are assumptions appropriate (i.e., are they based onreasonable interpretations of present circumstances andon the best available information)?

1 Is the data used in making the estimate likely to be bothrelevant and reliable?

1 Is any of the data used produced by an IT process thatshould be evaluated?

1 Is the model used to make an estimate appropriate, andis it applied correctly?

These “what can go wrong” questions are the foundation theproject team can use to determine whether controls properlyaddress the risks related to material misstatements,omissions, and discrepancies in the financial statements. By considering “what can go wrong” questions for eachclass of transaction, the project team can improve itsability to identify the significant risks related to thefinancial statements, while minimizing time spent on lessrelevant aspects of the process.

“What Can Go Wrong” Questions AssertionWhat ensures that cash disbursements are

correctly coded? Completeness

What ensures that cash disbursements/transfers are recorded in the proper period? Completeness

What ensures that duplicate postings of cash disbursements are not made to the general ledger? Occurrence

What ensures that cash disbursements are real? Existence/Occurrence

What ensures that all cash disbursements are recorded? Completeness

What ensures that cash disbursement amounts recorded agree with amounts paid? Valuation/Measurement


AS K “WH AT CA N GO WRO N G” QU E S T I O N S

Illustration 3—Example “What Can Go Wrong” Questions

17

The number of questions the project team should posedepends, among other things, upon the complexity of theprocess and the number of opportunities for errors to occurand remain undetected.









BalanceSheet



ID E N T I F Y CO N T RO L S


SignificantAccounts


What CanGo Wrong?

Controls

Evaluate/Monitor

Report


?









Next Steps{

19

Identify Controls

At this point, the project team

considers controls over each

significant process that address the

“what can go wrong” questions for the relevant

assertions. The objective is to identify the

controls that provide reasonable assurance that

errors relating to each of the relevant financial

statement assertions are prevented, or that any

errors that occur during processing are

detected and corrected.

Management generally designs, and places in operation,controls over processes to ensure that the operating, financialreporting, and compliance objectives of each process areachieved. However, for purposes of evaluating theeffectiveness of internal control over financial reportingunder the Act, the project team is concerned with controlsthat address the financial reporting objective. Therefore, theproject team should identify controls related to the initiation,recording, processing, and reporting of transactions.

In some situations, the project team may identify high-levelmanagement controls that are relevant to both operating andfinancial reporting objectives. If these higher-level controlsare sufficiently sensitive to prevent or detect errors ofimportance for one or more assertions, the project teammay identify and evaluate them. An example of a higher-level control is a reconciliation of quantities shipped perthe shipping log to quantities billed per the sales journal.

While higher-level controls may be present, the projectteam should not focus solely on such controls because they generally are dependent on controls over processes or activities at the transaction level. The project team alsoshould understand processes or activities at the transactionlevel in order to identify and understand controls that addressall relevant assertions. The project team’s conclusions aboutthe effectiveness of the related controls may be based on acombination of higher-level controls and controls at thetransaction level.

Types of ControlsControls may relate to any of the five components of internalcontrol (i.e., the control environment, risk assessmentprocess, information and communication, control activities,and monitoring) provided the controls are relevant to thepoints at which errors or fraud can occur and are likely tobe effective in reducing the risk of error or fraud. Controlsthat management relies on to prevent or detect and correcterrors, or to prevent or detect fraud, may exist in any of thefive components. The project team should identify anddocument relevant controls in each of the five components.

Two broad types of controls and their description are listedbelow.

Control Types DescriptionPrevent Controls Procedures designed to prevent an error or

fraud. Prevent controls are normally applied at a single transaction level.

Detect Controls Policies and procedures that are designed to monitor the achievement of the relevantprocess objectives, including identifying errorsor fraud. Detect controls can be applied togroups of transactions.

The project team should keep in mind that, to be effective,systems of internal control often have to include strongprevent controls in addition to detect controls. For example,where there is a high volume of transactions, the lack ofprevent controls significantly increases the risk of errors andaccordingly increases the need for particularly sensitivedetect controls. In the absence of prevent controls, a highnumber of errors can render detect controls ineffective indetecting and correcting errors in a timely manner.

The categorization of a control by the project team maydepend on how and for what purpose it is used, and the wayin which the project team views it. Ultimately, what mattersis not the categorization but whether the control is effectivein reducing the risk of errors of importance or fraud.

Prevent and detect controls can reside both within andoutside of computerized environments. Within thecomputerized environment, prevent and detect controls areoften referred to collectively as “programmed or applicationcontrols” in that their implementation and ongoingeffectiveness depends on the consistent application of anembedded software program/application or “routine” totransactions processed by that application. Programmedcontrols usually are either programmed control procedures(e.g., edit, matching, or reconciliation routines) or computerprocesses (e.g., calculations, on-line entries, automaticinterfaces between systems). Identifying controls frequentlywill require collaboration with both process owners and IT personnel.

If the project team determines that management is relyingon programmed controls or that identified controls aredependent on IT-generated data (i.e., electronic evidence),it should ask a second question: “What ensures thatprogrammed controls are operating effectively?” Theresponse may be that (1) user procedures verify the accuracyof the processing (e.g., manually recompute complexcalculations or reconcile IT reports to manual batch totals)and/or (2) management relies on the IT system to effectivelyexecute the control or produce the data. When (2) is theresponse, the project team should consider the effect of ITgeneral controls in evaluating the effectiveness of controlsthat are dependent on the IT system or IT-generated data.

IT general controls are IT processes and related controlsthat generally are applied above the computer applicationlevel; however, they may be performed on a singleplatform for a single application. IT general controls, or ITprocess controls, are designed to:

1 Ensure that changes to applications are properlyauthorized, tested, and approved before they areimplemented, and

1 Ensure that only authorized persons and applications have access to data, and then only to perform specificallydefined functions (e.g., inquire, execute, update).

We anticipate that, except in certain rare instances, projectteams will find it necessary to document IT generalcontrols. Many prevent controls are programmed controlsresiding in computer applications, and detect controls oftenrely on information produced by computers. Therefore, thedocumentation and evaluation of IT general controls isimportant because those controls provide a basis forconcluding that prevent controls residing in computerapplications continue to function over time and provide, in part, a basis to rely on the output from computerizedapplications (i.e., electronic evidence) used in theperformance of detect controls.

Most prevent controls residing in computer applicationsshould have been tested prior to implementation. If this is thecase and the earlier tests results were retained (and ITgeneral controls prove to be effective), project teamsgenerally will be able to document the prevent controlswithout extensive additional effort.

Considerations for Documenting Controls The project team should document the controls the company/reporting unit has established that are responsive to the“what can go wrong” questions. Information obtained asthe project team identifies where errors can occur and therelevant controls should be supplemented, as necessary, bymemoranda, notes, and copies of related documentation.

Generally, documentation of the controls over significantapplications and transactions is sufficient when it:

1 Specifies “what can go wrong” in the processing streamand thus where controls are needed



21

1 Describes the relevant prevent and detect controls thatare responsive to each “what can go wrong” question

1 States who performs the controls

The project team’s documentation of controls should provideevidence that appropriate controls have been established andare effectively designed to prevent or detect errors ofimportance or fraud. We recommend the documentationinclude a description of each control, including how thecontrol is performed, who performs the control, what datareports, files, or other materials are used in performing thecontrol, and what physical evidence, if any, is produced asa result of performing the control. This documentation willbe helpful in subsequent phases of the process, particularly indesigning procedures to verify the operating effectiveness ofthose controls. In addition, this documentation will beuseful in:

1 Identifying whether controls have changed over time

1 Identifying situations where there is a potential lack ofsegregation of duties

1 Considering whether controls have been designed sothat they are not easily overridden and, if they areoverridden, whether policies and programs (e.g., fraudprograms) exist to detect and report such overrides

Ernst & Young has developed an Illustrative DocumentationTemplate in Microsoft Access® to illustrate the steps todocument internal controls that a company/reporting unit hasestablished that are responsive to the “what can go wrong”questions. Companies can use the template as a guide indesigning their approach to documenting internal control atthe process, transaction, or application level. Smallercompanies or companies with a non-complex organizationalstructure may elect to use the template as provided. However,Ernst &Young does not intend to support the template orrelated software. You may obtain an electronic copy of thetemplate, free of charge, by contacting your Ernst & Youngengagement team or a local Ernst & Young representative.

Perform Walk-Throughs to Confirm Understanding of Process and Controls We recommend that project teams walk through eachprocess, from the point at which the major classes oftransactions are initiated to the end of the recording

process, to confirm (1) the understanding of the processingprocedures, (2) the correctness of the information obtainedabout the relevant prevent and/or detect controls in theprocess, and (3) that these controls have, in fact, been placedin operation. For non-routine and estimation transactions,generally the project team can gain an understanding of thetransaction, identify and understand controls, and conductwalk-throughs simultaneously.

A walk-through normally is performed using documents thatthe project team believes are typical of the process beingreviewed. We recommend performing a walk-through for atleast one transaction within each major class of transactionspreviously identified, unless additional walk-throughs areneeded to confirm the project team’s understanding. Whenthere have been significant changes in the process and/or thesupporting computer applications during the period underevaluation, the project team should consider the need to walkthrough transactions that were processed both before andafter the change. The need to do this depends on the natureof the change and how it affects the likelihood of errors ofimportance or fraud in the related accounts.

During the walk-through, the project team should questionpersonnel at each point where important processing controlsor procedures are prescribed (i.e., those most relevant to theaccuracy of the financial statements). The questions shouldfocus on their understanding of what is required and whetherthe processing procedures and controls are performed on aregular basis.

The project team also may attempt to corroborateinformation obtained at various points in the walk-throughby asking personnel to describe their understanding of theprevious and succeeding processing or control activitiesand to demonstrate what they do. Furthermore, during thewalk-through we recommend attempting to identifyexceptions to the prescribed processing procedures and thecontrols and any differences between what the project teamunderstands is required and what is actually done.

If the control is an employee review, and the employee isrequired to initial a document as evidence of havingreviewed it, we recommend inquiring about the nature ofthe review performed and ascertaining whether thedocuments subject to the walk-through have been initialed



by an appropriate employee. Furthermore, we recommendasking what the person does if the review process revealsan error or other discrepancy in the document, and ifappropriate, examining documents where problems weredetected to confirm that appropriate actions were taken.

If the control consists of the preparation and analysis of aperiodic reconciliation, we recommend:

1 Reviewing one or more of the reconciliations todetermine whether all the relevant data are accuratelyand promptly included

1 Noting the disposition of any unusual items

1 Inquiring about the actions taken when thereconciliation reveals actual or potential errors

1 Inquiring how the errors occurred

1 Whenever practicable, obtaining evidence of thecorrection of the errors that were noted during thereconciliation process

1 Determining whether the reconciliation is performed byor relies on information processed by a computersystem. If the reconciliation relies on an automatedprocess, the project team should consider the results ofprocedures it performed related to IT general controls.

In addition to following the physical flow of documents andforms, the project team also should follow the flow of dataand file information through the automated processes (at asystem level, not a detailed logic level). These proceduresmay include inquiry of independent and knowledgeablepersonnel, review of user manuals, observation of a userprocessing transactions at a terminal in the case of an on-line application, and review of documentation such asoutput reports.

Perform Walk-Throughs of IT General ControlsIT general controls are designed to (1) ensure that changesto applications are properly authorized, tested, and approvedbefore they are implemented, and (2) ensure that onlyauthorized persons and applications have access to data,and then only to perform specifically defined functions(e.g., inquire, execute, update). Appendix C provides alisting of common IT general controls over programacquisition, implementation and maintenance and overaccess to IT resources.

The project team should perform walk-throughs of the ITgeneral controls (or equivalent procedures) to confirm itsunderstanding of their design and determine that they havebeen placed in operation. In addition, the project team alsoshould obtain some evidence about whether the controls areoperating as designed. The means of gathering evidence duringthe walk-throughs or equivalent procedures may include:

1 Inquiring of various personnel to corroborate theunderstanding obtained from the IT process owner

1 Selecting an item over which the controls are designedto operate (e.g., a request for a program change) andinspecting evidence of the operation of the controls onthat item. Some controls may leave no evidence of theiroperation (e.g., meetings with IT personnel and users todiscuss user needs or approve the design of controls). Theproject team will need to use its judgment to determinethe adequacy of the evidence in such situations.

1 Examining documentation of the control’s design

1 Examining reports of key performance indicators orother information that is used to monitor the controls

1 Observing whether the IT process owner or others actupon the results of the controls

Considerations for Documenting Walk-ThroughsWalk-throughs of processes and the related controlsgenerally are documented in brief memos describing theprocedures the project team performed to confirm itsunderstanding of the process design and the relatedcontrols and whether they have been placed in operation.

Controls Residing Outside the CompanyBecause companies often use service organizations to hold assets, execute transactions and maintain relatedaccountability, or record transactions and process relateddata, the project team may identify parts of the processand/or controls related to significant accounts or groups ofaccounts that are performed by service organizations. Theproject team should first determine whether the companyhas implemented effective internal control over theprocessing performed by the service organization. Insituations where this is the case, the project team may notneed to gain an understanding of the flow of the transactions

23

or the controls at the service organization because thecompany has the ability to, and has, placed effective controlsin operation (e.g., comparison of input to output).

When the company is unable to place into operation effectivecontrols over the service organization’s activities, the projectteam likely will need to gain an understanding of the flow oftransactions and the controls at the service organization, aswell as at the company. The project team should obtain, read,and evaluate an appropriate service auditor’s report (i.e., SAS70 report) that describes the service organization’s processes,identifies the related controls, including describing tests of their operating effectiveness performed by the serviceauditor, and specifies the period covered by the report. Theproject team should document its conclusions as to how the controls at the service organization support the relevantfinancial statement assertions (similar to how it documentsother controls).

Finalizing the Documentation of ControlsAs the project team finalizes its documentation ofcontrols identified over a specific process, it needs todetermine whether:

(1) All significant risks identified as “what can go wrong”questions are addressed by one or more of theidentified controls, and

(2) The controls that address the identified risks areadequately designed to prevent or detect errors ofimportance or fraud.

The project team should be mindful that it is common thatsome controls can address more than one risk. For somerisks, the project team may find it necessary to identifymore than one control to conclude that the controls, in theaggregate, are adequately designed to address the risks oferrors identified.

Appendix B provides example documentation of the “whatcould go wrong” questions and controls related to the cashdisbursements process for a medium-sized manufacturingcompany. This example control documentation assumesthat appropriate documentation also has been prepared ofthe flows of transactions through the cash disbursementsprocess (i.e., how transactions are initiated, recorded,processed, and reported). As illustrated in the example,several of the controls identified address, at least in part,

more than one risk as defined by the “what can go wrong”questions. Similarly, it was necessary in the example toidentify more than one control to address several of theindividual risks identified.

The project team will need to follow up to ensureappropriate corrective action is taken when it is unable toconclude that the design of identified controls providesreasonable assurance that errors of importance or fraudwill not be prevented or detected on a timely basis.

Company Policies and Procedures RegardingAuthorization, Safeguarding of Assets, and Asset AccountabilityIn addition to considering controls over specific processes,the project team also should consider company policies andprocedures regarding authorization, safeguarding of assets,and asset accountability. These policies and proceduresprovide reasonable assurance that:

1 Assets are acquired, safeguarded, and used, and thatliabilities are incurred and discharged, in accordancewith management authorization

1 Financial information is accurately maintained in thebooks and records with respect to assets and liabilitiesresulting from such decisions

These policies and procedures relate primarily tomanagement’s control over the disposition of the company’sassets and liabilities and only indirectly to controls over theprocessing of data, which are concerned with the accurate,timely, and complete recording of transactions. However,the absence of such policies and procedures may increasethe risk of errors of importance or fraud. For example, assetaccountability procedures frequently take the form ofaccount reconciliations or other detect controls. The absenceof, or weaknesses in, such procedures may influence theproject team’s evaluation of controls over processes.

The project team should assess the extent to which anysignificant weaknesses in management’s authorization,asset safeguarding, and asset accountability procedurescould increase the likelihood of errors of importance inaccount balances. In making this assessment, the projectteam should consider the materiality of the assets concernedand their susceptibility to physical loss or loss in valuethrough errors or fraud.


NE X T ST E P S









BalanceSheet



SignificantAccounts


What CanGo Wrong?

Controls

Evaluate/Monitor

Report


?









Next Steps{

25

The completion of the documentation

of internal control at the entity level

and internal controls at the process,

transaction, or application level will provide

the project team with information necessary to

evaluate the overall effectiveness of controls in

the final phase of the methodology.

In the final phase, the project team will determine that thecontrols identified are functioning as designed. Additionalinformation about evaluating the overall effectiveness ofinternal control, including procedures for determining thatcontrols are functioning as designed, identifying matters forimprovement, and evaluating processes to monitor the systemof internal control, will be provided in a future publication.

Next Steps


Cash Disbursements Routine ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Maintain Policy Master File Routine ✖ ✖ ✖

Premiums and Commissions Routine ✖ ✖ ✖

Develop/Monitor Deferred Acquisition Costs Assumptions Estimation/Routine ✖

Investments—Purchase and Sell Routine ✖ ✖

Manage Derivatives and Hedges Estimation ✖


Cash Receipts Routine ✖ ✖ ✖ ✖

Payroll Routine ✖ ✖

Claims and Benefits Routine ✖

Claim and Collect Reinsurance Non-Routine ✖

Develop/Monitor Reserve Estimates Estimation/Routine ✖

Investments—Recognize Income, Gain and Loss Estimation/Routine ✖ ✖

Assess Assets for Impairment Estimation ✖

Estimate Commitments and Contingencies Estimation ✖



Life and Health Insurance

Cash

and

Cash

Equiv

alent

sInv

estm

ent a

ndRe

lated

Incom

e,Ga

insan

dLo

sses

Defe

rred

Polic

y Acq

uisiti

onCo

sts

and

Amor

tizat

ion

Reins

uran

ceSe

para

teAc

coun

t Ass

ets/

Liabi

lities

Bene

fit/C

laim

Rese

rves

and

Relat

edEx

pens

es

Unea

rned

Prem

iumRe

serv

eInc

ome T

axes

(Cur

rent

, Def

erre

d)an

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Prem

iums

and

Relat

edRe

ceiva

bles

Fees

and

Com

miss

ions

Oper

ating

/Und

erwr

iting

/Gen

eral

Expe

nses

Appendix A — Example SignificantAccounts and Processes for SelectedIndustries

27


AP P E N D I X A — EX A M P L E SI G N I F I C A N T

AC C O U N T S A N D PRO C E S S E S F O R

SE L E C T E D IN D U S T R I E S


Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Payroll Routine ✖ ✖ ✖ ✖



Sales and Accounts Receivable Routine ✖






Depreciate Property, Plant and Equipment Non-Routine ✖ ✖

Estimate Commitments and Contingencies Estimation ✖ ✖




Estimate Warranty Reserve and Expense Estimation ✖ ✖

Lower of Cost or Market Calculation Estimation ✖






Manufacturing

Cash

and

Cash

Equiv

alent

sAc

coun

tsRe

ceiva

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Allow

ance

for D

oubt

ful A

ccou

nts

and

Bad

Debt

Expe

nse

Inven

torie

san

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Inven

tory

Rese

rves

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Prep

aids,

Othe

r Cur

rent

Asse

tsan

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Prop

erty,

Plan

t and

Equip

men

t and

Depr

eciat

ionEx

pens

e

Intan

gible

Asse

tsan

dRe

lated

Amor

tizat

ion

Acco

unts

Paya

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Accr

ued

Liabi

lities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Debt

and

Relat

edInt

eres

t Exp

ense

Pens

ion,

OPEB

san

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Stoc

khold

ers’

Equit

y and

Stoc

k Com

pens

atio

nEx

pens

e

Payro

ll Exp

ense

and

Relat

edAc

crue

dLia

bilit

ies

29


Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖


Capitalization and Amortization of Deferred Acquisition Costs Estimation/Routine ✖

Claims Payment Routine ✖ ✖

Premium and Commission Routine ✖ ✖ ✖ ✖ ✖ ✖

Calculate Loss Reserve Balances Non-Routine ✖

Contingent Premium/Commission Accruals Non-Routine ✖ ✖ ✖

Underwriting Routine ✖

Investments—Purchase and Sell Routine ✖

Investments—Recognize Income, Gain and Loss Routine ✖

Manage Derivatives and Hedges Estimation ✖

Investments Valuation Estimation/Routine ✖

Reinsurance Estimation ✖ ✖






Property and Casualty Insurance

Cash

and

Cash

Equiv

alent

sInv

estm

ents

and

Relat

edInc

ome,

Gains

and

Loss

es

Prem

iumRe

ceiva

bles/

Agen

tsBa

lance

s

Reins

uran

ceBa

lance

sDe

ferre

dPo

licy A

cquis

ition

Cost

san

dAm

ortiz

atio

n

Loss

Adjus

tmen

t Exp

ense

Rese

rves

and

Relat

edEx

pens

e

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Unea

rned

Prem

iumRe

serv

esCo

mm

itmen

ts, C

ontin

genc

iesan

dRe

lated

Expe

nse

Prem

iumInc

ome

Fees

and

Com

miss

ions

Unde

rwrit

ingan

dGe

nera

l Exp

ense

san

dRe

lated

Liabi

lities

Payro

ll Exp

ense

and

Relat

edAc

crua

ls





Cash Disbursements Routine ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Purchase and Pay for Assets and Non-Interest Expense Routine ✖ ✖

Treasury/Investment Securities-Transaction Execution Routine ✖ ✖ ✖

Operations—Clearing and Settlement Routine ✖ ✖ ✖ ✖

Operations—Electronic Funds Transfers Routine ✖ ✖ ✖ ✖

Calculate Amortization Non-Routine ✖


Cash Receipts Routine ✖ ✖


Treasury/Investment Securities-Valuation and Income Recognition Routine ✖ ✖

Operations—Deposits, Withdrawals, Fee Income and Interest Expense Routine ✖ ✖

Credit Origination, Transaction Processing and Income Recognition Routine ✖ ✖

Investments in Affiliates/Joint Ventures Non-Routine ✖


Calculate Depreciation Non-Routine ✖



Estimate Allowance for Credit Losses Estimation ✖

Manage Derivatives and Hedging Non-Routine ✖ ✖ ✖



Banks and Savings Institutions

Cash

and

Due

From

Bank

sInv

estm

ent S

ecur

ities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Cred

itFa

ciliti

esan

dRe

lated

Inter

est/

Incom

e

Allow

ance

and

Relat

edPr

ovisi

onfo

r Cre

dit L

osse

s

Othe

r Ass

ets

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Depo

sits,

Fee

Incom

ean

dRe

lated

Expe

nse

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Othe

r Liab

ilities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Borro

wing

san

dRe

lated

Inter

est E

xpen

se

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Stoc

khold

ers’

Equit

yPa

yroll E

xpen

sean

dRe

lated

Accr

ued

Liabi

lities

31


Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖


Record Rental Income Routine ✖

Purchase and Pay for Assets and Expenses Routine ✖ ✖ ✖ ✖ ✖ ✖

Acquire and Dispose of Real Estate Non-Routine ✖ ✖ ✖ ✖ ✖ ✖

Assess Assets for Impairment Estimation ✖ ✖ ✖ ✖ ✖ ✖ ✖

Calculate Accrued Liabilities Non-Routine ✖

Calculate Common Area Maintenance/Recoveries Non-Routine ✖

Calculate Deferred Leasing Costs and Other Prepaid Expenses Non-Routine ✖ ✖

Calculate Depreciation and Amortization Non-Routine ✖ ✖ ✖ ✖


Calculate Straight-Line and Percentage Rents Non-Routine ✖

Capitalized Construction Costs (Including Interest, Overhead, and Taxes) Non-Routine ✖ ✖

Equity Allocations Non-Routine ✖


Estimate Uncollectible Receivables (Tenant and Other) Estimation ✖

Investments in Affiliates/Joint Ventures Non-Routine ✖ ✖


Report on Debt Covenant Compliance Non-Routine ✖



Commercial and Multifamily Real Estate

Allow

ance

for D

oubt

ful A

ccou

nts

and

Bad

Debt

Expe

nse

Cash

and

Cash

Equiv

alent

s

Othe

r Inv

estm

ents

(Inclu

ding

Equit

y Inv

estm

ents

) and

Othe

r Inc

ome/

Expe

nse

Inves

tmen

t In

and

Adva

nces

toPa

rtner

ship

s,JV

san

dEq

uity i

nEa

rning

s

Defe

rred

Char

ges

and

Relat

edAm

ortiz

atio

n

Deve

lopm

ent P

rope

rties

Real

Esta

teInv

estm

ents

and

Depr

eciat

ionEx

pens

e

Intan

gible

Asse

tsan

dRe

lated

Amor

tizat

ion

Acco

unts

Paya

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Accr

ued

Liabi

lities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Mortg

ages

/Not

esPa

yable

and

Relat

edInt

eres

t Exp

ense

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Shar

ehold

ers’

Equit

yPa

yroll E

xpen

sean

dRe

lated

Accr

ued

Liabi

lities

Gain/

Loss

onSa

leof

Real

Esta

te

Rece

ivable

s (Te

nant

, Esc

rows

, Con

tract

, Ret

ainag

e, Un

bille

d Co

sts,

Othe

r)

and

Relat

ed In

com

e St

atem

ent A

ctivi

tyPr

epaid

Expe

nses

, Def

erre

d Le

asing

Cos

ts a

nd O

ther

Cur

rent

Asse

ts

and

Relat

ed In

com

e St

atem

ent A

ctivi

ty






Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖




Sales and Cash Audit Routine ✖ ✖

Retail Price Change Process Routine ✖

Retail Stock Ledger Process Routine ✖



Account for Vendor Chargebacks Routine ✖ ✖ ✖

Account for Vendor Support Estimation/Non-Routine ✖ ✖ ✖




Calculate Accrued Liabilities Non-Routine ✖

Depreciate Property and Equipment Non-Routine ✖


Estimate Excess and Obsolete Inventory Estimation ✖

Estimate Inventory Shrink Reserve and Expense Estimation ✖


Estimate Self-Insurance Reserve Estimation ✖

Estimate Closed Store Reserve and Expense Estimation ✖






Retail

Vend

orSu

ppor

t Rec

eivab

lean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Allow

ance

for D

oubt

ful A

ccou

nts

and

Bad

Debt

Expe

nse

Acco

unts

Rece

ivable

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Cash

and

Cash

Equiv

alent

s

Inven

torie

san

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Inven

tory

Rese

rves

and

Relat

edEx

pens

e

Inven

tory

Shrin

k Res

erve

and

Relat

edEx

pens

e

Prep

aids,

Othe

r Cur

rent

Asse

tsan

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Prop

erty,

Plan

t and

Equip

men

t and

Depr

eciat

ionEx

pens

e

Intan

gibles

, Oth

erAs

sets

and

Relat

edAm

ortiz

atio

n

Acco

unts

Paya

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Accr

ued

Liabi

lities

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Clos

edSt

ore

Rese

rve

and

Relat

edEx

pens

e

Self-

Insur

ance

Rese

rve

and

Relat

edEx

pens

e

Debt

and

Relat

edInt

eres

t Exp

ense

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Stoc

khold

ers’

Equit

y and

Stoc

k Com

pens

atio

nEx

pens

e

Payro

ll Exp

ense

and

Relat

edAc

crue

dLia

bilit

ies

33


Cash Disbursements Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Financial Statement Close Non-Routine ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖

Payroll Routine ✖ ✖ ✖

Purchase and Pay for Assets and Expenses Routine ✖ ✖ ✖ ✖ ✖

Bill and Collect for Sales Routine ✖

Billing Adjustments Routine ✖

Cost and Record Inventory/Sales Routine ✖

Account for Marketable Securities Non-Routine ✖ ✖


Capitalize and Amortize Software Development Costs Non-Routine ✖

Amortize Prepaid and Intangible Assets Non-Routine ✖ ✖ ✖

Assess Assets for Impairment Estimation ✖ ✖ ✖ ✖


Depreciate Property and Equipment Non-Routine ✖



Estimate Reserve for Restructuring Expense Estimation ✖


Estimate Warranty and Returns Reserves Estimation ✖ ✖

Defer and Recognize Revenue Non-Routine ✖

Account for Business Combinations Non-Routine ✖





Technology & Communications

Inven

tory

Rese

rves

and

Relat

edEx

pens

e

Inven

torie

san

dCo

stof

Sales

Allow

ance

for D

oubt

ful A

ccou

nts

and

Bad

Debt

Expe

nse

Sales

and

Acco

unts

Rece

ivable

Mark

etab

leSe

curit

iesan

dRe

lated

I/SAc

tivity

Cash

and

Cash

Equiv

alent

s

Prep

aidEx

pens

esan

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Defe

rred

Char

ges

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Capi

taliz

edSo

ftwar

ean

dRe

lated

Amor

tizat

ion

Prop

erty,

Plan

t and

Equip

men

t and

Relat

edDe

prec

iatio

n

Intan

gible

Asse

tsan

dRe

lated

Amor

tizat

ion

Acco

unts

Paya

blean

dRe

lated

Incom

eSt

atem

ent A

ctivi

ty

Incom

e Tax

es(C

urre

nt, D

efer

red)

and

Relat

edInc

ome

Stat

emen

t Act

ivity

Payro

ll Exp

ense

and

Relat

edAc

crua

ls

Defe

rred

Reve

nue

and

Relat

edInc

ome

Line

Cost

san

dRe

lated

Accr

uals

Accr

ued

and

Expe

nsed

Rest

ruct

uring

Cost

s

Warra

nty R

eser

ves

and

Relat

edEx

pens

e

Debt

and

Relat

edInt

eres

t Exp

ense

Com

mitm

ents

, Con

tinge

ncies

and

Relat

edEx

pens

e

Stoc

khold

ers’

Equit

y and

Stoc

k Com

pens

atio

nEx

pens

e


AP P E N D I X B — EX A M P L E RI S K A N D

CO N T RO L DO C U M E N TAT I O N F O R CA S H

DI S BU R S E M E N T S PRO C E S S

Appendix B — Example Risk andControl Documentation for CashDisbursements Process

Example Controls

Example “What Can Go Wrong” Questions Assertion

Consider “What Can Go Wrong” Questions and Identify Controls

Vend

orco

mpl

aint

sto

purc

hasi

ngde

part

men

t are

mon

itore

d

Vend

orst

atem

ents

reco

ncile

dto

acco

unts

paya

ble

deta

il

Disb

urse

men

t req

uisi

tions

for n

on-tr

ade

paya

bles

are

revie

wed

Acco

unts

paya

ble

subl

edge

r/agi

ngis

revie

wed

and

reco

ncile

dto

gene

ral l

edge

r

Appr

oval

requ

ired

for c

hang

esto

vend

orm

aste

r file

s

Bank

reco

ncili

atio

nspr

epar

edan

dre

viewe

don

atim

ely

basi

s

Syst

emm

atch

esPO

, rec

eivin

gre

port

, and

invo

ice

(3-w

aym

atch

)

Syst

empr

esen

tsin

voic

efo

r pay

men

t onl

yaf

ter 3

-way

mat

ch

Syst

emon

lyal

lows

paym

ent o

f inv

oice

once

Disb

urse

men

tsgr

eate

r tha

nsp

ecifi

edam

ount

sre

quire

addi

tiona

l app

rova

l

Syst

em a

utom

atic

ally

write

s ch

ecks

and

/or p

roce

sses

ele

ctro

nic

paym

ents

bas

ed o

n va

lue

of a

ppro

ved

invo

ices

What ensures that cash disbursements/transfers are recorded in the proper period? Completeness ✖

What ensures that duplicate postings of cash disbursements are not made to the general ledger? Occurrence ✖ ✖

What ensures that cash disbursements are correctly coded? Completeness ✖ ✖ ✖ ✖ ✖

What ensures that cash disbursements are real? Existence/Occurrence ✖ ✖ ✖ ✖ ✖

What ensures that all cash disbursements are recorded? Completeness ✖

What ensures that cash disbursement amounts recorded agree with amounts paid? Valuation/Measurement ✖ ✖ ✖ ✖

Process: Cash Disbursements

Transaction Type: Routine

Example Significant Accounts Affected:Cash and Cash EquivalentsAccounts Payable and ExpensesAccrued Liabilities and ExpensesDebt and Related Interest ExpensePension, OPEBs and Related ExpenseCommitments, Contingencies and Related Expense

35

Vendor statements reconciled to accounts payable detail Detect AP Clerks Yes Yes Effective

Electronic Evidence

Disbursement requisitions for non-trade payables are reviewed Detect Department Head No N/A Effective

Vendor complaints to purchasing department are monitored Detect AP Clerks No N/A Effective

Accounts payable subledger/aging is reviewed and Detect AP Supervisor Yes Yes Effectivereconciled to general ledger Electronic Evidence

Approval required for changes to vendor master files Prevent Accounting No N/A Effective

Bank reconciliations prepared and reviewed on a timely basis Detect Treasury Clerk No N/A Effective

System matches PO, receiving reports, and invoice (3-way match) Prevent System Yes Yes EffectiveProgrammed Control

System presents invoice for payment only after 3-way match Prevent System Yes Yes EffectiveProgrammed Control

System only allows payment of invoice once Prevent System Yes Yes EffectiveProgrammed Control

System automatically writes checks and/or processes electronic Prevent System Yes Yes Effectivepayments based on value of approved invoices Programmed Control

Disbursements greater than specified amounts require Prevent CFO No N/A Effectiveadditional approval

Control Documentation

Example Controls

Eval

uatio

n

ITGe

nera

l Con

trols

Eval

uate

d?

Cont

rol D

epen

dent

onIT

?

Who

Perfo

rms?

Cont

rol T

ype

Document Controls

This example control documentation assumes that appropriate documentation also hasbeen prepared of the flows of transactions through the cash disbursements process (i.e., how transactions are initiated, recorded, processed, and reported).


AP P E N D I X C — CO M M O N IT GE N E R A L CO N T RO L S

IT Program Acquisition, Implementation andMaintenance ControlsBelow is a listing of common controls over IT programacquisition, implementation and maintenance.

1 Formal policies and procedures are in place that define anapproach to systems acquisition and change management(e.g., a formal systems development methodology)

1 User department and IT department managementapproval is required before systems acquisition andchange projects are undertaken

1 The IT department maintains project documentation,including systems requirements definitions, riskanalyses, and cost-benefit analyses

1 A mechanism is in place to periodically review serviceorganization operational and control effectiveness

1 The systems acquisition and change approach addressessecurity risks

1 The systems acquisition and change approach addressesdata conversion

1 Environments for development (or modification) andtesting of IT solutions are separated (either logical orphysical) from production systems

1 Management reviews and approves IT solutions prior totheir implementation

1 Users are actively involved in the test process

1 Development personnel are prohibited from migratingapplications and data from the test environment toproduction

1 Post-implementation review procedures are performedfor system modifications made during an emergency

IT Access ControlsBelow is a listing of common controls over access to ITresources.

1 Formal policies and procedures are in place that definean approach to system security (includingconfidentiality of data and information)

1 A mechanism is in place for communicating securitypolicies to employees (e.g., requiring users to sign anacknowledgement that they have read and understoodthe company’s security policies)

1 A security organization exists that is independent of boththe user departments and other IT department functions

1 IT department personnel do not have operational oraccounting responsibilities

1 Appropriate user department and IT departmentmanagement control access to the following:

—Local and wide area networks

—Remote connection to networks and/or applications

—Internet/intranet sites

—Applications and application modules

1 The following user account security parameters are inplace:

—Users are assigned unique user IDs

—Adequate passwords are required (e.g., minimum andmaximum password length, at least one alpha andone numeric character)

—User created passwords (e.g., passwords are notassigned)

—Periodic password changes are required

Appendix C — Common ITGeneral ControlsListed below are illustrative IT general controls to guide project teams in identifying significant IT general controls intheir companies. These lists are not all-inclusive, and each project team will need to consider the unique IT environmentof its company.

37

—User accounts are disabled after a limited number ofunsuccessful logon attempts

—Users are limited to one session per account (e.g.,concurrent sessions or logons are not allowed)

—Measures are in place to prevent the repeated use of apassword

—Administrator rights are assigned to a limited numberof individuals who require those rights to performtheir job duties

1 Communications with public networks are controlled bya firewall. The firewall is implemented to:

—Hide the structure of the client’s network

—Provide an audit trail of communications with publicparties

—Generate alarms when suspicious activity issuspected

—Defend itself and/or the company’s network againstattack

1 Procedures for protection against malicious programsare in place through the use of anti-virus software andother measures (which may include policies limiting theinstallation of unapproved programs, procedures forreporting suspected occurrences of viruses, etc.)

1 Physical access to technology infrastructure is restricted

1 Access to internal networks and/or applications bysuppliers, customers, and/or other business partners isapproved by appropriate management and limited to thosenetworks and/or applications required to conduct business

1 Representatives of suppliers, customers, and/or otherbusiness partners are required to adhere to the client’spolicies, procedures, and security standards whenaccessing the client’s systems


AP P E N D I X D — EX A M P L E SE G R E G AT I O N

O F DU T I E S TE M P L AT E

Appendix D — Example Segregation ofDuties Template

Additional ConsiderationsIn instances where “computer” or “IT” has been listed as performing a function checked above, consider whether (1) theindividuals authorized to enter transactions or adjustments perform other incompatible duties and (2) whether there areprocedures to ensure that only authorized individuals have the capabilities to enter the transactions or adjustments.

In addition, when the “computer” or “IT” has been identified as performing potentially incompatible duties, considerwhether the segregation of duties within the IT department and/or other controls result in effective segregation of duties.

ConclusionHave any potentially conflicting duties been identified? YES NO

If potentially conflicting duties have been identified, note them and either (1) indicate their effects on our evaluation ofthe controls over the cash disbursements application and our assessment of the risk of fraud, or (2) indicate where in thedocumentation their effects are considered.

Controls the accuracy, completeness of, and access to cash disbursements programs and data files

Maintains accounts payable records

Maintains purchases journal

Approves voucher packages for payment

Matches invoices to purchase orders andreceiving reports

Reconciles bank accounts

Approves wire transfers

Initiates wire transfers

Maintains cash disbursements journal

Mails checks

Signs checks

Prepares checks

Maintains/controls checks and signature plate

Segregation of Duties in Significant Accounting Applications

CompanySubsidiary or DivisionDate

Cash Disbursements Application

Custody ControlAuthorization of assets Recording activity

© 2003 Ernst & Young LLP.

All Rights Reserved.

Ernst & Young is

a registered trademark.

SCORE Retrieval File

No. EE0692

www.ey.comER N S T & YO U N G LLP

Documents

Evaluating Internal Controls - SOXRightsoxright.com/downloads/EY2EvaluatingInternalControls.pdf · in evaluating internal controls. ... Transaction, or Application Level Significant