The typical small business uses a software accounting program like QUICKBOOKS to perform its accounting functions but if there ever was an example of “garbage in, garbage out”, it is small business’ use of this type of software. How many financial statements are false or misleading because of incorrect coding? How many IRS audits are both created and then made much harder by improper use of software? How many other mistakes cost businesses incalculable losses? It all sounds so simple when you first install the program and then it all goes astray.
A chart of accounts is nothing more, on paper, than a list of all of the various types of codes that can be assigned to a company’s financial transactions relating to income, assets, debts, and other various issues.
A typical example of coding income might be listing of income received for rent, interest, sales, services, etc. Within each code, a business likely will have sub-codes assigned such as which property the rent was received from (if there is more than one property), interest from each account (such as accounts by account number or by different banks), and sales (possibly by store location, type of good sold, etc.). One might also code debts (rent, lease payments on equipment, etc.) in different ways as well.
Other types of coding might be to show current fair market values of assets such a buildings, vehicles, and equipment as opposed to the depreciated values for those assets or those which have been written off or written down to zero.
The goal of coding any type of financial information is to make it more usable to the reader so the person doing the coding must have a very clear idea of what types of reports will be generated and what those readers are truly looking for.
Let’s take a small company that sells baked goods. They might set up their coding far different than a construction company.
Under assets they might have a general category coded 1000 for sales, but they have sub-categories for cash sales, credit card sales, debit cards. They might also have codes for rolls, danishes, cookies, macaroons, etc.
For their liability coding, they might have a larger code such as 2000 for “ingredients” then sub-codes for flour, vanilla, coloring, etc. They might even code in how much they actually bought of an ingredient---such as 200 pounds---and what their per pound price was.
Anything that helps give the end user the best picture of the company is what should be done, but how does one do that? To truly prevent “garbage in, garbage out”, one must start at the beginning of the process.
The end users need to take the lead to get what they want
The data can be entered accurately into every category, but when the reader sees the report and exclaims “but what does this mean?”, you know you have a problem.
Too many small businesses are so content to just have the data entered accurately that they forget how the data is eventually going to be used and end up spending a lot of time trying to understand the numbers when good coding may have made the reports understandable from the beginning. The biggest problem with new businesses is they may not have a clue what each category that might use will be and even less of an idea as to the sub-categories; but this is a problem which can be solved.
Small businesses need to have the data entry person talk with the ultimate recipients of the reports to find out how they are going to use the reports. The more cooperation that these persons have, the better. In fact, the person(s) to receive reports should take the lead here and give the main categories and their sub-categories by name to the data entry person(s).
Coding is not exactly a state secret and the ultimate recipients are in the best position to assign codes. Perhaps a competitor will share their codes or an employee will have worked for a competitor. Another good idea is to consult your bookkeeper or CPA and see if they have a set of codes that they might want the software to spit out tabulations in when you send the software files to them at the end of the quarter, year, or whatever period of time you want them to perform functions upon. One major upside to talking to your bookkeeper or CPA is that they can insure that your coding is consistent with the Financial Accounting Standards Board (FASB) and generally accepted accounting principles (GAAP). The IRS likes this too.
You can also search online for various codings at accounting and industry websites, but the ultimate goal is to create a tree for each major category such as income, debts, and assets with branches of the tree underneath each major category for the sub-categories. It is quite common to then have sub-sub-categories as well.
Too many businesses lack the integration between the data entry person(s) and the end user(s) to create reports that are useful to the readers. The more that can be done before any data entry is performed, the better.
A real-world example may be insightful here. A company was designing software for football teams to use to analyze opponents’ tendencies on offense and defense. During a demonstration of the software, one of the football coaches who was being asked to spend an ungodly amount of money on the new software asked, “so what players were on the field on either the offense or defense for each play analyzed?” The demonstrator said they didn’t keep track of that information. No sale. Do not pass go. Do not collect $200,000.
The people who will ultimately use the reports and make decisions based on what is contained in the reports have to take the lead in giving direction to the data entry people as to the categories and sub-categories. There is no other way.
Once the categories are set, keep using them year after year. If you need to make new sub-categories based on new types of information that is one thing, but do not start using a new code and then input the same information type as the year before from another code. Doing so renders year-to-year comparisons a nullity.
Sometimes when small companies either take over other companies or are taken over by other companies, the coding do not change and you end up with different reports for each company not using the same criteria. This is a huge mistake. They need to change to be the same for all parts of a company. You cannot have one part of a company looking at a report using certain codes and then have another part of the company looking at different reports using different codes on the same data types. Possibly the smaller company’s coding system is the better system but, when there is a merger, there has to be a consensus of which coding will be used going forward.
Lastly, there can be certain categories of coding which result in very small amounts being attributed to them. Over time, if you notice that certain accounts generate almost no activity or the dollar amounts are small, then feel free to eliminate these codes and re-code these small amounts elsewhere going forward.
If the end users are actively involved in the coding process before the first piece of data is ever entered in the software program, then the readers of reports will never suffer from a “garbage in, garbage out” problem.
What emerges in the reports might be pure garbage but at least the readers will know it is garbage and know what the garbage means.