LawsonGuru Blog

Thought-Provoking Commentary for the Lawson Software Community

The P-Card Shuffle


Is there a reasonable Lawson solution for purchasing cards ("p-cards")?

After working through this with my "go-to" procurement consultant, I just don’t think there’s a good way…

You probably know what I’m talking about. If you’re not familiar with p-cards, they’re corporate credit cards that are issued to specific users and/or "loaned out" on an as-needed basis–essentially a discretionary spending account. There is literally no control, and for this reason, p-cards are not a "best practice" recommendation. Also, it’s entirely offline so there’s little actual Lawson-ese involved with the implementation. It all comes down to internal policy and procedures.

Some people will tell you (my procurement consultant included!) that p-cards are a cop-out. You, as a client, go to all the trouble and expense of setting up an ERP purchasing solution, and establishing purchasing "best practices". Then you throw it all asunder by issuing what amounts to a "system override". However, like anything in life, there are exceptions. In particular, you can’t issue a PO for every purchase (travel in particular), and some vendors don’t accept POs– they want a credit card! Those "oh-so-savvy" employees who know how to "work the system" (read: bypass the purchasing department!) buy everything on a p-card, and then…why did you implement those best practices anyway?

However, I digress….here’s my theory in a nutshell on how p-cards should work (obviously not based on Lawson functionality!):

You need to make a purchase from a company that only accepts credit cards (i.e. a website vendor). You enter a requisition which gets approved and then a PO gets issued. You then go to the vendor’s website, and enter your p-card (credit card) number. You might also enter the PO#, if the vendor offers that option. As soon as you enter that "charge" to the p-card, it should credit a liability (i.e. credit card payable) rather than create an invoice. When AP receives the invoice from the credit card company, you debit the credit card payable/liability account and cut a check to the credit card company. Sounds simple, right? Well, not so fast.

There are a couple of issues at purchase time that make this difficult:

  • P-Cards are used both by purchasing "buyers" as well as regular employees, particularly those on travel. The "buyer" POs are for approved requisitions, and the buyer is just using it as a means of payment. The document trail exists — req to PO.
  • However, the "non-buyer" (let’s call them a "traveler") may not even have a requisition. Instead, they have that "discretionary spending account" bestowed to them by virtue of being allowed to use the card. In other words, whoever authorized them to use the card gave them, in reality, a "blanket requisition" to spend up to the limit (if any) on the card.

So, for the sake of argument, let’s assume we can figure out who’s who, and we can treat "traveler" reqs and "buyer" POs correctly.

What about Receiving? You can’t match a PO that doesn’t have a receipt, and you can’t close a PO that isn’t matched. Are you going to enter a receipt for every p-card purchase? Should you?

Now, on to the fun stuff–Invoicing–And, herein lies the rub, as they say: You have two vendors: one for purchasing; one for payment! The matching has to be done for the purchasing vendor, but the invoice comes from the invoice vendor–the credit card company. How the heck do you reconcile and match that? One client I worked with showed me–literally–stacks of credit card invoices and reconciliations back to the purchase receipts.

The "invoice" is the credit card statement, which should be "matched" against the PO. And, of course, there will be the "traveler" credit card purchases without a PO. It does seem like an impossible situation without its own module. How come Lawson hasn’t paid it any attention?

So, that’s where it falls apart. The credit card statement is essentially the invoice, yet it cannot be the invoice. It MUST be an invoice from the PO Vendor in order to match and close the PO. Plus all the distribution coding is contained on the RQ/PO.

The argument is that you need the PO to 1) generate a commitment and 2) to track vendor purchasing (i.e. for small business utilization, etc). Ultimately, the client’s purchasing department cares about who the vendor is–be it Staples, Decision Analytics, etc.–for purchasing volume, small-business utilization/reporting, etc. Purchasing isn’t interested in how the bill gets paid.

The good news is that Lawson v8.03 contains functionality in the XML/e-Reqs self service module to interface with certain vendors to use p-cards And requisitions, and for the first time, system logic and accounting flow that will marry the p-card transaction. However, there are only 3 or 4 vendors that work today (one of them being Dell).

In the meantime, if anyone has any good suggestions, or workarounds, or you think that this would benefit from a 3rd-party solution, send me an email at mailto:letter@lawsonguru.com, and I’ll be happy to report back in a future issue.

Many thanks to Bill Ianni for his help on this article…you can reach Bill at mailto:billianni@yahoo.com.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: