Vendor Management & AP Audit Report - Data Mining & Analytics

Vendor Management & Accounts Payable Audit Report
Semi-Elite Properties, LLC
ACC 637
DR. Willie Reddic
Winter 2018
Audit Staff
Taylor Provenzano
Claire O’Connor
Shonzetta Carpenter
Yu Sun
Yifan Yu
Teri Grossheim

Table of Contents
Executive Summary 2
Introduction 2
Objective 2
Scope 2
Approach of the Problem
Opinion 3
Data Extracts 3
Findings 3
1. Orders must be placed and invoices received before payments can be made. 3
2. Employees can only place and authorize purchase orders for amounts within their
defined authorization limits 4
3. Payments can only be issued to addresses that exist on the Vendor Master file. 5
4. Payments must be made within a timeframe consistent to terms agreed upon with
suppliers. 6
5. Orders cannot be placed and payments cannot be made to inactive vendors. 7
6. An invoiced amount can only be paid once to a vendor. 7
7. An invoiced amount cannot be paid to multiple vendors. 9
8. Vendors Should Be Inactivated After One Year of No Payment History 9
9. Employees Cannot be Designated as a Supplier Within the Vendor Master File 10
10. Vendors may have multiple, active vendor records as long as mailing/remit to
addresses are different 11
11. Vendors with multiple vendor records may have the same Tax ID and different
vendor entities should not have the same Tax ID within the Vendor Master file 11
Concluding Remarks 12
Appendix 13
Page 1 of 20

Executive Summary
Introduction
Semi-Elite Properties, LLC (SEP) recently acquired a real estate company within the
past few years. Since the merger, there have been no audits performed on their
systems. After the acquisition, there is no documentation or settings of the Accounts
Payable software the client could utilize to better implement controls. There have also
been no preventive, detective or documented controls for this process. Therefore, our
audit team will be performing an audit of the Accounts Payable and Vendor
Management processes to obtain a better understanding of the risk SEP faces and any
gaps in existing controls.
Objective
Semi-Elite Properties, LLC (SEP) is currently considering an initial public offering and as
a result, this report serves as a starting point for analysis and recommendation for an
accounts payable assessment. The goal of this report is to provide SEP with a systemic
foundation for audit controls using data analytics techniques. The tests outlined in this
report reflect observations and findings that Dunne, Wright, and Phast LLP (DWP)
thought were relevant to the stated objectives, in an effort to support a comprehensive
assessment strategy. The assessment of the accounts payable system should be one
of many tools SEP leverages while preparing for an initial public offering.
Scope
The scope of the audit will encompass the Accounts Payable and Vendor Management
processes. The audit period will include January 1, 2014 to December 31, 2016 due to a
lack of audit after acquisition and increased risk of Accounts Payable systems.
Approach of the Problem
DWP’s approach to recommending an accounts payable assessment is based on
accounting principles and data analytics. After identifying and retrieving important data
extracts, DWP reviewed and analyzed important business rules that are important to the
integrity of the accounts payable system, which are outlined in the Findings section this
report. Data analytics were used in a test factual information, in an effort to determine
the integrity of each business rule. Depending on the test results, recommendations
have been made for SEP to take action on, serving as the basis of the accounts
payable assessment.
Page 2 of 20

Opinion
After close consideration of all of the objectives and assessing risks within the
company’s protocols, a qualified opinion must be issued. This is due to scope limitations
as well as evidence of weak controls within the accounts payable and vendor
management processes. Once all information is received, we can proceed with the audit
of the company’s protocols.
Data Extracts
Employee Master 1019 Final
Payment Authorization Limits 1019 Final
Vendor Master 1019 Final
Payment History 1019 Final
Findings
1. Orders must be placed and invoices received before payments can be made.
Objective: To identify records in which the pay date precedes the order date as well as
the invoice date.
Test: An extraction of data was used within the payment history file to extract all
payment dates that came before order and invoice dates. A copy was obtained of the
Payment History file that contains invoice number, payment date, invoice date, order
date, purchase authorizer, etc. Idea was then used to create an extraction with the
formula “Payment Date < Invoice Date OR Payment Date < Order Date.” The
observations were recorded and analyzed. The Payment History file was then joined
with the Employee Master file in order to see if the employees that approved the records
went over their authorization limit.
Findings: The Payment History file has a total of 96,298 records in it. There were a total
of 6 records found in which the payment date preceded the order or invoice date. All of
the records found were negative (payments), paid by check and were RV documents.
When the files were joined, it was found that all employees except one were over their
limits when they approved the transactions. The records found can be referenced in
Appendix A-2.
Cause of the observation: Having payment dates that precede order and invoice dates
could be due to human error and a weakness in the inputting system.
Page 3 of 20

Recommendations: An automated system should be put in to counter these
weaknesses in the accounts payable process. The system would not allow a payment to
be made before an invoice or order date. Even though only 6 records were shown to go
against this protocol, it still shows a weakness in controls. All records should be further
looked into in order to rule out any possible fraudulent behavior because this could be
due to human error.
2. Employees can only place and authorize purchase orders for amounts within
their defined authorization limits
Objective: To identify any records in which an employee approved an amount that was
greater than what they are authorized to approve.
Test: Join analysis was used in order to join certain data. A copy of Payment
Authorization Limits file, Employee Master file and Payment History file were obtained.
In Idea, a join was performed between the Employee Master file and the Payment
History file in order to get an idea of which employees approved which payments. A join
was then performed between the above joined file and the Payment Authorization Limits
file to compare the payments made and the authorization limits. The absolute value of
the payments was appended to the file because regardless of whether or not the entry
is a reversal or a payment, it should not exceed the employee’s limit. An extraction was
made with the formula “Payment > Authorization Limit.” All records were recorded and
summarized to show which employees went over their limit the most often. The records
found as well as the summarization can be found in Appendix A-1.
Findings: There were a total of 34,881 records found that were above the authorization
limit. This was then summarized to find which employees most often went over their
limits and there were 11 employees that had over 1,000 records of going over their limit,
payment or reversal. 43 different employees were found to go over their limits.
Cause of observation: Having many records that go over authorization limits shows a
fault in the inputting system once again.
Recommendations: An automated system should be put in to counter these
weaknesses in the accounts payable process. This will restrict users from inputting
payments greater than their authorization limit. A control should be put into place so that
if a payment must be made over an employee’s limit, the employee’s direct superior
Page 4 of 20

must approve it. It is also recommended to look into the employees that went over their
limits a large amount of times to rule out any fraudulent behavior.
3. Payments can only be issued to addresses that exist on the Vendor Master file.
Objective: To ensure that our client, Semi-Elite Properties, LLC, is properly following
their protocol around vendor management, we have decided to test for authorized
vendors. If payments are made to unauthorized vendors, that is not who the client
typically does business with and may be a flag for potential misappropriation of assets.
Controls need to be in place to prevent unauthorized payments from occuring so the
company does not affect income.
Test: Using Caseware IDEA, one way to test this objective is by joining the Vendor
Master File to the Payments History file by addresses, a form of unique identifier.
Oftentimes when dealing with addresses, it is extremely easy to input different versions
of the same address, such as using “Ave.” verses “Avenue”. To help avoid this
discrepancy, we looked at the first 10 characters of the addresses and checked to see
which vendors did not match to the vendor master file.
Findings: The test resulted in 7 payments that were made to unauthorized addresses.
This amounts to less than a percent of all payments. However, three of the payments
were made to vendors with similar names and amounts. The vendors are “Quis
Accumsan”, “Quis Tristique Ac Ltd”, and “Quisque Tincidunt PC” for payments between
$5,400 and $7,800. This does not automatically indicate fraud, however there should
definitely be further investigation. See Appendix B for results.
Cause of Observation: As there are not many unauthorized payments by vendor
address, the control is operating effectively. However, the three similar payments to
vendors should be further investigated.
Recommendations: Because there were not many payments made to vendors with
unauthorized addresses, the only recommendation would be to communicate the
policies and procedures around payment processing to vendors, and re-train the
employees that authorized these payments.
Page 5 of 20

4. Payments must be made within a timeframe consistent to terms agreed upon
with suppliers.
Objective: Payments must be made within a timeframe consistent to terms agreed upon
with the suppliers. When conducting business with vendors, they want to ensure they
are getting paid, as do all businesses. Therefore, the client’s trusted vendors may
choose to terminate their contracts. For this reason, a test was designed to indicate if
there were any payments that are aging greater than the payable terms specified by
each vendor.
Test: By joining the Payment History dataset to the Vendor Master File, we are able to
compare the age of the purchases that have not been paid to the payable terms
established by individual vendors. When joining the files by matching addresses
similarly to test #3, the dataset needed to be filtered by payments that were older than
their agreed upon terms.
Findings: The result is that there were 38,218 payments aging greater than the vendor’s
payable terms.The greatest payment belongs to the vendor “Aliquam Arcu Aliquam
Company” overdue by 9 days for the amount of -$330,205.49. This means that
Semi-Elite Properties, LLC. is not paying invoices on time. More descriptively, for the
past two years about 40% of the purchases are paid late. See Appendix C for results.
Cause of Observation: The material amount of late payments could potentially affect our
client if vendors choose not to do business with our client. If they establish a reputation
for not paying their invoices on time, it will be harder to build inventory and operate
effectively for the company’s customers.
Recommendations: Due to this material finding, the client should enhance their payment
processing controls to contain timely restrictions for paying vendors. A payment aging
team should be put in place to pull weekly reports of aging payments and ensure that
they are paid on time. The client may also choose to re-train employees on how to
process payments timely.
Page 6 of 20

5. Orders cannot be placed and payments cannot be made to inactive vendors.
Objective: To identify orders placed and payments made to inactive vendors for the
period from May 1, 2014 through May 16, 2016.
Test: The matching of transactions based on certain variables (Vendor Name, Order
Date and Status) was used to detect duplicate records. A copy of the Vendor Master file
was obtained containing active and inactive vendors and Payment History file of
payments processed during the analysis period. Stata was used to join the Vendor
Master File to the Payment History file using Vendor Name as the criteria and dropping
records with an “Active” status. The results were then exported into Excel where a
TRUE/FALSE formula was generated identifying records where the Order Date is less
than (<) the Inactive Date.
Findings: The Vendor Master file contained 10,143 records and the Payment History
File contains 96,298 payments for a total of 104,780 merger records between the
subject time period. After inspecting the file, it was discovered that there were 78
payments paid to 53 inactive vendors totaling $241,148. Appendix F-1.
Cause of observations: Based on the analysis of the file, payments to inactive vendors
appear to be an inadequate procedure issue.
Recommendations: Develop policy and procedures over the AP system and ensure all
employees comply. A lookup first policy/procedure should be instituted before the AP
team place orders to ensure that orders are placed from active vendors. Vendor file
should be linked to the ordering file where an error would result in orders placed to
inactive vendors. Also, periodically audit the vendor file with the payment file, to timely
determine if orders are being placed and payments being made to inactive vendors.
6. An invoiced amount can only be paid once to a vendor.
Objective: To identify duplicate payments made to vendors for the period from May 1,
2014 through May 16, 2016.
Test: The matching of transactions based on certain variables (Vendor Name, Order
Date, Invoice Date, Payment Date, Payment Amount and Payment Number) was used
to detect duplicate records. A copy of the Payment History master file of payments
processed during the analysis period was obtained.
Page 7 of 20

Stata was used to tag possible duplicate payments using Vendor Name, Order Date,
Payment Number and Payment Amount as the criteria. The results were exported into
Excel to tag duplicates by the same criteria using adding an absolute value formula to
detect reversals. Sorting the results by the tagged fields to remove the identified
reversals. Conditioning Formatting was used to highlight duplicates by Order Date to
easier identify the tagged records. The technique was used independently on the
Invoice Number and Payment Number to verify if there were any possible duplicates
that was not tagged as a duplicate payment, visually spot checking the report. Also,
used this technique on the Invoice Number and Document Company number to verify
duplicate payments.
Findings: The Payment History File contains 96,298 payments totaling $193,591,596
between the subject time period. After inspecting the file, it was discovered that there
were 15,876 duplicate payments totaling $6,774,918. There were 16,106 duplicates
before tagging reversals. There was a total of 927 reversals totaling $4,074,736.
Appendix G-1.
Cause of Observations: Based on the analysis of the file, duplicate payments were
primarily the result of vendors issuing two invoices with different numbers for the same
order.
Findings: There was approximately 141 potential duplicate payments totaling $150,383
identified by Invoice Number and/or Document Company as invoice numbers are
generated by the vendor therefore it may or may not be unique to a specific vendor.
These transactions represent <1% of the total file. However, preventive measures
should be consider in attempt to keep risk low. Appendix G-2.
Cause of Observations: Based on the analysis of the file, appear to be data entry errors.
Recommendations: Develop policy and procedures over the AP system and ensure all
employees comply. The master file for duplicate payments should be reviewed
regularly to resolve overpayments timely. A standard policy for invoice numbering,
established to ensure that invoice numbers are unique. Possibly adding the vendor
number as part of the invoice number. Also, have an error or warning display if a
duplicate invoice number is entered to trigger additional review before proceeding.
Page 8 of 20

7. An invoiced amount cannot be paid to multiple vendors.
Objective: For this objective, the goal is to identify one payment made to duplicate
vendors.
Test: We summarized the Payments file by invoice numbers, and it came up the invoice
number with the times of the vendor appeared. We extracted the vendors appeared
more than once. Then, we sorted all the duplicate vendors by Inv_Number from the
Payments file. We also tested the Invoice number with different variables such as
payment number, invoice date, payment date and payment amount.
Findings: There were nine INV_NUMBER had duplicate vendors. Appendix H-1 In total,
there were 57 records if we test for inv_number and payment amount, and there were
209 records of duplicate vendors if we test for inv_number and payment date.
Cause of observations: In our opinion, the potential cause of this situation might be
because of the employee's negligence.
Recommendation: Increase the internal control of the company to prevent the invoice
amount to multiple vendors. The company also need to train the employee to be more
professional. We also suggest the company use Inv_number with Vendor number so
that the company will get more detailed vendor information, and this will decrease one
invoiced amount be paid to multiple vendors.
8. Vendors Should Be Inactivated After One Year of No Payment History
Objective: To identify active vendors with no payment history over a year.
Test: We used Case IDEA to find a database only have active vendors. Then, we
summarized by vendor numbers in the payment history file, and we can see each
vendor had a record of active information. Because May 17, 2016, was the baseline, so
we set the record before the most recent payment date on May 17, 2015. After that, join
the active database with the over a year database, and we could get the record of
vendors who did not have payment history over a year still active.
Findings: We found that there were 364 active vendors got their last payment over a
year. We also joined the active vendor database with the most payment history
Page 9 of 20

database, and we found that 2130 active vendors did not have any payment history. We
also found that there were 3698 records of the inactive date of 12/31/2099.
Cause of Observations: The reason for vendor inactivation happened because the
company was less of internal control of the payment history.
Recommendation: We need further investigation to figure out how did the vendor still
active without payment for over one year. Maybe because of the documentation
mistakes or the person who in charge of this did on purpose. We highly doubted that
there was a mistake on the inactive date of the Year 2099 because it is too far from now
on..
9. Employees Cannot be Designated as a Supplier Within the Vendor Master File
Objective: Joining the Employee Master File to the Vendor Master file and ensuring
whether employees would reimburse for expenses through the accounts payable
system. In addition, we need to make sure if employees are regarded as suppliers in the
system.
Findings: We joined the file of the Employee Master and the file of Vendor Master in the
CaseWare IDEA. We got one result showing that the vendor number is 694807, vendor
name is Sed Congue Consulting, and the address is 5919 Grand Creek Ridge. It
represents that one of employees was designed as a supplier within the Vendor Master
File. The record can be found in Appendix E-1.
Cause of Observation: Once employees made reimbursements by using the accounts
payable system, they possibly were regarded as suppliers in the system and were
assigned vendor numbers, which were associated with existing suppliers. The potential
issue is that one of employees were designed as a supplier within the Vendor Master
File indeed. It is apparent that this issue probably affects the nature of operation in the
company, if it continues to happen. In addition, this issue may attempt to cause a fraud
existing in the company, because employees obviously take their advantages and make
dummy vendor numbers to reimburse for unnecessary expenses, which may cause the
financial losses.
Recommendation: The employees in the relevant division should help to check the
reimbursed expenses regularly. Not only it is able to help the company to make sure
whether the expenses are related with employees may be reimbursed or related with
suppliers showing the vendor numbers, when they make reimbursements for expenses,
Page 10 of 20

but also it is able to take charge of insuring if employees have fraudulent behaviors
existing in the company to avoid the direct and serious losses.
10. Vendors may have multiple, active vendor records as long as mailing/remit to
addresses are different
Objective: To test whether vendors had several inactive vendor records once the
mailing or remit to addresses were different, the Vendor Master file and Payment
History File will need to be joined.
Findings: Based on the Payment History 1019 Final File, we made a summarization
firstly. we sorted by vendor number, vendor name and remit to address. Then, based on
the Vendor Master 1019 Final File, we did another summarization as well and we sorted
by vendor number, vendor name and street. After we did a summarization with active
status, we joined these files together sorting by the remit to address. we got one result
displaying different vendor numbers, same vendor name and same street and remit to
street. The record can be found in Appendix E-2.
Cause of Observation: The policy of the vendor management business rules is to
ensure that the vendor has different numbers and same vendor names under the
condition of different addresses. In other words, if we find the same addresses, vendor
names and different vendor numbers, this issue can be considered as a risk.
Recommendation: As auditors, we need to take responsible for checking the vendor
processes in details regularly. In addition, we need to make sure the information of
vendors is accurate and the payment is complete. This process not only can help the
company to lookout for financial discrepancies, but also help to reduce the risk of
duplicate invoice payments being made.
11. Vendors with multiple vendor records may have the same Tax ID and different
vendor entities should not have the same Tax ID within the Vendor Master file.
Objective: The vendors that the client works with are individual entities. A purchase can
be made to the same vendor many times, therefore their Tax ID may appear frequently.
However, Tax ID’s are unique identifiers, therefore multiple vendors cannot have the
same identity or else they are no longer unique. The goal of this test is to analyze
Page 11 of 20

whether or not entities have multiple Tax ID’s, or the same Tax ID is being used for
multiple vendors.
Test: A summarization was created from the Vendor Master List dataset, which
validated the total number of records. Since the business rules request reviewing
duplicate records, two pivot tables were created outlining a visual aid between duplicate
and non-duplicate records. This can be found in Appendix D and D1.
Findings: After analyzing the dataset contained in the vendor master list, it was verified
that while vendors with multiple records have the same Tax ID, different vendor entities
do not have the same Tax ID. See Appendix D for results. There is a one to one
relationship between vendor name and tax ID, please see Appendix D-1 for this test.
Cause of Observation: Business rules indicated the potential for duplicate records for
vendor name and Tax ID. It was validated that while there were duplicate records, there
is a one to one relationship between vendor name and Tax ID.
Recommendations: A data cleansing procedure via a consulting engagement is
recommended to streamline the one to one relationship between vendor name and tax
ID by deleting duplicate records and validating vendor entities for auditing records
management. In addition, we recommend that the company should investigate the
vendors regularly and make sure whether the vendor master file has existed the dummy
addresses and vendor numbers of vendors.
Concluding Remarks
Overall, Semi-Elite Properties, LLC. had many gaps within their undocumented controls.
The first step would be to document all controls in place for both the Accounts Payable
process and Vendor Management process. The company should also perform vendor
maintenance to ensure that there are no unnecessary or unauthorized payments going
to vendors that they are not supposed to have contracts with. A detailed analysis of the
Accounts Payable process should be performed and enhance the controls based upon
recommendations provided.
Page 12 of 20

Appendix
Appendix A-1 - The output below shows the records that were over the authorization
limit.
This summarization shows a list of
employees that have gone over the
authorization limits the most times.
Appendix A-2 - This output shows
the 6 records found in which the pay
date precedes the order date as well
as the invoice date as well as the
employees that approved these records. The second output shows that all but one
employee went over their authorization limit.
Appendix B - This output reflects the payments made to unauthorized vendors. The
largest payment is greater than -$90,000, however most range from -$5,000 to -$7,000.
Page 13 of 20

Appendix C - The output reflects payments that are past due. When the client
purchases from a vendor, they establish a certain time-frame that our client has to pay
the invoice. This test indicates that about 40% of purchases are paid outside of the
vendor’s terms.
Appendix D - There is a 1:1 relationship between Vendor Name and Tax ID
Page 15 of 20

Appendix D1 - Vendor by Tax ID (Non - Duplicate / Duplicate Records PivotTables)
Page 16 of 20

Appendix E-1: The output shows that one of employees was designed as a supplier
within the Vendor Master File.
Appendix E-2: The output shows that different vendor numbers, same vendor name
and same street and remit to street
Appendix F-1:Inactive vendor payment results.
Page 17 of 20

Appendix G-1:Duplicate payments by Order Date, Payment Amount and Payment
Number results.
Appendix G-2: Possible duplicate invoice payments to different vendors.
Page 18 of 20

Appendix H-1: Duplicate vendors of nine Inv_Number.
Page 19 of 20

Vendor Management & AP Audit Report - Data Mining & Analytics

More Related Content

Similar to Vendor Management & AP Audit Report - Data Mining & Analytics (20)

More from Teri Grossheim (18)

Recently uploaded (20)

Vendor Management & AP Audit Report - Data Mining & Analytics