Billing Schemes

Accounting Data Analytics

Accounting 420
Course Structure
Theme 1 The Context of Accounting Analytics : The Search for Fraud Chapters 1-3

Business Transactions
Theme 2: The Tools of Accounting
Analytics Chapters 4-6
Theme 3: Misappropriation
of Assets Fraud Schemes
Chapters 7-13
Reasonable Assurance:
Free of Fraud & Error
Theme 4: Non-Misappropriation
of Assets Fraud Schemes
Chapters 14-16 & 18

Audit & Analytics/The Search for Fraud & Error

Background on Billing Schemes
• Billing schemes occur
• In the normal course of business activities
• Accounts payable
• Travel and entertainment expenses and reimbursements
• Most payables go through the same accounts payable process
• Large number of transactions
• Opportunities for fraud and errors
• Examples of errors
• Duplicate payments
• Unnecessary charges
• Late fees
• Missed discounts
• Post to wrong vendor account
Background on Billing Schemes
• Accounts payable fraud example
• Form a bogus company and bill for goods and services not provided
• Look like any other vendor
• Duplicate billings
• Billing fraud with service
• No inventory to account for and no collusion needed with receiving and
warehousing
• Sell at inflated prices
• Less risky
Fraud Using a Bogus Company (Steps)
• Form a company
• Setup
• Bank account
• Post office box
• Submit documents for false or fraudulent payments
• Get authorization of these fraudulent documents
• Forge or collusion
• Once one is done, the subsequent ones become easier
• Once company is in the master vendor list other frauds become easier
Preventing Fraud in Payments
• Have strong controls in place
• Automated payment systems usually require technology-based
internal controls
• Manual payment processes require manual controls
State Vendor Payments File
• Make sure you know the field definitions and measurement
• Over 2 million transaction
• Payment_Amount
• $34,388 zero amounts
• Range $5,996,550.22 to $48,907,078.15
• Invioce_Date_2
• 76,461 errors
• Payment_Date_2
• No data errors
• 41 payments on Sunday and 64 on Saturday
Transaction Types
• B voucher
• C positive & negative amounts
• H regular voucher
• P paid amounts
• R refunds
• W negative amount
Analyzing Transactions of Type P: Benford’s
Law
• Extract all transactions of Transaction Type P
• Apply tests to this database
• Review field statistics
• Benford’s Law
• First digit, first two digits, and last two digits generally conformed
• May want to select 1 or 2 vendors and reapply these tests
Relative Size Factor (RSF)

• Multiple steps
• RSF>10 is the cutoff threshold
• Found two above this threshold
• Oklahoma City Abstract and Title RSF=57.42
• Deborah Brown (charter) RSF=18.10
• I think a better approach to RSF
• Summarize on the strata calculating average and standard deviation
• Calculate the grand mean and average the standard deviations
• Use these values to calculates z-scores
• If a strata has z-score>=2.00 extract records to spreadsheet and calculate RSF
• Calculate z-score for each transaction in the questionable strata
Even Dollar Amounts
• Most amounts of any variety (liabilities) rarely are in even amounts
• In IDEA, extract the even amounts in the field of interest
• For example, even 1000s, IDEA code (payment % 1000)=0 .AND. Payment <>0)
• % invokes the MOD and the code divides the residual by 1000 and selects records with a
0 residual after dividing by 1000 (even 1000 payment) and makes sure the payment is
not equal to zero
• In the vendor payments database has too many even 1000 dollar
payments to investigate all of them.
• Draw a sample and study the sample
Same-Same-Same Test & Same-Same-
Different Test
• Same-Same-Same Test
• Compare multiple fields to see if all are identical
• For example, in vendor payment file might want to see transaction with
identical values for
• Agency_Name, Vendor_Name, Payment_Date_2, Invoice_ID
• Same-Same-Different Test
• Compare multiple fields to see if all are identical
• For example, in vendor payment file might want to see transaction with
identical values for
• Agency_Name, Vendor_Name, Payment_Date_2, Invoice_ID
Payments Without Purchase Order Tests
• Typically each payment should have a matching purchasing order
• Usually a matching invoice too
• In IDEA and payments DB
• Purchase_order_contract_number = “ “ .AND. Payment_Amount <> 0.0
• Finds transactions with missing PO numbers with payments >0
• If there are a large number of such transactions
• Filter these transaction for level of materiality
• Sample from these transactions
Length of Time Between Invoice and
Payment Date Tests
• Calculate days between invoice date and payment date
• Looking for payment penalties and missed payment discounts
• Create a new field “Date_Difference” using @Age(Payment_Date_2,
Invoice_Date_2)
• Difference in days between these two fields
• Stratify the transactions on the date_difference field
• 0-120 day strata
• Results
• 826,000 payments on same day as invoice date
• Examine further: invoice date data unreliable
• Once the unreliable dates omitted examine the remaining ones: internal control and procedure
violations
Length of Time Between Invoice and
Payment Date Tests
• Additional examination create a new field for day of the week the
payment was made
• @workday(payment_date_2) returns 0 if payment made on Saturday or
Sunday, 1 otherwise
• @DOW(payment_date_2) returns 1-Sunday through 7-on Saturday
• Results
• 41 payments made on Sunday and 64 payments on Sunday
• Extract these payments to see data errors; payment magnitude; recipient
• After filtering found 8 payments on Sunday & 13 on Saturday most of which
were made to Water Resources Board Agency over year after the invoice date
Search for Post Office Boxes
• Most vendors have business street addresses
• Except for an occasional small business or non-profit
• PO Box raises red flags for fraud
• Hide identity
• False business
• Search vendor addresses in a master file
• Use wildcards * for multiple characters or ? For one character
• Can also use Boolean connectors .AND. .OR.
• If have vendors with PO Box addresses and payments, investigate
further
Match Vendor & Employee Addresses
• The idea is that the same address shared by a vendor and employee is a red flag of
fraud
• Employee is submitting false invoices
• Create a new field: Address_Check using
• @strip(@left(supplier_address,10)): specific commands depend on formatting of supplier
addresses
• “Strip” eliminates all spaces, control characters, & punctuation
• “Left” starts the strip from the left
• “10” denotes the strip of 10 characters
• Create a similar field in the employee file or database
• Specific code depends on field formatting
• Join the supplier address database (primary) with employee database (secondary)
• Exact match on the address check field in each database
• Result: only one match” requires investigation
Payments to Vendors not in Master File
• Join payments database (primary) and vendor or supplier database
(secondary)
• Join on supplier or vendor number
• Join records with NO SECONDARY MTCH
• Yield is a database with records of payments to vendors not in master
vendor list
• Results in this database
• One record of payment of $14,370.05 paid to supplier 20536
• Same person who authorized payment also posted the payment (lack of segregation od duties)
• Vendor may be false or a former supplier with whom we no longer do business
• If it is “one-off” transaction usually have a generic vendor number like 99999
Gap Detection: Sequence of Check Numbers
• IDEA has a gap detection routine
• In the vendor payment database, check numbers are alphanumeric
rather than numeric
• IDEA sets up a mask for the particular check format
• These results find one missing check A52656
• Investigate this check and payment