This post doesn't have anything to do with Dynamics GP specifically, but more about business processes, internal controls or lack thereof and a fun "Twitter Moment" earlier today.

Late last week, Steve Endow, fellow Microsoft MVP, independent technical consultant, and ISV posted a tweet, and it's not the first time I've seen something like this from him. It says "Another Dynamics GP partner paid me by credit card, and then sent me a check 2 weeks later. Methinks this is a common AP control / process / communication issue. Unfortunately, I don't think software can easily fix this."

Former MVP Ian Grieve had responded to the original tweet, which was to say "Yeah, this is a process problem, not a software one". Fast forward a week, and Steve posted a follow up thought on this, which triggered a fun twitter-storm conversation amongst a few of us. Sidebar: it's honestly one of the things I love about Twitter… conversations out of nowhere when we're all randomly online at the same time.

Today's tweet was "Could a PowerApp help here? Allow an employee to formally submit CC payments to the AP department? App lets user upload invoice to SharePoint, sends notification to AP, and maybe insert CC charge in GP via eConnect?". He went on to tag a few of us to ignite a conversation and sure enough, we all jumped in! It's a legitimate question. I admire Steve for many things, one of which is looking at what people are talking about in forums (issues they are having) or things that happen to him and seeing what problems he can solve with technology.

The situation

All of us that Steve tagged jumped in on the conversation. Interestingly enough, we all had different angles on our approach to the conversation, but we all agreed, paraphrasing, that software does little to help fix process problems or lack of internal controls.

The basic premise to the situation and a recurring thing Steve has run into: someone pays his invoice by credit card but somehow the invoice also makes it into the A/P department, who then cuts a cheque for the invoice and Steve gets paid twice.

It boggles my mind that this can even happen! I can see it happening once, by mistake, but Steve has had this happen to him numerous times. In further tweets in our thread, he mentions "… partners regularly have consultants buy ISV licenses via CC. Those employees are not in AP dept, are not GP users, and they are either not communicating with AP, or AP is not handling those comms properly".

Could software assist? Maybe, but in my opinion, ultimately it comes back to process and internal controls. Where could software assist, from Steve's point of view? Potentially I could have an app where the person paying by credit card could then record it and it gets pushed either a communications to the A/P department or even auto-entering a credit card payment.

My take on it

I see this as a clear sign of lack of either process/procedures around credit card payments and/or lack of internal controls around the handling of invoices that could be paid by credit card. When I hear these stories, the accountant side of me goes a little nuts, thinking of all the ways this could be avoided. No process is perfect, and things will slip through the cracks, however, some basic controls and procedures would go a long way in mitigating this kind of risk.

Have clear procedures around credit card use

I worked for Dynamics GP partners in the past, and there was no way we were allowed to pay for an ISV product via credit card ourselves. Software purchases for customers had to be billed and paid for up front so there were clear processes in both big firms I worked for in the past. Both were accounting firms as well, so that likely contributed to having stronger-than-average internal controls I would imagine. It didn't matter how anxious we were about getting going with a project, there were procedures.

If other partners are allowing consultants to pay by credit card in order to get registration keys faster, it's time to look at the controls. As I said in one of the tweets today, any GP partner that has duplicate payment problems like this better darn well not be having "process" discussions on the right and wrong way to do things, with me (as a client) as part of an implementation project! Pot calling the kettle black anyone?

Procedures here should spell out things like:

  1. Who is allowed to have a corporate credit card and what are appropriate uses for that? (I'm making a big assumption that this could be a corporate credit card issue and I'm quite sure it's probably not).
  2. Corporate credit cards should be limited to specific types of purchases, in most cases: travel & expenses, subscription or recurring charges for things where frequent invoicing and payments of small amounts may not make sense, point-of-sale purchases if applicable and warranted, etc. Whatever the list is, it should be clear, and if exceptions are made, it should be made clear how to handle the invoice and notifying A/P that payment was already made.
  3. If it's personal credit card use and expensing of things, what are the policies around that? Here is where in most organizations there should be very few things allowed to be purchased via a personal credit card. Travel costs perhaps if users don't have a corporate credit card, but realistically, if users are allowed to pay other things on their personal card, it should be approved ahead of time by some clearly defined process (requisition or otherwise).
  4. It should also clearly noted on the backup or approval of the paperwork that the payment would be made electronically, so there is a trail.

Identify vendors paid by credit card and segregate them

If there are certain vendors paid by credit card, ALL purchases for that vendor should be made by credit card, no hybrid payment options. It's very difficult to track which invoices may have been made by credit card and which are supposed to be paid by cheque or EFT etc. if there is a mix. I would flag these vendors in a different category like Vendor Class in Dynamics GP that is excluded from "Build Batch" payment runs. Any invoices entered for these vendors should be not auto-paid by other means until proven that they aren't in fact already paid.

Reconcile key accounts!

In the situation Steve describes above, this may not help, depending on the exact situation. If a consultant paid him for software to get keys earlier, they may have expensed the cost back to their employer, which then flows through a different "vendor ID" than Steve's invoice, so reconciling doesn't really address the issue.

However, if the payment is from a corporate credit card, part of the process should be reviewing or auditing statements to see if a vendor on a statement is recognizable as a vendor paid via cheque. Ideally users can use things like Dynamics GP's credit card features to enter invoices under the "real" vendor and still record them as paid by credit card. In this case at some point users would see a credit card payment to Steve + an invoice and a cheque to Steve, resulting in a credit balance. Watch for credit balances that don't make sense. Follow up on them.

Ensure all credit card payments are recorded

If it's credit card payments initiated by the Finance department themselves, all payments made in a given day should be recorded and there could be posting reports to compare what was posted as credit card payments vs. what payments were actually made to confirm entries.

Final thoughts

These are really just the few thoughts off the top of my head based on our conversations today. Often there are policies in place but they aren't actively enforced, which makes them worthless. Someone should be monitoring, even if it's random spot checks, that processes are being followed and addressing concerns when they are not.

How would I even know if a vendor was paid twice if one payment was made via expense report and the other goes to a vendor account? Do I check my employees' expense reports for known vendors from time to time to make sure there are no duplicate invoices/payments? What are my review processes to catch, if not prevent, these situations from happening?

All in all, it was a great discussion and often we (as consultants) spend so much time talking about the software, that basic controls in processes are missed or ignored altogether.