To:
From:
Date:
Re:
Message:
Dr. Michelle Diaz
Alicia Washington
Jeremy Fleenor
Derek Richard
Gabrielle Naquin
Thomas Fry
February 12, 2009
Peachtree Internal Control Assignment
The purpose of this audit is to ensure that proper internal controls exist within the Peachtree
Framework. Our team tested ten controls, shown below with their purpose and description. Based on a
scale from zero to three, zero being no controls existed to three being sufficient controls exist, our team
rated each control. The controls are ranked from one to ten, one being the most critical and ten being the
least critical control. This is based on what fraudulent risks are present, and if adequate controls existed
the importance of improvement.
Here is the chart of controls tested:
Test
No:
13
Critical Ranking
Description/Purpose
1
If new vendor can be created while
making cash disbursements
16
2
0
7
3
20
10
4
5
5
6
6
7
2
8
If paycheck can be accepted with an
unreasonable amount of hours
If negative cash receipt can be
recorded
If previous transactions can be deleted
If amount can be paid that exceeds
invoice amount
If more inventory items can be
returned than were actually sold
If negative inventory items can be
returned.
If invoice number is required
19
9
3
1
10
If general journal entry must be
balanced to record
If invoices can have duplicate numbers
Page |1
Performance
Rating
0
0
1
0
1
1
0
3
Risks Present/Importance
Accounts Payable clerk can create
fictitious vendor and make
fraudulent payments
Payroll clerk can overpay an
employee
Sales clerk can pocket extra cash
received
Employee can erase past data
Purchasing clerk can pay more
than the company owes
Employee can over credit a
customer’s account
Sales clerk can overcharge a
customer
Sales clerk can record transaction
with no reference number
Controls sufficient, could make
more easy to calculate difference
Controls sufficient, could
automatically assign invoice
number
Based on the test performed, the following controls were given a critical ranking due to the level of
potential fraud risk. Test number 13 was critically ranked one and received performance rating zero, because an
accounts payable clerk can create a fictitious vendor and make fraudulent payments. Test number 16 was critically
ranked two and received performance rating zero, because a payroll clerk can overpay without raising suspicion.
Test number seven was critically ranked three and received performance rating zero, because a salesperson could
record a negative cash receipt for a customer and pocket the money. Test number 20 was critically ranked four and
received performance rating zero, because allowing users to delete invoices enables employees to pocket money
from customers and delete the invoice associated with the payment. Test number 10 was critically ranked five and
received performance rating zero, because a purchasing clerk would be able to successful fraudulently state that
they paid a vendor an amount greater than the total of the purchase. Test number 5 was critically ranked six and
received performance rating zero, because an employee can over credit a customer’s account. Test number 6 was
critically ranked seven and received performance rating zero, because a sales clerk can overcharge a customer.
Test number 2 was critically ranked eight and received performance rating zero, because a user can forget to
assign an invoice number to the invoice resulting in incomplete and inaccurate records.
The following tests showed sufficient controls in place to prevent, detect, or correct fraudulent
misstatements; however, improvement is important to keep these controls up to date. Test number 19 was
critically ranked nine and received performance rating zero, because sufficient controls were present. However,
the system could be automated making less chance for errors. Test number one was critically ranked ten and
received performance rating zero, because sufficient controls were present. However, invoice numbers could be
automatically assigned lowering the chances of an invoice number being omitted or duplicated. Out of the ten
controls tested, Peachtree Internal Control Framework only successfully passed two tests. Therefore, our audit
team rates Peachtree, based on a scale from zero to ten, a two.
Page |2
Test number 13 – The purpose of this test is to see if a new vendor can be added while making cash
disbursements. The following steps were taken:
1) To create a new cash disbursement follow this menu path:
Vendor& Purchases >> Pay Bills>>Pay Bill.
2) For Vendor ID, select the drop down menu key.
The following screen appears:
3) Enter the following information: Vendor ID=DUKE, Expense Account=10100-Cash On Hand.
4) After clicking “Save,” the user is returned to the main cash disbursements screen.
5) Enter the following information: Quantity=3, Unit Price=500
Here is the cash disbursement created:
Page |3
Assessment: Based on the results of the test performed, there seems to be insufficient controls for
making payments. On a scale from zero to three, our team would rate this zero, because the software
allowed the user to go into payments, create a fictitious vendor, and send phony vendor payments.
There should be a control in place to only let authorized personnel of the company add new vendors.
Also there should be a control in place for someone to review the payments to all new vendors, making
sure that no employee has created a “new vendor” only the have payments shipped to the employee.
Test Number 16 - The purpose of this test was to see if a paycheck can be accepted with an
unreasonable amount of hours. The following steps were taken:
1. To create a paycheck, follow this menu path:
Employees & Payroll Module >> Pay Employees >> Enter Payroll for One Employee
2. For Employee ID, choose “DCARTER.” Enter 90,000 in the regular hour’s field.
Here is the input screen for the invoice created:
After selecting “Save,” the paycheck entered the system, and the following screen appeared:
Page |4
Assessment: Based on the results of the test performed, there appears to be insufficient controls set in
place. Based on a scale from zero to three, our team would rate the control a zero. A user is able to
enter 90,000 hours for DCARTER for a bi-weekly pay period. Considering that there are only 80 regular
hours in a bi-weekly pay period and 336 in two calendar weeks, 90,000 hours seemed significantly
unreasonable. A payroll clerk would be able to overpay employees by grotesquely large amounts. I
recommend instituting a control that would prevent payroll entry clerks from entering more than the
number of hours allotted in a week to be paid.
Test number 7- The purpose of this test was to see if a negative cash receipt can be recorded. The
following steps were taken:
1. Create a cash receipt by following this menu path:
Tasks>> Receipts
2. By Customer ID pick SEAWRIGHT from the dropdown menu. Enter -600 under cash receipt and
the following data: Reference= 2, Receipt Number= 13, Payment Method= cash, and accept all
other defaults.
Here is the input screen for the cash receipt I created:
Page |5
After clicking “save” the following screen appears:
Assessment- Based on the results of the test performed, there appears to be insufficient controls
stopping a user from applying a negative payment to the amount due. On a scale from zero to three,
our team would rate this control a zero, because a user can apply a negative payment, thus increasing
the customer’s amount due, even though the customer has not bought anything to increase this
Page |6
amount. There should be a control in place that does not allow a user to record a cash receipt that is
less than zero. An error message should appear and read “only cash receipts greater than 0 can be
recorded.”
Test number 20 – The purpose of this test was to see if users have the ability to delete existing
transactions such as a sales invoice. The following steps were taken:
1. To open an existing invoice follow the menu path:
Customer & Sales >> Sales Invoices >> View and Edit Sales Invoices
2. In the Sales Invoice List, find and open invoice number 10225 for Seawright.
After selecting delete, the following message was shown:
After clicking “Yes” the invoice information is cleared as it is now permanently deleted from the system.
Now when I access the Sales Invoice List, invoice number 10225 is nowhere to be found.
Page |7
Assessment: Based on this results of the test performed, there seems to be insufficient controls to
prevent users from deleting existing invoices. On a scale from zero to three, our team would rate this
control a one, because while it may prevent invoices from being deleted accidentally it does not prevent
them from being deleted intentionally. By giving the user a warning message to confirm the delete, the
control at least insures that users do not accidentally delete an invoice by inadvertently hitting the
delete icon from the invoice screen. However the control does not prevent a user from committing
fraud and deleting an invoice intentionally. In order to improve this control, the delete function should
only be available to the system administrator. This would help prevent invoices and other transactions
from being removed from the system.
Test Number 10 – The purpose of this test was to see if an amount can be paid at the time of purchase
that exceeds the amount of the invoice. The following steps were taken:
1) To create a new invoice, follow this menu path:
Vendors & Purchases >> Enter Bills >> New Bill
2) For Vendor ID field, choose “HAWKINS”. Enter the following information: Invoice
Number=TEST1, Quantity= 1, Item= AVRY-10100 Birdhouse, Amount Paid at Purchase= 80.00,
Reference=TEST1, and accept all other defaults.
Here is the input screen for the invoice created:
Page |8
After selecting “Save,” the overpaid invoice entered the system, and the following screen appeared:
Assessment: Based on the results of the test performed, there appears to be insufficient controls in
place. Based on a scale from zero to three, our team would rate the control as a zero. A user will be able
to enter amounts greater than the purchase. In some cases it may be accidental like keying 1500 in
error when keying 150 was intended. In other cases, entering an amount greater than the invoice total
could be fraudulent. It would be easy to commit such a fraud since there is not a control in place to
allocate the overpaid amount to other outstanding invoices while enter the new invoice. Our team
Page |9
recommends putting a control in place that will prevent entering amounts greater than the invoice
amount without referring to a credit memo issued by the overpaid vendor or allocating the overpaid
amount to other outstanding invoices.
Test number 5 – The purpose of this test is to see if inventory items could be returned than were
actually sold. The following steps were taken:
1) To create a new credit memo follow this menu path:
Customer & Sales >> Credits and Returns>>Credit Memo.
2) Enter the following information: Customer ID=Archer, Apply to Invoice No= 10329,
Item=LAND-17800, Returned=3, and accept all other defaults.
Here is the input screen for the credit memo created:
After clicking “Save,” the following message appeared:
After clicking “Yes,” the credit memo saved and posted with no other problems.
P a g e | 10
Assessment: Based on the results of the test performed, there appears to be insufficient controls for
posting credit memo information. On a scale from zero to three, our team would rate a one to this
control, because although it notified that the credit was more than the customer had due, it still allowed
the user to register the information and give ARCHER credit for items not purchased. In some instances
it may be required to credit the customer with extra credit on his account, but it does not happen often;
therefore, authorization should only be given to an administrator.
Test number 6 – The purpose of this test was to see if a negative amount of inventory item can be
returned. The following steps were taken:
1) To create a new credit memo follow this menu path:
Customer & Sales >> Credits and Returns>>Credit Memo.
2) Enter the following information: Customer ID=Archer, Credit No=CCM10317, Apply to
Invoice No=10317, Returned= (-5), and accept all other defaults.
Here is the input screen for the credit memo created:
P a g e | 11
After selecting “Save”, the following message is shown:
After clicking “Yes”, the screen proceeds to a new Credit Memo. The Customer Ledger is shown below to
show that the negative credit (therefore debit on the journal entry) was posted to the customer’s
account. Notice also that the indicated Credit Memo seen on the Credit Memo List is shown as applied.
Assessment: Based on the results of the test performed, there appears to be insufficient controls for
posting credit memo information. On a scale from zero to three, our team would rate a one to this
P a g e | 12
control, because although an error message was shown, the data was still allowed to be posted as
originally entered. Under normal business circumstances, a negative inventory return would not occur. A
user might need to enter a negative inventory in order to reverse a previously posted mistake; however,
an administrator’s authorization should be necessary. Either the control should not allow the entry to be
made or require an administrative user to properly authorize the entry.
Test Number 2 – The purpose of this test was to see if an invoice number is required in recording a sale.
The following steps were taken:
1. To create a sales invoice follow the menu path:
Customer & Sales >> Sales Invoice >> New Sales Invoice
2. For Customer ID, choose KENTON from the drop down list. The information for Kenton Golf &
Tennis center is loaded into the invoice. Enter item number AVRY-10100 to create a proper
invoice for testing the control.
3. After the invoice has been filled out, click the “save” icon without entering an invoice number.
To check that the invoice was saved into the system, look for an invoice for KENTON in the Sales Invoice
List. As you can see, the KENTON invoice for 139.09 has been saved without an invoice number.
P a g e | 13
Assessment: Based on the results of the test performed, there seems to be insufficient controls for
preventing invoices from being saved without an invoice number. On a scale from zero to three, our
team would rate a zero to this control, because it is inadequate in ensuring invoice numbers are
assigned to every invoice. Invoice numbers are very important for company records and keeping track of
different orders to each individual customer. Since it can be very easy for someone to forget to assign an
invoice number, the system should have a control making it mandatory to enter an invoice number
before saving the invoice.
Test number 19 – The purpose of this test was to see if an out of balance general journal entry can be
recorded. The following steps were taken:
1) Create new journal entry by following this menu path:
Company module>>General Journal Entry
2) Enter the following information: Reference=1, GL Account #1= Other Expense Acct 5800000, Description= Sales Clerk Till Off by Minimal Amount, Debit= 20, GL Account #2= Petty
Cash 10000-00, Description= Sales Clerk Till Off by Minimal Amount, Credit= 2, and accept
all other defaults.
Here is the input screen for the general journal entry created:
P a g e | 14
After selecting “Save”, the following message is shown:
After clicking “Ok”, I am returned to the journal entry and allowed to correct the mistake.
Assessment: Based on this result, there appears to be sufficient controls that tests and ensure the
journal entry’s debits and credits balance. On a scale from zero to three, our team would assign a three
to this control, because I was unable to post a journal entry that was unbalanced. As well as a control
that does not allow unbalanced journal entries, there is also a callout formula when posting journal
entries that continuously shows a user whether or not the debits and credits are balanced, as well as
what the potential discrepancy is. We believe it might be beneficial for the program to automatically
assume that each line in the entry is meant to balance the journal; similar in the way it assumes that the
descriptions for each line match the entire entry. For this example, after entering in the information for
the first line associated with the Other Expense Account and choosing the Petty Cash Account for the
second line, once the user chooses the Credit cell, it would automatically post 20 and the user would be
free to change it if desired. Also, if the user still posted 2, once a third line was created it would
automatically post 18.
Test number 1- The purpose of this test is to find out if a sale can be recorded using a duplicate invoice
number. The following steps were taken:
1. Create an invoice by following this menu path:
Tasks>> Sales/Invoices.
2. Enter the following information: Invoice No. = 1, Customer PO= 471, Quantity= 1,
Item=AVRY-10100 and accepted all other defaults.
3. Click save, a new invoice is created.
4. Enter the following information: Invoice No. = 1, Customer PO= 471, Quantity= 2,
Item=AVRY-10110 and accepted all other defaults.
P a g e | 15
Here is the input screen for the two invoices:
After selecting “Save” for the second invoice, the following message is appears:
Assessment- Based on the results of the test performed, there appears to be sufficient controls that
ensure a duplicate invoice number cannot be recorded. On a scale from zero to three, our team would
rate this control a three, because it successfully prevents recording a sale with an invoice number that
had already been used. The content of the error message could be stronger by including the next
available invoice number.
P a g e | 16