Duplicate Payments UserGuide1

8/10/2019 Duplicate Payments UserGuide1

1/49

Duplicate payment testprocedures using

Web CAATData analysis made easier

Page 1


2/49

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. Allcomments and suggestionsare 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
http://ezrstats.com/doc/Testing_for_Duplicate_Payments.pdfhttp://ezrstats.com/doc/Testing_for_Duplicate_Payments.pdfhttp://ezrstats.com/Courses/home.htmlhttp://ezrstats.com/doc/Testing_for_Duplicate_Payments.pdfhttp://ezrstats.com/doc/Testing_for_Duplicate_Payments.pdfhttp://ezrstats.com/Courses/home.html


3/49

Document History

Revision History

Revision

Number

Revision Date Summary of Changes

1. !"#"$11 %nitial version

Page 3


4/49

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 vervie' 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


5/49

$.) Test 2ame ven!or5 amount5 similar invoice 67D8 ............. .............. .............. .............. ............... ............. ..... ..... ..... ...#0

$., Test 3 2 ame ven!or5 amount5 similar invoice 678 ............. .............. .............. .............. ............... .......... ...... ...... ..... ..... .#1

$.- Test 9 2 ame ven!or5 amount5 similar invoice 6D8 ............. .............. .............. .............. .............. ........... ..... ...... ..... ..... .#$

$.: 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 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 ther tests ............... .............. .............. .............. .............. ............... .............. .............. .............. .............. ......... ...... ...... ...... ...%%

%.# ?uestions5 comments an! suggestions .............. .............. ............... .............. .............. .............. .............. ............. ..... ...... ....%%

Page 5


6/49

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

theauthor.

1.$ cope

This guide provides a general approach for identifying potential duplicate payments, as well as e'amples of

use.

Page 1
http://ezrstats.com/http://ezrstats.com/About.htmhttp://ezrstats.com/About.htmhttp://ezrstats.com/http://ezrstats.com/About.htm


7/49

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 , Linu', or 2ac [email protected], 6.4, ?pera .4, Google Chrome 4.4, $afari 0.6.

Page 2


8/49

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

rom 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


9/49

G"!!#$% S!&'!"(

From the main form, two actions need to be taken:

1. Sign-in to the system2. 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


10/49

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 ?ther functionsD9uplicate invoices*/.

Page 5


11/49

G"!!#$% S!&'!"(

Clic)ing on this menu item will cause the following form to be displayed5

Page /


12/49

S"!!#$% ) !*" +o', b"$-* !&b"

2.4 P'o0#(#$% )'o-"#$% )&'&"!"'

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


13/49

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

u;;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


14/49

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


15/49

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 uly , 044H were not to be tested. The e'act wording to use will

Page 16


16/49

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!&!""$! 7$!&8 E8-#o$ ob9"-!#0"

Invoice 9ateI J (044H"4>"4* 9o not test transactions with a date earlier than uly

, 044H

ICurrency CodeI K MB$9E 9o not test transactions which do not have a

currency code mar)ed as B$9

I=endor numberI in1M067: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

Invoice 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 (


17/49

G"!!#$% S!&'!"(

Clic)ing on the menu item (#eport of suspect duplicate payments* opens the following form.

Page 12


18/49

A"#$% !*" '"!

3 R$$#$% !*" !"!

Currently 1:@04/ there are N tests which are lettered (A* through ($*. This document e'plains the

procedures for running the tests.

$.1 vervie' an! general proce!ures

All of the procedures described can be completed using menus, drop down lists and (fill in the

blan)s*. or 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


19/49

R$$#$% !*" !"!

%ote5 colors can be modified using the menu item (?ther Processes D menu items ( and (?ther Processes D

bac)ground colors*.

Page 14


20/49

R$$#$% !*" !"!

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


21/49

R$$#$% !*" !"!?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/


22/49

R$$#$% !*" !"!

3.4 Test C 2ame ven!or number5 invoice an! !ate


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 1


23/49

R$$#$% !*" !"!

?utput form

3.5 Test D 2ame ven!or number5 invoice !ate an! amount


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 1


24/49

R$$#$% !*" !"!

nput form

?utput form

Page 1


25/49

R$$#$% !*" !"!3./ Test 2ame ven!or5 amount5 similar invoice 67D8

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 numberswould be the same if characters other than digits or letters were ignored.

nput form

?utput form

Page 26


26/49

R$$#$% !*" !"!

3. Test 3 2 ame ven!or5 amount5 similar invoice 678


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


27/49

R$$#$% !*" !"!

?utput form

Page 22


28/49

R$$#$% !*" !"!3. Test 9 2 ame ven!or5 amount5 similar invoice 6D8


invoice amount 1invoice numbers can differ/.

I$)! -'#!"'#&5 none.

S""-!#o$ -'#!"'#&- two payments having the same vendor number and invoice amount. nvoice numberswould be the same if characters other than digits were ignored.

.

nput form

?utput form

Page 23


29/49

R$$#$% !*" !"!

3. Test H 2 ame ven!or5 amount5 similar invoice 67evenshtein

!istance8


invoice number and amount 1invoice numbers can differ/.

I$)! -'#!"'#&5 2a'imum Levenshtein distance.


are within the Levenshtein distance specified.

nput form

Page 24


30/49

R$$#$% !*" !"!

?utput form

Page 25


31/49

R$$#$% !*" !"!3.16Test " 2 ame ven!or5 amount5 similar invoice 6transposition8


and amount 1invoice numbers are transposed/.

I$)! -'#!"'#&5 2a'imum number of e'tra characters.


would be the same if transpositions were considered.

nput form

?utput form

Page 2/


32/49


33/49

R$$#$% !*" !"!

?utput form

Page 2


34/49

R$$#$% !*" !"!

3.12Test < 2 ame ven!or5 !ate5 amounts 'ithin a percentage


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 arewithin a specified amount of each other

nput form

Page 2


35/49

R$$#$% !*" !"!

?utput form

3.13Test 7 2 ame ven!or5 !ate5 similar invoice 6lea!ing characters8


invoice date 1invoice numbers can differ/.

I$)! -'#!"'#&5 none.

Page 36


36/49

R$$#$% !*" !"!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


37/49

R$$#$% !*" !"!

3.14Test = 2 ame ven!or5 !ate5 similar invoice 6trailingcharacters8


invoice date 1invoice numbers can differ/.

I$)! -'#!"'#&5 ilter 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


38/49

R$$#$% !*" !"!

?utput form

Page 33


39/49

R$$#$% !*" !"!

Page 34


40/49

R$$#$% !*" !"!

3.15Test > 2 ame ven!or5 !ate5 amount5 !ifferent invoices


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


41/49

R$$#$% !*" !"!

3.1/Test 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/


42/49

R$$#$% !*" !"!

?utput form

Page 3


43/49

R$$#$% !*" !"!3.1Test P 2 ame invoice5 !ate5 amounts 'ithin percentage


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 3


44/49

R$$#$% !*" !"!

3.1Test ? 2 ame ven!or5 amount5 invoice5 similar !ate


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 3


45/49

R$$#$% !*" !"!

?utput form

3.1Test R 2 ame ven!or5 invoice5 similar !ate


invoice number 1invoice dates can differ/.

Page 46


46/49

R$$#$% !*" !"!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


47/49

R$$#$% !*" !"!

3.26Test 2 ame invoice5 !ate5 amount5 similar ven!or using

7evenshtein !istance


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


48/49

R$$#$% !*" !"!

?utput form

Page 43


49/49

Duplicate Payments UserGuide1

Documents

Transcript of Duplicate Payments UserGuide1