Every client I have worked with uses a multitude of spreadsheets, for everything from tracking inventory levels, performing ad hoc analysis, and preparing financial and regulatory reports. Over the past several years, particularly with the introduction of Sarbanes-Oxley, spreadsheets have come under more scrutiny, especially those used for external reporting. Companies and their auditors have been working to understand how the spreadsheets work, what controls are in place governing their numbers, and how well they can rely on the accuracy and consistency of their results. Groups such as the IIA have studied the use of spreadsheets, and other groups such as the European Spreadsheet Risks Interest Group help spread knowledge about the risks associated with spreadsheets.

All this effort has been done for good reason – there are plenty of errors made in spreadsheets that cause material problems, including earnings restatements:

• Kodak had to restate earnings because of an incorrect number of 0’s being entered into a spreadsheet
• RedEnvelope shares fell 25% when Cost of Goods Sold was incorrectly reported due to a spreadsheet error
• Other examples can be found at http://www.eusprig.org/stories.htm

Many companies have developed policies to govern the development and maintenance of spreadsheets, with the goal of providing a level of comfort over the results while giving employees the flexibility to quickly create reporting tools without heavy IT involvement. Others have revised their “end-user computing” policies to prescribe controls over spreadsheets. I developed such a policy for a client who was using a host of spreadsheets and databases to perform ad hoc analysis, financial filings, and respond to regulatory requests. Together, we called these spreadsheets and databases “User-Developed Applications (UDAs),” and the policy was designed to meet the needs of management, IT, and Internal Audit:

• Management wanted the flexibility to be able to develop tools for ad hoc and recurring analysis, without being required to work through the IT PMO process for each new application or change. They also wanted to ensure that the results were consistent from one iteration to the next, and that they were aware of changes made to underlying formulas. Finally, they wanted the option of having IT take over maintenance and control of the application if it grew in size and importance.
• IT wanted to be able to respond to calls to the helpdesk and support the business, even though they did not officially support UDAs. As such, they asked that users follow general development principles, maintain accurate documentation, and store applications on the network, allowing IT to debug formulas and restore prior versions of the application.
• Internal Audit wanted to ensure that they could rely on the results of these applications, audit the formulas, and follow the chain of approvals for changes made to the application.

Depending on the significance of the application (defined in terms of its financial, operational, and other risk level), the UDA policy contained guidelines over the following areas:

1. Documentation
2. System Development Life Cycle
3. Change Control
4. Security and Data Integrity
5. Analytics and Logic Inspection
6. Backups
7. Training
8. Segregation of Duties

To aid implementation and compliance, we developed a procedure manual that outlined requirements for UDAs, including checklists of activities within each of the 8 areas (depending on the application’s significance) and approval templates (modeled after the company’s IT PMO templates where possible).

Taken as a whole, the UDA policy and procedures helped formalize the process of developing and using spreadsheets and databases, while allowing IT to provide a increased level of support, and Internal Audit a greater level of confidence in results produced by these applications.