Expert Q&A

Auditor Answers: Enterprise Resource Planning Audits

Enterprise resource planning (ERP) systems have improved transaction processing efficiencies by
eliminating organizational barriers. But the integrated nature of ERP demands a different method of review
from the archetypal approach to auditing standalone systems. Our expert auditor offers advice on how to
conduct a successful ERP audit.

By Xenia Ley Parker

A Reader Asks: "What should auditors look for when auditing ERP systems?"

The Auditor Answers:

Enterprise Resource Planning (ERP) systems are integrated client/server application suites such as SAP
R/3, Oracle Financials, and PeopleSoft. Such suites have become ubiquitous, since they provide a versatile
transaction processing solution for organizations that require financial and human resources applications.

ERP suites include a set of modules that can be tailored to meet typical financial needs, such as accounts
payable (AP), accounts receivable (AR), general ledger (G/L), and others, as provided by Oracle Financials
and SAP R/3, probably the most widely used, along with PeopleSoft, which originally focused on human
resources and related financial tracking. An overview of all types of ERP available, with the module options
available might be longer than this column has space to provide.

ERP application modules can be linked together to form end-to-end processing; for example, from purchase
order or requisition through to invoice and payment, and on to the general ledger. To allow ERPs to work in
many locations, each module -- what one might think of an “an application” -- is more like a set of building
blocks. Various options, transaction codes, reports, audit trails, monitoring features, and so on, are
configured to suit the business needs. ERP implementation can be remarkably complex.

Among the general issues auditors should look for in an ERP review are common false assumptions about
development. For example, it is still possible to hear someone say: “It’s packaged software; therefore,
implementation is low risk” (as compared to applications developed in house). While this probably wasn’t
even true when it was a relatively common perspective in the early 1990s, it’s especially erroneous when
thinking about ERP. In fact, many early implementations failed due to extreme underestimation of the time,
money and effort made by organizations thinking ERP was like shrink-wrapped accounting software: just
add a chart of accounts and it would be ready to use.

To add to this picture, ERP systems require a fairly robust database management system, commonly
Oracle. The complexity of providing suitable data architecture, schema, subschema, and related data
elements is another aspect of ERP system implementations that may pose a challenge.
To do an effective audit -- of any sort, really -- you need to state audit objectives clearly. In general, when
considering ERP, begin by defining the audit universe (or auditable entities): assess the risks and then the
controls to mitigate those risks. For ERP systems focused on financial transaction processing, audit
objectives are usually things like, “Ensure only authorized payments are made in correct amounts to
approved vendors.” In other words, does the accounts payable system process only authorized transactions
-- once, without duplicates, completely and accurately -- and record them in the right sub-ledgers?

Auditors and IT managers should be aware that developing a program to review ERP is different from the
“classic” approach to selecting and auditing standalone systems, such as an accounts payable application.
What formerly could be fairly easily defined as an audit of a specific application, with its own boundaries and
controls is now an integrated process. The integration of application modules makes it more difficult to turn
this type of objective into a clear-cut audit program.

Auditors need to understand the ERP process flow, since the originating transaction establishes the data,
which then moves through various modules. Perform a walkthrough to understand the larger business
process; such as sales, disbursements, payroll, or customer service. This will help clarify how various sub-
processes (and their supporting modules) interact. Since the controls are often dependent on aspects of the
initiating transaction and subsequent interaction, understanding an entire process is an important step.

ERP Reviews

Some of the questions auditors should ask during an ERP review are pretty much the same as those that
should be asked during development and implementation of the system:
• If financial, does the system process according to GAAP (Generally Accepted Accounting
Principles) and GAAS (Generally Accepted Auditing Standards)?

• Does it meet the needs for reporting, whether regulatory or organizational?

• Were adequate user requirements developed through meaningful interaction?

• Does the system protect confidentiality and integrity of information assets?

• Does it have controls to process only authentic, valid, accurate transactions?

• Are effective system operations and support functions provided?

• Are all system resources protected from unauthorized access and use?

• Are user privileges based on what is called “role-based access?”

• Is there an ERP system administrator with clearly defined responsibilities?

• Is the functionality acceptable? Are user requirements met? Are users happy?

• Have workarounds or manual steps been required to meet business needs?

• Are there adequate audit trails and monitoring of user activities?

• Can the system provide management with suitable performance data?

 • Are users trained? Do they have complete and current documentation?

• Is there a problem-escalation process?

Change Management and Control

For an ERP system in use, another critical aspect is change management. Review questions ultimately are
related to IT development, but focus on controls over updates and changes in ERP in production. Change
management is an art and can be one of the weak points in controls when it is not handled effectively.
Auditors should ask:
• Is there a formal change-request process, with documented, authorized policies and related control
forms and approvals?

• Are all change requests and related activity logged for tracking purposes?

• Does management authorize all changes with informed consent?

• Does security administration to follow up on changes to permissions immediately?

Documentation of detailed testing of all changes should exist, including a test plan, results, and related
approvals to proceed. To avoid the possibility that a major change is not tested adequately, change
management policy should include a definition of levels of change. Minor changes reasonably might not
require the same level of testing and documentation as major changes, but in the haste to complete
changes developers sometimes say that a given change was “too small” to follow the fully documented test
process at all. Having clear definitions up front addresses that issue.

Before implementation of significant upgrades or major changes, complete backups of prior versions should
be made. Auditors should ask whether a back-out plan is developed as a normal aspect of major change. In
case of a failed change, IT will be able to restore the previous version. Also inquire about user involvement
and notification about major changes prior to implementation.

This response is necessarily a brief overview of a complex issue, providing key areas to consider developing
specific audit programs and test steps for ERP systems. There are literally volumes written on how to audit
ERP suites: auditors should seek out more detailed guidance for their environments.

Xenia Ley Parker, CIA, CISA, CFSA, is a Certified Internal Auditor (Institute of Internal Auditors), Certified
Information Systems Auditor, and Certified Financial Services Auditor with more than 24 years of experience
in IT and auditing. Parker is Senior Director of internal audit, and global head of IT audit, for a major risk
management firm. She was President of XLP Associates for 4 years, and previously was with Coopers &
Lybrand for 14 years and Ernst & Young for three. Her clients were in a wide range of industries, particularly
financial services. Prior to that, she was with CBS Inc. She has written numerous monographs; the
technology aspects of the original COSO study; and was co-author of all editions of The Handbook of IT
Auditing. Currently, she is the author of Information Technology Audits, published annually by CCH, with the
5th edition in June, 2007. She was adjunct Assistant Professor of Information Systems at New York
University, is a frequent speaker at audit conferences, and was a Senior Consultant for MIS Training
Institute.

Note:All views expressed in this article are those of the author and should not be considered to represent
the views of any other individual, entity, or organization. They are provided with the understanding that the
author is not engaged in rendering legal, accounting or other professional services. If such assistance is
required, the services of a competent professional should be sought.