Vendor Master File Integrity Testing

Overview Testing the integrity of the vendor master file is an essential component of any test of the purchase to pay process. This article covers some of the key aspects of such tests, such as: Testing authorization and propriety of changes made to the vendor master file Identifying data values which are missing or possibly invalid Cross-checking the vendor master file against the employee master to identify any employees who are also vendors in order to better assure that conflicts of interest do not exist

This article demonstrates procedures which may be used based upon test data available. The test data is contained in an Excel 2003 format workbook which contains five sheets: 1. Vendors (a master list of vendors) 2. VendorBefore (an example of a group of vendors at a point in time for comparison with another group at a later time) 3. VendorAfter (an example of vendors after changes and deletions) 4. VendorEmp (en employee master file for use in cross-checking for employees who are also vendors) 5. VendorIntegrity ( a vendor file which contains some errors to be identified using data integrity tests) The three key sheets can either be exported using the menu item File | Save AS, or else written out using the macro included in the workbook or else imported as text files: VendorBefore.txt, VendorAfter.txt, VendorIntegrity.txt. Importing the data The data has been imported using the standard Web CAAT menu process which involves copying (uploading) a file and then importing it into a table. Detecting additions and deletions to the vendor master file Additions to the vendor master file can be detected by comparing two copies of the vendor master made at different times. For the example, a snapshot is taken at one point and the Vendor data is saved as VendorBefore. At some later point, e.g. weeks or months later, a second snap shot is taken. To detect vendors which have been added, a query can be made to list all vendors in the after snap shot which do not exist in the before snapshot. The SQL to do this would be as follows:

Vendor Master File Integrity Testing select a.* from VendorAfter a where a.`Vendor Number` not in (select distinct b.`Vendor Number` from VendorBefore b); Similarly, for deletions, the reverse scenario is used, i.e. vendors which exist in the before image, but do not exist in the after image. The SQL to do this would be as follows: select a.* from VendorBefore a where a.`Vendor Number` not in (select distinct b.`Vendor Number` from VendorAfter b); Once these vendors are listed out, they can then be tested to assure that all the changes made were authorized. The mechanics of this process, using Web CAAT, are as follows:

Sign-in to the system using the default id audit1 and the password audit1.

Vendor Master File Integrity Testing Select the menu item Processes | Other Processes | Join Tables

Vendor Master File Integrity Testing Select the names of the tables to be joined and click the Process button.

Vendor Master File Integrity Testing Select the name of the column in the first table A to be used for the match.

Vendor Master File Integrity Testing Select the name of the column in the second table that is to be used for the match. Note that the column names do not need to be the same, however, the values must match if the merge is to be successful.

Vendor Master File Integrity Testing Click the Process button to have the matching function performed.

Vendor Master File Integrity Testing A report of all the items which are in table B but not in table A is produced.

Vendor Master File Integrity Testing The detail rows where the merge was not successful are shown. In this case there were three rows.

Vendor Master File Integrity Testing The process to obtain vendor deletions is identical. Next, the process of checking for selected changes will be done. In this case, the same vendor number exists both before and after, but the value of a particular column will be different. For this example, a test will be made for changes to the bank account number. The test will be performed by having the system compare each vendors bank account number at two points in time. If the bank account number is different, then it has been changed. The SQL to perform this task is as follows: select a.`Routing Number`, a.`Vendor Number`, b.`Routing Number` from VendorBefore b, VendorAfter a where a.`Routing Number` != b.`Routing Number` and a.`Vendor Number` = b.`Vendor Number`; This can be done in the Web CAAT system using the same menu process as described before. Data Integrity A preliminary test which can be performed on any vendor master file is to simply obtain a count of missing values. For example to quantify the number of instances that the vendor master file has a missing tax payer identification number (TIN) the SQL command would be: select count(*) from `VendorBefore` where isnull(TIN); Running this command produces a result of zero, indicating that there are no missing TIN numbers. An alternative command is: select count(*) from `VendorBefore` where length(TIN) < 1; All of the state codes should have a length of exactly 2. To test this, the following command can be used: select count(*) from `VendorBefore` where length(`State`) <> 2; To list the actual vendor record where the exception exists, the following command could be used:

10

Vendor Master File Integrity Testing select * from `VendorBefore` where length(`State`) <> 2; Running this query provides the result that the vendor is Canadian, and apparently no state was set up. Employee / Vendor Cross-Checking To match vendor TIN numbers with employee SSN numbers, the following SQL command could be used: select a.* , b.* from VendorBefore a, vendoremp b where a.`TIN` = b.`SSN`; Similar checks could be mad on other columns as well. For example to check for a match in address based on city and street, the following command could be used: select a.* , b.* from VendorBefore a, vendoremp b where a.`TIN` = b.`SSN`; This particular command produces 111 possible matches, so it may be desirable to refine it a bit more.

11