Automated Techniquesfor Detectionof Procurement Fraud

Automated Techniques for the
Detection of Procurement Fraud
By Mike Blakely

Summary

As procurement systems become increasingly automated and process larger numbers of
payments, the need for both preventive and detective controls over fraud takes on greater
importance. Regardless of how well controls are designed and implemented, there is
invariably an opportunity for error or fraud, especially if participants are sufficiently
motivated. Thus the auditor should perform at least some analytical tests, in order to
comply with SAS 99 and satisfy that basic controls are functioning as intended.
However, too often this process can be likened to searching for a “needle in a haystack,”
simply due to the sheer volume of records.

This article describes several approaches that are suitable for examining very substantial
volumes of transactions. It has been written for dual purposes; 1) to provide insight and
support to the practicing auditor of techniques that can be applied in real world situations
and 2) be used as the basis for course exercises and assignments in accounting/auditing
courses for students wishing to enter the audit profession.

This article is patterned closely upon the information included in the audit report
published by the Wake County School Public School (WCPSS) Board in response to two
frauds. Although much of the article and scenarios described are based on official reports,
all of the data, including names, numbers and amounts are strictly fictitious and have
been changed.

WCPSS has approximately 128,000 students, which is the second largest in the State of
North Carolina and ranks 22nd nationally. The system has approximately 8,500 teachers
and an annual operating budget of just over $1,025,000,000, with 81% going to salaries
and benefits, 10% to purchased services and the balance to other. The system has 835
yellow school buses which carry more than 68,500 children daily. Data Source: Wake
County School Board’s FAQ page .

The WCPSS also has a very significant transportation system. The data below is from
the WCPSS site:

Basic Transportation Facts
• Operates 767 regular route buses
• 213 contract vehicles for transporting students with special needs (2004-2005)
• 61,600 plus students transported daily (2004-2005)
• 4,000 -plus daily bus routes (2004-2005)
• Nation’s 20th largest school bus fleet; second largest in the state
• Serves 139 schools

Detection of Procurement Fraud Page 1

• Buses travel approximately 77,000 miles daily, 14 million miles annually (2004-
2005)
• Uses 2.2 million gallons of fuel annually
Data Source: http://www.wcpss.net/news/back-to-school_2005/transport_facts.pdf

Between July 1, 2002 and December 31, 2005, Wake County School employees in the
school transportation department and Barnes Motor & Parts Co., based in Wilson, NC,
submitted at least $3.8 million in fraudulent invoices for school bus and automotive parts.
Much of the money was used by the employees to buy personal items such as
automobiles, campers, golf carts and plasma-screen televisions. This, despite a bid limit
of just $2,500. The story received wide press. An audit report explaining many of the
details is available on the School Board's web page. Wake County schools had three
internal auditors at the time these frauds were occurring. The size of the internal audit
staff at the time was approximately 60% smaller than that of comparable schools,
according to a study “100 Largest School Districts Audit Survey” conducted by James M.
Kaplan, CIA, CFE and the Fairfax County Public Schools Internal Audit Office, April
2005.

Once the WCPSS district fired the employees and an investigation was performed, $4.8
million was recovered from Barnes and the former employees. Numerous red flags were
not noticed:

• Payments to Barnes Motor & Parts increased 342% from 2002 to 2003 (an
increase in excess of $3,700,000).
• Two thirds of the invoices from Barnes Motor & Parts were under the $2,500 bid
limit, and did not have a corresponding purchase order.
• For two years, over 99.95% of invoices were under $2,500.
• On 24 occasions, there were 50 or more invoices from Barnes Motor & Parts with
the same invoice date, and a majority of these invoices had consecutive invoice
numbers.
• On June 10, 2003, as the fiscal year end approached, Barnes Motor & Parts
submitted 466 invoices totaling $909,266.

Around the same time this fraud was detected and investigated, another, smaller fraud, in
the amount of approximately $200,000 was also uncovered. The WCPSS then requested
a system wide fraud assessment, the results of which were published on the WCPSS site.

It is essential to detect when instances of circumvention of procurement controls may be
happening. Basic histogram charts and data analysis can readily disclose many such
anomalies, which can then be used as a basis for further investigation.

The purpose of this article is to present a methodology, based upon automated
procedures, by which such a situation can be detected earlier, and hopefully prevent
subsequent losses or similar situations from reoccurring.


The data for testing
Data accompanying this article can be downloaded and used to see firsthand how testing
can be performed. The data file is provided in three formats; 1) a data file with column
headers, in tab separated value format, and 2) an MS-Access database and 3) a database
in Dbase IV format. All three contain the same data, which consists of 245,901
transaction records. The file size is approximately 29 MB, (unzipped is 108 MB).

Data elements and descriptions are as follows:

• Vendor Number – (6-7 character field, if the first character is a letter, then it is a
contractor, otherwise a regular vendor, Except that there are a series of valid
vendors whose codes begin with E1-E3 and also G2)
• Voucher Number
• Check Number
• Invoice Date
• Payment Date
• Due Date
• Invoice Amount
• PO Number (All zeros indicates no purchase order, i.e. under $2,500)

The master file contains four years of payment transactions to vendors (which includes
contractors). This master file includes payments to contractors, which are reviewed
separately, and therefore are not addressed as part of the audit procedures described here.
This master file consists of 245,901 transaction records for invoices dated between 1-1-
2002 and 12-31-2005. The file total is $384,293,656.

Why perform automated testing?
Detection of fraud is often akin to looking for the proverbial “needle in a haystack.” In
situations like these, sampling is not generally feasible, as the required sample size can
quickly become too large, making such a review unfeasible. Manual review of
documents may not be effective either, simply based upon “auditor fatigue” from
reviewing so many transactions that are free from fraud. Once a possibly fraudulent
transaction is encountered, it is too easy to just “gloss over” the transaction and not see it
for what it is.

This article presents a methodology which effectively filters out the “irrelevant many”
leaving just the “significant few” in order to enable the auditor to focus their effort on
transactions which may be of audit interest. This filtration process is automated and can
be used in even large populations. The data accompanying this article consists of


245,901 transactions, but even much larger volumes can also be readily analyzed, even
using PC-based systems.

One of the key advantages of using an automated approach for audit testing is that any of
the so-called “impossible conditions” can be tested for. Examples include transactions
approved, contrary to policy, transactions or combinations of transactions which together
make no sense, negative acquisition costs, etc. The data accompanying this article does
include some extreme situations, but these situations illustrate what was reported after the
investigation.

This article is organized around eight audit steps/procedures, each to illustrate a particular
process. For each audit step, example approaches using each of the three software tools
are shown, along with the summary results of that procedure. All of the data, including
the scripts, commands and log files used are available for free download, in case you
wish to re-perform the tests that were done. This eliminates the need for the auditor to re-
type the commands for their own use or modification. As noted previously, this article
also includes some questions, for those wishing to use the article as a case study.

By no means has every possible test been included that could be performed to test for
fraud. Rather, the concepts and possible approaches are presented in order that they may
be used or adapted in other situations. Thus, although the procedures in this article are not
exhaustive, they should illustrate many of the types of automated procedures that could
be employed during a fraud investigation. The procedural listings include comments, in
order that auditors not familiar with the particular language are better able to understand
the detail logic of the procedure. In order to make it clearer to the reader and to
distinguish between the text of the article and the text of any procedural code, commands
or formulae, all procedural code is shown in a different font (Arial Black). The font
usage does not indicate any particular importance, but only that a code example is being
shown.

A Few Words of Caution
All of the software in this article uses fairly powerful computer languages. The term
powerful is meant to convey that almost any conceivable audit computation or analysis
can be accomplished using the computer language, provided the auditor has the skills.
However, an inherent risk with any powerful computer language is that it will not
function as intended, due to improper syntax, logic, etc. All of the code in this article has
been tested to some extent, but there is no assurance that it will be suitable for any
particular purpose. The code is shown here only to provide a starting point for an audit.
When using the more powerful features of Excel, SAS or XL Audit Commander, some
assistance from an auditor with more in-depth knowledge of computer programming
languages may be necessary.


Verification of Audit Test Results
Some cautions on the use of Excel for complex statistical computations have been made,
most notably in certain academic articles. The audit procedures described in this article
use Excel as a means to facilitate audit testing. Most audit procedures and results should
be subjected to some reasonableness tests and verification through alternative means. My
experience has been that Excel is widely available and used, contains many powerful and
useful features, and can provide significant value to audit (and other) analytical
procedures. Nevertheless, audit test results, regardless of source, need to be taken with a
“grain of salt” until verified (to some extent) using alternative procedures. The fact that
test results obtained in this article were essentially the same regardless of software used,
validates, to an extent, the software functions properly.

Review Objectives / Testing Approach
In almost any review for fraud, the focus will be on looking for the exceptional / unusual.
Almost every fraud follows a pattern that sets it apart from ordinary transactions in some
manner or another. The challenge is to be able to isolate that unusual pattern or attribute.
Often, this can be done using analytical procedures/tests that include tools such as:

• Histograms
• Data extract
• Checking Weekdays/Holidays
• Univariate Statistics
• Data Stratification
• Ageing
• Chi Square / Linear Regression trending

The eight recommended audit steps and their explanation are as follows:

Step 1: Extract all the relevant data from the master file using the following criteria:

• Exclude contractor payments
• Only include those payments which were made during the last Fiscal Year, i.e.
7/1/2004 – 6/30/2005.
• Payments made between July 1 2005 and July 15, 2005 are to be included if the
invoice date was earlier than July 1, 2005
• Audit management has decided to exclude any vendor with annual payments
totaling $10,000 or less, regardless.

Step 2: Perform a high-level, initial analysis of all invoices by vendor number. This
analysis will consist of two parts:


a) A test of conformity with Benford’s Law, and
b) Summary totals of invoice amount.

This article does not go into detail on Benford’s Law, as there have been many good
articles written on its use and application, as well as all the underlying theory. However,
for those readers who may not be generally familiar with it, Benford’s Law has been
found to be useful in the identification of fraud. In particular, Benford’s Law can be used
to identify invoice amounts which are out of the ordinary. Although Benford’s Law does
not apply to all numeric populations, it will often apply when arithmetic (or other)
computations are involved.

Invoices can generally be classified as to two types:
a) those which are not based upon computations or calculations (these would
typically be recurring fixed amounts such as rental, lease or mortgage
payments, or other fixed amounts made pursuant to an agreement), and
b) invoices which are based upon a series of arithmetic computations, such as
multiplying a unit quantity (e.g. hours or pounds) by a unit rate. These
amounts are then summed, and may possibly include further arithmetic
calculations such as discounts, sales taxes or other fees, etc. Generally, such
computed amounts, when tested using Benford’s law, will be found to
conform with that which would be expected. Conformity with Benford’s law
can be measured using various statistics, such as Chi Square and the
Kolmogorov-Smirnov “d-statistic.” This article is also not going to go into a
discussion of these statistics, as they are explained very well elsewhere. They
are mentioned only so the reader is aware that there are standard
methodologies or metrics by which the “goodness of fit” can be measured for
distributions such as those expected under Benford’s Law.

The second audit step, then, is to obtain two overall measures of the population of
invoices by vendor:

a) Summary of invoice amount
b) Measure of conformity of invoice amounts with that expected under
Benford’s Law, quantified both as to Chi Square value and the K-S d-
statistic.

Then, depending upon the auditor’s judgment, the top five vendors in each category (i.e.
summary and Benford’s law) will be further analyzed (“drill down”) in the following
steps (3-8).

Step 3: For each vendor identified in step 2, prepare summary payments by month and
chart them, both as to number of payments as well as payment totals. Determine if there
are any “spikes” or other unusual patterns. What are the payment trends for each vendor?
Flat, increasing or decreasing?


Step 4: For each vendor identified in step 2, stratify the payment amounts in order to
determine how many relate to purchase orders (i.e. over the $2,500 limit) and how many
are under the limit (i.e. do not require a purchase order).

Step 5: Check for payments made for over $2,500 which are not made pursuant to a
purchase order. Prepare a schedule of such payments.

Step 6: For each vendor identified in step 2, determine what percentage of invoices
consist are consecutively numbered. Although consecutively numbered invoices may be
legitimate, they are also an indication that the auditee may be their only customer, that
duplicate services/goods are being billed or that an error/fraud is occurring. Depending
upon the auditor’s judgment, a schedule of the top five such vendors should be prepared
for further analysis and determination of the reasons why consecutively numbered
invoices are occurring.

Step 7: Check for invoices whose invoice date falls on a holiday. Prepare a schedule of
any such invoices.

Step 8: For any vendors who appear to have unusual patterns identified in steps 3 – 7,
extend the testing to the full audit period, i.e. the three year period from July 1, 2002
through June 30, 2005.

General Approaches for Each Software Tool

Excel

• The number of transactions (245,901) is too large to be loaded into a single
worksheet. Therefore the transactions will have to be split among multiple
worksheets in order to be able to handle them.

• The required selection criteria are too complex to be easily handled by Excel
formulae; therefore a macro will be written.

• Use built-in Excel facilities, such as Histogram, where available.

• Excel has date arithmetic functionality; this will be used for the ageing.

• Excel has a sub-total facility; this will be used for the summarizations required.

SAS Software


• SAS software has few, if any, limitations, and should be able to handle all the
required audit functionality, although some programming is required.

XL Audit Commander

• The standard XL Audit Commander functions will be used for the testing to be
performed. Where complex extracts or other functionality is required, some
programming is required.

STEP 1 – EXTRACT THE DATA
STEP 1 – EXTRACT THE DATA
STEP 1 – EXTRACT THE DATA.............................................................................................................. 9
STEP 2 – HIGH LEVEL ANALYSIS
STEP 2 – HIGH LEVEL ANALYSIS
STEP 2 – HIGH LEVEL ANALYSIS....................................................................................................... 10
STEP 3 – SUMMARY PAYMENTS BY YEAR
STEP 3 – SUMMARY PAYMENTS BY YEAR
STEP 3 – SUMMARY PAYMENTS BY YEAR...................................................................................... 13
STEP 4 – STRATIFY PAYMENT AMOUNTS TO TEST COMPLIANCE WITH BID POLICY ... 15
STEP 4 – STRATIFY PAYMENT AMOUNTS TO TEST COMPLIANCE WITH BID POLICY
STEP 4 – STRATIFY PAYMENT AMOUNTS TO TEST COMPLIANCE WITH BID POLICY
STEP 5 – LIST EXCEPTIONS – IINVOICES OVER $2,,500 AND NO PO .......................................... 17
STEP 5 – LIST EXCEPTIONS – INVOICES OVER $2 500 AND NO PO
STEP 5 – LIST EXCEPTIONS NVOICES OVER $2,500 AND NO PO
STEP 6 – DETERMINE PERCENTAGE OF CONSECUTIVELY NUMBERED IINVOICES ......... 19
STEP 6 – DETERMINE PERCENTAGE OF CONSECUTIVELY NUMBERED INVOICES
STEP 6 – DETERMINE PERCENTAGE OF CONSECUTIVELY NUMBERED NVOICES
STEP 7 – IINVOICES ON HOLIDAYS .................................................................................................... 20
STEP 7 – INVOICES ON HOLIDAYS
STEP 7 – NVOICES ON HOLIDAYS
STEP 8 – EXTEND TESTING OF STEPS 3 – 7 FOR PRIOR PERIODS ........................................... 23
STEP 8 – EXTEND TESTING OF STEPS 3 – 7 FOR PRIOR PERIODS
STEP 8 – EXTEND TESTING OF STEPS FOR PRIOR PERIODS
SUMMARY AND CONCLUSION ........................................................................................................... 23
SUMMARY AND CONCLUSION
SUMMARY AND CONCLUSION



Step 1 – Extract the Data

Excel

The data file has too many rows to be imported directly into Excel. Instead, you will
need to create a macro to do the file import. All of the following code can be
downloaded, but the individual steps are as follows:

1. Create a new (empty) workbook and start a new macro by clicking on the
“Visual Basic Editor” element on the toolbar (if this is not shown select the
View | Toolbars | Visual basic).
2. From the menu, select Insert | Module, naming the module with a meaningful
name (instead of Module1 – could be POAudit)
3. In the Visual basic Editor, start a new subroutine, by doing the following:
4. Enter the dimension statements to define a new file scripting object (for file
handling), a string buffer for containing each line of the file, a variant for
converting the input buffer to any array, and an object to use to read the file
5. The processing logic is to open the file (“POData.txt”) for reading, read a line
at a time splitting it into an array
6. Selection logic is based upon the contents of the first column, which is the
vendor number – if the first character is numeric, or the fist two characters are
“E1” – “E3” or “G2” select it
7. For selected lines, write them to a separate sheet, advancing one line after
each selection
8. At the end of the file, close up everything and you’re finished with the first
step. You should have an output file of 50,689 rows, footing to
$335,507,438.98.

The download files include an example of an Excel macro which performs the procedures
described above.

SAS Software

The SAS software processing logic is almost identical, but much easier, as all the file
handling is already done for you. Establish a variable to be used as a flag for selection,
with an initial value of 0 (False). Then perform the selection tests by checking the first
character of the vendor number for numeric, if so set the selection flag to 1 (True). The
same test can also be performed on the first two characters. In SAS software, you use the
output statement to write a record and the delete statement to skip it.


The results of the extract should be exactly the same as in Excel, i.e. 50,689 output rows,
footing to $335,507,438.98. You can verify this by looking at the SAS log.

The download files include an example of a SAS software script which performs the
procedures described above. Included in the script are steps for “PROC SUMMARY” in
order to obtain the file counts and totals for verification.

XL Audit Commander

The processing logic is almost identical to that performed using Excel alone, but much
easier, as all the file handling is already done for you. The selection logic is placed into a
macro module with the name “extract” (has to be this exact name).

Then run any of the following commands, depending upon whether you wish to perform
the extract from the MS Access database provided, or else the text file. The syntax for
the commands is very similar:

To extract from a text file:

Extract ds=file file=PO.txt recap=”Data Extract”

To extract from the MS-Access database:

Extract ds=db conn=”c:your directorypo.mdb” sql=”select * from po”
recap=”Data Extract”

Each of these commands will place the extract data on a worksheet named “Data
Extract”. (If the worksheet doesn’t exist it will be created, if it does it will be
overwritten).

The results of the extract should be the same as both Excel and SAS software, i.e. 50,689
output rows, footing to $335,507,438.98. This can be verified using the XL Audit
Commander Univariate command (“un”).

Step 2 – High Level Analysis

Excel

Before you begin, you should make two copies of the worksheet created in step 1 and
give them meaningful names such as “Summary by Vendor” and “Benford’s Law.”


Obtaining summaries by vendor is fairly easy – first sort the worksheet “Summary by
Vendor” by vendor and then use the Data | Subtotals menu command to obtain subtotals
of invoice amount by vendor.

Performing a compliance test for Benford’s law is more challenging and involves the
following steps:

1. Sort the worksheet “Benford’s Law” by vendor.
2. Insert a new column which will contain the first digit of the invoice
3. In the first row containing an invoice amount, insert the formula
(=INT(left(ColName,1)) without using the parenthesis and using the
actual column name – e.g. A2, etc. Then replicate this formula over
the remaining rows.
4. Now set up a column which will be used to store the counts of the
digits 1 – 9. Counts can be performed using the Excel “COUNTIF”
function, the range and the criteria for selection. For example to count
all the “1’s” in the range E2:E200, the formula would be
“=COUNTIF($E$2:$E$200,”=1”)” (without the exterior quotes. This
formula should then be replicated over the eight more cells, with
counts for the digits 2 -9. Note the use of the absolute addressing to
prevent the input address from being changed as the formula is copied.
5. The next step is to compute the number of digits that would be
expected under Benford’s law. The first piece of information
necessary is the sum of the individual counts, i.e. the counts of all of
the observations. Once this information is known, the expected values
can be computed using the formula for Benford’s Law, i.e.
=INT(LOG(1+(1/E2))*$D$14). In this formula, it is assumed that the
value of the digit (1-9) is in cell E2 , and the count of all digits is in
cell D14. The purpose of the INT formula is to truncate the results to
an integer.
6. Once the observed and expected values have been obtained, the chi
square can be computed as the sum of (O-E)*(O-E)/E. In this formula
O is the number of digits observed and E is the number expected
(which was computed. The sum of each of these nine computed
values provides the Chi Square value. This amount can be evaluated
for 8 degrees of freedom to determine is the observe pattern follows
that which would be obtained using Benford’s Law.
7. The K-S “d-statistic” is computed in a similar fashion, but involves
comparing the actual cumulative percentage with the expected
cumulative percentage. The mechanics of computing the d-statistic are
to compute percentages for each observed count, then develop a
running cumulative amount. This is done for both the number of
observations as well as the expected number. Then the absolute value
of the difference between the two amounts is computed. The digit
having the largest difference in the cumulative percentages is the digit


that is most different between the two. Critical values for the d-
statistic can be computed, but a rule of thumb is that 10% or more is
generally significant.
8. Steps 1 – 7 are then repeated for each vendor in order to determine the
chi square values and d-statistics for each.

The output from these procedures (as well as the Excel macros used) can be seen in the
data available for download.

SAS Software

The SAS software processing logic is almost identical, but much easier, as all the file
handling is done for you. The syntax for the SAS language is different from Visual basic,
but the concepts are the same. The SAS language also includes built-in capabilities for
record counting, etc. making the process somewhat easier. Example code is available for
download.

XL Audit Commander

In XL Audit Commander the analysis is done using the Benford Analysis (BA)
command. The syntax depends upon whether the source data is in a file, on a worksheet
or in a database. Regardless, the syntax is very similar for each:

File

To analyze the extract file, using the column named Vendor and the perform a Benford’s
analysis on the amount of the invoice in the column named invamt and store the summary
results on a worksheet named Benford, the following command would be used:

BA ds=file file=poextract.txt col=vendno amount=invamt recap=Benford.

WorkSheet

For an analogous situation, except the data is contained on a worksheet named “PO
Extract”, the syntax would be as follows:

BA ds=rng sheet=”PO Extract” col=vendno amount=invamt recap=Benford

DataBase


If the source data is stored in MS-Access or other database, the syntax would be as
follows:

BA ds=db conn=”c:mydirectorypo.mdb” sql=”select vendor, invamt * from
po” recap=Benford fldno=0 amount=1.

Results from Step 2

The results of this analysis are rather striking. The computations of Chi Square (which
measure the goodness of fit between that which is observed and that which is expected
show the following values for the top five vendors (when sorted by descending Chi
Square values):

Benford Summary Report
Variable Count Total ChiSQ d-stat
105436 5584 12,047,211.71 23,724.10 0.4899
E26417 631 4,377,691.00 25.9 0.0499
138478 641 4,814,116.53 15.4 0.0301
731409 658 4,894,463.79 15 0.0405
891424 634 4,907,960.95 14.5 0.0258

From this, it is possible to see that one vendor, 105436, is “off the chart”. Certainly, each
of these five vendors merits further review. Once a Benford chart is done on these
vendors, it will become much clearer why the vendor invoice statistics are “off the chart”.

The test of Benford’s Law can be run on each of these five vendors and the data plotted
in Excel. These results are charted at the end of this article.

Step 3 – Summary Payments by Year

Excel

In Excel, invoice payments by year can be obtained using the built-in Data | Subtotals
command. In order to do so, start with extract data from Step 1 and add two columns (J
and K) which will contain the year of the invoice and the month of the invoice. For
example, to obtain the year portion of the invoice date, in cell J2 enter the formula
“=Year(E2)” (without the quotes). Similarly, in column K, enter the formula for the
month as “=Month(E2)” (again without the quotes). These formulas can then be


replicated over the entire worksheet with a select and drag command. Then sort the
worksheet data by Vendor Number, Year and Month.

To obtain invoice totals, use the Data | Subtotals command. To do so, specify that the
subtotal should be added to the invoice amount at each change in the month (since they
are already sorted). The process takes some time, even on a fairly fast computer, due to
the fairly large number of rows involved.

Once the data has been subtotaled, the results can be viewed at three different levels,
depending upon the level umber selected in Excel, which can be one, two or three; one
being the highest summary level (grand totals), two being the intermediate level (totals by
month) and three being no detail at all.

In order to work with or chart this data, it is necessary to extract just the rows which
contain the subtotal amounts. This can be done using a macro, and basing the extraction
criteria on the existence of the word “Total” on the row in column K. Note that the
vendor number must be picked up from the prior row; it is not contained on the summary
row.

Also note that there are some vendors with letter number prefixes whose monthly totals
are to be ignored as they are too small to merit detail review. Thus, the macro needs to
have logic to exclude these vendors. The macro code to perform this extract is included
in the workbook which can be downloaded.

SAS Software

Using SAS software, this summarization is a very straightforward process, and the code
example to do so is available for download. SAS has a “proc summary” command which
can be used to summarize data.

XL Audit Commander

To summarize the data, use the Summary command. The syntax depends upon where the
data source is (file, database, worksheet etc). Below is the syntax to summarize the data
on a worksheet, putting the summary results on another worksheet. Note that the data
does not need to be first sorted. The summary is based on a derived column, which is a
combination of the vendor number, invoice year and month. This column was created
using the Excel formula “=A2 & quot;|quot; & YEAR(E2) & quot;|quot; & MONTH(E2)” without the
quotes.

The data is summarized using the following command:


Summary ds=rng sheet=PO recap=”Summary Data” col=”Key”
amount=”Invoice Amount”

Results from Step 3

The summaries by vendor indicate that generally the invoice totals by vendors are
clustered around the same values, which is generally not common. Typically, a few
vendors will account for a significant portion of the total (the Pareto effect). For the
calendar year 2005, the top five vendors, in terms of invoices paid, are shown below.

Vendor Total Year
105436 4,107,795 2005
828246 1,579,452 2005
E10063 1,507,438 2005
530812 1,503,751 2005
581794 1,488,891 2005

Step 4 – Stratify Payment Amounts to test compliance
with bid policy

Excel

In Excel, the COUNTIF and SUMIF functions can be used to perform a stratification of
sorts. Note that these functions do not support complex criteria, such as strata consisting
of multiple layers.

SAS Software

Using SAS software, it is fairly easy to produce stratifications of data. This can be done
by defining various strata ranges and then accumulating totals. SAS software has the
ability to “retain” values between processing of rows, and these “retained” variables can
be used to accumulate (and report) stratification amounts. Sample code is available for
download.

XL Audit Commander

The syntax of the stratify command depends upon the data source. In order to perform a
stratification of data contained on a worksheet, and separate the totals into a series of
defined strata, saving the results on a worksheet named “Stratified Data” the command
would be as follows. Note that the selection of the strata values here is purely arbitrary.


Typically the auditor will select some values, see what the results are, then “fine tune”
them and re-run them. The processing speed depends upon the CPU used, but speeds of
20,000 rows per second are not unusual, so it is very feasible to run multiple iterations
until the desired results are obtained.

Stratify ds=rng sheet=”PO” col=”Invoice Amount” strata=”-5000 0 3000
10000 20000 50000” recap=”Stratified Data”

Results from Step 4

The stratification of invoices for the selected vendors shows some significant disparities
between them.

First, a stratification of invoices from vendor 105436:

stratify ds=rng sheet=V105436 col=quot;Invoice Amountquot; strata=quot;-5000 0 3000
10000 20000 50000quot; recap=Strat105436 ulc=a1

The results from this stratification produce little in the way of information, other than the
data is closely concentrated:

Summary for Strata -5000 0 3000 10000 20000 50000
Start End Count Amount Pct Cumulative
Below Below 0 0 0 0
-5000 0 0 0 0 0
0 3000 5,584 12,047,211.71 1 1
3000 10000 0 0 0 1
10000 20000 0 0 0 1
20000 50000 0 0 0 1
Above Above 0 0 0 1
Totals totals 5,584 12,047,211.71

Because the data is so concentrated, we can rerun the stratification command using
different parameters:

stratify ds=rng sheet=V105436 col=quot;Invoice Amountquot; strata=quot;0 100 200 500
1000 1500 2000 2500 3000quot; recap=Strat105436A ulc=a1

This produces the following analysis:


Summary f0 100 200 500 1000 1500 2000 2500 3000
Below Below 0 0 0.00% 0.00%
0 100 253 14,005.76 0.12% 0.12%
100 200 0 0 0.00% 0.12%
200 500 0 0 0.00% 0.12%
500 1000 0 0 0.00% 0.12%
1000 1500 0 0 0.00% 0.12%
1500 2000 9 18,000.00 0.15% 0.27%
2000 2500 5,308 11,980,097.96 99.44% 99.71%
2500 3000 14 35,107.99 0.29% 100.00%
Above Above 0 0 0.00% 100.00%
Totals totals 5,584 12,047,211.71

This analysis indicates just a handful of invoices under $100, with the bulk between
$2,000 and $2,500. Interestingly, just .29% exceeds the bid limit.

This contrasts sharply with distributions of invoices from other vendors. For example,
the same analysis on vendor 581794 produces results which appear more normal. The
command used specified the same strata as for vendor 105436:

stratify ds=rng sheet=V581794 col=quot;Invoice Amountquot; strata=quot;-5000 0 3000
10000 20000 50000quot; recap=Strat581794 ulc=a1

Summary
for Strata -5000 0 3000 10000 20000 50000
Below Below 0 0 0.00% 0.00%
-5,000 0 1 0 0.00% 0.00%
0 3,000 178 337,716.71 7.04% 7.04%
3,000 10,000 299 1,826,168.99 38.05% 45.09%
10,000 20,000 182 2,635,250.16 54.91% 100.00%
20,000 50,000 0 0 0.00% 100.00%
Above Above 0 0 0.00% 100.00%
Totals totals 660 4,799,135.86

Step 5 – List Exceptions – Invoices over $2,500 and no
PO

Excel


To identity any invoices over $2,500 which do not contain a PO number, a new column
would be established (e.g. L) and then a formula would be inserted to compute to “1” if
the condition is true and “0” if the condition is false. Once the computations are made for
each invoice, the worksheet can be sorted on the resulting value.

The Excel formula to be inserted in column 2 would be
“=IF(AND(H2>2500,LEN(I2)<2),1,0) “ (without the quotes). What this formula says, in
plain English is if the invoice amount is greater than $2500 and the length of the PO
Number less than 2 then the cell value is 1 (true), otherwise 0 (false).

This formula can now be replicated over the remainder of the worksheet and then the
worksheet can be sorted on the results. This process should result in the identification of
49 instances where an invoice for more than $2,500 was paid without a corresponding
Purchase Order.

SAS Software

Using SAS software, it is a fairly simple process to list any invoices paid for more than
$2,500 without a corresponding purchase order. Example code is provided.

XL Audit Commander

To extract such data from a worksheet, use the command below:

Extract ds=rng sheet=PO recap=”Missing PO” ulc=a1

Of course, this requires that first, an extract macro must be written, similar to what was
done using the SAS software. An example is available for download.

There are five such invoices, interestingly all for the same amount:

Vendor Voucher Check Invoice Invoice Invoice
Number Number Number Number date Payment Date Due Date Amount
G20036 92454 59245 7359 8/17/2004 9/18/2004 9/16/2004 18604.79
982809 86386 58639 12268 9/27/2004 10/31/2004 10/27/2004 18604.79
766057 41309 54131 7253 5/8/2003 6/3/2003 6/7/2003 18604.79
421470 70266 57027 10397 6/28/2005 7/27/2005 7/28/2005 18604.79
232367 70456 57046 4613 9/13/2005 10/16/2005 10/13/2005 18604.79


Step 6 – Determine Number of Consecutively Numbered
Invoices

Excel

There are alternative solutions in Excel that enable the determination of the percentage of
invoices which are consecutively numbered. Both entail first sorting the data on the
worksheet by vendor then invoice date and then by invoice number.

Method 1 – Manual

In this method, either the data is visually scanned, or else a separate column established
and a formula placed which subtracts each invoice number from the prior to determine of
the difference is exactly one. This condition can be noted using an IF statement with a
condition, setting the value of the cell to “1” if the condition is met and “0” if not. Then
the number of invoices for each vendor is totaled and the divided into the count of the
number of conditions which are now labeled 1.

Method 2 – Macro

Using this method, all the above is done programmatically. The advantage of doing so
programmatically is not only the time savings but the increased assurance that all of the
processing was performed uniformly (i.e. less chance of an error). With a programmatic
method, the results can also be written out to separate sheets, one containing a detail
listing of consecutive invoices and the other worksheet containing counts by vendors. An
example of this code can be found in the download file.

SAS Software

Using SAS software, the approach is almost the same, but with slightly different
mechanics. With SAS, the value of a variable can be “retained” from record to record,
i.e. not lost as a new record is read in. With this technique, the value of the vendor
number and the invoice number can be saved and then the current vendor number
compared with the last vendor number and the current invoice number compared with the
last invoice number. This technique can be used to produce a report fairly easily which
quantifies the number of consecutive invoices which have been issued. An example of
such code can be found in the SAS software script available for download. The results
are the same as that obtained using MS Excel.


XL Audit Commander

XL Audit Commander has built in functionality to quantify the number of consecutive
invoices. However, in order to take advantage of this functionality when there is more
than one vendor, it is necessary to write a short macro. The macro uses a built-in class
named cStringArray. An object of this class is instantiated, and then the entire file is
processed, passing the value of the vendor number and the invoice number to the class.

Once the entire file has been processed, a report can be produced which shows the count
and percentages of consecutive invoices by vendor. An example of such code is also
available for download.

Results:

One vendor, 105436, stands out, having issued 2,726 consecutive invoices, an order of
magnitude larger than the vendor (650403) having the dubious distinction of second
place.

Vendor Consecutive
105436 2,726
650403 100
387707 91
152255 91
292790 88
650914 86
853541 85
817910 85
369473 85
138478 85
806989 84
581794 84
398704 84
264066 80
164945 79
117667 79
375007 78
817470 77
731409 76
490727 76

Step 7 – Invoices on Holidays

Excel


Although Excel has extensive date handling functionality, there is no built in
functionality for recognizing dates falling on a federal holiday. In order to do so one
approach is to construct a worksheet which contains all the federal holidays to be tested
for and then do a “VLOOKUP” for each date field to be tested.

SAS Software

SAS software also has extensive date handling functionality, but nothing specifically
targeted towards the identification of dates falling on a federal holiday. One approach
which could be used is to construct a SAS dataset containing all the federal holiday dates
to be checked for. Then sort both this dataset and the data to be tested in date sequence
and then do a match/merge, writing the results out to another SAS dataset for listing. An
example of such a procedure is also available for download.

XL Audit Commander
XL Audit Commander has a built in command to test for federal holidays. The command
to test for holidays varies depending upon the data source, i.e. file, worksheet, selected
range or database. The basic syntax for checking a worksheet range would be:

holiday ds=rng sheet=PO col=quot;Invoice Datequot; recap=quot;Invoices on Holidaysquot;
ulc=a1holiday ds=rng sheet=PO col=InvDate recap=quot;Invoices on Holidaysquot;
ulc=a1

The command can be abbreviated to just the first two letters, i.e. HO. In the command
above the data source is a worksheet named “PO”, with the data starting in the upper left
hand corner (ulc) of cell A12. Results of the extract are written to the worksheet named
“Invoices on Holidays” – this worksheet will be created if it doesn’t exist.

Results:

This command identifies 2,139 invoices dated on a federal holiday. The top of the report
sheet is shown below (sorted in vendor order)


Holiday Report:

Vendor Voucher Check Invoice Invoice PO
Holiday Number Number Number Number Invoice date Payment Date Due Date Amount Number Key Condition
10/14/2002 12417 5099 50510 7514 10/14/2002 11/18/2002 11/13/2002 12538.3 1874 12417|2002 0
2/18/2002 12417 67514 56751 4258 2/18/2002 3/12/2002 3/20/2002 8410.88 9154 12417|2002 0
9/1/2003 12417 9019 50902 6923 9/1/2003 10/4/2003 10/1/2003 9405.91 9809 12417|2003 0
10/13/2003 12417 41409 54141 7498 10/13/2003 11/17/2003 11/12/2003 14813.93 1882 12417|2003 0
10/13/2003 12417 18786 51879 7534 10/13/2003 11/17/2003 11/12/2003 3459.22 4940 12417|2003 0
9/1/2003 12417 2378 50238 6958 9/1/2003 10/4/2003 10/1/2003 460.96 0 12417|2003 0
2/17/2003 12417 73496 57350 4270 2/17/2003 3/11/2003 3/19/2003 4150.44 6125 12417|2003 0
9/1/2003 12417 68938 56894 6936 9/1/2003 10/4/2003 10/1/2003 7747.68 8855 12417|2003 0
11/11/2004 12417 16997 51700 7949 11/11/2004 12/18/2004 12/11/2004 17508.68 1573 12417|2004 0
1/19/2004 12417 29274 52927 3877 1/19/2004 2/9/2004 2/18/2004 17342.21 1263 12417|2004 0
1/19/2004 12417 68193 56819 3869 1/19/2004 2/8/2004 2/18/2004 450.2 0 12417|2004 0
7/5/2004 12417 25963 52596 6147 7/5/2004 8/4/2004 8/4/2004 8475.25 9499 12417|2004 0
1/19/2004 12417 69726 56973 3852 1/19/2004 2/8/2004 2/18/2004 11651.62 2024 12417|2004 0
1/19/2004 12417 50338 55034 3847 1/19/2004 2/8/2004 2/18/2004 231.11 0 12417|2004 0

If we wished to summarize this data by vendor, in order to see which vendors most
commonly date their invoices on federal holidays, the following command could be used:

summary ds=rng sheet=quot;Invoices on Holidaysquot; col=quot;Vendor Numberquot;
amount=quot;Invoice Amountquot; recap=quot;Holiday Summaryquot; ulc=a2

The output (after sorting) appears as follows:

Summary Report
Variable Count Total Debits Credits
105436 149 318,030.03 318,030.03 0
421470 34 296,651.03 296,651.03 0
530812 41 292,540.71 292,540.71 0
806989 42 286,589.68 286,589.68 0
553084 34 284,704.95 284,704.95 0
292790 33 284,547.49 284,547.49 0
418846 36 283,415.91 283,415.91 0
164945 30 260,623.11 260,623.11 0
E151309 35 258,017.86 258,017.86 0
158647 31 253,340.24 253,340.24 0
731409 32 252,293.22 252,293.22 0
581794 26 251,971.89 251,971.89 0
369473 35 247,924.58 247,924.58 0
828246 36 247,794.38 247,794.38 0
650914 31 241,857.02 241,857.02 0
509929 29 240,778.35 240,778.35 0
817470 32 233,772.96 233,772.96 0
152255 33 231,576.90 231,576.90 0
695326 27 224,872.29 224,872.29 0
817910 26 223,474.50 223,474.50 0

This indicates that vendor 105436 is also the leading vendor for invoicing on holidays,
both as to number of invoices and amount.


Step 8 – Extend testing of steps 3 – 7 for prior periods

Excel

Using Excel, additional worksheets would need to be extracted and developed.

SAS Software

Using SAS software, extending the audit period is simpler, as it entails making just some
minor modifications to the script and then re-running.

XL Audit Commander

Using the XL Audit Commander software, the process is also simpler as it entails
primarily looking at different data sources, i.e. transactions for different periods of time.
This is done by making some minor modifications to the script and then re-running

Summary and Conclusion
There are various automated approaches for the detection of procurement (and other)
fraud which can be very effective. Too often, frauds can go undetected, not because an
automated approach was unable to find them, but because no automated test was used at
all. The process of investigating fraud in an enterprise can be daunting, especially when
the number of records which need to be reviewed is in the thousands or even millions, not
an unusual situation. By using an automated approach, it is feasible to perform testing of
100% of the records in certain instances. Most audit software is suitable for this process,
although some skill and training may be required. Hopefully, auditors will expand their
automated testing procedures as well as further share some of their techniques, code and
approaches taken, where feasible.

About the author:
Mike Blakley is currently an IT auditor with the State of North Carolina, Department of
Health and Human Services. Mike maintains a blog devoted to audit software topics at
http://blog.ezrstats.com and his e-mail address is Mike.Blakley@ezrstats.org.


Attachments
Charting results of test of first digit of invoice amount, using Benford’s Law.

The results for the first vendor, 105436, are shown below.

The next four vendors show only very minor variations between observed and expected
as illustrated in the charts below:


Automated Techniquesfor Detectionof Procurement Fraud

Recomendados

Recomendados

Más contenido relacionado

Similar a Automated Techniquesfor Detectionof Procurement Fraud

Similar a Automated Techniquesfor Detectionof Procurement Fraud (20)

Más de EZ-R Stats, LLC

Más de EZ-R Stats, LLC (7)

Automated Techniquesfor Detectionof Procurement Fraud