Memorandum
To:
Michelle Diaz, PhD, CPA
From: Ashley Fontenot, Sarah A. Miller
Date: 3/12/2016
Re:
Analysis of Peachtree Internal Controls
Test Number
1
2
3
4
5
6
7
8
Test Description
Recording an
unreasonable amount
of hours for an
employee paycheck
Paying an amount
that exceeds the
amount of an invoice
Recording more
inventory items
returned than sold
Entering identical
check numbers for
multiple checks
Recording more
inventory items sold
than are on hand
Recording a negative
cash receipt
Recording a sales
invoice without an
invoice number
Recording a negative
paycheck
Strength of
Control
Risk Ranking
Significance
Reference
Page
Number
Nonexistent (0)
1
Most
Significance
5
Nonexistent (0)
2
Most
Significance
7
Nonexistent (0)
3
Moderate
Significance
9
Nonexistent (0)
4
Moderate
Significance
11
Weak (1)
5
Moderate
Significance
14
Nonexistent (0)
6
Moderate
Significance
17
Nonexistent (0)
7
Moderate
Significance
20
Nonexistent (0)
8
Low
Significance
22
1
2
9
10
Recording an invoice
without a vendor
invoice number
Recording an
unreasonably journal
entry
Strong (3)
9
Low
Significance
24
Strong (3)
10
Low
Significance
26
After reviewing and analyzing the Peachtree Accounting Software for Bellwether Garden Supply, we
conclude that Peachtree lacks several controls to make it an adequate accounting system. We
conducted ten tests to assess the strength of Peachtree’s application controls. The table above
summarizes the controls tested, and ranks the controls from most risky to least risky. Each of the
tests is discussed in more detail within this document.
Most Significance
We found that the application control that carried the most amount of risk was the recording of an
unreasonable amount of hours for an employee paycheck. This control bears the most risk to the
company because it carries a high possibility of fraud. There was no control on this application—
employees could input any number they wanted to record as the number of hours they worked. This
could have a detrimental effect on Bellwether’s financial statements. If employees enter their hours
worked into this application every other Friday, the frequency and possibility of this occurring is high.
A good control for this application would be a limit check for the number of hours worked.
The second most risky application is the paying of an amount that exceeds the amount of an invoice
made. This control is highly susceptible to fraud because a user of Peachtree could easily overpay the
invoice and then collect the overpayment that is sent back to the original company. This would affect
Bellwether’s financial statements because there would be an outstanding receivable from the
overpayment made, but it would never be collected because someone could have collected the
overpayment themselves. A limit check should be implemented so an overpayment should not be
possible.
Moderate Significance
The controls over recording more inventory returned than was sold proved to have moderate risk
associated with the transaction. Recording more inventory returned by a vendor than sold would
affect Bellwether’s financial statements because inventory would be overstated. To fix the lack of
control, Peachtree could implement a limit check within this application. The number of items
recorded as returned could be checked against the number of items the vendor purchased. A limit
would then be established for the number of items that vendor can return.
March 12, 2016
Entering identical check numbers for multiple checks was another control tested. There was no
control in place for this application. Although there would be no impact on Bellwether’s financial
statements if multiple checks had the same check number, there is an efficiency issue at risk. It would
be harder to trace checks if, for example, you had 10 #101 checks. This could create confusion for any
employee who used the information from processed checks. We recommend that all of the checks be
pre-numbered as a form of control.
We also found a moderate risk when trying to record more inventory sold than was on hand. This
could negatively impact the financial statements because the inventory account would be decreased
incorrectly and the revenues account would be increased incorrectly. This application had a weak
control, but it could be improved if a limit check was implemented. Although a limit check was found
in this application, the limit check did not stop the transaction from being processed. Our
recommendation is for the limit check to not allow the transaction to occur if more inventory is trying
to be sold than is on hand.
Recording a negative cash receipt was another transaction we found to have moderate risk. While
this application did not have any control in place, the likelihood of recording a negative cash receipt is
low. However, recording a negative cash receipt could negatively affect Bellwether’s financial
statements. We recommend implementing a sign check for this application, so that a negative cash
receipt could not be entered.
We tested whether we could record a sales invoice without an invoice number. There was no control
in place for this application. This would not affect the financial statements of Bellwether, but it would
create an efficiency problem. This could both internally and externally affect Bellwether. Internally,
this could cause confusion when trying to find a sales invoice. Externally, if a vendor asked for a copy
of their sales invoice and Bellwether could not find it, the vendor might become dissatisfied with
Bellwether’s customer service. A good control for this application would be to pre-number the sales
invoices.
Least Significance
Recording a negative paycheck was a control that we tested that proved to have weak controls, but
little significance. It is highly unlikely that an employee would try to record a negative paycheck.
However, if it were to happen, the paycheck would be noticed by whoever is reviewing their
paycheck. We would implement a sign check for this application, just in case someone accidently
tries to record a negative paycheck.
Recording an invoice number without a vendor number had very strong controls. An error message
appeared whenever we tried to complete this action. The only suggestion we have for improving this
3
4
application is to distinguish between the two invoice numbers on the form, “Customer Invoice No.”
and “Invoice No.” This could be done by changing the current field labeled “Invoice No.” to read
“Vendor Invoice No.” This would clarify the error message that reads “You must enter an invoice
number” since it does not specific which invoice number must be entered.
The least risky control tested was the recording of an unreasonable journal entry. We first tried to
enter different amounts for the debit and credit entries, but were then prompted by an error
message that told us we had an out-of-balance error. The application also forced us to enter accounts
to which the journal entries were posted. We have no recommendations for improving this control.
In conclusion, Peachtree has many weak controls of moderate significance. Many changes must be
made to Peachtree before it can be an adequate system. More detailed explanations of our controls
tested can be found in the following pages. A page number is referenced in the first table for your
convenience.
March 12, 2016
Test number 1: This test focuses on whether an unreasonable amount of hours can be accepted. We
took the following steps:
1) We input DCARTER as the Employee ID.
2) We input 9000 hours in the hours field.
Our input screen of our test data was as follows:
We selected “save” and the following screen appeared:
5
6
Assessment—There appears to be no control for entering an unreasonable amount of hours because the
program saved our entry. We would therefore rate this control as 0, or nonexistent. A good control for this
application would be a limit check.
March 12, 2016
Test Number 2: This test focuses on whether an unreasonable payment amount can be applied to an
invoice. This is accomplished by entering a payment amount that exceeds the amount of the invoice.
We performed the following steps:
1) We input AKERSON as the vendor.
2) We checked the pay box for both invoices, and entered the full amount to be paid to invoice
A-7811 and an amount exceeding the amount due ($2000 > $1686.25) for invoice A-6411.
3) We accepted all other defaults.
Our input screen of our test data was as follows:
We selected “save” and the following screen appeared:
7
8
Assessment: Because the program allowed us to save the payment, there was a lack of controls. We
would therefore rate this control as 0, or nonexistent. A good control to have here would be a limit
check, which should prevent the amount paid from exceeding the amount due.
March 12, 2016
Test Number 3: This test determines whether an unreasonable number of returned items may be
accepted in a credit memo. This is accomplished by entering a higher number of returned items than
sold items. We performed the following steps:
1) We selected ARCHER as our customer.
2) We input the following information: Credit No. = 12345, Customer PO = 123, Return
Authorization = Me, Apply to Invoice No. = 10209, Quantity Returned = 22 (note that this is
higher than the quantity sold, 20), and accepted all other defaults.
Our input screen of our test data was as follows:
We selected “save” and the following screen appeared:
9
10
Assessment: Because the program accepted our save, there appears to be no control over the
amount of items that can be returned. We would rate this control as a 0, or nonexistent. A good
control to use here would be a limit check to restrict the number of items returned to no more than
the number of items sold.
March 12, 2016
Test number 4: This test determines whether two checks may be created having the same check
number. This is accomplished by creating checks for two vendors with identical check numbers. We
performed the following steps:
1) We selected CLINE as our vendor.
2) We input the Check Number as 765, clicked the Pay box, and accepted all other defaults.
Our input screen of our test data was as follows:
3) We selected “save” and submitted the check.
4) We selected vendor CLOONEY.
5) We input the Check Number as 765, checked both Pay boxes, and accepted all other defaults.
11
12
Our input screen of our test data was as follows:
We selected “save” and the following screen appeared:
March 12, 2016
Assessment: The program allowed us to create two checks with the same check number. We would
therefore rate this control as a 0, or nonexistent. There is an efficiency issue at risk here. Multiple
checks with the same number could be created and cause confusion. A good control to implement
here would be to have the program pre-number the checks.
13
14
Test Number 5: This test focuses on whether more inventory items can be sold than there are on
hand. This is tested by recording the sale of too many items to Dash. We took the following steps:
1) We selected the Customer ID “Dash” and then went to the item category.
2) Selected “Bird house kit” (“AVRY-10100”) and tried to order 1000 birdhouses.
Our input screen of our test data was as follows:
3) We typed “1000” in the quantity category and we were prompted the following message:
March 12, 2016
We selected “save” and the following screen appeared:
15
16
Assessment: The program allowed us to place an order from a vendor for more inventory than was on
hand. We would therefore rate this control as 1, or weak, because there was a control in place (the
error message), but I was still able to process the transaction. A good control to implement here would
be a limit check so that we could not place an order for more inventory than was on hand.
March 12, 2016
Test number 6: This test focuses on the adequacy of internal control over recording cash receipts.
We tested this by trying to record a negative cash receipt from customer SEAWRIGHT. We took the
following steps:
1) We chose customer “Seawright” from the Customer ID field.
Our input screen of our test data was as follows:
2) We then entered a “-100” in the amount paid field.
17
18
We then saved the entry.
March 12, 2016
Assessment: Based on this result, there was no control for entering a negative cash receipt. We
would therefore rate this control as 0, or nonexistent. This control could be improved if a sign check
was implemented as a control.
19
20
Test number 7: This test determines whether an incomplete sales invoice form may be submitted.
This is accomplished by leaving the Invoice No. field blank. We performed the following steps:
1. We selected KENTON as our customer.
2. We input the following information: Customer PO = 001, Ship Via = UPS Ground, Ship Date =
Mar 19, 2007, Quantity = 1, Item = AVRY-10100, and accepted all other defaults.
3. We intentionally left the Invoice No. field empty.
Our input screen was as follows:
We selected “save” and the following screen appeared:
March 12, 2016
Assessment: Because the program accepted our save, there appears to be no control ensuring that
the invoice number must be entered. We would therefore rate this control as a 0, or nonexistent. A
good control to use here would be pre-numbering the invoices for a particular customer to prevent
someone from forgetting to enter this information or accidentally entering wrong information.
21
22
Test number 8: This test determines whether a negative paycheck amount can be paid. We
performed the following steps:
1) We selected VANSELL as our employee.
2) We input “-9000” in the salary field.
Our input screen of our test data was as follows:
We selected “save” and the following screen appeared:
March 12, 2016
Assessment: Because the program accepted our save, there appears to be no control with this
application. We would therefore rate this control as a 0, or nonexistent. A good control to use here
would be a sign check, so that a negative cash receipt could not be entered.
23
24
Test number 9: This test determines whether an incomplete invoice form may be submitted. This is
accomplished by leaving the vendor Invoice No. field blank. We performed the following steps:
1. We selected CALDWELL as our vendor.
2. We input the following information: Customer Invoice No. = 1234, Apply to Purchase Order
No. = e2, and accepted all other defaults.
3. We intentionally left the Invoice No. field blank.
Our input screen of our test data was as follows:
We selected “save” and the following message appeared:
March 12, 2016
Assessment: The program would not let us save the invoice without a vendor invoice number. We
would therefore rate this control as a 3, or strong. One suggestion we have is to label the field as
“Vendor Invoice No.” because there is a “Customer Invoice No.” field on the same screen. The error
message should be updated to say “vendor invoice number” to avoid confusion about which invoice
number needs to be entered.
25
26
Test number 10: This test determines whether an unreasonable entry can be recorded. We took the
following steps:
1) GL Account 10100 was selected.
2) “This is a test” was entered into the description.
3) $11,111 was the amount entered as the debit, $222,222,222 was the amount entered as
the credit.
4) “CHAPPLE,02-Permits” was entered as the job for the debit entry.
5) “MORTON” was entered as the job for the credit entry.
6) We selected “save” and the following message appeared:
March 12, 2016
Assessment: The program would not let us save the general ledger entry until the credit amount and
the debit amount were equal. We would therefore rate this control as a 3, or strong. We have no
suggestions for improving this control.
27