24-Seven: Missing information relevant to payables processing

Question that Kiran should have asked or pursued further	Reason for asking the question
1	How do you know suspended transactions are resolved timely, i.e., in time to be included in the right month?	Suspension of invoices beyond the determination of the period-end payables adjusting entry would lead to understatement of payables
2
3	[add rows as needed]

24-Seven: Effects of control weaknesses associated with accounts payable processing

Control weakness	System affected: Current, contem-plated or both	Potential effect on
Financial statements	Operational effectiveness
1	Suspended payables transactions potentially omitted from calculations of adjusting entries	Both	Accounts payable may be understated	Planning for cash management may underestimate cash needs
2
3	[add rows as needed]

Read the conversation below and determine what flaws the system has in the table above.

The scene: Early in the year, when 24-Seven accounting staff 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.

Kiran: Just what gets matched?

Pat: PO number on the invoice to PO 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 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 for all payable invoices. 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 closing 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 following month, which sums the amounts of invoices with invoice status = 'R'. The sum becomes the amount for the adjusting entry to the GL 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 make 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 easy--there's 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 it's own idiosyncrasies, that might be quite a job.

Kiran: Can we go back to the process for a moment? Where was invoice 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 (8 full-time and 4 part-time) have read access to payables transactions and reports. Management has been talking about an AI approach like what Airbus is doing, which cut its employee expense reimbursement time in half while halving the workload for payables staff. 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 and vendor addresses.

Kiran: How did you get started writing reports? In 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 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: 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 evolve an existing report to make 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 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 make 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 invoice will go straight to the database, where it'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, 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 overwhelmed. 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. Another thing that worries me is desktop control. 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.

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 RFID badges, and passwords have to be 8 characters with some upper and lower case letters and some numbers. The system enforces password changes every six months, and passwords can't be reused.

Kiran: What can you tell me about sever 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, 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. 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 setting 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 understand--the personal technologies aren't going away. They're multiplying instead.

Dana: Like rabbits!