PM10-4, Application

Controls Concepts

Team Activity Support Materials

The following is a copy of the Application Controls White Paper finalized August 19,
2005.
Application Controls: A Practical Approach to Identification and Testing
I. Introduction
Application controls are an essential element of a well-designed internal control environment.
Given the importance of application controls, there is an increased interest in focusing on
identifying, walking through, and testing application controls to increase the quality and
effectiveness of our internal control assessment for an integrated audit as well as our financial
statement audits. Consequently, the purpose of this white paper is to establish a framework to
understanding and evaluating application controls. It is not the intention of this paper to
discuss IT-dependent manual controls (e.g., reporting, reconciliation, etc.).

RAS Core Skills III

PM10-4, Application Controls Concepts

Team Activity Support Materials

Ernst & Young Global Audit Methodology (EY GAM) Definition and Approach
Application controls are automated controls that apply to the processing of individual
transactions and include such controls as edit checks, validations, calculations, interfaces, and
authorizations. The purpose of such controls is to provide reasonable assurance that all
transactions are valid, properly authorized and recorded, and processed completely,
accurately, and on a timely basis. Application controls are characterized as either embedded
or configurable. These characterizations, coupled with the type of application control, are
important to consider as we perform our walk-throughs and determine the nature, timing, and
extent of our testing procedures.
See the diagram below for a classification of the internal control environment.

Manual
Manual
Controls
Controls

(Purely)
(Purely) Manual
Manual
Controls
Controls

Automated
Automated
Controls
Controls

IT-Dependent
Application
IT-Dependent
Manual
Controls
Manual Controls
Controls
Controls
1.
1. Embedded
Embedded Controls
Controls
2.
2. Configurable
Configurable Controls
Controls

IT General Controls

RAS Core Skills III

PM10-4, Application
Controls Concepts

Team Activity Support Materials

Application Control Characteristics
Embedded Control System is programmed to perform the control because of either
custom coding or packaged delivery of that functionality.
Configurable Control System has the capability to perform the control depending on its
setup but may have been configured differently; used especially in the context of ERP
systems.
Types of Application Controls

Edit Checks Controls to limit the risk of inappropriate input, processing, or output of
data due to field format (e.g., dollar amounts must be in the numeric format).

Validations Controls to limit the risk of inappropriate input, processing, or output of

data due to the confirmation of a test. Examples include tolerances, duplicate checks, and
matching (e.g., an automated three-way match, where a check to a supplier will not be
generated without a matched purchase order, receipt of goods, and invoice).

Calculations Controls to ensure that a computation is occurring accurately (e.g., the

system automatically extends and foots an invoice).

Interfaces Controls to limit the risk of inappropriate input, processing, or output of data
being exchanged from one system to another (e.g., the system confirms through a record
count that all records were uploaded from the sales sub-ledger to the general ledger or
confirms that totals from a header record reconcile to the detail that was posted).

Authorizations Controls to limit the risk of inappropriate input, processing, or output of

key financial data due to unauthorized access to key financial functions or data and
includes segregation of duties, authorization checks, limits and hierarchies (e.g., roles are
defined within the system so that only the purchasing manager has the ability to add
vendors to the vendor master).

Approach to the Identification and Testing of Application Controls

When we are identifying controls in an automated environment, often the most effective
approach is for the financial auditors to team with the IT specialist (often a member of the
TSRS practice). The financial auditor brings a knowledge and experience of the clients
business processes, risks (what can go wrongs), and key controls, while the IT specialist
brings knowledge and experience of how the IT systems may be configured and used to
support the business processes and controls. The IT specialist will help bring the knowledge
and experience necessary to identify application-specific risks and controls that are
responsive to those risks to help us optimize our audit strategy.
The IT specialist should work closely with the financial auditors to identify the relevant risks,
controls, and testing approach to either validate (especially if application-specific knowledge
is available) or co-develop the audit strategy as it relates to the identification and testing of
application controls.

RAS Core Skills III

PM10-4: Application
Controls Concepts
Once the population of application controls has been identified and those that we plan to test
are walked-through, the financial auditor and IT specialist should come to an agreement on
which application controls should be tested (i.e., in scope) and by whom. Testing application
controls may provide for a more effective and efficient audit, as a test of one of each
significant transaction type may suffice, provided we conclude that IT general controls
supporting the application are functioning effectively.
The testing strategy for application controls may utilize the following approach:

First, working together, the financial auditor and IT specialist should identify the
optimum combination of manual, application, and IT-dependent manual controls to
test. The testing should include appropriate controls to provide sufficient frequency,
sensitivity, and pervasiveness to cover the identified assertions and risks.

Second, an approach should be developed between the financial auditor and IT

specialist to determine how the specific application controls will be covered in our
walk-through of the business process/significant class of transactions. For example,
should the IT specialist be involved in the entire walk-through of the business
process/significant class of transactions or only a portion of the walk-through that
relates to the specific application controls under consideration?

Third, determine if the walk-through may suffice as a test of one or if additional

testing may need to be performed.

Finally, confirm the relevant ITGCs are effective for the relevant period. Testing
ITGCs is the most effective way to confirm that an application control has continued
to operate throughout the period. However, if ITGCs are deemed ineffective, it may
be possible to still evaluate application controls as effective if we are able to confirm
via other means that the control operated throughout the period (e.g., confirmation
that the configuration or program did not change or testing 25 of each application
control).

III. Nature of Application Control Testing

The nature of a test of an application control is dependent upon whether it is embedded or
configurable. Generally, for a configurable control we would inspect the configuration for
each significant transaction type and determine that the control is configured appropriately,
while considering the ability to override that control. Likewise, in general for an embedded
control, we would walk through each significant transaction type and determine that the
control is operating appropriately, while considering the ability to override that control. As
part of our walk through and/or testing procedures, we need to understand the ability of
process owners to override a control, independent of whether an embedded or configurable
control. The ability to override a control may affect the operating effectiveness of the control,
therefore altering the extent of testing or reliance.
The nature of application control tests includes the following:

Inspect configuration System is configured to process a transaction in a certain manner

(e.g., the system places an invoice on hold if a purchase price variance exceeds a

RAS Core Skills III

PM10-4, Application
Controls Concepts

Team Activity Support Materials

configured threshold). This configuration can usually be viewed within a configuration
screen on the system or via a system-generated report.
o Manual Override We also should determine the ability of a system user to
manually override a system configuration in order to allow a transaction to be
processed in a certain manner, which is usually different from how the system
might normally process a particular transaction and includes understanding where
the override takes place in the process to understand the impact on the controls
earlier in the process. This determination usually requires a baseline knowledge of
the application and the overrides that it allows. For instance, within the Oracle
Financials application, credit limits are defined at the Profile Class level but can
be overridden at the customer record.

Re-performance via a walk-through of each significant transaction type and processing

alternative A technique to test how a significant transaction is processed based on the
system programming (embedded) or configuration. The walk-through needs to represent
each transaction type and processing alternative and demonstrate the operating
effectiveness of the control, confirming the control both prevents and allows what it
should (e.g., if the invoice dollar tolerance is set to 5 percent, confirm that the system
prevents invoices with a greater than 5 percent variance from being paid and allows those
with less than a 5 percent variance to be paid).
o Manual Override We also should determine the ability of a system user to
manually override a system program (embedded) or configuration in order to
allow a transaction to be processed in a certain manner, which is usually different
from how the system might normally process a particular transaction. This usually
requires a baseline knowledge of the application and the overrides that it allows.
For instance, within a particular application a user may be prevented from posting
an unbalanced journal entry, but that user knows that by pushing a particular
sequence of keys that he or she can force the posting.

Inspection of authorizations and re-performance to confirm that the way the system is
programmed and configured to restrict access to those that are programmed or configured
to have it and that the configuration and programming does work An evaluation by the
auditors of whether the privileges assigned to a particular system user are commensurate
with the users job responsibilities and whether those responsibilities support the control
environment. (Note: the objective of our logical access testing as part of IT general
controls is to confirm there are adequate controls in place around adding, updating,
deleting, and restricting user access to key financial data and that access to that data is
appropriately restricted at the operating system and database levels. We are typically
unable to conclude specifically on whether access to key accounting functions allowed by
the financial applications is appropriately restricted or segregated. Instead, we would
perform specific testing on that access or segregation of that access as part of application
controls testing.)

The techniques to test application controls vary based on the type of control being tested (the
assumption is that a walk-through has been completed). The table below shows the
relationship between the different types of application controls and the techniques that can be
used by an auditor to test such controls.
RAS Core Skills III

PM10-4: Application
Controls Concepts

Configurable

dEmbedde

Edit
Re-performance
via walkthrough

Type of Application Control

Validation Calculation Interface
1

Authorization

1
2

Inspection of
authorization
Inspected

Re-performance
via walkthrough

1
2

Inspection of
authorization

Overrides Override capability typically requires special authorization or security rights;

therefore, our authorization control testing should include the key override capabilities.
Dependencies Some application controls may be dependent upon the operation of others.
For instance, the three-way match is dependent on both the application forcing the match as
well as adequate segregation of duties ensuring that no one individual has the ability to
approve a purchase order, enter a receipt, and enter an invoice. It is therefore critical that we
understand each of these dependencies.
IV. Timing
There is no requirement that our detailed tests of controls cover a specific period of time
(e.g., four months, six months, or eight months). The decision regarding when to test
the relevant controls is a matter of judgment. However, when we perform our tests of
controls at an interim date, we remember that the higher the degree of intended reliance
(that is, the more we intend to rely on the controls and thereby limit our substantive
procedures), the greater our need to be satisfied that the controls operated as intended
throughout the period. Further, the earlier in the year we perform the test, the greater is
the risk of changes to the control.
V. Extent
By recognizing that application controls operate in a systematic manner, we may be able to
limit the extent of our testing of those controls to a walk-through per significant transaction
type and processing alternative. We perform tests to obtain evidence that the application
controls operated effectively throughout the period of reliance. Testing ITGCs is the most
effective way to obtain evidence that an application control has continued to operate
throughout the period. However, if ITGCs are deemed ineffective, it may be possible to still
evaluate application controls as effective if we are able to confirm that the control operated
1
2

Often a test of one will suffice; this often occurs during walk-through.
A sample of users should be selected.

RAS Core Skills III

PM10-4, Application
Controls Concepts

Team Activity Support Materials

throughout the period via other means (e.g., confirmation that the configuration or program
did not change or testing that the application control operated throughout the period).

RAS Core Skills III