End-User Computing Applications

Kennesaw State UniversityDigitalCommons@Kennesaw State University

Faculty Publications

7-2011

End-User Computing ApplicationsMary C. HillKennesaw State University, [email protected]

W. Alan BarnesAssurant

Follow this and additional works at: http://digitalcommons.kennesaw.edu/facpubs

Part of the Accounting Commons, and the Management Information Systems Commons

This Article is brought to you for free and open access by DigitalCommons@Kennesaw State University. It has been accepted for inclusion in FacultyPublications by an authorized administrator of DigitalCommons@Kennesaw State University. For more information, please [email protected].

Recommended CitationHill, Mary Callahan, and W. Alan Barnes. "End-User Computing Applications." The CPA Journal 81.7 (2011): 67-71.

67JULY 2011 / THE CPA JOURNAL

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 these applications has been increased by the require-ments of the Sarbanes-Oxley Act of 2002 (SOX), which call formanagement to document end-to-end financial operations and

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

BackgroundThe following is a textbook definition of end-user computing: [A]n information system developed by the users themselvesrather than IT professionals to meet company operational ormanagement information needs. An end-user application oftenextracts or transfers data from a corporate database as a start-

End-User Computing Applications

T E C H N O L O G Y

t h e c p a & t h e c o m p u t e r

By Mary Callahan Hill and W. Alan Barnes

Implications for Internal Auditors and Managers

JULY 2011 / THE CPA JOURNAL68

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

cations such as spreadsheets, databases, dataextraction 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 businessprocesses or to complete their financial report-ing (“Spreadsheet Management: Not WhatYou Figured,” Deloitte, www.deloitte.com/assets/Dcom-UnitedStates/Local%20Assets/Documents/AERS/us_aers_Spreadsheet_eBrochure_070710.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 and, thus, does nothave to wait for the funding and schedul-ing of the project through an IT depart-ment’s budgetary processes. 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.

Risks End-user computing, however, can result

in four significant risks from an operationalor financial reporting standpoint. First, thereis the risk that the end-user application willhave unintentional errors that 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 theAssociation 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 bankrupt-cy. In the rush to file before the bankrupt-cy court deadline, however, errors weremade in spreadsheet use and formatting thatcaused Barclays to list assets in the final pur-chase offer that it did not want to pur-chase. As a result of this error, 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 docu-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 errors 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 from 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 thesesteps 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 source of errors. End usersfrequently select the tool they know best,rather than the best tool 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 from 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-

JULY 2011 / THE CPA JOURNAL 69

nization loses both the 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 that is built into systems developedvia IT departments 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 flexible, 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 $700 million in bad trading deci-sions. To cover his losses, he substituteda falsified spreadsheet as the input to a pro-duction trading system that his supervisorsused for control (Gary Flood, “Spreadingthe Blame,” Financial Director, May 25,2006).

Finally, end-user applications can berisky with respect to data breaches. Manyend-user applications extract data from aproduction database into the end-user appli-cation. The data then become much lesssecure, because the application can bestored on a user workstation, laptop, flashdrive, or other portable device. A 2008study found that more than 800,000 lap-tops are lost each year by users travelingthrough airports in the United States andEurope (Donna Fuscaldo, “Services FindLost, Stolen Laptops,” FoxBusiness,February 11, 2010). The press frequentlyreports of data breaches due to lost orstolen laptops containing confidential data,including Social Security or credit cardnumbers.

Control End-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 internal auditand IT departments, midsized companiesare those that have some designated IT spe-cialists, and small companies are those that

have few departmental classifications.Large companies with internal audit staffare most likely to be aware of the risksrelated to end-user computing applications.Recently, the Institute of Internal Auditorsissued Global Technology Audit Guide 14on this topic (Christine A. Bellino, DouglasOchab, and Jeffery S. Rowland, AuditingUser-developed Applications, June 2010).Smaller companies have less guidance onthis issue.

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. Thesecond is examining the end-user applica-tions themselves.

Control over development includes a pol-icy on end-user applications, communicationabout end-user applications, and training onsoftware to develop end-user applications.Below, we discuss each of these aspects ofcontrol over development of end-userapplications 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 that applications are developed withsome form of control, and to make cer-tain that the application is examined by atleast one other employee. Meeting thesegoals should help to eliminate unintentionalerrors from 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-user appli-cations (Panko 2006). Further, 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 internal auditand IT departments. Policies may have to beapproved or conform to standards set bythe companies’ external auditors. Once the

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

One portion of the policy should includea description of a process that users shouldfollow when developing applications. Thistype 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 applicationwith 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

least one other user on the application(Romney and Steinbart 2006). Large com-panies are likely to already have anSDLC process in place in the IT depart-ment, and for simplicity and efficiency, theend-user computing policy 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 internal controls surrounding end-user applications once they are developed.

End-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 resources, and the

number of end-user applications.

JULY 2011 / THE CPA JOURNAL70

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 used. Documentationstandards should ensure that, to the greatestextent possible, the application is self-docu-menting, using tools such as clear field labelsand built-in instructions. Access controlsshould require the application to have pass-words and storing applications, with criticalor sensitive data on secure servers that havefrequent backups performed.

For large companies, the 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 theinternal audit department for determinationof potential inclusion of the application inthe internal audit staff audit plans. Themore “yes” answers to the questions 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 is the maximumdollar impact? ■ Is the output used for accounting orfinancial reporting purposes? If yes, whataccounts are affected? ■ Would the loss of the end-user 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 data 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 resources 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 responsibility 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.,Microsoft 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 fewerresources available to develop and imple-ment formal policies. Further, in small com-panies with informal cultures, implement-ing policies and controls can imply a lackof trust, 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 users 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 request that end-user applica-tions be cleared with the company expert(Caulkins, Morrison, and Weidemann 2007).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 overlapping orredundant end-user applications.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 information, 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 coordination ofend-user applications. Communication to theIT department and internal audit shouldoccur at the beginning of the end-user 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 possible 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. Endusers must know how to use 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

JULY 2011 / THE CPA JOURNAL 71

employees to attend training classes. It isimportant also for supervisors to be knowl-edgeable about software in order toappropriately direct their 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.The first is gaining knowledge of the appli-cations that exist and their purpose; the sec-ond is testing the application for accurateprocessing. Examining end-user applica-tions is important in order to avoid all fourpotential risks associated with these appli-cations: errors, waste, fraud, and databreaches.

In large companies, examining end-userapplications would most naturally be per-formed by the internal audit staff. Internalaudit would first conduct an inventory toidentify end-user applications that are cur-rently being used. An inventory can beconducted using either of two methods ora combination of both methods. Onemethod is to survey users about their useof end-user applications to complete busi-ness processes or financial reporting. Thesurvey would include questions on the pur-pose of an application, how frequently itis used, the number of copies or versionsof the application, and whether there is ade-quate documentation of the application.The 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, other nonnetworkedcomputers, flash drives, and other 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 the application documen-tation or a review of the self-documentingfeatures of the 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 that the reportsare transmitted as PDF files rather than ascopies of the application itself (unless theapplication will require further downstreaminput)■ A comparison of input data to sourcematerial■ A review of the backup process for themost current version of the application■ A review of the termination control pro-cess, if an employee who “owns” a criticalend-user application leaves the 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 thefollowing: ■ 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, alongwith suggested remediation efforts.

In small and midsized companies, whichgenerally do not have internal audit depart-ments, examination of end-user applica-tions would be conducted less formally.However, inspection is almost more impor-tant for 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-user applications, alongwith 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 that the input is correct,the critical calculation in the application,a review of the documentation for theapplication, and the backup and storageprocesses for the application. The testingwould occur by assigning the cross-trainedemployee to utilize the application in theabsence of the original developer.

For small companies, examination of end-user applications will primarily rest withthe developer’s supervisor. Companies maywant to develop a checklist of things to lookfor in end-user applications, such as criticalcalculations or locked fields. Further, it isimportant that the supervisor perform a “snifftest” that examines both any critical assump-tions used to develop the application and thebottom-line reasonableness of any outputof the application (Caulkins, Morrison, andWeidemann 2007).

Controlling RiskEnd-user applications are a critical busi-

ness resource and a fact of life in today’sorganizations. While end-user computing hasmany benefits, there are risks involved in itthat need to be recognized and controlled.Some audit staff and IT professionals arguethat, given the spontaneous nature of thedevelopment of end-user applications andtheir immense number, these applications areimpossible to control. However, uncontrolleddevelopment of end-user applications leavesan organization open to error, waste, andfraud. Therefore, even the smallest compa-nies must make some effort to control them.Steps to control the development and useof end-user applications include imple-menting policies that govern their develop-ment, increasing communication about theapplications, training users, and independentexamination of critical applications. ❑

Mary Callahan Hill, PhD, CPA, is a pro-fessor of accounting at Kennesaw StateUniversity, Kennesaw, Ga. W. Alan Barnes,CPA, CIA, is a director of risk and adviso-ry services at Assurant, Atlanta, Ga.