Professional Documents
Culture Documents
System Document 2702
System Document 2702
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:
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 system’s 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 archi-
tectures) 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 50—100 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 in-
creases 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.1a—3.2e, which include the operational environment and
maintenance phases.
Page 3 of 39
AUDITING IN ERP ENVIRONMENT
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 system’s 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 system’s 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.
Risk Analyses
A risk analysis of an organization’s 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:
implementation of new technology. Numerous studies imply that there is often too
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:
individual to spend much time browsing undetected through file cabinets or other
manual storage areas.
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:
Page 9 of 39
AUDITING IN ERP ENVIRONMENT
process.
Concentration of Responsibilities
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:
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
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 individual’s 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 non-
Page 12 of 39
AUDITING IN ERP ENVIRONMENT
working-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.
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
Page 13 of 39
AUDITING IN ERP ENVIRONMENT
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.
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:
The plan of organization and all the methods and procedures adopted by
the management of an entity to assist in achieving management’s 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 be-
yond 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 organization’s 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 effi-
ciency 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 organization’s internal control
structure must meet several control objectives to prevent, detect and correct errors,
Page 16 of 39
AUDITING IN ERP ENVIRONMENT
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
objectives that an author should look for are:
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
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 cus-
tomer 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 39
AUDITING IN ERP ENVIRONMENT
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.
Page 20 of 39
AUDITING IN ERP ENVIRONMENT
• In Vadodara SSA it was seen that equipment costing Rs. 1.45 crore received
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.
Page 21 of 39
AUDITING IN ERP ENVIRONMENT
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
Page 23 of 39
AUDITING IN ERP ENVIRONMENT
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,
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.
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
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:
Page 25 of 39
AUDITING IN ERP ENVIRONMENT
controls and the security of the system which revealed the following deficiencies:
(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
Page 26 of 39
AUDITING IN ERP ENVIRONMENT
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.
(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 Company’s
requirements. It was observed that the IT environment of the Company was not
Page 27 of 39
AUDITING IN ERP ENVIRONMENT
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
Page 28 of 39
AUDITING IN ERP ENVIRONMENT
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
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
Page 30 of 39
AUDITING IN ERP ENVIRONMENT
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.
• 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
Page 31 of 39
AUDITING IN ERP ENVIRONMENT
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 32 of 39
AUDITING IN ERP ENVIRONMENT
Inventory Management
1. Shortcomings in customization:
•6 Missing description of programs
•7 Duplication of programs
•8 Deficiencies in logical access control
•9 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 33 of 39
AUDITING IN ERP ENVIRONMENT
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 38 of 39
AUDITING IN ERP ENVIRONMENT
Page 39 of 39