Search
Close this search box.
Home / Articles / Credit Card Payments – A Case Study in Fraud

Credit Card Payments – A Case Study in Fraud

August 21, 2014

Share:

Every once in a while a situation comes along that manages to shock (ok – surprise) me.  Having seen many instances of occupational fraud in all shapes and sizes, I find myself surprised by what I see far less frequently.  Having said that, a case we investigated recently did remind me of just how creative and resourceful perpetrators of occupational fraud can be.

A bookkeeper employed by a relatively small family owned business found herself in a difficult personal financial situation.  The lifestyle maintained by the accountant and her family was quickly outpacing her ability to finance it (her spouse was operating a newly formed, not yet profitable, retail business).

Means, Motive and Opportunity

Confronted with mounting credit card debt, the bookkeeper was feeling the pressure.  As is often the case, her personal financial problems were not known to her employer.  As her debt deepened, she began to rationalize the act of stealing from her employer as a means of temporarily “borrowing” enough to resolve her immediate financial problems.  She now needed the right opportunity.

That opportunity presented itself in the form of customer credit card activity.  As the only accountant on staff, the bookkeeper found herself responsible for executing nearly all of the cash receipt and cash disbursement activity of the company.  The role also included reconciling the bank account on a monthly basis.

The Loophole

Like most small businesses, the company uses an off-the-shelf software package to handle its general ledger activity and to manage its invoicing and payment processing.  As customers were offered an opportunity to pay invoices by credit card, the bookkeeper needed to quickly get up to speed on the mechanics of recording the payments.

Within the software system, the receipt of a credit card payment is handled no differently than the receipt of cash or checks.  The outstanding invoice being paid is identified, and the payment is applied to it.  Unlike the receipt of cash or checks, which are physically deposited into the company’s bank account, the credit card payment must be deposited electronically.  To accomplish this, the software manufacturer provides access to an online, virtual server within which the credit card payment is processed and the authorized depository bank account is paid.

This system is effective in processing payments, but presents a significant loophole:  refunds to credit and debit cards can be processed the same way, and without linking the refund to a previous payment or customer card.  Through a simple exercise of trial and error, the bookkeeper had stumbled onto a relatively easy and concealable scheme.

Over the course of almost three years, the bookkeeper, whose initial rationalization was to “borrow” enough money from her employer to resolve her immediate financial difficulties, managed to refund to her own credit and debit cards more than $260,000.  And what further exacerbated the loophole and facilitated the bookkeeper’s concealment was the way in which the credit card activity posted to the company’s bank statement.  On a given day, all of the credit card activity posted to the bank account was reflected on the bank statement as one net amount.  By timing a $9,000 refund made to her own cards to coincide with a day on which a $10,000 customer credit card payment was received, the bookkeeper was able to engineer a net $1,000 deposit reported on the bank statement.   Add to the mix that the bookkeeper prepared the bank reconciliation with little supervision, the theft was adequately concealed.

The Moral of the Story

As it turned out, the bookkeeper didn’t stop with this scheme, and eventually made enough mistakes to get caught.  As the case was investigated and the damages were quantified, the owners of the business had to face the reality that blind faith in a trusted employee is a poor substitute for a properly designed and maintained set of internal controls.  Even with a limited accounting staff, cross training on critical functions, basic segregation of duties, and proper oversight are immediately achievable steps that can prevent the devastation (financial and emotional) caused by employee theft.  Concepts that sound foreign and complicated can be surprisingly simple and effective with the proper guidance.

And one more thing: insist that your business’ bank reconciliation process include obtaining the monthly statements generated by your merchant services provider.  These statements present the detail of every credit or debit card transaction, not simply the net amounts reported on your bank statement.  With this information in hand, a review of the bank reconciliation would have quickly identified the theft.  The bookkeeper in this case simply shredded these upon receipt, and the employer was not aware they even existed.

© 2014

All content provided in this article is for informational purposes only. Matters discussed in this article are subject to change. For up-to-date information on this subject please contact a Clark Schaefer Hackett professional. Clark Schaefer Hackett will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within these pages or any information accessed through this site.

Guidance

Related Articles

Article

2 Min Read

New IRS Guidance: Tax Treatment for Energy Efficiency Rebates

Article

2 Min Read

Marriage & Tax Returns: The Benefits of Joint vs. Separate Filing

Article

2 Min Read

Not-for-Profits and the De Minimis Indirect Cost Rate

Article

2 Min Read

Tax Deductions for Home Office Professionals

Article

2 Min Read

OMB Rolls Out Updated Guidance Around Federal Awards

Article

2 Min Read

The other side in an M&A deal can lead to tax benefits for both

Get in Touch.

What service are you looking for? We'll match you with an experienced advisor, who will help you find an effective and sustainable solution.

  • Hidden
  • This field is for validation purposes and should be left unchanged.