Identifying Effective and Efficient Sets of Internal Controls

in a Highly Automated Procure-To-Pay Process

Abstract: Auditors seek to perform effective audits in the most efficient way. In highly automated

systems, auditors may be able to gain efficiencies by testing controls. An effective set of controls

gives a high level of assurance of the absence of errors pertaining to system objectives, e.g., the

balance sheet assertions for existence, completeness, and valuation, and the absence of fraud. An

efficient set of controls comprises the fewest (or cheapest to test) set of controls that is still

effective. This paper demonstrates how to use a business process diagram (BPD) with controls in

the Krishnan et al. (2005) notation to identify effective and efficient sets of internal controls for a

procure-to-pay process including a control set for a specific kind of fraud. To the extent effective

or efficient control sets do not exist, additional controls whose implementation would enable

effective and efficient sets of controls are explained.

Key Words: Business process; Effective control set; Efficient control set; Internal control

evaluation; Procure-to-pay process

Identifying Effective and Efficient Sets of Internal Controls

in a Highly Automated Procure-To-Pay Process

INTRODUCTION

The implementation of accounting systems with only digital transactions creates

opportunities for auditors to take advantage of electronic evidence to perform effective audits in

the most efficient way (AICPA 1997; Williamson 1997; Lavigne 2003). In highly automated

systems, auditors may be able to gain efficiencies by testing controls provided the controls give a

high level of assurance of the absence of errors (an effective control set) and the controls can be

tested efficiently. An efficient set of controls comprises the fewest (or cheapest to test) set of

controls that is still effective. This paper demonstrates the use of a business process diagram

(BPD) with controls in the Krishnan et al. (2005) notation to identify effective and efficient sets

of internal controls for a procure-to-pay process for a make-to-order personal computer (PC)

company. To the extent effective or efficient control sets do not exist in the company’s existing

system, additional controls whose implementation would enable effective and efficient sets of

controls are designed.

The Notation

To illustrate the use of a BPD with controls in the Krishnan et al. (2005) notation, consider

Figure 1 showing PC-Now Company’s procure-to-pay process. PC-Now is a fictitious company

that makes personal computers (PCs) to order, loosely modeled on accounts of Dell Computer

Corporation’s approach to its make-to-order PC business (Kraemer et al. 2000; Magretta 2002;

Murphy 2003; Breen 2004; Goff 2005; Null 2005). The BPD satisfies the Business Process

Management Institute’s specifications for business process diagrams (BPMI 2004; White 2004)

enhanced with the Krishnan et al. (2005) notation for showing the span of controls. Their

convention is to show controls in process symbols with dashed lines marking the beginning and

the end of the sequence of processes subject to the control, i.e., the span of control. Data

definitions for attributes appear in Table 1.

TABLE 1Data Attributes

Table/Attributea Explanation

customerOrder: Customer order for a PC

orderIDa Unique identifier for a customer ordercustomerID Unique identifier for a customerpaymentID Unique identifier for a customer’s paymentdate Date customer placed orderorderAmount Dollar amount for the ordertaxes Dollar amount of taxes on the ordershipping Dollar amount of shipping on the ordertotalAmount Dollar amount of total of order components

customerOrderLineItem: Parts required to complete an orderordered Unique identifier for an orderpartID Unique identifier for a partquantity Quantity of the partpickDate Date and time part will be picked from assembly line store

customerPayment: Payment from customerpaymentID Unique identifier for a customer paymentamount Amount in dollars of a customer paymentdatePaid Date customer payment committedcreditCardComp

anyIDUnique identifier for a credit card company

creditCardNumber

Unique identifier for a credit card

authorizationNumber

Authorization number from a credit card company

EFTauthorization: Authorization to transfer fundsauthorizationID Unique identifier for an EFT authorizationrpalletSummaryI

DUnique identifier for a pallet summary

dateDue Date and time payment dueamountDue Amount due in dollarssupplierID Unique identifier for a suppliersuppplierAccoun

tIDUnique identifier for the supplier’s bank account to receive payment

supplierBankID Unique identifier for the supplier’s bank

EFTconfirmation: Confirmation of funds transferconfirmationID Unique identifier for an EFT confirmationauthorizationID Unique identifier for an EFT authorizationdatePaid Date and time funds transferredamountEFT Dollar amount transferredsupplierID Unique identifier for a suppliersupplierAccountI

DUnique identifier for the supplier’s bank account to receive payment

supplierBankID Unique identifier for the supplier’s bank

2

invoice: Invoice from a supplierinvoiceID Unique identifier for an invoicesupplierID Unique identifier for a suppliersupplierInvoiceC

odeSupplier’s unique identifier for an invoice

invoiceTotal Dollar amount for an invoiceinvoiceDate Creation date of an invoicedatePaymentDue Date payment for an invoice is due

a Primary keys in bold

3

TABLE 1 (Continued)Data Attributes

invoiceLineItem: Line item on an invoiceinvoiceID Unique identifier for an invoicelineID Unique identifier for an invoice linepartID Unique identifier for a partdatePalletsAccep

tedDate pallets were accepted

palletPrice Price of a pallet of a part, in dollarspalletQuantity Quantity of palletslineItemTotal Product of palletPrice and palletQuantitychargebackAmo

untAmount in dollars of chargebacks for a partID

palletAcceptance: Acceptance of a pallet from a supplierpalletAcceptanceID Unique identifier for a pallet acceptance

partID Unique identifier for a partsupplierID Unique identifier for a supplierdateAccepted Date and time pallet acceptedoperatorID Unique identifier for the operator accepting the palletRFIDtagID Unique identifier for the RFID tag on the palletpalletPrice Price of a pallet of a part, in dollarspalletChargebac

kAmount in dollars of chargebacks for a pallet

palletSummaryID

Unique identifier for a pallet summary

palletSummary: Summary by day of pallets acceptedpalletSummary

IDUnique identifier for a pallet summary

supplierID Unique identifier for a suppliertotalDueSupplier Total amount in dollars due a supplier for accepted palletsdatePrepared Date and time summary prepareddatePaymentDue Due date for payment

partLowNotice: Recognition that assembly-line stores need replenishingpartLowNoticeI

DUnique identifier for a part low notice

partID Unique identifier for a partdateNoticed Date and time low parts noticedoperatorID Unique identifier for the operator recording the notice

partFailure: Part failure during assemblypartID Unique identifier for a partsupplierID Unique identifier for a supplierpalletAcceptance

IDUnique identifier for a pallet acceptance

failureDate Date and time of a part failureassemblyStage Assembly stage in which failure is detectedfailureCode Code for the kind of failure

partPrice: Prices of parts, from supplierspartID Unique identifier for a partsupplierID Unique identifier for a supplier

4

effectiveDate Date and time the price goes into effectpalletPrice Price of a pallet of the part, in dollarsunitsPerPallet Number of units of the part per pallet

TABLE 1 (Continued)Data Attributes

supplierPriceUpdate: Price update for parts, from supplierspartID Unique identifier for a partsupplierID Unique identifier for a suppliereffectiveDate Date and time the price goes into effectpalletPrice Price of a pallet of the part, in dollarsunitsPerPallet Number of units of the part per pallet

CONTROLS FOR ASSERTIONS ABOUT ACCOUNT BALANCES

With respect to account balances at the end of a period, management’s financial statements

make assertions about existence, completeness, valuation and allocation, and rights and

obligations (AICPA 2004, AU326). In Figure 1, if a control pertains to these assertions, the last

line of the control symbol text identifies the relevant assertions, i.e., E, R, C, and V for existence,

rights/obligations, completeness, and valuation and allocation, respectively. An account balance

relevant to the procure-to-pay process is accounts payable. The sections below illustrate the use

of the BPD with controls depicted in the Krishnan et al. (2005) notation to identify existing

controls for specific assertions for accounts payable for parts from suppliers that are assembled

into PCs and for one common kind of fraud in assembly operations.

Existence Assertion

The existence assertion addresses whether the ending accounts payable balance reflects

payables that actually exist as of the report date. Begin scanning the company’s swimlane1 for

logistics, looking for processes in which the company assumes liability for paying for parts from

suppliers. The first symbol is the gateway “Parts low?” which checks for sufficient parts being

staged for assembly. The process after the “Parts low?” gateway shows the company accepting

pallets of parts from suppliers (“Read RFID tag” and “Write pallet acceptance”), which initiates

1 A swimlane shows the flow of a process from left to right for a specific entity or a subdivision within an entity. A pool is a set of swimlanes belonging to one entity. For example, the pool for PC-Now Company has swimlanes for accounts payable, logistics, order entry/production scheduling, and PC-assembly. The supplier appears as a pool with a single swimlane.

5

the payable transaction for pallets as they are accepted. The radio-frequency (RF) reader is

positioned at double white lines painted on the assembly plant floor. The company’s agreement

with suppliers is that the company takes possession of a pallet when it crosses the double white

lines. Suppliers stage truckloads of pallets at docks to the plant. When a truck trailer has only a

few pallets left, the company signals the supplier to deliver another truckload.

The first control over this part of the process bears the text “1. Daily: Reconcile part-low

notices with pallet acceptances to detect RFID read failures.” This control pertains to existence by

in ensuring that pallets accepted (and thus recorded as payable) were physically accepted,

signified by the part-low notice and corresponding RFID tag for the pallet accepted.

When parts fail to pass assembly tests (“Pass tests?” gateway in the PC assembly swimlane),

they are replaced in the PC and a charge back record is written to decrease pallet price by the

price of the defective parts (“Record charge backs” in the swimlane for accounts payable). The

next process (“1. Prepare pallet summaries and 2. Select payments due”) is where the charge

backs are applied. No control, however, gives assurance that the charge backs are actually

applied. This means we have identified an instance of potential lack of control over payables. If

charge backs are not applied, the company may pay for defective parts that should have been

returned and charged back to the supplier. There are at least two approaches to designing the

absent control. We could invoke control over the system development life cycle to verify that the

“Prepare pallet summaries” process works correctly, or we could design an independent control,

e.g., “Reconcile pallet acceptances and charge backs with pallet summaries and payments due.”

The preferred approach may depend on the volatility of system changes for charge back

processing. If system changes are rare, depending on the integrity of the SDLC might be

sufficient. If system changes are frequent, an independent control is probably preferred because it

makes the control explicit and less likely to be overlooked in subsequent system changes

affecting the processing of charge backs. This new control (“A. Reconcile pallet acceptances and

charge backs with pallet summaries and payments due”) appears on the BPD in Figure 2.

6

As shown, the company initiates payments to suppliers based on its records of its payables,

i.e., the process “Select payments due” occurs before “Receive invoices.” Notice, however, the

control that assures that the company and supplier agree, i.e., “2. Reconcile payments due with

invoices,” on payments due.

The last portion of the payables process concerns the execution of the electronic funds

transfers (EFTs). The control “3. Reconcile confirmed payments with authorizations to pay”

verifies that every payment made was authorized, i.e., the payments were for payables that

actually exist.

For the existence assertion, we have identified three existing controls and designed one new

control. Because all the transactions are available in electronic form (data attributes in Table 1),

an auditor could test the controls with queries of the data. Because the four controls involve

reconciliations, they could be tested by querying the results of the reconciliations looking for

unreconciled transactions or other anomalies.

Completeness Assertion

The completeness assertion addresses whether the ending accounts payable balance reflects

all the payables that should be included as of the report date. As before for the existence

assertion, begin scanning the company’s swimlane for logistics, looking for processes in which

the company assumes liability for paying for parts from suppliers. The first symbol is the gateway

“Parts low?” which checks for sufficient parts being staged for assembly. The process after the

“Parts low?” gateway shows the company accepting pallets of parts from suppliers (“Read RFID

tag” and “Write pallet acceptance”), which initiates the payable transaction for pallets as they are

accepted.

The first control over this part of the process bears the text “1. Daily: Reconcile part-low

notices with pallet acceptances to detect RFID read failures.” This control pertains to

7

completeness by ensuring that pallets physically accepted were recorded as payable, signified by

the part-low notice and corresponding RFID tag for the pallet accepted.

When parts fail to pass assembly tests (“Pass tests?” gateway in the PC assembly swimlane),

they are replaced in the PC and a charge back record is written to decrease the pallet price by the

price of the defective parts (“Record charge backs” in the swimlane for accounts payable). The

next process (“1. Prepare pallet summaries and 2. Select payments due”) is where the charge

backs would be applied. No control, however, gives assurance that the charge backs are not

applied in excess of those warranted by the volume of defective parts. This constitutes an instance

of potential lack of control over payables. If charge backs are applied in excess of defective parts,

the company may neglect to include all portions of accepted, non-defective pallets in its payables

transactions. As in the case for existence, there are at least two approaches to designing the absent

control. We could invoke control over the system development life cycle to verify that the

“Prepare pallet summaries” process works correctly, or we could design an independent control,

e.g., “Reconcile pallet acceptances and charge backs with pallet summaries and payments due.”

The preferred approach may depend on the volatility of system changes for charge back

processing. If system changes are rare, depending on the integrity of the SDLC might be

sufficient. If system changes are frequent, an independent control is probably preferred because it

makes the control explicit and less likely to be overlooked in subsequent system changes

affecting the processing of charge backs.

As shown, the company initiates payments to suppliers based on its records of its payables,

i.e., the process “Select payments due” occurs before “Receive invoices.” Notice, however, the

control that assures that the company and supplier agree, i.e., “2. Reconcile payments due with

invoices,” on payments due. This reconciliation ensures that the company includes all accounts

payable transactions.

The last portion of the payables process concerns the execution of the electronic funds

transfers (EFTs). The control “3. Reconcile confirmed payments with authorizations to pay”

8

verifies that all authorized payments were actually made, i.e., that the set of payments to suppliers

is complete.

Like the case for the existence assertion, there were three existing controls and one new

control to design. Because all the transactions are available in electronic form (data attributes in

Table 1), an auditor could test the controls with queries of the data. Because the four controls

involve reconciliations, they could be tested by querying the results of the reconciliations to

identify unreconciled transactions or other anomalies.

Valuation and Allocation Assertion

The valuation and allocation assertion addresses whether accounts payable is valued at

appropriate amounts and that any allocation adjustments are appropriately recorded. Because this

example concerns only direct materials in the form of parts assembled into PCs, there are no

allocations. Begin scanning the supplier pool and the company’s swimlane for accounts payable,

looking for processes concerned with the prices of parts from suppliers. Suppliers send price

changes (Supplier: “Weekly: Send changed parts prices,”) which the company appends to its

supplier update table (“1. Append prices to partSupplierUpdate table.”) These additions to the

table are then applied to the partPrice table (“2. Apply prices to partPrice table,”) incorporate the

updated prices. Price updates are frequent because PC parts depreciate, on average, from a half to

a full percentage point a week. Daily, the system prepares a pallet summary by supplier for the

pallets accepted since the last pallet summary was prepared (“1. Get price and prepare pallet

summaries,’) which looks up pallet prices and adds the palletSummaryID to the corresponding

row in the palletAcceptance table. The company depends on change control to maintain the

integrity of processing (4. SDLC: Operation of price lookup”), that is, to ensure that the lookup

program finds and records the right price. No other processes are involved in valuation.

Because the application of updated prices from suppliers affects the prices the company uses

in pricing the pallets included in payables, a control is warranted to verify that prices match

9

164

supplier prices by week. Because all the transactions are available in electronic form (data

attributes in Table 1), this control could be made a permanent part of the system. This control

(“B. Weekly: verify prices match supplier prices”) appears in Figure 2.

Rights and Obligations Assertion

The assertion for rights and obligations addresses whether the company has the rights to

claim assets and that liabilities are the obligations of the company. For accounts payable, a

liability, there is only the obligation, which is fixed through the processes establishing existence

and completeness, as explained above.

CONTROLS FOR DETERRING FRAUD

Fraud in the Form of Misappropriated Parts

A fraud risk endemic with assembly operations as in PC-Now is misappropriation of parts for

personal gain. Similar to the analysis for control over assertions about the accounts payable

balance, the BPD can be used to assess the strength of control over this kind of event. The risk

begins with the acceptance of pallets in PC-Now’s logistics swimlane (Figure 1) because that is

when parts become available to persons at PC-Now. The existing process has no control for

detecting when parts that may be usable in production are never applied to production. Because

many PC parts are small and of high value, employees or others may be able to profit by

removing them from the production area. A control for detecting when accepted parts less

charged back parts are never applied in production would be to reconcile PC production with

pallets accepted and charged back parts. This control (“C. Daily, reconcile PC production with

pallets accepted and charge backs”) appears in Figure 2.

EFFECTIVE AND EFFICIENT CONTROL SETS

Table 2 shows the existing and newly designed controls and the control objectives to which

they pertain as explained above. Existing controls are numbered, and newly designed controls are

10

preceded with letters. For each objective, the control sets are both effective and efficient. Some

controls pertain to more than one objective. All the existing controls except two pertain to the

control objectives for the accounts payable balance or detecting missing parts. As they appear in

Figure 1, these two controls are:

5. Referential integrity: PaymentID is required foreign key in order table

6. Weekly, reconcile paid orders with production

Although these two controls do not pertain to objectives for accounts payable or detection of

missing parts, they are germane to control objectives for other processes.

11

TABLE 2Controls Noted By Control Objective

Accounts Payable BalanceMissing

PartsControl Existence Completeness ValuationRights/

Obligations

Controls Included in Effective and Efficient Sets1. Daily: Reconcile part-low notices with

pallet acceptances to detect RFID read failures

√ √ √

2. Reconcile payments due with invoices √ √ √3. Reconcile confirmed payments with

authorizations to pay√ √ √

A. Reconcile pallet acceptances and charge backs with pallet summaries and payments due

√ √ √

4. SDLC: Operation of price lookup √B. Weekly: Verify prices match supplier

prices√

C. Daily: Reconcile PC production with pallets and accepted and charge backs

√

Controls Not Included in Effective and Efficient Sets for Control Objectives Listed Above5. Referential integrity: PaymentID is

required foreign key in order table6. Weekly: Reconcile paid orders with

production

ASSESSMENT OF FEASIBILITY IN PRACTICE

For over 25 years, auditors and academicians have tried to develop approaches for evaluating

internal control that would be rigorous, systematic, and tractable in practice. One of the earliest of

these was Bailey et al.’s The Internal Control Model (TICOM) for designing, analyzing, and

evaluating internal control systems, which required coding agents and tasks in the PASCAL

programming language and using a query processor to analyze the model. The internal

representation was in the form of “a bilogic-directed graph showing both control and data flows”

(Bailey et al. 1985 194). While TICOM was rigorous and systematic, its use was not tractable in

practice. The burden of representing systems in the programming language was huge, and the

logic embedded in graph representations was foreign to audit practice. Since that time, other

mathematically-based frameworks have been developed, but they suffered similar fates in not

being amenable to practice.

12

Changes in Business and Auditing

Several changes in the business and auditing environments support the wider applicability of

the modeling approach illustrated here with PC-Now’s procure-to-pay process. Business process

representations in the BPMN (BPMI 2004) or comparable formats (Carnaghan 2006) are

becoming more common in business because they are being prepared at design time as part of the

system development process (Kalpic and Bernus 2002). Thus, if business process models already

exist, auditors would not have to incur the expense of preparing them. Furthermore, the auto-

generation of code derived from graphical specifications offers the promise of solving the long-

standing problem of non-existent or out-of-date documentation. Although BPMN (BPMI 2004)

does not explicitly represent flow of control, Krishnan et al.’s (2005) extension of BPMN for

explicit representation of controls offers a means of building out the constructs required to

facilitate control recognition for evaluating internal control and performing audit risk

assessments. The generation and maintenance of BPDs by the development process would ensure

currency and completeness of the graphical representations of business processes, overcoming

one of the impediments to evaluating control with an automated internal control framework.

A change in the auditing environment has made graphical modeling potentially more useful.

The change is the adoption of assertion-based auditing, which has the effect of separating some

complex audit constructs into simpler ones. That is, instead of auditors simultaneously thinking

about existence, completeness, and valuation all at once, they can now focus on the separate

assertions individually.

Prospects for Continuous Monitoring and Auditing

The controls in PC-Now’s procure-to-pay process assume one of two forms: reconciliations of

data generated by operations as PCs are assembled and reliance on control over system

development and subsequent change control. Because all the data required for the reconciliations

are generated and maintained electronically, they could be automated with escalating messages

sent to appropriate operational and internal audit staff for remediation commensurate with the

13

level of reconciliation failures. This is a case where continuous monitoring and auditing might be

implementable (Rezaee et al. 2002; Vasarhelyi 2002; Alles et al. 2006; Carnaghan 2006;

Vasarhelyi and Chan 2011).

SUMMARY

This paper demonstrated how to use a business process diagram (BPD) with controls in the

Krishnan et al. (2005) notation to identify effective and efficient sets of internal controls for the

accounts payable balance for a procure-to-pay process including a control set for a specific kind

of fraud. To the extent effective or efficient control sets did not exist, additional controls whose

implementation would enable effective and efficient sets of controls were designed. The paper

argued that even though earlier attempts to apply mathematical frameworks to model and

evaluate internal control did not lead to use in practice, the shift to business process

representations such as business process diagrams (BPD) combined with the application of

assertion-based auditing makes the approach illustrated here more promising. In addition, this

approach may make continuous monitoring and auditing more implementable.

REFERENCES

AICPA, A. I. o. C. P. A. 1997. The Information Technology Age: Evidential Matter in the Electronic Environment. Jersey City, NJ: American Institute of Certified Public Accountants.

———. 2004. Codification of Auditing Standards Numbers 1-101. New York, NY: American Institute of Certified Public Accountants.

Alles, M., M. G. Brennan, A. Kogan, and R. P. Srivastava. 2006. Continuous monitoring of business process controls: A pilot implementation of a continuous auditing system at Siemens. International Journal of Accounting Information Systems 7: 137-161.

Bailey, A. D., Jr., G. L. Duke, J. Gerlach, C.-E. Ko, R. D. Meservy, and A. B. Whinston. 1985. TICOM and the analysis of internal controls. The Accounting Review 60 (2): 186-201.

BPMI, B. P. M. I. 2004. Business Process Modeling Notation (BPMN) Version 1.0. Aurora, CO: BPMI. Available at http://www.bpmi.org/downloads/BPMN-V1.0.pdf.

Bradford, M., S. B. Richtermeyer, and D. F. Roberts. 2007. System diagramming techniques: an analysis of methods used in accounting education and practice. Journal of Information Systems 21 (1): 173-212.

Breen, B. 2004. Living in Dell time. Fast Company (November): 96-105. Available at http://www.fastcompany.com/magazine/88/dell.html.

Carnaghan, C. 2006. Business process modeling approaches in the context of process level audit risk assessment: An analysis and comparison. International Journal of Accounting Information Systems 7: 170-204.

14

Goff, J. 2005. Start with demand: Demand-driven manufacturing is radically altering how some businesses serve customers. CFO Magazine (January): 53-57. Available at http://cfomagazine.com/article.cfm/3515755?f=search.

Kalpic, B., and P. Bernus. 2002. Business process modelling in industry--the powerful tool in enterprise management. Computers in Industry 47: 299-318.

Kraemer, K. L., J. Dedrick, and S. Yamashiro. 2000. Refining and extending the business model with information technology: Dell Computer Corporation. The Information Society 16: 5-21.

Krishnan, R., J. Peters, R. Padman, and D. Kaplan. 2005. On data reliability assessment in accounting information systems. Information Systems Research 16 (3): 307-326.

Lavigne, A. 2003. Electronic Audit Evidence. Toronto, Ontario: Canadian Institute of Chartered Accountants.

Magretta, J. 2002. Why business models matter. Harvard Business Review 80 (5): 86-92.Murphy, C. 2003. Imagining what’s possible. InformationWeek (September 8. Available at

http://www.informationweek.com/news/showArticle.jhtml?articleID=14500036): 52-56.Null, C. 2005. Dude, you’re getting a Dell-Every five seconds. Business 2.0 (December 1): 73-73.

Available at http://money.cnn.com/magazines/business2/business2_archive/2005/12/01/8364587/index.htm.

Peslak, A. R. 2005. Incorporating business processes and functions: Addressing the missing element in informaiton systems education. The Journal of Computer Information Systems 45 (4): 56-61.

Rezaee, Z., A. Sharbatoghlie, R. Elam, and P. L. McMickle. 2002. Continuous auditing: Building automated auditing capability. Auditing: A Journal of Practice and Theory 21 (1): 147-163.

Vasarhelyi, M. 2002. Concepts in continuous assurance. In Researching Accouning as an Information Systems Discipline, edited by V. Arnold and s. G. Sutton. Sarasota, FL: American Accounting Association.

Vasarhelyi, M., and D. Y. Chan. 2011. Innovation and practice of continuous auditing. International Journal of Accounting Information Systems 12.

White, S. A. 2004. Introduction to BPMN. Aurora, CO: BPMI. Available at http://www.bpmi.org/downloads/Introduction_to_BPMN89.pdf.

Williamson, A. L. 1997. The implications of electronic evidence. Journal of Accountancy (February): 69-71. Available at http://www.journalofaccountancy.com/Issues/1997/Feb/implic.

15

FIGURE 1PC-Now Company Procure-to-Pay Process With Existing Controls in the Krishnan et al. (2005) Format

Cus

tom

er

PC

ass

embl

y

Burn software &

test PC

5 minutes

Order and pay for PC

Assemble PC

Ord

er e

ntry

&

prod

uctio

n sc

hedu

ling

Logi

stic

sA

ccou

nts

paya

ble

Sup

plie

rP

C-N

ow C

ompa

ny

1. Accept order & payment

2. Schedule PC build

Refill assembly-line stores

Match PC and

monitor

Drive truck to

bay

Stage pallets

for pickup

Truck PC to merge center

Pack PC

3-7 hours 10 minutes

Pack monitor

Transfer to

shipper

12 hours

Parts low?

1. Write part-low notice

2. Read RFID tag3. Write pallet

acceptance

Tractor-trailer low?

Pass tests?

No

Signal supplier to deliver next

load

Yes

Shi

pper Deliver to

customer

Receive PC and monitor

Track PC from web

site

1. Replace part(s)

2. Record part failure(s)

Yes

No

Yes

No

Record charge-backs

Daily

Authorize electronic

funds transfers by supplier

PC

-Now

's

bank

Make funds transfers to suppliers

Notify PC-Now

Receive payment confirma-

tions

6. Weekly, reconcile paid

orders with production

5. Referential integrity:

PaymentID is required foreign

key in order table

Weekly: Send changed

parts prices

1. Append prices to partSupplier-Update table

2. Apply prices to partPrice table

4. SDLC: Operation of price

lookupV

3. Reconcile confirmed

payments with authorizations to

payE, C, R/O

1. Daily: Reconcile part-low notices with pallet acceptances to detect RFID read

failuresE, C, R/O

Daily: Return

defective parts

Daily: Accept

defective parts

Prepare and send invoices

Receive invoices

1. Prepare pallet summaries

2. Select payments due

2. Reconcile payments due with invoices

E, C, R/O

16

FIGURE 2PC-Now Company Procure-to-Pay Process: Existing and Missing (in bold) Controls

Cus

tom

er

PC

ass

embl

y

Burn software &

test PC

5 minutes

Order and pay for PC

Assemble PC

Ord

er e

ntry

&

prod

uctio

n sc

hedu

ling

Logi

stic

sA

ccou

nts

paya

ble

Sup

plie

rP

C-N

ow C

ompa

ny

1. Accept order & payment

2. Schedule PC build

Refill assembly-line stores

Match PC and

monitor

Drive truck to

bay

Stage pallets

for pickup

Truck PC to merge center

Pack PC

3-7 hours 10 minutes

Pack monitor

Transfer to

shipper

12 hours

Parts low?

1. Write part-low notice

2. Read RFID tag3. Write pallet

acceptance

Tractor-trailer low?

Pass tests?

No

Signal supplier to deliver next

load

Yes

Shi

pper Deliver to

customer

Receive PC and monitor

Track PC from web

site

1. Replace part(s)

2. Record part failure(s)

Yes

No

Yes

No

Record charge-backs

Daily

Authorize electronic

funds transfers by supplier

PC

-Now

's

bank

Make funds transfers to suppliers

Notify PC-Now

Receive payment confirma-

tions

C. Daily, reconcile PC

production with pallets accepted

and chargebacks.Missing parts

6. Weekly, reconcile paid

orders with production

5. Referential integrity:

PaymentID is required foreign

key in order table

Weekly: Send changed

parts prices

1. Append prices to partSupplier-Update table

2. Apply prices to partPrice table

4. SDLC: Operation of price

lookupV

B. Weekly: Verify prices match

supplier pricesV

3. Reconcile confirmed

payments with authorizations to

payE, C, R/O

1. Daily: Reconcile part-low notices with pallet acceptances to detect RFID read

failuresE, C, R/O

Daily: Return

defective parts

Daily: Accept

defective parts

Prepare and send invoices

Receive invoices

1. Get price and prepare pallet summaries

2. Select payments due

2. Reconcile payments due with invoices

E, C, R/O

A. Reconcile pallet acceptances and charge backs with pallet summaries

and payments dueE, C, R/O

17

18