Audit Considerations for Enterprise Software Implementations Part 2: Applying Controls and Audit Emphasis

  • Written By:
  • Published:


Recent scandals in the corporate world have created a refreshed awareness of the audit function. One example is the Sarbanes-Oxley Act of 2002 (SOX), which is an attempt to strengthen the integrity of financial reporting. While some may argue that the Act does not go far enough, it is a positive, aggressive start.

While this reemphasis may be good news for current and ongoing systems, the process of developing an audit awareness and the need for substantial controls should be established as software is being implemented. If you are the project manager or the project sponsor, possibly the company's CEO or CFO, it is in your best interest to create a financially healthy environment from the start of the implementation project. The expectation is that this good inbreeding will continue with the software into production and throughout its entire life cycle. Considering the extensive scope of enterprise software such as enterprise resource planning (ERP), supply chain management (SCM), and warehouse management systems (WMS) software, the need for adequate and substantial controls is even more apparent.

Part I explored the impact of SOX on project management and documentation. This analysis illustrates how an audit emphasis during the implementation of software can lay the solid foundation for SOX compliance.

This part demonstrates how controls and the audit emphasis can be applied during an implementation project and throughout the software's lifecycle.

Control Framework

The prevailing guideline for internal controls is the Committee of Sponsoring Organizations (COSO) of the National Commission on Fraudulent Financial Reporting (Treadway Commission). COSO has provided a standard definition of internal controls to assist organizations in achieving financial, operational, and compliance objectives of SOX. As illustrated by the model below, the COSO framework can, and should, be applied to project activities. The following sections provide examples of how internal controls and procedures can be instituted while the project is underway and carried forward in production. Hopefully, as the project manager and working in concert with the audit function, you can think of others that may be pertinent and cost-effective to your organization. If that is not enough, perhaps the threat of SOX and the attached penalties may be enough to jolt you and your organization into action.

Software Piloting

When implementing enterprise software, piloting of this software is one of, if not the most critical event in the project's life cycle. Piloting or conference room pilot (CRP) is the process by which you put the software through its paces in a pseudo production setting to verify that it can support the standard business practices and routines of the company. If done well, the pilot will uncover issues before they become problems, instill confidence in the users that the software is ready for prime time, and make the "go live" uneventful and a cause for celebration.

What role can the audit function play in this segment of the project? A traditional and necessary function of an auditor is the development and execution of comprehensive sets of test conditions and work programs. These conditions serve to test the software under an as "close to" normal operating environment as possible to ensure that the intended results are achieved. This testing function comes into play during two specific piloting processes: module piloting and integrated piloting.

First and shortly after the enterprise software is installed, verification is needed that specific modules perform as expected and can satisfy the business practices of the company. Can orders be taken and invoiced correctly? Is inventory being relieved at the proper points in the process? Are production costs being accumulated accurately? The same types of tests must be developed for the other modules of the enterprise software. The auditor's participation in the development of the test conditions can ensure that the financial and operationally significant aspects of the company are serviced and software executes successfully. While it may be impractical for the auditor to develop business conditions for each module, the audit function should provide overall guidance as to the generally accepted principles of controls, a statement of objectives of auditing through and around computer systems, and participation in a review of testing results and resolution of issues.

The second phase of piloting, which occurs near the end of implementation and after testing of the individual modules is completed, is the verification that the enterprise software is ready for prime time, live production processing. In this second phase of piloting, typically referred to as the integrated pilot or compliance testing, the auditor can and should play an even more dominant role. Not only can auditors develop test scripts, the actual conductance of this acceptance pilot could be placed under their complete control. In this role, auditors provide the independence needed for this critical quality assurance event, relieving the project manager and sponsor of this responsibility. An additional benefit of the auditor's involvement in this pilot is that the test scripts, in full or partial format, can be used in subsequent mid- and end-of-year audit testing. The auditor's familiarity with the enterprise software will continue to pay benefits in many years to come.

Data Conversion

A major consideration in an enterprise software implementation is migrating existing data into the new software. Particularly with legacy data, where data structures and models can be significantly different, the matter of data conversion can be tricky and complicated. How this data is to be converted is a separate discussion, which can be found in the earlier published TEC article, Data Conversion in an ERP Environment. Here, we are more concerned with assurances that the resulting data is complete, accurate, and timely. How can the audit function assist in achieving these objectives?

Before embarking on this task, it is important that the data be cleansed and pruned. For example, if you were to convert inaccurate inventory records into the database of the new enterprise software, poor practices and the lack of data integrity will be continued. Orders would be taken with insufficient, unavailable inventory. Pickers could continue to pull inventory from locations of their choosing to complete picklists. The auditor, possibly as part of his normal responsibilities, can help in this regard. Continuing with our inventory example, the timely completion of a physical inventory can help the project with data cleansing and complete an audit requirement as well.

In regard to data pruning, the auditor can assist in determining the legal and tax implications of deleting (or not converting) data. Not only can such pruning reduce the processing clock time of conversion runs but it can also reduce problems downstream. By reviewing the significant issues and findings from historical audits, an auditor can help the company avoid being placed in potentially compromising situations of not having the data to answer questions. At a bare minimum and in case of doubts, the auditor should advise as to what legacy data needs to be archived.

Whether done manually or electronically, the old data must be mapped to the new data. The auditor's familiarity with old and legacy data can be invaluable in two ways. First, while there may not be a receiving field for existing data, an auditor will know when such data is still needed for the company's operations. At this point, an unused field must be selected to store valuable data. The auditor can ensure that, through testing, there will be no fallout from these decisions downstream or in other modules. Secondly, an auditor can determine which existing data maps most appropriately to new data structures. For example, verification that the product ID in the context of your current systems has the same meaning and use as the product number in the new software. The auditor's historical perspective of the systems being replaced and the knowledge of the successor software gained during the piloting processes can be put to good use and, again, avoid potential problems downstream.

While to a lesser degree when performed manually, run-to-run controls to verify the accuracy and completeness of data conversion routines can save time and effort. Automatic run-to-run controls can compare before and after record counts, financial sums, and hash totals or subtotals of key fields. The auditor can identify the critical fields on which these controls should be based. Are you more concerned with quantity on hand or reorder quantity? Are you more concerned with the customer's ID or zip code? Are you more concerned with the product's invoiced price or standard cost?

The most reasonable choice to the above questions is the first choice. There may be legitimate arguments on both sides as to which choice holds the most importance. For example, you could argue that, if the standard cost of a product is wrong, your revenue will be misstated, having a direct impact on the price charged your customers. However, if the invoiced price is wrong, you will look foolish to your customers and, if it is lower than the true price, you may not be able to correct the error on the just delivered invoices. Besides, there are variance reports that can help identify costing issues. Understand that it is not feasible to develop controls on every field or you may have a routine that does little else than add numbers. An auditor can help you navigate through these turbulent waters and suggest which totals give you the most control bang for your processing buck. Additionally, this valuable assistant can identify mitigating circumstances, like variance reports, that can achieve similar results and control objectives.

Finally, since data may have to be converted several times during the course of an implementation project, effective use of run-to-run controls can avoid the laborious task of data verification after the completion of each data conversion process. Particularly for the conversion before "go live," you can ill afford the time to perform this analysis.


From the feedback received on other articles on this topic, some companies do make effective use of the audit function during software implementations. However, based on personal experiences and the small number of comments to the contrary, unfortunately most organizations do not appear to be making use of this valuable resource. With the latest problems in corporate America and the emphasis provided by SOX, this practice needs rethinking.

Whether audit expertise is provided by an internal staff or an independent, outside agency, calling in an audit specialist is as normal as calling in a kicking specialist in a penalty or field goal situation in football. Particularly when you consider the majority of an enterprise software implementation is all about testing, the presence of an auditor as a functioning member of the project team makes perfect and logical sense.

About the Author

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for Fortune 100 companies.

He can be reached at

comments powered by Disqus