ACCT 432 Week 4 Group Discussion Board Forum 3 Example

Group Discussion Board Forum 3: Transaction Processing, Financial Reporting Systems and the Audit Trail

ACCT 432 IT Audit, Group Discussion Board Forum 3

Thread by [Student Name]

The company and the classmates are composites; the textbook and the scholarly research cited are real.

The problem I selected asks how the audit trail changes when transaction processing is fully computerized. Cedar Valley Foods, a composite distributor, takes orders through a customer portal, ships from a warehouse system that prints no picking slips, bills electronically and receives payment by bank transfer matched automatically to invoices. Every journal entry for sales, cost of sales and cash is generated by the system, and no paper document exists at any step. Its auditors still select forty sales transactions at year-end and ask for supporting documents.

Hall (2016) explains that in computerized systems the audit trail consists of transaction logs, master files, reference files and the system's own records of processing, rather than source documents. At Cedar Valley, the evidence that a sale occurred is the order record, the shipment record and the posting, linked by keys in the database. Because postings are real-time, an error in the pricing master file affects every invoice from the moment it is entered. The auditor's central question becomes whether the master files and processing logic were controlled, not whether a paper invoice exists.

That shift argues for continuous auditing. Alles et al. (2008) reported on two pilot implementations and found that automating existing procedures was achievable but that the real gains came from rethinking which procedures to perform. Kogan et al. (2014) built a two-tier design in which a rules layer tests each transaction, for instance that a payment has an approved invoice behind it, and an analytics layer flags patterns that look unusual, and they evaluated it on purchasing records supplied by a major hospital system. In a paperless system, testing forty transactions in December examines the smallest part of the only evidence there is. For Cedar Valley, rule-based tests on every invoice and payment would replace much of the year-end sampling. The auditors would spend their time on the exceptions instead of on transactions that were never in doubt.

Reply to Hannah

Hannah, you argued that continuous monitoring would let Cedar Valley's auditors catch pricing errors within days rather than at year-end, and I agree that speed is the main advantage. The difficulty I would add is volume. Speed only helps if someone can respond to what the system finds. Kogan et al. (2014) separated exceptions, which violate a definite business rule, from anomalies, which are merely unusual, precisely because analytical tests on a full population generate far more flags than any team can investigate. If Cedar Valley's system processes 4,000 invoices a day and even 1% are flagged, staff face 40 investigations daily, and many will turn out to be harmless, such as a legitimate customer discount. Hall (2016) notes that controls are only effective when their outputs are reviewed and acted on. A practical design would start with a small number of high-value rules, such as any invoice price below cost or any payment without a matching invoice, track how many flags prove to be real errors, and retire or refine tests that rarely find anything. Over time, the system becomes more precise and the review workload falls. Without that tuning, staff learn to ignore the alerts, which is worse than having no system, because it creates the appearance of control without the substance. Auditors who later test the control will find unreviewed alerts and conclude it did not operate. I would also assign each rule an owner who decides when its threshold should change, so that tuning does not happen informally.

Reply to Luis

Luis, you pointed out that auditing standards were written around sampling and that an auditor who tests every transaction may still wonder how to document the evidence. That is a fair concern. It is also one the profession has recognized for years. Alles et al. (2008) observed that continuous auditing has been led largely by researchers and pilot projects rather than by changes in standards, and practice has moved faster than guidance. Still, nothing in the standards prevents full-population testing; the question is how to evaluate and document it. Firms that use analytics today have built their own documentation templates. Hall (2016) explains that computer-assisted audit techniques can serve as tests of controls or substantive tests, depending on what they examine, which gives auditors a way to classify the work. At Cedar Valley, a rule that matches every payment to an approved invoice is a test of the operating effectiveness of the matching control over the whole year, and the exceptions it finds are the population for follow-up. The auditor documents the rule, the data source and how its completeness was verified, the number of exceptions and their resolution. Reconciling the record count to the general ledger is the usual way to show that no data were left out. Kogan et al. (2014) showed that such rules can be evaluated systematically, which gives the documentation a defensible basis. Until standards catch up, careful documentation of that kind is what lets the evidence stand on review, and it gives a reviewer the same rule to rerun if questions arise later.

References

Alles, M. G., Kogan, A., & Vasarhelyi, M. A. (2008). Putting continuous auditing theory into practice: Lessons from two pilot implementations. Journal of Information Systems, 22(2), 195-214. https://doi.org/10.2308/jis.2008.22.2.195

Hall, J. A. (2016). Information technology auditing (4th ed.). Cengage Learning.

Kogan, A., Alles, M. G., Vasarhelyi, M. A., & Wu, J. (2014). Design and evaluation of a continuous data level auditing system. Auditing: A Journal of Practice & Theory, 33(4), 221-245. https://doi.org/10.2308/ajpt-50844