to e… · web viewerp applications concentrate data in an easy-to-access format. in manual...

AUDITING IN ERP ENVIRONMENT

INTRODUCTIONEnterprise 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

of 40


assistance that will be available during the installation period. • Range compatibility. If the workload expands, can the configuration be

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.

of 40


ERP System Architecture

NEED FOR AN ERP RISK ASSESSMENT

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

of 40


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.

OVERVIEW OF RISKSOrganizations 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.

Overview of Risks Exhibit 2.1 Risks and exposures for ERPLC

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:

• Searches out an ERP system’s vulnerabilities and the probabilities of threats materializing to exploit these vulnerabilities.

of 40


• 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 environment’s vulnerabilities and set of threats should be assessed to arrive at some estimate of possible damaging events. Such an 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 ERP’s 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:

• Improper use of technology.• Inability to control technology.• Inability to translate user needs into technical requirements.• Illogical processing.• Inability to react quickly (to stop processing).• Cascading of errors.• Repetition of errors.• Incorrect entry of data.• Concentration of data.• Inability to substantiate processing.• 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 user’s 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.

of 40


• The conditions that lead to the improper use of technology include:• Premature user of new hardware technology.• Early user of new software technology.• Minimal planning for the installation of new hardware and software

technology.• Systems 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 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:

• Selection of vendor-offered system control capabilities by systems programmers without considering audit needs.

• Too many control trade-offs for operational efficiency. • Inadequate restart/recovery procedures. • Inadequate control over different versions of programs. • Inadequate control over schedulers, system operators, tape librarians, print

capabilities, and data transmission capabilities. • Inadequate 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:

• Failure to implement needs because users were unaware of technical capabilities.

• Improperly implemented needs because the technical personnel did not understand user requirements.

• Users accepting improperly implemented needs because they are unsure how to specify changes.

• • Building of redundant manual systems to compensate for weaknesses in ERP applications.

• Conditions that can lead to the inability to translate user needs into technical requirements include:

• Users without technical IT skills.

of 40


• Technical people without sufficient understanding of user requirements. • User’s inability to specify requirements in sufficient detail. • Multi-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 recognizable. Conditions that can result in illogical processing include:

• Failure to check for unusually large amounts on output documents. • Fields that are either too small or too large, thereby impacting the

completeness, accuracy, or efficiency of the data being processed. • Failure 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 application’s 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:

• Computer time is unavailable to satisfy the request, or computer terminals/microcomputers are not readily accessible to users.

• The structure of the computer files is inconsistent with the information requested.

• General-purpose extract programs are not available to satisfy the desired request.

• 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

of 40


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:

• Inadequately tested applications. • Failure to communicate the type and date of changes being implemented. • 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:

• Insufficient program testing. • Inadequate checks on entry of master information. • 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 point-

of 40


of-sale equipment. However, these are all mechanical devices and thus subject to failure.

Conditions that can cause incorrect entry of data include:

• Human errors in keying data. • Mechanical failure of hardware devices. • Misinterpretation of characters or meaning of manually recorded input. • Misunderstanding of data entry procedures. • 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.

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:

• Erroneous data and its impact on multiple users of that data. • Impact of hardware and software failures that ordinarily make the data available to multiple users. • Inadequate access controls enabling unauthorized access to data. • 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.

of 40


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:

• Evidence is not retained long enough. • The evidence from intermediate processing is not retained. • Evidence is not independently reviewed for quality assurance and/or data integrity. • Outputs are not reviewed for quality by the users. • The cost of substantiating processing exceeds the benefits derived from the 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:

• Establishment of a data processing programming and systems group to develop ERP applications for an organization. • Centralized processing of ERP applications. • Establishment of a database administration function. • Lack of adequate standards and enforcement of those standards. • 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.

• Unreasonable or inconsistent source data values may not be detected. • Keying errors during transcription may not be detected.

of 40


• Incomplete or poorly formatted data records may be accepted as if they were complete records.

• Records in one format may be interpreted according to a different format. • An employee may fraudulently add, delete, or modify data (e.g., payment

vouchers, claims) to obtain benefits (e.g., checks, negotiable coupons) for himself.

• Lack 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.

• Records about the data entry personnel (e.g., a record of a personnel action) may be modified during data entry.

• Data that arrives at the last minute (or under some other special or emergency condition) may not be verified prior to processing.

• Records 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 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. • A 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 employee’s home addresses as a mailing list).

• Information may be altered for an unauthorized end user (e.g., altering of personnel records).

• An authorized user may use the system for personal benefit (e.g., theft of services).

• A supervisor may manage to approve and enter a fraudulent transaction. • A disgruntled or terminated employee may destroy or modify records, possibly

in such a way that backup records are also corrupted and useless. • An 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.

• Data or programs may be stolen from the IT room or other storage areas. • ERP facilities may be destroyed or damaged by intruders or employees. • Individuals may not be adequately identified before they are allowed to enter

the IT area. • Remote terminals may not be adequately protected from use by unauthorized

persons. • An unauthorized user may gain access to the system via a dial-in line and an

authorized user’s password. • Passwords may be inadvertently revealed to unauthorized individuals. A user

of 40


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.

• A user may leave a logged-in terminal unattended, allowing an unauthorized person to use it.

• A terminated employee may retain access to an ERP system because his name and password are not immediately deleted from authorization tables and control lists.

• An 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).

• Repeated 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.

• Poorly defined criteria for authorized access may cause employees not to know what information they, or others, are permitted to access.

• The person responsible for security may fail to restrict user access to only those processes and data that are needed to accomplish assigned tasks.

• Large funds disbursements, unusual price changes, and unanticipated inventory usage may not be reviewed for accuracy.

• Repeated payments to the same party may go unnoticed because there is no review.

• Sensitive data may be carelessly handled by the application staff, by the mail service, or by other personnel within the organization.

• Post-processing reports analyzing system operations may not be reviewed to detect security violations.

• Inadvertent modification or destruction of files may occur when trainees are allowed to work on live data.

• Appropriate 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.

• Files may be destroyed during database reorganization or during release of disk space.

• Operators may ignore operational procedures; for example, by allowing programmers to operate computer equipment.

• Job control language parameters may be erroneous. • An installation manager may circumvent operational controls to obtain

information. • Careless or incorrect restarting after shutdown may cause the state of a

transaction update to be unknown. of 40


• 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).

• Hardware maintenance may be performed while production data is online and the equipment undergoing maintenance is not isolated.

• 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).

• Operations staff may sabotage the computer (e.g., drop pieces of metal into a terminal).

• The wrong version of a program may be executed. • A program may be executed using wrong data or may be executed twice

using the same transactions. • An operator may bypass required safety controls (e.g., write rings for tape

reels). • Supervision of operations personnel may not be adequate during non-

working-hour shifts. • Due to incorrectly learned procedures, an operator may alter or erase the

master files. • A console operator may override a label check without recording the action in

the security log. Storage Media Handling.

• Critical tape files may be mounted without being write protected. • Inadvertently or intentionally mislabeled storage media are erased. In case

they contain backup files, the erasure may not be noticed until it is needed. • Internal labels on storage media may not be checked for accuracy. • Files with missing or mislabeled expiration dates may be erased. • 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.

• Scratch tapes used for jobs processing sensitive data may not be adequately erased after use.

• 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.

• Storage media containing sensitive information may not get adequate protection because operations staff does not know the nature of the information content.

• Tape management procedures may not adequately account for the current status of all tapes.

• Magnetic storage media that contain very sensitive information may not be degaussed before being released.

• Output may be sent to the wrong individual or terminal. • Improper operation of output or post-processing units (e.g., bursters,

decollators, or multipart forms) may result in loss of output.

of 40


• Surplus output material (e.g., duplicates of output data, used carbon paper) may not be disposed of properly.

• 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.

• Records may be deleted from sensitive files without a guarantee that the deleted records can be reconstructed.

• Programmers may insert special provisions in programs that manipulate data concerning themselves (e.g., a payroll programmer may alter his own payroll records).

• Data may not be stored separately from code so that program modifications are more difficult and must be made more frequently.

• Program changes may not be tested adequately before being used in a production run.

• Changes to a program may result in new errors due to unanticipated interactions between program modules.

• 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).

• Programs with contents that should be safeguarded may not be identified and protected.

• Code, test data with its associated output, and documentation for certified programs may not be filed and retained for reference.

• Documentation for vital programs may not be safeguarded. • Programmers may fail to keep a change log, to maintain back copies, or to

formalize record-keeping activities. • 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).

• 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.

• Production data may be disclosed or destroyed when it is used during testing. • A programmer who misunderstands requests for changes to the program may

cause errors. • A programmer who makes changes directly to machine code may introduce

errors. • Programs may contain routines not compatible with their intended purposes,

which can disable or bypass security protection mechanisms. For example, a

of 40


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.

• 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.

• Simultaneous processing of the same file by two jobs may introduce inconsistencies into data.

• An operating system design or implementation error may allow a user to disable audit controls or to access all system information.

• The operating system may not protect a copy of information as thoroughly as it protects the original.

• Unauthorized modification to the operating system may allow a data entry clerk to enter programs and thus subvert the system.

• An operating system crash may expose valuable information such as password lists or authorization tables.

• 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 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).

• An operating system may fail to record that multiple copies of output have been made from spooled storage devices.

• An operating system may fail to maintain an unbroken audit trail. • When restarting after a system crash, the operating system may fail to

ascertain that all terminal locations are still occupied by the same individuals. • A user may be able to get into monitor or supervisory mode. • The operating system may fail to erase all scratch space assigned to a job

after the normal or abnormal termination of the job. • 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.

• Undetected communication errors may result in incorrect or modified data. • Information may be accidentally misdirected to the wrong terminal. • Communication nodes may leave unprotected fragments of messages in

memory during unanticipated interruptions in processing. • Communication protocol may fail to positively identify the transmitter or

receiver of a message. Intentional Acts.

of 40


• Communication lines may be monitored by unauthorized individuals. • Data or programs may be stolen via telephone circuits from a remote job entry

terminal. • Programs in the network switching computers may be modified to

compromise security. • Data may be deliberately changed by individuals tapping the line (requires

some sophistication, but is applicable to financial data). • 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.

• If encryption is used, keys may be stolen. • A terminal user may be spoofed into providing sensitive data. • False messages may be inserted into the system. • True messages may be deleted from the system. • 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.

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:

• Obligations and costs comply with applicable laws. • All assets are safeguarded against waste, loss, unauthorized use, and

misappropriation. • 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 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

of 40


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, 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 objectives that an author should look for are:

• Transactions are properly authorized (Authorized). • Transactions are recorded on a timely basis (Timeliness). • Transactions are accurately processed (Accuracy). • All existing transactions are recorded (Completeness). • All recorded transactions are valid (Validity). • Transactions are properly valued (Valuation). • Transactions are properly classified and posted to proper accounts and

subsidiary records (Classification). • Transactions are properly summarized and reported (Reporting). • Assets, including software programs, data, human resources, computer

facilities, etc. are safeguarded against damage, theft, and so forth (Security). • System and data integrity is maintained (Integrity). • System availability is assured (Availability). • System controllability and auditability is maintained (Controllability and

Auditability). • System maintainability is assured (Maintainability). • System usability is assured (Usability). • System economy and efficiency are maintained (Efficiency).

of 40


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:

• 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.

• Information systems design. For example, numerically prenumbered forms, message authentication, console logs, encryption, range and limit checks on input fields.

• Physical controls. For example, combination locks for vaults, card acceptor devices for restricted access areas.

• 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 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

of 40


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.

of 40


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 of 40


Agreement with M/s SISL stipulated that service records, personal details, watching 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 Company’s 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

of 40


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 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

of 40


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 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.

of 40


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 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 (WBS2), 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

of 40


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, 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.

of 40


• 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 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

of 40


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 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

of 40


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. (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 VSAT3 from all

of 40


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 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, 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 team4 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 user’s 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 Management’s 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 Company’s 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 Company’s 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

of 40


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. • Analysis of purchase orders/Work orders released through the system showed that in respect of service contracts, POs/WOs were created (19,406 in 2007-08 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

of 40


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 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

of 40


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.

• 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 of 40


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.

of 40


Inventory Management

Bharat Electronics Limited Information Technology Audit on the computerisation of inventory management at Bangalore Complex:• Non-adjustment of finished Goods (FG) stock in the event of reversal of sale• Drawal of material in excess of Bill of Material (BOM) quantities• Non-netting of quantities while processing Purchase Requisition (PR)• Non-closure of work orders after completion• Discrepancies in comparable stock data between MRP-II and IFASDeficiencies 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

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.

of 40


(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.

• Logon activity:(i) To ensure that other users do not access the system during the

authorized user’s 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.

• Standard user protectionWhen 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

• Input and validation controls1. Inconsistent codes and duplicate description in the material master2. Updation of master data3. Different units of measurement for same material4. Duplicate vendor codes5. Inconsistencies in delivery and purchase order dates6. Inconsistencies in purchase requisition release date and purchase order

date7. Purchase documents without material code

of 40


8. Valuation of stock as per accounting policy9. Scrap/off-cut material being processed manually

Oil and Natural Gas Corporation Limited IT Audit of Material Management Input Controls

1. Purchase orders for stores and spares items with wrong valuation types2. Purchase orders for capital items with wrong valuation type3. Delivery date in purchase orders4. Creation of fresh purchase requisitions with earlier requisitions

remaining pending5. Non clearance of stock in transfers6. Delay in recording of material consumption7. 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

of 40


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 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: Review in audit revealed the following:

(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 group3. Discrepancies in vendor master:

(i) Classification data like annual turnover, manufacturer, distributor, retailer and trader were not maintained.

of 40


(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 locations5. 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.

of 40


(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 case, the requisition was flagged as closed but in the change history1 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 RFQ4. Excess withdrawal of material against reservation5. Placement of PO on blocked vendor6. 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

of 40


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 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.

of 40

to e… · web viewerp applications concentrate data in an easy-to-access format. in manual...

Documents