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?