101 ACL Apps

101 ACL Applications:
A Toolkit for Today’s Auditor
by Richard B. Lanza, CPA
THIRD EDITION
© Copyright 2000 Richard B. Lanza All rights reserved 1

Copyright © 2000 Richard B. Lanza
All rights reserved. Third edition.
No part of this publication may be reproduced in any form by any means, electronic or
mechanical including photocopying and recording, information storage, retrieval or
transmission without permission in writing from the publisher, except by a reviewer who may
quote brief passages in a review.
Global Audit Publications

575 Richards Street
Vancouver, BC
Canada V6B 2Z5
gap_editor@acl.com
Global Audit Publications' mission is to provide a worldwide forum to disseminate innovative

and productive concepts and ideas regarding technology commonly used by auditors,
information security experts and other information guarantors. Authors wishing to submit
manuscripts are encouraged to contact the publisher for publication guidelines.
LIMITATION OF LIABILITY/DISCLAIMER OF WARRANTY: THE AUTHOR, RICHARD B.

LANZA, AND THE PUBLISHER, GLOBAL AUDIT PUBLICATIONS, HAVE USED THEIR
BEST EFFORTS IN PREPARING THIS BOOK AND ARE NOT RESPONSIBLE FOR ANY
ERRORS OR OMISSIONS. THEY MAKE NO REPRESENTATIONS OR WARRANTIES WITH
RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS BOOK
AND SPECIFICALLY DISCLAIM ANY IMPLIED WARRANTIES OR MERCHANTABILITY
OR FITNESS FOR ANY PARTICULAR PURPOSE AND SHALL IN NO EVENT BE LIABLE
FOR ANY LOSS OF PROFIT OR ANY OTHER FINANCIAL OR COMMERCIAL DAMAGE,
INCLUDING, BUT NOT LIMITED TO, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR
OTHER DAMAGES.
All product names, trademarks or registered trademarks are the property of their respective
companies, including:
ACL for WindowsACL Services Ltd.
Excel, Word, WindowsMicrosoft Corporation
ISBN 1-894497-08
Written, printed and bound in Canada
2 © Copyright 2000 Richard B. Lanza All rights reserved

Table of Contents
101 ACL Applications: A Toolkit for Today’s Auditor
Table of Contents i-1

Introduction i-9
Staying Informed with ACL Software i-11
Key Concepts i-13
Where to find more information i-15
How the book is organized i-17
Chapters 1-3
Read This First 1-1

Motivation behind this book 1-1
The Seven Steps To Power Applications 1-2
Continuous Auditing Procedures 2-1
Adjusting Your Data and Batches 2-1
Chapter 4: General Ledger
General Ledger 4-1

General Ledger Objectives 4-1
General Ledger Applications 4-1
General Ledger Data File 4-2
General Ledger Verification Batch 4-3
Application 1: Stratify general ledger activity
for unusual trends and exceptions 4-7
Copyright © 2000 Richard B. Lanza All rights reserved i-1

Application 2: “Flatten” journal entries into one record
to extract repetitive and unique journal entries 4-11
Application 3: Summarize debit and credit activity
Application 4: Summarize general ledger activity
on account type 4-27
Application 5: Merge detailed information
from other modules into the general ledger 4-29
Application 6: List all journal entries
that do not net to zero 4-33
Application 7: Select journal entry compliance samples
based on various factors 4-37
Application 8: Review the sequence of
journal entry numbers for gaps 4-45
Chapter 5: Purchasing & Accounts Payable
Purchasing and Accounts Payable Management 5-1

Purchasing and Accounts Payable Objectives 5-1
Purchasing and Accounts Payable Activities
are Operating Effectively and Efficiently 5-1
Purchasing and Accounts Payable Data Files 5-4
Purchasing and Accounts Payable Verification Batch 5-8
Application 1: Stratify vendor balances, check amounts,
invoice amounts, purchase order amounts, approval limits
and check dates for unusual trends and exceptions 5-13
Application 2: List vendors with post office boxes
for identification of possible fictitious vendors 5-21
Application 3: Match payroll file to vendor file
for identification of possible unauthorized vendors 5-25
Application 4: Calculate the annualized unit price changes
in purchase orders for the same product in the same year 5-31
i-2 Copyright © 2000 Richard B. Lanza All rights reserved

Application 5: Calculate the variance between
the approved purchase order and the invoice cost 5-31
Application 6: Select expenditure compliance samples
under numerous situations 5-39
Application 7: Review the sequence of invoices,
purchase orders and check numbers for gaps 5-49
Application 8: Analyze purchase orders
based upon their issuers and/or approvers 5-53
Application 9: Extract large invoice payments
excluding any intercompany transactions 5-57
Application 10: Select a Monetary Unit Sample
of vendor invoices and automatically create
confirmation requests 5-61
Application 11: Calculate weighted days payable
outstanding and interest lost for not paying
in 30, 45 and 60 days 5-67
Application 12: Detect vendors with no discounts taken
when discounts have been taken in the past 5-75
Application 13: Calculate interest lost for paying invoices
prior to their due dates 5-79
Application 14: Identify vendors with numerous checks
who could potentially be paid on a monthly basis 5-83
Application 15: List possible duplicate payments based
on matching invoice number, vendor name and
the absolute value of the check amount 5-87
on matching invoice date, vendor name and
on invoice date, invoice number and
Application 18: Extract check payments
for unrecorded liability testwork 5-95
Application 19: Consolidate vendor activity to assess
organizational purchasing power 5-101
Application Recommendations 5-102

Application 20: Summarize debit memos on vendor, issuer,
and type for exceptions and unusual trends 5-105
Application 21: Identify all vendors with debit balances 5-111
Chapter 6: Payroll Processing
Payroll Processing 6-1

Payroll Processing Objectives 6-1
Payroll Processing Applications 6-2
Payroll Processing Data Files 6-3
Payroll Processing Verification Batches 6-6
Application 1: Stratify payment amounts, hours worked,
hourly rates and check dates for
unusual trends and exceptions 6-11
Application 2: Reconcile salaried employee gross pay
from one pay period to the next 6-17
Application 3: Compare payroll costs
from one period to another 6-21
Application 4: List all hourly employees working
more than the total hours available in the week 6-27
Application 5: Select a payroll sample
for compliance testwork 6-31
Application 6: Compare payroll data files to
human resource data files to detect additional/missing
employees and differing salary rates 6-35
Application 7: List possible duplicate payments
based on the same day and employee 6-41
Application 8: List possible duplicate payments
based on the check date and the absolute value
of the check amount 6-41
Application 9: Review the sequence
of check numbers for gaps 6-47

Chapter 7: Billing and Accounts Receivable Management
Billing Function and A/R Management Objectives 7-1

Billing Function and A/R Management Applications 7-2
Billing Function and A/R Management Data Files 7-3
Billing Function and A/R Management Verification Batches7-7
Application 1: Stratify sales for unusual trends
and exceptions 7-13
Application 2: Stratify cash receipts for unusual trends
and exceptions 7-19
Application 3: Calculate weighted days sales
outstanding (“DSO”) by customer, salesperson,
and the entire organization 7-25
Application 4: Review the sequence of invoices,
sales orders and shipping documents for gaps 7-33
Application 5: Calculate interest lost for shipments
not billed to date 7-37
Application 6: Calculate interest lost for the time lag
between the shipment being made
and the billing being processed 7-37
Application 7: Recalculate the aging of
accounts receivables 7-43
Application 8: Report customers with old and
large account balances 7-47
Application 9: Identify customers with no set credit limit 7-51
Application 10: Identify customers who have exceeded
their credit limit 7-51
Application 11: Summarize credit memos on customer,
credit manager and type for exceptions and unusual trends 7-55
Application 12: Identify all customers with credit balances7-59
of customer invoices and automatically create
confirmation requests 7-63
Application 14: Analyze discounts taken by customers
after the discount due date 7-69

Chapter 8: Inventory Management
Inventory Objectives 8-1

Inventory Management Applications 8-2
Inventory Management Data File 8-3
Inventory Management Verification Batch 8-6
Application 1: Stratify inventory costs for unusual trends
and exceptions 8-9
Application 2: Calculate inventory turnover and assess it
in relation to part lead times 8-13
Application 3: Identify slow moving inventory parts 8-19
Application 4: Compare unit cost to current sales price
for lower of cost or market testing 8-23
of inventory parts 8-27
Application 6: Summarize inventory adjustments
Application 7: List parts with extended cost, unit cost
or quantity less than zero 8-35
Application 8: Identify inventory not counted
in a specified period of time 8-37
Application 9: Identify parts that have never been counted 8-37
Application 10: Stratify parts based on the last date
they were counted 8-37

Chapter 9: Property, Plant and Equipment
Property, Plant and Equipment Objectives 9-1

Property, Plant and Equipment Applications and Reports 9-2
Property, Plant and Equipment Data File 9-2
Property, Plant and Equipment Verification Batch 9-5
Application 1: Summarize fixed assets
by their depreciable lives 9-9
Application 2: Detect expenses that
should have been capitalized 9-12
Application 3: Extract large additions
or disposals for review 9-17
of fixed assets for vouching and physical inspection 9-21
Application 5: Stratify disposal information
by dollar amount and select a sample for detail testwork 9-25
Application 6: List assets with high salvage values
compared to asset values 9-29
Application 7: List assets that have been depreciated
beyond their cost 9-29
Chapter 10: Electronic Data Processing Review
Electronic Data Processing Objectives 10-1

Electronic Data Processing Applications 10-2
Electronic Data Processing Data Files 10-3
Electronic Data Processing Verification Batch 10-5
Application 1: Review activity reports
for default usernames and usernames of unrecognized
or terminated employees 10-9

Application 2: Review activity reports for users
with no activity in an unacceptable period of time 10-13
Application 3: Summarize access types by username 10-17
Application 4: Review the time of
and length of login times 10-19
Application 5: Review activity reports for login failures 10-23
Chapter 11: Using Dialog Builders With The Toolkit
Implementing Dialog Builder in the PAYROLL_1 batch 11-3
About the author

Introduction
101 ACL Applications gives you all the information you need to produce audit reports
immediately for the most common accounting areas: general ledger, accounts receivable/payable,
payroll, inventory, fixed assets and more. Detailed instructions, report objectives, and audit steps
are included with each application. Electronic templates and sample data are also provided on
disk, giving users an immediate "hands on" experience with ACL -one of the most powerful
software tools currently on the market for auditors, accountants and managers.
The 101 ACL applications are intuitive and easy to understand. They propel you immediately into
an orbit of higher efficiency and professionalism. With these predefined ACL applications you
can access and use most of the data available to you, and do so in minutes or hours. Of course,
ACL still provides powerful interactivity and supports the important intellectual spontaneity so
valuable today. You don't waste time setting yourself up, but apply a proven pattern and are free
to develop these applications over time into your own bank of personal or organizational
'information generators'.
This book assumes the technical knowledge of 'intermediate ACL users'. This means that basic
knowledge of a few key concepts is taken for granted: e.g., view, report, application, batch,
document and notes. They will be briefly explained immediately below the next section, but it
would be ideal if you have had a basic introduction to ACL or some prior experience with it.
The book is also intended to help experienced ACL users to both customize these application
templates for their own data and reporting needs and to develop new ones. Evidently, this book
cannot contain a complete listing of all the reports you may want to produce with ACL. It is
therefore my hope that, over time, these applications will provide the basis for your own audit
programs and management reports-and more importantly, that they will 'tickle' your
imagination. No meaningful and relevant report can be created without imagination. I would be
pleased to hear from you if you want to share the results of your newfound freedom.
© Copyright 2000 Richard B. Lanza All rights reserved i-9

i-10 © Copyright 2000 Richard B. Lanza All rights reserved
Staying Informed with ACL Software
To say that we live in a world of information is an understatement. Actually, we are
living in a world of overabundant information. There are 500 television channels;
the Internet; CD ROMs; 25 data files to process one customer invoice; more data
than could be processed in ten lifetimes;... you name it. The information overload is
evident everywhere and would be overbearing if we did not have the tools to filter
and customize the numerous signals for our own purposes. It is almost trite to
assert: Computers today have become a necessity - at the office and at home! What
we really need now is 'intelligent' software for intelligent users.
The American Institute of Certified Public Accountants' (AICPA) Special

Committee on Financial Reporting was formed in 1991 to address various concerns
about the relevance and usefulness of current financial reporting practices.
Obviously, traditional financial reporting is based on conceptual and technological
assumptions which are no longer true. In times of data glut and information
overload, users of financial information need all the help and support they can get.
Fortunately, we also have vastly improved information processing capabilities - as
long as we can harness them easily for our own purposes.
Not surprisingly, the AICPA Committee concluded, "whether a Fortune 500 CEO,
an investment professional or a financial manager, individuals make important
investment decisions every day or rely on others to make decisions for them based
on the information in financial reporting...In times of rapid change, the risk
increases that business reporting will fall behind the pace of change, failing to
provide what users need to know."
With ACL, business reporting can keep pace with the changing times by equipping
any auditor and manager with the means to generate and test the information
necessary for frequently rapid decision-making and (re)action. This sounds almost
too good to be true, but these applications will convince you that it is true even for
you!
ACL software is a powerful data analysis and interrogation tool that supports the
integration of accounting, controllership and auditing with a common technology.
ACL was designed for auditors and management alike, giving them universal data
access and powerful processing capabilities. It is hard to believe that one software
system can have so many different applications. ACL's adhoc query language

combined with its sophisticated batch capabilities allow auditors and other users to
inquire spontaneously about any information; to test any data; to process even
complex and interactive applications; and to develop value-added reports and
applications relatively easily!
ACL saves time and money: there is no need to learn multiple data analysis and
report writing methods for the various accounting and financial modules in today's
organization. Rather than wasting time with technology, all users can generate
solutions and tests to their hearts' content; follow their own intuition; use their
imagination freely and creatively; and simultaneously organize their thoughts into
standard applications of the kind you see illustrated in this book.

Key Concepts
Throughout this book, six basic ACL concepts need to be understood by the reader:
1 View: In order to see the contents of data files users depend on a ‘View’
which represents those data fields defined and arranged by them for
display on the screen. The data fields become columns in a View and the
user can arrange many different Views, include virtual (COMPUTED)
fields for various purposes and filter the records in various ways. A
View can be printed as a 'Report' at any time the user clicks on the
printer button.
2 Report: When we talk about a 'Report' in this book, we refer to the

results of one or more executed ACL commands. These are presented to
the user in either an ACL data, report or log file; an exported file for
further use with different software; or a View formatted for printout.
3 Application: An ACL 'Application' refers to a single report or a

collection of related reports which support an audit, accounting, or
management area's objectives and provide relevant information.
4 Batch: An ACL 'Batch' collection and grouping of ACL commands that

execute Reports and Applications. The batches reside in the ACL
'Document'. If you know the batch name, you can execute it directly by
double clicking on it in the Overview window, or you can select "Tools"
from the menu bar, choose "Do Batch" and double click on the
appropriate batch for processing.
5 Document: An ACL 'Document' is a collection of ACL input file

definitions, views, batches, workspaces and indexes. This way
applications such as the ones contained in this book can be organized in
a modular and easily understood manner.
6 Notes: With ACL you can document all your work in great detail. For
example, you can attach 'Notes' to Batches, Documents, files and fields.
For additional information pertaining to basic ACL concepts, review the ACL User
Guide and Reference Manual. It is suggested that you also complete the entire ACL

Workbook. At a minimum, be sure to complete or understand the concepts presented
in the following Workbook chapters:
■ Key Concepts (Pages 7 - 9)

■ Lesson 1 - Viewing Data (Pages 11 - 24)
■ Lesson 16 - Creating a Document and Input File Definition (Pages 171-181)
■ Lesson 18 - Using Batches (Pages 197 - 204)

Where to find more information
If you have a question about using ACL, refer to the following resources for
information:
■ ACL User Guide

■ ACL Command Reference
■ ACL Workbook
■ Online Help
If you still can't find the solution to your problem and you are a supported user, in
North America contact ACL Technical Support at 1-604-669-4225 (fax: 1-604-669-
3225). If you have a modem, you can obtain helpful tips and suggestions from the
ACL BBS by calling 1-604-669-3277. Overseas, you should call your local authorized
distributor and/or support center. Alternatively, if you have access to the Internet,
you can get online help by pointing your favorite browser at www.acl.com, or by
sending email to support@acl.com.
When contacting ACL concerning problems, be sure to have the following

information at hand:
■ The serial number of ACL (Select "Help" from the menu bar and choose
About ACL)
■ The type of hardware you are using, and whether it is connected to a Local
Area Network (LAN). A description of what happened and what you were
doing when the problem occurred
■ The error message, if any, displayed by ACL.

How the book is organized
101 ACL Applications comprises the following chapters:
Chapter 1: Read This First - This chapter summarizes the practical motivation of the
book and highlights the Seven Steps to Power Applications which are meant to get
the user up and running ACL applications as soon as possible.
Chapter 2: Continuous Auditing Procedures - This chapter outlines how certain

applications can be used to constantly monitor organizational activity. Constant
monitoring could ultimately replace periodic audit tests. For example, duplicate
payments or key financial stratifications could be "built in"" exception reports,
reviewed routinely rather than in periodic audits. Applications that meet this
criterion will be designated by a "*" in the Table of Contents and associated chapters.
Chapter 3: Adjusting Your Data and Batches - Steps will be provided to adjust the data
definitions provided with the Toolkit to your own data.
Chapter 4: General Ledger
Chapter 5: Accounts Payable
Chapter 6: Payroll
Chapter 7: Billing & Accounts Receivable
Chapter 8: Inventory
Chapter 9: Property Plant & Equipment
Chapter 10: Electronic Data Processing
All chapters begin with a general overview and a listing of the objectives relevant to
the area. The overview and objectives are followed by references to the numbered
applications which will assist in achieving those objectives.
Each application will then be presented in the following detail:
1) an overview for the application
2) the audit objectives supported

3) the data fields necessary
4) the applicable data validity batches that should be utilized
5) the actual batch with supporting explanatory paragraphs, if applicable
6) audit procedures to perform
7) helpful hints.
Through use of the following table, the reader should gain a better appreciation for
the range of applications and reports presented in the Toolkit. Essentially there are
101 reports in six audit areas with a bonus chapter for electronic data processing
which provides an additional five reports.
Chapter Applications Reports
Chapter 4 General Ledger 8 12
Chapter 5 Purchasing and Accounts 21 30
Payable Management
Chapter 6 Payroll Processing 9 12
Chapter 7 Billing Function and Accounts 14 27
Receivable Management
Chapter 8 Inventory Management 10 12
Chapter 9 Property, Plant & Equipment 7 8
Application / Report Totals 69 101
Chapter 10 (Bonus!) Electronic Data Processing 5 5
Total Applications / Reports in Toolkit 74 106

Notes

Notes

Read This First Chapter 1
Motivation behind this book

It’s 9:00 a.m. and you awaken in a room filled with a PC, a data file and ACL for
Windows. But wait, just when you thought everyone has forgotten your existence,
you come across a note left by your supervisor that reads “Test It!”.
This may be taking things a little too far but haven’t we all, at some time in our data
reporting careers, been faced with a similar situation? Wouldn't it have been helpful
from a productivity and self-confidence standpoint to own a book that would:
■ walk you through basic reporting concepts

■ map out each command to execute
■ equip you with sample data and batches, providing a glimpse of the
resulting report prior to the (crunch time) situation
■ suggest audit procedures which could be added to existing audit programs
within your organization.
Now you have all these things. My objective in writing is to apply Computer Assisted
Audit Techniques (“CAATs”) to situations you face as an auditor everyday. The book
can be used as a starting point in your journey or as an aid along the way. When used
effectively, it will help you break through the “information barrier”.
Please note: This book is not meant to be read cover to cover in one sitting, but
is expected to yield positive results one step at a time. (I am sure Confucius would
say this more eloquently!). Use the Seven Steps to Power Applications to ensure that
you attain quick and effective results. Most importantly, have fun!
Copyright © 2000 Richard B. Lanza All rights reserved 1–1

The Seven Steps To Power Applications
1 Identify your audit areas and objectives to test - Most likely, these will
already be identified as you approach ACL for Windows. If not, select an
audit area (Chapters 4 through 10), read its overview and objectives and
browse the associated applications prior to selecting the associated
objectives to test.
2 Select the application that best meets the selected objective - In the
beginning, try to work with one application at a time. As you get
comfortable, it may be more efficient to combine application processing,
especially when preparing to extract the required data from the system.
3 Read the application’s overview, audit procedures, batch notes and

helpful hints to ensure it meets your requirements - The numbered
listing of applications at the beginning of each audit area chapter
(Chapters 4 through 10) may seem self explanatory. Nevertheless, I suggest
that at a minimum, the audit steps, batch notes and overview sections be
read prior to preparing to extract the necessary data. If any commands
appear unfamiliar, review the appropriate ACL for Windows documentation
(i.e. - User Guide, Reference Manual).
Please note: In the Batch section of each application, the key icon indicates
notations which are critical to the proper functioning of the batch.
4 Run the batch on the sample data provided - Insert the disk enclosed with
the textbook into your floppy drive and copy its contents to a directory on
your harddrive. Then after starting ACL for Windows, open the document
TOOLKIT.ACL. To execute the batch, select “Tools” from the menu bar,
choose “Do Batch” and double click on the appropriate batch for
execution.
Allow yourself time to understand the results of each batch. Begin to

imagine how your data will be represented in the reports. Ask yourself:
■ Is the application providing me with enough information to meet the

selected objective?
■ Do I need to add more data fields or can I delete any?
1–2 Copyright © 2000 Richard B. Lanza All rights reserved

■ Does the presentation of the report convey its message effectively?
If the answers to the above questions were “Yes”, “No” and “Yes”, move on
to step 5. Otherwise, analyze your situation and make the necessary changes
to the batch so that you can execute it properly within your own scenario.
5 Review the necessary data file, “Required” data fields and, if you desire,
also review the “Useful” fields as presented in each application’s Data
Fields and Validity Tests section.
Without the ‘required data fields’, batch processing, as defined in the

Toolkit, cannot occur. ‘Useful data fields’ are those that may assist your
efforts in locating supporting documents or broadening the scope of the
report; however, they are not necessary for batch processing. (By default,
the batches and data files supplied with the Toolkit include all required and
useful fields).
Once you are finished reviewing the data fields above:
■ Proceed to the beginning of the audit area’s chapter.

■ Review the appropriate data file field formats and additional
explanatory comments in this area.
■ Obtain the data on your own or request that the data be extracted by
your Technology Group to create your data files. Keep in mind that any
additions, deletions or name changes to data fields will need to be
adjusted in the batch prior to processing.
■ Go to Chapter 3 to learn how to adjust the batches and data definitions
provided with the Toolkit to your own data.
6 Use the verification batch and additional authentication procedures -

Based on the file selected, review the Data Fields and Validity Tests section of
the application to select the appropriate verification batch. It is
recommended that the supplied verification procedures be completed to
provide reasonable assurance that the data fields are valid for processing.
7 Run the batch on your data and perform the audit steps provided - At
this point, the hard work is done. Now all you need to do is:
■ Choose “Do Batch” from the Tools menu and select the batch to execute

■ Perform the audit procedures as outlined in the Audit Steps section of the
application.
Congratulations! You have taken a directive as ambiguous as “Test It!” and

transformed it into a live audit application. From here on you can reapply these
seven steps as often as you want, until you decide to develop your own applications.
Again: Good Luck and Have Fun!

Continuous Auditing Procedures Chapter 2
“Do the job right the first time” - This lesson has prompted accounting system
designers to place data validity checks at the point of input and provide exception
reporting prior to system updates. The question is only: Have the designers included
all possible exception reports, including those required by auditors?
The answer is all too often a flat: “No!”.
So, what is an auditor to do? Learn numerous reporting packages for the various
accounting systems? I wouldn’t suggest it. What would be more efficient is to learn to
use just one system, one that allows you to continuously monitor all of the
accounting results from other packages. That software is ACL for Windows.
Continuous monitoring is a wide-ranging concept, potentially applying to every

aspect of a business. One can monitor inventory values, payrolls, sales, purchasing,
or any other materially significant data, testing for trends, exceptions, and invalid
data. Once the appropriate batch is written, the process is largely automated and
requires little or no ongoing labor. The test itself is often very simple, yet if it were not
automated, it would be prohibitively labor-intensive. For example, in theory it is
assumed that any accounting package on the market today will verify that all journal
entries net to zero. However, in practice, the larger the data set and the more
complex the application, the greater the risk that something has been missed. You
can be sure that the software is indeed operating properly if you run an ACL
application similar to Application 6 in Chapter 4 (General Ledger).
Over time, constant monitoring could ultimately replace periodic audit tests. For
example, an application highlighting possible duplicate payments (Applications 15,
16 and 17 in Chapter 5) could be a “built in” exception report, to be reviewed prior
to each check run, rather than being left for possible detection in an annual audit.

Notes

Notes

Notes

Adjusting Your Data and Batches Chapter 3
This chapter consists of three sections:
1 How to reformat data definitions and ACL batches to fit your own data
2 Verification batches - a summary
3 Helpful hints
1 How to reformat data definitions and ACL batches to fit your own data
For applications like these, intended partly as study exercises, a predefined data set is
essential. In order to process actual data using the batches in this book, you must
first define that data, and in most cases adjust the batches themselves as well. Data
definitions are called ‘input file definitions’ or IFDs in ACL for Windows. This
section shows how easy creating an IFD or making a batch adjustment is. By this
point you will typically have completed Steps 1-4 in the Seven Steps to Power
Applications, that is, you will have set your audit objective, picked a suitable
application, read the documentation, and run the application using the sample data
provided. All you need to do at this point is to take your chosen “app” into the real
world.
To illustrate the reformatting process, I have chosen to work with a hypothetical

general ledger file and General Ledger Application 6, which lists all journal entries
that do not net to zero. This is among the commonest of audit tasks and a logical
starting point, as general ledger data is stored in similar ways in virtually all
accounting systems. If you are just coming to this section for the first time, you will
need to stop to complete Steps 1-4 for GENLED_6 before you can follow the
procedure listed here.
1 When reformatting, you must decide what data to obtain, and what fields in
the data file are needed by the application. You will typically have to request
the data from your Information Systems department. Pay special attention
to the “Required” and “Useful” data fields in the application's Data Fields

and Validity Tests section. In this example, there are only two required fields
and none designated “useful”. The fields required by the application will
obviously have different names in a real system, but by referring to the field
descriptions, you can easily determine what is what. The full field list for the
general ledger sample data is shown below to illustrate. This same list
appears in Chapter 4.
(GENERAL_LEDGER.FIL) - This file consists of all journals posted to the general

ledger for a one year period (1/1/96 to 12/22/96). It is used to process all General
Ledger applications.
Data Structure
44 Records using GENLED.FIL as the data file.
Field Format Start Length Decimal Addtl.format

explanation
GL_Account ASCII 1 5
Trans_Amount NUMERIC 6 9 2
Journal_Entry ASCII 15 5
JE_Date DATE 20 6 PICTURE
“yymmdd”
Misc_Field ASCII 26 8
Field Explanations
GL_Account The general ledger account number.
Trans_Amount The amount of the posted transaction.
Journal_Entry The number of the journal entry.
JE_Date The date of the journal entry.
Misc_Field An additional field used to code particular

transactions.
The following fields in the GENERAL_LEDGER file are required to execute the
GENLED_6 batch:

Required
<Journal_Entry>
<Trans_Amount>
2 Once you receive the data, go into ACL and open your Overview window
(Choose “Open Overview” from the Window menu item). Highlight
the Input File Definition title, then click on the “New” button as identified in
the screen print below:
3 By doing so, you will be brought to the Data Definition Wizard:

Select Next and after selecting the Disk, select the file GENETEST.FIL. You will need
to use the checkboxes to set the file format to Other, the length to Fixed, and to
designate this as a Data File.
If you check off the correct properties, you will be presented with this screen:
Deselect lines by clicking on them, to create the revised field layout shown below:

Select Next and type Journal_Entry in the Name field.
Then click on the Numeric field and type Trans_Amount in the Name field. Finally,
type 2 in the Decimal box. Both required fields have now been defined.
Click Next, Finish, and OK in succession to arrive at the defined file's Default View:

If you ever desire to change the data field definition, you can select Edit, Input File
Definition from the menu bar, double click on the field you choose to edit
(Journal_Entry was selected in the example below), and edit as you choose:
4 Your new file is now defined and is ready for processing with the existing
batch. All that is required is to replace in the application batch (GENLED_6)
the file name “GENERAL_LEDGER” with “GENETEST”.
This can be accomplished by:
■ Editing the batches (Select “Edit” from the menu bar,

choose “Batches”, double-click on GENLED_6),
■ Selecting the “Find and/or Replace” feature
(click on the flashlight button),
■ Typing “GENERAL_LEDGER” in the Find box and typing
“GENETEST” in the Replace With box and
■ Clicking on “Change All” as completed below.

5 How simple this was! You can now run Application 6 (GENLED_6) with
your own data by selecting “Tools” from the menu bar, choosing “Do
Batch” and double clicking on “GENLED_6”.
Potential adjustment issues
If fewer fields are defined, the batch will not process properly, because it expects to find
fields that have not been included in the file.
For example, if you wished to use the file re-defined above as GENETEST in another
batch that calls for an extraction of the Journal_Entry, Trans_Amount and
GL_Account fields, the batch would fail because it would not find the
GL_Account field.
(Only Journal_Entry and Trans_Amount are defined in the GENETEST

file). To rectify this situation, you will need to edit the batch (by selecting “Edit” >
“Batches” from the menu bar and selecting the appropriate batch to edit) but be
careful! If you delete any “Required” fields from the batch (as listed in each
application’s Data Fields and Validity Tests section) the batch will not execute
properly. Therefore, “Useful” fields are the only fields that can be deleted from a
batch without any negative effect on processing. Another solution is to get from your
Information Technology Department all of the “Required” and Useful” fields.

I would like to have more fields listed in the final report than are currently listed in the
batch.
Since the “Required and Useful” fields listed in each application’s Data Fields and
Validity Tests section are the only fields listed in the batch, you will need to edit the
batch to add any additional fields. This can be accomplished by selecting “Edit” >
“Batches” from the menu bar and selecting the appropriate batch to edit.
It would be great if the batch would ask me which fields to use.
This is an intermediate-to-advanced topic. Chapter 11 discusses how to make

batches interactive and includes instructions on how to select desired fields for use in
the batch.
For more information on using data files and defining data fields see Chapters 1
(Quick Start), 3 (Key Concepts) and 4 (Defining Files and Fields) of the ACL User
Guide.
2 Verification Batches - A Summary
A data integrity review should be performed prior to processing to assure the

accuracy and completeness of the data. When discussing each application in the
following chapters, references will be made in each Data Fields and Validity Tests
section. They highlight the need for executing the respective validation batches
which are documented at the beginning of each chapter.
Each verification uses two batches. The first “triggers” the second, which executes
the various commands or, if there is invalid data or certain file requirements not met,
prompts the user with a message indicating the batch has terminated. The use of a
“trigger” batch is an effective method to implement error prevention routines as part
of application processing in ACL.
For an example, the AP_VERIFY batch (see Chapter 5) will continue processing
with the AP_VERIFY1 batch if all fields are verified using ACL’s VERIFY
command (see fourth line of the AP_VERIFY batch). If not, the message “BATCH
TERMINATED” - The data used has an INVALID field/fields. Please review the Last
Result window to determine INVALID field/fields” will present itself to the user.

3 Helpful Hints
Along with the many suggestions in the Helpful Hints section of each application
(see Chapters 4 through 10), the following general hints may prove useful:
Time Adjustment
Depending on the audit's scope, beginning and ending file time points may need to
be adjusted. For example, network access log files may be processed more effectively
in weekly batches yet the data file is extracted from the system in annual form.
To accommodate this modified selection, follow these steps:
1 insert para 4.0.6
Using the ACCEPT command, the batch will prompt you for the date upon which
data extraction should begin, the number of days in the audit period, and the field to
extract. If using the sample data use 12/31/95 in YYMMDD format (i.e. 961231).
SET SAFETY OFF

ACCEPT “Enter the start date in YYMMDD format” to
START_DATE
ASSIGN STARTDATE=CTOD(START_DATE)
ACCEPT “# of days in audit period” to DAYS “Which field do
you wish to extract based upon” FIELDS ‘D’ to F
EXTRACT RECORD TO NEW FOR AGE(%F%,STARTDATE)<VALUE(DAYS,0)
AND AGE(%F%,STARTDATE)<=0
OPEN NEW
DELETE ALL OK
SET SAFETY ON
2 The file named NEW can be renamed to the file name to be used in your
next batch.

Ensure the same data field formats and data types are used - In order to use the
batches in their present form, the data field formats must be the same as those used
in the Toolkit. Otherwise, ACL may not be able to accurately process the application.
Make sure you use reverse quotes for dates - Whenever a date is referenced as in
the command “EXTRACT IF Date_1<>‘000101’”, reverse quotes - not
regular quotes - are surrounding the 000101.
Use Join - It is not expected that the data files used in the Toolkit will exactly match
those used at your organization. An attempt was made though to include
uncomplicated file structures to facilitate comparability. Comparability can be
increased further through the use of the Join command to link or extend the scope
of files. See the ACL for Windows Reference Manual for additional details.
Use the VAL() and STRING() expressions - Such expressions will convert ASCII
data formats to a numeric value and vice versa. This may be of assistance if the fields,
in their “raw form” do not match the format used in the Toolkit. See the ACL for
Windows User Guide for additional details.
Export to your favorite spreadsheet - Although the Print Preview utility provided
with ACL saves a few trees, you can save a forest by exporting the report to a
spreadsheet application rather than printing. Not only is the data more flexible than
in hardcopy form, it is also processed faster.
Make batches interactive - Whenever possible, replace field names and/or batch
requirements with dialog boxes. See Chapter 11 (Dialog Builders) for a discussion
on using dialog boxes in batches.
Watch batches run - By opening the Command Log Window (Select “Window”
from the menu bar and choose “Open Command Log”) prior to executing any
batch, the commands being executed, along with their associated results, can be
viewed as the batch progresses.
Save your log files - ACL produces a log file for each document which can be viewed
in the Command Log Window. Save these log files in your workpaper
documentation to support testwork performed with ACL. These files are saved in an
ASCII format and can therefore be viewed in any word processing software.
3 – 10 Copyright © 2000 Richard B. Lanza All rights reserved

Notes
Copyright © 2000 Richard B. Lanza All rights reserved 3 – 11

Notes

General Ledger Chapter 4
The general ledger is the repository of transactions from all accounting flows within
the organization. Used properly, it can act as a compass, pointing to those areas
considered vital to the audit at hand.
General Ledger Objectives

The following is a list of specific audit objectives for the general ledger along with the
applicable report numbers. The auditor should attempt to obtain reasonable
assurance that the following objectives have been achieved by the organization:
General Ledger Activities are Operating Effectively and Efficiently
Report numbers: 1, 2, 3, 4, 6, 7
General Ledger Activities are Properly Authorized, Accurate and Complete
Report numbers: 1, 2, 3, 4, 6, 7, 8
General Ledger Activities are Properly Classified
General Ledger Applications

Below are eight applications which contain 12 reports. The number of reports and
difficulty level are shown after each application.
1 Stratify general ledger activity for unusual trends and exceptions. (3)
Novice

2 “Flatten” journal entries into one record to extract repetitive, and unique
journal entries. (2) Advanced
3 Summarize debit and credit activity for unusual trends and exceptions. (2)
Novice
4 Summarize general ledger activity on account type. (1) Novice
5 Merge detailed information from other accounting modules into the

general ledger (i.e. - Accounts Payable, Payroll, Fixed Assets or Accounts
Receivable). (1) Intermediate
6 List all journal entries that do not net to zero. (1) Novice
7 Select journal entry compliance samples based on various factors. (1)

Intermediate
8 Review the sequence of journal entry numbers for gaps. (1) Novice
General Ledger Data File
(GENERAL_LEDGER) - This file consists of all journals posted to the general ledger
for a one year period (1/1/96 to 12/22/96). All eight General Ledger applications use
it. The data structure for GENERAL_LEDGER is followed by a field explanation list:

Data Structure
44 Records using GENLED.FIL as the data file.

explanation
GL_Account ASCII 1 5
Trans_Amount NUMERIC 6 9 2
Journal_Entry ASCII 15 5
JE_Date DATE 20 6 PICTURE “yymmdd”
Misc_Field ASCII 26 8
Field Explanation List
GL_Account The general ledger account number.
Trans_Amount The amount of the posted transaction.
Journal_Entry The number of the journal entry.
JE_Date The date of the journal entry.
Misc_Field An additional field used to code particular

transactions.
General Ledger Verification Batch

GL_VERIFY
This batch should be executed prior to using the GENERAL_LEDGER. It will:
1 Execute the Verify command on each data field - Review the “Command
Log” after batch processing to ensure that the command yielded the
response “0 data validity errors detected”.
Please note: The batch will terminate processing at this point, with an
appropriate user dialog box, if the data has any invalid fields.

2 Stratify all general ledger activity for the period on the journal entry credit
amounts, debit amounts and journal entry date - These printed reports
could be reviewed with management for their reasonableness. Care should
be taken with regards to large negative or positive transactions which may
need specific identification and review.
3 Classify information by journal entry number - From the file JE, select a
judgmental sample of journal entry debit amount accumulations and agree
to the supporting journals. The purpose of this test is to ensure, on a modest
level, that the basic dollar amounts used are accurate and complete.
4 Sequence on journal entry number - Review the printed report to

determine if the number of gaps signal an incomplete data extraction. It
may be useful to discuss with management the starting and ending journal
entry numbers for the period which can be matched to the extraction.
This batch is executed by opening the Overview window, expanding the list of
batches, double-clicking on the GL_VERIFY batch, and then clicking “Run” in the
resulting Message box.
When running this batch you will be prompted to enter the aging date. This
parameter is required to allow the AGE() function, as used to stratify on the
JE_Date, to function properly. If using the sample data provided with the Toolkit,
enter the date 12/22/96 in YYMMDD format (i.e. 961222).
SET SAFETY OFF

DELETE ALL OK
OPEN GENERAL_LEDGER
VERIFY FIELDS GL_Account JE_Date Journal_Entry Misc_Field
Trans_Amount ERRORLIMIT 10
The batch will terminate if there are any invalid fields detected using the VERIFY
command. If the data is valid, processing will continue with GL_VERIFY1 which is
listed below.
DO GL_VERIFY1 IF WRITE1=0
PAUSE ‘BATCH TERMINATED - The data used has an INVALID
field/fields. Please review the Last Result window to
determine INVALID field/fields’ IF WRITE1>0

DELETE ALL OK
SET SAFETY ON
GL_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCH GL_VERIFY

- SEE CHAPTER 3 RELATIVE TO VERIFICATION BATCHES
FOR A FURTHER DISCUSSION”
The following field will be used in the associated stratifications and classification
below:
DEFINE FIELD Trans_Amount_Dr COMPUTED

Trans_Amount IF Trans_Amount>0
0.00
To stratify on the debit journal entry amount:
STRATIFY ON Trans_Amount ACCUMULATE Trans_Amount TO SCREEN

FREE 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 IF Trans_Amount>0 HEADER=‘Stratification on
debit activity’
To stratify on the credit journal entry amount:

FREE -1000000, -500000, -100000, -50000,
-10000, -1000, -100, 0 IF Trans_Amount<0
HEADER=‘Stratification on credit activity’
To stratify on the journal entry date:
ACCEPT “Enter the aging date in yymmdd order:” to AGE_DATE

AGE ON JE_DATE CUTOFF AGE_DATE INTERVAL 0, 30, 60, 90, 120,
150, 180, 210, 240, 270, 300, 330, 360 ACCUMULATE
Trans_Amount TO SCREEN IF Trans_Amount>0 HEADER=‘Aging
on journal entry date’

To sequence gaps in journal entry numbers and create a file (JE) for sample
selection:
CLASSIFY ON Journal_Entry ACCUMULATE Trans_Amount_Dr

TO “JE”
DELETE Trans_Amount_Dr OK
OPEN JE
GAPS ON Journal_Entry ERRORLIMIT 10 to SCREEN PRESORT
SET SAFETY ON

Stratify general ledger activity for unusual Application 1
trends and exceptions Batch: GENLED_1
Novice
Overview
Look at the multitude of activities in a general ledger and ask yourself, “How can I
survey this data in an extremely quick manner while efficiently planning my audit”?
This batch should provide the answer (also look at Applications 2 through 4 in this
chapter) along with a means to assess the administrative burden from maintaining
low dollar activity.
Audit Objectives Tested
Data Fields and Validity Tests
The following fields, currently in the file GENERAL_LEDGER as included with this
Toolkit, are required to execute the GENLED_1 batch:
Required
<JE_Date>
<Trans_Amount>

To test the validity of the data used in this application, execute the GL_VERIFY
batch.
Batch
batches, double-clicking on the GENLED_1 batch, and then clicking “Run” in the
parameter is required to allow the AGE command, as used to age on the JE_Date.
If using the sample data provided with the Toolkit, enter the date 12/22/96 in
YYYYMMDD format (i.e. 19961222).
SET SAFETY OFF

OPEN GENERAL_LEDGER
To stratify on debit activity (see the Audit Steps section below for procedures to
perform using the resulting report):

FREE 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 if Trans_Amount>0 HEADER=‘Stratification on
debit activity’

To stratify on credit activity (see the Audit Steps section below for procedures to

FREE -1000000, -500000, -100000, -50000,
-10000, -1000, -100, 0 if Trans_Amount<0
HEADER=‘Stratification on credit activity’
To stratify on JE_Date - Considering a journal entry will normally net to zero (any
that do not will be tested in GENLED_6), the “if Trans_Amount>0”
expression is added to report balances in the stratification (see the Audit Steps
section below for procedures to perform using the resulting report):
AGE ON JE_DATE CUTOFF AGE_DATE INTERVAL 0, 30, 60, 90, 120,

150, 180, 210, 240, 270, 300, 330, 360 ACCUMULATE
Trans_Amount TO SCREEN IF Trans_Amount>0 HEADER=‘Aging
on journal entry date’
SET SAFETY ON
Audit Steps
Review Trans_Amount in the three printed reports for:
■ unreasonably large balances where activity could be extracted for

recalculation and proper classification
■ high number of transactions with low accumulated activity for possible
consolidation
■ planning detailed testing of the journal entry approval process (actual
testwork could be completed by executing Application 7)
■ planning detailed testing based on the time period with increased
throughput.

Helpful Hints
■ To focus audit efforts more precisely, use the time adjustment batch, as
explained in Helpful Hints section of Chapter 3, to select the appropriate
period for review.
■ For continuous auditing purposes or as a managerial tool, the selection of
each month’s data prior to posting may detect potential errors or
irregularities.
■ Use the stratification percentages as a guide to accurately communicate the
coverages obtained in audit tests. For example, “22% of transactions greater
than $500,000, representing 82% of the total dollar activity during 1995,
were found to be properly recorded”.

“Flatten” journal entries into one record to Application 2
extract repetitive and unique journal Batch: GENLED_2
entries Advanced
Overview
Organizations tend to repeat many transactions throughout an audit period, so, why
not review identical transactions once and focus the remainder of your time on the
unique, material activity? The old saying in audit programs, “Scan the General
Ledger for any unusual activity” takes on new meaning with this complete and
searchable report.
Toolkit, are required and/or useful to execute the GENLED_2 batch:
Required Useful
<Journal_Entry> <JE_Date>
<Trans_Amount>
<GL_Account>

batch.
Batch
SET SAFETY OFF

OPEN GENERAL_LEDGER
The next four DEFINE FIELD commands will create separate debit and credit
columns for both the amounts (Trans_Amount_Dr and Trans_Amount_Cr)
and the accounts (GL_Account_Dr and GL_Account_Cr) depending on
whether the value in the field is positive or negative.

0.00
DEFINE FIELD Trans_Amount_Cr COMPUTED
Trans_Amount IF Trans_Amount<0
0.00
DEFINE FIELD GL_Account_Dr COMPUTED
GL_Account IF Trans_Amount>0
“ ”
DEFINE FIELD GL_Account_Cr COMPUTED
GL_Account IF Trans_Amount<0
“ ”

From now on, the batch will “flatten” the data into one record. For example, a
journal entry’s two debit records will become two fields in one record. See the
example below:
The batch requires the activity to be separated into two files, one for debits and the
other for credits, which are then “flattened” and joined to make one file.
EXTRACT ALL IF Trans_Amount_Cr<0 TO CREDITS

EXTRACT ALL IF Trans_Amount_Dr>0 TO DEBITS
END

DELETE Trans_Amount_Cr OK
DELETE GL_Account_Dr OK
DELETE GL_Account_Cr OK
USE DEBITS
The maximum number of debit and credit entries to be processed will be five each.
If you wish to have more than five debits or credits in each entry, complete the
following:
■ Wherever there is a “GL_AccountDR5” or “GL_AccountCR5” field

reference, ensure that a duplicate reference and associated commands be
made for any additional entries. Further ensure that this reference has a
different name (i.e. - GL_AccountDR6).
■ Wherever there is a “Trans_Amount_Dr5” or
“Trans_Amount_Cr5” field reference, ensure that a duplicate reference
and associated commands be made for any additional entries. Further
ensure that this reference has a different name (i.e. -
Trans_Amount_DR6).
ASSIGN CTR=1
The GL_Account_Dr and Journal_Entry fields are both five bytes each. If
your data has different field lengths, make sure the number of spaces and question
marks in the quotes below agrees with those field lengths. This would only be the
case for ASCII fields considering all numeric fields such as Trans_Amount would
be equal to zero.
ASSIGN Pr_Journal_Entry=‘?????’
ASSIGN GL_AccountDr1=‘ ’
ASSIGN Trans_Amount_Dr1=0.00

GROUP IF Journal_Entry=Pr_Journal_Entry
ASSIGN CTR=CTR+1
ASSIGN GL_AccountDr2=GL_Account_Dr IF CTR=2
ASSIGN Trans_Amount_Dr2=Trans_Amount_Dr IF CTR=2
ASSIGN Pr_Journal_Entry=Journal_Entry
ELSE IF RECNO()>1 AND Journal_Entry <> Pr_Journal_Entry
EXTRACT Pr_Journal_Entry AS ‘Journal_Entry’ JE_Date
GL_AccountDr1 GL_AccountDr2 GL_AccountDr3
GL_AccountDr4 GL_AccountDr5 Trans_Amount_Dr1
Trans_Amount_Dr2 Trans_Amount_Dr3 Trans_Amount_Dr4
Trans_Amount_Dr5 TO FLJDR EOF
ASSIGN GL_AccountDr1=GL_Account_Dr
ASSIGN Trans_Amount_Dr1=Trans_Amount_Dr
ASSIGN CTR=1

ELSE IF RECNO()=1 AND Journal_Entry <> Pr_Journal_Entry

ASSIGN GL_AccountDr1=GL_Account_Dr
ASSIGN Trans_Amount_Dr1=Trans_Amount_Dr
ASSIGN CTR=1
END
DELETE ALL OK
Above this note, ACL created FLJDR which is a flat file for all of the debit accounts
in each journal entry. Below, the same will be completed for the credit transactions
which will be aptly named FLJCR. These two files will be joined later in the batch to
create one record for each journal entry (in an input file named FLAT_JOURNALS)
OPEN CREDITS
ASSIGN CTR=1
The GL_Account_Cr and Journal_Entry fields are both five bytes each. If
your data has different field lengths, make sure the number of spaces and question
marks in the quotes below agrees with those field lengths. This would only be the
case for ASCII fields considering all numeric fields such as Trans_Amount would
be equal to zero.
ASSIGN Pr_Journal_Entry=‘?????’
ASSIGN GL_AccountCr1=‘ ’

ASSIGN Trans_Amount_Cr1=0.00
GROUP IF Journal_Entry=Pr_Journal_Entry
ASSIGN CTR=CTR+1
ASSIGN GL_AccountCr2=GL_Account_Cr IF CTR=2
ASSIGN Trans_Amount_Cr2=Trans_Amount_Cr IF CTR=2
ELSE IF RECNO()>1
EXTRACT Pr_Journal_Entry AS ‘Journal_Entry’ JE_Date
GL_AccountCr1 GL_AccountCr2 GL_AccountCr3
GL_AccountCr4 GL_AccountCr5 Trans_Amount_Cr1
Trans_Amount_Cr2 Trans_Amount_Cr3 Trans_Amount_Cr4
Trans_Amount_Cr5 TO FLJCR EOF
ASSIGN GL_AccountCr1=GL_Account_Cr
ASSIGN Trans_Amount_Cr1=Trans_Amount_Cr

ASSIGN CTR=1
ELSE IF RECNO()=1
ASSIGN GL_AccountCr1=GL_Account_Cr
ASSIGN Trans_Amount_Cr1=Trans_Amount_Cr
ASSIGN CTR=1
END
DELETE ALL OK
OPEN FLJDR
OPEN FLJCR SECONDARY
The next command will join the debit and credit transactions into one file named
FLAT_JOURNALS (see the Audit Steps section below for procedures to perform
using the resulting file):
JOIN PKEY Journal_Entry FIELDS Journal_Entry GL_AccountDr1

GL_AccountDr2 GL_AccountDr3 GL_AccountDr4
GL_AccountDr5 Trans_Amount_Dr1 Trans_Amount_Dr2
SKEY Journal_Entry WITH GL_AccountCr1 GL_AccountCr2

Trans_Amount_Cr4 Trans_Amount_Cr5 TO “FLAT JOURNALS”
CLOSE SECONDARY
OPEN FLAT_JOURNALS
The final commands of the batch will create two files named
REPETITIVE_JOURNALS which are all journal entries that are duplicated at least
once and UNIQUE_JOURNALS which are all files which only occur once in the data
examined (see the Audit Steps section below for procedures to perform using the
resulting files):
SORT ON GL_AccountDr1 GL_AccountDr2 GL_AccountDr3

GL_AccountDr4 GL_AccountDr5 GL_AccountCr1
GL_AccountCr5 TO “SORTED”
OPEN SORTED
SUMMARIZE ON GL_AccountDr1 GL_AccountDr2 GL_AccountDr3
GL_AccountDr4 GL_AccountDr5 GL_AccountCr1

GL_AccountCr5 ACCUMULATE Trans_Amount_Cr1
Trans_Amount_Cr5 Trans_Amount_Dr1 Trans_Amount_Dr2
OTHER Journal_Entry TO JOURNALS_SUM PRESORT
OPEN JOURNALS_SUM
GROUP
EXTRACT RECORD IF COUNT>1 TO REPETITIVE_JOURNALS
EXTRACT RECORD IF COUNT=1 TO UNIQUE_JOURNALS
END
SET SAFETY ON
Audit Steps
The initial file to review is the FLAT_JOURNALS file, which, as explained above,
reports each journal entry in one record. Review high dollar activity by creating an
expression totaling all of your debit or credit fields (aptly named
Trans_Amt_Tot_Dr and Trans_Amt_Tot_Cr, respectively) and sort this in
descending order.
Open the REPETITIVE_JOURNALS file, noting that each Trans_Amount field

holds the accumulation of each repetitive entry. Also, note that the
Journal_Entry field is not provided considering it would only report the first
journal entry encountered for that recurring entry (as consistent with the
Summarize command). To understand high activity, regardless of dollar value, try
sorting the transactions in descending order based on the Count field. Or, if you
wish to review high dollar activity, create an expression totaling all of your debit or
credit fields (aptly named Trans_Amt_Tot_Dr and Cr, respectively) and sort
this in descending order. The goal of these analyses is to isolate types of transactions
which can be discussed with management. One such example may be the weekly
posting of expenses from the payroll accounting package. These 52 transactions
need not be reviewed in depth but rather in an overall sense which should provide
more audit time for the unique testwork below.

“Emphasize exceptions” is an underlying rule of the UNIQUE_JOURNALS file. As
discussed above, review high dollar activity by creating an expression totaling either
all of your debit or credit fields, which can then be sorted in a descending fashion.
You now have the largest single journal entries in the year (with entry numbers)
which can be reviewed in detail for proper approval, completeness, accuracy and
classification.
After your analysis of both the REPETITIVE and UNIQUE_JOURNALS files, total
all debit or credit fields and divide this total by the dollar value of transactions
reviewed, in effect calculating the audit coverage obtained.
Helpful Hints
Although the objective of this application is to make one record for each journal
entry so that summarization may take place, it may be easier to review using ACL’s
Multiline View capabilities.

Notes

Summarize debit and credit activity for Application 3
unusual trends and exceptions Batch: GENLED_3
Novice
Overview
Unlike the first two applications in this chapter which dealt mainly with high level or
journal entry analysis, this batch will allow the auditor to observe the general ledger
on an account level basis. Examination of specific accounts could be performed
based on prior experience or relative size in the current audit period.
Toolkit, are required and/or useful to execute the GENLED_3 batch:
Required
<Trans_Amount>
<GL_Account>
batch.

Batch
SET SAFETY OFF

OPEN GENERAL_LEDGER
The next two DEFINE FIELD commands will create debit and credit columns
depending on whether the value in the field is positive or negative.

0.00
DEFINE FIELD Trans_Amount_Cr COMPUTED
Trans_Amount IF Trans_Amount<0
0.00
To create the summarized file of credit and debit activity on account number for use
in the two Sort commands at the end of this batch:
SUMMARIZE ON GL_Account ACCUMULATE Trans_Amount

Trans_Amount_Dr Trans_Amount_Cr TO CREDDEB PRESORT
DELETE Trans_Amount_Cr OK
OPEN CREDDEB
Once the debit and credit activity is summarized on account number, the following
sorts will highlight the material activity (descending sorts on debits and credits) for
the period (see the Audit Steps section below for procedures to perform using the
resulting files):
SORT ON Trans_Amount_Dr D to DEBSORT

SORT ON Trans_Amount_Cr to CREDSORT

SET SAFETY ON
Audit Steps
High dollar activity
Usually, much of the large activity in the general ledger is due to an interface with
other accounting modules such as accounts payable or payroll. Although these are
important, it is usually more interesting to review large transactions that occur less
frequently. These are also displayed in the DEBSORT and CREDSORT files. They are
denoted as having a high balance (Trans_Amount or Cr) and a low number of
transactions (Count). Obtain the account number (GL_Account) from either of
the two created files and extract, using the FLAT_JOURNALS file, all posted
journal entries to that account. These can then be matched to the proper supporting
documentation and discussed with management.
Specific account analysis
Certain accounts deserve more attention because they are difficult to calculate or
they occur infrequently. Based on a simple extraction (EXTRACT IF
GL_Account=‘123’) or use of the Search command in the Analyze menu, the
auditor could quickly conclude whether audit resources are required in these specific
areas. Once this is determined, an extraction from the FLAT_JOURNALS file (as
created in Application 2) would provide all posted journal entries to that account.
These can then be matched to the proper supporting documentation and discussed
with management.

Notes

Summarize general ledger activity on Application 4
account type Batch: no batch
Novice
Overview
Have you ever tried to find a needle in a haystack? Have you ever attempted to locate
transactions in a general ledger without defined coding techniques? It would be
impossible to expect every item to be coded, but why not those entries which
warrant an upper management analysis or which require year-end review by the
auditors? If not already implemented, such a system could be suggested to
management as an effective identification tool.
The following discussion explains the elements in coding a general ledger entry.
There is no batch supplied. After implementing the needed coding field, you can
proceed directly to stratify, classify, or extract the data you are interested in.
There are no specific data fields from the GENERAL_LEDGER file which are
required or useful to execute this process. One field is added to the file, for entry of

codes. (The fields you want, obviously, are whatever fields you wish to stratify,
classify, or extract. These could be anything.)
batch.
Report Recommendations
In order to code activity, there must be an empty field which can either be entered by
the user or automatically updated at posting through the use of program logic
(consult your software vendor or in-house development team). It is also possible to
employ unused bytes in an existing field. For example, the journal entry number
field may have two extra bytes which could be coded with the following suffixes
depending on the type of activity: Payroll - PR, Accounts Payable - AP, Fixed Assets
- FA, etc. After opening this data file in ACL, the journal entry field could be parsed
where the two bytes occur and defined as JE_TYPE.
Using this JE_TYPE field, perform:
■ an extraction (see the Extract command in the ACL for Windows User
Guide) would be the most likely first command, followed by
■ a stratification (see the Stratify command in the ACL for Windows User
Guide) on JE_TYPE to determine where to focus audit efforts and
■ classifications (see the Classify command in ACL’s User Guide) on such
fields as GL_Account, Journal_Entry and AGE(JE_Date) to
further solidify testwork planning.

Merge detailed information from other Application 5
accounting modules into the general Batch: GENLED_5
ledger (i.e. - Accounts Payable, Payroll, Intermediate
Fixed Assets or Accounts Receivable)
Overview
The general ledger can take on a face of anonymity mainly through the use of
summarized posting mechanisms in its programming logic. Hundreds of accounts
payable expenses may be summed into one account posting. Or, a detailed posting
may be made with an uninformative reference such as an accounts payable voucher
number requiring subsequent manual review in that particular module.
This problem can be solved by merging the data from the various modules into a
more complete file, thereby creating an informative and readily available
information source.
There are no specific objectives referenced considering this batch only provides a
more detailed method to review the general ledger and not a direct means of
achieving an audit objective.
Some general data requirements to execute this batch are:
■ The module must post in detail.

■ There must be a common data field between the general ledger and
associated modules.
■ The common data field must be the same length and have the same format
in each file.
■ The common data field must be unique.
Examples of unique fields are as follows for the given modules:
■ Accounts Payable - Voucher number or the combination of vendor number

and invoice number
■ Payroll - Employee number and pay date or check number
■ Billing/Accounts Receivable - Customer invoice number/credit or debit
memo number
■ Fixed Assets - Asset number
For the purposes of this book, the payroll module will be merged into the general
ledger due to the large volume normally posted from this package. The following
fields, currently in the PAYROLL_FILE as included with this Toolkit, are required
and/or useful to execute the GENLED_5 batch:
Required Useful
<Check_Number> <Check_Date>
<Employee_Number> <Department_Code>
<Employee_Name>
<Weekly_Grs_Pay>
<Weekly_Net_Pay>
The following fields, currently in the GENERAL_LEDGER file as included with this
Toolkit, are also required:
Required
<Trans_Amount>
<GL_Account>
<Misc_Field> (which maintains the Check_Number as
referenced from the payroll accounting package)

To test the validity of the data used in this application, execute the GL_VERIFY and
PAYROLL_VERIFY batches.
Batch
The commands will render a simple join of all data fields listed above. Please note the
Misc_Field and Check_Number fields both hold the check number, are equal
in length (8 bytes) and are the same in type (ASCII). These fields will be used as the
key field between the two files.
SET SAFETY OFF
The Join command requires that both files to be joined be sorted on the key field, as
completed below:
OPEN PAYROLL_FILE
SORT ON Check_Number to SORTED
OPEN GENERAL_LEDGER
OPEN SORTED SECONDARY
To join the GENERAL_LEDGER and PAYROLL_FILE files. See the Helpful Hints
section below for steps to complete using the resulting file:
JOIN PKEY Misc_Field FIELDS Trans_Amount GL_Account

Misc_Field SKEY Check_Number WITH Check_Number
Check_Date Employee_Number Department_Code
Employee_Name Weekly_Grs_Pay Weekly_Net_Pay TO “JOINED
GL PAY” PRESORT
CLOSE SECONDARY
OPEN JOINED_GL_PAY
DEFINE REPORT DEFAULT_VIEW

SET SAFETY ON
Helpful Hints
Extractions and summarizations which originally could only be performed on a few

fields in the GENERAL_LEDGER file can now be completed on the multitude of
available fields. With payroll as an example, this file could assist an accountant’s
research when asked the question, “What hit my department’s expense account in
June?” Further, to understand where employees charge expenses, an auditor could
Summarize the file on GL_Account and Employee_Name and then Sort on
Employee_Name.
Using this newly sorted file, the auditor may detect unusual classifications for the
same employee warranting further examination of supporting documentation and
discussion with management.

List all journal entries that do not net to Application 6
zero Batch: GENLED_6
Novice
Overview
This is an accounting “no no” and is easy to test, assuming that the required data
fields are present.
The following fields, currently in the GENERAL_LEDGER file as included with this
Toolkit, are required to execute the GENLED_6 batch:
Required
<Journal_Entry>
<Trans_Amount>
batch.

Batch
SET SAFETY OFF

OPEN GENERAL_LEDGER
To classify on journal entry number the net amount of the entry (which should net
to zero).
CLASSIFY ON Journal_Entry ACCUMULATE Trans_Amount TO

CLASSIFIED
OPEN CLASSIFIED
To extract all entries not netting to zero (see the Audit Steps section below for
procedures to perform using the resulting file):
EXTRACT RECORD IF Trans_Amount<>0 TO JE_NO_ZERO

OPEN JE_NO_ZERO
SET SAFETY ON
Audit Steps
Review the materiality of journal entries that do not net to zero (see
JE_NO_ZERO). If determined to be material, an extraction of those journal entries
based on the JE_Number field would be warranted. This could lead to an inquiry
by management and/or a recalculation of the entry based on supporting
documentation.
Material or immaterial, occurrences of this nature should be detected by a system

control in the accounting package (which does not allow the posting of entries

netting to more than zero). By default, this control is tested through the use of this
batch.

Notes

Select journal entry compliance samples Application 7
based on various factors Batch: GENLED_7
Intermediate
Overview
To extract a journal entry sample for compliance testwork normally requires

obtaining a general ledger, manually selecting items based on judgment and then
documenting the actual selection. With ACL, this antiquated exercise becomes
obsolete with the only requirements being the receipt of the general ledger data file,
the following batch statements and about one minute of auditor time.
Although it is possible to select a random sample from the entire general ledger file
(see the first selection in the batch below), it may be more effective to make
selections based on the approval limits associated with each entry (which can also be
accomplished using this batch). Classifying samples in this way leads to a more
focused audit analysis and clearer recommendations to management.
The following files and fields are required depending on whether approval limits are
used as a selection criteria:

For samples with approval limits as a selection factor use FLAT_JOURNALS as
created in Application 2 for the General Ledger.
Required
<Journal_Entry>
<Trans_Amt_Tot_Dr> (This field is created by following the
instructions in the Audit Steps section of
Application_2 for the General Ledger.)
For samples without approval limits use GENERAL_LEDGER
Required
<Journal_Entry>
<Trans_Amount>
batch.
Batch
Please note, samples based on approval limits will not process without establishing
the field Trans_Amt_Tot_Dr in the file FLAT_JOURNALS as explained in the
Audit Steps section of Application 2 in this chapter.
SET SAFETY OFF

DELETE ALL OK
ACCEPT “How many simple random items do you wish to sample?
Only answer if you wish to select a random sample,
otherwise respond with a 0:” TO ITEMS

ACCEPT “What is the approval limit to test? Only answer if
you wish to select a sample based on approval limits,
otherwise respond with a 0:” TO LIMIT
ACCEPT “How many over approval limit items do you wish to
sample? Only answer if you wish to select a sample based
on approval limits, otherwise respond with a 0:” TO
ITEMSOVR
ACCEPT “How many under approval limit items do you wish to
sample? Only answer if you wish to select a sample based
on approval limits, otherwise respond with a 0:” TO
ITEMSUND
The above statements will prompt you to enter the number of sample items you wish
to select and answer some questions regarding the approval limits. Based on the
entries, the following “DO BATCH” commands will be executed. Also, certain
“PAUSE” statements have been added if (1) no items meet your criteria, (2) you do
not select any items to sample or (3) you select more sample items than there are
items meeting the criteria in the file. For example, if there are 0 over limit items in a
file or you wish to sample 25 over limit items when there are only 15 in the file, the
particular batch will not execute and the PAUSE statement will appear notifying you
of such occurrence. Select “OK” to continue batch processing.
OPEN GENERAL_LEDGER
CLASSIFY ON Journal_Entry ACCUMULATE Trans_Amount TO
CLASSIFIED
OPEN CLASSIFIED
To select a simple random sample of journal entries (see the GL_SAMPLE batch
below for further processing):
COUNT
DO GL_SAMPLE IF VALUE(ITEMS,0)>0 AND
COUNT1>=VALUE(ITEMS,0)
PAUSE ‘The basic random sample did not process since
either there are no records in the file or the number
sampled>number of records in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMS,0)

PAUSE ‘The basic random sample did not process since there
were no selected items.’ IF VALUE(ITEMS,0)=0
To select a sample of journal entries over the user defined approval (see the
OVR_GLSAMP batch below for further processing):
OPEN FLAT_JOURNALS
COUNT IF Trans_Amt_Tot_Dr>VALUE(LIMIT,0)
DO OVR_GLSAMP IF VALUE(ITEMSOVR,0)>0 AND COUNT1>
=VALUE(ITEMSOVR,0)
PAUSE ‘The sample for over limit items did not process
since either there are no over limits or the number over
limits sampled>number in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMSOVR,0)
PAUSE ‘The sample for over limit items sample did not
process since there were no selected items.’ IF
VALUE(ITEMSOVR,0)=0
To select a sample of journal entries under the user defined approval (see the
UND_GLSAMP batch below for further processing):
COUNT IF Trans_Amt_Tot_Dr<VALUE(LIMIT,0)
DO UND_GLSAMP IF VALUE(ITEMSUND,0)>0 AND COUNT1>
=VALUE(ITEMSUND,0)
PAUSE ‘The sample for under limit items did not process
since either there are no under limits or the number
under limits sampled>number in the file.’ IF COUNT1=0
OR COUNT1<VALUE(ITEMSUND,0)
PAUSE ‘The sample for under limit items sample did not
process since there were no selected items.’ IF
VALUE(ITEMSUND,0)=0
DELETE ALL OK
SET SAFETY ON
The actual sample batches are as follows. These batches were “triggered” by the “DO
BATCH” command for each type of sample selected. Samples are random which is

preferred for compliance testwork because each record has an equal opportunity to
be selected. The first command will select a random seed (initial value for the
random number generator) for the sample which is followed by the actual sample
command.
GL_SAMPLE
COMMENT “THIS BATCH IS REFERENCED BY BATCH GENLED_7 - SEE

APPLICATION 7 IN CHAPTER 4 FOR A FURTHER DISCUSSION”
X=RAND(COUNT1)
To select a random sample (see the Audit Steps section below for procedures to
perform using the resulting file):
SAMPLE ON RECORD RANDOM X NUMBER ITEMS RECORD TO “SAMPJE”
OVR_GLSAMP

X=RAND(COUNT1)
To select a sample of journal entries with values over the approval limit (see the Audit
Steps section below for procedures to perform using the resulting file):
SAMPLE ON RECORD RANDOM X NUMBER ITEMSOVR POPULATION

COUNT1 RECORD TO “SAMOVRJE” IF
Trans_Amt_Tot_Dr>VALUE(LIMIT,0)
UND_GLSAMP

X=RAND(COUNT1)
To select a sample of journal entries falling under the approval limit (see the Audit

SAMPLE ON RECORD RANDOM X NUMBER ITEMSUND POPULATION
COUNT1 RECORD TO “SAMUNDJE” IF
Trans_Amt_Tot_Dr<VALUE(LIMIT,0)
The batches produce the following files:
SAMPJE Simple random sample of journal entries.
SAMOVEJE Sample of journal entries over the approval limit.
SAMUNDJE Sample of journal entries under the approval limit.
Audit Steps
For the sample selected, observe the actual journal entries to:
■ verify proper approval by supervisory personnel.

■ determine that the description of the journal entry is reasonable based on
the account coding/classification.
■ agree the associated account codings and amounts.
■ determine whether supporting documentation is adequate.
■ recalculate wherever applicable.
Please note: When auditing with this approach, the accuracy of the general
ledger is tested more so than the completeness. That is, data already in the system is
traced back to the appropriate support. To further test completeness, judgmentally
select a sample of journal entries from the appropriate files and perform all related
testwork described in the bullets above. This information will be traced to rather
than from the general ledger.

Helpful Hints
It may be more useful to export the resulting information to a spreadsheet

(exporting is done by selecting “Data” from the menu bar and choosing
“Export”) where columns have already been established for the audit steps to
perform. As each step is completed, an ‘X’ can be placed in the column with any
comments typed in the adjacent columns. This approach leads to the
standardization of testwork, cleaner workpapers and a saved tree.

Notes

Review the sequence of journal entry Application 8
numbers for gaps Batch: GENLED_8
Novice
See Chapter 5 (Purchasing Function and Accounts Payable Management), Application

7 (Sequence gaps in invoice batches, purchase orders and check numbers) for
discussion regarding Overview and Audit Steps.
The following field, currently in the GENERAL_LEDGER as included with this

Toolkit, is required to execute the GENLED_8 batch:
Required
<Journal Entry>
batch.
Batch
SET SAFETY OFF

OPEN GENERAL_LEDGER
To sequence the gaps in the journal entry numbers (see the Audit Steps section below
for procedures to perform using the resulting report):
GAPS ON Journal_Entry ERRORLIMIT 10 TO SCREEN PRESORT

SET SAFETY ON

Notes

Notes

Purchasing and Accounts Payable
Management Chapter 5
Cost cutting and restructuring efforts are nothing new to today’s auditor. The costs
of providing a product or service are as important to the organization as increased
market share. Companies are partnering with vendors, increasing their usage of
preferred supply contracts and utilizing procurement credit cards, all in an effort to
reduce the administrative expenses related to the procurement of goods and to
effectuate improved vendor terms.
The objective of this chapter is not only to provide the financial auditor with the
tools to test the proper and complete recording of liabilities, but also to assess the
effectiveness of the procurement system. The data analysis that follows will provide
the auditor with quantitative evidence that, used properly, will lead to increased
value to the organization.
Purchasing and Accounts Payable Objectives

The following is a list of specific audit objectives for the purchasing and accounts
payable function along with the applicable report numbers. The auditor should
attempt to obtain reasonable assurance that the following objectives have been
achieved by the organization:
Purchasing and Accounts Payable Activities are Operating

Effectively and Efficiently
Report numbers: 1, 4, 5, 6, 9, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21
Purchase Orders are Properly Authorized, Accurate and Complete

Report numbers: 1, 4, 5, 6, 7, 8, 9
Receipts are Accurate and Complete
Report number: 6, 9
Expenses are Properly Authorized, Accurate and Complete
Report numbers: 1, 2, 3, 5, 6, 7, 9, 10, 15, 16, 17, 18, 20, 21
Check Processing is Safeguarded, Accurate and Complete
Report numbers: 1, 2, 3, 6, 7, 9, 15, 16, 17, 20, 21
Purchasing and Accounts Payable Applications
Below are 21 applications which contain 30 reports. The number of reports per
application is shown after each application, along with the difficulty level.
1 Stratify vendor balances, check amounts, invoice amounts, purchase order

amounts, approval limits and check dates for unusual trends and
exceptions. (6) Novice
2 List vendors with post office boxes for identification of possible fictitious
vendors. (1) Intermediate
3 Match the payroll file to vendor file for identification of possible

unauthorized vendors. (1) Advanced
4 Calculate the annualized unit price changes in purchase orders for the same
product in the same year. (1) Intermediate
5 Calculate the variance between the approved purchase order and the invoice
cost. (1) Intermediate
6 Select expenditure compliance samples under numerous situations.

(1) Intermediate
7 Review the sequence of invoices, purchase orders and check numbers for
gaps. (3) Novice

8 Analyze purchase orders based upon their issuers and/or approvers.
(1) Novice
9 Extract large invoice payments excluding any intercompany transactions.

(1) Intermediate
10 Select a Monetary Unit Sample of vendor invoices and automatically create

confirmation requests (no typing necessary). (1) Intermediate
11 Calculate weighted days payable outstanding and interest lost for not paying
in 30, 45 and 60 days. (1) Advanced
12 Detect vendors with no discounts taken when discounts have been taken in
the past. (1) Intermediate
13 Calculate interest lost for paying invoices prior to their due dates.
(1) Intermediate
14 Identify vendors with numerous checks who could potentially be paid on a

monthly basis. (1) Intermediate
15 List possible duplicate payments based on invoice number, vendor name

and the absolute value of the check amount. (1) Novice
16 List possible duplicate payments based on invoice date, vendor name and
the absolute value of the check amount. (1) Novice
17 List possible duplicate payments based on invoice date, invoice number and
the absolute value of the check amount. (1) Novice
18 Extract check payments for unrecorded liability testwork. (1) Intermediate
19 Consolidate vendor activity to assess organizational purchasing power.

(1) Intermediate
20 Summarize debit memos on vendor, issuer, and type for exceptions and
unusual trends. (3) Novice
21 Identify all vendors with debit balances. (1) Novice

Purchasing and Accounts Payable Data Files
(PAID_FILE) - This file consists of one year of invoices (1/1/96 to 12/31/96) and
their associated payments used to process most accounts payable applications. Each
record is uniquely defined by an invoice number. Please note the Check_Amount
field is the invoice amount which, when paid, has a Check_Date that is not equal
to zero (“000101”). Below is the data structure which is followed by a field
explanation list:
Data Structure
729 Records using PAIDFILE.FIL as the data file with
activity from 1/1/96 to 12/31/96

explanation
Check_Number ASCII 1 4
Debit_Memo_Code ASCII 5 2
Check_Amout NUMERIC 7 8 2 PICTURE
“(9,999,999.99)”
Discount NUMERIC 15 7 2 PICTURE
“(9,999,999.99)”
Entered_Date DATE 22 6 PICTURE “yymmdd”

Enterer_Init ASCII 28 2
Expected_Pay_Date DATE 30 6 PICTURE “yymmdd”
AS “Expected Pay
Date” WIDTH 6
Invoice_Batch ASCII 36 3
Invoice_Date DATE 39 6 PICTURE
“yymmdd”WIDTH 6
Invoice_Number ASCII 45 6 AS “Invoice
Number”
Man_Chk_Ind ASCII 51 1
Payment_Terms NUMERIC 52 2 0
PO_Approver ASCII 54 10
PO_Issuer ASCII 64 10
PO_Number ASCII 74 5
Vendor_Address ASCII 79 20 AS “Vendor
Address”
Vendor_City ASCII 99 11 AS “Vendor City”
Vendor_Name ASCII 110 26
Vendor_Number ASCII 136 7
Vendor_State ASCII 143 2
Vendor_Zip ASCII 145 5
Check_Date DATE 150 8 PICTURE
“YYYYMMDD”
Check_Amount The amount of the invoice and, if there is a

Check_Date greater than zero, the field also
represents the check payment amount.
Check_Date The date of the check payment.
Check_Number The check number.
Debit_Memo_Code A code to designate the reason for a debit memo.
Discount The financial discount taken at the time of check

payment.

Entered_Date The date the invoice was entered into the system.
Enterer_Init The initials of the employee entering the invoice.
Expected_Pay_Date The expected date to pay the invoice.
Invoice_Batch The invoice batch.
Invoice_Date The date of the invoice.
Invoice_Number The invoice number.
Man_Chk_Id Indicates whether a manual check was issued.
Payment_Terms The negotiated payment terms with the vendor.
PO_Approver Signifies the approver of the purchase order.
PO_Issuer Signifies the issuer of the purchase order.
PO_Num The purchase order number.
Vendor_Address The vendor’s street address.
Vendor_City The vendor’s city.
Vendor_Name The name of the vendor.
Vendor_Number The vendor number.
Vendor_State The vendor’s state.
Vendor_Zip The vendor’s zip code.

(PURCHASE_FILE) - This file consists of one year of purchase orders (1/1/96 to
12/25/96) used in the processing of accounts payable applications (see Chapter 5).
Below is the data structure which is followed by a field explanation list:
Data Structure
354 Records using PO_FILE.FIL as the data file.

explanation
PO_Total_Amt NUMERIC 1 9 2
PO_Date DATE 10 6 PICTURE “yymmdd”
PO_Approver ASCII 16 10
PO_Issuer ASCII 26 10
PO_Number ASCII 36 5
PO_Tot_Amt The amount of the purchase order.
PO_Date The date of the purchase order.
PO_Approver Signifies the approver of the purchase order.
PO_Issuer Signifies the issuer of the purchase order.

PO_Number The purchase order number.
Vendor_Number The vendor number.
Purchasing and Accounts Payable Verification Batch

AP_VERIFY
Executed prior to using the PAID_FILE to:
1 Execute the Verify command on each data field - Review the

“Command and Log” in ACL after batch processing to ensure that the
command yielded the response “0 data validity errors detected”. Please note
the batch will terminate processing at this point, with an appropriate user
dialog box, if the data has any invalid fields.
2 Classify information by invoice batch - Using the BATCH, select a

judgmental sample of invoice batch amounts and match to supporting
information. The purpose of this test is to ensure, on a small level, that the
basic dollar amounts used are accurate and complete.
3 Stratify all paid invoice activity for the period on invoice amount and
check date - These reports could be reviewed with management for their
reasonableness. Care should be taken with regard to large negative or
positive transactions that may need specific identification and review.
4 Sequence on invoice batch - Review the printed report to determine if the

number of gaps signals an incomplete data extraction. It may be useful to
discuss with management the starting and ending invoice batch numbers
for the period to be matched to the extraction.
batches, double-clicking on the AP_VERIFY batch, and then clicking “Run” in the
parameter is required to allow the AGE command to stratify on the Check_Date.

If using the sample data provided with the Toolkit, enter the date 12/31/96 in
YYYYMMDD format (i.e. 19961231).
SET SAFETY OFF

DELETE ALL OK
OPEN PAID_FILE
ACCEPT “Enter the aging date in yyyymmdd order:” to
AGE_DATE
Please note: The Check_Date field has not been verified considering it has
dates of “19000101”. These dates are properly not considered valid by ACL although
they do serve a purpose, designating those invoices not paid as of the date of the file.
VERIFY FIELDS Check_Amount Check_Number Debit_Memo_Code

Discount Entered_Date Enterer_Init Expected_Pay_Date
Invoice_Batch Invoice_Date Invoice_Number Man_Chk_Ind
Payment_Terms PO_Approver PO_Issuer PO_Number
Vendor_Address Vendor_City Vendor_Name Vendor_Number
Vendor_State Vendor_Zip ERRORLIMIT 10
The batch will terminate if there are any invalid fields detected using the Verify
command. If the data is valid, processing will continue with AP_VERIFY which is
listed below.
DO AP_VERIFY1 IF WRITE1=0
DELETE ALL OK
SET SAFETY ON
AP_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCH AP_VERIFY

- SEE CHAPTER 3 RELATIVE TO VERIFICATION BATCHES FOR A
FURTHER DISCUSSION”
To stratify paid invoices on check amount:

STRATIFY ON Check_Amount ACCUMULATE Check_Amount MINIMUM -
1000000 MAXIMUM 1000000 FREE -1000000,-100000,-10000,-
1000,-100,-1,0,1,100,1000,10000,100000,1000000
header=‘Stratification on Check Amount’ TO SCREEN IF
Check_Date<>‘19000101’
To stratify paid invoices on check date:
AGE ON Check_Date CUTOFF Age_Date INTERVAL 0, 30, 60, 90,

120, 150, 180, 210, 270, 300, 330, 360 ACCUMULATE
Check_Amount TO SCREEN IF Check_Date <> ‘19000101’
HEADER=”Aging on Check_Date”
To sequence gaps in invoice batch sequence:
CLASSIFY ON Invoice_Batch ACCUMULATE Check_Amount TO

“INVB”
OPEN INVB
SEQUENCE ON Invoice_Batch GAPS ERRORLIMIT 10 to SCREEN
SET SAFETY ON
PURCHASE_VERIFY
To be executed prior to using the PURCHASE_FILE which will:

“Command and Log” in ACL after batch processing to ensure that the
command yielded the response “0 data validity errors detected”. Please note
SET SAFETY OFF

DELETE ALL OK
OPEN PURCHASE_FILE
VERIFY FIELDS PO_Approver PO_Date PO_Issuer PO_Number
PO_Total_Amt Vendor_Number ERRORLIMIT 10

command.

SET SAFETY ON

Notes

Stratify vendor balances, check amounts, Application 1
invoice amounts, purchase order amounts, Batch: ACCPAY_1
approval limits and check dates for unusual Novice
trends and exceptions
Overview
■ Do you want a “big picture” expenditure analysis?

■ Need to focus limited audit time on a seemingly unlimited volume of
purchases?
Then look no further than the following batch. With it, audit tests can be tailored to
single large payments, accumulated payments to vendors, varying approvals or
check timing. Percentage coverage was never so easy to calculate. Further, payment
patterns can be scrutinized to assess any potential administrative burden.
Purchasing and Accounts Payable Activities are Operating Effectively and

Efficiently

The following fields, currently in the PAID_FILE as included with this Toolkit, are
required to execute the following batch. Since the PAID_FILE is made of invoice
records, the Check_Amount field is actually the amount paid for that particular
invoice when the Check_Date is not equal to zero or “000101”. If equal to zero,
the Check_Amount field represents an open invoice amount.
Required
<Check_Amount>
<Check_Number>
<Check_Date>
<PO_Number>
<Vendor_Name>
To test the validity of the data used in this application, execute the AP_VERIFY
batch. Please note the second stratification in this batch (on check amount) provides
such a wide-angle focus of the activity; it was used in the AP_VERIFY batch as
further explained in Chapter 3.
Batch
batches, double-clicking on the ACCPAY_1 batch, and then clicking “Run” in the
When running this batch you will be prompted to enter the aging date (i.e. the date
of the last payment in the file). This parameter is required to allow the AGE
command to age on Check_Date. If using the sample data provided with the
Toolkit, enter the date 12/31/96 in YYYYMMDD format (i.e. 19961231).
SET SAFETY OFF

Please note: The upper limit check amount was set to $5,000,000. If your
organization issues checks of a larger amount, change this limit prior to batch
execution. Also, the approval strata, shown as an “X” in the following command,
must be edited prior to execution (Select “Batches” from the “Edit” menu item
to edit this strata).
PAUSE ‘Please be sure that you have entered the X value in

the stratification on approval limits prior to
executing the batch’
ACCEPT “Enter the aging date in yyyymmdd order:” to
AGE_DATE
To stratify on accumulated vendor payments (see the Audit Steps section below for
procedures to perform using the resulting report):
OPEN PAID_FILE
CLASSIFY ON Vendor_Name ACCUMULATE Check_Amount TO VENDORS
IF Check_Date<>‘19000101’
OPEN VENDORS
STRATIFY ON Check_Amount ACCUMULATE Check_Amount TO SCREEN
free 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 header=‘Stratify on Vendor_Balance’

The batch will print each of the stratifications. If you prefer to view this information
in your favorite spreadsheet or word processing application, open it as a text file in
the preferred application.
To stratify on check payments (see the Audit Steps section below for procedures to
OPEN PAID_FILE
CLASSIFY ON Check_Number ACCUMULATE Check_Amount TO CHECKS
OPEN CHECKS
free 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 header=‘Stratify on Check Balance’
To stratify on invoice payment (see the Audit Steps section below for procedures to
OPEN PAID_FILE
free 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 header=‘Stratify on Invoice Amount’ IF
To stratify on purchase order payments (see the Audit Steps section below for
OPEN PAID_FILE
CLASSIFY ON PO_Number ACCUMULATE Check_Amount TO PO IF
OPEN PO
free 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 header=’Stratify on Purchase Order Amount’
To stratify on approval limits (see the Audit Steps section below for procedures to

Please note: The upper limit check amount was set to $5,000,000. If your
organization issues checks of a larger amount, change this limit prior to batch
execution. Also, the approval strata, shown as an “X” in the following command,
must be edited prior to execution (Select “Batches” from the “Edit” menu item
to edit this strata).
OPEN Paid_File
Stratify ON Check_Amount ACCUMULATE Check_Amount TO SCREEN
free 0, X,5000000 header=’Stratify on Approval Limit’
To stratify on check date (see the Audit Steps section below for procedures to

120, 150, 180, 210, 270, 300, 330, 360 ACCUMULATE
Check_Amount TO SCREEN IF Check_Date <> ‘19000101’
HEADER=”Aging on Check_Date”
SET SAFETY ON
Audit Steps
Review on vendor amount for:
■ unreasonably large balances where activity could be extracted and further

reviewed
■ material vendors to request their corresponding competitive bids
■ a high number of vendors with low accumulated activity for possible
consolidation
■ debit balances (see related testwork in Applications 21 and 22 in this
chapter).
Review on check/invoice amount for:
■ unreasonably large amounts which could be extracted and further reviewed

■ negative amounts which should only represent voided transactions and
debit memos
■ a large volume of small checks/invoices that may be reduced by monthly
vendor billings or the use of a procurement credit card system available
through various financial institutions. Under such a system, credit cards,
useable in certain transactions based on the approved Standard Industry
Codes (“SIC”), would be used to initiate purchases with vendors. Payment
would be made on a monthly basis to the credit card vendor with approval
of the vendors’ invoice and/or credit card statements.
Review on purchase order amount for:
■ unreasonably large amounts which could be extracted and further reviewed

for proper approval and associated competitive bids
■ a high volume of low dollar purchase orders. It has been estimated in
various corporate surveys that each purchase order costs between $50 and
$125 dollars to issue. To limit this expense, perhaps the dollar limit, under
which purchase orders would not be necessary, could be raised. Those
purchases falling under the limit could be approved directly on the invoice
after receipt of the goods/services. Another approach would be the
utilization of a procurement credit card system as explained in the previous
section.
Review on approval limit for:
■ assessing whether such limits are effective. If the majority of payments fall
below established approval limits, a judgment should be made as to whether
the limit should be lowered in response. Such activity may also signal a
bypass of controls (i.e. - management intentionally requests invoices below
the limit that relinquishes the need for approval)
■ planning for compliance sampling on such limits as performed in
Application 6 in this chapter.
Review on check date for:
■ perceiving the organization’s cash requirement needs throughout the year

■ tailoring audit testwork to more active payment periods.

Helpful Hints
explained in Helpful Hints section of Chapter 3, to select an appropriate
period for review.
■ For continuous auditing purposes or as a managerial tool, the stratification
of each check run’s data prior to payment may detect potential errors or
irregularities.
■ Use the stratification percentages as a guide to accurately communicate the
coverages obtained in audit tests. For example, “95% of invoices greater
than $50,000, representing 62% of the total dollar expenditures during
1995, were found to be properly approved”.

Notes

List vendors with post office boxes for Application 2
identification of possible fictitious vendors Batch: ACCPAY_2
Intermediate
Overview
The theory behind this application is that an unauthorized employee, wishing to

obtain fraudulent payments, could establish a post office box address to minimize
the risk of detection. Although this test may detect fraudulent activity, many valid
companies utilize these boxes especially with the advent of lockbox accounts as
provided by financial institutions.
required to execute the following batch:
Required
<Check_Amount>
<Vendor_Name>
<Vendor_Address>

batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
In the command shown below, note that use of the FIND() function with “BOX”
will return a match regardless of the case since this function is not case sensitive. It is
possible that the use of “BOX” will extract more items than necessary (i.e. - The
Boxer Association), but it is best to be less rather than more specific in these searches
to ensure the completeness of processing.
To create a summarized file on the vendor name (see the Audit Steps section below
for procedures to perform using the resulting file):
SORT ON Vendor_Name to SORTED IF

FIND(‘BOX’,Vendor+Address) PRESORT
OPEN SORTED
SUMMARIZE ON Vendor_Name ACCUMULATE Check_Amount OTHER
Vendor_Address TO PO_VENDORS
OPEN PO_VENDORS
SET SAFETY ON

Audit Steps
Using POBOX or PO_VENDORS, review the vendor files to ensure that all payments
were made for properly approved and valid expenses of the organization. The
preferred filing system with this test is a sort by vendor name. If this is not the case,
open POBOX and sort on whichever field is most appropriate to the filing system
encountered (i.e. - by invoice batch, invoice number, etc.)
Since this exercise may detect fraud, it may be beneficial to locate the invoices or
vendor files independent of the accounts payable department to prevent any
forewarning of the ensuing testwork.

Notes

Match payroll file to vendor file for Application 3
identification of possible unauthorized Batch: ACCPAY_3
vendors Advanced
Overview
There is no more classic fraud detection technique than the matching of the vendor
file to the payroll masterfile. The match may detect a fraud scheme to update the
vendor masterfile with the name of an employee and process unapproved payments
through the improper account
The following fields, currently in the files PAID_FILE and PAYROLL_FILE as

included with this Toolkit, are required to execute the following batch:
PAID_FILE
Required Useful
<Check_Amount> <Check_Date>
<Vendor_Name> <Invoice_Number>
<Invoice_Batch>

<Vendor_Number>
PAYROLL_FILE
Required
<Employee_Last_Name>
<Weekly_Net_Pay>
To test the validity of the data used in this application, execute the AP_VERIFY and
PAYROLL_VERIFY batches.
Batch
SET SAFETY OFF

OPEN PAYROLL_FILE
CLASSIFY ON Employee_Last_Name ACCUMULATE Weekly_Net_Pay
TO CLASSIFIED
OPEN CLASSIFIED
The following “LIST” command will create a text copy of the line shown below with
the Employee_Last_Name field replaced with the actual employee names. A
new text line will be created for each employee in the PAYROLL_FILE. See the
subsequent note below for how to complete batch processing with these lines of text.
LIST “EXTRACT Check_Amount Vendor_Name Invoice_Number

Invoice_Date Invoice_Batch Vendor_Number Check_Date TO
ACCPAY3.FIL IF
FIND(TRIM(Employee_Last_Name),Vendor_Name)
UNFORMATTED
SET SAFETY ON

At this point, a text file named ACCPAY3.BAT exists in your working directory.
Open it in your favorite word processor to see a listing of Extract commands, one
for each employee per the PAYROLL_FILE file. Copy its contents to a new batch
named “ACCPAY_3_Results” as completed below. Essentially, one large “IF”
statement is created rather than having numerous “Extract” commands to
minimize processing time.
Also, be sure, at a minimum, to type the SET SAFETY OFF, USE PAID_FILE
and SET SAFETY ON commands prior to execution. To execute this new batch,
select “Tools” from the menu bar, choose “Do Batch” and double click on
“ACCPAY_3_RESULTS”.
SET SAFETY OFF

OPEN PAID_FILE
EXTRACT Check_Amount Vendor_Name Invoice_Number
Invoice_Date Invoice_Batch Vendor_Number Check_Date
TO ACCPAY3.LOG IF FIND('COX',Vendor_Name)
TO ACCPAY3.LOG IF FIND('DOWNES',Vendor_Name)
TO ACCPAY3.LOG IF FIND('DUNAWAY',Vendor_Name)
TO ACCPAY3.LOG IF FIND('FRIEDMAN',Vendor_Name)
TO ACCPAY3.LOG IF FIND('JACOBS',Vendor_Name)
TO ACCPAY3.LOG IF FIND('JONES',Vendor_Name)
TO ACCPAY3.LOG IF FIND('KELLER',Vendor_Name)

TO ACCPAY3.LOG IF FIND('LIPTON',Vendor_Name)
TO ACCPAY3.LOG IF FIND('MANNING',Vendor_Name)
TO ACCPAY3.LOG IF FIND('MOULDEN',Vendor_Name)
TO ACCPAY3.LOG IF FIND('RATCLIFF',Vendor_Name)
TO ACCPAY3.LOG IF FIND('ROCKLIN',Vendor_Name)
TO ACCPAY3.LOG IF FIND('SIMMS',Vendor_Name)
TO ACCPAY3.LOG IF FIND('SMITH',Vendor_Name)
TO ACCPAY3.LOG IF FIND('TAYLOR',Vendor_Name)
OPEN ACCPAY3

SET SAFETY ON
Audit Steps
Using ACCPAY3.LOG, review the vendor files to ensure that all payments were
made for properly approved and valid expenses of the organization.
Since this exercise may detect fraud, it may be beneficial to locate the invoices or
vendor files independent of the accounts payable department to prevent any
forewarning regarding the ensuing testwork.
Helpful Hints
It is common for employees to be listed as vendors in the accounts payable file to

process payments for travel and entertainment expenses or employee advances.
These payments should not be construed as fraudulent assuming they have been
properly approved and relate to the ongoing function of the organization.

Notes

Calculate the annualized unit price Application 4
changes in purchase orders for the same Batch: ACCPAY_4
product in the same year Intermediate
Calculate the variance between the Application 5

approved purchase order and the invoice Batch: ACCPAY_5
cost Intermediate
Overview - This Overview is applicable to Applications 4 & 5
Understanding the nature and extent of price increases during the year can be of
interest to purchasing managers and auditors alike. Although in dollar terms a price
change within the year may go unnoticed, such a change, when viewed in annualized
percentage terms, could demand increased attention.
Not only are price changes an issue for review but they can lead to processing
inefficiencies within the purchasing function. In line with the saying, “Do it right the
first time,” purchase orders should guide the payment process. For example, in
many accounts payable systems, material dollar changes between the purchase order
and invoice price must be approved by a party independent of the accounts payable
function (usually the purchasing manager) prior to payment. Thus, in this
purchasing environment:
1 The purchasing manager creates a purchase order by contacting the vendor

and establishing all necessary terms.
2 The accounts payable accountant verifies the accuracy of this document to

the invoice, noting any discrepancies.
3 The discrepancies are then approved, in a second handling process, by the

purchasing manager.

In Controlling Vendor Transactions, by Kenneth Clark, this process was deemed
inefficient and avoidable if the accounts payable accountant could place confidence
in the purchase order’s accuracy, basing payment solely on this document.
“Presumably, the vendor reads the purchase orders prior to making shipments.
Thus, any shipments and invoicing that are contradictory to terms and conditions
provided on the orders must, consequentially, be due to some error on the part of the
vendor’s personnel or system.” What results is:
■ saved time through the approval of purchase terms once, assumedly by the
purchasing manager, when the purchase order is created
■ payment based on the lower of the purchase order or invoice price
■ less administrative burden of invoice reconciliation which is appropriately
placed on the vendor.
Audit Objectives Tested - Application 4

Efficiently
Audit Objectives Tested - Application 5

Efficiently

Data Fields and Validity Tests - Application 4
The following fields, currently in the INVENTORY_FILE as included with this

Toolkit, are required and/or useful to execute the ACCPAY_4 batch.
Required Useful
<Inventory_Number> <Vendor_Name>or<Vendor_Number>
<PO_Date_1>
<PO_Price_1>
<PO_Number_1>
<PO_Date_2>
<PO_Price_2>
<PO_Number_2>
To test the validity of the data used in this application, execute the
INVENTORY_VERIFY batch.
required and/or useful to execute the ACCPAY_5 batch:
Required Useful
<Invoice_Number>
<Vendor_Number>or<Vendor_Name>
<Inv_Batch>
<Inv_Date>
<PO_Date>

The following fields, currently in the PURCHASE_FILE as included with this
Toolkit, are also required:
Required
<PO_Total_Amount>
<PO_Number>
To test the validity of the data used in this application, execute the AP_VERIFY and
PO_VERIFY batches.
Batch - Application 4
resulting Message box. When running the batch you will be prompted to enter the
aging date (i.e. date of the last payment in the file). This parameter is required to
allow the AGE() function to work properly. If using the sample data provided with
the Toolkit, enter the date 12/31/96 in YYMMDD format (i.e. 961231).
SET SAFETY OFF

OPEN INVENTORY_FILE
ASSIGN AGEDATE=CTOD(AGE_DATE)
SET FILTER TO AGE(PO_1,AGEDATE)<365 AND
AGE(PO_Date_1,AGEDATE)>=0 AND
AGE(PO_Date_2,AGEDATE)<365 AND
AGE(PO_Date_2,AGEDATE)>=0
The above filter assumes there will be no more than one year reviewed. The analysis
could be reviewed for multiple years by changing the number of days above from 365
to the desired time period. Remember if this is completed to also change the number
365 in the “DEFINE FIELD” commands shown below to an equivalent number of
days.

The below field definition will “annualize” the change so, for example, if a $1.00
product price increased by $1.00 in 60 days, the annualized price change would be
roughly 300% using the calculation ((2-1/2)*(365/60)).
DEFINE FIELD PO_PRICE_CHG COMPUTED

((PO_Price_1-PO_Price_2)/PO_Price_2)*(365/(PO_Date_1-
PO_Date_2))
To sort the price changes in a descending fashion (see the Audit Steps section below
SORT ON PO_PRICE_CHG D TO POPRICE_DESCEND

OPEN POPRICE_DESCEND

SET SAFETY ON
SET SAFETY OFF

OPEN PAID_FILE
OPEN PURCHASE_FILE
SORT ON PO_Number TO SORTED1
SUMMARIZE ON PO_Number ACCUMULATE Check_Amount OTHER
Check_Date Invoice_Number Vendor_Name Invoice_Batch
Invoice_Date TO SUMMARIZED IF PO_Number <> “ “
PRESORT OPEN
OPEN SORTED1 SECONDARY
To join the purchase order original amount to that paid under the purchase order
(see the Audit Steps section below for procedures to perform using the resulting file):
JOIN PKEY PO_Number FIELDS PO_Number Check_Date

Check_Amount Invoice_Date Invoice_Number Vendor_Name
Invoice_Batch SKEY PO_Number WITH PO_Total_Amt PO_Date
PRIMARY TO “POINV”
CLOSE SECONDARY
OPEN POINV
DEFINE FIELD PO_INV_DIFF COMPUTED (Check_Amount-

PO_Total_Amt)
SET SAFETY ON

Audit Steps - These Audit Steps are applicable to Applications 4 & 5
These files (POPRICE_DESCEND and POINV) can be used for two purposes:
1 Determine whether the process is operating effectively and is cost

beneficial.
2 Test the established approval process.
1 Determine whether the process is operating effectively and is cost beneficial:

The auditor could stratify based on the appropriate difference field
(PO_PRICE_CHG for Application 4 and PO_INV_DIFF for Application 5) to
determine the relative size of each variance and the magnitude of variances. For an
example of testwork related to Application 5, assume the accounts payable
accountant is empowered to pay all invoices with a tolerance (difference between
invoice and purchase order price) under $10.00. Using the stratification, a review of
all variances greater than $10.00 would identify the number of approvals obtained or
time spent by the purchasing manager and accounts payable accountant. For
variances equal to or less than $10.00, the dollar value lost due to payment being
based on the invoice and not the purchase order price, is calculated.
Assuming an estimate in both time and routing costs for each over $10.00 approval
made, the total of these estimates could be used to support the empowerment of the
accounts payable accountant.
2 Test the established approval process: Using the stratifications explained above
will identify the variances’ size which can then be applied by either sorting the
differences in a descending fashion or simply extracting those variances deemed
appropriate. If there is no empowerment of the accounts payable function as
explained in Overview above, proper approval should be noted on each purchase
order/invoice showing a variance considered material by management. A useful
summarization on Vendor Name or Vendor Number can highlight those vendors
with a habit of changing prices.
The accuracy of purchase order prices can also be tested using the above reports by
reviewing unreasonable variances. It is common for prices to be entered incorrectly
in purchase orders. It is also common for a lower price to be entered in the approved
purchase order when the invoice price is much higher. This may detect inadequate
planning or an attempt to circumvent established controls. You may find it beneficial

to review certain unusual increases with a party independent of the purchasing
function to assess whether potential “kickback” situations exist. A kickback can
occur when prices higher than the normal market are approved by company
personnel with a covert agreement existing whereby these personnel expect to share
in the profits from approving the increased prices.

Select expenditure compliance samples Application 6
under numerous situations Batch: ACCPAY_6
Intermediate
Overview
To extract an expenditure sample for compliance testwork normally requires the

procurement of a printed check register, manual selection of items based on
judgment and then documentation of the actual selection. With ACL for Windows,
this antiquated exercise becomes obsolete. All that are required are the receipt of the
paid check data file, the following batch statements and about one minute of auditor
time.
Although it is possible to select a random sample from the entire paid file (see first
selection in batch), it may be more effective to make selections based on the
transaction type. For example, in a compliance sample of expenditures with
purchase orders, invoices would not have to be reviewed for their proper approval, as
the purchase order has eliminated the need. Classifying samples in this way leads to
a more focused audit analysis and clearer recommendations to management.

Efficiently

required and/or useful to execute the ACCPAY_6 batch. Please note it is assumed
that the check number and invoice number are the references used by the accounting
system to locate the invoice package. It may be necessary to include or substitute
additional fields such as the voucher number, invoice batch, etc., depending on the
payment references used by the accounting system:
Required Useful
<Check_Number> <Invoice_Date>
<Invoice_Number> <Invoice_Batch>
<PO_Number> <Vendor_Number>
<Manual_Chk_Ind> <Vendor_Name>
batch.
Batch
SET SAFETY OFF

DELETE ALL OK
ACCEPT “How many simple random items do you wish to sample?
Only answer if you wish to select this type of a sample,
otherwise respond with a 0:” TO ITEMS

ACCEPT “How many PO items do you wish to sample? Only
answer if you wish to select this type of a sample,
otherwise respond with a 0:” TO ITEMSPO
ACCEPT “How many Non PO items do you wish to sample? Only
otherwise respond with a 0:” TO ITEMSNOPO
ACCEPT “How many manual checks do you wish to sample? Only
otherwise respond with a 0:” TO ITEMSMAN
It may be effective to execute the approval limit stratification explained in

ACCPAY_1 to adequately prepare for the following queries.
ACCEPT “How many over approval limit items do you wish to

sample? Only answer if you wish to select this type of
a sample, otherwise respond with a 0:” TO ITEMSOVR
ACCEPT “How many under approval limit items do you wish to
sample? Only answer if you wish to select this type of
a sample, otherwise respond with a 0:” TO ITEMSUND
ACCEPT “What is the approval limit to test:” TO LIMIT
The above statements prompt you to enter the number of sample items you wish to
select. The first ACCEPT statement requests the number of items if a random sample
of the entire population, regardless of expenditure type, is being executed. If you do
not wish to select any sample items from a particular category (i.e. - manual checks,
Non PO items, etc.), enter 0 at the appropriate ACCEPT command. Based on the
entries, the below “DO BATCH” commands will be executed. Also, certain
“PAUSE” statements have been added if (1) no items meet your criteria (2) you enter
0 at any of the ACCEPT commands above or (3) you select more sample items than
there are items meeting the criteria in the file. For example, if there are 0 purchase
orders in a file or you wish to sample 25 purchase orders when there are only 15 in
the file, the particular batch will not execute and the PAUSE statement will appear
notifying you of such occurrence. In each of these instance, Select “OK” to further
commence batch processing.
OPEN PAID_FILE

The samples below are meant to be selected from valid paid invoices (invoices
possessing a check date) by means of the following command.
EXTRACT RECORD TO EXTRACTED IF Check_Date<>‘000101’

OPEN EXTRACTED
To select a simple random sample (see AP_SAMPLE batch for further processing):
COUNT
DO AP_SAMPLE IF VALUE(ITEMS,0)>0 AND COUNT1>VALUE(ITEMS,0)
To select a sample of purchase order invoices (see PO_SAMPLE batch for further
processing):
COUNT IF PO_Number<>‘ ’
DO PO_SAMPLE IF VALUE(ITEMSPO,0)>0 AND
COUNT1>VALUE(ITEMSPO,0)
PAUSE ‘The sample for purchase orders did not process
since either there are no POs or the number POs
sampled>number in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMSPO,0)
PAUSE ‘The sample for purchase orders did not process
since there were no selected items.’ IF
VALUE(ITEMSPO,0)=0
To select a sample of non-purchase-order invoices (see NOPO_SAMPLE batch for

further processing):
COUNT IF PO_Number=’ ‘
DO NOPO_SAMPLE IF VALUE(ITEMSNOPO,0)>0 AND
COUNT1>VALUE(ITEMSNOPO,0)

PAUSE ‘The sample for NO purchase orders did not process
since either there are only POs or the number of non POs
sampled>number in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMSNOPO,0)
PAUSE ‘The sample for NO purchase orders did not process
VALUE(ITEMSNOPO,0)=0
To select a sample of invoices paid by manual checks (see MAN_SAMPLE batch for
further processing):
COUNT IF UPPER(Man_Chk_Ind)=‘Y’
DO MAN_SAMPLE IF VALUE(ITEMSMAN,0)>0 AND
COUNT1>VALUE(ITEMSMAN,0)
PAUSE ‘The sample for manual checks did not process since
either there are no manual checks or the number of
manuals sampled>number in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMSMAN,0)
PAUSE ‘The sample for manual checks did not process since
there were no selected items.’ IF VALUE(ITEMSMAN,0)=0
To select a sample of invoices over the user defined approval limit (see
OVR_SAMPLE batch for further processing):
COUNT IF Check_Amount>VALUE(LIMIT,0)
DO OVR_SAMPLE IF VALUE(ITEMSOVR,0)>0 AND
COUNT1>VALUE(ITEMSOVR,0)
PAUSE ‘The sample for over limit checks did not process
since either there are no over limits or the number of
over limits sampled>number in the file.’ IF COUNT1=0 OR
COUNT1<VALUE(ITEMSOVR,0)
PAUSE ‘The sample for over limit checks did not process
VALUE(ITEMSOVR,0)=0
To select a sample of invoices under the user defined approval limit (see
UND_SAMPLE batch for further processing):

COUNT IF Check_Amount<VALUE(LIMIT,0)
DO UND_SAMPLE IF VALUE(ITEMSUND,0)>0 AND
COUNT1>VALUE(ITEMSUND,0)
PAUSE ‘The sample for under limit checks did not process
since either there are no under limits or the number of
under limits sampled>number in the file.’ IF COUNT1=0
OR COUNT1<VALUE(ITEMSOVR,0)
PAUSE ‘The sample for under limit checks did not process
VALUE(ITEMSUND,0)=0
DELETE ALL OK
SET SAFETY ON
The actual sample batches are as follows. These batches were “triggered” by the “DO
BATCH” command for each type of sample selected. Samples are random, meaning
that each record has an equal opportunity to be selected. This is preferred when
doing compliance testwork. The first command will select a random seed (initial
value for the random number generator) for the sample; the random seed is followed
by the actual sample command.
AP_SAMPLE
COMMENT “THIS BATCH IS REFERENCED BY BATCH ACCPAY_6 - SEE

X=RAND(COUNT1)
To select a simple random sample (see the Audit Steps section below for procedures
to perform using the resulting file):
SAMPLE ON RECORD RANDOM X NUMBER ITEMS Vendor_Number

Vendor_Name Invoice_Number Invoice_Date Invoice_Batch
PO_Number Man_Chk_Ind Check_Date Check_Number
Check_Amount TO “SAMP”
PO_SAMPLE


X=RAND(COUNT1)
To select a sample of purchase order invoices (see the Audit Steps section below for
SAMPLE ON RECORD RANDOM X NUMBER ITEMSPO POPULATION COUNT1

Vendor_Number Vendor_Name Invoice_Number Invoice_Date
Invoice_Batch PO_Number Man_Chk_Ind Check_Date
Check_Number Check_Amount TO “SAMPPO” IF PO_Number<>’
‘
NOPO_SAMPLE

X=RAND(COUNT1)
To select a sample of non purchase order invoices (see the Audit Steps section below
SAMPLE ON RECORD RANDOM X NUMBER ITEMSNOPO POPULATION

COUNT1 Vendor_Number Vendor_Name Invoice_Number
Invoice_Date Invoice_Batch PO_Number Man_Chk_Ind
Check_Date Check_Number Check_Amount TO “SAMPNOPO” IF
PO_Number=’ ‘
MAN_SAMPLE

X=RAND(COUNT1)
To select a sample of invoices paid by manual checks (see the Audit Steps section
below for procedures to perform using the resulting file):
SAMPLE ON RECORD RANDOM X NUMBER ITEMSMAN POPULATION

Check_Date Check_Number Check_Amount TO “SAMPMAN” IF
Man_Chk_Ind=‘Y’

OVR_SAMPLE

X=RAND(COUNT1)
To select a sample of invoices over the user defined approval limit (see the Audit Steps
section below for procedures to perform using the resulting file):
SAMPLE ON RECORD RANDOM X NUMBER ITEMSOVR POPULATION

Check_Date Check_Number Check_Amount TO “SAMPOVR” IF
Check_Amount>VALUE(LIMIT,0)
UND_SAMPLE

X=RAND(COUNT1)
To select a sample of invoices under the user defined approval limit (see the Audit
SAMPLE ON RECORD RANDOM X NUMBER ITEMSUND POPULATION

Check_Date Check_Number Check_Amount TO “SAMPUND” IF
Check_Amount<VALUE(LIMIT,0)
The batch produces the following files:
SAMP Simple random sample of invoices.
SAMPPO Sample of invoices with purchase orders.
SAMPNOPO Sample of invoices without purchase orders.
SAMPMAN Sample of invoices paid by manual check.
SAMPOVR Sample of invoices over the established limit.

SAMPUND Sample of invoices under the established limit.
Audit Steps
The following tests could be performed, depending on the nature of the sample
selected, to assist the auditor in determining whether reasonable assurance has been
achieved with regard to the associated audit objectives:
■ Match all invoice information to the purchase requisition and/or purchase

order, receiving report and check copy noting completeness and proper
authorization of all documents in accordance with company policy.
■ Review any associated competitive bids.
■ Recalculate clerical accuracy of invoices.
■ Review expense account distributions for reasonableness.
■ Ensure that only original invoices were processed for payment. If the
original was not used, provide explanation as to why payment was made.
■ Determine that all documentary support is canceled to prevent subsequent
reuse.
■ Determine if the invoice was paid so as to take advantage of terms offered by
the vendor.
■ Review payment terms and determine if the invoice was paid early, late or
on time.
Helpful Hints
It may be more useful to export the results to a spreadsheet (exporting is done by

selecting “Data” from the menu bar and choosing “Export”) where columns
have already been established for the audit steps to perform. As each step is
completed, an ‘X’ can be placed in the column with any comments typed in the
adjacent columns. This approach leads to the standardization of testwork, cleaner
workpapers and a saved tree.

Review the sequence of invoices, purchase Application 7
orders and check numbers for gaps Batch: ACCPAY_7
Novice
Overview
Gaps may signal incomplete data processing or, in the situation of checks, possible
misappropriated assets. Usually, a method of documenting these occurrences, along
with a review by an independent party, is sufficient to ensure the completeness and
accuracy of processing.
required to execute the ACCPAY_7 batch:
Required
<Check_Number>
<Check_Amount>
<Invoice_Batch>
<PO_Number>

batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
To sequence gaps on invoice batches (see the Audit Steps section below for
CLASSIFY ON Invoice_Batch ACCUMULATE Check_Amount TO

CLASSIFIED
OPEN CLASSIFIED
GAPS ON Invoice_Batch ERRORLIMIT 10 TO SCREEN PRESORT
OPEN PAID_FILE
To sequence gaps on purchase order numbers (see the Audit Steps section below for
CLASSIFY ON PO_Number ACCUMULATE Check_Amount TO

CLASSIFIED
OPEN CLASSIFIED
GAPS ON PO_Number ERRORLIMIT 10 TO SCREEN PRESORT
OPEN PAID_FILE
To sequence gaps on check numbers (see the Audit Steps section below for
CLASSIFY ON Check_Number ACCUMULATE Check_Amount TO

CLASSIFIED

OPEN CLASSIFIED
GAPS ON Check_Number ERRORLIMIT 10 TO SCREEN PRESORT
SET SAFETY ON
Audit Steps
To assist in understanding the effects on the organization, gaps in:
■ purchase orders can result in management being unaware of the complete

value of obligations at period end.
■ invoice batches signal potential expenses not recognized in the financial
statements.
■ checks could point to a potential for misappropriation.
As an initial step, attempt to distinguish trends in the gaps (i.e. - a repeated

occurrence of four-check gaps throughout the report which may signal that the
printer voids the first four checks in order to align itself for processing).
Then identify unique gaps (i.e. - 249 gaps in the invoice batch sequence) for inquiry
with management and review of established procedures.
The testwork should answer the following questions:
■ What procedures are in place to document and approve all gaps in the
respective sequences?
■ How are gaps communicated to management?
■ Are voided checks properly documented with the signature area removed to
prevent re-use?

Notes

Analyze purchase orders based upon their Application 8
issuers and/or approvers Batch: ACCPAY_8
Novice
Overview
Many purchase order packages maintain the user IDs for each issuance and approval
of a purchase order. The ability to issue or approve a purchase order should be
limited to only those individuals empowered to initiate purchases within the
organization (i.e., purchasing manager, controller, etc.).
required and/or useful to execute the ACCPAY_8 batch:
Required
<PO_Approver>
<PO_Issuer>
<Check_Amount>
batch.

Batch
SET SAFETY OFF

OPEN PAID_FILE
To classify amounts paid on purchase order approver (see the Audit Steps section
CLASSIFY ON PO_Approver ACCUMULATE Check_Amount to APPROVE
To classify amounts paid on purchase order issuer (see the Audit Steps section below
CLASSIFY ON PO_Issuer ACCUMULATE Check_Amount to ISSUER

SET SAFETY ON
Audit Steps
Review these files with the appropriate level of management, paying special
attention to any unauthorized or inappropriate user access. Considering the data
encompasses the entire audit period, any attempts to update user access listings
immediately prior to the audit would be detected (see further testwork in Chapter 10
- Electronic Data Processing).
As a result of this testwork, any unauthorized access should be terminated with

controls established to prevent its reoccurrence in the future. Some examples of
detection and prevention controls are as follows:
1 Periodic review of the changes made to the purchase order user masterfile.
2 The timely review of this report.

3 The establishment of a masterfile change form system with approvals
obtained prior to any access being granted.

Notes

Extract large invoice payments excluding Application 9
any intercompany transactions Batch: ACCPAY_9
Intermediate
Overview
Materiality is the name of the game, especially when audit resources are limited.
With that in mind, extractions of significant items for detailed or other compliance
testwork is an effective means to gain audit coverage while lowering the extent of
additional sampling. Intercompany transactions are excluded from this exercise as
they would be eliminated from consolidated statements.

Efficiently

Required Useful
<Vendor_Name> <Check_Number>
<Invoice_Date>
<Invoice_Number>
<Invoice_Batch>
<PO_Approver>
<PO_Issuer>
<PO_Number>
batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
DIALOG (DIALOG TITLE "User Dialog" WIDTH 496 HEIGHT 210 )
(BUTTONSET TITLE "&OK;&Cancel" AT 360,132 DEFAULT 1 )
(TEXT TITLE "Enter intercompany name in UPPERCASE" AT
24,16 ) (EDIT TO "KEY" AT 24,84 WIDTH 168 ) (TEXT TITLE
"Enter large payment criteria" AT 24,124 ) (EDIT TO
"LARGE" AT 36,156 ) (TEXT TITLE "Press Enter if you do
not wish to deny intercompany payment extraction" AT
24,40 )
1 Be sure to enter the intercompany name in UPPERCASE to facilitate the

proper functioning of the AT() command below which uses the UPPER()
function.

2 If there is more than one key word you wish to enter, (1) copy the above
command, (2) change the variable from “KEY” to “KEY1” in the new
command and (3) add an additional AT() function for this new variable in
the “EXTRACT” command below.
3 If using the sample data provided, use “OUR” as the intercompany name to
exclude.
Prior to setting the above variable, it is suggested that the stratification command
related to invoice payment size in ACCPAY_1 be issued. This will enable the auditor
to understand the number of transactions over a significant level along with the
respective audit coverage obtained.
EXTRACT TO KEY_FILE IF AT(1,KEY,UPPER(Vendor_Name))=0 AND

FIELDS Check_Amount>VALUE(LARGE,0) AND
Check_Date<>‘19000101’ Check_Amount Check_Number
Vendor_Name Invoice_Date Invoice_Number Invoice_Batch
Payment_Date PO_Approver PO_Issuer PO_Number
DELETE ALL OK
See the Audit Steps section below for procedures to perform using the resulting
KEY_FILE file:
OPEN KEY_FILE
SET SAFETY ON
Audit Steps
Any number of audit tests could be performed on the resulting purchases. For
guidance, review the compliance sample testwork as explained in the Audit Steps
section of Application 6 in this chapter.

Notes

Select a Monetary Unit Sample of vendor Application 10
invoices and automatically create Batch: ACCPAY_10
confirmation requests (no typing Intermediate
necessary)
Overview
Confirmations are effective in providing external evidence to support the existence

and accuracy of internally reported balances. Although in the liabilities area it may
be useful to gain comfort with these two assertions (existence and accuracy), it may
be more important to detect those liabilities not reported at period end. Therein lies
the completeness assertion which is tested to some extent if the confirmation of
vendors leads to the communication of additional liabilities. This assertion can be
tested further through Application 18 in this chapter.
Required
<Check_Amount>
<Check_Date>

<Invoice_Date>
<Invoice_Number>
<Vendor_Address>
<Vendor_City>
<Vendor_Name>
<Vendor_State>
<Vendor_Zip>
batch.
Batch
The sample that follows uses invoices as the sampling units. In other words,
individual invoices are sampled rather than entire vendor balances, providing the
same level of statistical audit coverage over the period end balance. This can be
achieved through a Monetary Unit, Fixed Interval sample. For a more detailed
explanation of the Sampling features, consult the ACL for Windows Reference
Manual which accompanies the software.
Prior to the execution of the batch:
■ Reconcile the balance per the entity’s records to the file used prior to
processing. To calculate the total open payables per the PAID_FILE file,
type the command “TOTAL Check_Amount IF
Check_Date=‘19000101’” at the command and log prompt.
■ Select “Sampling” from the menu bar, choose “Size” and calculate the
sample size. Remember that only open invoices (those with a
Check_Date of ‘19000101’) which are not intercompany will be
selected for sampling. Therefore, if using the sample data provided, the
“Population” would be calculated by the following command (assuming
‘OUR’ is the intercompany name):
“Total Check_Amount IF Check_Date=‘19000101’ and NOT
FIND(‘OUR’, Vendor_Name)

■ Once calculated, note the INTERVAL value which will be accepted by the
batch.
■ Generate a random number to act as the START value in the batch.
■ Determine whether significant transactions, which can be identified in the
batch by entering a CUTOFF value, will be reviewed separately. Prior to
establishment, review Application 1 in this chapter for guidance in setting
the value. (The stratifications should provide you with the information
necessary to decide where the cutoff should originate.) Please note that if no
value is set, ACL will automatically select any balance greater than the
INTERVAL value, as consistent with Monetary Unit Sampling.
SET SAFETY OFF

OPEN PAID_FILE
To accept all necessary information for processing a MUS sample:
ACCEPT ‘Enter intercompany name’ to KEY

ACCEPT ‘Enter interval’ to INT
ACCEPT ‘Enter cutoff’ to CUT
ACCEPT ‘Enter start value’ to START
ASSIGN CUT=INT if LEN(CUT)=0
To select the MUS sample (see the Audit Steps section below for procedures to
SAMPLE ON Check_Amount INTERVAL INT FIXED START CUTOFF CUT

RECORD TO “SAMPLE AP” IF Check_Date=‘19000101’
OPEN SAMPLE_AP
To export the information into a Microsoft Word mail merge format, the following
command is issued. This format allows the merging of vendor data, as created by
ACL, with a blank confirmation form in the Microsoft Word application. ACL for
Windows currently supports mail merge with Word and WordPerfect.

GROUP
EXPORT TO MAILAP.DOC Check_Amount Invoice_Date
Invoice_Number Vendor_Address Vendor_City Vendor_Name
Vendor_State Vendor_Zip WORD
The following command is executed to create a log, in Excel format, which acts as a
documented monitoring tool for those confirmations received or still outstanding.
EXPORT TO APLOG.XLS Check_Amount Invoice_Date

Invoice_Number Vendor_Address Vendor_City Vendor_Name
Vendor_State Vendor_Zip EXCEL
END
DELETE ALL OK
SET SAFETY ON
Audit Steps
Mail and log confirmations upon receipt. Investigate any confirmations not
returned or returned undelivered. Second requests should be mailed for these. If
responses are not expected to be received by period end, additional procedures
should be considered such as invoice or (after period end) check payment
observation.
A quick way to observe check payments is to join the SAMPLE_AP along with an
after period end PAID_FILE as follows:
SET SAFETY OFF

OPEN PAID_FILE
SORT ON Vendor_Name Invoice_Number TO SORTED IF
OPEN SAMPLE_AP

JOIN PKEY Vendor_Name Invoice_Number FIELDS Check_Amount
Invoice_Date Invoice_Number Vendor_Address Vendor_City
Vendor_Name Vendor_State Vendor_Zip SKEY Ven_Name
Invoice_Number WITH Check_Number Check_Date TO “APPAID”
CLOSE SECONDARY
OPEN APPAID
SET SAFETY OFF
Once the confirmation/additional testwork process is complete, use the Evaluate

command (select “Sampling” from the menu bar and choose “Evaluate”).
This will calculate the “Most Likely Error” and “Upper Error Limit” as further
explained in the ACL for Windows User Guide, Reference Manual, or on line help.

Notes

Calculate weighted days payable Application 11
outstanding and interest lost for not Batch: ACCPAY_11
paying in 30, 45 and 60 days Advanced
Overview
■ Who are our largest vendors?

■ When are vendors paid?
■ What benefits can be realized if vendors are paid under extended terms?
The answers to the above questions are available in one searchable report, as
described below.

Efficiently
Required
<Check_Amount>
<Discount>

<Check_Date>
<Invoice_Date>
<Vendor_Name>
batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
The following fields will calculate interest lost for not paying invoices at 30, 45, and
60 days assuming a 7% rate of interest. If the rate of interest you wish to use is
different than this percentage, update the three field definitions below (see .07 in the
beginning of each of the definitions). Also please note that the division of certain
fields is multiplied by 1.000 in the field definition below. This is completed to avoid
any calculation inaccuracies due to the rounding of minuscule percentages.
DEFINE FIELD Interest_Lost_30 COMPUTED

(.07*Check_Amount)*(((1.000*(Check_Date-Invoice_Date))-
30)/360) IF (Check_Date-Invoice_Date)<30
0.000
0.000

0.000
DEFINE FIELD DPO COMPUTED (Check_Date-Invoice_Date)
The field below will become the total payments made to the vendor after various
sorting and summarizations which follow.
DEFINE FIELD Sum_of_checks COMPUTED

Check_Amount IF Check_Amount>=0
0.000
Prior to sorting, the batch requires that only paid invoices with valid invoice dates
and amounts be processed. Otherwise, inaccurate DPO calculations or division by
zero may occur. The batch also does not process any invoices with a financial
discount which would artificially lower the DPO. These amounts can be tested
further in Application 12 in this chapter.
SUMMARIZE ON Vendor_Name ACCUMULATE Sum_of_Checks TO

“SORTED1” IF Invoice_Date<>‘19000101’ AND
Check_Date<>‘19000101’ AND Check_Amount<>0 and
Discount=0 PRESORT
JOIN PKEY Vendor_Name FIELDS DPO Check_Amount
Payment_Terms Discount Check_Date Invoice_Date
Vendor_Name Interest_Lost_30 Interest_Lost_45
Interest_Lost_60 SKEY Vendor_Name WITH Sum_of_Checks
PRIMARY TO “DPOSUM” PRESORT
CLOSE SECONDARY
OPEN DPOSUM
The previous commands have essentially created a file with a record for each check
amount along with the total payments to the vendor (Sum_of_Checks). Using
these amounts, a weighting of the DPO will be computed. Review this example to
understand how the Vendor_DPO field is defined. Then review the
Vendor_Sum_DPO file, completed later in the batch, for the final results:

Vendor Name Check_Amount Sum_of_Checks DPO Vendor_DPO
(A) (B) (C) (A)/(B)*(C)
ABC Corporation 1,000.00 10,000.00 30 3
ABC Corporation 2,500.00 10,000.00 28 17
ABC Corporation 2,500.00 10,000.00 32 8
ABC Corporation 4,000.00 10,000.00 10 4
Weighted DPO 22
DEFINE FIELD Vendor_DPO COMPUTED

(DPO*(1.00000*Check_Amount/Sum_of_Checks)) IF
Invoice_Date<>‘19000101’ AND Check_Date<>‘19000101’
AND Check_Amount<>0
0.00000
SUMMARIZE ON Vendor_Name ACCUMULATE Vendor_DPO
Check_Amount Interest_Lost_30 Interest_Lost_45
Interest_Lost_60 OTHER Vendor_Name Sum_of_Checks TO
Vendor_Sum_DPO IF Check_Amount>0 and Sum_of_Checks>0

The last two requirements of the previous command are essential to ensure that no
division by zero occurs in the weighted days payable outstanding calculation.
DELETE Vendor_DPO OK
DELETE ALL OK
OPEN PAID_FILE
DELETE Interest_Lost_30 OK
DELETE DPO OK
DELETE Sum_of_checks OK
OPEN Vendor_Sum_DPO
It may be helpful to set the printer to “Landscape” prior to batch execution so that
the four fields accumulated below will appear on the final printed report.
To stratify on the weighted days payable outstanding (see the Audit Steps section
below for procedures to perform using the resulting report):
STRATIFY ON Vendor_DPO ACCUMULATE Check_Amount

Interest_Lost_30 Interest_Lost_45 Interest_Lost_60
MINIMUM 0 MAXIMUM 100 FREE 1,7,14,21,30,60,90 TO SCREEN
HEADER=’Stratification on Vendor DPO’

SET SAFETY ON
Audit Steps
The printed stratification brings into clearer focus where we are with relation to
vendor payments and interest lost as opposed to where we want to be. After
reviewing this report, try extracting the “100 worst offenders” (defined as those with
the lowest DPO) by sorting on the Vendor_DPO field in ascending fashion and
extracting if RECNO()<101. If practicable, and with the permission of purchasing
management, these “offenders” could be contacted to request new terms, either
through an offer of a financial discount for early payment or the allowance of
extended payment terms.The average weighted DPO for the organization can be
calculated by executing the following commands, preferably in a batch form.
(Review the total of the Total_DPO field in the Last Result window after
execution.)
COM “To Calculate the Average Weighted Days Payable

Outstanding for the Organization”

TOTAL Check_Amount
DEFINE FIELD Total_DPO COMPUTED
(Vendor_DPO*(1.00000*Check_Amount/TOTAL1) IF
Check_Amount<>0
0.00000
TOTAL Total_DPO
Helpful Hints
Payment timing cannot be analyzed in a vacuum. It must take into consideration any
financial discounts taken for early payment (which this batch does not due to the
artificially low DPO it would create), improved pricing in the marketplace or better
service due to early payment terms. Although the last two benefits cannot be
reviewed effectively using ACL for Windows, the first can through the execution of
Application 12. (Application 12 summarizes by vendor the total expenditure amount
upon which discounts were taken and the total amount upon which no discounts
were taken).

Notes

Detect vendors with no discounts taken Application 12
when discounts have been taken in the Batch: ACCPAY_12
past Intermediate
Overview
The objective of this batch is to match all vendor activity when a financial discount
was taken, to an activity when a discount was not taken. Quantifying these detects
weaknesses in the negotiated payment terms with vendors or in the invoice approval
process. To better understand the potential for loss in these instances, a 2% discount
for payment within 10 days equates to a 36.7% annualized return on investment,
after subtracting the lost interest due to early payment. Such returns are difficult to
attain, even when the stock market is running at its peak. Further, this return is
attained with little or no risk which is stark in comparison to the risk of investing in
equities.
Audit Objective Tested

Efficiently
Required
<Check_Amount>

<Discount>
<Vendor_Name>
batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
The following classifications will create one file of all vendors not paid a discount
and another of all vendors with whom a discount was taken. Later in the batch, these
two files will be merged and sequenced for duplicates to create one file of vendors
with discounts taken/not taken.
CLASSIFY ON Vendor_Name ACCUMULATE Discount Check_Amount

IF Discount=0 AND Check_Date<>‘19000101’ TO “VENDORS1”
CLASSIFY ON Vendor_Name ACCUMULATE Discount Check_Amount
IF Discount>0 AND Check_Date<>‘19000101’ TO “VENDORS2”
OPEN VENDORS2
OPEN SECONDARY VENDORS1
MERGE ON Vendor_Name TO MERGED
OPEN MERGED
CLOSE SECONDARY
DUPLICATES ON Vendor_Name OTHER Check_Amount Discount
Count AS ‘Num of Invoices’ ERRORLIMIT 10 TO
DISCOUNT.FIL
OPEN DISCOUNT

SET SAFETY ON
A sample of the resulting report is presented below (see the Audit Steps section below
Audit Steps
Review those reported vendor files to determine if discounts were offered on

invoices when no discounts were taken. (Bear in mind it is common for discounts to
be offered on some invoices and not others from a particular vendor.) An extraction
of the detailed transactions for material vendors without discounts taken could be
done as follows:
OPEN PAID_FILE
EXTRACT RECORD IF MATCH(Vendor_Name,‘Coffee
Service’,‘Equipment Maintenance’,‘Health Care
Service’,‘Raw Materials Corp’,‘Skys the Limit
Publishing’) AND Discount=0 TO DISD
OPEN DISD
Use of this detailed report will assist the inspection of vendor files.

Many discounts that are available and not taken are due to the slow routing of
invoices through the approval process. It could be recommended, preferably in a
written purchasing policy, that discounted invoices should receive increased
attention and priority. If approval is received from a decentralized location, the use
of a faxed copy for payment with mailed documents after the fact could be a simple
yet effective method for maximizing payment terms.
It could also be recommended that all invoices initially be recorded in the accounts
payable system net of available discounts. When the invoice is paid, any discount not
taken could be recorded in a “Lost Discount” account. Such a process eliminates the
need for the audit testwork outlined in this application. The only report necessary
would be one that summarizes, on vendor name, the “Lost Discount” account.
Helpful Hints
It must be noted that this report only detects discounts not taken when a discount
has been taken at other times in the audit period. Discounts not taken at all from
a particular vendor cannot be reviewed in this report. To retrieve a complete list of
available discounts not taken, it is best to code such activity. A miscellaneous data
field could be used to place a ‘Y’ for a discountable invoice or to record the actual
discount available. ACL could then be used to define these fields and extract
accordingly.

Calculate interest lost for paying invoices Application 13
prior to their due dates Batch: ACCPAY_13
Intermediate
Overview
Most accounts payable systems automatically pay invoices based on a check date that
is either user-defined upon invoice entry or calculated by adding user-defined
payment terms to the entered invoice date. Assuming check processing occurs each
Friday, invoices expected to be paid from that day through the following Thursday
will be processed. Therefore, invoices paid within a seven-day window could
conceivably be acceptable early payments while any processing prior to this window
could be extracted and reviewed.

Efficiently
Required Useful
<Check_Date> <Check_Number>
<Check_Amount> <Invoice_Batch>
<Discount> <Invoice_Number>

<Expected_Pay_Date> <PO_Number>
<Invoice_Date> <Vendor_Number>
<Payment_Terms> <Vendor_Name>
batch.
Batch
SET SAFETY OFF

DELETE ALL OK
OPEN PAID_FILE
Using the example in Overview above, an entry of 7 for the following ACCEPT
command would detect any payments made one week prior to the expected pay date
in the system:
ACCEPT ‘Enter acceptable payment window in days’ to WINDOW
To calculate the days before or after the established pay date that an invoice is paid:
DEFINE FIELD Days_Payment_Diff COMPUTED (Check_Date-

Expected_Pay_Date)
To calculate the difference in payment terms established and the actual time to pay:
DEFINE FIELD Pay_Term_Diff COMPUTED (Payment_Terms-

(Check_Date-Invoice_Date))
To calculate interest lost for not paying invoices at the expected pay date assuming a
7% rate of interest (If the rate of interest you wish to use is different than this
percentage, update the field definition):

DEFINE FIELD Interest_Lost COMPUTED
(Check_Amount)*(1.000*(Check_Date-Expected_Pay_Date)/
360)*.07
To ensure accurate processing, the batch requires that only paid invoices with valid
dates and amounts be extracted. This is accomplished by the numerous statements
below.
EXTRACT TO “EXTRACTED” if (Expected_Pay_Date-

VALUE(WINDOW,0))>=Check_Date and
Expected_Pay_Date<>‘19000101’ and
Check_Date<>‘19000101’ and Check_Amount>0 and
Discount=0
Check_Date Invoice_Date Invoice_Batch Check_Amount
Invoice_Number Check_Number Invoice_Date Payment_Terms
PO_Number Vendor_Number Vendor_Name Expected_Pay_Date
Days_Payment_Diff Pay_Term_Diff Interest_Lost
DELETE Days_Payment_Diff OK
DELETE Pay_Term_Diff OK
DELETE Interest_Lost OK
OPEN EXTRACTED
To sort and classify the early paid invoices by vendor (see the Audit Steps section
SORT ON Vendor_Name to VEN_SORT_EARLPAY

OPEN VEN_SORT_EARLPAY
CLASSIFY ON Vendor_Name ACCUMULATE Check_Amount
Interest_Lost TO VEN_CLASS_EARLPAY
DELETE ALL OK
OPEN VEN_CLASS_EARLPAY
SET SAFETY ON

Audit Steps
For those invoices paid outside of the acceptable range:
1 Review the Pay_Term_Diff field to determine whether a payment was

made prematurely when compared to the established terms for this vendor.
This requires a Payment_Terms field.
2 Review Application 12 (Summary of vendor activity with weighted Days

Payable Outstanding (“DPO”) and interest lost for not paying in 30, 45 and 60
days) in relation to the particular invoice in question.
3 Observe original invoices for verification of invoice date and terms.
4 Assess the reasons for early payment per inquiry of purchasing and
accounts payable management.

Identify vendors with numerous checks Application 14
who could potentially be paid on a Batch: ACCPAY_14
monthly basis Intermediate
Overview
Large numbers of checks to any one vendor can signal inefficiencies in the payment
processing function. One such solution is to pay on a monthly basis. This could be
initiated either by requesting a monthly invoice from the vendor or by negotiating
for proxy terms. These terms specify that all invoices received in the current month
would be paid a certain number of days after month end (usually thirty). Such terms
would need to be analyzed for their associated costs and benefits coupled with the
increased efficiencies in the payment process.

Efficiently
Required
<Check_Amount>
<Check_Number>
<Vendor_Name>

batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
The batch will assume that only one check could be written a month to each vendor
(even though this cannot always be possible) with the number of months set by the
below “ACCEPT” command. If using the sample data, Enter “12”.
ACCEPT ‘Enter the number of months of data under review’

TO CHK
To first summarize the data by check number and then summarize the checks by
vendor name. The resulting file CHK_SUMM_VEN, will be used in a subsequent
Extract command below:
SUMMARIZE ON Check_Number ACCUMULATE Check_Amount OTHER

Vendor_Name TO “SUMMARIZED” PRESORT
OPEN SUMMARIZED
SUMMARIZE ON Vendor_Name ACCUMULATE Check_Amount TO
CHK_SUMM_VEN PRESORT
OPEN CHK_SUMM_VEN
To extract vendors with more than one check written in a given month (see the Audit
EXTRACT RECORD IF COUNT>VALUE(CHK,0) to OVER_X_CHECKS

OPEN OVER_X_CHECKS

SET SAFETY ON
Audit Steps
A simple sort in descending order of the Count field in the OVER_X_CHECKS file
will lead the auditor to the most frequently paid vendors. These could be targeted for
requests for monthly billings or improved payment terms.
Discuss with management whether changes to the payment system are feasible. One
obstacle to monthly processing may be that the vendor is not able to continue as a
going concern without more frequent payments to meet current costs. Uncovering
this fact may raise another issue as to why the organization is doing business with
such “fly by night” operations.

Notes

List possible duplicate payments based on Application 15
matching invoice number, vendor name Batch: ACCPAY_15
and the absolute value of the check Novice
amount*

matching invoice date, vendor name and Batch: ACCPAY_16
the absolute value of the check amount* Novice

invoice date, invoice number and the Batch: ACCPAY_17
absolute value of the check amount* Novice
Overview
Duplicate payments are usually caused by malfunctioning system controls in an

accounting package or keypunch errors that bypass the established system controls.
Some current trends in accounts payable management and duplicate payment
detection are discussed in the following briefs:
“Companies continue slashing accounts payable departments because they

are tempting targets. American companies employ more than 150,000
people, mostly clerks, in accounts payable, according to the Controllers'
Council, a trade group. In theory, clerks who spend all day comparing
purchase orders with invoices don't perform a core function. But they
annually handle more than $3.5 trillion of vendors' bills, more than half the

nation's gross domestic product, consultants estimate. And accounts
payable errors, whether man or machine, directly affect the bottom line.”
“An accounts payable consultant company’s recoveries of overpayments and

the like at client companies have soared to $400 million a year, double the
total five years ago.”
“Some (unscrupulous vendors) send us two invoices with different numbers

for the same item, others add a letter at the end of the invoice number and
still others actually print an exact copy of the original invoice with desktop
publishing computers. A computer can’t catch these scams unless
specifically programmed to do so.”
The below applications provide a sample, but not a conclusive, approach to test for
such duplication. Some free advice, “Don’t pay an accounts payable consultant for
what ACL and some research can do for you”.

Efficiently
required to execute the ACCPAY_15_16_17 batch:
Required Useful
<Check_Amount> <Check_Number>
<Check_Date> <Invoice_Batch>

<Invoice_Date>
<Invoice_Number>
<Vendor_Name>
batch.
Batch
batches, double-clicking on the ACCPAY_15_16_17 batch, and then clicking
“Run” in the resulting Message box.
SET SAFETY OFF

OPEN PAID_FILE
To sequence on matching invoice number, vendor name and the absolute value of
the check amount (see the Audit Steps section below for procedures to perform using
the resulting file):
DUPLICATES ON Invoice_Number Vendor_Name

ABS(Check_Amount) other Invoice_Date Invoice_Batch
Check_Number Check_Date Check_Amount ERRORLIMIT 10 TO
DUP_INV_VEN_NET.FIL IF Check_Date<>‘000101’
To sequence on matching invoice date, vendor name and the absolute value of the
check amount (see the Audit Steps section below for procedures to perform using the
resulting file):
DUPLICATES ON Invoice_Date Vendor_Name ABS(Check_Amount)

OTHER Invoice_Number Invoice_Batch Check_Number
Check_Date Check_Amount ERRORLIMIT 10 TO
DUP_DATE_VEN_NET.FIL IF Check_Date<>‘000101’
OPEN PAID_FILE

To sequence on matching invoice date, invoice number and the absolute value of the
check amount (see the Audit Steps section below for procedures to perform using the
resulting file):
DUPLICATES ON Invoice_Date Invoice_Number

ABS(Check_Amount) OTHER Vendor_Name Invoice_Batch
Check_Number Check_Date Check_Amount TO
DUP_DATE_NUM_NET.FIL IF Check_Date<>‘000101’
SET SAFETY ON
Audit Steps
The following files can be tested as follows:
DUP_INV_VEN_NET - This file lists possible duplicate payments based on matching

invoice number, vendor name and the absolute value of the check amount. This report
was created to test the accounting system control against allowing a duplicate vendor
name, check amount and invoice number to be processed. The absolute value is used
considering the system should allow an invoice to be entered, voided with an equal
negative entry and reentered. If the absolute value function was not used, sorting
would lead to the positive valued entry and reentry of a payment to improperly be
considered duplicates, with no consideration for the voided negative entry.

To ease review, summarize this file on Invoice_Number and Vendor_Name
and accumulate the Check_Amount (not absolute). Any accumulation that is
greater than zero should represent a valid duplicate which can be traced to the
original invoices and discussed with management.
DUP_DATE_VEN_NET - This file lists all possible duplicate payments based on

matching invoice date, vendor name and the absolute value of the check amount.
Working off the concepts discussed in the last report, imagine that on the duplicate
entering of an invoice, everything is keyed properly except for the invoice number.
Instead of being entered as “123”, it is entered as “12-3”. The previous report would
not identify the duplicate; this report will.
To ease review, summarize this file on Invoice_Date (use the DATE() function
to create a character field for summarization) and Vendor_Name and accumulate
the Check_Amount (not absolute). Return to the DUP_DATE_VEN_NET file. For
all vendors with an accumulation greater than zero, review the invoice number field
to determine whether a duplicate has occurred. Much of the activity reviewed
should represent numerous invoices from a given vendor sent on the same date (i.e.
- Invoice numbers 10123 and 10124 from the same vendor, both sent on 12/21/95).
For any invoices that appear to be keypunch errors, as in the example in the previous
paragraph, observe the original invoices and discuss them with management to
conclude whether a duplicate payment has occurred.

DUP_DATE_NUM_NET - This report lists possible duplicate payments based on
matching invoice date, invoice number and the absolute value of the check amount.
If the wrong vendor name is selected when entering an invoice the second time, the
system will not catch it. This is common considering there may be many different
vendor names established for the same company. For example, ACL may be “ACL
Software”, “ACL Corp.”, etc.
Once again, the first step is to summarize the file on Invoice_Date (use the
DATE() function to create a character field for summarization) and
Invoice_Number and accumulate the Check_Amount (not absolute). As in
the previous report, return to the DUP_VEN_NET_DATE file. For all vendors with
an accumulation greater than zero, review the vendor name field to determine
whether a duplicate has occurred. Much of the activity reviewed should represent
different vendors who coincidentally sent invoices with the same number, date and
amount.
For any in question, observe the original invoices and discuss them with
management to conclude whether a duplicate payment has occurred.
If a duplicate is detected, the following prevention/detection techniques could be

suggested:
■ Execute the above reports prior to each pay run during final processing.
■ Review a more detailed and timely analysis of budget to actual costs with
management.

■ Implement a standardized format for invoice entry to minimize keypunch
errors.
■ Review an invoice edit report (report of all transactions entered) soon after
each input session
Helpful Hints
Certain accounting packages allow the issuance of partial payments, which therefore
allows a payment to the same vendor with the same invoice number, date and
possibly the same amount. Usually, this transaction requires an additional coding
(i.e. - entering a “P” in a field that may be named Transaction Type to designate
partial payment of an invoice) which could be extracted and reviewed as part of the
testwork explained above.

Notes

Extract check payments for unrecorded Application 18
liability testwork Batch: ACCPAY_18
Intermediate
Overview
The classic unrecorded liability test is to extract material check payments occurring
after period end, review invoice packages, and determine whether the item should
have been expensed prior to period. This test should be performed through the last
date of fieldwork, immediately prior to issuing an opinion relative to the financial
statements.
It is futile to extract those items entered prior to period end and paid after such date
since accounts payable packages that accrue such amounts automatically. However,
ACL could extract items similar to those just explained which were entered after
period end and appear to relate to a prior time. This results in a report that, similar
to the classic example stated above, also puts into question the completeness of the
ending liability reported in the financial statements.

Required Useful
<Check_Amount> <Check_Number>
<Check_Date> <Invoice_Number>
<Entered_Date> <Invoice_Batch>
<Invoice_Date> <Expected_Pay_Date>
<PO_Number>
<Vendor_Name>or<Vendor_Number>
batch.
Batches
ACCPAY_18_1
There are two batches listed below that you will use to complete the unrecorded
liability analysis.
The first batch is designed to test the system control which should accrue all open
liabilities at period end. It requires a file to be downloaded at period end. This batch
is executed by opening the Overview window, expanding the list of batches, double-
clicking on the ACCPAY_18_1 batch, and then clicking “Run” in the resulting
Message box.
SET SAFETY OFF

OPEN PAID_FILE
The following ACCEPT command requires a user-entered date in the same format as
that which is defined for the Check_Date field. For purposes of this batch, the
Check_Date field is defined as YYYYMMDD. If using the data supplied with the
Toolkit, type 19961231.
ACCEPT ‘Period end date: YYYYMMDD’ TO PERIOD

To total open invoices with check dates of ‘000101’ entered prior to period end (see
the Audit Steps section below for procedures to perform using the resulting total):
TOTAL Check_Amount IF Check_Date=‘19000101’ AND

AGE(PERIOD,Entered_Date)<=0
DELETE ALL OK
SET SAFETY ON
ACCPAY_18_2
The second batch will complete the extractions explained in Overview above. It
requires a file to be downloaded on the last day of fieldwork. This batch is executed
by opening the Overview window, expanding the list of batches, double-clicking on
the ACCPAY_18_2 batch, and then clicking “Run” in the resulting Message box.
SET SAFETY OFF

OPEN PAID_FILE
ACCEPT ‘Period end date: YYYYMMDD’ TO PERIOD
Materiality can be judged by many methods, but regardless of method, the coverage
obtained should be the deciding factor in the established limit. Such coverage can be
assessed through the review of the various stratifications completed in Application 1
in this chapter (most notably, stratification on invoice amounts).
ACCEPT ‘Materiality limit for extraction:’ TO MATER

GROUP
To extract large payments entered after period end (see the Audit Steps section below
EXTRACT TO UNRECORD_EXTR IF AGE(PERIOD,Check_Date)>0 AND

AGE(PERIOD,Entered_Date)>0 AND
Check_Amount>VALUE(MATER,0)
Check_Amount Check_Number Check_Date Invoice_Number

Entered_Date Invoice_Batch Invoice_Date
Expected_Pay_Date PO_Number Vendor_Name

To extract payments with invoice dates prior to period end which are entered and
paid after such date (see the Audit Steps section below for procedures to perform
EXTRACT TO SUSPICIOUS_LIAB IF AGE(PERIOD,Check_Date)>0 AND

AGE(PERIOD,Invoice_Date)<=0 AND
AGE(PERIOD,Entered_Date)>0
Check_Amount Check_Number Check_Date Invoice_Number

Entered_Date Invoice_Batch Invoice_Date
Expected_Pay_Date PO_Number Vendor_Name
END
DELETE ALL OK
SET SAFETY ON
Audit Steps
ACCPAY_18_1
The total of the Check_Amount field can be obtained by reviewing either the
Last Result or Command Log windows. This amount should be accrued in
the general ledger at period end for accounts payable invoices. Completion of this
testwork will not only attest to the validity of the data file obtained but also the
system control to accrue such amounts. Further analysis, if necessary, could be
performed using the EXTRACT command.
ACCPAY_18_2
Deliver the information within UNRECORD_EXTR to management so that the

corresponding invoice packages can be accessed. Analyze these packages to
determine if goods were received or services were rendered prior to period end. For
all prior related expenses, review associated accruals to conclude whether the
completeness of the liability is intact and whether an audit adjustment is necessary.
Please note only those invoices entered after period end were extracted for testwork
(by using the expression AGE(PERIOD,Entered_Date)>0) considering all

invoices entered prior should have been tested through the Total command in
ACCPAY_18_1.
For lack of a better date, the SUSPICIOUS_LIAB file extracts all transactions with
an invoice date prior to period end which were entered after such date. The better
date, under which liability attaches, would be either a service completion date or
receipt date (which are both assumed to not be readily available in the accounts
payable file) depending on whether services or goods were received, respectively.
Using this report, the auditor should perform the associated testwork as explained in
UNRECORD_EXTR to further conclude whether the ending liability is complete.

Notes

Consolidate vendor activity to assess Application 19
organizational purchasing power Batch: no batch
Intermediate
Overview
Volume discounts: it is amazing how such an elementary concept could be lost sight
of when applied in practice. Lately, organizations tend to make decisions in a
decentralized fashion, most likely due to the surge of employee empowerment. This
apparent lack of coordination leads to dysfunctional purchasing; the focus is on the
individual’s needs, not the organization’s. Through the merging of information from
various locations, the auditor can begin to coordinate such activity with the
objective of improved pricing and payment terms.
This application does not require a batch. Fewer than a dozen lines of code are
needed, and details will vary with your intended use of the application.

Efficiently
There are no specific data fields from the PAID_FILE file which are required or
useful in this reporting technique.

batch.
Application Recommendations
Assume that there are two locations which will be merged. Although it is not
necessary, it is preferred that the locations’ files are created with the same software
package. This will ensure the proper functioning of the Merge command which
requires that both files being merged have identical record structures (which
includes number of fields, field lengths and field definitions). If this is not the case,
the data files will need to be defined in that manner prior to processing.
Further, ACL prefers the files to be sorted in ascending order on a key field. One
approach would be to classify on the vendor’s name accumulating the check
amounts paid and financial discounts taken for the period (CLASSIFY ON
Vendor_Name ACCUMULATE Check_Amount Discount TO
PAID_FILE_LOC_1). Each file could then be extracted to two new files with a
location code attached and merged as follows:
OPEN PAID_FILE_LOC_1
For each record in the PAID_FILE_LOC_1 file, a Location_Code of LOC_1

will be extracted using the following command. Such a code will be used in a later
Merge command in the batch.
EXTRACT ALL “LOC_1” as “Location_Code” to EXTRACTED

OPEN PAID_FILE_LOC_2
For each record in the PAID_FILE_LOC_1 file, a Location_Code of LOC_2

will be extracted using the following command. Such a code will be used in a later
Merge command in the batch.
EXTRACT ALL “LOC_2” as “Location_Code” to EXTRACTED1

OPEN EXTRACTED
OPEN EXTRACTED1 SECONDARY

To merge both files with location codes for analysis:
MERGE PKEY Vendor_Name SKEY Vendor_Name TO MERGED

OPEN MERGED
CLOSE SECONDARY
SORT ON Vendor_Name to SORTED
OPEN SORTED
The resulting file will be a vendor listing, sorted on vendor name, with each
corresponding location code attached. Through a quick review, it should be readily
determinable whether coordination of vendor purchases is financially viable. The
Discount field should also be reviewed to ascertain whether any financial discounts
taken with a vendor by one location are not taken by other locations. It may be
helpful to extract from the SORTED file all vendors who provide a discount; this list
could be forwarded to each purchasing manager. Managers could then be instructed
to review this document prior to ordering, to ensure that vendors providing
financial discounts to one location provide equivalent discounts to the remaining
locations in the organization.
Helpful Hints
Due to decentralized processing, the vendor names recorded in the accounting

system may vary between locations. One location may record “ACL Services” while
another may use “LTD, ACL Software” It is suggested that a manual review be
performed to ensure that all similar vendors are aggregated. To assist in this
compilation, the AT() function is extremely useful and is suggested to ensure the
completeness of the aggregation. Using the “ACL Services” example above, the
following command could be issued to extract all vendor listings with ACL in their
Vendor_Name field:
EXTRACT ALL IF FIND(‘ACL’,Vendor_Name) TO ACL

Notes

Summarize debit memos on vendor, issuer, Application 20
and type for exceptions and unusual trends Batch: ACCPAY_20
Novice
Overview
Vendor credit memos occur for various events (i.e. - price adjustments) after
payment. Most of these credits call into question the controls surrounding the
review process. Many of the underlying events should have been detected prior to
payment. Summarization of such activity by the entering party, vendor and type of
memo can point to trends which may require the strengthening of related controls.

Efficiently
required to execute the ACCPAY_20 batch. The following codes, which are not all-
inclusive, are presented in the field <Debit_Memo_Code>:
■ BE - billing errors

■ DP - duplicate payments
■ NA - No debit memo code applicable
■ PA - price adjustments
■ PR - product returns
■ VD - voided check
Required
<Check_Amount>
<Debit Memo Code>
<Vendor_Name>
<Enterer_Init>
batch.
Batch
SET SAFETY OFF

DELETE ALL OK
OPEN PAID_FILE
To classify debit memos on vendor name (see the Audit Steps section below for
CLASSIFY ON Vendor_Name ACCUMULATE Check_Amount IF

Check_Amount<0 TO CLASS_VEN_DR
To classify debit memos on the established codes (see the Audit Steps section below

CLASSIFY ON Debit_Memo_Code ACCUMULATE Check_Amount IF
Check_Amount<0 TO CLASS_CODE_DR
To classify debit memos on the entering party’s initials (see the Audit Steps section
CLASSIFY ON Enterer_Init ACCUMULATE Check_Amount IF

Check_Amount<0 TO CLASS_ENT_DR
To summarize first on the vendor and then on the debit codes recorded, for
additional analysis of the types of codes by vendor:
SUMMARIZE ON Vendor_Name Debit_Memo_Code ACCUMULATE

Check_Amount TO SUMM_VEN_CD_DR IF
Debit_Memo_Code<>'NA' PRESORT
SET SAFETY ON
The following files are created:
CLASS_VEN_DR Debit memos classified on vendor.
CLASS_CODE_DR Debit memos classified on code.
CLASS_ENT_DR Debit memos classified on the enterer’s initials.
SUMM_VEN_CD_DR Debit memos summarized on vendor and then by

code.

Audit Steps
The following audit tests should be performed for the various types of credit memos
received from vendors:
■ PA - Price adjustments - Inquire of management and observe the matching

process of purchase order to invoice prices. Determine whether a lapse of
controls existed leading to payment of improper prices. To further
determine the extent of purchase order to invoice differences, review
Application 5 (Variance in total purchase order cost to invoice cost) in this
chapter.
■ BE - Billing errors - See procedures for Price Adjustments below and apply
to the events initiating a billing error (i.e. - quantity differences, erroneous
service charges, etc.).
■ DP - Duplicate payments - Determine whether the system control
disallowing payments for equivalent vendor, amount and invoice is
operating effectively. This can be tested through the execution of
Application 15 in this chapter. Applications 15, 16 and 17 could be
recommended to management as effective tools in detecting duplicate
payments prior to the issuance of checks.
■ PR - Product returns - Inquire of management and observe the quality
control process to ensure that receipts are in good working condition prior
to acceptance.
■ VD - Voided check - Inquire of management and review the process for
voiding checks. A check log, noting all voids, should be maintained and
reviewed by the appropriate level of management. Voided checks should
have their signature portion torn off and the word “VOID” written
conspicuously on the front. Additional testwork relative to the sequence of
checks could be completed through Application 7 in this chapter.
Trends in vendor credit memos could be analyzed based on:
■ the entering party, possibly signifying a lack of employee training or

oversight
■ the vendor, as this could highlight vendors with numerous pricing,
billing or quality issues

■ the type of credit memo, to assist in the calculation of administrative
burden created from such transactions.

Notes

Identify all vendors with debit balances Application 21
Batch: ACCPAY_21
Novice
Overview
Although it is possible for vendors to provide a credit after the organization has paid
their balance in full, it should be the exception rather than the norm. Such credits
could be for price adjustments, billing errors, duplicate payments or product returns
after payment. All of these listed items call into question the controls surrounding
the review process since most of these credits should have been detected prior to
payment.

Efficiently
Required

<Check_Amount>
<Vendor_Name>
batch.
Batch
SET SAFETY OFF

OPEN PAID_FILE
To detect all vendor balances less than zero (see the Audit Steps section below for
CLASSIFY ON Vendor_Name ACCUMULATE Check_Amount TO

CLASSIFIED
OPEN CLASSIFIED
EXTRACT RECORD IF Check_Amount<0 TO VEN_DEB_BAL
OPEN VEN_DEB_BAL
SET SAFETY ON
Audit Steps
See the Audit Steps section in Application 20 in this chapter.

Payroll Processing Chapter 6
The auditor may use a variety of analytical and substantial procedures to complete
the current-year audit testwork. This chapter is meant to provide exception
reporting tools to support this aim.
Payroll Processing Objectives

Following is a list of specific audit objectives for the payroll function along with the
applicable report numbers. The auditor should attempt to obtain reasonable
Payroll Processing is Operating Effectively and Efficiently
Report numbers: 1, 2, 3, 4, 5
Changes to the Employee Masterfile are Authorized, Accurate and Complete
Report numbers: 2, 3, 5, 6
Payroll Expenses are Properly Authorized, Accurate and Complete
Report numbers: 1, 2, 3, 4, 5
Report numbers: 1, 2, 4, 5, 7, 8, 9

Payroll Processing Applications
Below are 9 applications containing 12 reports. The number of reports and the
difficulty level are referenced after each application.
1 Stratify payment amounts, hours worked, hourly rates and check dates for
unusual trends and exceptions. (4) Novice
2 Reconcile salaried employee gross pay from one pay period to the next.
(1) Intermediate
3 Compare payroll costs from one period to another. (1) Intermediate
4 List all hourly employees working more than the total hours available in a
week. (1) Novice
5 Select a payroll sample for compliance testwork. (1) Intermediate
6 Compare payroll data files to human resource data files to detect additional/
missing employees and differing salary rates. (1) Advanced
7 List possible duplicate payments based on the same day and employee.
(1) Novice
8 List possible duplicate payments based on the check date and the absolute
value of the check amount. (1) Novice
9 Review the sequence of check numbers for gaps. (1) Novice

Payroll Processing Data Files
(PAYROLL_FILE) - A check register of payroll activity used to process all Payroll

Processing applications (see Chapter 6). Check payments are recorded and made on
a weekly basis. The file contains eight pay periods (10/4/96 to 11/22/96). Below is the
data structure which is followed by a field explanation list:
Data Structure
123 Records using PAYRLLFL.FIL as the data file.
Field Format Start Length Decimal Addtl.

format
explanation
Employee_Last_Name ASCII 1 8
Employee_Address ASCII 9 20
Employee_Number ASCII 29 5
Department_Code ASCII 34 3
Salary_Rate NUMERIC 37 5 2
Check_Date DATE 50 6 PICTURE
“yymmdd”
Weekly_Grs_Pay NUMERIC 56 7 2
Weekly_Net_Pay NUMERIC 63 7 2

Weekly_OT_15 NUMERIC 70 7 2
Weekly_OT_20 NUMERIC 77 7 2
Total_Hours NUMERIC 84 6 0
Regular_Hours NUMERIC 90 5 0
Hours_OT_15 NUMERIC 95 5 0
Hours_OT_20 NUMERIC 100 5 0
Total_Taxes NUMERIC 105 7 2
Various_Deductions NUMERIC 112 6 2
Employee_Last_Name The employee’s last name.
Employee_Address The employee’s address.
Employee_Number The number assigned to the employee by the payroll

system.
Department_Code The department to which the employee reports.
Salary_Rate The employee’s hourly rate.
Check_Number The check number.
Check_Date The date of the check payment.
Weekly_Grs_Pay The gross pay for the week.
Weekly_Net_Pay The net pay for the week which would have been
reported on the employee’s pay check. Represents the
weekly gross pay less any taxes and deductions.
Weekly_OT_15 The overtime pay at 1.5 times the normal salary rate
for the week.
Weekly_OT_20 The overtime pay at 2.0 times the normal salary rate
for the week.
Total_Hours The total hours worked including overtime for the

week.

Regular_Hours The regular hours worked in the week.
Hours_OT_15 The hours at 1.5 times the normal salary rate for the
week.
Hours_OT_20 The hours at 2.0 times the normal salary rate for the
week.
Total_Taxes The total taxes paid for the week.
Various_Deductions Any deductions paid during the week.
(HR_FILE) - A file as of 11/22/96 which lists employee information as represented

in the organization’s human resource system. Below is the data structure which is
followed by a field explanation list:
Data Structure
15 Records using HR_FILE.FIL as the data file.
Field Format Start Length Decimal Addtl.

format
explanation
Employee_Last_Name ASCII 1 8
Employee_Number ASCII 9 5
Salary_Rate NUMERIC 14 5 2

Employee_Last_Name The employee’s last name.
Employee_Number The number assigned to the employee by the payroll

system.
Salary_Rate The employee’s hourly rate.
Payroll Processing Verification Batches

HR_VERIFY
To be executed prior to using the HR_FILE to:
and Log” in ACL after batch processing to ensure that the command yielded
the response “0 data validity errors detected”. Please note the batch will
terminate processing at this point, with an appropriate user dialog box, if
the data has any invalid fields.
2 Selecting a sample of three employees to agree back to supporting

documentation for accuracy - Agree information per the file HR_SAMP to
the supporting documentation. Please note the number of sampled items in
the batch can be adjusted if necessary.
batches, double-clicking on the HR_VERIFY batch, and then clicking “Run” in the
SET SAFETY OFF

OPEN HR_FILE
DELETE ALL OK
VERIFY FIELDS Employee_Last_Name Employee_Number
Salary_Rate ERRORLIMIT 10 TO SCREEN

command or if there are fewer than three records in the file for sampling. If the data
is valid, processing will continue with HR_VERIFY1 which is listed below.
COUNT
DO HR_VERIFY1 IF WRITE1=0 AND COUNT1>=3
PAUSE ‘BATCH TERMINATED - There are either no records or
less than three records in the file for sampling
purposes ‘IF COUNT1=0 OR COUNT1<3
DELETE ALL OK
SET SAFETY ON
HR_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCH HR_VERIFY - SEE

CHAPTER 3 RELATIVE TO VERIFICATION BATCHES FOR A
To select a sample of three employees for agreement to supporting information:
X=RAND(COUNT1)
SAMPLE ON RECORD RANDOM X NUMBER 3 RECORD TO “HR_SAMP”
OPEN HR_SAMP
PAYROLL_VERIFY
Executed prior to using the PAYROLL_FILE to:
and Log” after batch processing to ensure that the command yielded the
response “0 data validity errors detected”. Please note the batch will

2 Stratify all payroll activity for the period on the weekly net payment
amount and check date - These reports could be reviewed with
management for their reasonableness. Care should be taken with regards to
large negative or positive transactions which may need specific
identification and review.
3 Selecting a sample of three employee payments to agree back to

supporting documentation for accuracy - Agree information per the file
PAY_VER_SAMP to the supporting documentation. Please note, the
number of sampled items can be adjusted in the batch, if necessary.
batches, double-clicking on the PAYROLL_VERIFY batch, and then clicking
Prior to opening ACL, it is necessary to change the computer’s system date to the last
payment date in the PAYROLL_FILE file. This will allow the age command, as
used to stratify on the Check_Date, to function properly (if using the sample data
provided with the Toolkit, use 11/22/96).
SET SAFETY OFF

DELETE ALL OK
OPEN PAYROLL_FILE
VERIFY FIELDS Check_Date Check_Number Department_Code
Employee_Address Employee_Last_Name Employee_Number
Hours_OT_15 Hours_OT_20 Regular_Hours Salary_Rate
Total_Hours Total_Taxes Various_Deductions
Weekly_Grs_Pay Weekly_Net_Pay Weekly_OT_15
Weekly_OT_20 ERRORLIMIT 10 TO SCREEN
command or if there are fewer than three records in the file for sampling. If the data
is valid, processing will continue with PAYROLL_VERIFY1 which is listed below.
COUNT
DO PAYROLL_VERIFY1 IF WRITE1=0 AND COUNT1>=3

purposes ‘IF COUNT1=0 OR COUNT1<3
DELETE ALL OK
SET SAFETY ON
PAYROLL_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCH PAYROLL_VERIFY

To stratify on weekly net pay:
STRATIFY ON Weekly_Net_Pay ACCUMULATE Weekly_Net_Pay TO

SCREEN FREE -100000, -50000, -10000, -1000, -100,
0,100,1000,5000,10000,50000,100000
HEADER=‘Stratification on weekly net payment’
To stratify on the check date:

120, 150, 180, 210, 240, 270, 300, 330, 360 ACCUMULATE
Weekly_Net_Pay TO SCREEN IF Check_Date <> ‘19000101’
HEADER=’Aging on Check Date’
To select a sample of three weekly payments for agreement to supporting

information:
X=RAND(COUNT1)
SAMPLE ON RECORD RANDOM X NUMBER 3 RECORD TO
“PAY_VER_SAMP”
OPEN PAY_VER_SAMP

Stratify payment amounts, hours worked, Application 1
hourly rates and check dates for unusual Batch: PAYROLL_1
trends and exceptions Novice
Overview
The analysis of the range and timing of pay across an organization is an intriguing
way to begin a review of payroll. These preliminary reports will go a long way to
improve the focus and effect of the upcoming audit.
The following fields, currently in the PAYROLL_FILE as included with this

Toolkit, are required to execute the PAYROLL_1 batch.
Required
<Check_Date>
One numeric field from this list:
<Hours_OT_15>
<Hours_OT_20>

<Regular_Hours>
<Salary_Rate>
<Total_Hours>
<Total_Taxes>
<Various_Deductions>
<Weekly_Grs_Pay>
<Weekly_Net_Pay>
<Weekly_OT_15 >
<Weekly_OT_20 >
PAYROLL_VERIFY batch. The stratification on net pay provides a wide-angle
focus of the activity; it was used in the PAYROLL_VERIFY batch as further
explained in Chapter 3.
Batch
batches, double-clicking on the PAYROLL_1 batch, and then clicking “Run” in the
of the last payment in the file). This parameter is required to allow the AGE()
function, as used to stratify on the Check_Date, to function properly. If using the
sample data provided with the Toolkit, enter the date 11/22/96 in YYMMDD format
(i.e. 961122).
SET SAFETY OFF

OPEN PAYROLL_FILE
(TEXT TITLE "Enter the aging date in YYYYMMDD order:"
AT 36,16 ) (EDIT TO "AGE_DATE" AT 36,48 WIDTH 151 )

This command will request, using a dialog box, the numeric field upon which the
stratification will be based.
ACCEPT “Select the field to stratify” FIELDS “N” TO

STRFIELD
Using the Statistics command prior to the stratification will allow for an automatic
calculation of the minimum and maximum occurrences in the selected field. Using
these occurrences, ACL will stratify the field’s data into ten intervals for analysis.
STATISTICS ON %STRFIELD%
To stratify on either gross pay, net pay or the three types of overtime based on a user
defined selection (see the Audit Steps section below for procedures to perform using
the resulting report):
STRATIFY ON %STRFIELD% ACCUMULATE %STRFIELD% INTERVAL 10

TO SCREEN HEADER ‘Stratification on payroll numeric
field selected’
To stratify on check date (see the Audit Steps section below for procedures to
AGE ON Check_Date CUTOFF AGE_DATE INTERVAL 0, 7, 14, 21,

30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360

ACCUMULATE %STRFIELD% TO SCREEN IF Check_Date <>
‘19000101’ HEADER=’Aging on Check Date’
DELETE ALL OK
SET SAFETY ON
Audit Steps
Review on gross and net pay for:
■ unreasonably large balances where activity could be extracted and further

reviewed
■ high number of employees with low accumulated activity
■ negative amounts which should represent voided transactions.
Review on the overtime amounts for:
■ unreasonably large or unreasonably small amounts that could be extracted

and further reviewed
■ possible consolidation of overtime among employees. For example, attempt
to spread overtime among employees at a rate of 1.5 to avoid any situations
requiring 2.0 rate overtime
Review on check date as a means to:
■ anticipate the organization’s cash requirements throughout the year

■ tailor audit testwork to more active payment periods.

Helpful Hints
■ To focus audit efforts more precisely, use the time adjustment batch (as
explained in the Helpful Hints section of Chapter 3), to select the appropriate
period for review.
of each check run’s data prior to payment may detect potential errors or
irregularities.
■ Use the stratification percentages as a guide to accurately communicating
the coverages obtained in audit tests. For example, “22% of weekly
payments greater than $5,000, representing 54% of the total dollar payroll
during 1995, were found to be properly approved.”

Notes

Reconcile salaried employee gross pay Application 2
from one pay period to the next Batch: PAYROLL_2
Intermediate
Overview
When testing for changes in the current period’s salaried payroll, payroll
accountants commonly reconcile the gross pay from the current to the previous pay
run. Any increases in salary, added employees or additional income will
immediately become apparent since salaried employees should be paid the same
amount each period. The auditor, using ACL, could perform this test for any given
pay date, or for all pay periods throughout the year.

Toolkit, are required to execute the PAYROLL_2 batch. Please note that the

overtime fields have been excluded; it is assumed that salaried employees are not
eligible for overtime.
Required
<Check_Date>
<Department_Code>
<Weekly_Grs_Pay>
PAYROLL_VERIFY batch.
Batch
SET SAFETY OFF

OPEN PAYROLL_FILE
To classify the amount of each weekly gross pay on check date (see the Audit Steps
section below for procedures to perform using the resulting report):
Even though the Department_Code field is 3 bytes long, the field is in an ASCII
format and therefore, the “IF” statement will search only the first byte of the field for
all salaried employees (Department_Code=’S’).
CLASSIFY ON DATE(Check_Date) ACCUMULATE Weekly_Grs_Pay TO

RECONCILE IF Departent_Code=’S’
OPEN RECONCILE
SET SAFETY ON

Audit Steps
To ease review of the RECONCILE file, export it to your favorite spreadsheet

program. Then, starting on the second line of data, type the expression “(B2-B1)”.
This can be copied for each successive line to provide a difference value from the
current to the previous pay run. See the illustration below:
A B Current to
Prior Period
Check_Date Gross_Pay Difference
7/5/96 142,000.00
7/12/96 142,000.00 (B2-B1) 0.00
7/19/96 144,000.00 (B3-B2) 2,000.00
7/26/96 144,000.00 (B4-B3) 0.00
Pay period differences that do not net to zero should be:
■ reviewed with management

■ agreed to the actual reconciliations as completed by the payroll department
(if completed)
■ used to request forms identifying changes to the employee masterfile which
could be reviewed for proper handling/approval in accordance with
company policy.

Compare payroll costs from one period to Application 3
another Batch: PAYROLL_3
Intermediate
Overview
Analyticals on gross pay, net pay or other numeric values tend to provide little
comfort when all they show are overall totals. This application allows the user to
pinpoint those employees or departments who contributed to the change within a
given time frame.

Required Useful
<Check_Date> <Employee_Last_Name>
<Department_Code>
<Employee_Number>

*Any Numeric Field currently in the file can be selected
for accumulating (the choices are <Hours_OT_15>,
<Hours_OT_20>, <Regular_Hours>, <Salary_Rate>,
<Total_Hours>, <Total_Taxes>, <Various_Deductions>,
<Weekly_Grs_Pay>, <Weekly_Net_Pay>, <Weekly_OT_15 >,
and <Weekly_OT_20 >)
Batch
To ensure the accuracy of the associated extraction and calculations, be sure to

change the system date to the date of the last payment in the file prior to opening
ACL. If using the sample data provided with the Toolkit, use 11/22/96.
SET SAFETY OFF

OPEN PAYROLL_FILE
ACCEPT “Number of Days from Last Payment in File to Include
in the First Calculation” TO WINDOW1
ACCEPT “Number of Days from the Beginning of the First
Calculation to Include in the Second Calculation” TO
WINDOW2
For an example using the two ACCEPT commands above, assume you wish to
review the month ended 10/22/96 data with relation to the month ended 11/22/96
(as consistent with the data supplied in the file). In this case, enter 31 (for those days
in November) at the first prompt and 31 (for those days in October) at the second
prompt. The first extraction below will be for the data relating to November while
the second would relate to October.
ACCEPT “Field to Accumulate” FIELDS “N” TO AVGFIELD

To extract the first window (November in the sample data example used above) to be
merged later in the batch with the second window of time:
EXTRACT TO EXTRACTED FIELDS IF

AGE(Check_Date)<=VALUE(WINDOW1,0) AND
AGE(Check_Date)>=0
%AVGFIELD% Employee_Number Employee_Last_Name
Department_Code Check_Date “FILE1” as “Extraction”
OPEN EXTRACTED
SUMMARIZE ON Employee_Number ACCUMULATE %AVGFIELD% OTHER
Department_Code Employee_Last_Name Extraction TO
SUMMARIZED PRESORT
OPEN PAYROLL_FILE
To extract the second window (October in the sample data example used above) to
be merged later in the batch with the second window of time:
ASSIGN WINDOW3=(VALUE(Window1,0)+VALUE(Window2,0))
EXTRACT TO EXTRACTED FIELDS IF AGE(Check_Date)<=WINDOW3
and AGE(Check_Date)>=0 and
AGE(Check_Date)>VALUE(WINDOW1,0)
%AVGFIELD% Employee_Number Employee_Last_Name
Department_Code Check_Date “FILE2” as “Extraction”
OPEN EXTRACTED
SUMMARIZE ON Employee Number ACCUMULATE %AVGFIELD% OTHER
Department_Code Employee_Last_Name Extraction TO
SUMMARIZE1 PRESORT
OPEN SUMMARIZED
OPEN SUMMARIZE1 SECONDARY
To merge the two period files into one file based on the employee number for use in
the Sequence command appearing later in the batch:
MERGE ON Employee_Number TO MERGED

OPEN MERGED
CLOSE SECONDARY

To sequence duplicates in employee number between the two period files (see the
Audit Steps section below for procedures to perform using the resulting file):
DUPLICATES ON Employee_Number OTHER %AVGFIELD%

Employee_Last_Name Department_Code Extraction Count as
‘Number of Payments’ ERRORLIMIT 10 TO ACCUM_REVIEW.FIL
PRESORT
OPEN ACCUM_REVIEW
To summarize the employee data created above into a departmental file (see the
SUMMARIZE ON Department_Code Extraction ACCUMULATE

%AVGFIELD% TO DEPT_REVIEW PRESORT
OPEN DEPT_REVIEW
DELETE ALL OK

SET SAFETY ON
Audit Steps
To ease review of the ACCUM_REVIEW and DEPT_REVIEW files, export them to

your favorite spreadsheet program. Keep in mind that “File 1” refers to the
period of time closest to the last payment in the file (this would be November if using
the example explained in Batch above). Then, starting on the second line of data,
type the expression “(B2-B1)”. This can be copied for every other line to provide a
difference value from the first to the second calculation time frame. See the
illustration below:
A B 2nd to 1st Time

Employee_Name Weekly_Net_Pay Extraction Frame Diff.
Joe Jones 24,462.66 File1
Joe Jones 22,554.89 File2 (1,907.77)(B2-B1)
Cindy Marksman 6,933.54 File1
Cindy Marksman 5,466.52 File2 (1,467.02)(B4-B3)
Such analysis may prove useful not only to auditors but also payroll accountants who
generate these reports prior to the final processing of each pay run. This would
confirm changes in the payroll from the prior period due to:
■ salary increases/decreases
■ bonuses
■ increased/decreased overtime
■ addition/termination of employees
■ unusual payments (i.e. - relocation costs)
■ changes in deductions
The auditor should:
1 attempt to gain analytical comfort with the payroll expenses,

2 plan current testwork focusing on those periods with the most differential
or
3 test the change controls in the employee masterfile (by requesting

appropriate change forms which could be reviewed for proper handling/
approval in accordance with company policy).

List all hourly employees working more Application 4
than the total hours available in the week Batch: PAYROLL_4
Novice
Overview
This simple yet effective test can point to control weaknesses within the payroll
accounting software which should have established system checks for such
unreasonable data entry.

Required Useful
<Total_Hours> <Weekly_Net_Pay>
<Check_Date>
<Employee_Last_Name>

Batch
resulting Message box. The batch assumes that pay periods are weekly.
If your organization processes for a different period, modify the number of hours in
the EXTRACT command below to equate to the maximum hours in the pay period.
SET SAFETY OFF

OPEN PAYROLL_FILE
To extract employees who worked more than 168 hours in one week (see the Audit
EXTRACT Check_Date Employee_Last_Name Total_Hours

Weekly_Net_Pay TO OVER168 IF Total_Hours>168
OPEN OVER168
SET SAFETY ON
Audit Steps
Determine through review of payroll registers, time cards, canceled checks and/or
inquiry of management whether the unusual payments took place during the audit
period. Execution of this application prior to each pay run and/or the establishment
of a system control disallowing payment to any employee who reported over 168
hours worked should prevent these occurrences in the future.

Helpful Hints
It may be beneficial to execute this batch not only for hours reported over 168 but
also for excessive hours. For example, all employees working 126 hours or 18 hour
days for 7 days could be extracted for analysis.

Notes

Select a payroll sample for compliance Application 5
testwork Batch: PAYROLL_5
Intermediate
Overview
Analytical testwork can only go so far, especially in the examination of internal

controls. Therefore, compliance testwork is necessary. Samples can be selected
manually (by scanning the various pay registers) or automatically, by using the
following batch.

Toolkit, are required to execute the PAYROLL_5 batch, assuming all of the testwork
performed in Audit Steps below will be completed:
Required Required

<Check_Date> <Salary_Rate>
<Department_Code> <Various_Deductions>
<Employee_Number> <Weekly_Grs_Pay>
<Employee_Last_Name> <Weekly_Net_Pay>
<Total_Taxes> <Weekly_OT_15 >
<Regular_Hours> <Weekly_OT_20 >
<Total_Hours>
<Hours_OT_15>
<Hours_OT_20>
Batch
SET SAFETY OFF

DELETE ALL OK
ACCEPT “How many employee payments, taken at random, do
you wish to sample? Only answer if you wish to select a
random sample, otherwise respond with a 0:” TO ITEMS
The above statement will prompt you to enter the number of sample items you wish
to select. Based on the entry, the following “DO BATCH” command will be
executed. Also, certain “PAUSE” statements have been added if (1) no items meet
your criteria, (2) you do not select any items to sample or (3) you select more sample
items than there are items meeting the criteria in the file. Select “OK” to continue
batch processing.
OPEN PAYROLL_FILE

COUNT
DO PAY_SAMPLE IF VALUE(ITEMS,0)>0 AND
COUNT1>VALUE(ITEMS,0)
OPEN PAYROLL_SAMP
DELETE ALL OK
SET SAFETY ON
The actual sample batch follows. This batch was “triggered” by the “DO
BATCH” command above. Samples are random which is preferred for compliance
testwork because each record has an equal opportunity to be selected. The first
command will select a random seed (initial value for the random number generator)
for the sample. This is followed by the actual sample command.
PAY_SAMPLE
COMMENT “THIS BATCH IS REFERENCED BY BATCH PAYROLL_5 -

SEE APPLICATION 5 IN CHAPTER 6 FOR A FURTHER
DISCUSSION”
X=RAND(COUNT1)
To select the sample (see the Audit Steps section below for procedures to perform
SAMPLE ON RECORD RANDOM X NUMBER ITEMS Check_Date

Department_Code Salary_Rate Employee_Number
Employee_Last_Name Various_Deductions Total_Taxes
Weekly_Grs_Pay Regular_Hours Total_Hours
Weekly_Net_Pay Hours_OT_15 Weekly_OT_15 Hours_OT_20
Weekly_OT_20 TO “PAYROLL_SAMP”

Audit Steps
The following tests could be performed, depending on the nature of the sample
selected, to assist the auditor in determining whether reasonable assurance has been
achieved with regard to the associated audit objectives:
■ Review hiring documents to ensure approval in accordance with

organizational policies.
■ Agree salary rate to proper authorization.
■ Review time cards for hourly employees and/or salaried employees who are
non-exempt, performing the following:
1 Agree hours to time cards.
2 Recalculate gross pay for accuracy (which could be performed

manually or by creating an expression in ACL).
3 Review for indication of clerical accuracy checks and appropriate

approvals.
4 Ensure that only original time cards were processed for payment.
■ Test the computation of federal and state income tax withholdings.

■ Agree check information (if not paid via direct deposit) to the canceled
check, ensuring the endorsement matches what is in the employee's file.
Helpful Hints
It may be more useful to export the resulting information to a spreadsheet

(exporting is done by selecting “Data” from the menu bar and choosing
“Export”) where columns have already been established for the audit steps to
perform. As each step is completed, an ‘X’ can be placed in the column with any
comments typed in the adjacent columns. This approach leads to the
standardization of testwork, cleaner work papers and a saved tree.

Compare payroll data files to human Application 6
resource data files to detect additional/ Batch: PAYROLL_6
missing employees and differing salary Advanced
rates
Overview
The following testwork assumes the payroll file used for processing is not updated by
the human resource file prior to each pay run. It is common for human resource and
payroll systems to operate independent of each other. This framework leads to “out
of the box” controls such as a reconciliation of the two files prior to each pay run
(sometimes completed once by each department, a massive time waster). Manual
controls open the door for human error or fraud which, in the case of payroll
processing, can lead to unauthorized payments.
The following fields, currently in the PAYROLL_FILE and HR_FILE as included

with this Toolkit, are required to execute the following batch. Please note the
Employee_Number field length and format must be identical between the files or
the join command, used in the batch, will not function. Further note the HR_FILE
is as of the last pay period in the file (11/22/96) considering it is a “snapshot” of the
employee records prior to the most recent processing.

PAYROLL_FILE HR_FILE
Required Required
<Employee_Last_Name> <Employee_Last_Name>
<Employee_Number> <Employee_Number>
<Salary_Rate> <Salary_Rate>
PAYROLL_VERIFY and HR_VERIFY batches.
Batch
SET SAFETY OFF
Through the Join command, ACL has the ability to trace each primary file record to
the secondary file, listing all primary file records that are not in the secondary. With
this in mind, there are four combinations of joined files below, each testing a
different aspect of the payroll/human resource file agreement.
To test for employees in the payroll file and not in the human resource file (see the
OPEN HR_FILE
SORT ON Employee_Number TO SORTED1
OPEN PAYROLL_FILE
JOIN PKEY Employee_Number FIELDS Employee_Number
Employee_Last_Name Salary_Rate Check_Date Check_Number
Weekly_Net_Pay SKEY Employee_Number UNMATCHED TO
“ADDTL_PAY_EMPLOYEES” PRESORT

CLOSE SECONDARY
To test for employees in the human resource file and not in the payroll file (see the
OPEN PAYROLL_FILE
SORT ON Employee_Number TO SORTED1
OPEN HR_FILE
JOIN PKEY Employee_Number FIELDS Employee_Number
Employee_Last_Name Salary_Rate SKEY Employee_Number
UNMATCHED TO “ADDTL_HR_EMPLOYEES” PRESORT
CLOSE SECONDARY
To test for employees with payroll rates in the payroll file which are different in the
human resource file (see the Audit Steps section below for procedures to perform
Remember, the resulting report will list only the primary records that do not match
the secondary. Therefore, it will be necessary to open the HR_FILE and manually
observe the differences in rates.
OPEN HR_FILE
SORT ON Employee_Number STRING(Salary_Rate,5) TO SORTED1
OPEN PAYROLL_FILE

JOIN PKEY Employee_Number STRING(Salary_Rate,5) FIELDS
Employee_Number Employee_Last_Name Salary_Rate
Check_Date Check_Number Weekly_Net_Pay SKEY
Employee_Number STRING(Salary_Rate,5) UNMATCHED TO
“DIFF_PAY_RATES” PRESORT
CLOSE SECONDARY
To test for employees with payroll rates in the human resource file that are different
in the payroll file (see the Audit Steps section below for procedures to perform using
the resulting file):
Remember, the resulting report will list only the primary records that do not match
the secondary. Therefore, it will be necessary to open the PAYROLL_FILE and
manually observe the differences in rates.
OPEN PAYROLL_FILE
SORT ON Employee_Number STRING(Salary_Rate,5) TO SORTED1
OPEN HR_FILE
JOIN PKEY Employee_Number STRING(Salary_Rate,5) FIELDS
Employee_Number Employee_Last_Name Salary_Rate SKEY
Employee_Number STRING(Salary_Rate,5) UNMATCHED TO
“DIFF_HR_RATES” PRESORT
CLOSE SECONDARY
SET SAFETY ON
The batch produces the following files:
1 ADDTL_PAY_EMPLOYEES - Employees in the payroll and not in the

human resource file.
2 ADDTL_HR_EMPLOYEES - Employees in the human resource and not in

the payroll file.
3 DIFF_PAY_RATES - Employees with payroll rates in the payroll file

which are different in the human resource file.

4 DIFF_HR_RATES - Employees with payroll rates in the human resource
file which are different in the payroll file.
Audit Steps
From a risk point of view, Reports 1 and 3 from the PAYROLL_6 batch should be
reviewed closely considering they represent rates that were paid different from the
human resource records or employees not appearing in the human resource records.
Further note that considering the HR_FILE is as of the last day in the pay period,
any pay rate changes since the inception of the PAYROLL_FILE file would be
reported in Report 3.
To test, examine the above reports, review the respective payroll registers and
inquire of management to determine whether:
■ Unauthorized payments were made

■ Unauthorized pay rates were used
■ Payments were not complete or inaccurate
■ Employees were fraudulently added to the payroll.
Helpful Hints
If, as stated in the Overview section above, a manual reconciliation is performed by

the human resource and payroll departments, it could be suggested that these
reports replace their procedures if executed prior to actual processing.

Notes

the same day and employee Batch: PAYROLL_7
Novice

the check date and the absolute value of Batch: PAYROLL_8
the check amount Novice
Overview
Duplicate payments are mainly due to non-operating system controls in an

accounting package or keypunch errors which bypass the established system
controls. The below reports provide a sample, but not a conclusive, approach to test
for such duplication.

Toolkit, are required to execute the PAYROLL_8 batch:
Required Useful

<Employee_Address> <Check_Number>
<Employee_Number> <Employee_Last_Name>
<Check_Date> <Weekly_Grs_Pay>
<Weekly_Net_Pay>
Batches
batches, double-clicking on the PAYROLL_7_8 batch, and then clicking “Run” in
the resulting Message box.
SET SAFETY OFF

OPEN PAYROLL_FILE
Sequence duplicate payments based on the employee number and check date (see
the Audit Steps section below for procedures to perform using the resulting file):
DUPLICATES ON Check_Date Employee_Number OTHER

Weekly_Net_Pay Weekly_Grs_Pay Check_Number
Employee_Last_Name ERRORLIMIT 10 TO
DUP_EMPNUM_DATE.FIL PRESORT
OPEN PAYROLL_FILE
Sequence duplicate payments based on the employee address and check date (see the
DUPLICATES ON Check_Date Employee_Address OTHER

Employee_Number Employee_Last_Name ERRORLIMIT 10 TO
DUP_EMPADD_DATE.FIL PRESORT
OPEN PAYROLL_FILE

Sequence duplicate payments based on the absolute value of the net pay and the
check date (see the Audit Steps section below for procedures to perform using the
resulting file):
DUPLICATES ON Check_Date ABS(Weekly_Net_Pay) OTHER

Employee_Number Employee_Last_Name TO
DUP_NETPAY_DATE.FIL
SET SAFETY ON
Audit Steps
The following files can be tested as follows:
DUP_EMPNUM_DATE - This file lists possible duplicate payments based on matching

employee number and check date. This report was created to test the payroll system
control which should prevent the processing of more than one check to the same
employee in a given pay period. If such a control does not exist, it is possible that
properly authorized miscellaneous payments (i.e. - vacation payout) were processed
in addition to the normal salary payment. For any in question, observe the payroll
register and the canceled check and discuss them with management to conclude
whether a duplicate payment has occurred.

DUP_EMPADD_DATE - This file lists possible duplicate payments based on matching
employee address and check date. Working from the concept in the first report, this
file could contain employees who were established twice due to a keypunch error in
the initial setup of the employee. Such a mistake could bypass the system control, if
in existence, which should ensure that the same employee name or number is not
paid twice within the same payroll period. For any in question, observe the payroll
register, canceled check and discuss them with management to conclude whether a
duplicate payment has occurred.
DUP_NETPAY_DATE - This file lists possible duplicate payments based on matching

check date and the absolute value of the net pay. To ease review, summarize this file on
Check_Date and accumulate the Weekly_Net_Pay (not the absolute value as used in
this batch). Any accumulation that is greater than zero could represent a valid
duplicate. The strength of this duplicate payment report is that it does not rely on
duplicate employee information as in the two previous reports and focuses more on

any equal payment in a pay period. Much of the activity reviewed should represent
different employees who coincidentally were paid the same net pay on the pay date.
To determine the accuracy of this finding, trace this file’s information to the payroll
register and canceled check and inquire of management.
(The absolute value is used because the system should allow an employee payment to
be entered, voided and reentered. Otherwise, when using the Sort command, the
positive valued entry and subsequent re-entry of a payment would improperly be
considered a duplicate with no consideration for the void.)
If a duplicate is detected, the following prevention/detection techniques could be

suggested to management:
■ Execute the above reports prior to the final processing of each pay run.
■ Personal delivery of checks to employees by a party independent of the
payroll function on a constant or periodic basis.
■ Complete a more detailed and timely analysis of payroll budget to actual
costs.
■ Review a payroll entry edit report (a report of all transactions entered) after
each input session.
■ Complete a salaried employee reconciliation for each pay run, as further
discussed in Application 2 in this chapter.

Notes

Review the sequence of check numbers for Application 9
gaps Batch: PAYROLL_9
Novice
This application is similar to Application 7 in Chapter 5. It identifies gaps in the

check number sequence.
The following field, currently in the PAYROLL_FILE as included with this Toolkit,
is required to execute the PAYROLL_9 batch:
Required
<Check_Number>
Batch
OPEN PAYROLL_FILE
To sequence gaps in the check numbers (see the Audit Steps section below for
GAPS ON Check_Number ERRORLIMIT 10 TO SCREEN PRESORT

SET SAFETY ON

Notes

Billing and Accounts
Receivable Management Chapter 7
The revenue cycle usually warrants the most attention in an audit and rightly so.
Without it, the organization would cease to exist. The auditor can review the controls
throughout the system through inquiry and observation or can test the accuracy and
completeness of the period end balances through customer confirmation and
examination.
Billing Function and Accounts Receivable Management

Objectives
The following is a list of specific audit objectives for the revenue function along with
the applicable report numbers. The auditor should attempt to obtain reasonable
Revenue and Collection Activities are Operating Effectively and Efficiently
Report numbers: 1, 2, 3, 5, 6, 11, 12, 14
Sales Orders are Properly Authorized, Accurate and Complete
Shipments/Services Performed are Accurate and Complete
Report number: 1, 4, 5, 6, 11, 12
Customer Invoices are Properly Authorized, Accurate and Complete
Report numbers: 1, 4, 5, 6, 11, 12, 13
Accounts Receivable are Accurate, Complete and Valued Properly

Report numbers: 3, 7, 8, 9, 10, 11, 12, 13
Cash Receipts are Safeguarded, Accurate and Complete
Report numbers: 2, 3 11, 12

Applications
Below are 14 applications which contain 27 reports. The number of reports and the
1 Stratify sales for unusual trends and exceptions. (4) Novice
2 Stratify cash receipts for unusual trends and exceptions. (4) Novice
3 Calculate weighted days sales outstanding (“DSO”) by customer,

salesperson and the entire organization. (3) Advanced
4 Review the sequence of invoices, sales orders and shipping documents for
gaps. (3) Novice
5 Calculate interest lost for shipments not billed to date. (1) Intermediate
6 Calculate interest lost for the time lag between the shipment being made and
the billing being processed. (1) Intermediate
7 Recalculate the aging of accounts receivables. (1) Novice
8 Report customers with old and large account balances. (1) Intermediate
9 Identify customers with no set credit limit. (1) Novice
10 Identify customers who have exceeded their credit limit. (1) Novice
11 Summarize credit memos on customer, credit manager, and type for

exceptions and unusual trends. (3) Novice

12 Identify all customers with credit balances. (1) Novice
13 Select a Monetary Unit Sample of customer invoices and automatically

create confirmation requests (no typing necessary). (1) Intermediate
14 Analyze discounts taken by customers after the discount due date.

(2) Intermediate
Billing Function and Accounts Receivable Management Data

Files
(REVENUE_FILE) - This file consists of one year of invoices (1/1/96 to 12/31/96)

and their associated cash receipts used in the processing of most accounts receivable
applications (see Chapter 7). An entry was made based on each invoice sent so each
record is uniquely defined by an invoice number. Please note the
Invoice_Amount_Paid field is the invoice amount which, when paid, has a
Paid_Date that is not equal to zero (‘000101’). Below is the data structure which
is followed by a field explanation list:
Data Structure
240 Records using REVFILE.FIL as the data file.

explanation
Credit_Limit NUMERIC 1 5 0 PICTURE
“(9,999,999.99)”
Credit_Manager ASCII 6 4
Credit_Memo_Code ASCII 10 2
Customer_Address ASCII 12 20
Customer_City ASCII 32 11
Customer_Name ASCII 43 28
Customer_State ASCII 71 2
Customer_Zip ASCII 73 5
Discount NUMERIC 78 6 2 PICTURE
“(9,999,999.99)”
Invoice_Amount NUMERIC 84 8 2 PICTURE
“(9,999,999.99)”
Invoice_Amount ACL 92 12 2
_Paid
Invoice_Date DATE 104 6 PICTURE
“(9,999,999.99)”
Invoice_Number ASCII 110 5
Paid_Date DATE 115 8 PICTURE
“(9,999,999.99)”
Product_Code ASCII 123 3
Salesperson_ID ASCII 126 2
Credit_Limit The credit limit afforded to the customer.
Credit_Manager The credit manager assigned to the customer account.
Credit_Memo_Code The code designating the reason for the credit memo.
Customer_Address The customer’s address.
Customer_City The customer’s city.
Customer_Name The customer’s name.

Customer_State The customer’s state.
Customer_Zip The customer’s zip code.
Discount Discount taken by the customer on the invoice

(calculated at 2%).
Invoice_Amount The amount of the invoice.
Invoice_Amount_PaidThe amount paid on the particular invoice.
Invoice_Date The date of the invoice.
Invoice_Number The invoice number.
Product_Code A code designating the product type sold.
Salesperson_ID Code designating the salesperson assigned to the

customer.
(SHIPMENT_FILE) - This file consists of roughly three months of shipments (9/3/

96 to 12/15/96) and their associated billing dates, used in the processing of accounts
receivable applications (see Chapter 7). Each entry is uniquely defined by a bill of
lading number. Below is the data structure which is followed by a field explanation
list:
Data Structure
50 Records using SHPMNTFL.FIL as the data file and
represents shipments from 9/3/96 to 12/15/96.

explanation
Bill_of_Lading ASCII 1 5 AS “Bill of
Lading”
Bill_Date DATE 6 6 PICTURE “YYMMDD”
Customer_Name ASCII 12 24
Inventory_Number ASCII 36 3 AS “Inventory
Number”
Sales_Order_Number DATE 39 4
Ship_Cost NUMERIC 43 7 2 AS “Ship Cost”
Ship_Date DATE 50 6 PICTURE “YYMMDD”
WIDTH 6
Ship_Quantity NUMERIC 56 3 0 AS “Ship
Quantity”
Ship_Unit_Price NUMERIC 59 7 2 AS “Ship Unit
Cost”
Billing_Date COMPUTED AS “Billing
Date”
Bill_of_Lading Shipment report number.
Billing_Date Date shipment was billed to the customer.
Customer_Name The customer receiving the shipment and invoice.
Inventory_Number Inventory product number shipped.
Sales_Order_Number Sales order associated with shipment.
Ship_Cost Total cost of shipment.
Ship_Date Date of shipment.
Ship_Quantity Quantity shipped.
Ship_Unit_Price Unit price of product shipped.

Verification Batches
REVENUE_VERIFY
Executed prior to using the REVENUE_FILE to:
the response “0 data validity errors detected”. Please note
2 Total the open invoice amount - Agree the amount in the “Last Result”
window to the organization’s open invoice register (this amount is reported
after the command in the “Last Result” window).
3 Stratify all open invoice amounts for the period on invoice amount and
invoice date - These reports could be reviewed with management for their
reasonableness. Care should be taken with regard to large negative or
positive transactions which may need specific identification and review.
4 Selecting a sample of five open invoices to agree back to supporting

documentation or discussed with management to assess its accuracy -
Agree information per the file REVENUE_SAMP to the supporting
documentation. Please note, the number of sampled items can be adjusted
in the batch, if necessary.
batches, double-clicking on the REVENUE_VERIFY batch, and then clicking
of the last invoice of the file). This parameter is required to correctly apply the AGE
command to the Invoice_Date. If using the sample data provided with the
SET SAFETY OFF

OPEN REVENUE_FILE
Please note: The Paid_Date field has not been verified considering it has
dates of ‘19000101’. These dates are properly not considered valid by ACL
although they do serve a purpose, designating those invoices not paid as of the date
of the file.
VERIFY FIELDS Discount Credit_Limit Credit_Manager

Credit_Memo_Code Customer_Address Customer_City
Customer_Name Customer_State Customer_Zip
Invoice_Amount Invoice_Amount_Paid Invoice_Date
Invoice_Number Product_Code Salesperson_ID ERRORLIMIT
10
command or if there are less than five records in the file for sampling. If the data is
valid, processing will continue with REVENUE_VERIFY1 which is listed below.
COUNT IF Paid_Date=‘19000101’
DO REVENUE_VERIFY1 IF WRITE1=0 AND COUNT1>=5
PAUSE ‘BATCH TERMINATED - There are either no open invoice
items or less than five open invoice items in the file
for sampling purposes’ IF COUNT1<5
DELETE ALL OK
SET SAFETY ON
REVENUE_VERIFY1
COMMENT ‘THIS BATCH IS REFERENCED BY BATCH REVENUE_VERIFY

FURTHER DISCUSSION’
To total the open invoice amount balance for agreement to the entity’s open accounts
receivable report:

TOTAL Invoice_Amount IF Paid_Date=‘000101’
To stratify on the date of the open invoice amount:
AGE ON Invoice_Date CUTOFF AGE_DATE INTERVAL 0, 7, 14, 21,

30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Invoice_Amount TO SCREEN HEADER=‘Aging of
open invoice amounts on Invoice_Date’ IF
Paid_Date=‘19000101’
To stratify on the open invoice amount:
STRATIFY ON Invoice_Amount ACCUMULATE Invoice_Amount TO

SCREEN FREE 0,100, 1000, 5000, 10000, 50000, 100000,
500000, 1000000 IF Paid_Date=‘19000101’
HEADER=’Stratification on open invoice amount’
To select a sample of five open invoices for agreement to supporting documentation:
X=RAND(COUNT1)
SAMPLE ON RECORD RANDOM X NUMBER 5 POPULATION COUNT1
RECORD TO “REVENUE_SAMP” IF Paid_Date=‘19000101’
OPEN REVENUE_SAMP
SHIPMENT_VERIFY
Executed prior to using the SHIPMENT_FILE to:
the response “0 data validity errors detected”. Please note

2 Stratify on shipment cost and date - These reports could be reviewed with
management for their reasonableness. Care should be taken with regards to
large negative or positive transactions which may need specific
identification and review.
3 Selecting a sample of five bill of ladings to agree back to supporting

documentation or discussed with management to assess its accuracy -
Agree information per the file SHIP_SAMP to the supporting
documentation. Please note, the number of sampled items can be adjusted
in the batch, if necessary.
batches, double-clicking on the SHIPMENT_VERIFY batch, and then clicking
of the last invoice of the file). This parameter is required to allow the AGE()
function, as used to stratify on the Ship_Date, to function properly. If using the
sample data provided with the Toolkit, enter the date 12/31/96 in YYMMDD format
(i.e. 961231).
SET SAFETY OFF

OPEN SHIPMENT_FILE
Please note: The Billing_Date field has not been verified considering it
has dates of `000101`. These dates are properly not considered valid by ACL
although they do serve a purpose, designating those shipments not billed as of the
date of the file.
VERIFY FIELDS Bill_of_Lading Customer_Name

Inventory_Number Sales_Order_Number Ship_Cost
Ship_Date Ship_Quantity Ship_Unit_Price ERRORLIMIT 10
command or if there are fewer than five records in the file for sampling. If the data is
valid, processing will continue with SHIPMENT_VERIFY1 which is listed below.
COUNT
DO SHIPMENT_VERIFY1 IF WRITE1=0 AND COUNT1>=5

PAUSE ‘BATCH TERMINATED - There are either no open invoice
items or less than five open invoice items in the file
for sampling purposes’ IF COUNT1=0 OR COUNT1<5
DELETE ALL OK
SET SAFETY OFF
SHIPMENT_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCH SHIPMENT_VERIFY

To stratify the shipment cost on its date:
AGE ON Ship_Date CUTOFF AGE_DATE INTERVAL 0, 7, 14, 21, 30,

60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Ship_Cost TO SCREEN HEADER=‘Aging of cost on
shipment date’
To stratify on the shipment cost:
STRATIFY ON Ship_Cost ACCUMULATE Ship_Cost TO SCREEN FREE

0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 HEADER=’Stratification on shipment cost’
To select a sample of five bills of lading for agreement to supporting documentation:
X=RAND(COUNT1)
SAMPLE ON RECORD RANDOM X NUMBER 5 RECORD TO “SHIP_SAMP”
OPEN SHIP_SAMP

Stratify sales for unusual trends and Application 1
exceptions Batch: REVENUE_1
Novice
Overview
A first step in determining whether reported revenue and accounts receivable are
accurate and complete is to review their characteristics.
■ What is the relative size of customers?

■ When are sales at their highest and lowest points?
■ Are sales dependent on few products?
These are a few of the questions that can be answered by analyzing the following
stratifications.
The following fields, currently in the REVENUE_FILE as included with this

Toolkit, are required to execute the REVENUE_1 batch. Please note that throughout

the batch, instances when “Paid_Date=‘000101’” represent open invoices
considering there is no valid date when the invoice was paid.
Required
<Customer_Name>
<Invoice_Amount>
<Invoice_Date>
<Paid_Date>
<Product_Code>
REVENUE_VERIFY batch. Two stratifications in this batch (on invoice amount and
date) provide such a wide-angle focus of the activity that they are used in the
REVENUE_VERIFY batch as further explained in Chapter 3.
Batch
batches, double-clicking on the REVENUE_1 batch, and then clicking “Run” in the
of the last invoice in the file). This parameter is required to correctly apply the AGE
Toolkit, enter the date 12/28/96 in YYYYMMDD format (i.e.19961228).
SET SAFETY OFF

OPEN REVENUE_FILE

The following two classifications will be used in the stratifications that follow. Please
note the “IF Paid_Date=‘19000101’” is used to designate invoices not paid
to date.
GROUP
CLASSIFY ON Customer_Name ACCUMULATE Invoice_Amount TO
CUSTOMERS IF Paid_Date=‘19000101’
CLASSIFY ON Product_Code ACCUMULATE Invoice_Amount TO
PRODUCTS IF Paid_Date=‘19000101’
END
To stratify on accumulated customer invoice amounts (see the Audit Steps section
below for procedures to perform using the resulting report):
OPEN CUSTOMERS
SCREEN FREE 0,100, 1000, 5000, 10000, 50000, 100000,
500000, 1000000 HEADER=’Stratification on open customer
balance’

To stratify on invoice date (see the Audit Steps section below for procedures to
OPEN REVENUE_FILE
AGE ON Invoice_Date CUTOFF AGE_DATE INTERVAL 0, 7, 14, 21,
30, 60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Invoice_Amount TO SCREEN HEADER=‘Aging of
open invoice amounts on Invoice_Date’ IF
To stratify accumulated invoices on product type (see the Audit Steps section below
OPEN PRODUCTS
SCREEN FREE 0,100, 1000, 5000, 10000, 50000, 100000,
500000, 1000000 HEADER=‘Stratification on open invoices
by product code’
To stratify on invoice amount (see the Audit Steps section below for procedures to
OPEN REVENUE_FILE
SCREEN FREE 0,100, 1000, 5000, 10000, 50000, 100000,
500000, 1000000 IF Paid_Date=‘19000101’
HEADER=’Stratification on open invoice amount’
SET SAFETY ON
Audit Steps
Review on customer for:
■ large accounts where activity could be extracted and further reviewed (i.e. -
top five customers). For customers that comprise a high percentage of the

organization’s sales, examine the most recent accounts receivable aging to
assess your customer’s payment patterns and potential credit risk.
■ material customers to sample their corresponding credit authorization
documentation.
■ credit balances (see related testwork in Application 11 in this chapter).
Review on invoice date for:
■ a sense of the organization’s revenue generation throughout the year.

■ more active sales periods, deserving increased audit attention.
Review on product to:
■ understand the makeup, in product terms, of the period’s sales.

■ determine whether the organization is dependent on a limited number of
products.
Review on invoice amount for:
■ unreasonably large or small invoices which could be extracted and further

reviewed.
■ a multitude of small dollar invoices to assess the administrative burden of
processing small amounts (leading to possible consolidation of billing).
Helpful Hints
explained in the Helpful Hints section of Chapter 3, to select the appropriate
period for review.
of each invoice run’s data prior to processing may detect potential errors or
irregularities.

the coverages obtained in audit tests. For example, “95% of invoices greater
than $50,000, representing 62% of the total dollar revenue during 1995,
were found to be properly approved”.

Stratify cash receipts for unusual trends Application 2
and exceptions Batch: REVENUE_2
Novice
Overview
Cash is the water spring of the organization which, without adequate monitoring,
could dry up. Although there are better reports to understand customer payment
patterns (i.e. - Application 3 regarding days sales outstanding), the auditor should
perform an initial assessment based on the timing, size and business significance of
each receipt.

Toolkit, are required to execute the REVENUE_2 batch. Throughout the batch,
instances where Paid_Date<>‘000101’ represent paid invoices, that is, a valid
payment date exists.
Required
<Customer_Name>
<Invoice_Amount_Paid>
<Paid_Date>

<Product_Code>
REVENUE_VERIFY batch. The last stratification in this batch (on receipt size)
provides such a wide-angle focus of the activity, that it was used in the
REVENUE_VERIFY batch as further explained in Chapter 3.
Batch
When running this batch you will be prompted to enter the aging date (i.e. to the
date of the last invoice in the file). This parameter is required to correctly apply the
AGE command to the Paid_Date. If using the sample data provided with the
SET SAFETY OFF

OPEN REVENUE_FILE
The following two classifications will be used in the stratifications that follow. Please
note the “IF Paid_Date=‘19000101’” is used to designate invoices not paid
to date.
GROUP
CLASSIFY ON Customer_Name ACCUMULATE Invoice_Amount_Paid
TO CUSTOMERS IF Paid_Date<>‘19000101’
CLASSIFY ON Product_Code ACCUMULATE Invoice_Amount_Paid TO
PRODUCTS IF Paid_Date<>‘19000101’
END

To stratify on accumulated customer receipts (see the Audit Steps section below for
USE CUSTOMERS
STRATIFY ON Invoice_Amount_Paid ACCUMULATE
Invoice_Amount_Paid TO SCREEN FREE 0,100, 1000, 5000,
10000, 50000, 100000, 500000, 1000000
HEADER=’Stratification on Customer Balances Paid’
To stratify on receipt date (see the Audit Steps section below for procedures to
OPEN REVENUE_FILE
AGE ON Paid_Date CUTOFF AGE_DATE INTERVAL 0, 7, 14, 21, 30,
60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Invoice_Amount_Paid TO SCREEN HEADER=’Aging
on Paid_Date’ IF Paid_Date <> ‘19000101’
To stratify accumulated receipts on product type (see the Audit Steps section below
OPEN PRODUCTS
Invoice_Amount_Paid TO SCREEN FREE 0,100, 1000, 5000,
10000, 50000, 100000, 500000, 1000000
HEADER=‘Stratification of paid invoice amounts on
product code’
To stratify on receipt amount (see the Audit Steps section below for procedures to
OPEN REVENUE_FILE
Invoice_Amount_Paid TO SCREEN FREE 0, 100, 1000, 5000,
10000, 50000, 100000, 500000, 1000000

HEADER=’Stratification of invoice amount paid’ IF
Paid_Date <> ‘19000101’
SET SAFETY ON
Audit Steps
Review on customer for:
■ large payments which could be extracted and further reviewed (i.e. - top five
paying customers).
■ material customers to assess the organization’s dependency on a limited
number of customers.
■ credit balances (see related testwork in Application 10 in this chapter).
Review on receipt date for:
■ a sense of the organization’s receipt patterns throughout the year.

■ more active receiving periods that deserve increased audit attention.
Review on product to:
■ understand the makeup, in product terms, of the period’s receipts.

■ determine whether the organization is dependent on receiving cash from a
limited number of products.
Review on receipt amount for:
■ unreasonably large or small receipts which could be extracted and further

reviewed.
■ small payments to assess the administrative burden of processing small
amounts (leading to possible consolidation of billing).

Helpful Hints
explained in the Helpful Hints section of Chapter 3, to select the appropriate
period for review.
of each invoice run’s data prior to processing may detect potential errors or
irregularities.
the coverages obtained in audit tests. For example, “37% of receipts greater
than $100,000, representing 58% of the total dollar receipts during 1995,
were found to be accurately recorded”.

Notes

Calculate weighted days sales outstanding Application 3
(“DSO”) by customer, salesperson, and the Batch: REVENUE_3_C
entire organization
Batch: REVENUE_3_S
Advanced
Overview
One quick way to identify slow paying customers is to review the over-60-days and
over-90-days categories in the accounts receivable aging report. The only problems
with this approach are that (a) it is not weighted towards higher dollar invoices,
requiring further manual analysis; and (b) it does not display paid invoices, but
rather those still outstanding. DSO calculations are normally performed using
various averaging techniques (i.e. 365 days / sales turnover) that, at times, can
distort the actual results. Only through weighting on payment amount can the truth
be found with regard to the timing of cash receipts.


Toolkit, are required to execute the REVENUE_3 batches. (These batches will
process fully paid invoices. Therefore, the Invoice_Amount_Paid field acts as
the customer receipt in the DSO calculation as further explained in Chapter 3.):
Required
<Customer_Name>
<Discount>
<Invoice_Amount_Paid>
<Invoice_Date>
<Paid_Date>
<Salesperson_ID>
REVENUE_VERIFY batch.
Batch
batches, and double-clicking on the appropriate batch. Click on “REVENUE_3_C”
for DSO calculation on customer and “REVENUE_3_S” for DSO calculation on
salesperson. Then click “Run” in the resulting Message box.
SET SAFETY OFF

OPEN REVENUE_FILE
The following fields will calculate interest lost for customers not paying invoices at
30, 45, and 60 days assuming a 7% rate of interest. If the rate of interest you wish to
use is different than this percentage, update the three field definitions below (see
.07 in the beginning of each of the definitions). Also, please note that the division

of certain fields is multiplied by 1.000 in the below field definition. This is completed
to avoid any calculation inaccuracies due to the rounding of minuscule percentages.

(.07*Invoice_Amount_Paid)*(((1.000*(Paid_Date-
Invoice_Date))-30)/360) IF (Paid_Date-Invoice_Date)>30
0.000
0.000
0.000
DEFINE FIELD DSO COMPUTED (Paid_Date-Invoice_Date)
The field below will become the total payments made by the customer after various
sorting and summarizations which follow.
DEFINE FIELD Sum_of_payments COMPUTED

(Invoice_Amount_Paid)
Prior to sorting, the batch requires that only paid invoices with valid invoice dates
and amounts be processed. Otherwise, inaccurate DSO calculations or division by
zero may occur. The batch also does not process any invoices with a financial
discount which would artificially lower the DSO.
SORT ON Customer_Name TO SORTED IF Invoice_Date<>`000101`

AND Paid_Date<>`000101` AND Invoice_Amount_Paid<>0 AND
Discount=0
OPEN SORTED
SUMMARIZE ON Customer_Name ACCUMULATE Sum_of_Payments TO
“SORTED1”

JOIN PKEY Customer_Name FIELDS DSO Invoice_Amount_Paid
Paid_Date Invoice_Date Customer_Name SKEY
Customer_Name WITH Sum_of_Payments PRIMARY TO “DSOSUM”
CLOSE SECONDARY
OPEN DSOSUM
The previous commands have essentially created a file with a record for each receipt
amount along with the entire customer payments (Sum_of_Payments). Using
these amounts, a weighting of the DSO will be computed. Review this example to
understand how the Customer_DSO field is defined. Then review the
Customer_Sum_DSO file, completed later in the batch, for the final results:
Customer Name Invoice Sum of DSO Customer DSO

Amount Paid Payments
(A) (B) C (A)/(B)*(C)
XYZ Corporation 1,000.00 10,000.00 30 3
XYZ Corporation 2,500.00 10,000.00 28 7
XYZ Corporation 2,500.00 10,000.00 32 8
XYZ Corporation 4,000.00 10,000.00 10 4
Weighted DSO 20
DEFINE FIELD Customer_DSO COMPUTED

(DSO*(1.00000*Invoice_Amount_Paid/Sum_of_Payments)) IF
Invoice_Date<>‘000101’ AND Paid_Date<>‘000101’ AND
Invoice_Amount_Paid<>0

0.00000
SUMMARIZE ON Customer_Name Accumulate Customer_DSO
Invoice_Amount_Paid Interest_Lost_30 Interest_Lost_45
Interest_Lost_60 OTHER Customer_Name Sum_of_Payments
TO Customer_Sum_DSO IF Invoice_Amount_Paid>0 AND
Sum_of_Payments>0
The last two requirements of the previous command are essential to ensure that no
division by zero occurs in the weighted days sales outstanding calculation.
DELETE Customer_DSO
OPEN REVENUE_FILE
DELETE DSO OK
DELETE Sum_of_payments OK
DELETE ALL OK
OPEN Customer_Sum_DSO
It may be helpful to set the printer to “Landscape” prior to batch execution so that
the four fields accumulated below will appear on the final printed report.

To stratify on the weighted days sales outstanding (see the Audit Steps section below
STRATIFY ON Customer_DSO ACCUMULATE Invoice_Amount_Paid

Interest_Lost_30 Interest_Lost_45 Interest_Lost_60
MINIMUM 0 MAXIMUM 100 FREE 1,7,14,21,30,60,90 TO SCREEN
HEADER=’Stratification on DSO with interest lost’
The remainder of the batch will calculate the weighted average DSO for the
organization. The final result is presented in the Last Result window as being
the total of the Total_DSO field.
TOTAL Invoice_Amount_Paid
DEFINE FIELD Total_DSO COMPUTED
(Customer_DSO*(1.00000*Invoice_Amount_Paid/TOTAL1)) IF
Invoice_Amount_Paid<>0
0.00000
TOTAL Total_DSO

SET SAFETY ON
Audit Steps
In this section, the auditor is mainly concerned with the proper valuation of the
accounts receivable balance and with understanding organizational cash receipt
trends so as to provide improvements. Such recommendations could be made not
only to credit but also sales management, depending on the batch executed.
To achieve this objective, review the following additional reports:
■ 25 worst offenders (defined as those with the lowest DSO) - Sort on the
Customer_DSO field in an ascending fashion and extract if
RECNO()<25. Remember that Customer_DSO can either be related to
the customer or the salesperson. Therefore, these reports will identify the
customers “taking the store” or those salespersons who are “holding the
door as they leave” depending on the batch that was executed
(REVENUE_3_C or REVENUE_3_S, respectively). This report can be
used to challenge credit management’s assumptions relative to the initial
approval of sales orders, as well as to pinpoint those customers requiring
added attention.
■ 25 aggregate customer/salesperson receipts - Sort on the
Invoice_Amount_Paid field in a descending fashion and extract if
RECNO()<25.
One last note is that payment timing cannot be analyzed in a vacuum. Depending on
the circumstances, large customers are generally provided additional room for
making payment to ensure a long term relationship. The organization should not
“bite off its nose to spite its face” by not paying attention to this special relationship.

Notes

Review the sequence of invoices, sales Application 4
orders and shipping documents for gaps Batch: REVENUE_4
Novice
Overview
Revenue generation activities should not be hampered with incomplete processing.

Gaps in the document sequence can cause the organization to:
■ lack the appropriate cash to sustain operations

■ provide inadequate shipments equating to poor quality service
■ find that assets have been misappropriated.

Toolkit, are required to execute the REVENUE_4 batch.
Required
<Invoice_Number>

The following fields, currently in the SHIPMENT_FILE as included with this
Toolkit, are also required.
Required
<Bill_of_Lading>
<Sales_Order_Number>
<Ship_Quantity>
REVENUE_VERIFY and SHIPMENT_VERIFY batches.
Batch
SET SAFETY OFF
To sequence gaps on invoice numbers (see the Audit Steps section below for
OPEN REVENUE_FILE
GAPS ON Invoice_Number ERRORLIMIT 10 TO SCREEN PRESORT
To sequence gaps on sales order numbers (see the Audit Steps section below for
OPEN SHIPMENT_FILE
CLASSIFY ON Sales_Order_Number ACCUMULATE Ship_Quantity TO
CLASSIFIED
OPEN CLASSIFIED
GAPS ON Sales_Order_Number ERRORLIMIT 10 TO SCREEN PRESORT

To sequence gaps in bill of ladings (see the Audit Steps section below for procedures
to perform using the resulting report):
OPEN SHIPMENT_FILE
GAPS ON Bill_of_Lading ERRORLIMIT 10 TO SCREEN PRESORT
SET SAFETY ON
Audit Steps
What are the potential results of sequence gaps?
■ In invoices/bill of lading numbers - Lost revenues, forfeited inventory and

poor customer service.
■ In sales orders - Lost revenues and poor customer service.
As an initial step, attempt to distinguish trends in the gaps (i.e. - a repeated

occurrence of ten gaps throughout the report). Then identify unique gaps (i.e. - 249
gaps in the sales order sequence) for inquiry with management and review of
established procedures. The testwork should answer the following questions:
■ What procedures are in place to document and approve all gaps in the
■ Are voided checks properly documented with the signature area removed to
prevent re-use?
■ What procedures are in place to document/approve all gaps in the
■ Are voided documents properly recorded with the signature area removed
to prevent re-use?

Notes

Calculate interest lost for shipments not Application 5
billed to date Batch: REVENUE_5
Intermediate
Calculate interest lost for the time lag Application 6

between the shipment being made and Batch: REVENUE_6
the billing being processed Intermediate
List shipments already billed with interest lost due to the time lag between the date of
shipment and the date of invoicing.
Overview
As the old adage goes, the faster you invoice your customers, the quicker they are
likely to pay the bill. Although this is not always the case, depending on the terms
afforded to the customer or the existing relationship, it stands to reason that doing so
can only increase the organization’s chances that payment will be made in a swift
manner. Apart from the interest lost, shipments not billed are also a clear sign of
inefficiencies within the invoicing process. Left unattended, these inefficiencies
could lead to inferior customer service and inadequate cash flow.


Toolkit, are required to execute the following batch.
Required
<Bill_of_Lading>
<Billing_Date>
<Customer_Name>
<Ship_Cost>
<Ship_Date>
<Ship_Price>
<Ship_Quantity>
To test the validity of the data used in this application, you should execute the
SHIPMENT_VERIFY batch described earlier in this chapter.
Batch
batches, double-clicking on the REVENUE_5_6 batch, and then clicking “Run” in
the resulting Message box. To ensure the accuracy of this batch processing, be sure to
change the system date to the date of the last shipment in the file prior to opening
ACL. (If using the data supplied with the Toolkit, use 12/15/96).
date of the last shipment in the file). This parameter is required to correctly apply the
AGE command to the Ship_Date. If using the sample data provided with the
SET SAFETY OFF


The first portion of this batch will complete Application 5. The batch assumes that all
shipments made have been priced, have a valid shipping date and have not been
billed which is verified using three “IF” requirements in the extraction below:
OPEN SHIPMENT_FILE
EXTRACT TO NOT_BILLED IF Billing_Date=‘19000101’ AND
Ship_Date<>‘000101’ and Ship_Cost<>0 FIELDS
Bill_of_Lading Billing_Date Customer_Name Ship_Date
Ship_Cost Ship_Unit_Price Ship_Quantity
OPEN NOT_BILLED
To calculate potential interest lost for not billing shipments from the date of
shipment, assume a 7% rate of interest. If the rate of interest you wish to use is higher
or lower than this percentage, update the computed field definition below.

(Ship_Cost)*(1.000*AGE(Ship_Date)/360)*.07
To stratify on the shipment date for assessment of the interest lost for not billing
customers who have been shipped product:

60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Ship_Cost Interest_Lost TO SCREEN

HEADER=’Aging on Shipping Date with Interest Lost for
No Billing’
This second portion of the batch will complete Application 6. The batch assumes that
all shipments made have been priced and have valid shipping and billing dates which
is verified using three “IF” requirements in the extraction below:
OPEN SHIPMENT_FILE
EXTRACT TO BILL_TIME IF Billing_Date<>‘19000101’ AND
Ship_Date<>‘19000101’ AND Ship_Cost<>0 FIELDS
Bill_of_Lading Billing_Date Customer_Name Ship_Date
Ship_Cost Ship_Unit_Price Ship_Quantity
OPEN BILL_TIME
To calculate a potential interest lost for not billing shipments from the date of
shipment, assuming a 7% rate of interest. If the rate of interest you wish to use is
higher or lower than this percentage, update the field definition.

(Ship_Cost)*(1.000*AGE(Ship_Date,Billing_Date)/360)*.07

To stratify on the shipment date for assessment of the interest lost due to the time lag
between when the product was shipped and the customer was billed:

60, 90, 120, 150, 180, 210, 240, 270, 300, 330, 360
ACCUMULATE Ship_Cost Interest_Lost TO SCREEN
HEADER=’Stratification on Shipment Date with Interest
Lost for Billing Time Lag’
SET SAFETY ON
Audit Steps
The invoicing procedures should be reviewed as an initial step in understanding the

affiliated process. It is common for shipments to not be billed due because:
■ no price has been established in the system

■ the customer has not been set up properly to execute invoicing (i.e. - no
billing address)
■ customer pickup of a preloaded shipment is expected at a later date (which
does not constitute a valid unbilled shipment considering the product has
not left the company premises)
■ invoices have been lost leading to gaps in the invoice sequence (see
Application 4 for the sequencing testwork for such gaps).
The costs to improve the process must be weighed against the expected benefits due
to the increased time value of money. Such costs could include employee training,
additional personnel to ensure a more timely billing, outsourcing of specified
functions and mechanisms to monitor the gaps in invoice sequence. The two
stratifications provide a high level time value analysis which can be later verified by
analyzing the two files NOT_BILLED (Application 5) and BILL_TIME
(Application 6).
Further, using these two files, it may be beneficial to “Classify” in ACL on

Customer_Name and accumulate the Ship_Cost to identify those customers

who are frequently not billed. Although it may appear beneficial from the customer’s
perspective that billings are not made timely, in fact the extra effort on the
customer’s part to reconcile the late bills may outweigh these advantages. Such
developments should be monitored closely by the auditor

Recalculate the aging of accounts Application 7
receivables Batch: REVENUE_7
Novice
Overview
An improperly aged accounts receivable report may lead management to make

inappropriate decisions regarding the valuation of the reported balance. One
method to test if the accounts receivable report is aged appropriately is to select a
random number of outstanding invoices, recalculate the aging category to which
they relate and trace them back to the report. But why test only a few invoices in a
manual recalculation when you can verify the entire sum of invoices in an automated
fashion? The answer is quite clear and follows below.

Required
<Invoice_Date>
<Invoice_Amount>
<Paid_Date>

Batch
date of the printed report). This parameter is required to correctly apply the AGE
Also, obtain a file with the same date as the printed report. This may entail using a
backup of the period end REVENUE_FILE or using a file as of today which can
then be matched to today’s report.
SET SAFETY OFF

OPEN REVENUE_FILE
DIALOG (DIALOG TITLE "User Dialog" WIDTH 482 HEIGHT
154 ) (BUTTONSET TITLE "&OK;&Cancel" AT 216,84
DEFAULT 1 ) (TEXT TITLE "Enter the aging date in
YYYYMMDD order:" AT 36,16 ) (EDIT TO "AGE_DATE" AT
36,48 WIDTH 151 )
The “IF” Statement below (selecting all items without a Paid_Date) will ensure
that only open items are aged:
AGE ON Invoice_Date CUTOFF AGE_DATE INTERVAL

0,30,60,90,120,150,180,210,240,270,300,330,360,10000
ACCUMULATE Invoice_Amount TO SCREEN IF
SET SAFETY ON

Audit Steps
Agree the totals per the aging categories in the ACL printed report to the aging
categories in the organization’s printed report. To gain additional assurance, select a
small sample of invoices, recalculate the aging and match it to the appropriate
category in the printed report.

Notes

Report customers with old and large Application 8
account balances Batch: REVENUE_8
Intermediate
Overview
In assessing the value of the period-end receivables balance, it is a common tactic to

isolate those customers possessing large, old balances. To this end, the auditor can
apply manual analysis to printed reports or execute a programmed search, as
explained below.

Required
<Customer_Name>
<Invoice_Date>
<Invoice_Amount>
<Paid_Date>

Batch
To ensure the accuracy of this batch processing, obtain a REVENUE_FILE file with
a date at the end of the period you wish to review. (If using the sample data provided
with the Toolkit, use 12/28/96.)
SET SAFETY OFF

ACCEPT ‘Date before which any data will be extracted
(enter in a yyyymmdd format):’ TO STARTDATE
ACCEPT ‘Date after which any data will be extracted (enter
in a yyyymmdd format):’ TO ENDDATE
For example, if it is 12/31/96 and you wish to extract all customers that have a
material balance (which will be established in the next acceptance) between 90 and
180 days old, enter 961001 at the first prompt and 960701 at the second prompt.
ACCEPT ‘Amount of customer balance in the specified time

period over which to extract data’ TO OVER
OPEN REVENUE_FILE
To filter customer and invoice information based on user date requirements (the
resulting file will be classified later in the batch for analysis purposes):
SET FILTER TO Invoice_Date<CTOD(STARTDATE) AND

Invoice_Date>CTOD(ENDDATE) AND Paid_Date=‘19000101’
The classification command is used to finish off the batch providing the auditor with
the “Percentage of ” fields. Such additions allow for a speedy analysis of the relative

size of each old paying customer balance, as well as, report the magnitude of invoices
which may require detailed analysis.
To classify invoice amounts on the customer name:
CLASSIFY ON Customer_Name to CLASSIFY ACCUMULATE

Invoice_Amount TO CLASSIFIED
OPEN CLASSIFIED
To extract customer, invoice and percentage information based on user amount

requirement. Please note the percentages listed in the new file will not equal 100%
since they are only an extracted portion of the CLASSIFIED above. (See the Audit
EXTRACT RECORD IF Invoice_Amount>VALUE(OVER,0) TO

OLD_BALANCES
OPEN OLD_BALANCES
DELETE ALL OK
SET SAFETY ON
Audit Steps
Discuss the resulting report with credit management to determine whether such
balances are expected to be paid. Also review the CUSTOMERS file as created in
Application 2 (summarization of customer cash receipts) to gain an appreciation for
the levels of cash flow received from these customers, especially that which was
received recently.

Notes

Identify customers with no set credit limit Application 9
Batch: REVENUE_9
Novice
Identify customers who have exceeded Application 10

their credit limit Batch: REVENUE_10
Novice
Overview
Credit limits are set to prevent a disaster (the extension of products and services
without any remuneration). The problem is that the credit manager routinely uses
his/her internal compass in lieu of established credit limits. The auditor, upon
encountering this strategy, should assess this potential effects on the organization.


Toolkit, are required to execute the REVENUE_9_10 batch.
Required
<Credit_Limit>
<Customer_Name>
<Invoice_Amount>
<Paid_Date>
Batch
batches, double-clicking on the REVENUE_9_10 batch, and then clicking “Run” in
SET SAFETY OFF

OPEN REVENUE_FILE
To sort and summarize open invoices on the customer name for use in the related
extractions and stratifications appearing later in the batch. For purposes of the
sample data supplied with the Toolkit, invoices are considered open if they do not
possess a paid date as required below:
SUMMARIZE ON Customer_Name ACCUMULATE Invoice_Amount OTHER

Credit_Limit TO CREDIT_CHECK IF Paid_Date=’19000101’
PRESORT
OPEN CREDIT_CHECK

To extract and stratify the invoice balance for all customers with a credit limit equal
to zero (see the Audit Steps section below for procedures to perform using the
resulting file):
EXTRACT RECORD IF Credit_Limit=0 TO NO_CREDIT

OPEN NO_CREDIT
STRATIFY ON Invoice_Amount ACCUMULATE Invoice_Amount FREE
0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 TO SCREEN HEADER=’Stratification on customer
balance without credit’
OPEN CREDIT_CHECK
To extract and stratify the invoice balance for all customer balances over the
established credit limit (see the Audit Steps section below for procedures to perform
EXTRACT RECORD IF (Invoice_Amount-Credit_Limit)>0 TO

OVER_CREDIT
OPEN OVER_CREDIT
STRATIFY ON (Invoice_Amount-Credit_Limit) ACCUMULATE
(Invoice_Amount-Credit_Limit) FREE 0,100, 1000, 5000,
10000, 50000, 100000, 500000, 1000000 TO SCREEN
HEADER=Stratification on customer balance over the
credit limit'
SET SAFETY ON

Audit Steps
The auditor should be concerned if the following exists:
1 Credit limits are rarely set or followed - At this point, the auditor should
decide whether or not to recommend that credit limits be set. Any over-
extension will be well presented in the two stratifications or, if detail is
required, in the NO_CREDIT or OVER_CREDIT files.
2 Credit limits are set for the majority of customers but there are
numerous occurrences of customers exceeding them - Assuming such
events are properly approved, preferably through written authorization,
there is little cause for alarm. If there is typically no authorization when
limits are exceeded, the situation is actually somewhat worse than in (1)
above, as the setting o f meaningless limits tends to create a false impression
of control. As with any review of credit limits, the customer payment
patterns should be closely monitored. These can be summarized through
the CUSTOMERS.FIL file (created in Application 2 -summarization of
customer cash receipts).

Summarize credit memos on customer, Application 11
credit manager and type for exceptions Batch: REVENUE_11
and unusual trends Novice
Overview
Customer credit memos are written for various events (i.e. - price adjustments) after
payment. Most of these memos call into question the effectiveness of credit
controlsm as many of the underlying events should have been detected prior to
payment. Summarization of such activity by the credit manager, customer and type
of memo can point to trends which may require the strengthening of these controls.
Accounts Receivables are Accurate, Complete and Valued Properly


Toolkit, are required to execute the REVENUE_11 batch. The following codes,
which are not all-inclusive, are presented in the field <Credit_Memo_Code>:
■ BE - billing errors
■ DP - duplicate payments
■ FR - freight adjustment
■ NA - no credit memo code applicable
■ PA - price adjustments
■ PR - product returns
■ TX - tax adjustment
Required
<Invoice_Amount>
<Credit Memo Code>
<Customer_Name>
<Credit_Manager>
Batch
batches, double-clicking on the REVENUE_11 batch, and then clicking “Run” in
SET SAFETY OFF

DELETE ALL OK

OPEN REVENUE_FILE
To classify credit memos on customer name (see the Audit Steps section below for
CLASSIFY ON Customer_Name ACCUMULATE Invoice_Amount IF

Invoice_Amount<0 TO CLASS_CUS_CR
To classify credit memos on the established codes (see the Audit Steps section below
CLASSIFY ON Credit_Memo_Code ACCUMULATE Invoice_Amount IF

Invoice_Amount<0 TO CLASS_CODE_CR
To classify credit memos on the credit manager (see the Audit Steps section below for
CLASSIFY ON Credit_Manager ACCUMULATE Invoice_Amount IF

Invoice_Amount<0 TO CLASS_CREDMGR_CR
To summarize first on the customer and then on the credit codes recorded for
additional analysis of the types of codes by customer (see the Audit Steps section
SUMMARIZE ON Customer_Name Credit_Memo_Code ACCUMULATE

Invoice_Amount TO SUMM_CUS_CD_CR IF
Credit_Memo_Code<>'NA' PRESORT
SET SAFETY ON
The following files are created:
CLASS_CUS_CR - Credit memos classified on customer.
CLASS_CODE_CR - Credit memos classified on code.
CLASS_CREDMGR_CR - Credit memos classified on the credit manager.
SUMM_VEN_CD_CR - Credit memos summarized on customer and then by

code.

Audit Steps
The following audit tests should be performed for the various types of credit memos
received from customers:
■ BE - Billing errors - Inquire of management and observe the matching

process of sales orders and shipping reports to invoices. Determine whether
a lapse of controls existed leading to improper invoicing.
■ DP - Duplicate payments - Determine whether there is a system control
disallowing receipt of payment for equivalent customer, amount and
invoice. If not, suggest the application of the Duplicates command. (See the
concepts presented in Applications 15, 16 and 17 in Chapter 5, including
reports related to duplicate payments.)
■ FR - Freight adjustment - See procedures for Billing Errors above and apply
to the events initiating a freight price error.
■ PA - Price adjustments - See procedures for Billing Errors above and apply
to the events initiating a pricing error.
■ PR - Product returns - Inquire of management and observe the quality
control process to ensure that inventory is in good working condition prior
to shipment, so as to minimize the extent of product returns. Further,
review the handling of returned goods to assess procedures relative to
disposal or repair.
■ TX - Tax adjustment - See procedures for Billing Errors above and apply to
the events initiating a tax error. Also review the established tax calculations
within the accounting system.
Trends in customer credit memos could be analyzed based on:
■ the customer, which could highlight customers with numerous pricing,

billing or quality issues
■ the type of credit memo, to assist in the calculation of administrative burden
created from such transactions
■ the credit manager, possibly signifying a liberal policy of credit memo
issuance.

Identify all customers with credit balances Application 12
Batch: REVENUE_12
Novice
Overview
Although it is possible to provide customers with a credit after they have paid their
balance in full, it should be the exception rather than the norm. Such credits could be
for price adjustments, billing errors, duplicate payments, product returns after
payment, freight and tax adjustments. All of these listed items call into question the
controls surrounding the review process considering most of these credits should
have been detected prior to payment.


Toolkit, are required to execute the REVENUE_12 batch:
Required
<Customer_Name>
<Invoice_Amount>
Batch
SET SAFETY OFF

OPEN REVENUE_FILE
To detect all customer balances less than zero (see the Audit Steps section below for
CLASSIFY ON Customer_Name ACCUMULATE Invoice_Amount TO

CLASSIFIED
OPEN CLASSIFIED
EXTRACT ALL IF Invoice_Amount<0 TO CUS_CR_BAL
OPEN CUS_CR_BAL
SET SAFETY ON

Audit Steps
See the Audit Steps section in Application 11 in this chapter.

Notes

Select a Monetary Unit Sample of customer Application 13
invoices and automatically create Batch: REVENUE_13
confirmation requests Intermediate
Overview
Confirmations provide external evidence to support the existence and accuracy of

internally reported balances. This test comes into play most often in the
confirmation of receivable balances. With this batch, you will no longer need to type
each confirmation. Instead, let the Mail Merge feature of Word for Windows do it for
you with data supplied by ACL.

Toolkit, are required to execute the following batch:
Required
<Customer_Address>
<Customer_City>
<Customer_Name>

<Customer_State>
<Customer_Zip>
<Invoice_Amount>
<Invoice_Date>
<Invoice Number>
<Paid_Date>
Since this application is testing the existence and accuracy of the receivable balance
as of a given date, this balance, per the entity’s records, should agree with the file
used prior to processing. To calculate the total open receivables per the file, type the
command “TOTAL Invoice_Amount IF Paid_Date<>‘19000101’” at
the command and log prompt.
Batch
The sample that follows uses invoices as the sampling units. In other words,
individual invoices are sampled on a monetary-unit, fixed-interval basis rather than
entire customer balances. This provides the same level of statistical audit coverage
over the period end balance. For a more detailed explanation of the sampling
features in ACL for Windows, consult the Reference Manual which accompanies the
software.
■ Agree the balance per the entity’s records to the file used prior to processing.
To calculate the total open payables per the REVENUE_FILE.FIL file,
type the command “TOTAL Invoice_Amount IF Paid_Date=‘19000101’” at
the command and log prompt. This balance can also be used as the
Population variable in the Sampling command below.
sample size. Remember that only open invoices (those with a Paid_Date

of ‘19000101’) should be sampled. Once calculated, note the
INTERVAL value which will be accepted by the batch.
■ Determine whether significant transactions, which can be identified in the
batch by entering a CUTOFF value, will be reviewed separately. Prior to
the value. (The stratifications should provide you with the information
necessary to decide where the cutoff should originate.) Please note that if no
value is set, ACL will automatically select any balance greater than the
INTERVAL value, as consistent with Monetary Unit Sampling.
SET SAFETY OFF

OPEN REVENUE_FILE
To accept all information necessary for a MUS sample:

SAMPLE ON Invoice_Amount INTERVAL INT FIXED START CUTOFF

CUT RECORD TO “SAMPLE AR” IF Paid_Date=‘19000101’
OPEN SAMPLE_AR
To export the information into a Microsoft Word mail merge format, the following
command is issued. This format allows the merging of vendor data, as created by
ACL, with a blank confirmation form in the Microsoft Word application. ACL for
Windows currently supports mail merge with Word and WordPerfect:
GROUP

EXPORT FIELDS Invoice_Amount Invoice_Date Invoice_Number
Customer_Address Customer_City Customer_Name
Customer_State Customer_Zip WORD TO MAILAR.DOC
The following command is executed to create a log, in Excel format, which acts as a
documented monitoring tool for those confirmations received or still outstanding:
EXPORT FIELDS Invoice_Amount Invoice_Date Invoice Number

Customer_State Customer_Zip EXCEL TO ARLOG.XLS
END
DELETE ALL OK
SET SAFETY ON
Audit Steps
Mail and log confirmations upon receipt. Any confirmations not returned or
returned undelivered should be investigated. Second requests should be mailed as
needed. If responses are not expected to be received by period end, additional
procedures should be considered such as invoice or (after period end) check
payment observation.
A quick way to determine if check payments were made is to join the

SAMPLE_AR.FIL with an after period end REVENUE_FILE.FIL as follows:
SET SAFETY OFF

OPEN REVENUE_FILE
SORT ON Customer_Name Invoice_Number TO SORTED IF
Paid_Date<>‘19000101’
OPEN SAMPLE_AR.FIL
SORT ON Customer_Name Invoice_Number TO SORTED1
OPEN SORTED1

JOIN PKEY Customer_Name Invoice_Number FIELDS
Invoice_Amount Invoice_Date Invoice_Number
Customer_State Customer_Zip SKEY Customer_Name
Invoice_Number WITH Paid_Date TO “ARPAID”
CLOSE SECONDARY
OPEN ARPAID
SET SAFETY OFF
Once the confirmations and additional testwork are complete, use the Evaluate
command in ACL (select “Sampling” from the menu bar and choose
“Evaluate”). This will calculate the “Most Likely Error” and “Upper Error Limit”
as further explained in the ACL for Windows User Guide, Reference Manual, or online
help.

Notes

Analyze discounts taken by customers after Application 14
the discount due date Batch: REVENUE_14
Intermediate
Overview
Many companies believe that tracking of discounts taken by customers after the
discount due date is a costly, nonbeneficial task. Therefore, late discounted
payments are considered paid in full invoices by Collection Departments. On some
counts, an auditor may agree with this decision; however, a review of such activity
(even if only at a customer level) may prove tracking to be efficient and beneficial
after all.

Toolkit, are required to execute the REVENUE_14 batch. Please note the sample
data assumes the discount terms to be ten days from the invoice date:
Required
<Customer_Name>
<Discount>
<Invoice_Amount>
<Invoice_Date>

<Paid_Date>
<Salesperson_ID>
Batch
SET SAFETY OFF

OPEN REVENUE_FILE
SORT ON Customer_Name TO SORTED IF Discount>0 AND
((Invoice_Date+10)<Paid_Date)
OPEN SORTED
STRATIFY ON (Paid_Date-Invoice_Date) ACCUMULATE Discount
MINIMUM 0 MAXIMUM 1000 FREE
14,20,25,30,40,50,60,100,365, TO SCREEN HEADER=‘Days
from discount date invoice was paid with discount
taken’
To summarize and stratify discounts taken after the due date by customer (see the
Audit Steps section below for procedures to perform using the resulting file and
report):
SUMMARIZE ON Customer_Name ACCUMULATE Discount

Invoice_Amount OTHER Salesperson_ID TO “DISCOUNT_SUM”
OPEN DISCOUNT_SUM
STRATIFY ON Discount ACCUMULATE Discount MINIMUM 0 MAXIMUM
100000 FREE 100,1000,10000,20000,50000 TO SCREEN
HEADER=‘Stratification on total discounts by customer
after discount due date’

To summarize and stratify discounts taken after the due date by salesperson
customer (see the Audit Steps section below for procedures to perform using the
resulting file and report):
SUMMARIZE ON Salesperson_ID ACCUMULATE Discount

Invoice_Amount OTHER TO “SALESPER_DISC_SUM” PRESORT
OPEN SALESPER_DISC_SUM
STRATIFY ON Discount ACCUMULATE Discount MINIMUM 0 MAXIMUM
100000 FREE 100,1000,10000,20000,50000 TO SCREEN
HEADER=‘Stratification on total discounts by
salesperson after discount due date’
SET SAFETY ON
Audit Steps
Review any existing controls relative to the approval by credit or collection

management of such payments. At a minimum, discuss the resulting reports with
management focusing mostly on the dollar extent of the lateness. If the appraised
amount is significant, consider the following options:
■ Maintain the discount, expected to have been paid by the customer, in the
customer’s account and communicate this though periodic statements or
dunning notices.
■ Evaluate whether the company should offer discounted payment terms to
the customer in the future.
■ Assess whether the customer’s future prices should be raised to compensate
for the discounts taken.
■ Communicate to sales and credit management that they must judge
customers carefully when extending discounted terms.

Notes

Inventory Management Chapter 8
Two critical questions an auditor will ask when approaching inventory are:
■ Is it there (existence and accuracy assertions)?

■ Is there good reason for it to still be there (valuation assertion)?
The applications provided in this chapter will address these concerns and allow
management to monitor the performance of this particular function. With estimates
of total final product cost, on average, comprised of 50 percent purchased materials,
inventory should never be overlooked for cost savings.
Inventory Objectives
The following is a list of specific audit objectives for the inventory function along
with the applicable report numbers. The auditor should attempt to obtain
reasonable assurance that the following objectives have been achieved by the
organization:
Inventory Management Activities are Operating Effectively and Efficiently
Report numbers: 1, 2, 3, 4, 6, 7, 8, 9 10
Inventory Exists and is Recorded Accurately and Completely
Report number: 1, 5, 6, 7, 8, 9, 10
Inventory Valuation is Appropriate

Inventory Management Applications
level of difficulty are referenced after each application.
1 Stratify inventory costs for unusual trends and exceptions. (2) Novice
2 Calculate inventory turnover and assess it in relation to part lead times.

(1) Advanced
3 Identify slow moving inventory parts. (2) Intermediate
4 Compare unit costs to current sales prices for lower of cost or market
testing. (1) Advanced
5 Select a Monetary Unit Sample of inventory parts. (1) Intermediate
6 Summarize inventory adjustments for unusual trends and exceptions.

(1) Novice
7 List parts with an extended cost, unit cost or quantity less than zero.
(1) Novice
8 Identify inventory not counted in a specified period of time.

(1) Intermediate
9 Identify parts that have never been counted. (1) Intermediate
10 Stratify parts based on the last date they were counted. (1) Novice

Inventory Management Data File
(INVENTORY_FILE) - This file consists of 50 inventory parts at 12/31/96.
Each entry is uniquely defined by an inventory number and includes a multitude of

historical data relative to each part’s usage, receipts and adjustments.
Below is the data structure which is followed by a field explanation list:
Data Structure
50 Records using NVNTRYFL as the input file and
representing the inventory at 12/31/96.
Field Format Start Length Decimal Addtl. format

explanation
Adjust_Curr_Per NUMERIC 1 2 0
Adjust_Prl_Per NUMERIC 3 2 0
Adjust_Pr2_Per NUMERIC 5 2 0
Annual_Turnover ACL 7 12 3

Begin_Quantity ACL 19 12 0
Company_Code ASCII 31 1
Inventory_Number ASCII 32 3
Last_Date_Counted DATE 35 8 PICTURE
“YYYYMMDD” AS
“Last Date
Counted”
Last_Receipt_Date DATE 43 6 PICTURE
“yymmdd” AS
“Last Receipt
Date” WIDTH 6
Lead_Time NUMERIC 49 2 0 AS “Lead Time”
PO_Date_1 DATE 51 6 PICTURE
“yymmdd” WIDTH 6
PO_Date_2 DATE 57 6 PICTURE
“yymmdd” WIDTH 6
PO_Number_1 ASCII 63 5
PO_Number_2 ASCII 68 5
PO_Price_1 NUMERIC 73 7 2
PO_Price_2 NUMERIC 80 7 2
PO_PRICE_CHG ACL 87 12 2
Quantity_On_Hand NUMERIC 99 3 0
Receipt_Curr_Per NUMERIC 102 3 0
Receipt_Prl_Per NUMERIC 105 3 0
Receipt_Pr2_Per NUMERIC 108 2 0
Total_Cost NUMERIC 110 9 2
Unit_Cost NUMERIC 119 7 2
Usage_Curr_Per NUMERIC 126 3 0
Usage_Prl_Per NUMERIC 129 2 0
Usage_Pr2_Per NUMERIC 131 2 0
Adjust_Curr_Per Total number of quantity adjustments in the current

year.

Adjust_Prl_Per Total number of quantity adjustments in the first prior
year.
Adjust_Pr2_Per Total number of quantity adjustments in the second

prior year.
Company_Code The code for the company to which the inventory

belongs.
Inventory_Number The inventory number.
Last_Date_Counted The last date the part was physically counted.
Last_Receipt_Date The last date a unit of the part was received.
Lead_Time The number of days necessary to receive the part from

the vendor.
PO_Date_1 The most recent purchase order’s date used to

purchase a unit of the inventory.
PO_Date_2 The second most recent purchase order’s date used to

purchase a unit of the inventory.
PO_Number_1 The most recent purchase order number.
PO_Number_2 The second most recent purchase order number.
PO_Price_1 The most recent purchase order price per unit of

inventory.
PO_Price_2 The second most recent purchase order price per unit
of inventory.
Quantity_On_Hand The quantity of inventory on hand as of the date of the

file.
Receipt_Curr_Per Total number of quantity receipts in the current year.
Receipt_Prl_Per Total number of quantity receipts in the first prior year.

Receipt_Pr2_Per Total number of quantity receipts in the second prior
year.
Total_Cost The extended cost (quantity on hand * unit cost) as of

the date of the file.
Unit_Cost The average unit cost for the part of inventory.
Usage_Curr_Per Total number of quantity usage in the current year.
Usage_Prl_Per Total number of quantity usage in the first prior year.
Usage_Pr2_Per Total number of quantity usage in the second prior

year.
Vendor_Number The vendor number from whom the last units of the
part were purchased.
Inventory Management Verification Batch

INVENTORY_VERIFY
Executed prior to using the INVENTORY_FILE to:
the response “0 data validity errors detected”. Please note the batch will
2 Stratify the inventory file on unit cost and total cost (unit
cost*quantity) - These reports could be reviewed with management for
their reasonableness. Care should be taken with regard to large negative or
positive transactions which may need specific identification and review.
3 Total the inventory file - Agree the amount in the “Last Result” window to
the organization’s inventory listing report (amount is reported after the
command TOTAL Total_Cost in the “Last Result” window).

4 Select a sample of three parts to agree back to supporting
documentation for accuracy - Agree the information per the
INV_VER_SAMP file to supporting documentation. The number of
sampled items can be adjusted in the batch, if necessary.
batches, double-clicking on the INVENTORY_VERIFY batch, and then clicking
SET SAFETY OFF

DELETE ALL OK
OPEN INVENTORY_FILE
Please note: The Last_Date_Counted field has not been verified

considering it has dates of ‘000101’. These dates are properly not considered valid
by ACL, although they do serve a purpose, designating these parts have not been
counted as of the date of the file.
VERIFY FIELDS Adjust_Curr_Per Adjust_Pr1_Per

Adjust_Pr2_Per Company_Code Inventory_Number
Last_Receipt_Date Lead_Time PO_Date_1 PO_Date_2
PO_Number_1 PO_Number_2 PO_Price_1 PO_Price_2
Quantity_On_Hand Receipt_Curr_Per Receipt_Pr1_Per
Receipt_Pr2_Per Total_Cost Unit_Cost Usage_Curr_Per
Usage_Pr1_Per Usage_Pr2_Per Vendor_Number ERRORLIMIT
10
command. If the data is valid, processing will continue with
INVENTORY_VERIFY1 which is listed below.
DO INVENTORY_VERIFY1 IF WRITE1=0
DELETE ALL OK
SET SAFETY ON

INVENTORY_VERIFY1
SET SAFETY OFF
To stratify on unit cost:
STRATIFY ON Unit_Cost ACCUMULATE Total_Cost MINIMUM

1000000 MAXIMUM 1000000 FREE 0, 1, 10,
100,1000,10000,100000,1000000 HEADER=’Stratification
on Unit Cost’ TO SCREEN
To stratify on total cost:
STRATIFY ON Total_Cost ACCUMULATE Total_Cost MINIMUM -

1000000 MAXIMUM 1000000 FREE 0, 1, 10,
on Total Cost’ TO SCREEN
To total the closing inventory value for agreement to supporting documentation:
TOTAL Total_Cost
To select a sample of three inventory parts for agreement to supporting

documentation:
COUNT
X=RAND(COUNT1)
RECORD TO “INV_VER_SAMP”
OPEN INV_VER_SAMP

Stratify inventory costs for unusual trends Application 1
and exceptions* Batch: INVENTORY_1
Novice
Overview
Inventory counting preparation formerly consisted of browsing through an

inventory listing and selecting all items with total costs over increasing dollar
amounts, until that perfect balance of audit time versus audit coverage was obtained.
Nowadays, efficiency is enhanced through the use of ACL. Auditors can stratify on
the total cost of the inventory file, reporting the “% of total field” for coverage
analysis.
On the other hand, unit cost stratification reports could be run to determine audit
coverage. More importantly, they could be gauged in conjunction with the priorities
established by management, thereby highlighting potential inefficiencies. For
example, inventory with low unit costs may be given lower priority for test counting,
or written off upon purchase to avoid inventory monitoring costs.


Toolkit, are required to execute the INVENTORY_1 batch.
Required
<Total_Cost>
<Unit_Cost>
INVENTORY_VERIFY batch. The second stratification in this batch (on
Total_Cost) provides such a wide-angle focus of the activity; it was used in the
INVENTORY_VERIFY batch as further explained in Chapter 3.
Batch
batches, double-clicking on the INVENTORY_1 batch, and then clicking “Run” in
SET SAFETY OFF
To stratify on unit cost (see the Audit Steps section below for procedures to perform
using the resulting report):
OPEN INVENTORY_FILE
STRATIFY ON Unit_Cost ACCUMULATE Total_Cost TO SCREEN FREE
0, 1, 10, 50, 100, 500, 1000, 5000, 10000, 50000,
100000, 500000, 1000000 HEADER=’Stratification on unit
cost’

To stratify on the extended or total cost (see the Audit Steps section below for
STRATIFY ON Total_Cost ACCUMULATE Total_Cost TO SCREEN

FREE 0, 1, 10, 50, 100, 500, 1000, 5000, 10000, 50000,
100000, 500000, 1000000 HEADER=’Stratification on total
cost’
SET SAFETY ON
Audit Steps
Review on unit cost for:
■ unreasonably large unit costs which could be extracted and further

reviewed.
■ a large volume of inventory with low unit costs. Discussions with
management should focus on setting priorities for these parts. Ask
questions such as:
1 Are requisitions necessary for each item?

2 Are periodic physical counting procedures the same for low dollar
versus high dollar parts?
3 Could the parts be written off to expense when purchased and

restocked when needed?
The answers may lead the auditor to determine that inventory management could be
made more efficient by focusing efforts towards higher dollar unit cost inventory.
Review on total cost:
■ for unreasonably large total costs, which could be extracted and further
reviewed.
■ to plan monetary unit sampling, as further discussed in Application 6 in this
chapter.
Helpful Hints
Use the stratification percentages as a guide to accurately communicate the

coverages obtained in audit tests. For example, “95% of inventory greater than
$50,000, representing 62% of the total dollar inventory at 12/31/95, was verified
through physical count procedures.”

Calculate inventory turnover and assess it Application 2
in relation to part lead times Batch: INVENTORY_2
Advanced
Overview
Turnover is an essential statistic to the inventory manager and supplier, providing

insight into the expectations for future years’ needs. “World Class” organizations
have adopted Just in Time (“JIT”), vendor stocking, vendor partnering and part
sharing arrangements to acquire:
1 Perfect quality products, in the
2 Exact quantities needed, at the
3 Precise time needed, with the
4 Lowest total delivered cost.
Not only do these practices lead to timely receipt of quality goods but they also allow
decreased handling charges. Such charges include:
■ material handling expenses

■ storage facility costs
■ lost interest due to lost use of funds
■ search time costs.
Handling charges have been estimated to average between 15% and 28% of unit
value.


Required
<Adjust_Curr_Per>
<Inventory_Number>
<Lead_Time>
<Quantity_On_Hand>
<Receipt_Curr_Per>
<Total_Cost>
<Unit_Cost>
<Usage_Curr_Per>
Batch
SET SAFETY OFF

OPEN INVENTORY_FILE
Inventory turnover is calculated by dividing the period usage by the average

inventory for the period. The sample data supplied with the Toolkit uses the

inventory file at 12/31/96, therefore, the definitions below will calculate the turnover
for the 1996 year.
To define the inventory at the beginning of the period (or the 1996 year as is the case
with the data supplied with the Toolkit), add back any usage while deducting both
the receipts and the adjustments for the year as follows:
DEFINE FIELD Begin_Quantity COMPUTED

(Quantity_On_Hand-Receipt_Curr_Per+Usage_Curr_Per-
Adjust_Curr_Per)
Using the beginning inventory defined above, the period turnover is calculated
through the below definition. Please note, in order to avoid any division by zero
situations, the denominator and numerator of the turnover equations
((Begin_Quantity+Quantity_On_Hand)/2 and Usage_Curr_Per
respectively), if equal to zero, yield a zero Annual_Turnover result. If the usage
is greater than zero (numerator) and the denominator is not, the usage appropriately
becomes the turnover for the period. These three “IF” statements exist to ensure the
integrity of the resulting computed field.
Please note that the division of certain fields is multiplied by 1.000 in the below field
definition. This is completed to avoid any calculation inaccuracies due to the
rounding of minuscule percentages.
DEFINE FIELD Annual_Turnover COMPUTED

0.00 IF Usage_Curr_Per=0
Usage_Curr_Per IF (Begin_Quantity+Quantity_On_Hand)<=0
and Usage_Curr_Per>0
(Usage_Curr_Per/
((1.000*(Begin_Quantity+Quantity_On_Hand)/2)))
SORT ON Annual_Turnover TO SORTED_TURNOVER
OPEN SORTED_TURNOVER

SET SAFETY ON
At the end of this batch, the expressions “Annual_Turnover” and

“Begin_Quantity” will remain in the INVENTORY_FILE. If you delete these
expressions, ACL will also delete them from the SORTED_TURNOVER file
(considering they share the same input file definition within the ACL document). To
remedy this situation, individually “Extract” all fields (In other words, you
cannot just “Extract RECORD”) from the SORTED_TURNOVER file to a new
file and then delete the expressions in the INVENTORY_FILE. The new file will
then have resident in its record these two created expressions, independent of the
INVENTORY_FILE.
Audit Steps
Discuss the SORTED_TURNOVER file with management and suggest:
■ Order parts with low lead times and low turnover when needed. To estimate
the reduction of inventory from this tactic, total those parts with turnover
less than one and a lead time less than three days through the use of the
following command:
“TOTAL Total_Cost IF Annual_Turnover<1 AND
Lead_Time<=3”
■ Organize parts in the storeroom based on turnover. Parts with a high
turnover could be placed in easily reached areas while those with low

turnover could be stored in less accessible areas, possibly at a lower-cost
offsite location.
■ Review parts with low turnover for obsolescence.
■ Share parts with low turnover among storeroom locations.
■ A vendor stocking arrangement for either high or low turnover items to
manage the parts internally. Suppliers could be provided with the
SORTED_TURNOVER file to gauge the value of those parts which would
benefit from such an arrangement and the savings achieved.

Notes

Identify slow moving inventory parts Application 3
Batch: INVENTORY_3
Intermediate
Overview
The goal of these two reports is to identify those parts with limited usage so as to
evaluate their current valuation. The first report quickly isolates inventory with no
usage in the past three years. The second takes a more refined approach. Say, for
instance, that a part was received today, thereby possessing zero usage for the past
three years. The first report would improperly identify this as old while the second,
which tallies parts with no usage and having an on-hand total greater than the total
receipts over the past three years, properly would not.

Required
<Inventory_Number>
<Quantity_On_Hand>

<Receipt_Curr_Per>
<Receipt_Pr1_Per>
<Receipt_Pr2_Per>
<Usage_Curr_Per>
<Usage_Pr1_Per>
<Usage_Pr2_Per>
<Total_Cost>
<Unit_Cost>
Batch
SET SAFETY OFF

OPEN INVENTORY_FILE
GROUP
The command below extracts parts with no usage in the three prior years which have
a quantity on hand greater than zero as of the date of the file - NO_3YR_USAGE (see
EXTRACT TO NO_3YR_USAGE IF Usage_Curr_Per=0 AND

Usage_Pr1_Per=0 AND Usage_Pr2_Per=0 AND
Quantity_On_Hand>0 FIELDS Inventory_Number
Quantity_On_Hand Receipt_Curr_Per Receipt_Pr1_Per
Receipt_Pr2_Per Usage_Curr_Per Usage_Pr1_Per
Usage_Pr2_Per Total_Cost Unit_Cost

This next command extracts parts with no usage in the past three years which had a
quantity on hand as of the date of the file that was not received in the past three years
-NO_3YR_USREC (see the Audit Steps section below for procedures to perform
EXTRACT TO NO_3YR_USREC IF
Quantity_On_Hand>(Receipt_Curr_Per+Receipt_Pr1_Per+Rec
eipt_Pr2_Per) AND Usage_Curr_Per=0 AND Usage_Pr1_Per=0
AND Usage_Pr2_Per=0 AND Quantity_On_Hand>0 FIELDS
Inventory_Number Quantity_On_Hand Receipt_Curr_Per
Receipt_Pr1_Per Receipt_Pr2_Per Usage_Curr_Per
Usage_Pr1_Per Usage_Pr2_Per Total_Cost Unit_Cost

END
SET SAFETY ON
Audit Steps
Using both reports:
■ “Total” the Total_Cost field in both the NO_3YR_USAGE and

NO_3YR_USREC files to determine the materiality.
■ Identify the reasons for such parts to be on hand for such extreme periods of
time without any usage.
■ Review this inventory carefully to determine if it is currently obsolete or
should be reduced in value to represent market conditions (see additional
testwork performed in Application 4). One likely possibility would be that
the inventory’s represents safety stock for those “unseen emergencies”. Even
these cases should be evaluated closely to conclude whether such situations
will ever emerge.

Compare unit cost to current sales price for Application 4
lower of cost or market testing Batch: INVENTORY_4
Advanced
Overview
“A departure from the cost basis of pricing the inventory is required when the utility
of the goods is no longer as great as its cost.” In line with this accounting principle,
this report will calculate the difference between the unit cost of the inventory
(presumably based on historical cost) and the most current selling price in the
shipment file.
INVENTORY_FILE

Required
<Inventory_Number>
<Quantity_On_Hand>
<Total_Cost>

<Unit_Cost>
SHIPMENT_FILE

Toolkit, are also required.
Required
<Inventory_Number>
<Ship_Unit_Price>
<Ship_Date>
SHIPMENT_VERIFY batch.
Batch
SET SAFETY OFF

OPEN SHIPMENT_FILE
By sorting and summarizing the SHIPMENT_FILE on the

Inventory_Number first and the descending Billing_Date second, the
resulting file will include the most current price for each part. The price will be
joined later to the INVENTORY_FILE to accommodate lower-of-cost-or-market
analysis.
SORT ON Inventory_Number Billing_Date D TO SORTED

SUMMARIZE ON Inventory_Number ACCUMULATE Ship_Quantity
OTHER Ship_Unit_Price TO SUMMARIZED

OPEN INVENTORY_FILE
SORT ON Inventory_Number TO SORTED1
OPEN SUMMARIZED SECONDARY
The “Join” command below will list all inventory records, regardless if there is a
current price in the SHIPMENT_FILE file. If you wish to include only those
records that have prices in the shipment file, remove the word “PRIMARY” from the
command.
JOIN PKEY Inventory_Number FIELDS Inventory_Number

Quantity_On_Hand Unit_Cost Total_Cost SKEY
Inventory_Number WITH Ship_Unit_Price PRIMARY TO
“INV_COST_PRICE”
CLOSE SECONDARY
OPEN INV_COST_PRICE
To calculate the difference between the most current sales price and the cost of the
inventory (see the Audit Steps section below for procedures to perform using the
resulting file):
DEFINE FIELD Cost_Price_Diff COMPUTED

0.00 IF Ship_Unit_Price=0 OR Unit_Cost=0
(Unit_Cost-Ship_Unit_Price)
SET SAFETY ON

Audit Steps
Review with management the Cost_Price_Diff field in the

INV_COST_PRICE file to assess whether a reduction to market is required. It may
be useful to “Extract IF Cost_Price_Diff>0” which represents all sales
prices greater than the average unit price.

Select a Monetary Unit Sample of Application 5
inventory parts Batch: INVENTORY_5
Intermediate
Overview
Counting inventory is an age-old tradition for auditors (especially on New Year’s

Day) which can be enhanced through the use of the following batch. In contrast to a
random sample, it is statistically very reassuring.

Toolkit, are required to execute the INVENTORY_5 batch:
Required
<Inventory_Number>
<Quantity_On_Hand>
<Total_Cost>
<Unit_Cost>

Since this application tests the existence and accuracy of the inventory balance as of
a given date, the balance per the entity’s records should be agreed to this file prior to
processing. To calculate the total inventory value per the file, type the command
“TOTAL Total_Cost” at the command log prompt.
Batch
The sample that follows uses inventory parts as the sampling unit. For a more
detailed explanation of the Sampling features, consult the ACL for Windows
Reference Manual.
■ Agree the balance per the entity’s records to the file used prior to processing.
To calculate the inventory value per the INVENTORY_FILE file, type the
command “TOTAL Total_Cost” at the command and log prompt
which will serve as the Population in the sample selection explained below.
sample size.
■ Once calculated, note the INTERVAL value that will be accepted by the
batch.
■ Determine whether significant transactions (identified in the batch by
entering a CUTOFF value) will be reviewed separately. Review Application 1
in this chapter for guidance in setting the value. (The stratification on
Total_Cost should provide you with the information necessary to
decide where the cutoff should originate.) Please note that if no value is set,
ACL will automatically select any balance greater than the INTERVAL
value, as consistent with Monetary Unit Sampling.
SET SAFETY OFF

OPEN INVENTORY_FILE
To accept all necessary information for processing a MUS sample:

SAMPLE ON Total_Cost INTERVAL INT FIXED START CUTOFF CUT

RECORD TO “SAMPLE INVENTORY”
OPEN SAMPLE_INVENTORY
DELETE ALL OK
SET SAFETY ON
Audit Steps
Once the physical count testwork is complete, use the Evaluate command in ACL
(select “Sampling” from the menu bar and choose “Evaluate”) for any
differences between the book and the physical inventory. This command will
calculate the “Most Likely Error” and “Upper Error Limit” as further explained in
the ACL for Windows Reference Manual or online help.

Notes

Summarize inventory adjustments for Application 6
unusual trends and exceptions Batch: INVENTORY_6
Novice
Overview
A review of the net dollar and quantity adjustments for the year may lead an auditor
to believe that there are few issues in this area. Use of the absolute value function in
ACL leads to the conclusion that net dollar amounts are not always important; it is
the proper functioning of the system underlying the balance that counts.

Required
<Company_Code>
<Adjust_Curr_Per>

<Adjust_Pr1_Per>
<Adjust_Pr2_Per>
<Unit_Cost>
Batch
SET SAFETY OFF

OPEN INVENTORY_FILE
These commands serve to define the absolute value of all adjustments occurring in
the current and two prior years. (If fewer or more years of adjustments are expected
to be reviewed, change the two field definitions below prior to executing the batch).
These defined fields will be used in a Summarize command, appearing later in the
batch:
DEFINE FIELD Abs_Adjust_3YR COMPUTED

ABS(Adjust_Curr_Per+Adjust_Pr1_Per+Adjust_Pr2_Per)
DEFINE FIELD Abs_Adjust_3YRC COMPUTED
(ABS(Adjust_Curr_Per+Adjust_Pr1_Per+Adjust_Pr2_Per)*Un
it_Cost)
Because there is only one company code in the file supplied with the Toolkit
(Company_Code=”1”) there is no reason to sort the file prior to the
summarization below. The resulting file, ADJUSTMENTS_SUM.FIL, will report
the absolute value of adjustments for the period of the file (see the Audit Steps section
SUMMARIZE ON Company_Code ACCUMULATE Abs_Adjust_3YR

Abs_Adjust_3YRC TO ADJUSTMENTS_SUM

DELETE Abs_Adjust_3YR OK
DELETE Abs_Adjust_3YRC OK
OPEN ADJUSTMENTS_SUM
SET SAFETY ON
Audit Steps
Adjustments in inventory usually occur for four reasons:
1 Parts were taken without proper documentation and/or entry into the
system.
2 Parts were taken and returned without proper documentation or entry into
the system.
3 Parts were mistakenly entered into the system, either at receipt or through
subsequent physical counts.
4 Parts were written off due to damage, obsolescence or misappropriation.
Each reason centers on a different control issue which can be abated through the
following recommendations. The recommendations below relate to the adjustment
reasons stated above:
1 Reiterate to management that forms and/or system entry must be

completed at the time of requisition. Perhaps the inventory area should be
locked, allowing access to key individuals who are made responsible to
perform proper requisition techniques. A video camera recording all
employees entering and exiting the storeroom could also be installed.
2 Reiterate to management that forms and/or system entry must be

completed at the time of return.
3 Suggest that batch totals (manual total of all receipts or adjustments entered
at a given time) be agreed to the input into the system.

4 Review quality control procedures relative to damaged goods with
management. Review procedures regarding obsolete goods, possibly in
conjunction with Applications 1, 2, 3, 4, 6 and 7, all concerning the valuation
assertion of inventory. If any goods are thought to be misappropriated,
perhaps the inventory area should be locked, allowing access to key
individuals only. Another suggestion is the installation of a video camera in
the storeroom.

List parts with extended cost, unit cost or Application 7
quantity less than zero Batch: INVENTORY_7
Novice
Overview
Stranger occurrences have been known to happen than having fewer than no parts
on hand or receiving payment for the storage of parts. Any negative quantities
should be handled carefully—especially considering that, scientifically speaking,
they represent anti-matter.

Required
<Inventory_Number>
<Quantity_On_Hand>
<Total_Cost>
<Unit_Cost>

Batch
SET SAFETY OFF

OPEN INVENTORY_FILE
To extract parts with unit cost, extended cost, or quantity less than zero (see the
EXTRACT FIELDS Inventory_Number Quantity_On_Hand

Total_Cost Unit_Cost IF Quantity_On_Hand<0 OR
Unit_Cost<0 OR Total_Cost<0 TO LESS_THAN_ZERO_INV
OPEN LESS_THAN_ZERO_INV
SET SAFETY ON
Audit Steps
Review the inventory program logic. Such a review could reveal that the software
allows negative inventory quantities. This points to data integrity issues that go
beyond the scope of this application. Usually, the negative quantity is the result of
entering sales to a customer without the corresponding vendor receipt entry.
From the point of view of negative prices, discuss with management to identify
transactions where the organization was paid to store the on hand parts. If not, the
same review of program logic and data integrity should be completed.

Identify inventory not counted in a Application 8
specified period of time Batch: INVENTORY_8
Intermediate
Identify parts that have never been Application 9

counted Batch: INVENTORY_9
Intermediate
Stratify parts based on the last date they Application 10

were counted Batch: INVENTORY_10
Novice
Overview
Most inventory accounting systems require a date to be entered when parts were last
counted. Since parts should be counted on a regular basis to ensure their accuracy,
these reports quickly identify those parts that require immediate attention.
■ Application 8 goes straight to the point by selecting parts that should have
been counted within an acceptable time range.
■ Through use of the Last_Receipt_Date field, Application 9 bypasses a
common complaint by inventory managers that certain parts will not have a
last count date entered because they were just received.
■ Application 10 provides a “bird’s eye view” of exactly when, throughout the
year, the parts were counted. To no one’s surprise, parts seem to be counted
more diligently at the beginning of an audit than at any other time of the
year.


Toolkit, are required to execute the INVENTORY_8, INVENTORY_9, and
INVENTORY_10 batches.
Application 8 Application 9 Application 10

Required Required Required
<Inventory_Number><Inventory_Number><Last_Date_Counted>
<Last_Date_Counted><Last_Date_Counted> <Total_Cost>
<Quantity_On_Hand><Quantity_On_Hand>
<Total_Cost> <Total_Cost>
<Unit_Cost> <Unit_Cost>
<Last_Receipt_Date>
To test the validity of the data used in these applications, execute the
Batches
Application 8

date of the inventory file). This parameter is required to allow the AGE() function,
as used to stratify on the Last_Date_Counted, to function properly. If using the
sample data provided with the Toolkit, enter the date 12/31/96 in YYYYMMDD
format (i.e. 19961231).
SET SAFETY OFF

ASSIGN AGEDATE=CTOD(AGE_DATE)
ACCEPT’Acceptable number of days for parts to not be
counted’ TO DAYS
For example, if parts are expected to be counted on an annual basis, enter 365 at the
above Accept command to extract parts counted more than one year ago.
OPEN INVENTORY_FILE
To extract counted parts which have last been counted outside the acceptable time
frame (see the Audit Steps section below for procedures to perform using the
resulting file):
EXTRACT FIELDS TO OLD_COUNTED IF

AGE(Last_Date_Counted,AGEDATE)>VALUE(DAYS,0) AND
Last_Date_Counted<>‘19000101’ FIELDS Inventory_Number
Last_Date_Counted Quantity_On_Hand Total_Cost
Unit_Cost
OPEN OLD_COUNTED

DELETE ALL OK
SET SAFETY ON
Application 9
date of the inventory file). This parameter is required to correctly apply the AGE()
function to the Last_Receipt_Date. If using the sample data provided with
the Toolkit, enter the date 12/31/96 in YYYYMMDD format (i.e. 19961231).
SET SAFETY OFF


ACCEPT’Acceptable number of days for parts to not be
counted’ TO DAYS
For example, if parts are expected to be counted on an annual basis, enter 365 at the
above Accept command to extract parts that should have been counted within the
year.
OPEN INVENTORY_FILE
To extract parts not counted yet received outside of the acceptable time frame (see
EXTRACT TO NOT_COUNTED IF Last_Date_Counted=‘19000101’ AND

AGE(Last_Receipt_Date,AGEDATE)>VALUE(DAYS,0) FIELDS
Inventory_Number Last_Date_Counted Quantity_On_Hand
Unit_Cost Total_Cost Last_Receipt_Date Receipt_Pr1_Per
Receipt_Pr2_Per
OPEN NOT_COUNTED

DELETE ALL OK
SET SAFETY ON
Application 10

date of the inventory file). This parameter is required to allow the AGE command, as
used to stratify on the Last_Date_Counted, to function properly. If using the
sample data provided with the Toolkit, enter the date 12/31/96 in YYYYMMDD
format (i.e. 19961231).
SET SAFETY OFF
OPEN INVENTORY_FILE
To stratify on the date the part was last counted (see the Audit Steps section below for
AGE ON Last_Date_Counted CUTOFF AGE_DATE INTERVAL 0, 7,

14, 30, 60, 90, 120, 150, 180, 270, 360 ACCUMULATE
Total_Cost TO SCREEN HEADER=’Stratification on the last
date the inventory was counted’
SET SAFETY ON

Audit Steps
Review each of the above reports with management to determine the reason why
these parts were not counted within the acceptable time frame. Time permitting,
select a sample of the parts from these reports for a physical count. It is more likely
that inaccuracies will develop in neglected parts than in parts that are counted on a
regular basis.

Property, Plant and Equipment Chapter 9
“To capitalize or not to capitalize, that is the question.”
Fixed assets are expenditures for tangible property which will be used for a period of
more than one year. Therefore, their cost is deferred to future periods in compliance
with the matching principle.10 With regard to the approval, receiving and recording
controls for fixed assets, much auditor reliance can be placed in the proper
functioning of the purchasing function (see Chapter 5). This is not to say that once
recorded in the general ledger, these assets are classified, depreciated and monitored
correctly. Such objectives can only be achieved through the existence and proper
functioning of a fixed asset control system, tested with the applications present in
this chapter.
Property, Plant and Equipment Objectives

The following is a list of specific audit objectives for the property, plant and
equipment area along with the applicable report numbers. The auditor should
attempt to obtain reasonable assurance that the following objectives have been
achieved by the organization:
Property, Plant and Equipment Exist and Are Recorded Accurately and
Completely
Report number: 2, 3, 4, 5
Property, Plant and Equipment Purchases and Retirements Are Properly

Approved
Report number: 2, 3, 4, 5
Property, Plant and Equipment Valuation Is Appropriate

Property, Plant and Equipment Applications and Reports
1 Summarize fixed assets by their depreciable lives. (1) Novice
2 Detect expenses that should have been capitalized. (1) Advanced
3 Extract large additions or disposals for review. (2) Novice
4 Select a Monetary Unit Sample of fixed assets for vouching and physical
inspection. (1) Intermediate
5 Stratify disposal information by dollar amount and select a sample for

detailed testwork. (1) Novice
6 List assets with high salvage values compared to asset values. (1) Novice
7 Report assets that have been depreciated beyond their cost. (1) Novice
Property, Plant and Equipment Data File

(PROPERTY_FILE) - The fixed asset subledger at 12/31/96 which includes the
addition, disposal, and depreciation listings. Below is the data structure which is
followed by a field explanation list:
Data Structure
50 Records using PRPRTTY.FIL as the data file.

explanation
Accm_Dep NUMERIC 1 9 2
Aquisition_Date DATE 10 6 PICTURE “yymmdd”
Addition_Cost NUMERIC 16 9 2
Asset_Number ASCII 25 2
Beg_Cost NUMERIC 27 9 2
Cash_Received NUMERIC 36 8 2
Check_Num_Rec ASCII 44 5
Current_Deprec NUMERIC 53 8 2
Depreciable_Life ASCII 61 2
Disposal_Acc_Dep NUMERIC 63 2
Disposal_Cost NUMERIC 71 8 2
Disposition_Date DATE 79 8 PICTURE “yymmdd”
End_Cost NUMERIC 87 9 2
Gain_Loss_On_Disp NUMERIC 96 8 2
Net_Book_Value NUMERIC 104 9 2
Salvage_Value NUMERIC 113 8 2
Accum_Dep The accumulated depreciation to date for the asset.
Acquisition_Date The date the asset was acquired.
Addition_Cost The cost of the current year addition.
Asset_Number The number of the asset.

Beg_Cost The cost of the asset at the beginning of the year.
Cash_Received The cash received on the current year disposal of the

asset.
Check_Num_Rec The number of the check received for the current year
disposal of the asset.
Check_Number The check number used to purchase the asset.
Current_Deprec The current year depreciation for the asset.
Depreciable_Life The life used to depreciate the asset.
Disposal_Accum_Dep The accumulated depreciation at the date of the

current year asset disposal.
Disposal_Cost The cost of the current year asset disposal.
Disposition_Date The date of the current year disposal.
End_Cost The cost of the asset at the end of the year.
Gain_Loss_On_Disp The gain or loss on the disposal of the current year

asset.
Net_Book_Value The net book value of the asset at the end of the year.
Salvage_Value The salvage value of the asset which will not be

depreciated.

Property, Plant and Equipment Verification Batch
PROPERTY_VERIFY
Executed prior to using the PROPERTY_FILE to:
Log” after batch processing to ensure that the command yielded the
response “0 data validity errors detected”. Please note the
batch will terminate processing at this point, with an appropriate user dialog
box, if the data has any invalid fields.
2 Stratify the fixed asset file on the ending cost value - These reports could
be reviewed with management for their reasonableness. Care should be
taken with regard to large negative or positive transactions which may need
specific identification and review.
3 Total the net book value (cost less accumulated depreciation) fixed
asset file - Agree the amount in the “Last Result” window to the
organization’s property, plant and equipment report (amount is reported
after the command TOTAL Net_Book_Value in the “Last Result”
window).

4 Select a sample of three assets to agree back to supporting
documentation for accuracy - Agree the information per the
PROP_VER_SAMP file to supporting documentation. The number of
sampled items can be adjusted in the batch, if necessary.
batches, double-clicking on the PROPERTY_VERIFY batch, and then clicking
SET SAFETY OFF

DELETE ALL OK
OPEN PROPERTY_FILE
Please note: The Disposition_Date field has not been verified

considering it has dates of ‘000101’. These dates are properly not considered valid by
ACL although they do serve a purpose, designating those assets not disposed during
the current year.
VERIFY FIELDS Accum_Dep Acquisition_Date Addition_Cost

Asset_Number Beg_Cost Cash_Received Check_Num_Rec
Check_Number Current_Deprec Depreciable_Life
Disposal_Accum_Dep Disposal_Cost End_Cost
Gain_Loss_On_Disp Net_Book_Value Salvage_Value
ERRORLIMIT 10
command. If the data is valid, processing will continue with
PROPERTY_VERIFY1 which is listed below.
DO PROPERTY_VERIFY1 IF WRITE1=0
DELETE ALL OK
SET SAFETY ON
PROPERTY_VERIFY1
SET SAFETY OFF

To stratify on the ending fixed asset value:
STRATIFY ON End_Cost ACCUMULATE End_Cost MINIMUM -1000000

MAXIMUM 1000000 FREE 0, 1, 10,
on the Ending PP&E Cost’ TO SCREEN
To total the closing net book value for agreement to company records:
TOTAL Net_Book_Value
To select a sample of three assets to agree back to supporting documentation:
COUNT
X=RAND(COUNT1)
RECORD TO “PROP_VER_SAMP”
OPEN PROP_VER_SAMP

Notes

Summarize fixed assets by their Application 1
depreciable lives Batch: PROPERTY_1
Novice
Overview
Utilize this application to obtain a fast representation of depreciation sources. With

this report, the auditor can assess asset life, expenses incurred and accumulated
depreciation for reasonableness.
The following fields, currently in the PROPERTY_FILE as included with this

Toolkit, are required to execute the PROPERTY_1 batch.
Required
<Current_Deprec>
<Depreciable_Life>
<End_Cost>
PROPERTY_VERIFY batch.

Batch
batches, double-clicking on the PROPERTY_1 batch, and then clicking “Run” in
SET SAFETY OFF

OPEN PROPERTY_FILE
To summarize the asset cost and current depreciation on the depreciable life for
analysis (see the Audit Steps section below for procedures to perform using the
resulting file):
SUMMARIZE ON Depreciable_Life ACCUMULATE End_Cost

Current_Deprec TO LIVES PRESORT
OPEN LIVES
The following two field definitions will support a current year depreciation
reasonableness calculation as further explained in the Audit Steps section below.
DEFINE FIELD Deprec_Reas COMPUTED

0.00 IF VALUE(Depreciable_Life,0)<=0
(End_Cost-Salvage_Value)/VALUE(Depreciable_Life,0)
DEFINE FIELD Deprec_Reas_Diff COMPUTED (Deprec_Reas-
Current_Deprec)

SET SAFETY ON
Audit Steps
Review the LIVES file for:
■ unreasonably large or small balances in any one depreciable life. Review this
in conjunction with the nature of the organization’s business.
■ credit balances in any one depreciable life. Such balances should not exist. If
found, the auditor should raise potential system or data integrity concerns
(see Application 7 for further testwork).
■ assets with no service life. Ensure that these assets are land with no
requirements for depletion.
The LIVES file can also be used to:
■ plan substantive testwork relative to depreciation expense.

■ assess the current year depreciation expense reasonableness test. This test
was already completed in the file through the definition of the fields
Deprec_Reas and Deprec_Reas_Diff. Of course, such an analysis
would not properly take into consideration:
1 depreciation for disposals made during the year
2 depreciation for current year additions
3 depreciation for assets already fully depreciated.

Detect expenses that should have been Application 2
capitalized Batch: PROPERTY_2
Advanced
Overview
With the current year expense savings associated with capitalizing assets, it seems
that everyone would be catching the “capitalization craze”. Although this may be
true at times, it is also true that approval for capital projects is normally more
difficult to obtain, leading certain purchases to be wrongfully expensed rather than
capitalized. Take for example a project that runs over budget and requires the Board
of Director’s approval if expenditures exceed $50,000 over the originally approved
limit. Such restrictions may lead management to cut corners, in an effort to maintain
personal and professional dignity.
To combat such strategies, a substantive test can be performed that reviews the
repairs and maintenance account for expenses that appear more capital in nature
(i.e. - tangible property that will be used for a period of more than one year).
Although this is a solid approach, another would be to review all purchases from
vendors that had supplied some capital assets during the year, in an attempt to
ensure that these and all other capital assets are recorded.
Property, Plant and Equipment Exist and Are Recorded Accurately and
Completely
Property, Plant and Equipment Purchases and Retirements Are Properly

Approved

PROPERTY_FILE

Required
<Check_Number>
PAID_FILE
also required and/or useful.
Required Useful
<Check_Number> <Invoice_Date>
<Invoice Number> <Invoice_Batch>
<Vendor_Name> <Vendor_Number>
batch.
Batch
The commands will render a simple join of all data fields listed above.

Please note that both files have a Check_Number field which is equal in length (8
bytes) and type (ASCII). This is necessary for the proper functioning of the JOIN
command.
SET SAFETY OFF

OPEN PAID_FILE
SORT ON Check_Number to SORTED1
OPEN PROPERTY_FILE
This Join is completed to derive the vendor name for each capital asset addition
purchased during the year. Note that the check number is the common field between
both the PROPERTY_FILE and PAID_FILE.
JOIN PKEY Check_Number FIELDS Check_Number SKEY

Check_Number WITH Vendor_Name TO “JOINED” PRESORT
CLOSE SECONDARY
OPEN JOINED
To classify on vendor name all asset purchases for use in the following List
command:
CLASSIFY ON Vendor_Name to CLASSIFIED

OPEN CLASSIFIED
The following “LIST” command will create a text copy of the below line with the
Vendor_Name field replaced with the actual vendor names. A new text line will be
created for each vendor in the PROPERTY_FILE file. See the subsequent note
below for how to complete batch processing with these lines of text.
LIST “EXTRACT Check_Amount Vendor_Name Invoice_Number

Invoice_Date Invoice_Batch Vendor_Number
Check_Date Check_Number TO PROP2 IF
AT(1,‘“+TRIM(UPPER(Vendor_Name))+”’,UPPER(Vendor_Name)
)>0” to PROP2.BAT UNFORMATTED
SET SAFETY ON

At this point, a text file named PROP2.BAT exists in your working directory. Open
it in your favorite word processor to see a listing of Extract commands, one for
each vendor per the PROPERTY_FILE file. Copy its contents to a new batch named
“PROPERTY_2_Results” as completed below. Essentially, one large “IF”
statement is created rather than having numerous “Extract” commands to
minimize processing time.
Also, be sure, at a minimum, to type the SET SAFETY OFF, USE PAID_FILE
and SET SAFETY ON commands prior to execution.
batches, double-clicking on the PROPERTY_2_RESULTS batch, and then clicking
SET SAFETY OFF

OPEN PAID_FILE
Invoice_Date Invoice_Batch Vendor_Number Check_Number
Check_Date TO PROP2 IF AT(1,‘EQUIPMENT
MAINTENANCE’,UPPER(Vendor_Name))>0 OR AT(1,’COX
EXECUTIVE SUPPLIES’,UPPER(Vendor_Name))>0 OR
AT(1,’COMPUTER STORE’,UPPER(Vendor_Name))>0
OPEN PROP2
SET SAFETY ON

Audit Steps
Using the file PROP2, review the actual invoices (making sure not to select those
with check numbers in the PROPERTY_FILE which have already been capitalized)
in an effort to determine whether the expenditure incurred was capital in nature.
It must be noted that this report only detects expenditures with vendors who have
provided capital assets at other times in the audit period. Therefore, all expenditures
that could potentially be capitalized cannot be reviewed using this report. To
achieve this aim, perform substantive tests using the PROP2 file and perform these
same tests on those invoices supporting expenditures incurred in the expense
accounts which have the potential to be capitalized (i.e. - repairs and maintenance
account).

Extract large additions or disposals for Application 3
review Batch: PROPERTY_3
Novice
Overview
Materiality is the name of the game, especially wherever audit resources are limited.
With that in mind, extractions of significant items for detailed or other compliance
testwork are an effective means to gain audit coverage while lowering the extent of
additional sampling. This batch has been set to allow the auditor to extract the ‘X’
largest additions, disposals or amounts in any of the other numeric fields in the
PROPERTY_FILE.
Property, Plant and Equipment Exist and Are Recorded Accurately and Completely
Property, Plant and Equipment Purchases and Retirements Are Properly Approved

Required Useful
<Asset_Number> <Depreciable_Life>
<Begin_Cost> <Current_Deprec>
<Addition_Cost> <Accum_Dep>
<Disposal_Cost> <Disposal_Accum_Dep>

<End_Cost> <Net_Book_Value>
<Cash_Received>
<Gain_Loss_On_Disp>
<Acquisition_Date>
<Disposition_Date>
<Salvage_Value>
<Check_Number>
Batch
SET SAFETY OFF

DELETE ALL OK
OPEN PROPERTY_FILE
Using the following ACCEPT command, the auditor can select any numeric field for
extraction.
ACCEPT ‘Enter field for extraction’ FIELDS ‘N’ to EXFIELD
The next ACCEPT command requests the number of largest transactions for use by
the auditor:
ACCEPT ‘Enter number of the largest items to extract’ to

TOP
OPEN PROPERTY_FILE

To sort, in a descending fashion, the selected numeric field for extraction of the top
transactions (see the Audit Steps section below for procedures to perform using the
resulting file):\
SORT ON %EXFIELD% D to SORTED

OPEN SORTED
EXTRACT RECORD IF RECNO()<=VALUE(TOP,0) TO TOP_EXTRACT
OPEN TOP_EXTRACT
DELETE ALL OK
SET SAFETY ON
Audit Steps
Any number of audit tests could be performed on the resulting extraction. For
guidance, review the compliance sample testwork as explained in the Audit Steps
section of Applications 4 and 5 in this chapter.

Notes

Select a Monetary Unit Sample of fixed Application 4
assets for vouching and physical inspection Batch: PROPERTY_4
Intermediate
Overview
Fixed assets normally represent a material portion of any balance sheet. Such assets
should be either vouched or physically inspected to ensure their existence and
accuracy in the organization’s records.

Required Useful
<Asset_Number> <Depreciable_Life>
<Addition_Cost> <Begin_Cost>
<End_Cost> <Current_Deprec>

<Accum_Dep>
<Disposal_Cost>
<Disposal_Accum_Dep>
<Net_Book_Value>
<Cash_Received>
<Gain_Loss_On_Disp>
<Acquisition_Date>
<Disposition_Date>
<Salvage_Value>
<Check_Number>
Batch
The sample that follows uses either current period additions or existing assets (as
defined by the user) as the sampling unit. For a more detailed explanation of the
Sampling features in ACL for Windows, consult the Reference Manual which
accompanies the software.
■ Agree the balance per the entity’s records (for either additions or ending
asset value, depending on which sample is being taken) to the file used prior
to processing. To calculate the addition or existing asset value per the
PROPERTY_FILE file, use the “Total” command.
sample size.
■ Once calculated, note the INTERVAL value which will be accepted by the
batch.

■ Determine whether significant transactions will be reviewed separately.
These can be identified in the batch by entering a CUTOFF value. Prior to
the value. (The classification on End_Cost should provide you with the
information necessary to decide where the cutoff should originate.) Please
note that if no value is set, ACL will automatically select any balance greater
than the INTERVAL value, as consistent with Monetary Unit Sampling.
SET SAFETY OFF

OPEN PROPERTY_FILE
To accept any numeric field in the file for sampling:
ACCEPT ‘Field for sampling’ FIELDS ‘N’ TO SAMFIELD
To accept the necessary information for a MUS sample:

ASSIGN CUT= INT if LEN(CUT)=0
To select a MUS sample (see the Audit Steps section below for procedures to perform
SAMPLE ON %SAMFIELD% INTERVAL INT FIXED START CUTOFF CUT

RECORD TO “SAMPLE PROPERTY”
OPEN SAMPLE_PROPERTY
DELETE ALL OK
SET SAFETY ON

Audit Steps
Perform the following tests, depending on the nature of the sample selected, to
determine whether reasonable assurance has been achieved with regards to the
associated audit objectives:
■ Vouch asset costs to vendor invoices and other documentation, as

applicable.
■ Perform physical count procedures for each selected asset.
■ Review approval documentation to determine compliance with
organization policy.
■ Compare total costs with approved amounts to determine if any cost
overruns occurred or additional approvals, as required by organization
policy, were obtained.
■ Determine whether completed construction projects were closed to the
fixed asset account on a timely basis, based on date of project completion.
■ Review the depreciable lives assigned for reasonableness and consistency
with organization policy.
Once the testwork is complete, use the Evaluate command in ACL (select
“Sampling” from the menu bar and choose “Evaluate”) to identify any
differences between the reported numeric value selected and the actual value
vouched. This command will calculate the “Most Likely Error” and “Upper Error
Limit” as further explained in the ACL for Windows Reference Manual or on line
help.

Stratify disposal information by dollar Application 5
amount and select a sample for detail Batch: PROPERTY_5
testwork Novice
Overview
Any transaction that has the potential of creating a gain or loss should be closely
reviewed to ensure that:
■ gains have not been overstated

■ losses have not been understated.
Through the use of the following stratifications and MUS samples (which focus
efforts on significant items) audit comfort should be achieved with regard to the
proper recording of disposals.

Required
<Asset_Number>

<Cash_Received>
<Check_Num_Rec>
<Depreciable_Life>
<Disposal_Accum_Dep>
<Disposal_Cost>
<Disposition_Date>
<Gain_Loss_On_Disp>
<Salvage_Value>
Batch
SET SAFETY OFF

OPEN PROPERTY_FILE
To stratify on the gain or loss on disposal for analysis as to their relative size (see the
Audit Steps section below for procedures to perform using the resulting report):
STRATIFY ON Gain_Loss_On_Disp ACCUMULATE

Gain_Loss_On_Disp TO SCREEN FREE -1000000, -500000, -
100000, -50000, -10000, -5000, -1000, -100, 0,100,
1000, 5000, 10000, 50000, 100000, 500000, 1000000
HEADER=’Stratify on Gain/Loss in Asset Disposal’
To calculate and stratify on the assets net book value at the time of disposal for
analysis as to its relative size (see the Audit Steps section below for procedures to

DEFINE FIELD Disposal_NBV COMPUTED
(Disposal_Cost-Disposal_Accum_Dep)
STRATIFY ON Disposal_NBV ACCUMULATE Disposal NBV TO SCREEN
FREE 0,100, 1000, 5000, 10000, 50000, 100000, 500000,
1000000 HEADER=’Stratify on Net Book Value in Asset
Disposal’
DELETE Disposal_NBV OK
SET SAFETY ON
Using the above stratifications as a guide, select a MUS sample using the
PROPERTY_4 batch either on the Gain/Loss in Disposal or the Net Book Value at
the time of disposal. For a more detailed explanation of the Sampling features in ACL
for Windows, consult the Command Reference guide which accompanies the
software.
Audit Steps
Perform the following tests, depending on the nature of the sample selected, to
determine whether reasonable assurance has been achieved with regards to the
associated audit objectives:
■ Vouch cash received to the customer check and other documentation, as

applicable.
■ Perform physical procedures to ensure the asset has been properly disposed.
■ Review approval documentation to determine compliance with
organization policy.
■ Review the gain/loss calculation to ensure compliance with GAAP.
Once the testwork is complete, use the Evaluate command in ACL (select
“Sampling” from the menu bar and choose “Evaluate”) to identify any
differences between the reported disposal entry value and the actual entry vouched.
This command will calculate the “Most Likely Error” and “Upper Error Limit” as
further explained in the command reference literature or on line help.

Notes

List assets with high salvage values Application 6
compared to asset values Batch: PROPERTY_6
Novice
List assets that have been depreciated Application 7

beyond their cost Batch: PROPERTY_7
Novice
Overview - This Overview is applicable to Applications 6 & 7
Testing for exceptions in the areas of accumulated depreciation and salvage value is
an effective means to determine whether fixed assets are properly valued at period
end. These two applications, which pinpoint potential exceptions, should assist in
achieving this objective.
Audit Objectives Tested - Applications 6 & 7

Required

<Asset_Number>
<End_Cost>
<Salvage_Value>

Required
<Accum_Dep>
<Asset_Number>
<End_Cost>
<Salvage_Value>
SET SAFETY OFF

OPEN PROPERTY_FILE

To sort, in a descending fashion, the percentage of the salvage value to the ending
value (see the Audit Steps section below for procedures to perform using the
resulting file):
SORT ON (Salvage_Value/End_Cost) D TO SORT_SALVAGE

OPEN SORT_SALVAGE
DEFINE FIELD Salvage_Percent COMPUTED
0.00 IF Salvage_Value<=0
0.00 if End_Cost<=0
(Salvage_Value/End_Cost)
Please note, if you wish to execute this batch a second time, it is required that the
Salvage_Percent expression be deleted from the SORT_SALVAGE file.
Otherwise, the batch will fail since such an expression will already exist when the
batch attempts to create it a second time.

SET SAFETY ON
SET SAFETY OFF

OPEN PROPERTY_FILE
The following field definition and related extraction will detect those assets, not
disposed during the year, which have accumulated depreciation exceeding their
asset cost less salvage value (see the Audit Steps section below for procedures to
DEFINE FIELD NBV_With_Salv COMPUTED

(End_Cost-(Salvage_Value+Disposal_Accum_Dep))

EXTRACT FIELDS Asset_Number End_Cost Salvage_Value
Accum_Dep NBV_With_Salv IF NBV_With_Salv<0 AND
End_Cost>0 TO OVER_DEPREC
DELETE NBV_With_Salv OK
OPEN OVER_DEPREC
SET SAFETY ON
Audit Steps - The Audit Steps below are applicable to Applications 6 & 7
Use the Salvage_Percent field in the SORT_SALVAGE file to review with

management the reasons for high established salvage values. This inquiry testwork
could also be performed in conjunction with independent confirmation (i.e. -
appraisal certificates) to determine whether the salvage values for assets are
appropriate.
The OVER_DEPREC file represents valid exceptions considering no asset should be

depreciated more than its original cost less salvage value. Such exceptions may
highlight data or system integrity issues that should be investigated and corrected.

Electronic Data
Processing Review Chapter 10
If only a few people had access to the computer network, the auditor’s job would be
a cinch. Unfortunately for the auditor, almost everyone today has a PC on his/her
desk and is linked to a network environment. If the network is secure (this should be
a rhetorical question.), then logical access (i.e. - passwords) should be effectively
established and monitored.
The objective of this chapter is to assist in minimizing the amount of time spent
reviewing the scores of network or operating system log files by consolidating
information and focusing the auditor’s view.
One word of caution - Keep these files secure. Username logins and related
information are highly sensitive and in the wrong hands, could lead to business loss.
It is okay to show hackers the door; it is not okay to then give them the key.
Although not thoroughly explored in this chapter, these ACL applications can be
used on telephone records. For example, Applications 4 and 5 search for unusual
times for login access. Employing these applications on a file of telephone usage
would detect weekend, after-hour, or all-day activity.
Electronic Data Processing Objectives

The following is a list of specific audit objectives for the electronic data processing
area along with the applicable report numbers. The auditor should attempt to obtain
reasonable assurance that the following objectives have been achieved by the
organization:
Logical Access is Properly Authorized and Updated Accurately
Report numbers: 1, 2, 3
Logical Access is Properly Monitored

Report number: 1, 2, 3, 4, 5
Electronic Data Processing Applications

Below are 5 applications containing 5 reports. The number of reports per application
and the difficulty level are referenced after each application.
1 Review activity reports for default usernames and usernames of

unrecognized or terminated employees.* (1) Novice
2 Review activity reports for users with no activity in an unacceptable period

of time. (1) Novice
3 Summarize access types by username. (1) Novice
4 Review the time of and length of login times.* (1) Intermediate
5 Review activity reports for login failures.* (1) Novice

Electronic Data Processing Data Files
(EDP_ACCESS_FILE) - A file detailing the access granted to each user of the

accounting system. It is used to process many of the EDP applications (see Chapter
10). Below is the data structure which is followed by a field explanation list:
Data Structure
18 Records using DPCCSSFL.FIL as the data file
Field Format Start Length Addtl.format

explanation
User_Name ASCII 1 10
Last_Login_Date DATE 11 6 PICTURE “yymmdd”
Activity ASCII 17 9
User_Name The name of the system user.
Last_Login_Date The date the user last logged into the system.
Activity The code for the access granted.

(EDP_ACTIVITY_FILE) - A file detailing the activity of access within the
accounting system for one week (9/16/96 to 9/22/96). It is used to process many of
the EDP applications (see Chapter 10). Below is the data structure which is followed
by a field explanation list:
Data Structure
58 Records using DPCTVTYF.FIL as the data file.

explanation
User_Name ASCII 1 10
Signon_Date DATE 11 6
Signoff_Date DATE 17 6 PICTURE “yymmdd”
Signon_Time NUMERIC 23 4 0 PICTURE “yymmdd”
Signoff_Time NUMERIC 27 4 0
Activity ASCII 31 9
Duration_Min NUMERIC 40 3 0
User_Name The name of the system user.
Signon_Date The date of a user login.
Signoff_Date The date of a user logoff.
Signon_Time The time of a user logon.
Signoff_Time The time of a user logoff.
Activity The code for the access granted.
Duration_Min The duration of access, in minutes.

Electronic Data Processing Verification Batch
EDP_ACC_VERIFY
Executed prior to using the EDP_ACCESS_FILE to:

“Command and Log” after batch processing to ensure that the command
yielded the response “0 data validity errors detected”. Please note the batch
will terminate processing at this point, with an appropriate user dialog box,
if the data has any invalid fields.
2 Selecting a sample of three user access levels to agree back to supporting

documentation for accuracy - Agree information per the file
EDP_ACC_SAMP to the supporting documentation. Please note, the
number of sampled items can be adjusted in the batch, if necessary.
batches, double-clicking on the EDP_ACC_VERIFY batch, and then clicking
SET SAFETY OFF

DELETE ALL OK
OPEN EDP_ACCESS_FILE
VERIFY FIELDS Activity Last_Login_Date User_Name
ERRORLIMIT 10
command or if there are less than three records in the file for sampling. If the data is
valid, processing will continue with EDP_ACC_VERIFY1 which is listed below.
Through the use of the “Assign” command below, EDP_ACC_VERIFY1 can be

used as a follow up to this and the EDP_ACT_VERIFY batch (the only change
required is the output file name for the sample file selected in EDP_ACC_VERIFY1
which is assigned individually in each “trigger” batch).
ASSIGN OUTPUTFILE=”EDP_ACC_SAMP”

COUNT
DO EDP_ACC_VERIFY1 IF WRITE1=0 AND COUNT1>=3
purposes‘ IF COUNT1<3
DELETE ALL OK
SET SAFETY ON
EDP_ACC_VERIFY1
COMMENT “THIS BATCH IS REFERENCED BY BATCHES

EDP_ACC_VERIFY AND EDP_ACT_VERIFY- SEE CHAPTER 3
RELATIVE TO VERIFICATION BATCHES FOR A FURTHER
DISCUSSION”
To select a sample of three user’s access for agreement to supporting information:
X=RAND(COUNT1)
SAMPLE ON RECORD RANDOM X NUMBER 3 RECORD TO %OUTPUTFILE%
OPEN %OUTPUTFILE%
EDP_ACT_VERIFY
Executed prior to using the EDP_ACTIVITY_FILE to:
and Log” after batch processing to ensure that the command yielded the
response “0 data validity errors detected”. Please note the batch will
2 Selecting a sample of three user access logins to agree back to

supporting documentation or discussed with management to assess its

accuracy - Agree information per the file EDP_ACT_SAMP to the
supporting documentation. Please note, the number of sampled items can
be adjusted in the batch, if necessary.
batches, double-clicking on the EDP_ACT_VERIFY batch, and then clicking
SET SAFETY OFF

DELETE ALL OK
OPEN EDP_ACTIVITY_FILE
VERIFY FIELDS Activity Duration_Min Signoff_Date
Signoff_Time Signon_Date Signon_Time User_Name
ERRORLIMIT 10
command or if there are less than three records in the file for sampling. If the data is
valid, processing will continue with EDP_ACC_VERIFY1 which is listed above.
ASSIGN OUTPUTFILE=”EDP_ACT_SAMP”
COUNT
DO EDP_ACC_VERIFY1 IF WRITE1=0 AND COUNT1>=3
purposes‘ IF COUNT1<3
DELETE ALL OK
SET SAFETY ON

Notes

Review activity reports for default Application 1
usernames and usernames of Batch: EDP_1
unrecognized or terminated employees Novice
Overview
This application tests for:
1 standard names such as “DEFAULT” or “TEST”. These IDs usually have

equally simple passwords for a hacker to guess.
2 unrecognized or terminated employees. This test focuses more on the

responsiveness within the EDP function to ensure that, at any point in time,
only authorized employees have system access.
The following field, currently in the EDP_ACCESS_FILE as included with this

Toolkit, is required to execute the following batch:
Required
User_Name

EDP_ACC_VERIFY batch.
It is possible to execute this application on the EDP_ACTIVITY_FILE as included

with this Toolkit, yet this analysis would detect questionable usernames only if they
were utilized during the time frame extracted.
Batch
batches, double-clicking on the EDP_1 batch, and then clicking “Run” in the
SET SAFETY OFF

To classify on the username (see the Audit Steps section below for procedures to
CLASSIFY ON User_Name TO USERS

OPEN USERS

SET SAFETY ON
Audit Steps
■ Review the USERS file for any ambiguous usernames such as DEFAULT,
TEST, SYSTEM, MANAGER and USER (to name a few). If detected,
recommend that the owner delete the username or change the default
password. In this step, it may be useful to review the software
documentation for those usernames (and passwords) used in the initial
installation. Also, verify that the system will not accept a blank password for
any of these usernames.
■ To ensure that all of these usernames are identified, utilize the MATCH()
function and Extract command as follows:
EXTRACT User_Name IF MATCH(User_Name, ‘TEST’, ‘SYSTEM‘,
‘MANAGER’, ‘USER’)>0 TO MATCHED

■ Obtain an employee list from the Human Resources Department and
reconcile it to the USERS file ensuring that all usernames relate to valid
employees. Any unrecognized or terminated employee names should be
deleted.
■ Review the USERS file for group usernames such as RECEIVABLES or
PAYABLES that correspond to the accounting function rather than the
individual accessing the system. If detected, recommend that the manager
delete these usernames and replace them with usernames specifically
identifying the accessing individual (i.e. - the first initial and last name of
the employee).
■ Review with the appropriate level of management:
1 the actions taken when an employee is terminated.
2 the established monitoring procedures with respect to user access the

authorizations required to add a user to the system.

Review activity reports for users with no Application 2
activity in an unacceptable period of time Batch: EDP_2
Novice
Overview
Raise your hand if you would like to review detailed access logs for users who have
not accessed the system in over thirty days. The objective of this application is to
identify those users who, considering they have not signed on within a acceptable
period, may not require access to the system.
The following fields, currently in the EDP_ACCESS_FILE as included with this

Required
User_Name
Last_Login_Date

The following fields, currently in the EDP_ACTIVITY_FILE as included with this
Toolkit, are also required to execute the following batch:
Required
User_Name
Signon_Date
EDP_ACT_VERIFY batch.
Batch
There are two distinct approaches to determine which users have not signed on in
the past thirty days. The first uses the EDP_ACCESS_FILE file to simply extract
based on the Last_Login_Date while the second uses the
EDP_ACTIVITY_FILE to extract those users who have not signed on during the
user defined time frame. The second approach is not as complete as the first
considering there may be users who have not signed on for periods longer than the
activity extracted in the EDP_ACTIVITY_FILE file. Thus, although the first
approach is the most complete, the EDP_ACCESS_FILE file at your location may
not always monitor the Last_Login_Date variable, thereby requiring the
second strategy to be executed.
Portion of the batch utilizing the EDP_ACCESS_FILE file as explained in the

above note:
SET SAFETY OFF
If using the data supplied with the Toolkit, you will record the date of the files used
by entering 19960922 (9/22/96) in the dialog box date field. The third box of the
dialog command is where you will define the acceptable time frame of inactivity:

DIALOG (DIALOG TITLE “User Dialog” WIDTH 532 HEIGHT 272 )
(BUTTONSET TITLE “&OK;Cancel” AT 36,28 ) (TEXT TITLE
“Date of Activity File (in yyymmdd format)” AT 36,112 )
(TEXT TITLE “Acceptable number of days of inactivity”
AT 36,196 ) (EDIT TO “DATEFILE AT 36,72 ) (EDIT TO
“DATE1” AT 36,144 ) (EDIT TO “DAYS” AT 36,228)
30 days is an appropriate response to the above Accept command if using the data
supplied with the Toolkit.
To extract users who have had no activity within the acceptable timeframe which
will be sorted in an ascending fashion (see the Audit Steps section below for
SORT ON Last_Login_Date D TO OLDER_ACCESS IF AGE

(Last_Login_Date,DATEFILE)>VALUE(DAYS,0)
Portion of this batch utilizing the EDP_ACTIVITY_FILE file as explained in the

above note:
The following Sort and Summarize commands will create a file of users with the
last date of activity (This will be used in a later Extract command):
SORT ON User_Name Signon_Date D to SORTED

OPEN SORTED
SUMMARIZE ON User_Name OTHER Signon_Date TO “SUMMARIZED”
The above three commands essentially create a file that reports the username and
last date he/she logged into the system, similar to the Last_Login_Date field
used in the EDP_ACESS_FILE file.
OPEN SUMMARIZED
To extract users who have had no activity within the acceptable timeframe which
will be sorted in an ascending fashion (see the Audit Steps section below for

OPEN EXTRACTED
SORT ON Signon_Date D TO OLDER_ACTIVITY IF
AGE(Signon_Date, DATE1)>30
OPEN OLDER_ACTIVITY
DELETE ALL OK
SET SAFETY ON
Audit Steps
■ Review the files OLDER_ACCESS and OLDER_ACTIVITY with the

appropriate level of management paying special attention to those users at
the beginning of the report. These should represent users that have not
accessed the system for the greatest amount of time (both files were sorted
in descending order as a final step).
■ Obtain an employee list from the Human Resources Department and,
similar to Application 1 in this section (Review for standard usernames and
usernames of unrecognized or terminated employees), reconcile it to the files
created ensuring that all usernames relate to valid employees as of the date
of the file.
■ Review with the appropriate level of management the actions taken when an
employee is terminated and the established monitoring procedures with
respect to user access.

Summarize access types by username Application 3
Batch: EDP_3
Novice
Overview
Anyone can have access to a system. Complications arise when this access allows a
user to effectuate unauthorized activity. If the foundation is set, through proper
authorization procedures (preferably written), then the structure can be erected
without fear of it crashing down.
The following field, currently in the EDP_ACCESS_FILE as included with this

Required
User_Name
Activity

Batch
resulting Message box. It is possible to execute this application on the
EDP_ACTIVITY_FILE as included with this Toolkit, yet this analysis would only
detect activities utilized during the time frame extracted. If you wish to execute this
batch on the EDP_ACTIVITY FILE file, edit the below command to open it
rather than the EDP_ACCESS_FILE file in the beginning of the batch.
SET SAFETY OFF

SORT ON User_Name Activity TO USER_ACTIVITY_SORT
SORT ON Activity User_Name TO ACTIVITY_USER_SORT
SET SAFETY ON
Audit Steps
■ Review the USER_ACTIVITY_SORT file (which will list each user

followed by the activities he/she may process) or the
ACTIVITY_USER_SORT file (which will list each activity followed by the
users who are allowed access) with the appropriate level of management to
assess whether access is appropriate for the user’s position in the
organization.
■ Obtain an employee list, which should include the department to which the
employee reports, from the Human Resources Department. Reconcile the
activities from the USER_ACTIVITY_SORT file to this listing. Discuss
with management any discrepancies or possible non-segregation of duties.
■ Discuss with the appropriate level of management the procedures for
granting a system activity to an employee and the established monitoring
procedures with respect to user access.

Review the time of and length of login Application 4
times Batch: EDP_4
Intermediate
Overview
A burglar finds it most easy to break in when no one is home. Similarly, the hacker or
other unauthorized individual prefer to process without a network manager
monitoring his/her activity. Aside from testing the relative time of access, this
application will also test the length of login times to assess whether users are logged
on for unreasonable amounts of time. This may signal unattended terminals (or
people who are chained to their desks for over 8 hours).
The following field, currently in the EDP_ACTIVITY_FILE as included with this

Required
User_Name
Signon_Date
Signon_Time
Duration_Min
Activity

Batch
resulting Message box. The batch is meant to review one set of weekends at a time, as
well as, search for any processing outside of the normal working hours for the entire
file under review. If using the sample data provided with the Toolkit, enter 960921
and 960922 (for the weekend of 9/21/96 and 9/22/96) in the following two Accept
commands.
SET SAFETY OFF

ACCEPT’First weekend day (in yymmdd format):’ to WD
ACCEPT’Second weekend day (in yymmdd format):’ to WD1
ACCEPT’Normal business opening hour (in 2400 format):’ to
OPEN
ACCEPT’Normal business closing hour (in 2400 format):’ to
CLOSE
GROUP
The next command will extract any user who signed on or off on a weekend date or
signed on or off after normal working hours (see the Audit Steps section below for
EXTRACT RECORD TO SUSPICIOUS_TIME_DATE IF

AGE(WD,Signon_Date)=0 or AGE(WD1,Signon_Date)=0 or
AGE(WD,Signoff_Date)=0 or AGE(WD1,Signoff_Date)=0 or
Signon_Time<VALUE(OPEN,0) or
Signon_Time>VALUE(CLOSE,0) or
Signoff_Time<VALUE(OPEN,0) or
Signoff_Time>VALUE(CLOSE,0)

The final command will extract any activity that was “left on” for more than eight
hours (see the Audit Steps section below for procedures to perform using the
resulting file):
EXTRACT RECORD TO OVER_EIGHT_HOURS IF Duration_Min>480

END
DELETE ALL OK
SET SAFETY ON
Audit Steps
Perform the following steps remembering that much of the reported activity should
relate to system intensive batch processing completed after hours when system
resources are at their highest capacity:
■ Review the SUSPICIOUS_TIME_DATE files with the appropriate level of

management to determine whether access, and the related activities, were
authorized during the non business hours.
■ Review the file OVER_EIGHT_HOURS with the appropriate level of
management to determine whether user terminals, with the respective
activities running, were left unattended.
■ Discuss with the appropriate level of management established monitoring
procedures with respect to user access.
■ Discuss with the appropriate level of management preventive procedures for
terminal access. One such procedure would be to institute a screen saver
password.

Notes

Review activity reports for login failures Application 5
Batch: EDP_5
Novice
Overview
A barrage of login failures (or “logfails”) due to incorrect passwords or usernames

can signal unwarranted attempts by outside individuals to enter the computer
system. Such attempts should be met and abated by the controls established with the
organization’s environment.
The following field, currently in the EDP_ACTIVITY_FILE as included with this

Required
User_Name
Signon_Date
Signon_Time
Activity

Batch
SET SAFETY OFF

If your system uses a different code for logfails than “LOGFAIL” substitute your
system code in the command below (be sure to enter the code in uppercase format as
in the below command).
To extract all logfails which will be sorted later in the batch on date and time (see the
SORT ON Signon_Date Signon_Time TO LOGFAILS IF

FIND (“LOGFAIL”
OPEN LOGFAILS
SET SAFETY ON
Audit Steps
■ Review the LOGFAILS file with special attention geared toward successive
logfails within a short time frame.
■ Any logfails which may signal an attempt to infiltrate the system should be
reviewed with the appropriate level of management.

■ Inquire as to the ongoing monitoring procedures with respect to logfails
and any system controls (i.e. - a control which will “lock” a user’s access
after three failed attempts).

Notes

Notes

Notes

Using Dialog Builders
With The Toolkit Chapter 11
Dialog Builder functionality lets you build custom dialog boxes for batches.
These boxes control how the batch is run by prompting the user for input and
selections. While you previously used the ACCEPT command to accept user input,
the Dialog Builder is more powerful by providing you with a full range of control
types including radiobuttons and checkboxes.
When a user selects options or types text in a custom dialog box, ACL assigns all the
input to variables. You can use these variables later in the same batch or in different
batches. Parameters such as dates, file names, or any information you need from the
user at the time the batch is run. For more details on variables, see ACL for Windows
Reference Manual, page 2-14.

Although practically all of the batches in this Toolkit can be made interactive, many
of the batches in the Toolkit already are accepting input from the user using the
ACCEPT command. These batches are as follows:
GENLED_7
ACCPAY_6
ACCPAY_9
ACCPAY_10
ACCPAY_13
ACCPAY_14
ACCPAY_18
PAYROLL_1
PAYROLL_3
PAYROLL_5
REVENUE_8
REVENUE_13
INVENTORY_5
INVENTORY_8
INVENTORY_9
PROPERTY_3
PROPERTY_4
EDP_4
The remainder of this chapter will demonstrate how a sample batch (PAYROLL_1)
can use this added functionality. For more information on the Dialog Builder, see
ACL for Windows Reference Manual, page .2-48.

Implementing Dialog Builder in the PAYROLL_1 batch
The PAYROLL_1 batch, starting on page 6.1.1, stratifies payroll related information
(e.g., payment amount, hours worked, etc.) which is selected by the user prior to
executing the STRATIFY and AGE commands. To execute properly, the batch needs
a cutoff date (the date of the last payment in the file) and a numeric field on which to
execute the STRATIFY command. As seen on page 6.1.3, the batch used two
ACCEPT commands (one for the cutoff date and one for the numeric field).
Using Dialog Builder, these two ACCEPT commands are replaced with a dialog box
by completing the following:
1 Click on Activate Overview window button
2 Double click on the word “Batches”, double click on the batch

“PAYROLL_1”, and Select “Edit”
3 In the Batch window, click on the Dialog command immediately below the
command “SET SAFETY OFF” and then click on the Dialog Builder
button to bring up the following screen:

(To accept the cutoff date and numeric field, we will be using the Text,
Editbox, and Dropdown Item List functionality of the Dialog Builder.)
4 To enter a Text box for the cutoff date, click on the Text button. When you
move your cursor into the definition area, your cursor changes to a box with
a plus at the top left corner. Click in the upper left corner of the definition
area and ACL displays the Text dialog box:
5 Type in the “Label” box “Enter the files’s aging date (YYYYMMDD)” as in
the above screen print and then OK.

6 To enter an Editbox for the cutoff date, click on the Editbox button. When
you move into the definition area, your cursor changes to a box with a plus
at the top left corner. Click underneath the textbox created in Step #4 above
and ACL displays the Editbox dialog box:
7 Type in the “Variable” box “age_date” as in the above screen print

and then OK.
8 To enter a Text box for the numeric field, click on the Text button. When you
move into the definition area, your cursor changes to a box with a plus at the
top left corner. Click under the editbox created in Step #6 and ACL displays
the Text dialog box:

9 Type in the “Label” box “Select field to age on” as in the
above screen print and then OK.
10 To enter a Dropdown Item List box for the numeric field, click on the
Dropdown Item List button. When you move into the definition area, your
cursor changes to a box with a plus at the top left corner. Click underneath
the textbox created in Step #8 above and ACL displays the Dropdown Item
List dialog box:
11 Type in the “Variable” box “STRFIELD”, select “Numeric

Fields” from the “Category” and Click on “Add”, as in the above
screen print. After completing these steps, click on OK.

Your screen should look as follows:
12 Close the dialog box.
13 Delete the two ACCEPT commands (since they have now been replaced by
the dialog box) by highlighting them and pressing the “Delete” key. Once
finished, close the batch, saving it as PAYROLL_1_NEW.
batches, double-clicking on the PAYROLL_1_DIALOG batch, and then clicking

Rich Lanza (CPA, CFE, PMP) enables organizations in the use of technology to (1)
generate cash recoveries, (2) stop profit leaks , (3) move away from control issues, and
(4) work towards process improvements. With automated report systems and
personalized coaching, Rich helps companies get quality results in minutes. This is done
by maximizing the technology companies already have and showing professionals how to
become “info magicians”. He is the author of numerous publications and training courses
in ACL, IDEA, Access, ActiveData, and Excel. While he has over 12 years of
experience and is a recognized leader in the use of technology, Rich also founded of
AuditSoftware.Net, a free website devoted to using technology for generating bottom line
results. To contact Rich, receive his free e-newsletter, or to order his products, e-mail
him at rich@richlanza.com or visit his website at www.infomagician.com.

101 ACL Apps

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

101 ACL Apps

Загружено:

Авторское право:

Доступные форматы

101 ACL Applications:

A Toolkit for Today’s Auditor

by Richard B. Lanza, CPA

© Copyright 2000 Richard B. Lanza All rights reserved 1

All rights reserved. Third edition.

Global Audit Publications

Global Audit Publications' mission is to provide a worldwide forum to disseminate innovative

LIMITATION OF LIABILITY/DISCLAIMER OF WARRANTY: THE AUTHOR, RICHARD B.

ACL for WindowsACL Services Ltd.

Excel, Word, WindowsMicrosoft Corporation

2 © Copyright 2000 Richard B. Lanza All rights reserved

101 ACL Applications: A Toolkit for Today’s Auditor

Table of Contents i-1

Read This First 1-1

Chapter 4: General Ledger

General Ledger 4-1

Copyright © 2000 Richard B. Lanza All rights reserved i-1

Chapter 5: Purchasing & Accounts Payable

Purchasing and Accounts Payable Management 5-1

i-2 Copyright © 2000 Richard B. Lanza All rights reserved

Copyright © 2000 Richard B. Lanza All rights reserved i-3

Chapter 6: Payroll Processing

Payroll Processing 6-1

i-4 Copyright © 2000 Richard B. Lanza All rights reserved

Billing Function and A/R Management Objectives 7-1

Copyright © 2000 Richard B. Lanza All rights reserved i-5

Inventory Objectives 8-1

i-6 Copyright © 2000 Richard B. Lanza All rights reserved

Property, Plant and Equipment Objectives 9-1

Chapter 10: Electronic Data Processing Review

Electronic Data Processing Objectives 10-1

Copyright © 2000 Richard B. Lanza All rights reserved i-7

Chapter 11: Using Dialog Builders With The Toolkit

Implementing Dialog Builder in the PAYROLL_1 batch 11-3

About the author

i-8 Copyright © 2000 Richard B. Lanza All rights reserved

© Copyright 2000 Richard B. Lanza All rights reserved i-9

The American Institute of Certified Public Accountants' (AICPA) Special

© Copyright 2000 Richard B. Lanza All rights reserved i-11

i-12 © Copyright 2000 Richard B. Lanza All rights reserved

2 Report: When we talk about a 'Report' in this book, we refer to the

3 Application: An ACL 'Application' refers to a single report or a

4 Batch: An ACL 'Batch' collection and grouping of ACL commands that

5 Document: An ACL 'Document' is a collection of ACL input file

© Copyright 2000 Richard B. Lanza All rights reserved i-13

■ Key Concepts (Pages 7 - 9)

i-14 © Copyright 2000 Richard B. Lanza All rights reserved

■ ACL User Guide

When contacting ACL concerning problems, be sure to have the following

© Copyright 2000 Richard B. Lanza All rights reserved i-15

Chapter 2: Continuous Auditing Procedures - This chapter outlines how certain

Chapter 4: General Ledger

Chapter 5: Accounts Payable

Chapter 7: Billing & Accounts Receivable

Chapter 9: Property Plant & Equipment

Chapter 10: Electronic Data Processing

Each application will then be presented in the following detail:

1) an overview for the application

2) the audit objectives supported

© Copyright 2000 Richard B. Lanza All rights reserved i-17

4) the applicable data validity batches that should be utilized

5) the actual batch with supporting explanatory paragraphs, if applicable

6) audit procedures to perform