T E C H N O L O G Y

the opa & the c o m p u t e r

End-User Computing ApplicationsImplications for Intemal Auditors and Managers

By Mary Callahan Hill and W. Alan Barnes

Businesses today rely on the work being done by staff usingpersonal computers. The proliferation of personal comput-ers has led to widespread implementation of end-usercomputing applications. As their name implies, end-user

applications are designed, implemented, and controlled by usersrather than by IT professionals. End-user applications can be riskyfor organizations, both with respect to management decision mak-ing and to financial reporting. For public companies, the riskinvolved in the.se applications has been increased by the require-ments of the Sarbane.s-Oxley Act of 2002 (SOX), which call formanagement to document end-to-end financial operations and

intemal control structures. Following is a review of the reasonsfor the prevalence of end-user applicatiiins and their inherent prob-lems, as well as strategies for the intemal coiiu-ol of these appli-cations for various-sized businesses.

BackgroundThe following is a textbook definition of end-user computing:[A In information system developed by the users themselvesrather than IT professionals to meet company operational ormanagement infomiation needs. An end-user application oftenexU"acts or U"ansfers data from a corporate database as a start-

JULY 2011/THE CPA JOURNAL 6 7

ing point. (Marshall Romney and PaulSteinbart, Accounting InformationSystems, 10th ed., 2006)End-user computing an result in appli-

cations such as spreadsheets, databases, dataexU-action queries, specialized reports, andwebsites. End-user computing applications,particularly spreadsheets, are essential to busi-ness processes: A recent survey indicates that70.1 % of companies rely heavily on spread-.sheets for critical portions of their businesspr[x:es.ses or to complete ths-ir financial report-ing ("Spreadsheet Management: Not WhatYou Figured," Deloitte, www.deloitte.com/assets/Dcom-UnitedStates/Local%20Assets/Documents/AERS/u.s_aers_Spreadsheet_eBrochLire_07()710.pdf).

A do-it-yourself mentality is prevalentin .society today, and end-user computingfits well with this mindset. End-user com-puting gives the user control over a tech-nology project such that explaining subjectarea or technical requirements to an IT spe-cialist is not required. Further, the end usercontrols the time schedule of the develop-ment, which generally results in a quickersolution. The end user employs his ownresources (time and knowledge) in devel-oping the application anc. thus, does nothave to wait for the funding and schedul-ing of the project through an IT depart-ment's budgetary prtx;esses. End-user com-puting tends to become even more preva-lent when budgets are tight and fundscannot be spent to acquire new software,and has become popular as users havegrown more sophisticated and more con-fident in their abilities to develop techni-cal solutions.

RisksEnd-user computing, however, can result

in four significant risks from an operationalor financial repi)rting .stand|X)int. First, thereis the risk that the end-user application willhave unintentional errors tliat result in poordecision making or inaccurate financialreporting. Second is the risk that scarceresources (money or employee time) willbe wasted on developing these applications.The third risk is that end-user applicationswill be used to perpetuate fraud or hidelosses. Finally, end-user applicationsincrease the risk of data breaches.

A recent study of spreadsheets—one ofthe most popular end-user computingtools—has found that over 90% of spread-

sheets have errors (Raymond R. Panko,"Spreadsheets and Sarbanes-Oxley:Regulations, Risks, and ControlFrameworks," Communications of theA.ssociation for Information Systems, vol.17, 2006). These unintentional errors canlead to poor decision making or additionalcosts. For example, in late 2008, BarclaysCapital used a spreadsheet to determinewhich assets belonging to Lehman Brothersit wished to buy after Lehman's bankmpt-cy. In the msh to file before the bankmpt-cy court deadline, however, errors weremade in spreadsheet use and fonnatting thatcaused Barclays to list assets in the final pur-chase offer that it did not want to pur-chase. As a result of this em)r, Barclays hadto file a legal motion to exclude 179Lehman contracts worth several million dol-lars that were mistakenly included in theasset purchase agreement (Frank Hayes,"Frankly Speaking: No. 1 Rule for Users:Keep It Simple," Computerworld,October 20, 2008). End-user applicationshave also been known to cause errors infinancial reporting; recently, large account-ing firms have issued client advisory dcx;u-ments that cite these applications as a sig-nificant threat. An example of a financialreporting error occurred in 2005, whenEastman Kodak was forced to restate finan-cial results due to a spreadsheet that incor-rectly calculated severance and pension-related termination benefits (RichardMorochove, 'Tech at Work: SpreadsheetSlip-ups Cause Financial Errors," PCWorld,September 2006).

End-user applications are prone to unin-tentional enors from a variety of sources.One source is the lack of a systemsdevelopment process. Because end-userapplications are often developed in hasteto meet an immediate need, theuser/developer may decide to prioritizetimeliness over the risk of errors (JonathanP. Caulkins, Erica Layne Morrison, andTimothy Weidemann, "Spreadsheet Errorsand Decision Making: Evidence ftxsm FieldInterviews," Journal of Organizational andEnd User Computing, July-September2007). These time pressures cause endusers to omit standard systems develop-ment activities, such as a program walk-through, testing, documentation, andindependent review. Failure to utilize these.steps can cause errors either in the formu-lation of the application (e.g., an incorrect

understanding of the calculations required)or in the creation of the application (e.g.,incorrect specifications of a formula inthe software or incorrect report generation).Increasing the risk of errors is the prob-lem that users tend to be overconfident intheir system development abilities (Panko2006). The selection of the end-user toolcan also be a souree of errors. End u.sersfi-equently select the tool they know best,rather than the best Xoo\ for the job. Themost common example is when end usersdevelop applications using spreadsheets,when a database tool would be better. (Adatabase tool is preferable when an appli-cation contains a large number of recordsor when the application requires search-ing and sorting capabilities.) Anothersource of errors arises from the need toinput data into the application; data canbe miskeyed or incorrectly or incomplete-ly extracted fTom a database. Finally, lackof documentation of the application can bea source of errors. If the initial developerleaves the organization, other employeesmight not know how to use the applica-tion, which can result in errors (e.g., aspreadsheet user enters data into a calcu-lated field, overwriting a formula).

Another risk is that companies will wastescarce resources developing end-user appli-cations. Often, end users spend an inordi-nate amount of time developing an appli-cation, only to find that there is existingsoftware that already performs the task(Stanley Earl Jenne. "Audits of End-UserComputing," Internal Auditor, December1996). Wasted resources also occur dueto duplication of applications within thesame company, as individual departmentscreate similar end-user .solutions for a com-mon problem but do not share them acrossdepartmental boundaries. Another poten-tial waste of resources is when users spendhours developing an application that anexpert could have developed in a few min-utes or using more efficient technology.Still another possible waste of resourcesis when a user chooses unusual develop-ment software that does not communicatewith the company's standard platform. Thelack of documentation on these applica-tions means that if the initial developerleaves the organization and other employ-ees do not know how to properly use it,the application can fall into disuse. Whenan end-user application is disused, the orga-

6 8 JULY 2011/THE CPA JOURNAL

nization loses both tiie time spent devel-oping it and the ability to perform an orga-nizational task.

End-user applications can be riskyfrom a perspective of intentional misstate-ments and frauds. The separation ofduties tiiat is built into systems developedvia IT deptirtments does not exist in end-user applications. In many cases, the devel-oper is simultaneously sponsor, program-mer, tester, and user (Deloitte 2009). Thetools used for end-user applications aremeant to be user friendly and fiexible. butthese qualities make applications developedwith the tools easy to manipulate. Anexample of this risk is shown in the spread-sheet fraud that was perpetuated by AllfirstBank trader John Rusnak. Rusnak lostclose to $7(X) million in bad trading deci-sions. To cover his losses, he substituteda falsified spreadsheet as tiie input to a pro-duction trading sy.stem tiiat his supervisorsu.sed for control (Gary Flood. "Spreadingthe Blame," Financial Director, May 25,20()6).

Finally, end-user applications can berisky witii respect to data breaches. Manyend-user applications extract data from aprcxluction database into tiie end-user appli-cation. The data tiien become much lesssecure, because the application can be.stored on a user work.station. laptop, fiashdrive, or t)ther portable device. A 2008study found tiiat more than 800,000 lap-tops are lo.st each year by users travelingthrough airports in the United States andEurope (Donna Fu.scaldo, "Services FindLost, Stolen Laptops." FoxBusiness.Febmary 11, 2010). The press frequentlyreports of data breaches due to lost orstolen laptops containing confidential data,including Social Security or credit cardnumbers.

ControlEnd-user applications are an issue for all

sizes of companies, but the approach tocontrolling these applications depends onthe size of the company, its resources,and the number of end-user applications.Thus, we discuss control strategies for end-user computing based on size classifica-tions as follows: Large companies aredefined as those that have intemal auditand IT departments, midsized companiesare those tiiat have some designated IT spe-cialists, and small companies are tiiose that

have few departmental classifications.Large companies with intemal audit staffare most likely to be aware of the risksrelated to end-user computing applications.Recently, tiie Institute of Intemal Auditorsissued Global Technology Audit Guide 14on tiiis topic (Chri.stine A. Bellino. DouglasOchab, and Jeffery S. Rowland. AuditingUser-developed Applications, June 2010).Smaller companies have less guidance ontiiis i.ssue.

Two efforts are required to make surethat end-user applications are properly con-trolled and do not have a negative effecton either financial reporting or opera-tional decision making. The first effort isto establish controls over the developmentof end-user computing applications. The.second is examining the end-user applica-tions tiiemselves.

ConUül over development includes a pol-icy on end-user applications, communicationabout end-u.ser applications, and training onsoftware to develop end-user applications.Below, we discass each of these aspects ofcontrol over development of end-userapplicatioas in general and then, more specif-ically, how that aspect might be put inplace for various sizes of companies.

PolicyFor all companies, a policy should be

put in place and communicated to employ-ees about the use of end-user applications(Morochove 2009). The goals of having apolicy are to promote consistency in devel-opment of end-user applications, toensure tiiat applications are developed withsome form of control, and to make cer-tain that tiie application is examined by atleast one other employee. Meeting thesegoals should help to eliminate unintentionalerrors ftom the end-user applications.

A policy to address end-user computingis particularly important for large companies,because .some large companies have beenknown to have hundreds of end-u.ser appli-cations (Panko 2006). Furtiier. large com-panies are most likely to be subject to therequirements of SOX or other regulationssuch as the Payment Card Industry DataSecurity Standard. In large companies, thepolicy would most effectively be developedas a joint effort between the intemal auditand IT departments. Policies may have to beapproved or conform to standards set bythe companies' extemal auditors. Once tiie

policy is developed, it needs to be commu-nicated to employees. IT staff' (training spe-cialists or help desk personnel) or intemalauditors who interface with users should beaware of and promote tiie end-user com-puting policy.

One portion of the policy should includea description of a process that users shouldfollow when developing applications. Tliistype of process is generally referred to asa systems development life cycle (SDLC).In general, SDLC processes include howto define requirements for an application;how to confirm the requirements bywalking through the proposed applicationwitii another knowledgeable user; how toselect the appropriate software for theapplication; how to conduct appropriatetesting; the type of documentation need-ed; and implementation standards, includ-ing backup and the need to cross-train at

&id-user applications are an issue

for all sizes of companies, but the

approach to controlling these

applications depends on the size of

the company, its resoün;es, and the

number of end-user applications.

least one other user on the application(Romney and Steinbart 2006). Large com-panies are likely to already have anSDLC prœess in place in the IT depart-ment and for simplicity and efficiency, theend-user computing [xilicy should utilizethe same SDLC process. The importanceof testing should be particularly empha-sized because end users have been foundto be overconfident about their technicalcompetency (Panko 2006).

Another portion of the policy shouldinclude intemal controls surrounding end-aser applications once tiiey are developed.

JULY 2011/THE CPA JOURNAL 69

These controls include version .standards,documentation standards, and access con-trols. Version standards include the devel-opment of a naming convention, the stor-age and backup of versions of the applica-tion, and a method to ensure that only thelatest version is being u.secl. Documentationstandards should ensure that, to the greatestextent possible, the application is self-docu-menting, using tools such as clear field labelsand built-in instmctions. Access controlsshould require the application to have pass-words and storing applications, with criticalor sensitive data on secure servers that havefiiequent backups performed.

For large companies, tfie policy shouldprovide a checklist to determine the levelof risk in the application. Using the check-list, users should determine the risk in theirapplication and report the risk level to theintemal audit department for determinationof potential inclusion of the application inthe intemal audit staff audit plans. Themore "yes" answers to the tjuestions below,the riskier the application. The followingfactors increase risk:

• Does the output of the end-user appli-cation significantly impact decisions aboutoperations? If yes, what i.s the maximumdollar impact?• Is the output used for accounting orfinancial reporting purposes? If yes, whataccounts are affected?• Would the loss of the end-aser appli-cation or its output have a detrimental oper-ational, financial, or legal impact? If yes,what losses would occur?• Do multiple users rely on the end-userapplication or its output? If yes, list thedownstream users.• Are the data contained in the applica-tion confidential to the business or employ-ees? If yes, specify the nature of the con-fidential data.• Is the application particularly complexwith respect to calculations? If yes, brieflydescribe the nature of the calculations.• Does the input to the application relyon multiple applications, such as a databaseextraction query to input datii into a spread-sheet? If yes, then the application's riskincreases because either the end-user appli-cation itself or the process for loading datacould contain an error.

While small and midsized companieshave fewer re.sources to devote to control-ling end-user applications, they must still

make an effort to set up some policies toavoid the risks noted above. In midsizedcompanies, the re.sponsibility for develop-ing a policy for end-user computing wouldnormally rest with the controller or account-ing manager. Department managers wouldcommunicate the policy to their employees.Midsized companies are less likely to havea formal SDLC process, but some aspectsof those processes should be included as partof the end-user computing policy. Mostimportantly, the policy should emphasizehow to conduct appropriate testing of anapplication and that the application needsdocumentation. Policies for midsized com-panies should also emphasize that end usersshould employ only .standard and well-known application software packages (e.g.,Micro.soñ Excel and Microsoft Access) sothat other users within the company willbe familiar with the development tool.Controls over the developed applicationshould be similar to those for large compa-nies and include version standards, docu-mentation standards, and access control.

Small companies have even fewerresourees available to develop and imple-ment formal policies. Fuither. in small com-panies with informal cultures, implement-ing policies cind controls can imply a lackof tmst, thereby hurting morale and damp-ing the initiative that is central to end-userapplication development (Caulkins,Morrison, and Weidemann 2007). A poli-cy with respect to end-user applicationsshould be part of a small company's con-trol environment; in fact, simply raisingawareness of the issue among staff mem-bers will help reduce risk. Small companiesshould also stipulate in their policies thatend asers utilize only well-known applica-tion .software packages, that they use tem-plates rather than starting from scratch oneach new application, that they adhere toreporting .standards (such as using bracketsfor negative amounts), and that they try tokeep the application as simple as possibleby avoiding complex formulas. Smallbusinesses might also find it valuable to des-ignate an employee as the "technologyexpert" and reque.st that end-user applica-tions be cleared with the company expert(Caulkins, Morrison, and Weidemann 20(77).Like other companies, small companiesshould have policies to control the devel-oped application: version standards, docu-mentation standards, and access control.

CommunicationCommunication about end-user applica-

tions is important in order to eliminatewaste. If end-user applications are devel-oped without communication, there is morelikelihood of duplicate or overlappingapplications within a company. Thus, com-munication includes monitoring develop-ment across departments or branchoffices that might develop overiapping orredundant end-user appl icat ions.Communication will help alleviate appli-cation losses that occur when developersleave the company. End users should com-municate the purpose of the application,the tool that is being used to develop theapplication, their contact infonnation, thelocation of the application, and the loca-tion of the application's documentation.

In large companies, communicationshould center on the IT support staff anduser help desk. IT support staff should actas a clearing house for the c(X)rdination ofend-user applications. Communication to theIT department and intemal audit shouldoccur at the beginning of the end-u.ser devel-opment. Communication to the IT staff alsofacilitates any technical support that the usermight need during the development and test-ing of an application.

In small and midsized companies, super-visors should encourage staff members todiscuss pt)ssible end-user applications withthem prior to initiating efforts to developthe application. Supervisors should sharedevelopments with peers in other depart-ments and with relevant IT support staff.

TrainingTraining on end-user application soft-

ware is critical to successful implementa-tion of the end-user policy and the controlsover the application itself Training isimportant in order to avoid waste in thedevelopment of the applications. Trainingissues are the same for all sizes of com-panies—the only difference would bewhether the training is offered within thecompany or by an outside vendor. Endu.sers must know how to u.se the develop-ment software, they must be able to eval-uate the complexity of the application theyare planning to develop, they must beable to estimate the time involved, and theymust know where to get help if they arehaving trouble with the development soft-ware. Supervisors should encourage

70 JULY 2011/THE CPA JOURNAL

employees to attend training classes. It isimportant al.so for supervisors to be knowl-edgeable about software in order toappropriately direct dieir employees' appli-cation development efforts.

As part of each application's training,users must be made aware of the appro-priate—and inappropriate—tasks forthe application. Training should includethe control attributes that are built intothe application, such as how to protectthe application using passwords; how toprevent input errors using locked datafields, embedded edits, or drop-downlists; and how to use any embeddedauditing tools (e.g.. Microsoft Excelcomes with an auditing tool that showscell dependencies). Users also need to betrained in how to use the self-documen-tation features of the application, such astrack changes and printing applicationstructures. Finally, end users should bemade aware of software that helps debugapplications, such as SpreadsheetDetective or OpenGate Software forMicrosoft Access.

Examining End-User ApplicationsFor all companies, examining end-user

applications consists of two activities.Tlie first is gaining knowledge of die appli-cations that exist and dieir purpose; the sec-ond is testing die application for accurateprocessing. Examining end-user applica-tions is important in order to avoid all fourpotential risks associated widi diese appli-cations: errors, waste, fraud, and databreaches.

In large companies, examining end-userapplications would most naturally be per-fonned by the intemal audit staff. Intemalaudit would first conduct an inventory toidentify end-user applications that are cur-rently being used. An inventory can beconducted using either of two mediods ora combination of both methods. Onemeth(xl is to survey users about their useof end-user applications to complete busi-ness processes or financial reporting. Thesurvey would include que.stions on the pur-pose of an application, how frequently itis used, the number of copies or versionsof die application, and whether there is ade-quate documentation of the application.Tlie other option for conducting an inven-tory is to scan the company network forspecific file extensions (e.g., ".xls" or

".mdb"). Each method has limitations: Thesurvey relies on user responses, while thescan excludes laptops, odier nonnetworkedcomputers, flash drives, and odier portablemedia.

Once the critical end-user applicationsare identified, internal auditors shouldperform tests on them. In large companies,testing might start with the following:• A review of die application documen-tation or a review of the self-documentingfeatures of die application• A review of the version control pro-cesses in place surrounding the applicationand consistent use of naming conventions• A review of the distribution list forthe application or its output• A review of the output of the applica-tion, such as making sure diat the reportsare transmitted as PDF files rather dian ascopies of the application itself (unless theapplication wiU require further downstreaminput)• A comparison of input data to sourcematerial• A review of the backup process for diemost current version of die application• A review of the termination control pro-cess, if an employee who "owns" a criticalend-aser application leaves die company.

These steps will also help an auditor gainan understanding of the application. Theexamination of the application wouldcontinue by having the auditor use theapplication itself. Some tests include diefollowing:• Testing the access control to theapplication by trying to log on using a pass-word and user ID• Recomputation of critical calculations• Testing field edits or drop-down lists• Trying to enter data into locked fields• Generation of critical reports.

Test results should be documented, alongwidi suggested remediation efforts.

In small and midsized companies, whichgenerally do not have intemal audit depart-ments, examination of end-user applica-tions would be conducted less formally.However, inspection is idmost more impor-tant tor small companies than large com-panies because large companies will cre-ate processes to build quality into end-userapplications, while smaller companies tendto try and "inspect" quality into the appli-cations (Caulkins . Morrison, andWeidemann 2007).

Midsized companies might want to keepa list of critical end-u.ser applications, alongwidi the developer name. In midsized com-panies, another employee should beassigned to both examine and be cross-trained on the application. The trainingwould include how to access the applica-tion, how data is input to the applicationand how to verify diat the input is correct,the critical calculation in the apphcation,a review of the documentation for theapplication, and the backup and storageprocesses for die application. The testingwould occur by assigning die cross-Uiiinedemployee to utilize die application in dieabsence of the original developer.

For small comjjanies, exiunination of end-user applications will primarily re.st withdie developer's supervisor. Comjianies maywant to develop a checkli.st of tilings to lookfor in end-user applications, such as criticalcalculations or locked fields. Further, it isimportant that die supervisor pedbnn a "snifftesf diat examines bodi any critical assump-tions ased to develop the application and diebottom-line reasonableness of any outputof the application (Caulkins, Monri.son, andWeidemann 2007).

Controlling RiskEnd-u.ser applications are a critical busi-

ness resouree and a fact of life in today'sorganizations. While end-user computing hasmany benefits, diere are risks involved in itdiat need to be recognized and controlled.Some audit staff and IT professionals arguethat, given the spontaneous nature of thedevelopment of end-user applications anddieir immense number, die.se applications areimpossible to control. However, uncontrolleddevelopment of end-user applications leavesan organization of)en to error, waste, andfraud. Therefore, even the smallest compa-nies must make some effort to control diem.Steps to control the development and useof end-user applications include imple-menting policies that govem dieir develop-ment increasing communication about dieapplications, training usei"s, and independentexamination of critical applications. •

Mary Callahan HiH PhD, CPA, is a pro-fessor of accounting at Kennesaw StateUniversity, Keimesaw, Ga W. Alan Barnes,CPA, CIA, is a director of risk and iidx'iso-ry services at As.'iurant, Atlanta, Ga.

JULY 2011/THE CPA JOURNAL 71

Copyright of CPA Journal is the property of New York State Society of CPAs and its content may not be copied

or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission.

However, users may print, download, or email articles for individual use.