Accounts Payable News recently ran a good article on the top six ways to carry out P2P fraud that every Supply Management professional should read BEFORE implementing any P2P system. While the sheer presence of a P2P system will discourage fraud, as fraud will be much harder to hide and/or require collusion if the system is properly integrated, it also enables fraud to be conducted faster and at a much larger scale if there are holes in the implementation. But first, let’s look at the frauds identified:

• Social Engineering
  A user who doesn’t need admin access gets it by convincing IT that it will be quicker if they can create accounts for authorized individuals, or that they need it for testing after hours. If such admin access can be used to create new, fictitious, suppliers with banking information that don’t require payment approvals …
• Fictitious Invoices for non-PO spend below the bar
  If invoices below a certain threshold, like $1,000, automatically get paid (without a purchase order or, worse, goods receipt match) from preferred suppliers if the line items are on an approved list, then all it takes is collusion between a buyer and supplier to generate and approve a few (dozen) false invoices and both get a free vacation on the Riviera.
• Reassignment and Undermining of Control
  If a fraudster can convince others to reassign approvals or part of the payment process to himself, then he can approve invoices from fictitious invoices from fake suppliers, which are actually companies, and bank accounts, he controls.
• Receipt of goods not actually delivered
  If the buyer, who never steps foot in the warehouse or on the construction site, receipts goods never delivered, the buyer can arrange for a supplier to be paid twice if the supplier sends an invoice before the goods, gets paid right away, and then drops off a second invoice with the goods, which is then matched against a PO and receipted. And, of course, the buyer would get a kickback.
• Approval of unapproved handling costs
  Which were never in the contract, but of which a portion will be kick-backed to the colluding buyer.
• Supplier Payment Diversion
  A smart buyer will open a bank account in a name that sounds like it is the suppliers name, like MJ Consulting if the supplier is M&J Consulting, provide finance with new banking instructions from a spoofed e-mail account, and collect the payments until AP discovers they have incorrect account information.

If you analyze these types of fraud, you see a couple of commonalities:

• Fake Data
• Lack of Control
• Collusion

It’s very easy with modern technology to prevent the first two and make the third harder, in that more people will have to be in on the fraud for it to succeed. Specifically, if you take the following steps:

• Lock down access to finance and admin functionality to only those who need it
  and, using fine-grained roles-based security, restrict admin functionality to only those functions admin rights are truly required by the person
• Require 2^nd party verification of all regulatory and financial data associated with a supplier
  as no one should be able to enter and confirm the same data element
• Only a person performing a function can enter data relating to that function
  as only a warehouse or site worker will know when the goods are/are not delivered
• Also require 2^nd party verification of any data element that can trigger a payment
  So, a goods receipt, as a whole, should be verified by a foreman
• Absolutely no automatic payments unless ( a) the supplier is verified, ( b) the supplier’s accounts are verified, ( c) the goods were verified as received
• Absolutely no payment for an invoice above the minimum threshold for non-automatic payment without a PO
  even if verified supplier, account, and receipt of goods
• Absolutely no payment for an invoice above the threshold for which approval is specified
  without a manager approval, even if there is a PO, verified supplier, account, and receipt of goods
• Absolutely no P2P/e-Procurement systems that don’t encrypt user access information, account information, and approvals. Otherwise, all an enterprising fraudster has to do is either (a) get onto the server and (a) query the database for an admin login, (b) overwrite the account record with his own bank record or, and this is way too easy in some systems, (c) set the approved for payment flag next to the invoice to true. The approval field should be a system encrypted value that only the system can decrypt to a valid “pay on” date using salts, hashes, and ciphers.

This will solve the fake data issue, as there can be no fake data unless there is collusion, and the lack of control issue, as there will be no way around the workflow unless there is collusion. You can’t solve the collusion issue, but you can certainly discourage it. Criminals tend not to trust each other, and when three or more parties are required to pull off a heist, the odds are much more in your favour.