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