Tuesday, August 28, 2007

Where Is My GPS Now That I’m In A/R?

Software developers have NEVER expended any effort in designing a good Accounts Receivable.  Maybe it’s stupidity on their part, or maybe it’s because they’re just plain lazy.  I don’t know the reason, but I do know their design results are a load of horse pucky!

Examples: 

1. Developers never consider “employee” receivables.  There is no capability of passing of data from Payroll to A/R.  There is no way to identify a customer as an employee.  What you wind up doing is reserving a series customer numbers for employees, and all postings are done by hand from a spreadsheet.  Right?  Some only allow you identify a customer as “active” or “inactive,” and that’s it.

2. “Customer numbers” are another problem.  They’re not an instinctive way to reference a customer.  If you have several hundred or thousands of customers it’s a real challenge to find the customer that you’re dealing with.  A/R needs better methods to access customer records than the limited methods that now exist.  Expanding use of search fields, more effective wildcard searches, filters, and consolidated screens would be a good start.

3. Lastly (at least for this rant), the navigation through the plethora of screens is anything but intuitive!  You almost need a GPS to get around.  The result is that time is lost, mistakes are made, and training takes much longer.  You’ll be doing a lot of training, as terrible software is frustrating and stressful to use.  The result of these faults is high staff turnover!

Of all the applications within a financial system A/R is probably the most poorly designed and the most neglected by developers.  Why is this?  Upper management has no clue as to what is needed by the accounting department, and they are the ones who make the decision as to what system to buy. They are wined and dined by software salesmen and are promised that their problems will be solved.  Yeah, right!  As long as companies keep buying useless software there is no incentive for developers to spend time and money to make things right. 

Saturday, August 25, 2007

Accounts Receivable, Ignored Once Again!

Accounts Receivable (A/R) is the most ignored application by software developers.  It has been superseded by other applications with fancy acronyms.  A/R is still there but pushed to the background.

A/R is the cash register for your company.  EVERYTHING your company sells must pass through A/R.  It is instrumental on how this information is posted to your G/L.  If it weren’t for poorly designed software, A/R could provide you with useful tools to help manage this revenue!

Typically, developers follow the folly of summarizing monthly activity into the arcane design based on “Buckets.” Yes, once again they took the easy way out and eliminated all chances of having meaningful analysis data!  Did anyone ever explain to them that “Buckets” are subject to errors?  Evidently they did, as they all seem to include elaborate methods of reconciling “Bucket” totals once reports don’t cross-foot.

Speaking of reports, those supplied with the system are extremely limited in their ability to provide useful information.  For example, aging reports can’t be modified at run time.  Even worse, Balance-Forward customers can only be reported as to what amounts are current or non-current.

Reporting periods have to be closed before charge and payment amounts for a new period can be posted.  Timing of closing a period, especially at year-end, becomes a CRITICAL!  Your company’s cash position hangs in the balance until your position is current!

There are many more issues to address than what I have mentioned.  It’s the same old story.  Developers are lazy, and their sales staff should be selling used cars or doing Infomercials for cheap jewelry on some shopping network!

In this day of tight money your company’s cash analysis is extremely important.  Can you count on your A/R, or does it leave you hanging in the balance?

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?