Using the sample payment file included with the IDEA software, a number of tests can be demonstrated.

Of major concern would be the same person authorizing the check and also performing the posting of payment to books.

In the sample payment file we note that POSTED_BY field data of initials is consistent while the AUTH field sometimes contains periods after the initials and sometimes not. We first normalize the AUTH field by creating a new field called AUTHORIZE using the equation of @Strip(AUTH), which removes spaces, punctuations, and control characters from the field, as shown in Figure 9.1.

From the test, we find that there were five transactions that were authorized and posted by the same person, as shown in Figure 9.2. One of the five transactions had no entries of who authorized the payment or who posted the payment. All of these transactions must be reviewed in greater detail.

Since we are now aware that the system permits blank entries, we need to extract out all transactions that are blank in either the POSTED_BY field or the AUTHORIZED

Preparation to Determine the Same Person Both Authorized and Posted the Transaction

FIGURE 9.1 Preparation to Determine the Same Person Both Authorized and Posted the Transaction

Results Where the Same Person Authorized and Posted the Transactions

FIGURE 9.2 Results Where the Same Person Authorized and Posted the Transactions

field. This is a good example where the results from one test lead to the need of applying additional tests based on the output.

We can use the equation of AUTHORIZED = = " " .OR. POSTED_BY = = " " to meet both these conditions. The results are displayed in Figure 9.3.

Results of Where There Are Blank Entries for the POSTED_BY Field or the AUTHORIZED Field

FIGURE 9.3 Results of Where There Are Blank Entries for the POSTED_BY Field or the AUTHORIZED Field

Two additional transactions are discovered to have been posted with no authorization. In addition to reviewing these transactions, determination of how the system allowed this is necessary. Is there a programming error at the stage where processing of transactions is allowed, even when all fields are not populated? Possibly, the system does not proceed without all the fields completed but allows for media cation of these two fields later on. If this is the case, then reliance cannot be placed on the test results shown in Figure 9.2. The fraudster merely has to change one of the fields so it does not show that the same person both authorized and posted the transactions. The potential of this cover-up scheme requires sampling and testing of the invoices and viewing the actual signed authorizing and posting initials.

To determine whether there are any missing check numbers, we can perform gap detections as shown in Chapter 8 in Figure 8.33. In addition to gaps, we are interested to know whether there were payments using out-of-sequence checks, that is, check numbers that are out of sequence in relation to the date. We simply index the PAY_ DATE_DATE field and then the CHEQUE field, and visually scan for out-of-sequence transactions, as in Figure 9.4.

Indexed by Date and Check Number

FIGURE 9.4 Indexed by Date and Check Number

If the CHEQUE field was a numeric field rather than a character field, we take an additional step after the index to identify every out-of-sequence transaction. We can append a new field using the equation of @If(@GetNextValue("CHEQUE") - CHEQUE = 1, 10, 11).

The equation takes the next value in the CHEQUE field, subtracts the current check value, and if the difference is 1, the number 10 is returned in the new field. If the difference is not 1, then the number 11 is displayed in the new field. All items with 11 are transactions not in sequence.

Payments based on an invoice that was diverted and then subsequently properly paid can be detected by using the Duplicate Key Exclusion test. We look for the same invoice number along with the same amount, but with different vendor names. In our sample payment file, there were no records that matched our criteria. We can also test for transactions of payments made to the same vendor with the same invoice number but with different amounts. These transactions could be payments made to the vendor in error or could be used as a mechanism for check-tampering fraud.

Our example test for the same supplier number along with the same invoice number but with different payment amounts is shown in Figure 9.5.

Duplicate Key Exclusion Test for Different Amounts Paid to the Same Supplier Base on the Same Invoice Number

FIGURE 9.5 Duplicate Key Exclusion Test for Different Amounts Paid to the Same Supplier Base on the Same Invoice Number

Our test results in 10 records that match the criteria, as shown in Figure 9.6.

Results of the Duplicate Key Exclusion Test

FIGURE 9.6 Results of the Duplicate Key Exclusion Test

Other Analytical Tests

Other analytical tests that can be done in which the data file contains additional fields include:

- Extract and review checks made out to cash, as these are of higher risk for fraud.

- Extract void checks and test for accuracy, as they may actually be cashed and just coded as void.

- Extract and review all payments of zero amounts, as the actual amounts may be higher or the amount may be changed from zero later on.

- Payments without purchase orders, as shown in Figure 8.17 in Chapter 8, should be reviewed. These could be further summarized by vendor, authorizer, and poster or in any combination.

- Summarize debit memos by vendor, authorizer, and poster or in any combination.

- Join payment system employee access log information for the authorizer or poster with the check register/payment database or electronic payment database.

- Extract and review journal entries or adjustments impacting the bank accounts.

In our example payment file, there is a MEMO field. We can check for any adjustments by using the search feature of IDEA to look for variations of the word adjustments.

Search Option and Results

FIGURE 9.7 Search Option and Results

We had used the wildcard character of - after the word adjust, as this would find words such as adjust, adjusted, adjustment, and adjustments in both uppercase and lowercase or in combination. Our search resulted in 15 matches, as seen in Figure 9.7. To access the record details we can click on the underlined words in the TEXT search-result field.


Some critical tests cannot be done by analyzing data alone or reviewing internal documents. Statements should be obtained from vendors, including those with zero balances, and compared to accounts payable. Data analytics can assist by using sampling to reduce the number of confirmations with vendors. Online bank balances and reconciliation should be reviewed on a regular basis. This is especially necessary with electronic-payment systems. The bank transactions details can be downloaded and then, by using the Join feature of IDEA, you can output those transactions that do not match with the check register database.

Fraudulent schemes are evolving rapidly, especially in the area of electronic payments. When the fraudster takes over an organization's electronic-payment system, instead of sending payments directly to the shell company they control, they can add another layer of complexity that makes detection more difficult. If the fraudster has taken over the payment systems of other organizations at the same time, they can have one organization pay the other legitimate organization i rst, and then have the second organization pay the fraudsters. This makes the electronic payments appear to be normal business-related transactions.

The risk of being victim of fraudulent schemes can be reduced by good internal controls that should not be circumvented. Successful check-tampering schemes rely heavily on the lack of separation of duties and lax internal controls.

< Prev   CONTENTS   Next >