Introduction To Erp

AUDITING IN ERP ENVIRONMENT
INTRODUCTION
Enterprise Resource Planning (ERP) System implementation is both an art and
science that consists of planning, implementation, and ongoing maintenance. This
methodology is designed to automate the drudgery of implementation and provide
organized approaches to problem solving by listing, diagramming, and documenting
all steps. Structured methodologies help to standardize and systemize ERP
implementation and maintenance by approaching them as an engineering discipline
rather than as whims of individual software developers. It is essential to understand
structured methodologies in the implementation of ERP systems.
The basic steps of structured methodologies are:
Project Definition and Requirement Analysis. Defining the terms of
reference, determining user needs and system constraints, generating a
functional specification and a logical model for the best solutions.
External Design. Detailing the design for a selected solution, including

diagrams relating all programs, subroutines, and data flow.
Internal Design. Building, testing, installing, and tuning software.
Pre-implementation. Evaluation and acceptance
Implementation. Implementing systems.
Post-implementation. Evaluation of controls and debugging.

When an organization purchases an ERP system, the intent is that the
purchased ERP system provides specific functions and benefits. These functions
and benefits need to be articulated to ensure that the ERP system performs as
desired. This process is called conducting a feasibility analysis. The purpose of the
feasibility study is to provide:
An analysis of the objectives, requirements, and system concepts.

An evaluation of different approaches for reasonably achieving the objectives.
Identification of a proposed approach. The feasibility analysis normally covers:
Current working practices. These are examined in depth, revealing areas in
the business where there is duplication of effort, or where procedures
instituted in the distant past are carried out even though there is no longer any
need for them.
Channels of information. These are examined because the feasibility study is
concerned primarily with the input and output information of each internal
system. Such a study ignores departmental boundaries and prejudices. When
the true information patterns within a business are exposed, it is often
possible to reorganize resources so that all relevant data is captured at the
point where it can be used for decision.
Alternative approaches. Alternative methods of handling or presenting the
data should be considered.
Cost factors. These must be clearly identified and show definite cost savings
or related benefits. Existing costs must be examined and used as a basis for
comparison. Since this presentation is likely to be related to the information
structure rather than to the departmental organization, the new approach may
suggest possible improvements that were hidden under the existing system.
Supporting services offered. The training and the systems and programming
assistance that will be available during the installation period.
Range compatibility. If the workload expands, can the configuration be
Page 1 of 38

increased in power without extensive reprogramming?
Audit Objectives in an ERP Environment
The fundamental objectives of an audit of controls do not change in an ERP
environment. When evaluating controls over ERP systems, decisions must be made
regarding the relevance of operational internal control procedures to Information
Technology (IT) controls. Specific control procedures for audit objectives must be
tested.
Descriptive material on control procedures and sample compliance tests will be
provided. This material will be as detailed as possible and should be read selectively,
considering its relevance to the specific environment being audited.
In addition to primary audit responsibilities, auditors should be able to provide
advice on effective design of control procedures. Audit should communicate
significant weaknesses that come to their attention to the appropriate IT personnel.
Auditors should also be alert to weaknesses that require special reviews and be
capable of assessing computer systems under development, in addition to the
existing systems.
ERP SYSTEM ARCHITECTURE
ERP systems should produce accurate, complete, and authorized information that is
supportable and timely. In a computing environment, this is accomplished by a
combination of controls in the ERP System, and controls in the environment in which
the ERP system operates, including its operating system. Controls are divided into
general and application controls. General controls can be further divided into
management and environmental controls. Management controls deal with
organizations, policies, procedures, planning, and so on. Environmental controls are
the operational controls administered through the computer center/computer
operations group and the built-in operating system controls.
ERP System Architecture

NEED FOR AN ERP RISK ASSESSMENT
Page 2 of 38
ERPs have substantially altered the method by which administrative processes, such
as payroll, accounts payable, inventory, sales and accounts receivable, operate, are
controlled and audited. Opportunities for personal review and clerical checking have
declined as the collection and subsequent uses of data have changed. The changes
are the result of moving from manual procedures performed by individuals familiar
with both the data and the accounting process; to high volume, automated processes
performed by individuals unfamiliar with either the data or the accounting practices.
Information Technology has substantially reduced the time available for the review of
transactions before their entry into the automated systems records. In poorly
controlled systems the opportunity for discovering errors or fraud before they have
an impact on operations is reduced, especially in the case of real time, distributed,
and database systems. The radical growth of these system configurations (or architectures) has increased the importance of both automated and manual internal
control/security procedures. It is imperative, therefore, that these systems are
reviewed, as they are being implemented; to ensure that adequate controls and
security are designed into the ERP system from the outset.
IMPLEMENTATION VERSUS OPERATIONAL AUDIT
Auditing in an ERP environment can be divided into two broad areas. First is the
audit of ERP systems under implementation and second is the audit of operational
ERP systems. These two types of audits require significantly different approaches.
In an implementation (vanilla or otherwise) of an ERP system, there is no
operational system or output data. The auditor evaluates controls without the benefit
of observing processing results. In an implementation audit, the auditor is concerned
with ensuring that the implementation procedures and standards have been properly
followed.
The audit of operational ERP systems evaluates the results of the automated
processes. It is normally a data-oriented audit, looking at processed transactions.
The adequacy and effectiveness of the system controls can be evaluated by
examining the results of operation (i.e., did the application produce the anticipated
outcome).
The operational audits can identify vulnerabilities, but these are costly to correct
after implementation because of the associated costs (in money and operational
downtime). Studies have shown that it costs approximately 50100 times more to
correct an operational system than it would have cost to build in the necessary
controls during implementation. Indeed, the cost to retrofit controls into a system increases geometrically as one progress through the ERP system life cycle phases.
If potential vulnerabilities can be identified during implementation of ERP
systems, they can be more easily and economically corrected than after the ERP
system is installed and operational. Thus, it becomes imperative to evaluate the
adequacy of the implementation approach to controls (i.e., how controls are
addressed, implemented, and documented). If an adequate system of controls is
built in during implementation, it can be fine-tuned through operational audits, as
necessary. The risks and exposures through the model ERP life cycle (ERPCL) are
presented in Exhibits 3.1a3.2e, which include the operational environment and
maintenance phases.
Page 3 of 38

OVERVIEW OF RISKS
Organizations assume risks in the normal conduct of doing business. These risks
represent potential damaging events that might produce losses. Controls or
safeguards are installed to reduce these risks. If controls are insufficient, the
organization is overexposed and is likely to suffer losses or operate at a less efficient
level than competitors.
Any IT environment presents unique vulnerabilities and threats to an organization.
Vulnerability is a weakness or a flaw in an IT-based system that may be exploited by
a threat that can cause destruction or by misuse of the systems assets or resources.
Threats can be environmental (e.g., fire, water damage, earthquakes, hurricanes,
etc.) or people-oriented (e.g., errors, omissions, intentional acts of violence, fraud,
etc.). When a threat materializes and takes advantage of a systems vulnerabilities, a
damaging event causes a loss. The risks of damaging events cannot be totally
eliminated, but the use of controls can reduce such risks to an acceptable level.
Overview of Risks Exhibit 2.1 Risks and exposures for ERPLC

Risk Analyses
A risk analysis of an organizations ERP systems, their existing controls, and their
vulnerabilities results in the loss potential for the system, with an estimated likelihood
of occurrence. This loss potential in damages must be represented in terms of dollar
value.
A risk analysis of an ERP system performs two important functions:
1 Searches out an ERP systems vulnerabilities and the probabilities of threats
materializing to exploit these vulnerabilities.
2 Calculates the damage or loss to its assets that could be produced by the
resulting damaging events.
A third component, to recommend controls or safeguards that would reduce the
damages or loss to an acceptable level (through the use of a cost/benefit analysis),
might also be added.
An ERP system environments vulnerabilities and set of threats should be
assessed to arrive at some estimate of possible damaging events. Such an
Page 4 of 38

assessment would also review the strengths of existing controls.
A vulnerability assessment is conducted as part of a risk analysis. The
vulnerability assessment is a major assessment of the adequacy of an ERPs
system. Organizations must first identify vulnerabilities and threats; and then
determine whether controls are adequate to reduce the resulting risks to an
acceptable level. If not, it will be necessary to correct and guard against threats.
RISKS IN AN ERP ENVIRONMENT
The risks in an ERP environment include both those present in a manual processing
environment and those that are unique or increased in an ERP environment. The use
of ERP systems clearly introduces additional risks into the system environment.
These additional risks include problems associated with:
3 Improper use of technology.
4 Inability to control technology.
5 Inability to translate user needs into technical requirements.
6 Illogical processing.
7 Inability to react quickly (to stop processing).
8 Cascading of errors.
9 Repetition of errors.
10 Incorrect entry of data.
11 Concentration of data.
12 Inability to substantiate processing.
13 Concentration of responsibilities.
Each of these risks is discussed individually below, including many of the
conditions that cause the risks to occur.
Improper Use of Technology
Information technology provides systems analysts and programmers with a variety of
processing capabilities. This technology must be matched to the users needs in
order to best meet those needs. A mismatch of technology and needs can result in
an unnecessary expenditure of organizational resources.
One of the more common misuses of technology is the introduction of new
technology prior to the clear establishment of its need. For example, many
organizations introduce database technology without clearly establishing the need
for that technology. Experience has shown that the early users of a new technology
frequently consume large amounts of resources learning to use that new technology.
14The conditions that lead to the improper use of technology include:
15Premature user of new hardware technology.
16Early user of new software technology.
17Minimal planning for the installation of new hardware and software
technology.
18Systems analyst/programmer improperly skilled in the use of technology.
Inability to Control Technology
IT personnel spend most of their effort on the problems associated with the
implementation of new technology. Numerous studies imply that there is often too
Page 5 of 38

little time left to develop and install technological controls. As a result, resources are
expended to correct technological problems.
Controls are needed over the technological environment. These controls ensure
that the proper version of the proper program is in production at the right time; that
the proper files are mounted; and that the operators perform the proper instructions.
Adequate procedures must be developed to prevent, detect, and correct problems in
the operating environment. The proper data must be maintained and retrievable
when needed. The conditions that result in uncontrolled technology include:
19Selection of vendor-offered system control capabilities by systems
programmers without considering audit needs.
20Too many control trade-offs for operational efficiency.
21Inadequate restart/recovery procedures.
22Inadequate control over different versions of programs.
23Inadequate control over schedulers, system operators, tape librarians, print
capabilities, and data transmission capabilities.
24Inadequate review of outputs.
Inability to Translate User Needs into Technical Requirements
One of the major failures of information technology has been a communication
failure between users and technical personnel. In many organizations, users cannot
adequately express their needs in terms that facilitate the implementation of ERP
applications. And the technical people are often unable to appreciate the concerns
and requirements of their users.
The risk associated with failure to satisfy user needs is complex. Exposures
include:
25Failure to implement needs because users were unaware of technical
capabilities.
26Improperly implemented needs because the technical personnel did not
understand user requirements.
27Users accepting improperly implemented needs because they are unsure how
to specify changes.
28 Building of redundant manual systems to compensate for weaknesses in
ERP applications.
29Conditions that can lead to the inability to translate user needs into technical
requirements include:
30Users without technical IT skills.
31Technical people without sufficient understanding of user requirements.
32Users inability to specify requirements in sufficient detail.
33Multi-user systems with no user in charge of the system.
Illogical Processing
Illogical processing is the performance of an automated event that would be highly
unlikely in a manual processing environment; for example, producing a payroll check
for a clerical individual for over $1 million. This is possible in an automated system
due to programming or hardware errors, but highly unlikely in a manual system.
ERP applications do not have the same human oversight as manual systems. In
addition, fewer people have a good understanding of the processing logic of ERP
applications. Thus, in some instances, illogical processing may not be readily
Page 6 of 38

recognizable. Conditions that can result in illogical processing include:
34Failure to check for unusually large amounts on output documents.
35Fields that are either too small or too large, thereby impacting the
completeness, accuracy, or efficiency of the data being processed.
36Failure to scan output documents.
Inability to React Quickly
ERP applications are valuable because they are able to satisfy user needs on a
timely basis. Some of these needs are predetermined and reports are prepared on a
regular basis to meet these needs. Other needs occur periodically and require
special actions to satisfy. If the ERP application is unable to satisfy these special
needs on a timely basis, redundant systems may be built for that purpose.
One of the measures of an ERP applications success is the speed with which
special requests can be satisfied. Some of the newer online database applications
that include a query language can satisfy some requests within a very short time
span. On the other hand, some of the older batch-oriented applications may take
several days or weeks to satisfy a special request. In some instances, the structure
of the application system is an inhibits satisfying requests. For example, if an auditor
wants all of the supporting information for a supply requisition in a tape-batched
system, the cost and difficulty of satisfying that request may be prohibitive. That
requisition could be spread over many weeks of processing, due to back orders,
returned shipments, and shipping errors. The evidence supporting the transaction
may be spread over many tape files and the cost of processing those files may be
exorbitant.
The conditions that make ERP applications unable to react quickly include:
37 Computer time is unavailable to satisfy the request, or computer
terminals/microcomputers are not readily accessible to users.
38 The structure of the computer files is inconsistent with the information
requested.
39 General-purpose extract programs are not available to satisfy the desired
request.
40 The cost of processing exceeds the value of the information requested.
Cascading of Errors
Cascading of errors is the domino effect of errors throughout an application system.
An error in one part of the program or application triggers a second yet unrelated
error in another part of the application system. This second error may trigger a third
error, and so on.
The cascading of error risk is frequently associated with making changes to
application systems. A change is made and tested in the program in which the
change occurs. However, some condition has been altered as a result of the change,
which causes an error to occur in another part of the application system.
Cascading of errors can occur between applications. This risk intensifies as
applications become more integrated. For example, a system that is accepting
orders may be tied through a series of applications to a system that replenishes
inventory based upon orders. Thus, an insignificant error in the order-entry program
can cascade through a series of applications resulting in a very serious error in the
inventory replenishment program.
The types of conditions that lead to cascading of errors include:
Page 7 of 38

41
Inadequately tested applications.
42
Failure to communicate the type and date of changes being
implemented.
43
Limited testing of program changes.
Repetition of Errors
In a manual processing environment, errors are made individually. Thus, a person
might process one item correctly, make an error on the next, process the next twenty
correctly, and then make another error. In ERP systems, the rules are applied
consistently. Thus, if the rules are correct, processing is always correct. But, if the
rules are erroneous, processing will always be erroneous.
Errors can result from application programs, hardware failures, and failures in
vendor-supplied software. For example, a wrong percentage may have been entered
for tax deductions. Thus, every employee for that pay period will have the wrong
amount deducted for tax purposes.
The conditions that cause repetition of errors include:
44
Insufficient program testing.
45
Inadequate checks on entry of master information.
46
Failure to monitor the results of processing.
Incorrect Entry of Data
In ERP applications, there is a mechanical step required to convert input data into
machine-readable format. In the process of conducting this task, errors can occur.
Data that was properly prepared and authorized may be entered into ERP
applications incorrectly.
Much of the data entered into batch-type systems is entered using a keyboard
device. Some of these devices are keypunch machines and key-to-disk machines.
The data originator manually transcribes the input information onto some type of
form, and the form is given to a key operator to enter on computer media. During this
keying process, errors can be made.
In the newer technology, data can be originated and entered at the same time.
For example, order entry clerks receive orders by telephone and key them directly
into computer memory. However, errors can still occur during this process.
Other methods of data entry include optical scanners, process-control
computers that monitor production machinery, automatic cash dispensers and pointof-sale equipment. However, these are all mechanical devices and thus subject to
failure.
Conditions that can cause incorrect entry of data include:
47
Human errors in keying data.
48
Mechanical failure of hardware devices.
49
Misinterpretation of characters or meaning of manually recorded input.
50
Misunderstanding of data entry procedures.
51
Inadequate data verification procedures.
Concentration of Data
ERP applications concentrate data in an easy-to-access format. In manual systems,
data is voluminous and stored in many places. It is difficult for an unauthorized
individual to spend much time browsing undetected through file cabinets or other
manual storage areas.
Page 8 of 38

With ERP media, unauthorized individuals can browse using computer
programs. This may be difficult to detect without adequate safeguards. In addition,
the data can be copied quickly without leaving any visible trail or destroying the
original data. Thus, the owners of the data may not be aware that the data has been
compromised.
Database technology increases the risk of data manipulation and compromise.
The more data that is stored in a single place, the greater the value of that data to an
unauthorized individual. For example, the information about an individual in the
payroll application is restricted to current pay information. But, when that data is
coupled with personnel history, not only current pay information, but also pay history,
individual skills, years and progression of employment, and perhaps performance
evaluation is available.
Concentration of data increases the problems of greater reliance on a single
piece of data and reliance on a single file. If the data entered is erroneous, the more
applications that rely on that piece of data, the greater the impact of the error. And
the more applications that use the concentrated data, the greater the impact when
that data is unavailable due to problems with the hardware or software used for
processing it.
The conditions that can create problems due to the concentration of data in ERP
applications include:
52
Erroneous data and its impact on multiple users of that data.
53
Impact of hardware and software failures that ordinarily make the data
available to multiple users.
54
Inadequate access controls enabling unauthorized access to data.
55
Inefficient use of system for data storage and/or retrieval, which may impact
response time or computer capacity.
Inability to Substantiate Processing
ERP applications should contain the capability to substantiate processing. This
substantiation includes both the ability to reconstruct the processing of a single
transaction and the ability to reconstruct control totals. ERP applications should be
able to produce all of the source transactions that support a control total as well as
substantiate that any source document is contained in a control total.
Application systems need to substantiate processing to correct errors and to
prove that processing is correct. When errors occur, computer personnel need to
pinpoint the cause so they can be corrected. ERP application customers, other
users, and control-oriented personnel, such as auditors, frequently want to verify that
processing is correct.
Conditions that may cause the inability to substantiate processing include:
56
Evidence is not retained long enough.
57
The evidence from intermediate processing is not retained.
58
Evidence is not independently reviewed for quality assurance and/or data
integrity.
59
Outputs are not reviewed for quality by the users.
60
The cost of substantiating processing exceeds the benefits derived from the
process.
Concentration of Responsibilities
Page 9 of 38

ERP systems concentrate the responsibilities of many people into the automated
application. Responsibilities that had been divided among many people for control
purposes may be concentrated into a single application system. A single application
system may also concentrate responsibilities from many departments within an
organization.
The responsibilities in an ERP environment may be concentrated in both the
application system and IT personnel. For example, the data-base administrator may
absorb data control responsibilities from many areas in the organization. A single
ERP system project leader may have the processing responsibility for many areas in
the organization. New methods of separation of duties must be substituted for the
previous segregation of duties among people.
Conditions that cause the concentration of responsibilities in an ERP
environment include:
61
Establishment of a data processing programming and systems group to
develop ERP applications for an organization.
62
Centralized processing of ERP applications.
63
Establishment of a database administration function.
64
Lack of adequate standards and enforcement of those standards.
65
Lack of adequate quality assurance and systems or applications testing.
The following is a list of negative situations to which ERP application systems
are vulnerable, grouped according to common system organizational structures.
While not intended to be all-inclusive, the list suggests various kinds of vulnerabilities
that may exist in an ERP system. This list of potential vulnerabilities helps identify the
additional risks presented in an ERP environment. Due to their value as a tool to
identify unique risks, a brief description of vulnerabilities by type is also provided.
Erroneous or Falsified Data Input. Erroneous or falsified input data is the simplest
and most common cause of undesirable performance by an applications system.
Vulnerabilities occur wherever data is collected, manually processed, or prepared for
entry to the computer.
66Unreasonable or inconsistent source data values may not be detected.
67Keying errors during transcription may not be detected.
68Incomplete or poorly formatted data records may be accepted as if they were
complete records.
69Records in one format may be interpreted according to a different format.
70An employee may fraudulently add, delete, or modify data (e.g., payment
vouchers, claims) to obtain benefits (e.g., checks, negotiable coupons) for
himself.
71Lack of document counts and other controls over source data or input
transactions may allow some of the data or transactions to be lost without
detection or allow extra records to be added.
72Records about the data entry personnel (e.g., a record of a personnel action)
may be modified during data entry.
73Data that arrives at the last minute (or under some other special or
emergency condition) may not be verified prior to processing.
74Records in which errors have been detected may be corrected without
verification of the full record.
Misuse by Authorized End Users. End users are the people served by ERP
Systems. The system is designed for their use, but they can also misuse it. It may be
Page 10 of 38

difficult to determine whether their use of the system is in accordance with the
legitimate performance of their job.
An employee may convert confidential information to an unauthorized use.
For example, he may sell privileged data about an individual to a prospective
employer, credit agency, insurance company, or competitor; or may use
statistics for stock market transactions before their public release.
75A user whose job requires access to individual records in a file may compile a
complete listing of the file and then make unauthorized use of it (e.g., sell a
listing of employees home addresses as a mailing list).
76Information may be altered for an unauthorized end user (e.g., altering of
personnel records).
77An authorized user may use the system for personal benefit (e.g., theft of
services).
78A supervisor may manage to approve and enter a fraudulent transaction.
79A disgruntled or terminated employee may destroy or modify records, possibly
in such a way that backup records are also corrupted and useless.
80An authorized user may accept a bribe to modify or obtain information.
Uncontrolled System Access. Organizations expose themselves to unnecessary
risk if they fail to establish controls over who can enter the system area, who can use
the ERP and who can access the information contained in the system.
81Data or programs may be stolen from the IT room or other storage areas.
82ERP facilities may be destroyed or damaged by intruders or employees.
83Individuals may not be adequately identified before they are allowed to enter
the IT area.
84Remote terminals may not be adequately protected from use by unauthorized
persons.
85An unauthorized user may gain access to the system via a dial-in line and an
authorized users password.
86Passwords may be inadvertently revealed to unauthorized individuals. A user
may write his password in some convenient place, or the password may be
obtained from some other apparent source, discarded printouts, or by
observing the user as he types it.
87A user may leave a logged-in terminal unattended, allowing an unauthorized
person to use it.
88A terminated employee may retain access to an ERP system because his
name and password are not immediately deleted from authorization tables
and control lists.
89An unauthorized individual may gain access to the system for his own
purposes (e.g., theft of computer services, data or programs, modification of
data, alteration of programs, sabotage and denial of services).
90Repeated attempts by the same user or terminal to gain unauthorized access
to the system or to a file may go undetected.
Ineffective Security Practices for the Application. Inadequate manual
checks and controls to ensure correct processing by the AIS, or negligence by
those responsible for carrying out these checks, result in many vulnerabilities.
91Poorly defined criteria for authorized access may cause employees not to
know what information they, or others, are permitted to access.
92The person responsible for security may fail to restrict user access to only
Page 11 of 38

those processes and data that are needed to accomplish assigned tasks.
93Large funds disbursements, unusual price changes, and unanticipated
inventory usage may not be reviewed for accuracy.
94Repeated payments to the same party may go unnoticed because there is no
review.
95Sensitive data may be carelessly handled by the application staff, by the mail
service, or by other personnel within the organization.
96Post-processing reports analyzing system operations may not be reviewed to
detect security violations.
97Inadvertent modification or destruction of files may occur when trainees are
allowed to work on live data.
98Appropriate action may not be pursued when a security variance is reported
to the system security officer or to the perpetrating individuals supervisor. In
fact, procedures covering such occurrences may not exist.
Procedural Errors within the IT Facility. Both errors and intentional acts committed
by the DP operations staff may result in improper operational procedures, lapsed
controls, and losses in storage media and output.
Procedures and Controls.
99Files may be destroyed during database reorganization or during release of
disk space.
100
Operators may ignore operational procedures; for example, by allowing
programmers to operate computer equipment.
101
Job control language parameters may be erroneous.
102
An installation manager may circumvent operational controls to obtain
information.
103
Careless or incorrect restarting after shutdown may cause the state of
a transaction update to be unknown.
104
An operator may enter erroneous information at a CPU console (e.g.,
control switch in wrong position, terminal user allowed full system access;
operator cancels wrong job from queue).
105
Hardware maintenance may be performed while production data is
online and the equipment undergoing maintenance is not isolated.
106
An operator may perform unauthorized acts for personal gain (e.g.,
make extra copies of competitive bidding reports, print copies of
unemployment checks; delete a record from a journal file).
107
Operations staff may sabotage the computer (e.g., drop pieces of metal
into a terminal).
108
The wrong version of a program may be executed.
109
A program may be executed using wrong data or may be executed
twice using the same transactions.
110
An operator may bypass required safety controls (e.g., write rings for
tape reels).
111
Supervision of operations personnel may not be adequate during nonworking-hour shifts.
112
Due to incorrectly learned procedures, an operator may alter or erase
the master files.
113
A console operator may override a label check without recording the
action in the security log.
Page 12 of 38

Storage Media Handling.
114
Critical tape files may be mounted without being write protected.
115
Inadvertently or intentionally mislabeled storage media are erased. In
case they contain backup files, the erasure may not be noticed until it is
needed.
116
Internal labels on storage media may not be checked for accuracy.
117
Files with missing or mislabeled expiration dates may be erased.
118
Incorrect processing of data or erroneous updating of files may occur
when input data has been dropped; partial input data is used; write rings
mistakenly are placed in tapes; wrong tapes are incorrectly mounted or worn
tapes mounted.
119
Scratch tapes used for jobs processing sensitive data may not be
adequately erased after use.
120
Temporary files written during a job step for use in subsequent steps
may be erroneously released or modified because they are not protected or
because of an abnormal termination.
121
Storage media containing sensitive information may not get adequate
protection because operations staff does not know the nature of the
information content.
122
Tape management procedures may not adequately account for the
current status of all tapes.
123
Magnetic storage media that contain very sensitive information may not
be degaussed before being released.
124
Output may be sent to the wrong individual or terminal.
125
Improper operation of output or post-processing units (e.g., bursters,
decollators, or multipart forms) may result in loss of output.
126
Surplus output material (e.g., duplicates of output data, used carbon
paper) may not be disposed of properly.
127
Tapes and programs that label output for distribution may be erroneous
or not protected from tampering.
Program Errors. ERP system should operate in an environment that requires and
supports complete, correct, and consistent program design, good programming
practices, adequate testing, review, documentation, and proper maintenance
procedures. Although programs developed and implemented in such an environment
may still contain undetected errors, programs not developed in this manner may be
rife with errors. Without these controls, programmers can deliberately modify
programs to produce undesirable side effects or they can misuse the programs they
monitor.
128
Records may be deleted from sensitive files without a guarantee that
the deleted records can be reconstructed.
129
Programmers may insert special provisions in programs that
manipulate data concerning themselves (e.g., a payroll programmer may alter
his own payroll records).
130
Data may not be stored separately from code so that program
modifications are more difficult and must be made more frequently.
131
Program changes may not be tested adequately before being used in a
production run.
132
Changes to a program may result in new errors due to unanticipated
Page 13 of 38

interactions between program modules.
133
Program acceptance tests may fail to detect errors that only occur for
unusual combinations of input (e.g., a program that is supposed to reject all
except a specified range of values actually accepts an additional value).
134
Programs with contents that should be safeguarded may not be
identified and protected.
135
Code, test data with its associated output, and documentation for
certified programs may not be filed and retained for reference.
136
Documentation for vital programs may not be safeguarded.
137
Programmers may fail to keep a change log, to maintain back copies,
or to formalize record-keeping activities.
138
An employee may steal programs he maintains and use them for
personal gain (e.g., sale to a commercial organization, hold another
organization for extortion).
139
A critical data value may be initialized twice due to poor program
design. An error may occur when the program is modified to change the data
value, but only changes it in one place.
140
Production data may be disclosed or destroyed when it is used during
testing.
141
A programmer who misunderstands requests for changes to the
program may cause errors.
142
A programmer who makes changes directly to machine code may
introduce errors.
143
Programs may contain routines not compatible with their intended
purposes, which can disable or bypass security protection mechanisms. For
example, a programmer who anticipates being fired, inserts code into a
program which will cause vital system files to be deleted as soon as his name
no longer appears in the payroll file.
144
Inadequate documentation or labeling may result in the wrong version
of a program being modified.
Operating System Flaws. Design and implementation errors, system generation
and maintenance problems, and deliberate penetrations causing modifications to the
operating system can produce undesirable effects in the ERP systems. Flaws in the
operating system are often difficult to prevent and detect. User jobs may be
permitted to read or write outside the assigned storage area.
145
Simultaneous processing of the same file by two jobs may introduce
inconsistencies into data.
146
An operating system design or implementation error may allow a user
to disable audit controls or to access all system information.
147
The operating system may not protect a copy of information as
thoroughly as it protects the original.
148
Unauthorized modification to the operating system may allow a data
entry clerk to enter programs and thus subvert the system.
149
An operating system crash may expose valuable information such as
password lists or authorization tables.
150
Maintenance personnel may bypass security controls while performing
maintenance work. At such times, the system is vulnerable to errors or
intentional acts of the maintenance personnel, or anyone else who might also
Page 14 of 38

be on the system and discover the opening (e.g., micro-coded sections of the
operating system may be tampered with or sensitive information from online
files may be disclosed).
151
An operating system may fail to record that multiple copies of output
have been made from spooled storage devices.
152
An operating system may fail to maintain an unbroken audit trail.
153
When restarting after a system crash, the operating system may fail to
ascertain that all terminal locations are still occupied by the same individuals.
154
A user may be able to get into monitor or supervisory mode.
155
The operating system may fail to erase all scratch space assigned to a
job after the normal or abnormal termination of the job.
156
Files may be allowed to be read or written without having been opened.
Communications System Failure. Information being routed from one location to
another over communication lines is vulnerable to accidental failures and to
intentional interception and modification by unauthorized parties.
Accidental Failures.
157
Undetected communication errors may result in incorrect or modified
data.
158
Information may be accidentally misdirected to the wrong terminal.
159
Communication nodes may leave unprotected fragments of messages
in memory during unanticipated interruptions in processing.
160
Communication protocol may fail to positively identify the transmitter or
receiver of a message.
Intentional Acts.
161
Communication lines may be monitored by unauthorized individuals.
162
Data or programs may be stolen via telephone circuits from a remote
job entry terminal.
163
Programs in the network switching computers may be modified to
compromise security.
164
Data may be deliberately changed by individuals tapping the line
(requires some sophistication, but is applicable to financial data).
165
An unauthorized user may take over a computer communication port
as an authorized user disconnects from it. Many systems cannot detect the
change. This is particularly true in much of the currently available
communication equipment and in many communication protocols.
166
If encryption is used, keys may be stolen.
167
A terminal user may be spoofed into providing sensitive data.
168
False messages may be inserted into the system.
169
True messages may be deleted from the system.
170
Messages may be recorded and replayed into the system (i.e., deposit
$100 messages).
Besides the risks described previously, the impact of these additional vulnerabilities
must be assessed. These special vulnerabilities pose threats, which are not present
at all, or are present to a lesser degree, in non-ERP environments. Once these risks
are identified, their severity should be estimated, and controls developed to mitigate
their impact on the ERP applications.
Page 15 of 38

INTERNAL CONTROL
Internal control systems are set up to help mitigate against the risks discussed
above. The purpose of internal control systems is to reasonably ensure that the
following goals are achieved:
171
Obligations and costs comply with applicable laws.
172
All assets are safeguarded against waste, loss, unauthorized use, and
misappropriation.
173
Revenues and expenditures that apply to organization operations are
recorded and properly accounted for, so that accounts and reliable financial
and statistical reports may be prepared and an accounting of these assets
may be maintained.
Control Objectives and Key Controls
In order to understand control objectives and key controls, it is important to know
what a system of internal controls is. The AICPA Guidelines of Internal Control define
it as:
The plan of organization and all the methods and procedures adopted by
the management of an entity to assist in achieving managements objective
of ensuring, as far as practical, the orderly and efficient conduct of its
business, including adherence to management policies, the safeguarding of
assets, the prevention and detection of fraud and error, the accuracy and
completeness of the accounting records, and the timely preparation of
reliable financial information. The system of internal controls extends beyond those matters which relate directly to the functions of accounting
system.
Control Objectives
Control objectives are high-level statements of intent by the management to ensure
that departmental programs designed to fulfill the organizations strategic plans are
carried out effectively and efficiently. These statements of intent embody the plan of
organization and all the related systems established by management to safeguard
assets, check the accuracy and reliability of financial data, promote operational efficiency and encourage adherence of prescribed management policies.
Once the business risk for the ERP systems is defined, it is possible to determine
how these risks will be contained. Control objectives can be defined as the purpose
or justification for having internal controls. The organizations internal control
structure must meet several control objectives to prevent, detect and correct errors,
omissions and irregularities in business transactions and processes, and to assure
continuity of business operations. They are a link between the risks and internal
controls.
Control objectives may differ, depending upon the type, scope, and purpose of the
audit. There could be several internal control objectives for a given business risk, so
that the risk is adequately addressed. Some of the common internal control
Page 16 of 38

objectives that an author should look for are:
174
Transactions are properly authorized (Authorized).
175
Transactions are recorded on a timely basis (Timeliness).
176
Transactions are accurately processed (Accuracy).
177
All existing transactions are recorded (Completeness).
178
All recorded transactions are valid (Validity).
179
Transactions are properly valued (Valuation).
180
Transactions are properly classified and posted to proper accounts and
subsidiary records (Classification).
181
Transactions are properly summarized and reported (Reporting).
182
Assets, including software programs, data, human resources, computer
facilities, etc. are safeguarded against damage, theft, and so forth (Security).
183
System and data integrity is maintained (Integrity).
184
System availability is assured (Availability).
185
System controllability and auditability is maintained (Controllability and
Auditability).
186
System maintainability is assured (Maintainability).
187
System usability is assured (Usability).
188
System economy and efficiency are maintained (Efficiency).
Key Controls
Each control objective is met by one or more control techniques. These techniques
are the ways and means that management controls the operations, are varied in
nature, and exist as:
189
Procedures and policies. For example, independent balancing,
cancellation of documents after processing, independent signing for approval
of prepared source documents, competent and trustworthy personnel,
segregation of duties, mandatory vacations and rotation of duty assignments.
190
Information systems design. For example, numerically prenumbered
forms, message authentication, console logs, encryption, range and limit
checks on input fields.
191
Physical controls. For example, combination locks for vaults, card
acceptor devices for restricted access areas.
192
Segregation of duties.
Segregation of Duties
The overall objective of the segregation of duties for ERP systems can be expressed
as production data is only accessible to bonafide users utilizing tested and approved
ERP. Bonafide users are those allowed by management to view, update, add or
delete transactions in a specific application. The manager in charge of the division or
department who relies on the data for its operations owns the data. For instance, the
controller owns the financial data; he or she is ultimately responsible for its accuracy
and safeguard.
From a practical standpoint, that manager will have devolved the responsibility of
Page 17 of 38

granting user access to managers reporting to him or her. These managers will, in
turn, rely on a system administrator, either a member of the user department or IT, to
brief them on the available functions of the ERP; the identity of the users whose job
requires access to these functions; and ultimately, the data. Having understood the
sensitivity of the functions and the confidentiality of the data, these managers will
delegate authority to the administrator to grant access to users. The IT department is
responsible for ensuring that powerful utilities are only accessible to selected users
and cannot be utilized in an unauthorized fashion to modify production data. In every
environment, there will always be one user and a back-up who have access or can
grant themselves access to all data.
These powerful users should be carefully selected and audit trails of their actions
should exist. Production data is never owned by IT unless it is specific to the
operations of the IT department. Production data should only be accessed through
authorized utilities that would not allow users to manipulate production data outside
of the constraints and controls implemented within the ERP systems. For instance,
the rules implemented at the database level require that a customer be in the customer file for their order to be recorded. If a user were able to directly access the
order table, through a text editor in a UNIX environment or by TSO/ISPF (True
Sharing Option/Interactive System Productivity Facility) in an MVS (Multiple Virtual
Storage) environment, the ERP control implemented could be bypassed and an
order entered for a nonexistent customer.
Page 18 of 38

Indian auditing experience in ERP Audit
Bharat Sanchar Nigam Limited
Bharat Sanchar Nigam Limited introduced SAP R/3 version 4.7 in Gujarat Telecom
Circle (GTC). The SAP-ERP server is installed at ERP Data Centre at Ahmedabad
and LAN (Local Area Network) / WAN (Wide Area Network) were used for connecting
R/3 environment to the nodes at Secondary Switching Areas (SSAs). The work of
implementation of ERP in GTC was awarded to Siemens Information Systems
Limited (SISL), Mumbai at a cost of Rs. 20.14 crore. The objectives of
implementation of ERP were to: (i) Improve the information flow to facilitate better
decision making leading to overall improvement in the performance of the
organisation by way of improvements in productivity, cycle time, financial
performance and information transparency, (ii) Convert GTC into a paperless
working environment and (iii) Reduce manpower requirement. However, it was
observed that the desired objectives did not accrue to the Company as detailed
below:
1. Business Process Re-engineering (BPR)
Business Process Re-engineering (BPR) is one of the fundamental steps undertaken
prior to ERP implementation. While according sanction for implementation of ERP in
Gujarat Telecom Circle, BSNL Corporate Office in August 2003 had approved
implementation of ERP in one SSA and implementation in entire Circle was to be
done after finalizing business processes. Against the instructions of the Corporate
Office, GTC went ahead with implementation of ERP in all SSAs without finalising
BPR which resulted in manual intervention and deprived the Company of
advantages of ERP. For instance, In the manual system, for sale of top-up and
recharge coupons the Marketing wing issues delivery note to the franchisee for the
quantity of top-up and recharge coupons and the Cash section receives the
payments against the quantity authorised by the Marketing wing. The products are
then issued by the Marketing wing after production of cash receipts. In an ERP
environment all the above functions could be carried out through a single window. It
was noticed that all the activities related to the sale of top-up and recharge coupons
of GTC were being carried out in the traditional way despite operating in a
computerised environment. The total value of sales of these coupons in the two
years of 2007-08 and 2008-09 was Rs. 470.50 crore out of which 79 per cent
amounting to Rs. 372 crore was through franchisees.
2. Interface with the telephone revenue billing packages
There are two billing packages used in GTC for billing. One of the important
conditions of the agreement with SISL for implementation of ERP was to provide
interface with the existing billing packages. It was observed that no interface was
provided with the revenue billing packages and the revenue from them are
accounted in ERP through Journal Vouchers. In the absence of interface bank
reconciliation of collection accounts is done manually depriving GTC of the
advantages of efficient fund management.
3. Digitisation of service details and records
Agreement with M/s SISL stipulated that service records, personal details, watching
Page 19 of 38

of crucial dates in service, Career Planning, Appraisal System, Pay Roll, terminal
benefits etc for approximately 28,000 employees were to be digitised. But it was
observed that the vendor did not comply with contractual agreement with the result
that service related activities like leave account of employees, pay fixation, grant of
increment etc are done manually in the Circle defeating one of the major objectives
of ERP implementation which was to reduce human intervention in various
administrative works.
4. Declaration of Go Live status even before achieving online status in
various modules:
As per terms of the agreement with M/s SISL, ERP was to be commissioned by
March 2005. It was observed (October 2009) that Go live was declared in the year
2007, even though online status was not achieved in many modules and
transactions. The activities like processing of Performance Bank Guarantees,
posting of leave entries, settlement of temporary advances, Leave Travel
Concession (LTC) and Medical claims were processed offline. Moreover, on review
of the Trial Balance and other accounting statements prepared from ERP it was
noticed that in the two years after declaring Go Live more than 65,000 JVs
(document created in ERP for accounting transaction carried out in legacy system)
were prepared during the preparation of final accounts of the Company. It is
expected that there should be minimum possible manual intervention after declaring
Go Live. But absence of interface with other software packages and continuance of
manual system contributed to the preparation of large number of JVs.
5. Customisation and mapping of rules on delegation of financial powers
Customising the ERP package to the requirements of the Company and mapping the
business rules of the Company completely to it was an important stage in the project
implementation. As per Companys accounting policy, sanction from the appropriate
level of Management is a must for incurring any expenditure. It was seen that while
implementing ERP the practice of preparing estimates for maintenance work was
replaced with a system of maintenance orders and no monetary limit was
prescribed for maintenance orders in the Plant Maintenance (PM) module. A review
of the expenditure in PM module for 2007-08 and 2008-09 showed that expenditures
of more than Rs. One lakh in each case aggregating Rs. 44.21 crore were incurred
without the cases being approved through workflow of ERP. This expenditure on
maintenance should have been linked with the workflow so that a watch on such
expenditure could be monitored by top level Management to ensure only
expenditures of maintenance nature are processed thorough Plant Maintenance
module. This led to inflated per line maintenance cost for GTC besides depriving it of
the benefits of depreciation which otherwise would have accrued on the capital
assets booked in PM module.
6. Monitoring of functioning of ERP
For efficient functioning of an IT system, it is important that the Management put in
place effective monitoring mechanism which would facilitate early detection and
rectification of deficiencies. Audit observed the following deficiencies due to lack of
effective monitoring of the functioning of ERP:
In Vadodara SSA it was seen that equipment costing Rs. 1.45 crore received
Page 20 of 38

in August 2007 was taken into stock only in Jan 2008. Though the equipment was
put to use, it neither formed part of Work in Progress (WIP) nor the Fixed Assets of
the SSA for the financial year 2007-08. On being pointed out by audit, it was replied
that the consignment was directly received by the sub-division and only on receipt of
bill for payment the omission was noticed.
In the Company, transfer of stores between different units is frequent and

processing of Advice of Transfer Debits (ATD) is an important activity in stores
transactions. Test check of ATD transactions in Surat SSA revealed that an ATD for
Rs. 43.6 lakh which was supported with invoices was shown in the system as Rs.
20.07 lakh.
As per the Company policy, assets costing less than Rs. 5,000 should be
depreciated fully. It was seen from the data in FICO module that in 792 cases assets
valuing less than Rs. 5,000 were not depreciated fully.
7. Data validation
Efficient data validation procedures are important to ensure the reliability of output
from the system. Audit observed the following deficiencies in the functioning of ERP
due to weak validation of data.
(a) As per existing rules the minimum subscription to GPF should be six per cent of
the pay. However, it was noticed that the system was accepting subscriptions below
six per cent of pay also. On this being pointed out, the Management replied that
validation for GPF subscription would be restored from April 2010.
(b) As per accepted accounting principles, depreciation of an asset should
commence from date of its capitalisation. However, it was observed that date of
capitalisation and date of commencement of depreciation were different in many
cases. Moreover, life of assets was not matched properly and in many cases it was
shown as 999 years.
(c) The currency of assets of Vadodara SSA in depreciation posted sub-module in
FICO was seen as US Dollars (USD) instead of Indian Rupee (INR).
8. User account management
Review of the user account management of ERP revealed that multiple user
accounts existed for the same officer in different capacities within the same SSA or in
two different SSAs and user once created was not being cancelled or deleted on
transfer or retirement of the official. It was also noticed in Surat SSA that bills
pertaining to Civil Division were accepted and passed by logging in as Accounts
Officer, Telecom Electrical Division.
Oil India Limited
Oil India Limited (OIL) adopted SAP R/3 (version 4.7) as its Enterprise Resource
Planning (ERP) software to enable it to integrate its business processes across the
value chain. The total project cost was Rs. 45.04 crore. The ERP system went live in
December 2005. At the time of implementing the system, the Company had carried
out a detailed cost benefit analysis incorporating all tangible benefits that would
accrue by implementing SAP R/3 and projected a benefit of Rs. 14.67 crore per
annum. The benefit, inter alia, was expected to flow mainly from control of inventory
carrying cost, overtime expenditure, fuel oil consumption, repair and maintenance
cost, decrease in surface equipment shutdown time in drilling operations, transport
and other contract cost, etc. Audit scrutiny, however, revealed that the Company
Page 21 of 38

could not get the above benefits entirely, due to inadequate End User Training and
underutilisation of ERP as detailed below:
There is no effective Information Security policy in the Company.
Corporate Financial Management (CFM) module is not being utilised and the
server purchased for CFM is kept under shutdown. The other modules viz. Plant
Maintenance (PM), Human Resource (HR) and Project System (PS) are also
underutilised. Plant Maintenance activities are not being adequately monitored
through PM module due to non updation of Maintenance history, Breakdown details,
job completion status, etc. Manpower Planning is not being carried out in HR
module. Further, HR data is not being updated regularly especially for separation
cases, loan data and new recruits. Daily Progress Report (DPR) for Drilling/
workover and survey activities are not being regularly captured in the PS Module.
Audit reviewed the general performance of two modules of SAP R/3 namely
Financial Accounting and Controlling (FICO) and Project System (PS) which
revealed the following:
1 Financial Accounting and Controlling (FICO)
Financial Accounting and Controlling (FICO) module of SAP R/3 is envisaged to
cater to all the accounting, financial and informational / reporting needs of the
Finance and Accounts Department of the Company. However, the following
deficiencies were observed in the FICO module:
a) Single invoice can be processed for payment more than once in the Cash journal.
b) Revenue budget has not been configured in SAP R/3 and, thus, budgetary
controls on the revenue expenditure could not be exercised.
c) General Ledger Accounts, which are supposed to take automatic direct posting
from other modules (such as Materials Management, Sales and Distribution
etc.), have not been marked for such automatic posting.
d) SAP has not been configured for preventing the use of wrong cost centres.
e) Depletion1 calculation has not been properly mapped. In SAP R/3, depletion is
being calculated on monthly basis, whereas the business process of the
Company requires depletion to be calculated on quarterly basis.
f) The system of allocation of cost to oil wells has not been properly mapped in SAP
R/3. So, the cost of departmental drilling manpower could not be allocated
correctly to oil wells as the allocation cycle could not differentiate between
departmentally operated oil wells and contractually operated oil wells. The
wrong allocation of costs is adversely affecting the well costs and leading to
generation of wrong Management Information System Reports.
g) In cash contra account the original document number is not properly linked with
the assignment field of the document being generated at the time of cash
disbursement. Due to such improper configuration of SAP R/3, cash contra
entries could not be reconciled automatically.
h) SAP R/3 has not been configured to generate Cash flow Statement, Segment
Reporting, etc.
i) Materials, which have already been consumed, are not being booked into SAP R/3
and are reflected in the inventory. The actual status of consumption of
material(s), worth Rs. 91.65 crore (as on 31 March 2009), at various storage
locations could not be ascertained.
j) Statistical Key Figures (SKFs) are not being updated by the respective
Page 22 of 38

departments. So, SAP R/3 could not automatically determine the Statistical
Key Figures (SKFs) for allocating the indirect costs. According to the
Management, the ignorance of respective users in updating the SKFs is the
reason for above anomaly.
k) The records of physical verification of assets are not being updated regularly in
SAP R/3 and the physical existence of assets, valued at Rs. 116.24 crore,
could not be confirmed. The Management could not monitor the physical
existence of assets of the Company through SAP R/3. According to the
Management this is an uploading issue and the same would be addressed.
l) Input controls are not sufficient to prevent the payments of regular nature being
made under the facility of one time vendor payments. Using the One Time
Vendor facility for making payments of regular nature increases the risk of
payment frauds.
2 Migration of data from legacy system
The data uploading into SAP R/3 was done without proper reconciliation and
cleaning. There was around Rs. 247 crore difference between legacy data and the
data migrated to SAP R/3. This fact was noticed by SAP itself, in course of Quality
Review Program after post Go Live Phase.
3 Project System
Project System (PS) module of SAP R/3 ERP system provides the framework for
mapping and processing of project tasks, planning, execution and monitoring of
projects in a targeted and cost-effective way. PS is linked to the SAP R/3 Financial
Accounting, Sales and Distribution, Materials Management, Production Planning,
and Plant Maintenance modules. The following issues were noticed during the
course of audit of Project System module of SAP R/3:a) Budgetary checks are not operating at the time of raising Purchase Requisitions
(PR) for contractual services. Audit noticed that Purchase Orders, valuing Rs.
12.30 crore were raised against PRs without reflecting commitment value,
during the period from 2006 to 2009.
b) Contract Work Order (CWO) can be created in SAP R/3 with unknown account
assignment bypassing budgetary controls. Audit noticed that sixty seven (67)
work orders valuing Rs. 11.09 crore were issued with unknown account
assignment during the period from 6 December 2005 to 30 April 2009.
c) Cost planning of the Work Break-Down Structures (WBS 2), except the material
cost, through network is not being done. Hence, the actual versus plan cost
against WBS does not reflect the correct scenario.
Hindustan Paper Corporation Limited
Hindustan Paper Corporation Limited (Company) was using Integrated Business
Information System (IBIS) for invoicing, sales and purchase accounting purposes. In
2003, the Company decided to implement the ERP solution for its various activities
and accordingly, Oracle e-Business Suite, an ERP solution by Oracle Corporation,
was selected through a global tendering process. Tata Consultancy Services Limited
was the implementation partner and WIPRO was the vendor for supply of the
production server. The ERP system, installed in Nagaon Paper Mill (NPM), Assam of
the Company, was made operational in April 2006 at the cost of Rs. 7.70 crore. As
per Memorandum of Understanding (MOU) (2002-03) with the Government of India,
Page 23 of 38

implementation of ERP was to be completed by March 2003. However, it was
noticed that the order for implementation was issued only in January 2005 and the
ERP system went live in April 2006, with a delay of three years. The delay was
primarily due to procedural delays attributable to the Management.
1 Anticipated benefits of ERP
The anticipated financial benefits of implementing ERP worked out to Rs. 13.07
crore over five years period mainly by way of savings in inventory carrying cost
through reduction of procurement cycle. Intangible benefits such as accuracy of
payment against material receipt, online availability of cost sheet integrated with
production/ sales data, accurate information of real-time customer balance helping
faster and error-free invoice-processing and dispatch operations were also expected.
The following tangible benefits as envisaged could not be achieved:
a) Against anticipated reduction of average procurement cycle time from 18 weeks
(2003) to 10.8 weeks, actual average procurement cycle time for the period
200609 was found to be more than 28 weeks.
b) 20 per cent reduction in inventory holding was also envisaged during post
implementation period. This could not be achieved as with similar levels of
turnover, the inventory levels remained almost same during 2006-2009.
2 General controls
Following deficiencies in general controls were noticed:
There was no documented Information Technology Policy.
Some of the security parameters as recommended by ORACLE were not

configured but retained as default values.
The user management was deficient which exposed the system to the risk of
unauthorised use and loss of audit trail and difficulty in tracing the identity of the
unsuccessful login.
3 Input control and validation checks
The following deficiencies were noticed in this regard:
Changes in price of finished products were not immediately uploaded in the

system. Consequently, sale of products in the intervening period was made at old
rates necessitating manual corrections by way of raising debit/credit notes. Analysis
revealed that on 81 occasions, the delay in changing price list ranged between 1 to
48 days. This increased the risk of errors and omission.
215 codes had been allotted to 78 customers indicating that customers were
allocated more than one code and the customer names were almost similar but their
Customer ids were different and goods were sold to the same customers under
different customer IDs. The existence of duplicate customer IDs may lead to the risk
of extending additional credit facilities to a single customer.
Analysis revealed that 1,090 inventory items were allotted more than one
code and separate stocks exist for 51 duplicate items. In case of 223 items, material
descriptions were not available in the system.
Though the quantity ordered for 3,663 items against 488 purchase orders had
Page 24 of 38

been fully delivered, the purchase orders remained open.
4 Business Process Mapping
Due to improper mapping of business rules the manual intervention was required
which resulted in non achievement of the intangible benefits as envisaged. In this
regard the following was observed:
Sale of finished product can be made either on credit or against cash/advance

payment. For cash payments, the customer is entitled to get a cash discount based
on the payment terms. In this connection, it is observed that for cash sale, payment
received from the customers is to be attached to the delivery orders generated. It
was, however, noticed that system permitted generation of delivery orders without
entering such payment details. Hence, there is a risk of delivery of finished goods
without payments and since cash discount is automatically calculated in the system,
there is a risk of incorrect billing also.
The system accepted the entry of same cheque/DD numbers against different
sales invoices. This may lead to the risk of incorrect adjustment of credits against
the sales, which necessitated further supervisory controls.
In the case of credit sale, deliveries were made against receipt of post-dated
cheques. It was, however, observed that system has not been customised to accept
post-dated cheques against credit sales which resulted in monitoring of such sales
through manual registers.
There is no provision in the system to levy penalty for quality and quantity
shortage and to calculate the Liquidated Damages for delay in supply of materials
though details relating to quality were available in the system. These were calculated
and fed in the system manually thereby increasing the risk of inaccurate calculation
besides underutilizing the system.
In case of rejection of goods by the customer, neither the returned items could
be taken in the stock nor could the accounting entry be passed immediately leading
to overstatement of sales and sundry debtors. This indicated that the system is
deficient in accounting the material return against direct sale.
Reports like Monthly Segment Report, Monthly Stockist Off Take Report etc.,
required for MIS purpose continued to be maintained separately for want of
customisation of the same in the system.
Rashtriya Chemicals and Fertilizers Limited
Rashtriya Chemicals and Fertilizers Limited (Company) issued (November 2004) a
work order for implementation of mySAP ERP with SAP R/3 Enterprise Version 4.7
on turnkey basis to Siemens Information Systems Limited, Mumbai at a lump sum
price of Rs. 3.47 crore. This included Rs. 1.72 crore towards 250 user licences of
mySAP ERP and Rs. 1.75 crore towards design, configuration, installation and
implementation of selected core modules. The Company incurred an expenditure of
Rs. 1.67 crore for procurement of hardware. The project went Go live on 1 January
2006.
Audit assessed the implementation and usage of the Material Management Module
controls and the security of the system which revealed the following deficiencies:
4.2.4.1 Business Process Mapping
Implementation of an ERP solution across the Company is to ensure integration of
Page 25 of 38

various business processes as far as possible. However, following deficiencies in
mapping of business rules were noticed:
(i) Logically, Purchase Requisition date should precede Purchase Order date. It
was observed that in 51 cases the Purchase Requisition dates were after
Purchase Order dates.
(ii) There was no online system of creation, approval and release of both Purchase
Requisitions and Purchase Orders. In case of raw materials the system was not
configured for release of Purchase Requisitions. The system followed by the
Company was to obtain approval on the file manually and input the data into the
system later.
(iii) Purchase Requisitions were created and released in the system for procurement
action. It was observed that in respect of 4,464 cases even though quotations were
invited, no further action was taken. Similarly, in 4,113 cases, no procurement action
was taken. There was also no provision in the system to capture the reasons for
pending Purchase Requisitions.
(iv) As per the delegation of powers, Deputy General Manager has powers to release
Purchase Orders upto Rs. 5 lakh only. The powers to be exercised by General
Manager and above were exercised by Deputy General Managers and officers below
the rank of Deputy General Managers which indicated absence of participation and
commitment.
(v) In respect of 146 cases, Purchase Orders released during the period from 1 April
2006 to 31 March 2008, valuing Rs. 5.13 crore where delivery was completed and in
1,342 cases valuing Rs. 1,390.68 crore where partial delivery was completed, the
Purchase Orders were still open (August 2009).
(vi) There was no provision in the system to generate MIS Reports of pending
Purchase Requisitions. The system was also not configured to indicate reasons for
delay.
(vii) In 7,974 cases, valuing Rs. 51.57 crore, the time gap for converting Purchase
Requisitions to Purchase Orders ranged from 90 days to more than 540 days. The
Company had not fixed any time schedule for issue of Purchase Orders from the
date of release of Purchase Requisitions in the system.
(viii) In 22,051 cases the Purchase Orders were issued on the same day or after the
expected delivery date specified by the requisitioner.
4.2.4.2 Non-utilisation of SAP
The data relating to availability and consumption pattern of materials available in the
SAP system was not utilised for decision-making as detailed below:
(i) The Company after implementation of SAP procured materials worth Rs. 1.23
crore between 1 April 2006 and 31 March 2009 in spite of non-moving stock of the
same materials worth Rs. 0.91 crore as on 1 April 2006.
(ii) After implementation of ERP, there should have been reduction in the inventory
holding. It was, however, observed that the inventory of non-insurance domestic and
imported spares increased by Rs. 18.42 crore from Rs. 129.94 crore as on 1 April
2006 to Rs. 148.36 crore as on 31 March 2009. The inventory as on 31 March 2009
included unmoved items worth Rs. 68.25 crore (46 per cent) during the period from 1
April 2006 to 31 March 2009.
(iii) Material Requirement Planning (MRP) facility to monitor and maintain minimum
and reorder stock levels for critical materials has not been utilised.
Page 26 of 38

(iv) The SAP system has provision for capturing data relating to delivery schedule of
materials ordered and levy liquidated damages wherever necessary. However, the
enforcement of liquidated damages clause as per agreement in respect of
late/undelivered Purchase Orders was not built into the system. During the year
2008-09, the Company recovered liquidated damages amounting to Rs. 2.12 crore
based on manual calculation.
(v) There were 2,075 cases (Rs. 2,240.51 crore) of partly delivered Purchase Orders
issued upto 31 March 2009 for which reminders were not generated through the
system and were issued manually despite reminder feature available in SAP.
(vi) The vendor-wise and material-wise lead-time details were not captured in the
system. In the absence of which the delays in delivery of materials could not be
monitored through the system.
(vii) There was no provision to capture and track shelf life and the expiry date of the
inventory. In the absence of such provision, the system could not prompt the users
for impending obsolescence and the risk of belated decisions for procurement,
replacement and disposal of obsolete inventory continued.
(viii) The system was not configured to capture inventory of repaired/repairable items
and the spares used for their repair/overhauling. Due to non-maintenance of these
details, inventory control could not be exercised over such items besides analysis of
frequency of repair and economies of repairs over new purchases was not possible.
(ix) The provision to capture information relating to warranty/guarantee terms of the
materials procured was not available in the system. Absence of this provision posed
the risk of failure to use/test the usability of the equipment within the
warranty/guarantee periods and to invoke the same wherever the situation
warranted.
Indian Oil Corporation Limited
Indian Oil Corporation Limited undertook an IT re-engineering project named
Manthan in 1997 and selected SAP R/3, ERP package with IS-OIL (specific ERP
solution that caters to the needs of SAP R/3 users amongst the oil industry). The
project was implemented in April 2004. The Company has around 10,000 users and
700 sites spread across the country working on SAP. Users from distant parts of the
country are able to access and make transactions in SAP on a real-time basis.
The Company has kept its Database and Application servers at the corporate data
centre, Gurgaon and they are accessible through leased line and / or VSAT 3 from all
State Offices, Refineries and Pipeline Unit Networks. Other units such as Terminals,
Depots and Bottling Plants etc., are connected to SAP through the nearest State
Office / Refinery. Along with the e-security audit of the system the finance module of
SAP was also selected for audit.
1 e-security
The IT security review broadly covered the IT security environment in the Company
and Roles and Authorisation in SAP system to conform to the Companys
requirements. It was observed that the IT environment of the Company was not
adequately secured as detailed below:
Rationalisation of Users roles and authorisation and segregation of duties

was deficient. It was noticed that 29 combinations of two or more conflicting critical
transaction codes involving processing sale orders / invoices / deliveries, payments,
Page 27 of 38

creation, settlement, change, deletion etc were extended to many users ranging from
18 to 4,808. The Management in its reply stated (September 2009) that roles and
authorisation have to be attached to a number of employees to fulfil and meet our
minimum operation, supply and distribution and logistic requirements. However, the
Management did not assess the risk involved while extending a critical combination
of authorisations to various users in the system.
88 users other than the BASIS team 4 was given access to the sensitive
Transaction Codes5.
There was laxity in the password policy of the Company which allowed
simple, trivial and non-alphanumeric passwords to be entered which made the
system vulnerable to security threats internally. The Management stated (September
2009) that considering the size and level of the user base and optimal operational
convenience, security measures were being implemented in a phased manner.
The users profile was not properly defined to which the Management replied
(September 2009) that updating user groups and other details was a continuous
process and concerned groups were taking action from time to time.
Out of 13,451 user IDs, 955 user IDs were common i.e. used by more than
one user. The Management in its reply stated (September 2009) that common users
had display authorisation only for reporting purposes. The Managements reply is
not factually correct as on verification it was found that Common User IDs were still
carrying create / change / cancel / delete authorisations.
In the absence of corporate IT policy, different virus, malware, spyware

protection softwares being used at different offices and sites. Further, internet
content could not be filtered through a uniform firewall policy. At Companys
Information Hub, it was observed that (a) although a fire wall was in place at the
premises, the firewall rules to censor the web content and monitoring were yet to be
framed and (b) the firewall in place was not enough to maintain a log of instances of
attempts and instances of actual breach into the Companys Network / firewall
internally or externally. The Management accepted the observation (September
2009) and informed that they were trying to ensure Network Security through a policy
which was being finalised.
2 Finance module
Finance Module (FI) is designed for management of the processes involved in
preparation of the accounts. The FI Module has inter-linkages with all the modules in
the ERP system and consolidates all the financial information to generate the
financial statement of the Company. The IT audit has been conducted keeping in
view the importance and criticality of the efficacy of FI module in the preparation and
generation of the accounts of the Company. The following deficiencies were
observed in the finance module due to which the reports generated from the system
could not be relied upon:
The date of commencement of depreciation was 3 to 14 months prior to the

date of capitalisation in respect of 15,805 assets and it was 1 to 15 months after the
date of capitalisation in respect of 4,391 assets.
Depreciation rates as per Schedule XIV of the Companies Act were not
adopted in respect of 2,550 assets.
The quantity was indicated as zero in 27,011 assets worth Rs. 652 crore and,
thus, the correctness of depreciation provided could not be ensured.
Page 28 of 38
Analysis of purchase orders/Work orders released through the system

showed that in respect of service contracts, POs/WOs were created (19,406 in 200708 and 12,705 in 2008-09) in the system only at the time or after the receipt of
goods/invoices for the services rendered (details given to the Company).
GR/IR is an intermediary account used for payments against goods received.

Analysis showed that more than three lakh entries amounting to Rs. 2091.12 crore
were pending clearance ranging from one to four years indicating lack of proper
monitoring by the Company.
It was observed that, though the stock balances are maintained in the system
the valuation of stocks is done outside the system which defeated the purpose of the
ERP system.
The Company decides and assigns credit limits to various categories of

customers which are accordingly entered into the system. Analysis of data on credit
limit extended to customers showed that, there were inadequate validation checks
with the credit limits maintained in the system that resulted in overdue amount of Rs.
294.89 crore in respect of 293 customers who had exceeded their credit limit.
Each customer is allotted a unique code. However, there was more than one
customer code assigned to the same customer in 1,552 cases in the customer
master.
Neyveli Lignite Corporation Limited
Neyveli Lignite Corporation Limited has an integrated power generating facility
consisting of lignite mines and Thermal Power Stations. The Material Management
(MM) Department of the Company centrally controls the inventory management of
the Company catering to the needs of all units through sub stores attached to the
respective units. The Company was using a COBOL based batch processing system
for its inventory management. In March 2002, the Company placed an order on the
Indian Institute of Technology (IIT), Kharagpur for development and implementation
of Online Integrated Material Management System (OLIMMS) at a cost of Rs. 2.05
crore with the objective of re-engineering the existing legacy system to make it more
responsive to reduce ordering costs by at least 40 per cent and lead time by at least
50 per cent and automation of demand forecasting and scientific inventory control for
all items including slow moving spares etc. The Company implemented OLIMMS in
October 2006. However, it was observed that the desired benefits were not accrued
to the Company as detailed below:
Better Inventory control could be achieved through well defined Decision Support
System (DSS) comprising of Economic Ordering Quantity (EOQ), Re-order Quantity
(ROQ), Re-order Level (ROL), Safety stock, Minimum Level, Maximum Level etc.
This would require data on procurement and consumption for three to five years
which could lead to reduction in ordering cost, optimal inventory holding and
minimum inventory carrying cost. The Company is having a system generated DSS
for economic indenting purpose. The system generates an economic quantity for
each and every material based on past consumption pattern, whenever an indent is
raised. However, during implementation of OLIMMS, the Company could not import
the legacy data and, hence, could not use the data available for effective inventory
management as per the above said inventory levels.
The indented quantity in respect of 5,979 out of 33,787 material codes was in
excess of system calculated economic quantity up to 100 times. This indicated non
Page 29 of 38

observance of control over the system as per the system generated economic
quantity. It was further observed that though OLIMMS provided for recording the
reasons thereon, in majority of the cases (4,823 cases) no reasons were found
recorded.
The closing stock value of stores and spares as at the year end exhibited in
the financial reports comprised of stock balance generated from OLIMMS and the
value of materials lying at site as reported by respective units through the reports
prepared manually. Manual intervention in this regard affected the true and fair view
of financial reports.
The delivery status, in respect of 498 Purchase Orders against which more
than 90 per cent of the ordered quantity was received, was still indicated as partial
supply instead of treating them as completed. In respect of 37 purchase orders
against which the ordered quantity was received in full, the delivery status still
indicated as partial supply.
Security controls
The MM Department did not have an approved/documented IT Security policy.
Data analysis showed that users have been allowed to have many IDs (2 to
29 IDs). Multiple user IDs would result in weak monitoring practice.
The Company did not have a documented/approved password policy. Data

analysis showed that same password is being used by many users. For example out
of 6,426 active User IDs available, 4,503 users (70 per cent of the users) including
many senior level officers having approval authority in the work flow hierarchy, use
the same password. As the Company has a customary practice of using a particular
employee related information as user ID, risk of unauthorised access to the system
was large, since common passwords were used and the user IDs were easily
predictable.
BEML Limited
BEML Limited was earlier using various in house developed applications for finance,
planning, purchase and inventory. In order to ensure effective utilisation of the
Company resources and also to ensure connectivity among various divisions,
corporate office, marketing division including its regional and district offices, the
Management decided (August 2004) to implement companywide Enterprise
Resource Planning (ERP). The Company selected SAP-ERP (mySAP ERP) software
for implementation covering basic modules. SAP system was implemented (October
2007) by Siemens Information Systems Limited (SISL) at a cost of Rs. 6.80 crore.
Later, in order to strengthen the Business operations, the Company procured and
implemented SAP-Supply Chain Management software through SISL at a cost of Rs.
6.00 crore. Audit scrutiny revealed that the Company could not realise the above
benefits entirely, due to the following:
SAP system allowed posting of the transactions relating to two months at any
given point of time i.e. previous month and current month. Normally if the system
was an on-line one, the data entry on the respective months would be allowed on the
first of every month, so that the transactions can be captured as it happens.
However, opening of the periods got delayed (up to 87 days) due to back log of data
entry indicating system has not been made on line even though the system was
made Go Live in October 2007.
Page 30 of 38
Though SAP provided for mapping of various delegations of powers for

release of purchase orders, sale orders, etc., the same were not mapped into the
system.
The Company continued uploading the materials balances even after the
system went (October 2007) Go live indicating incomplete migration of data into the
system. As uploading of materials has one sided influence on inventories and its
values in the financial accounts, these transactions should be avoided after Go live
of the system.
Audit also reviewed the general performance of two modules of SAP, i.e., production
planning and materials management modules, which revealed the following:
Production planning
Due to the back log of data entry the validation checks built in SAP system were not
enabled and the system accepted:
the dates of delivery of finished goods prior to the date of opening of the
production orders;
drawal of material even before opening of the respective production order and
after the completion of such manufacturing activity;
closing of production orders and delivery of goods even when there were
incomplete drawal of materials required for production;
the dates of invoice/billing prior to date of opening of respective production

orders;
issue of materials even before receipt of materials from the suppliers resulting
in issue of 1,323 materials valuing Rs. 185.50 crore during March 2009; and
676 purchase requisitions with the requirement dates prior to the request
date.
From the above, it may be observed that there were inconsistencies in the dates
relating to various stages of the production orders; purchase requisition dates and
drawl of materials for the production. Hence, the data relating to the production
planning available in the system was not reliable and dependable.
Materials management
The following discrepancies were noticed in the material management module:
It was observed that system accounted the materials and delivered the
materials without the quality inspection checks due to deficient validation checks.
On test check of some of the materials in the inventory, the system permitted
the issue of materials by adopting other than the then existing weighted average
rates. The
The system released payment of Rs. 18.10 crore due to one vendor/supplier
through another vendor indicating that the controls for effecting payments to relevant
vendor through Company account were absent. Similarly, system accepted payment
related to a sale of equipment from the customer other than the customer invoiced.
In the year 2008-09, while accounting the transfer of materials valued at Rs.
4.01 crore from manufacturing divisions to marketing divisions, instead of reducing
inventory account, the same has been accounted as expenditure in Profit and Loss
account.
Page 31 of 38

Inventory Management
Bharat Electronics Limited Information Technology Audit on the
computerisation of inventory management at Bangalore Complex:
1
Non-adjustment of finished Goods (FG) stock in the event of reversal of sale
2
Drawal of material in excess of Bill of Material (BOM) quantities
3
Non-netting of quantities while processing Purchase Requisition (PR)
4
Non-closure of work orders after completion
5
Discrepancies in comparable stock data between MRP-II and IFAS
Deficiencies in General Controls:
(i) In HF Division - Computer Centre, no written approvals for providing
access to the staff were available.
(ii) In Central Material Management Department, general authorisation was
given to 68 employees without making proper analysis of minimum
access requirement to discharge their duties.
(iii) Report and Query rights (read only) associated with the module were
provided generally to all the employees, working in the respective
module, without making analysis of need to know/need to work.
(iv) Based on the Audit observations, the Company issued instructions to all
Departmental Heads to review and confirm permission already given to
each user and to advise the Computer Centre in writing about changes, if
any.
(v) The Company had not assessed the exact requirement of software
licences and had not procured the required software wherever necessary.
(vi) Passwords were changed monthly instead of fortnightly and special
characters were not enforced.
(vii) Audit trails and Audit Logs, though enabled, were not periodically
reviewed.
Garden Reach Shipbuilders and Engineers Limited
Material Management in the ERP system
6
7
8
9
1. Shortcomings in customization:
Missing description of programs
Duplication of programs
Deficiencies in logical access control
Password policy:
(i) The length of the password can be checked through a system
setting. Against the recommended minimum password length of
five characters, the Company set a minimum length of only three
characters.
Page 32 of 38

(ii) Recommended change of users passwords is within 30 days. It
was noticed in audit that 63 users of 71 users did not change
their passwords for a period ranging from 7 months to 48 months.
(iii) To ensure that easy-to-guess passwords are not used by the
users, the list of prohibited passwords which exists in the system
has to be populated. Scrutiny, however, revealed that this had not
been done. As a result, there was a possibility of some of the
users creating easy-to-guess password thereby putting the
system at a risk of unauthorised access.
10
Logon activity:
(i) To ensure that other users do not access the system during the
authorized users absence, a time limit can be set on the period
of inactivity before the system logs the user out of SAP. The
Company has set this parameter at 5400 seconds (90 minutes)
which was high.
(ii) Users IDs and passwords should not be shared as it would be
difficult to identify the user who is responsible for security breach,
if any. It was observed, however, that several users were using
one user ID on different terminals simultaneously. This indicated
that the user IDs and passwords were known by more than one
user or the user allowed unauthorised access to the system,
thereby compromising the security of the system.
11
Standard user protection

When SAP is installed, certain standard users are automatically
created with default passwords which are commonly known. To
prevent unauthorised use of such users, the default passwords
should be changed. These users should then be de-activated by
activating a system parameter setting. It was noticed in audit that
these users had not been deactivated. This resulted in the
system being exposed to the risk of unauthorised access. In a
test check, Audit could access the system by using one such
user ID with its default password.
2. Observations on material management module

12
1.
2.
3.
4.
5.
6.
7.
8.
Input and validation controls

Inconsistent codes and duplicate description in the material master
Updation of master data
Different units of measurement for same material
Duplicate vendor codes
Inconsistencies in delivery and purchase order dates
Inconsistencies in purchase requisition release date and purchase order
date
Purchase documents without material code
Valuation of stock as per accounting policy
Page 33 of 38

9. Scrap/off-cut material being processed manually
Oil and Natural Gas Corporation Limited
IT Audit of Material Management
Input Controls
1.
2.
3.
4.
Purchase orders for stores and spares items with wrong valuation types
Purchase orders for capital items with wrong valuation type
Delivery date in purchase orders
Creation of fresh purchase requisitions with earlier requisitions
remaining pending
5. Non clearance of stock in transfers
6. Delay in recording of material consumption
7. Insurance spares
Mapping of business rule
1. Material procurement planning: Analysis of inventory holding of material
vis--vis consumption to find out the extent to which the stock holding was in
consonance with the actual requirement or consumption revealed that there
existed 6512 items (material codes) each of average stock value exceeding
Rs.one lakh, consumption of which during 2005-06 was nil. Based on the
value of the average stock holding during 2005-06, funds invested on these
inventory items amounted to Rs.523.09 crore. Included in these items were 47
stores items costing Rs.177.38 crore and six spares items costing Rs.11.52
crore of average stock value over Rs.one crore. Further month-wise stock
analysis, since implementation of the ERP system, of items with average
stock value over Rs.50 lakh revealed 62 items with nil consumption during the
entire period. The average stock value of these items amounted to Rs 139.66
crore in March 2006.
2. Purchase requisition release dates: It was observed that the release date
field in the purchase requisitions in the system automatically captured the
date as one day prior to the date of delivery of material indicated in the
purchase requisition instead of actual date of release. Capturing of wrong
date of release, which was a vital key indicator resulted in vitiating any
analysis or MIS generation involving date of release of the PR due to wrong
capture of data in the SAP reports.
3. Open purchase orders with small residual quantity: In case where the
finally delivered quantity of material against a purchase order was
marginally less than the ordered quantity and the remaining ordered quantity
was not expected to be delivered, the purchase order was to be closed as
completed so that funds attached therewith were freed for other use. The ERP
system had neither been configured to close or trigger the closing of such
purchase orders nor did the MM function generate periodical reports from the
system to close such open purchase orders. Due to non closing of such type
of open purchase orders, the material and funds attached to such quantities
remained blocked during the year. Analysis of open purchase orders for the
period October 2003 to March 2005 with delivery date before 30 September
2005 and residual quantity of less than 10 per cent of the ordered quantity as
in July 2006 revealed that 240 purchase orders of this nature involving funds
Page 34 of 38

of Rs.3.39 crore were yet to be closed.
Data migration
1. Material master data:
1 It was observed that 16780 master records were migrated into the ERP
system without complete codification details out of which 3880 records
were not associated with any material in the master table. As the primary
details of the material were missing in these records, transactions
concerning these materials could not be made. The inventory lying against
these material codes since October 2004 amounted to Rs.3.52 crore. It
was also observed that subsequent to the data migration, ICE MM core
teams, responsible for creation and maintenance of the Material Master
data further blocked 4043 discrepant master records to prevent the users
from making any procurement against these material codes.
There were 801 records of spares items in the master table without details
of part numbers. So, these records provided insufficient details to the
users for placing indent on inventory management and for MIS generation.
Similarly, 56741 records with missing manufacturer name were also found
among the spares items.
In order to check the correctness of data during the data migration from
the legacy system into the new system, Audit analysed sample data that
was uploaded into the MM module. Comparative study of the migrated unit
price vis--vis the current moving average prices revealed that the former
was abnormally higher than the latter. This indicated that the data migrated
from legacy system was unreliable.
Oil India Limited
Material Management System
Input controls
1. Absence of primary details of material:
following:
Review in audit revealed the
(i) Standardisation of description was not done;

(ii) Description in respect of 45 materials valuing Rs.1.72 lakh was incorrect;
(iii) Manufacturers names were not incorporated in the material master;
(iv) Out of 38095 stock materials, part number was not mentioned in respect
of 18358 materials;
(v) Detailed specification did not exist in respect of 10745 materials valuing
Rs.8.42 crore; and
(vi) Duplicate material descriptions were noticed in the material master and in
respect of 224 materials valuing Rs.14.90 lakh, 1069 material codes existed.
2. Existence of incorrect material group
3. Discrepancies in vendor master:
(i) Classification data like annual turnover, manufacturer, distributor, retailer
and trader were not maintained.
(ii) Incorrect grouping under SSI and PSU.
(iii) Naming convention was not consistent.
(iv) Duplicate/multiple vendor code continued to exist in the system.
4. Wide variation in values of same materials at two storage locations
Page 35 of 38

5. Carrying of material at low value: It was observed that materials, which
were written off during earlier years , were uploaded in the system at their
residual value of five per cent. The value of such materials was Rs.2.08 crore
and Rs.1.49 crore as on 31 March 2006 and 31 March 2007, respectively. On
a review (June 2007) of data in the system, it was noted that materials valuing
Rs.28.84 lakh were issued to capital jobs up to 31 March 2007 at residual
value instead of at full material value. Thus, capital jobs were under charged
to the extent of Rs.5.48 crore. Further, these materials were also issued on
loan to other companies (Rs.8.11 lakh) and contractors (Rs.34.54 lakh).
Therefore, in case any recovery was to be made from outside parties there
was a risk of under recovery as compared with the actual value of materials.
6. Existence of capital and stock code for the same material: Audit found
that purchase of stock material like line pipe, cable, cement, coupling, elbow,
gasket and valve were made as non-stock material and capital material. As
per the accounting procedure, unconsumed stock and non stock material of
the project is returned to store. In case of capital materials which were fully
charged to the capital job, such portion of the material that remained
unconsumed could not be taken back into the store records.
7. Delay in posting of goods issue and receipts: It was noticed in audit
that:
(i) there was delay in posting of 2697 goods issue documents valuing
Rs.12.28 crore towards cost centers and capital jobs by periods exceeding 30
days;
(ii) due to delay in posting of the material documents referred to above,
material consumption amounting to Rs.80.22 lakh (Rs.78.02 lakh in 2005-06
and Rs.2.20 lakh in 2006-07 ) was accounted for in the following financial
years;
(iii) posting of 8410 goods receipt documents valuing Rs.119.75 crore was
delayed for periods more than 30 days. As a result, goods receipt documents
amounting Rs.42.89 crore of 2005-06 and Rs.41.21 lakh of 2006-07 were
accounted for in the following financial years; and
(iv) data pertaining to the period Jan 2006 to June 2007 revealed that in 2020
cases (Rs.15.73 crore), there were delays ranging from 30 to 496 days in final
posting after the materials were provisionally accepted.
Validation checks
1. Change date of purchase requisition earlier than its creation date and
anomaly in change history:
(i)
Purchase requisition date and any subsequent change date in the
requisition are system created dates. Analysis of purchase requisitions
revealed that in three cases, date of change of purchase requisitions were
earlier than its creation date.
(ii)
Purchase order number is generated automatically in the system. In
one case, the system did not show any purchase order number but purchase
order date was indicated.
(iii)
There was anomaly in last change date of purchase requisition as in
one case, two different dates were shown in two places in the system. In this
Page 36 of 38

case, the requisition was flagged as closed but in the change history 1 no
detail of its closing was indicated. As a result of the anomaly in change
history, complete and correct picture on processing of document from
creation to latest status was not available in the system.
2. Expected/scheduled delivery date in the purchase requisition and
purchase order earlier than requisition/order date
3. Creation of purchase order without reference to RFQ
4. Excess withdrawal of material against reservation
5. Placement of PO on blocked vendor
6. Release of PO beyond authorization
Failure to capture complete data
1. Slow moving stores and spares: No provision is made in the ERP system
for analysis of slow moving item of stores and spares by importing from the
legacy system the necessary information like last issue dates and last receipt
dates of materials. The Company has also not developed customised report
for analysis of slow moving material.
2. Non stock items: According to the Management, stock items based on the
physical verification were uploaded into the system and non-stock items were
not uploaded into the system. Review in audit revealed that the Company held
non stock materials amounting to Rs.17.29 crore and Rs.32.65 crore as on
March 2006 and March 2007, respectively. Evidently, at any point of time
some non-stock materials would remain unconsumed and should be suitably
reflected in the data base.
Incorrect/inadequate business mapping
1. Insurance spares: In the Material Master, 209 materials valuing Rs.8.66
crore were flagged as insurance spares as on 31 March 2007. It was noticed
in Audit that these materials were considered as a part of inventory instead of
being capitalised as required by Accounting Standards issued by Institute of
Chartered Accountants of India. Thus the system was not mapped to take
care of the above mentioned provisions of the Accounting Standards
2. Old reservations remaining open without any withdrawal or partial
withdrawal: In terms of business blue print, automatic closure of the
reservations in the system was required if the material was not withdrawn
within 15 days. It was noticed in Audit (June 2007) that in respect of 2036
reservations, goods were either not issued or partially issued. However,
reservations were not closed for the period ranging from 3 to 15 months.
Thus, the system was not configured for automatic flagging for deletion of
reservations even for long pending reservations. Delayed or non closure of
old unwanted reservations leaves scope for possible irregular practice.
Out put control
1. Business warehouse module: Business Warehouse (BW) module contains
reports which are generated based on SAP R/3 database on all aspects of the
business of the Company. Review of reports relating to material management
Page 37 of 38

analytics revealed the following discrepancies:
(i) Procurement lead time analysis for the year 2006-07 in the BW module
considered 1473 purchase orders. However, a total 3540 purchase orders
were issued during this period.
(ii) As per the stock values for stock and non-stock items shown in BW report
the stock, as on 31 March 2007, stood at Rs.294.86 crore whereas in ERP
database it was Rs.296.05 crore.
Page 38 of 38

Introduction To Erp

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Erp

Uploaded by

Copyright:

Available Formats

AUDITING IN ERP ENVIRONMENT

External Design. Detailing the design for a selected solution, including

Internal Design. Building, testing, installing, and tuning software.

Pre-implementation. Evaluation and acceptance

Implementation. Implementing systems.

Post-implementation. Evaluation of controls and debugging.

An analysis of the objectives, requirements, and system concepts.

AUDITING IN ERP ENVIRONMENT

ERP System Architecture

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

Overview of Risks Exhibit 2.1 Risks and exposures for ERPLC

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

In the Company, transfer of stores between different units is frequent and

AUDITING IN ERP ENVIRONMENT

There is no effective Information Security policy in the Company.

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

There was no documented Information Technology Policy.

Some of the security parameters as recommended by ORACLE were not

Changes in price of finished products were not immediately uploaded in the

AUDITING IN ERP ENVIRONMENT

Sale of finished product can be made either on credit or against cash/advance

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

Rationalisation of Users roles and authorisation and segregation of duties

AUDITING IN ERP ENVIRONMENT

In the absence of corporate IT policy, different virus, malware, spyware

The date of commencement of depreciation was 3 to 14 months prior to the

AUDITING IN ERP ENVIRONMENT

Analysis of purchase orders/Work orders released through the system

GR/IR is an intermediary account used for payments against goods received.

The Company decides and assigns credit limits to various categories of

AUDITING IN ERP ENVIRONMENT

The MM Department did not have an approved/documented IT Security policy.

The Company did not have a documented/approved password policy. Data

AUDITING IN ERP ENVIRONMENT

Though SAP provided for mapping of various delegations of powers for

the dates of invoice/billing prior to date of opening of respective production

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

Standard user protection

2. Observations on material management module

Input and validation controls

AUDITING IN ERP ENVIRONMENT

AUDITING IN ERP ENVIRONMENT

Review in audit revealed the