Paper-1

advertisement
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
2
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
Unique identifier for a customer order
orderIDa
customerID
paymentID
date
orderAmount
taxes
shipping
totalAmount
Unique identifier for a customer
Unique identifier for a customer’s payment
Date customer placed order
Dollar amount for the order
Dollar amount of taxes on the order
Dollar amount of shipping on the order
Dollar amount of total of order components
customerOrderLineItem: Parts required to complete an order
Unique identifier for an order
ordered
Unique identifier for a part
partID
quantity
Quantity of the part
pickDate
Date and time part will be picked from assembly line store
customerPayment: Payment from customer
Unique identifier for a customer payment
paymentID
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
Unique identifier for an EFT authorizationr
authorizationID
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
Unique identifier for an EFT confirmation
confirmationID
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
Unique identifier for an invoice
invoiceID
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
3
datePaymentDue
a
Primary keys in bold
Date payment for an invoice is due
4
TABLE 1 (Continued)
Data Attributes
invoiceLineItem: Line item on an invoice
Unique identifier for an invoice
invoiceID
Unique identifier for an invoice line
lineID
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
Unique identifier for a pallet acceptance
palletAcceptanceID
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
Unique identifier for a pallet summary
palletSummaryID
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
Unique identifier for a part low notice
partLowNoticeID
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
Unique identifier for a part
partID
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
Unique identifier for a part
partID
Unique identifier for a supplier
supplierID
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
5
TABLE 1 (Continued)
Data Attributes
supplierPriceUpdate: Price update for parts, from suppliers
Unique identifier for a part
partID
Unique identifier for a supplier
supplierID
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
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.
6
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.
7
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
8
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”
9
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
10
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
11
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.
12
TABLE 2
Controls Noted By Control Objective
Accounts Payable Balance
Control
Existence
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
Completeness
Valuation
Rights/
Obligations
√
√
√
√
√
√
√
√
√
√
Missing
Parts
√
√
√
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.
13
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 autogeneration of code derived from graphical specifications offers the promise of solving the longstanding 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
14
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): 173212.
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.
15
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): 6971. Available at http://www.journalofaccountancy.com/Issues/1997/Feb/implic.
16
Customer
FIGURE 1
PC-Now Company Procure-to-Pay Process With Existing Controls in the Krishnan et al. (2005) Format
Track PC
from web
site
Order and
pay for PC
Receive PC
and monitor
Shipper
6. Weekly,
reconcile paid
orders with
production
PC assembly
5 minutes
Assemble
PC
12 hours
10 minutes
3-7 hours
Burn
software &
test PC
Pass
tests?
Yes
Truck PC to
merge center
Pack PC
Match PC
and
monitor
Pack monitor
1. Replace
part(s)
2. Record part
failure(s)
Parts low?
Transfer
to
shipper
2. Reconcile
payments due
with invoices
E, C, R/O
Daily:
Return
defective
parts
No
Logistics
PC-Now Company
Order entry &
production
scheduling
No
5. Referential
integrity:
PaymentID is
required foreign
key in order
table
1. Accept
order &
payment
2. Schedule
PC build
Deliver to
customer
No
1. Write part-low
notice
Yes
2. Read RFID tag
3. Write pallet
acceptance
Refill
assemblyline stores
Signal
supplier to
deliver next
load
Yes
Tractortrailer low?
3. Reconcile
confirmed
payments with
authorizations to
pay
E, C, R/O
PC-Now's
bank
Supplier
Accounts
payable
Daily
1. Append prices
to partSupplierUpdate table
2. Apply prices to
partPrice table
Record
chargebacks
Weekly: Send
changed
parts prices
1. Daily: Reconcile
part-low notices with
pallet acceptances
to detect RFID read
failures
E, C, R/O
1. Prepare pallet
summaries
2. Select
payments due
Receive
invoices
Daily:
Accept
defective
parts
Prepare
and send
invoices
4. SDLC:
Operation of price
lookup
V
Authorize
electronic
funds transfers
by supplier
Drive
truck to
bay
Receive
payment
confirmations
Stage
pallets
for
pickup
Make funds
transfers to
suppliers
Notify
PC-Now
17
Customer
FIGURE 2
PC-Now Company Procure-to-Pay Process: Existing and Missing (in bold) Controls
Track PC
from web
site
Order and
pay for PC
Receive PC
and monitor
Shipper
6. Weekly,
reconcile paid
orders with
production
PC assembly
5 minutes
Assemble
PC
12 hours
10 minutes
3-7 hours
Burn
software &
test PC
Pass
tests?
Yes
Truck PC to
merge center
Pack PC
Match PC
and
monitor
Pack monitor
1. Replace
part(s)
2. Record part
failure(s)
Transfer
to
shipper
2. Reconcile
payments due
with invoices
E, C, R/O
C. Daily,
reconcile PC
production with
pallets accepted
and chargebacks.
Missing parts
Daily:
Return
defective
parts
No
Logistics
PC-Now Company
Order entry &
production
scheduling
No
5. Referential
integrity:
PaymentID is
required foreign
key in order
table
1. Accept
order &
payment
2. Schedule
PC build
Deliver to
customer
No
Parts low?
1. Write part-low
notice
Yes
2. Read RFID tag
3. Write pallet
acceptance
Refill
assemblyline stores
Signal
supplier to
deliver next
load
Yes
Tractortrailer low?
3. Reconcile
confirmed
payments with
authorizations to
pay
E, C, R/O
PC-Now's
bank
Supplier
Accounts
payable
Daily
1. Append prices
to partSupplierUpdate table
2. Apply prices to
partPrice table
Weekly: Send
changed
parts prices
Record
chargebacks
B. Weekly: Verify
prices match
supplier prices
V
1. Daily: Reconcile
part-low notices with
pallet acceptances
to detect RFID read
failures
E, C, R/O
1. Get price and
prepare pallet
summaries
2. Select
payments due
Receive
invoices
Daily:
Accept
defective
parts
Prepare
and send
invoices
4. SDLC:
Operation of price
lookup
V
A. Reconcile pallet
acceptances and
charge backs with
pallet summaries
and payments due
E, C, R/O
Authorize
electronic
funds transfers
by supplier
Drive
truck to
bay
Receive
payment
confirmations
Stage
pallets
for
pickup
Make funds
transfers to
suppliers
Notify
PC-Now
18
Download