Using Graphical Representations of Business

Processes in Evaluating Internal Control

A. Faye Borthick, Gary P. Schneider, and Anthony Vance

ABSTRACT: In this case, students (1) extend business process diagrams (BPD) to

represent current and contemplated business processes for accounts payable

processing for a convenience store company's merchandise purchases and (2) use

the graphical representations of the business processes to identify control weaknesses

and their potential effects on the financial statements and operational effectiveness. The

case is appropriate for students developing skills in documenting business processes

and evaluating internal control in business processes in introductory courses in

accounting information systems (AIS), auditing, and information technology (IT) auditing.

Before beginning the case, students should be familiar with the procure-to-pay process,

preparing BPDs, and identifying internal control weaknesses in business processes.

Working the case requires students to think critically about the business processes and

the implications of differences in current and contemplated processes.

Keywords: business process diagram; business process modeling; financial statement

assertions; internal control evaluation; operational effectiveness.

THE CASE

The Business Situation: Accounts Payable for Merchandise at 24-Seven Company

The scene: The time is early in the year, when 24-Seven accounting staff members are

documenting internal control for accounts payable for vendors supplying store inventory. Kiran, an

accountant, is interviewing Pat, the payables manager.

Kiran: ''Thank you for making time to talk to me. I really appreciate it because I know you're

busy!''

Pat: ''Not a problem. What would you like to know?''

Kiran: ''I'm familiar with the payables process up to the point where we receive invoices from

vendors. Would you start there?''

Pat: ''Sure. On the 5th and 20th of the month, the system matches all unprocessed invoices to

purchase orders (POs).''

Kiran: ''Just what gets matched?''

Pat: ''PO number on the invoice to purchase order number on the PO, and PO and invoice

amounts. When matched, invoice status is set to 'A' for payable.''

Kiran: ''What happens if there's not a match?''

Pat: ''The system sets invoice status to 'S' for 'suspended,' and payables staff resolve the

mismatch and set status to payable.''

Kiran: ''How are payments made?''

Pat: ''The payables system requests the bank to send an electronic funds transfer (EFT) to the

vendor's bank.''

Kiran: ''How do you know an EFT was made?''

Pat: ''On the 10th and 25th of the month, EFT requests are prepared. Before the EFT request

goes to the bank, the system sets the EFT status for an invoice to 'P' for 'pending.' After the

system sends a batch of EFT requests to the bank, it changes the EFT status for each one in

the batch to 'R' for 'requested.' After making payments, the bank returns EFT confirmations

to us.''

Kiran: ''How do you know the process works correctly?''

Pat: ''As part of closing the month, we run a report that verifies that payments were made only

for valid requests.''

Kiran: ''Are there adjusting entries for payables each month?''

Pat: ''Yes. To close the month, we download the payables file from the system into a

spreadsheet on the first of the month, which sums the amounts of invoices with status'R.'

The sum becomes the amount for the adjusting entry to the general ledger that enters the

payables amount for the month being closed.''

Kiran: ''And the prior month's entry is reversed?''

Pat: ''Yes. The spreadsheet keeps up with the monthly amounts.''

Kiran: ''Where is the spreadsheet, and how do you know that it does what it is supposed to do

and nothing else?''

Pat: ''The spreadsheet is on Bern's PC. That's because when we started using a spreadsheet to

calculate the entry, Bern [an accounts payable staff member] had the time to develop it.''

Kiran: ''When Bern isn't here, who runs the spreadsheet to create the adjusting entries, and was

it tested by anybody else?''

Pat: [thinking] ''I looked over test results based on the month before we started using it, and

everything looked fine to me. I know it's easy to use because when Bern's not here, other

accounts payable staff members go to Bern's PC to run it.''

Kiran: ''I've got to ask. Is there a reason the enterprise system (ES) doesn't do the adjusting

entries every month?''

Pat: ''I'm with you on that one. We started using a spreadsheet when we acquired the first

company that wasn't integrated into our existing ES. Over time, there were more of these. If

you look at other financial statement balances, you'll find spreadsheets used similarly. And

there's a monster spreadsheet that consolidates all the financial data from all the different

systems run by all the subs (subsidiaries). As long as we keep acquiring companies, but not

integrating them into our ES, I guess we'll keep using spreadsheets to prepare the adjusting

entries.''

Kiran: ''So are the subs volatile, i.e., is there much change in them?''

Pat: ''Actually, there will be changes several times a year. Some are acquisitions and some are

spin-offs. You just never know what will happen next. Finding out about the spin-offs is

easythere are no data when we go to download it. Usually, we see a press release when

there's a new acquisition. Bern just adds and deletes columns as the companies change.''

Kiran: ''How hard is it to set up the data download for a new acquisition?''

Pat: ''Must not be too hard because Bern doesn't spend much time setting them up.''

Kiran: ''Has anybody ever cross-checked the entries calculated in the spreadsheet against the

trial balances of the subs?''

Pat: ''I don't think so. Because each of the subs has its own idiosyncrasies, that might be quite a

job.''

Kiran: ''Can we go back to the process for a moment? Where was the status set to 'R'?''

Pat: ''When we receive an invoice from a vendor, the system sets status'R' for 'received.'''

Kiran: ''Okay. What can you tell me about how the payables application was developed?''

Pat: ''Unfortunately, not much because I wasn't here when it was installed a couple of years

ago.''

Kiran: ''I understand. Have there been problems with it? Does it get updated often?''

Pat: ''I guess the best responses are 'no' and 'no.' You'll have to talk to one of the application

developers.''

Kiran: ''I'll do that. Can you tell me who has access to payables?''

Pat: ''Now, that I can answer. All the payables staff (eight full-time and four part-time) have

ready access to payables transactions and reports. All the staff can edit payables

transactions. Only my two supervisors and I can develop reports that run against the

transactions in the database or enter adjusting entries. Depending on their job functions,

payables staff members can run reports.''

Kiran: ''What kind of reports do you have?''

Pat: ''Some of them are analysis reports, e.g., we just wrote one that identifies groups of similar

payables so we can inspect them visually for potential duplicates. Another one matches

employee addresses to vendor addresses.''

Kiran: ''How did you get started writing reports? In Structured Query Language (SQL)?''

Pat: ''We got started because it took so long to get ad hoc reports developed by the IT

development group. When one of the IT analysts indicated an interest in rotating through

payables to understand the business better, I jumped at the chance. Jan, who knew SQL,

wrote the first ones and explained them to us. When we saw how powerful the report writer

was, we paid attention because we realized that we could answer a lot of our questions

ourselves by querying the data. The pressure to analyze data is relentless. A lot of people

want information about payables. The report writer we're using supports SQL and Query-

By-Example (QBE). Although I'm not exactly a whiz at it and Jan has long since rotated

out, I have friends in IT and in other app areas that will answer occasional questions.

Sometimes, I can search the web for answers to specific querying questions. Now that we've

written several reports, we can use them as models for new ones.''

Kiran: ''How hard was it to learn to write reports yourself?''

Pat: ''Not very. We'd already been experimenting with the QBE interface in Microsoft

Accesst, which worked the same way in the report writer. Accesst is on all our PCs. Once

you get familiar with one relational database manager, you're familiar with them all!''

Kiran: ''What do you do about checking for errors in the queries?''

Pat: [looking puzzled] ''We just keep modifying reports until they run to our satisfaction.''

Kiran: ''Do you modify them often? Do you run them only for yourselves?''

Pat: ''Mostly, the reports are just for us and, yes, we modify them often. Actually, it's more like

we take an existing report and work with it to create a new one. Sometimes, though, one of

our reports strikes the fancy of others, who clamor to get access to it. For example, buyers

like the report that shows purchases by inventory item ID grouped by vendor. They can use

that information to manage their buying better.''

Kiran: ''Do the buyers run the reports from your private program library?''

Pat: ''The libraries are organized into a hierarchy. When I get a request for running one of our

reports from non-payables staff members, I decide whether it makes business sense. If so, I

request the database administrator (DBA) to copy the report to a library that they can access.

If the DBAs are busy, it might take a while.''

Kiran: ''Would buyers have access to updated versions of reports?''

Pat: [thinking] ''I never thought of that. I haven't asked the DBAs to republish reports for

buyers or anybody else. Maybe I should.''

Kiran: ''There's one more area to talk about. How will the payables application change with the

contemplated system?''

Pat: ''The current plan is to use the existing application to the extent feasible. I'm looking forward

to doing away with the payables flowing from the delivery tickets. I've never been quite sure

how accurate the tickets were and whether they were accurately reflected in the invoices.''

Kiran: ''Why was that?''

Pat: ''I guess I'm just a born skeptic. Everywhere else we have receiving reports, but not with

these deliveries. Another change will be that instead of all invoices coming over leased lines

from vendors, some invoices will be created in web forms.''

Kiran: ''Which ones?''

Pat: ''The ones from small vendors, e.g., the souvenir makers. For these, the vendor will complete a web form and submit it. If the validation routine detects missing or inconsistent

fields, it will prompt for changes until the invoice passes all the edit checks. Once validated,

the invoices will go straight to the database, where they'll be handled like any other invoice.

When stores take delivery, the store manager (or designee) will indicate receipt to the

system.''

Kiran: ''Cool! Thank you very much for talking to me!''

Pat: ''You're welcome!''

The Scene: Kiran Interviewing Denny, the IT Applications Development Manager

Kiran: ''Thank you for finding time to talk to me. Would you explain your development

process? Maybe illustrate it with the payables application.''

Denny: ''Sure. Users and management get together to agree on application functions. When

they sign off on them, we start. Sometimes, we suggest changes based on the difficulty and

cost of implementing features. Usually, we're able to come to agreement that pleases

everyone involved. Analysts develop the specs in more detail. If they encounter surprises,

they go back to users with them and work them out.''

Kiran: ''Are there many surprises?''

Denny: ''There used to be a lot, but that was before the new CIO (chief information officer)

helped management develop a strategic IT plan for supporting the business.''

Kiran: ''How did that change the process?''

Denny: ''Part of the plan is the requirement that every user proposal be vetted against the plan.

As long as proposals enable the plan and fit the budget, everything's fine. When they don't

enable the plan, the proposal has to go to the IT steering committee. If the proposal

improves on the plan in some way, the committee is likely to incorporate it into the plan. If

not, the committee suggests changes users might make.''

Kiran: ''Okay. What happens after the analyst has developed the specs?''

Denny: ''Programmers develop programs and test them. Once they're satisfied that programs

pass program-level tests, they check them into the development program library. Once a

week, all the programs are compiled together into a build, and integration tests are run

against all the programs in that build. Any programs that break the build are returned to programmers for rework. When the build is deemed complete, we do what we call stress

testing, i.e., throw enough transactions at the application to see how fast it will run before

stalling. Part of the stress testing is maxing out on the volume to see where the app

breaks.''

Kiran: ''Is this the electronic version of running one's car at high speed to see how long it

lasts?''

Denny: ''Sort of, but in the case of programs, there's no damage analogous to blowing out the

engine after redlining the tach for too long. It may be tedious to analyze the results to see

what broke first, but the programs themselves are intact.''

Kiran: ''This kind of testing must be expensive. How did you come to this approach?''

Denny: ''Once you get in the pattern, this testing is probably no more expensive than what we

used to do. The reason we do it is because several years ago, when we brought up a new

system, everything came to an abrupt halt because the load was too much. In hindsight, we

figured out that the throughput and volume were predictable. We think we learned our

lesson. Once an app passes stress testing, users get a shot at it in user acceptance testing.

When users sign off, the app goes to QA (quality assurance), which occasionally finds

things that need fixing. From there, QA authorizes the DBAs to install the app in the

production library.''

Kiran: ''Who can run programs from the production library?''

Denny: ''Only operations personnel. When programmers need data for the next program

iteration, whatever extracts they need are made available to them in their development

libraries.''

Kiran: ''Do you have much of a backlog?''

Denny: ''Not as much as we used to have. The strategic plan helped, and more users are writing

more of their own ad hoc reports now. I'm skeptical of their quality, but can't do anything

about it because we just don't have the staff to write reports for everyone. But even BI

(business intelligence) reports would be better than spreadsheets.1 Another thing that

worries me is desktop control.2 Users actually want IT to defend their desktops against

viruses and bots. After that, it's a mess. Users want to install new software before IT can

vouch for its good behavior. Even worse, users can plug in external media like USB drives.

Although users need flexibility, it makes us vulnerable. In my opinion, it's just a matter of

time before we're written up in the business press about some unintended data exposure.''3

Kiran: ''I see balancing control and ease of use getting even more complex. Thank you for

talking to me.''

The Scene: Kiran Interviewing Kwan, the IT Security Manager

Kiran: ''Thank you for finding time to talk to me. This won't take long. Tell me who authorizes

access.''

Kwan: ''It all goes back to user management. When employees are hired, their managers

specify the access privileges they get based on existing profiles. For example, there's a base level

profile for entry-level accounts payable staff. When employees move to different

positions, their managers authorize us to add privileges consistent with their new roles.''

Kiran: ''When do you terminate access?''

Kwan: ''Usually, it's when employees leave the company. We remove the employees from the

access tables, and that takes care of that. You won't hear about our former employees still

having access to IT resources! We get lists of terminated employees daily from HR (human

resources), which means we're not having to rely on managers to tell us.''

Kiran: ''How secure is the system?''

Kwan: ''Of course, it's very secure. Employees gain access to their areas with radio frequency

identification badges, and passwords have to be eight characters with some upper and lower

case letters and some numbers. The system enforces password changes every 90 days, and

passwords can't be reused within a year.''

Kiran: ''What can you tell me about server security?''

Kwan: ''You mean the computers in the operations center?''

Kiran: ''Yes.''

Kwan: ''You need to see Dana in systems support.''

Kiran: ''Thanks!''

The Scene: Kiran Interviewing Dana, Systems Support Manager

Kiran: ''Kwan said you could tell me about server security.''

Dana: ''I'd like to say 'secure,' but I know better. After reading about the holes in one

company's security perimeter,4 we did a little sleuthing. As a result, we identified over a

hundred servers that weren't protected. We're in the process of protecting them, although

some users aren't exactly ecstatic about it.''

Kiran: ''Has there ever been a penetration test of perimeter security?''

Dana: ''No, we haven't been able to budget for it. Finding that many unprotected servers is

giving us reasons to ask for more security-related funding. Now that we've identified all the

servers (I think!), we're working through changing all the default settings.5 The stuff to fix

is endless!''

Kiran: ''At least you know why you're doing it!''

Dana: Yes, but users don't always appreciate their work being rearranged.''

Kiran: [puzzled] ''What's 'rearranged'?''

Dana: ''Changing default settings entails users having to deal with harder passwords and more

of them. In some cases, access privileges were removed. The end result is that it takes users

longer to get their work done.''

Kiran: ''Okay, I get it.''

Dana: ''After we get the servers protected, we'll worry about how to deal with the growing tide

of personal technology that users want to have all the time.''

Kiran: ''How's that a problem?''

Dana: ''We can't support every personal technology, e.g., iPhones, but users figure out how to

use them anyway. If we could work with users, we'd be more likely to help them take

advantage of personal technology for business use without creating information or system

vulnerabilities. The security risks are enormous.''

Kiran: ''I think I understandthe personal technologies aren't going away. They're

multiplying instead.''

Dana: ''Like rabbits!''

1.prepare a business process diagram (BPD) for the existing 24-Seven Company accounts payable processing system.

2. prepare a business process diagram (BPD) for the processing of 24-Seven Company accounts payable that takes into account the changes proposed by the company by modifying the diagram provided in section 1.

3. Provide an analysis of control weaknesses and their potential impact on the financial statements and operational effectiveness. Divide the analysis according to; 1. Weaknesses in the existing system only, 2. Weaknesses in the proposed system only, 3. Weaknesses in both the existing system and the proposed system. Use the Table 1 template as a guide.

4. Give suggestions for overcoming the weaknesses identified in section 3.

table 1:

existing systems only

control weaknesses | potential upward effect |

| financial statements | operational effectiveness |

1.

2

recommendation system only

control weaknesses | potential upward effect |

| financial statements | operational effectiveness |

1

2

existing systems and recommendations

control weaknesses | potential upward effect |

| financial statements | operational effectiveness |

1

2