Saturday, March 31, 2007

Green Tie and Purple Socks!

Back in the Stone Age, when I was taking a programming class, my instructor handed out a 2-page dialog on how to compute overtime.  It started out, “If an employee comes to work wearing a green tie and purple socks, parts his hair on the right side, and the barometric pressure is 29.05 and rising, and it’s the 3rd Thursday of the 11th month, and . . . . .” This went on for almost 2 full pages.  The last sentence went on, “This employee will receive double time, UNLESS . . . .”

While amusing, this dialog does point out the difficulty in computing an employee’s earnings.  Over the years, with the influence of government mandates, union negotiations, and well meaning but misguided Human Resource Directors, payroll systems have become very convoluted. 

What have the financial software providers done to alleviate the problem?  Nothing!  They let payroll departments do the difficult record keeping and computations by hand.  Of all the general accounting packages, payroll has to be the most difficult system to design.  That’s why most of today’s payroll packages fall short mark.  It takes a lot of effort, talent, and experience to design a payroll system, something most software houses lack!

Example:  How do you handle multiple payroll attachments?  Let’s say Crowdad Dwarski has been less than an ideal father; i.e., he’s a dead-beat dad with a couple of children, a tax lien from the Feds, and another from the State for back taxes.  Which lien takes precedence?  How much goes to each lien holder?  How much is left for Crowdad to live on? 

Another Example:  A union contract that states if an employee shows up for work on time for an entire month (wow, what a concept!) he gets a bonus of $.05 for every hour that he worked to be included on his 1st payroll check in the following month.  Additionally, if he’s not tardy for an entire quarter, he receives an additional $1.00 for each day he worked to be paid in a separate check the first Friday following the end of the quarter.  On top of that, if he makes it through the entire year without being late he receives $100.00 or .005% of his normal annual earnings, which ever is greater to be paid on the first Friday on January of the following year.

Can you believe this?  These are not unusual situations.  They’re everyday challenges for payroll departments.  You just can’t make this stuff up.  It takes the confused mind of a government official or some union lackey to dream up this kind of B%& S^*& !

Name me one payroll application that can solve these problems!

Saturday, March 24, 2007

Stop the Short-Cutter!

I continue to be amazed at the number of Financial Systems out there that are designed with the stupid idea that users NEVER make a mistake.  The software developers assume that users will always post invoices, payments, etc. correctly.  Really I-G-N-O-R-A-N-T !

How can I say this?  Don’t these developers provide recovery procedures or methods to correct mistakes?  Well, yes, but clever users find ways to take shortcuts and circumvent the “safeguards.”

For example: Let’s say someone incorrectly posted an invoice to the wrong general ledger account and then updated the G/L with this incorrect account number.  The standard method to correct the problem would be to go back to the A/P system, void the invoice (creating a negative posting to the G/L for the incorrect account), and re-post the invoice with the correct account.  However, in a crunch, or if just a tad on the lazy side the “short-cutter” will just make changes in the G/L, leaving the A/P alone.  Auditors just love this!

Wouldn’t it be great if the System protected the integrity of the data and would not allow such “corrections?” It would be nice if software developers would provide tools to make corrections easier and be less time consuming for those overworked accounting types.  They stress out so easily.

Agree? 

Friday, March 16, 2007

Keep Your Pants Up!

What really gets to me is when Management doesn’t give a rip about security until it’s too late – what idiots!  The greatest danger is from “within” but Management remains oblivious to this danger.  Usually Management wants everything done NOW, and that applies to bringing new staff members up to speed on the applications they will be using.  That can lead to disaster.  Embezzlement can happen quicker than you ever thought possible!

Case in point:  A new Assistant Controller is hired, and Management says, “Get him trained on the financials this week.  He’s going to be managing the Payables section next week.  Give him whatever access he needs to do the job.” The IT Department explains that “everything” means having the ability to post invoices, payments, and to add and modify the Vendor’s master file which is a security risk.  Management responds, “We don’t care, just do it!” Oh, did I mention that these geniuses gave this individual check signing privileges as well?

The Assistant Controller they hired was a smart one.  Within a week this individual had the A/P system figured out.  He could modify an existing vendor name to his name, post a couple of false invoices, cut a check made out to himself, and change the master record back to the original vendor name.  Of course, he picked a vendor with high activity, so it wasn’t questioned because the A/P system reported these payments under the original vendor name.  Nobody was the wiser until the employee failed to show up for work after taking the company for thousands of dollars!  Management got caught with their collective pants down, and they had no one to blame but themselves.

We need to protect ourselves from incidents such as these!  We can’t do anything about Management. Stupid is, as stupid does.  Ideally, we would separate the duties, so that staff who create the master records (vendors, customers, and employees) aren’t the same people that post checks or payments.

We also need do something about Systems.  Systems need a way of tracking additions, changes, and deletes to all records.  Changes need to record a before and after image.  Additionally, there needs to be a time-stamp and operator ID as part of this record.  Most importantly, there needs to be a means to monitor and report this information, possibly with an alarm mechanism to an IT security person and/or to the Controller.  At least this way it’s faster to discover and easier to prosecute! 

What’s your horror story?

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?

Sunday, February 25, 2007

SEE IT NOW!

This blog started off as an article about the shortcomings of several Payroll systems.  I then had an epiphany; the problem applies to almost every financial package! 

There are times when you need to research an employee’s pay history, a vendor’s invoice, a customer’s payment, or details behind a journal entry in the G/L.  The only way this information can be gathered, in some financial systems, is to run report after report (that’s if your lucky).  You go to all the effort to enter data, and then you can’t get to it.  How many times has management walked in and wanted to know why the A/P clerk hasn’t paid Dwarski Construction, or how much overtime has Ruthie Fredawitz been paid in the last 6 weeks?  Usually management wants that number NOW! 

How much effort do you go through with your current system to trace every action performed on a vendor’s invoice?  Wouldn’t it be nice to see when the invoice was received, posted, paid (and how), or what discounts were taken?  How about a digital image of the invoice and appropriate signatures without running reports or going to 10 different screens?  I have seen systems where this information was on 1 screen, but you needed special magnifying goggles to read it! 

There has got to be a better way.  Give us the ability to research at the screen without having to jump through hoops and definitely not by running reports.

This is a major challenge that must be overcome, and it’s a major rewrite to do it correctly.  The omission of this search capability is inexcusable.  It’s like software developers have never been in a true business office environment.  To be quite frank, a great many of them haven’t.

Agree or disagree?

Wednesday, February 14, 2007

Support? You’ve Got To Be Kidding!

I don’t know about you, but I’m REALLY fed-up with all this outsourcing of software support to in-duh-viduals (sorry Scott Adams), often working in a call-pool located in a foreign country.  They often have no knowledge of the software they are supposedly supporting. 

Incident #1:

I was on the phone the other night trying to resolve a problem with a support person who was reading from a script.  I could barely understand him, and he had no idea what I was talking about.  I didn’t dare try to interject a comment, or it would lead him away from scripted instructions and force him to begin again from the top!  After an unsuccessful hour and a half I was elevated to the second level of support.  At least the second fellow was able to determine that the problem was above his knowledge, and after 15 minutes I was elevated to the next higher level.  I lost count of the times I was “elevated,” but eventually I wound up talking to someone who actually worked at the company, not some foreigner!  He solved the problem in about 5 minutes.

Incident #2:

Here’s another case of ignorant support people.  Recently I bought a new computer.  I had only a dial-up line available for Internet and E-mail at the blazing speed of 26kbs.  It was nearly impossible to download anything.  After 2 weeks the modem would not respond.  I called support and was pleased to find at least they’re here in the U.S.  The support person asked what release of the operating system (OS) I was using.  Their reply was that my OS had problems supporting their proprietary modem, and that I needed to upgrade my OS.  I said, “Fine could you send me the new release on a CD?” Their reply was, “Sorry, we don’t do that anymore you’ll have to down-load it from the Internet.”. . . . Hello? Don’t you get it?

Has anyone else out there had these problems?

Wednesday, January 31, 2007

Changes = Weekends Lost!

How many times have you needed to do a mass change in an application?  Let’s say the Controller comes in and says, “You need to change the department code for the Janitorial Service department, as they now report directly to Maintenance.” Do you tell the Controller that this should have been thought of before building the stupid chart of accounts?  Do you cancel plans for the weekend?  Worse yet, you need to ask the IT staff if they would write the script to make changes in the Database. You don’t want to ask them to do anything because of the never-ending !#@)☹! you’ll have to put up with.  Time for a career change?

There are 2 challenges here.  First, there needs to be a tool that creates a Database script that you can use without getting IT involved and without having to become a DBA yourself.  Second, the entire Database has to be restructured because the department code is a major key in the Database.  As it is now, this job translates into hours and hours of time and effort, and for Heaven’s sake don’t make a mistake!

It’s not just in General Ledger that this happens, it’s in all applications: changing 500 customers from one sales territory to another, giving everyone in a certain department a 5% raise, changing the default liability account on 1000 vendors, and the list goes on.

You would think that if we can put a camera, a calculator, a stereo, an e-mail device, a television, a Jacuzzi, and who knows what else in a small portable phone, they ought to be able to solve this problem.  (Just kidding about the Jacuzzi.)

Thursday, January 25, 2007

To 1099 or Not 1099

One of the questions I ask software salesman during their presentations is, “How does your system handle 1099’s?” You won’t believe the answers you get!  Not surprisingly, there are some that say, “What’s a 1099?” The best response I have heard is, “There is a flag setting in the vendor master record.” When pressed as to the purpose of this flag the response was, “Oh nothing, it’s just there to tell you to do something.” Even if they understand what a 1099 is (and all its variations) most systems don’t address all governmental reporting requirements.  Why is all this important? . . .

If your business is involved with outside contractors, renting, interest on loans, or any of the many different types of payments subject to governmental reporting, you need to be very concerned with how your software deals with 1099’s.  Government’s quest to relieve us of any spare change isn’t going to go away, and enforcement of reporting earnings through the use of 1099’s will only increase.  Failure to comply will bring heavy fines!

What is needed to comply with these regulations is the following:

a. Identify those vendors who are subject to 1099 reporting and record all pertinent data.
b. Identify those vendors who are subject to backup withholding.
c. Allow for multiple 1099 categories per vendor.  This means identify what type of form (1099-M, 1099-I, etc) and which box numbers are to be used to for the reported amounts.
d. Ability to identify by invoice line item the amount is reportable and to which form.
e. Be able to withhold by invoice, maintain a withholding balance and reflect that in the G/L.
f. Don’t use BUCKETS to maintain totals of reportable amounts and withholding.  Always process dynamically.
g. Provide an auditing report that can be run throughout the year to report on any possible 1099 vendors, type of 1099, line item description from invoice, and line item amounts (including withholding).
h. Provide for the ability to combine different companies that have the same tax ID for unified corporate reporting.
i. Provide for electronic filing.

The above items are BARE minimum.  Now that I have provided design requirements do you think the software providers will do anything?  They should, but I doubt it.  There may be some software company that can provide some of these items.  It’s time for more searching.  All we can do is hope.

Thursday, January 18, 2007

Narrow-Minded Versus Open-Reporting

For background read: “Can the Buckets!”, category Systems.

I can’t believe some of the narrow-minded providers of accounting software who don’t see the importance of a system that can be used as a REAL MANAGEMENT TOOL.  When you push them for more reporting power they are likely to come back with, “Did you know we’re an eight billion dollar a year company?” All that tells me is that there are a lot of pigeons out there that will buy a product based on the name only.  Talk to any CEO, manager, or supervisor on how their current General Ledger helps them manage, and they’ll give you the true story.  Let me explain . . .

Once we do away with the “buckets” concept and write systems using an active open database, the General Ledger becomes more than a reporting tool for the Auditors.  It becomes a Business Management Tool.  Modern database engines, along with proper database design can provide needed performance, processing hundreds of thousands of transactions in mere seconds.  You would then have a system that could support multiple time frames or calendars.  These calendars could be for a 4 month period of time or an 18 month period.  It doesn’t matter, it’s whatever your needs are, you are in control.  What a concept! 

You’ve got everything you need for project management; i.e., payables, receivables and payroll data.  Of course, this assumes that you have good interfaces coming from these systems.  Too bad some of the major software providers didn’t write all the packages that they’re selling, but buying is cheaper than developing.  A complete financial system should be a seamless integration of data and function, but I digress.

Another tool that goes along with open reporting capabilities is the use of statistical information.  Such things as payroll hours, number of items produced, quantities sold, all become an important part of producing a picture of real performance when measured against the dollar. 

Without open reporting and statistical data you don’t have a real Financial Manager.  The big guys will try to sell you on allocation journals and customer reports, etc.  Those aren’t features those are requirements.  Ask them about open reporting and statistics.  It’s fun to hear them stutter and listen to the yammering about, “Why would you ever need those things.” Get a grip!

Am I wrong?  I don’t think so.

Wednesday, January 10, 2007

Can the Buckets!

Certain big providers of today’s financial software continue to wrap a GUI interface around old ideas. Of course they think it’s a great product; you can tell that by the prices they’re charging! They should be ashamed! Let me explain…

One concept is a file architecture that summarizes transactions into what are called “buckets”. Their General Ledger uses period buckets, usually 12 monthly periods. Payroll uses year-to-date and in some cases quarter-to-date, while Accounts Receivable and Accounts Payable are usually only year-to-date. This concept makes any required reporting much easier for programming staff and reduces the number of transactions necessary to provide desired reports. Essentially, the boss is happy because bank auditors have their reports. However, these reports don’t provide meaningful detail information to aid in managing the company.

That was fine for the Stone Age, but not now.

Why is it a mistake to keep using systems based on this archaic method? There are a number of reasons, read on.

Occasionally “buckets” get out of sync when detail transactions don’t equal the summarized bucket total. This doesn’t happen often, but it does happen. If it isn’t a problem why do these financial systems have manually run “reconciliation programs” to re-sync the buckets? You bet it’s a problem and one that is not easy to detect. The software provider will tell you that it almost never happens, but they won’t be standing next to you when the president of the firm calls you on the carpet when his bank report shows an incorrect balance!

Everything has to be posted and balanced (as at year-end) before proceeding with the new period. This can delay reporting on the new period’s information for some time, depending upon the efficiency of the accounting department. This, in some cases, is not just a year-end problem but can occur throughout the accounting-year, reporting-period by reporting-period.

Because of this antiquated design, prior period detail information is usually LOST after a period close, especially at year-end closings. You’ll have summary data available as a prior-year history (again in buckets), but only for the immediate previous year.

This rigid accounting calendar, caused by this bucket concept, locks your company into the financial system’s way of reporting information, as opposed to adapting to your company’s business cycle needs. What if your fiscal year is July through June, but your business cycle is February through October (farming, construction, tourism, etc.)? Wouldn’t it be better to report your business cycle information at whatever frequency and level of detail you need?

What’s the solution? Can the BUCKETS!

Today, with the software tools and hardware capabilities now available, there is no excuse for “buckets.” Work with the RAW DATA! Let software perform data collections that are needed for whatever task is at hand. Develop software that allows the end-user to manipulate data in a form that they can work with. What a concept!

Remember, truth lies in the RAW DATA. We need systems that work directly with the detail transactions that are posted to the system.

It’s time that software developers pull their heads out of the sand and offer software that will provide the tools that we need! We’ve waited long enough! Why isn’t there something better?