Wednesday, February 28, 2007

Accounts Receivable, One Size Does Not Fit All!

I’ve heard controllers say that Accounts Receivable (A/R) is the “Cash register for the company.” Strictly speaking A/R is the final step in the cash register process with Order-Entry (O/E), Inventory (IN), etc. also in the mix.  A/R is the only part of this equation that can be a generic application.  When you look at the different industry needs for O/E, IN, etc. you’ll find that one design just won’t work.  There are so many variables with quantities, shipping, pricing, etc.  This is not a great revelation of mine.  Software companies have gotten rich selling systems that are an acronym soup.  ERP, CRM, JIT, DDS, and the list goes on. 

We need these systems, expensive as they are, to do our business.  Where we get into trouble is when we try to use the financial packages (G/L, A/P, A/R) that come with these systems.  Some of these applications have less sophistication than Quick Books.  Don’t get me wrong, Quick Books is a fine product for a small business, but don’t try to run General Motors with it.  I know of a sales presentation by a major software house that featured their ERP system.  The only thing consistent in their presentation was the statement that they were the industry leader of Enterprise Resource Planning (ERP) systems and that the company should buy their product based on that fact.  When asked about such minor things as 1099’s in A/P, their response was, “What’s a 1099?” and when asked about “open-reporting” in the G/L they answered with, “Why would you want to do that?” Their ERP system was as lacking as their financial applications, and they were not selected. 

There is another problem.  A great number of these software houses don’t develop all of the applications they sell.  Instead they buy them and then write interfaces to pass needed data back and forth.  This works, sort of, but it’s not seamless, and there is a lack of continuity between the applications.  Sometimes this is a real pain in the you-know-what, maintenance wise.

What’s the solution?  I don’t know if there is just one solution.  If it were up to me (no one in their right mind would leave it up to me) I would take the following approach.  Develop a good, strong, generic A/R.  One that defines complete customer information, the G/L accounting rules, and A/R terms and conditions.  Make interfacing to and from A/R a very simple task.  That way, a company could implement any O/E that meets their specific needs.

Next develop a generic O/E and other associated applications to dovetail to the A/R that could be used in a distribution industry, both retail and wholesale.  I would not attempt to make the mistake of trying to be all things to all people.  Let someone else deal with ERP, CRM, DDS and all of the other TLA’s (three letter acronyms). 

This way the A/R could be used no matter what your company’s needs are.  What say you?