Duplicate payment test

procedures using
Web CAAT
Data analysis made easier
Page 1
Testing for Duplicate Payments
Using Web CAAT
A document previously published provided an overview of the process for detecting suspect duplicate
payments. This document presents the specific steps in detail, shown using the Web CAAT system. The
software is open source under the LGPL license. There is no cost for the software.
The software used to illustrate the concepts is currently being used to teach auditing concepts, statistical
sampling and data mining. !"# $tats, LLC is registered with the %orth Carolina $tate &oard of Certified
Public Accountant 'aminers as a provider of Continuing Professional ducation.
This software is a (wor) in progress* and is updated based upon comments and suggestions received from
practicing auditors as well as class participants. All comments and suggestions are welcome. A number of
in+uiries have been received regarding use of the software for the most common audit functions done by the
(non power* users. ,n fact, this is the primary intention for the use of this software.
The name (Web CAAT* is derived from the two )ey aspects of the software - ./ it runs as a web service
either on a stand alone machine or as part of a corporate intranet, and 0/ it is a computer assisted audit tool
1CAAT/. The primary advantages of the software are ./ only a web browser is re+uired to run it 1nothing to
install/ and 0/ it leverages powerful open source software such as 2y$3L to provide e'tensive audit
capabilities. Advantages also include the ability to easily share data between auditors, and also enhance
audit productivity by enabling most auditors to run standard, menu driven procedures without the need for
lengthy learning cycles. This is done by providing over .44 (ready to run* audit procedures, all using
standard web based forms that most auditors are familiar with.
Page 2
Document History
Revision History
Revision
Number
Revision Date Summary of Changes
1. !"#"$11 %nitial version
Page 3
Table of Contents
1 SYSTEM OVERVIEW ................................................................................................................ 1
1.1 Who houl! Use "t ................................................................................................................................................................. 1
1.# Purpose ................................................................................................................................................................................... 1
1.$ cope ....................................................................................................................................................................................... 1
1.% "nten!e! au!ience .................................................................................................................................................................. #
1.& Har!'are re(uirements ........................................................................................................................................................ #
1.) oft'are re(uirements .......................................................................................................................................................... #
2 SETTING UP THE WORK BENCH ....................................................................................... 3
#.1 The menu ................................................................................................................................................................................ $
#.# ign*in to the system .............................................................................................................................................................. %
#.$ etting up the 'or+ bench .................................................................................................................................................... &
#.% Provi!ing processing parameters ......................................................................................................................................... ,
#.& Creating the 'or+ bench table ............................................................................................................................................. -
#.) ./clu!ing transactions from testing .................................................................................................................................. 10
#., Report of suspect !uplicates ............................................................................................................................................... 11
3 RUNNING THE TESTS .......................................................................................................... 13
$.1 1vervie' an! general proce!ures ..................................................................................................................................... 1$
$.# Test A 2 3our 'ay match ..................................................................................................................................................... 1&
$.$ Test 4 2ame ven!or number5 invoice an! amount .......................................................................................................... 1)
$.% Test C 2ame ven!or number5 invoice an! !ate ............................................................................................................... 1,
$.& Test D 2ame ven!or number5 invoice !ate an! amount ................................................................................................. 1-
Page 4
$.) Test . 2ame ven!or5 amount5 similar invoice 67D18 ..................................................................................................... #0
$., Test 3 2 ame ven!or5 amount5 similar invoice 6718 ....................................................................................................... #1
$.- Test 9 2 ame ven!or5 amount5 similar invoice 6D18 ...................................................................................................... #$
$.: Test H 2 ame ven!or5 amount5 similar invoice 67evenshtein !istance8 ......................................................................... #%
$.10 Test " 2 ame ven!or5 amount5 similar invoice 6transposition8 ...................................................................................... #)
$.11 Test ; 2 ame ven!or5 similar amount5 similar invoice 6characters in common8 ......................................................... #,
$.1# Test < 2 ame ven!or5 !ate5 amounts 'ithin a percentage ............................................................................................ #:
$.1$ Test 7 2 ame ven!or5 !ate5 similar invoice 6lea!ing characters8 ................................................................................. $0
$.1% Test = 2 ame ven!or5 !ate5 similar invoice 6trailing characters8 ................................................................................ $#
$.1& Test > 2 ame ven!or5 !ate5 amount5 !ifferent invoices ................................................................................................. $&
$.1) Test 1 2 ame invoice5 !ate5 amount5 !ifferent ven!ors ................................................................................................ $)
$.1, Test P 2 ame invoice5 !ate5 amounts 'ithin percentage ............................................................................................... $-
$.1- Test ? 2 ame ven!or5 amount5 invoice5 similar !ate ..................................................................................................... $:
$.1: Test R 2 ame ven!or5 invoice5 similar !ate .................................................................................................................... %0
$.#0 Test 2 ame invoice5 !ate5 amount5 similar ven!or using 7evenshtein !istance ...................................................... %#
4 ASSESSING THE RESULTS .................................................................................................. 44
%.1 1ther tests ............................................................................................................................................................................ %%
%.# ?uestions5 comments an! suggestions ............................................................................................................................... %%
Page 5
Abo! W"b CAAT
1 ystem overvie'
This document is divided into the following sections5
$ection . - $ystem overview
$ection 0 - $etting up the (wor) bench*
$ection 6 - #unning the tests
$ection 7 - Assessing the results
1.1 Who houl! Use "t
,nternal auditors, accounts payable specialists and audit recovery professionals are the primary users of the
system to perform their 8obs.
Auditors5 can use the software to assess the ade+uacy of controls in payment processing systems.
A side benefit is the identification of potential overpayments for recovery.
Accounts payable specialists5 can use the software as an operational tool to identify overpayments
before they are made.
Audit recovery specialists5 can use the software to identify potential duplicate payments.
1.# Purpose
The purpose of this monograph is to provide a practical guide to the identification of potential duplicate
payments using Web CAAT. The auditor does not need special computer s)ills in order to be able to
perform these tests because they are largely menu driven with (fill in the blan)s*.
9evelopment of the software began in August 044: when the author searched fruitlessly for a relatively easy
to use, economical software pac)age for analy;ing data on 'cel wor) sheets 1and other/. 9uring its
development, suggestions and improvements were made by a variety of audit practitioners.
2ore information about the system is available from the website. 2ore information is also available about
the author.
1.$ cope
This guide provides a general approach for identifying potential duplicate payments, as well as e'amples of
use.
Page 1
Abo! W"b CAAT
1.% "nten!e! au!ience
The software is intended for use by both internal and e'ternal auditors, audit recovery specialists, accounts
payable professionals, students learning data analysis, business analysts and anyone else interested in
identifying potential duplicate payments in a more efficient and effective manner.
1.& Har!'are re(uirements
At least :.0 2& of memory 1more if possible/. 2inimum free dis) space is :44 2&.
1.) oft'are re(uirements
#e+uires Windows <P, =ista or Windows >, Linu', or 2ac ?$@<. A web browser is re+uired to use the
software 1, >.4, AA 6.4, ?pera ...4, Google Chrome .4.4, $afari 0.6.
Page 2
G"!!#$% S!&'!"(
2 S"!!#$% ) !*" +o', b"$-*
The starting point for a test to identify potential duplicate payments is to load payment data transactions into
Web CAAT. The process for importing data into Web CAAT is covered elsewhere and will not be discussed
here. ?nce payment data has been loaded, then a (wor) bench* needs to be established. The purpose of
the wor) bench is to contain copies of payment transactions, which can then be (mar)ed* electronically,
along with comments and other information. The wor) bench does not necessarily need to contain all
payment transactions being tested. ,n fact, it is typically a subset of all payment transactions. #easons for
loo)ing at a subset may due to a specific time period being tested, e'clusion of certain foreign currency
transactions, e'clusion of vendors )nown not to be of interest in duplicate payment testing.
#.1 The menu
Arom the opening menu on Web CAAT, the menu item 9uplicate payment testing is selected. This brings up
a menu of various tests and procedures for duplicate invoice testing.
The main menu of Web CAAT appears as follows5
Page 3
G"!!#$% S!&'!"(
From the main form, two actions need to be taken:
1. Sign-in to the system
2. Select a table for processing (this will be the table of invoice payment
transactions
#.# ign*in to the system
Bnless a different user id and password is desired, sign"in with an id of (root* and a password of (test* 1both
without the +uotation mar)s.
Bpon successful sign"in, the system will then as) for the selection of a table. %ote that the menu item (Table
$election* can also be used for this purpose.
,n this e'ample, a test file named (invoice0* has been established and will be selected for illustration. %ote
that the actual table name, column names, etc. will vary and may not be li)e those shown here.
The table named (invoice0* is selected from the drop down list.
Page 4
S"!!#$% ) !*" +o', b"$-* !&b."
#.$ etting up the 'or+ bench
?nce the payment transaction table has been selected, the ne't step is to establish the wor) bench. The
starting point is to select the duplicate invoice item from the menu C?ther functionsD9uplicate invoices*/.
Page 5
G"!!#$% S!&'!"(
Clic)ing on this menu item will cause the following form to be displayed5
Page /
S"!!#$% ) !*" +o', b"$-* !&b."
2.4 P'o0#(#$% )'o-"11#$% )&'&2"!"'1
,n order to function, the system needs to have certain information. This information is gathered when the
contents of the form are completed and the (Process* button clic)ed. An e'planation of the form contents is
as follows5
W@P 9oc - name of the wor) paper document which identifies the form elements selected
Where - optional specification which can be used to restrict the duplicate payment tests to 8ust
certain transactions, e.g. date ranges, specific vendors, specific currencies, etc. ,f left blan) all
Page 3
G"!!#$% S!&'!"(
transactions are selected. %ote that there is an option under the ('clusion* menu item to e'clude
transactions from testing which can be used later.
Purpose@comments - any remar)s regarding the particular test
=endor number - select the name of the column which identifies the vendor or supplier
,nvoice number " select the name of the column which identifies the supplierEs invoice number
,nvoice 9ate " select the name of the column which identifies the date to be used for testing,
normally the invoice date
,nvoice amount " select the name of the column which identifies the numeric amount to be tested,
normally invoice amount
Au;;y " select the name of the column which identifies the column to be used for (fu;;y* testing.
%ormally this will be the invoice number
Chec)bo' - Chec) the bo' if the e'isting wor) bench information is to be replaced. %ormally the
bo' will be chec)ed the first time a new study is being performed. ,f you wish to continue a previous
study, then the wor) bench data should not be replaced and therefore the bo' should be unchec)ed.
Process - Clic) the (Process* button once all the information has been entered
2.5 C'"&!#$% !*" +o', b"$-* !&b."
When the (Process* button is clic)ed, the wor) bench table will be created if the chec)bo' was chec)ed.
The table will not be created instantly because a number of steps need to be performed. The length of time
to create the wor) bench will vary depending upon the number of transactions involved. ?nce the wor)
bench data has been created a diagnostic screen will be displayed. There should be nor errors shown and
the form will appear something as follows5
Page 4
S"!!#$% ) !*" +o', b"$-* !&b."
This shows the details of how the wor) bench table was set up. Fey is that no error or warning messages
are shown. rror or warning messages have an error number and a message. ,n for the form above, there
are two warning messages numbered .4>0 which indicate that some inde'es did not e'ist.

Page 5
G"!!#$% S!&'!"(
#.) ./clu!ing transactions from testing
,n some cases it may be desirable to restrict testing for duplicate payments. 'amples include testing only
transactions within a date range, e'cluding certain vendors from testing, e'cluding certain locations, foreign
currencies, etc. All this can be done using the (Payment 'clusion* menu item.
Clic)ing on the menu item (Payment e'clusion* brings up the following form5
To e'clude transactions from testing, type the e'clusion criteria into the bo' labeled (Where*. An e'ample is
circled above where transactions prior to Guly ., 044H were not to be tested. The e'act wording to use will
Page 16
S"!!#$% ) !*" +o', b"$-* !&b."
depend upon the e'clusion ob8ectives and the names of the columns being used. &elow are 8ust a few
e'amples to illustrate. ?n the left is the synta' of the statement and on the right is an e'planation of the
e'clusion ob8ective.
S!&!"2"$! 17$!&8 E8-.1#o$ ob9"-!#0"
I,nvoice 9ateI J (044H"4>"4.* 9o not test transactions with a date earlier than Guly
., 044H
ICurrency CodeI KL MB$9E 9o not test transactions which do not have a
currency code mar)ed as B$9
I=endor numberI in1M.067:E,EA&C9E,,#$E/ 'clude three vendors from testing - .067:, A&C9
and ,#$
,snull1IP? numberI/ 9o not test transactions which do not have an
assigned P? number
I,nvoice amountI J 4 ,gnore credit memos
These are 8ust a few e'amples. %ote that when a column name contains an embedded blan), it must be
enclosed with the bac) +uote which is usually found in upper left corner of the )eyboard, 8ust to the left of the
digit (.*.
Clic)ing on the (Process* button will mar) all the indicated rows with an (<* 1e'clude/ and echo bac) the
command used such as shown below,
#., Report of suspect !uplicates
As wor) proceeds, suspect duplicate payments are identified. The wor) bench provides the facility
to classify these payment transactions as suspect duplicates or e'clude them from further processing. ?nce
a transaction has been classified, then it is no longer included in any further testing.
At the end of the process the system provides the ability to list all transactions which have been identified as
duplicate suspects. The list is provided as both a report as well as a te't file which can be imported into
'cel 1or other program/ for further analysis.
Page 11
G"!!#$% S!&'!"(
Clic)ing on the menu item (#eport of suspect duplicate payments* opens the following form.
Page 12
A11"11#$% !*" '"1.!1
3 R$$#$% !*" !"1!1
Currently 1:@04../ there are .N tests which are lettered (A* through ($*. This document e'plains the
procedures for running the tests.
$.1 1vervie' an! general proce!ures
All of the procedures described can be completed using menus, drop down lists and (fill in the
blan)s*. Aor each type of analytical review procedure described, a general overview of the procedure and
its purpose will be provided.
ach procedure wor)s in a very similar fashion, which consists of three steps5
.. Clic) the menu item to specify the test to be performed
0. Complete the parameters needed for the test, if any, and clic) the (Process* button
6. #eview the output report, and for any transactions which can be classified, specify (9uplicate* or
('cluded* from the drop down list. ,n addition, the uni+ue number of the corresponding payment
can be specified, along with comments.
ach of the procedures contains detail e'planatory information at the bottom of the form.
The menu items appear as shown below.
Page 13
R$$#$% !*" !"1!1
%ote5 colors can be modified using the menu item (?ther Processes D menu items ( and (?ther Processes D
bac)ground colors*.
Page 14
R$$#$% !*" !"1!1
3.2 Test A 2 3our 'ay match
Automated systems with functioning controls, should not produce a duplicate payment, defined as two
payments consisting of the same vendor number, same invoice number, invoice date and amount. Oowever,
this test can be used to determine if this is in fact correct.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice number, invoice date and
invoice amount.
,nput form
Page 15
R$$#$% !*" !"1!1
?utput form
3.3 Test 4 2ame ven!or number5 invoice an! amount
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice number and amount 1invoice dates can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice number and invoice amount.
,nput form
?utput form
Page 1/
R$$#$% !*" !"1!1
3.4 Test C 2ame ven!or number5 invoice an! !ate
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice number and date 1invoice amounts can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice number and invoice amount.
,nput form
Page 13
R$$#$% !*" !"1!1
?utput form
3.5 Test D 2ame ven!or number5 invoice !ate an! amount
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice date and amount 1invoice numbers can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice date and invoice amount.
Page 14
R$$#$% !*" !"1!1
,nput form
?utput form
Page 15
R$$#$% !*" !"1!1
3./ Test . 2ame ven!or5 amount5 similar invoice 67D18
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number
and invoice amount. ,nvoice numbers would be the same if characters other than digits or letters were
ignored.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice amount. ,nvoice numbers
would be the same if characters other than digits or letters were ignored.
,nput form
?utput form
Page 26
R$$#$% !*" !"1!1
3.3 Test 3 2 ame ven!or5 amount5 similar invoice 6718
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
amount 1invoice numbers can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice amount. ,nvoice numbers
would be the same if characters other than letters were ignored.
,nput form
Page 21
R$$#$% !*" !"1!1
?utput form
Page 22
R$$#$% !*" !"1!1
3.4 Test 9 2 ame ven!or5 amount5 similar invoice 6D18
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice amount 1invoice numbers can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice amount. ,nvoice numbers
would be the same if characters other than digits were ignored.
.
,nput form
?utput form
Page 23
R$$#$% !*" !"1!1
3.5 Test H 2 ame ven!or5 amount5 similar invoice 67evenshtein
!istance8
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice number and amount 1invoice numbers can differ/.
I$)! -'#!"'#&5 2a'imum Levenshtein distance.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice amount. ,nvoice numbers
are within the Levenshtein distance specified.
,nput form
Page 24
R$$#$% !*" !"1!1
?utput form
Page 25
R$$#$% !*" !"1!1
3.16Test " 2 ame ven!or5 amount5 similar invoice 6transposition8
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
and amount 1invoice numbers are transposed/.
I$)! -'#!"'#&5 2a'imum number of e'tra characters.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice amount. ,nvoice numbers
would be the same if transpositions were considered.
,nput form
?utput form
Page 2/
R$$#$% !*" !"1!1
3.11Test ; 2 ame ven!or5 similar amount5 similar invoice
6characters in common8
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
and amount 1invoice numbers can differ/.
I$)! -'#!"'#&5 rounding factor and degree of similarity
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and similar invoice amount. ,nvoice
numbers have the specified percentage pf characters in common.
.
,nput form
Page 23
R$$#$% !*" !"1!1
?utput form
Page 24
R$$#$% !*" !"1!1
3.12Test < 2 ame ven!or5 !ate5 amounts 'ithin a percentage
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice date 1invoice amounts within a percentage/.
I$)! -'#!"'#&5 2a'imum percentage difference between amounts.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number and invoice date. ,nvoice amounts are
within a specified amount of each other
,nput form
Page 25
R$$#$% !*" !"1!1
?utput form
3.13Test 7 2 ame ven!or5 !ate5 similar invoice 6lea!ing characters8
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice date 1invoice numbers can differ/.
I$)! -'#!"'#&5 none.
Page 36
R$$#$% !*" !"1!1
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice date and invoice numbers
having the same leading characters.
,nput form
?utput form
Page 31
R$$#$% !*" !"1!1
3.14Test = 2 ame ven!or5 !ate5 similar invoice 6trailing
characters8
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice date 1invoice numbers can differ/.
I$)! -'#!"'#&5 Ailter to be used - L9?, L?, 9? or %one
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice date and invoice numbers
similar considering trailing characters.
,nput form
Page 32
R$$#$% !*" !"1!1
?utput form
Page 33
R$$#$% !*" !"1!1
Page 34
R$$#$% !*" !"1!1
3.15Test > 2 ame ven!or5 !ate5 amount5 !ifferent invoices
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice date and amount 1invoice numbers differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice number and invoice date, with
different invoice numbers.
,nput form
?utput form
Page 35
R$$#$% !*" !"1!1
3.1/Test 1 2 ame invoice5 !ate5 amount5 !ifferent ven!ors
This test chec) for a duplicate payment, defined as two payments consisting of the same invoice number,
invoice date and amount 1vendors are different/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same invoice number, invoice date and invoice amount with
different vendors.
,nput form
Page 3/
R$$#$% !*" !"1!1
?utput form
Page 33
R$$#$% !*" !"1!1
3.13Test P 2 ame invoice5 !ate5 amounts 'ithin percentage
This test chec) for a duplicate payment, defined as two payments consisting of the same invoice number,
invoice date and amounts within a percentage of each other.
I$)! -'#!"'#&5 2a'imum percentage difference.
S"."-!#o$ -'#!"'#& - two payments having the same invoice number, invoice date and amounts within a
percentage.
,nput form
?utput form
Page 34
R$$#$% !*" !"1!1
3.14Test ? 2 ame ven!or5 amount5 invoice5 similar !ate
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice amount 1invoice dates can differ/.
I$)! -'#!"'#&5 none.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice amount and invoice dates
within a specified number of days apart
,nput form
Page 35
R$$#$% !*" !"1!1
?utput form
3.15Test R 2 ame ven!or5 invoice5 similar !ate
This test chec) for a duplicate payment, defined as two payments consisting of the same vendor number,
invoice number 1invoice dates can differ/.
Page 46
R$$#$% !*" !"1!1
I$)! -'#!"'#&5 2a'imum number of days difference.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice number and invoice dates are
within a specified number of days apart.
,nput form
?utput form
Page 41
R$$#$% !*" !"1!1
3.26Test 2 ame invoice5 !ate5 amount5 similar ven!or using
7evenshtein !istance
This test chec) for a duplicate payment, defined as two payments consisting of the same invoice number,
invoice date and invoice amount 1vendors can differ/.
I$)! -'#!"'#&5 2a'imum number for Levenshtein distance.
S"."-!#o$ -'#!"'#& - two payments having the same vendor number, invoice date and number with vendor
numbers a specified Levenshtein distance apart.
,nput form
Page 42
R$$#$% !*" !"1!1
?utput form
Page 43
A11"11#$% !*" '"1.!1
% Assessing the results
As each +uery is run, some may identify suspect duplicate payments. ach payment can be identified as
either a potential duplicate payment, a payment which is not a duplicate payment or a payment that should
be e'cluded from further testing. All of this information is stored in the wor) bench table. At any time, a
report of suspect duplicate payments can be printed or imported into an 'cel wor) boo) for further analysis.

%.1 1ther tests
The system is open source and e'tensible. ,t is entirely feasible to develop and implement other test
procedures, given a basic )nowledge of the POP language and using the scripts provided.
%.# ?uestions5 comments an! suggestions
Please provide any comments, suggestions or +uestions to 2i)e.&la)leyPe;rstats.com 1or call me at N.N"
0.N".Q00/. , welcome your comments and will try to respond to all e"mails within one business day.
Page 44