Identifying Effective and Efficient Sets of Internal Controls from a Process-Oriented

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 1 Data Attributes Table/Attributea Explanation customerOrder: Customer order for a PC orderIDa Unique identifier for a customer order customerID Unique identifier for a customer paymentID Unique identifier for a customer’s payment date Date customer placed order orderAmount Dollar amount for the order taxes Dollar amount of taxes on the order shipping Dollar amount of shipping on the order totalAmount Dollar amount of total of order components customerOrderLineItem: Parts required to complete an order ordered Unique identifier for an order partID Unique identifier for a part quantity Quantity of the part pickDate Date and time part will be picked from assembly line store customerPayment: Payment from customer paymentID Unique identifier for a customer payment amount Amount in dollars of a customer payment datePaid Date customer payment committed creditCardCompanyID Unique 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 funds authorizationID Unique identifier for an EFT authorizationr palletSummaryID Unique identifier for a pallet summary dateDue Date and time payment due amountDue Amount due in dollars supplierID Unique identifier for a supplier suppplierAccountID Unique identifier for the supplier’s bank account to receive payment supplierBankID Unique identifier for the supplier’s bank EFTconfirmation: Confirmation of funds transfer confirmationID Unique identifier for an EFT confirmation authorizationID Unique identifier for an EFT authorization datePaid Date and time funds transferred amountEFT Dollar amount transferred supplierID Unique identifier for a supplier supplierAccountID Unique identifier for the supplier’s bank account to receive payment supplierBankID Unique identifier for the supplier’s bank invoice: Invoice from a supplier invoiceID Unique identifier for an invoice supplierID Unique identifier for a supplier supplierInvoiceCode Supplier’s unique identifier for an invoice invoiceTotal Dollar amount for an invoice invoiceDate Creation date of an invoice datePaymentDue Date payment for an invoice is due a Primary keys in bold TABLE 1 (Continued) Data Attributes invoiceLineItem: Line item on an invoice invoiceID Unique identifier for an invoice lineID Unique identifier for an invoice line partID Unique identifier for a part datePalletsAccepted Date pallets were accepted palletPrice Price of a pallet of a part, in dollars palletQuantity Quantity of pallets lineItemTotal Product of palletPrice and palletQuantity chargebackAmount Amount in dollars of chargebacks for a partID palletAcceptance: Acceptance of a pallet from a supplier palletAcceptanceID Unique identifier for a pallet acceptance partID Unique identifier for a part supplierID Unique identifier for a supplier dateAccepted Date and time pallet accepted operatorID Unique identifier for the operator accepting the pallet RFIDtagID Unique identifier for the RFID tag on the pallet palletPrice Price of a pallet of a part, in dollars palletChargeback Amount in dollars of chargebacks for a pallet palletSummaryID Unique identifier for a pallet summary palletSummary: Summary by day of pallets accepted palletSummaryID Unique identifier for a pallet summary supplierID Unique identifier for a supplier totalDueSupplier Total amount in dollars due a supplier for accepted pallets datePrepared Date and time summary prepared datePaymentDue Due date for payment partLowNotice: Recognition that assembly-line stores need replenishing partLowNoticeID Unique identifier for a part low notice partID Unique identifier for a part dateNoticed Date and time low parts noticed operatorID Unique identifier for the operator recording the notice partFailure: Part failure during assembly partID Unique identifier for a part supplierID Unique identifier for a supplier palletAcceptanceID Unique identifier for a pallet acceptance failureDate Date and time of a part failure assemblyStage Assembly stage in which failure is detected failureCode Code for the kind of failure partPrice: Prices of parts, from suppliers partID Unique identifier for a part supplierID Unique identifier for a supplier effectiveDate Date and time the price goes into effect palletPrice Price of a pallet of the part, in dollars unitsPerPallet Number of units of the part per pallet TABLE 1 (Continued) Data Attributes supplierPriceUpdate: Price update for parts, from suppliers partID Unique identifier for a part supplierID Unique identifier for a supplier effectiveDate Date and time the price goes into effect palletPrice Price of a pallet of the part, in dollars unitsPerPallet 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 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

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. 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.

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 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” 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

164 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

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 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. TABLE 2 Controls Noted By Control Objective Accounts Payable Balance Rights/ Missing Control Existence Completeness Valuation Obligations Parts Controls Included in Effective and Efficient Sets 1. 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 Above 5. Referential integrity: PaymentID is required foreign key in order table 6. 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. 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 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. 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. 16

FIGURE 1 PC-Now Company Procure -to-Pay Process With Existing Controls in the Krishnan et al . (2005 ) Format r e Track PC m Order and Receive PC o t from web s pay for PC and monitor u site C

6. Weekly,

r reconcile paid e

p orders with Deliver to p i

h production customer S

5 minutes 3-7 hours 10 minutes 12 hours y l

b Truck PC to

m Burn Match PC Transfer e Assemble Pass Yes merge center s software & Pack PC s and to

a PC tests? test PC monitor shipper C Pack monitor P

No 5. Referential 2. Reconcile &

1. Accept

n g payments due

y 1. Replace Daily:

r o n integrity: i t i l order & t with invoices n y u c PaymentID is part(s) Return e n d u payment E, C, R/O a r e d required foreign 2. Record part defective e p h o 2. Schedule r d c failure(s) parts m r

p key in order s

o PC build O

C table

w o N - No No C P 1. Write part-low 3. Reconcile

s Signal c

i notice Refill Yes confirmed t Yes Tractor- supplier to s i Parts low? 2. Read RFID tag assembly- payments with

g trailer low? deliver next o 3. Write pallet line stores authorizations to L load acceptance pay E, C, R/O Daily

s 1. Append prices t e

l 1. Prepare pallet Authorize Receive n

b to partSupplier- Record u

a summaries Receive electronic payment o

y Update table charge- c a

c 2. Select invoices funds transfers confirma- p

A 2. Apply prices to backs payments due by supplier tions partPrice table

r Daily: Stage

e Weekly: Send Prepare Drive i l Accept pallets p changed and send truck to p defective for u parts prices invoices bay S parts pickup 1. Daily: Reconcile part-low notices with

s pallet acceptances ' 4. SDLC:

w Make funds

k to detect RFID read o

n Operation of price Notify

N a failures transfers to -

b lookup PC-Now

C E, C, R/O suppliers

P V 17

FIGURE 2 PC-Now Company Procure-to-Pay Process : Existing and Missing (in bold) Controls r e Track PC m Order and Receive PC o t from web s pay for PC and monitor u site C

6. Weekly,

r reconcile paid e

p orders with Deliver to p i

h production customer S

5 minutes 3-7 hours 10 minutes 12 hours y l

b Truck PC to

m Burn Match PC Transfer e Assemble Pass Yes merge center s software & Pack PC s and to

a PC tests? test PC monitor shipper C Pack monitor P

No 5. Referential C. Daily, 2. Reconcile &

1. Accept

n g payments due

y 1. Replace Daily: reconcile PC

r o n integrity: i t i l order & t with invoices n y u c PaymentID is part(s) Return production with e n d u payment E, C, R/O a r e d required foreign 2. Record part defective pallets accepted e p h o 2. Schedule r d c failure(s) parts and chargebacks. m r

p key in order s

o PC build O Missing parts

C table

w o N - No No C P 1. Write part-low 3. Reconcile

s Signal c

i notice Refill Yes confirmed t Yes Tractor- supplier to s i Parts low? 2. Read RFID tag assembly- payments with

g trailer low? deliver next o 3. Write pallet line stores authorizations to L load acceptance pay E, C, R/O Daily

s 1. Append prices 1. Get price and t e

l Authorize Receive n

b to partSupplier- Record prepare pallet u

a Receive electronic payment o

y Update table charge- summaries c a

c invoices funds transfers confirma- p

A 2. Apply prices to backs 2. Select by supplier tions partPrice table payments due

r B. Weekly: Verify Daily: Stage e Weekly: Send Prepare Drive i l Accept pallets p changed prices match and send truck to p defective for u parts prices supplier prices invoices bay S V parts pickup 1. Daily: Reconcile part-low notices with A. Reconcile pallet

acceptances and

s pallet acceptances ' 4. SDLC:

w Make funds

k to detect RFID read charge backs with o

n Operation of price Notify

N a failures pallet summaries transfers to -

b lookup PC-Now

C E, C, R/O and payments due suppliers

P V E, C, R/O 18