When we moved to a new system at a previous company, I was tempted to move the account codes intact from the old company. They were developed over the better part of a decade and were stable.

The vendor strongly recommended against that approach. I brought in a consultant who helped identify core weaknesses in process that were driven by the account code itself. Example: when building the cash flow statement, there is a natural flow if there are account codes specific to acquisition and disposal for each fixed asset grouping. If reporting is done in Excel, it may not seem like such a big deal but we wanted to force all normal reporting to come from the system and use Excel only for subsidiary analytics.

At any rate, we ultimately put together a much longer account code structure and then added a zero to the end of each code, to ensure we had space for future unknowns. We went from a four digit code (plus department) to a six digit code (plus department).

To some extent, the account code architecture drives parts of your process. Understanding that aspect may prove quite useful in your new system.

The simple concept it to identify your total number range and use the entire range. You will find that as you include a lot of space between similar accounts that your system has room for growth.

I agree with both Robert and Patrick, but I caution you that when there are excess unused gl codes, there is a greater chance of people requesting a bunch of accounts that may make sense today, but will be future issues. The result of too many accounts is increased reconciliation to correct mis-postings. I recommend you project what type of growth you expect in the next 10 years and try to plan accordingly.

I am not working at my 4th high growth company and can offer some suggestions.

1. First off, even though you report in Excel, try to break that habit. I know it is tempting to export, but then the temptation to correct is always there. If you set up the discipline to use the accounting system, then you will setup it properly (or vice versa). Take the time to make the GL, the reports and the process meet the goals of reporting from the accounting system, it is good for the long term.

2. Second, changing the GL is always incremental. You can plan for growth, but what that really means is to anticipate the coding structure needed for future operations. What you need then is flexibility and adaptability. Look at your goals and make sure the underlying structure supports it (Divisions, Sub accounts, etc). This may require you throw out the old one and may not.

Would be glad to help more, but the VP, Finance comes back from vacation today. If anyone needs advice, I have been down this road many times,; just email me.

Don

I agree with Regis re: excess unused accounts. Another way to look at it to determine if g/l account proliferation adds value when analyzing results or does it end up getting grouped into a broader category for reporting.

GL Software vendors need to "normalize" their database structures in relation (no pun intended) to the gl account code record. Typical gl structures use the gl code for two purposes - as a unique identifier of the record, and as a sort parameter (herein lies the problem). Dr. Codd, rest his soul, would be aghast. If software vendors would add an additional field, a sort parameter for ordering gl codes for reporting, etc., the gl code could do its job - to be the unique identifier of that record, and the sort parameter would shoulder the burden of ordering the gl codes for reporting purposes. In this strange world, when you added a gl code, you would grab the next number available, without regard to the number sequence, because it wouldn't matter (it is a key field). Its only job is to uniquely identify the record. You would then use the sort parameter to position the code in reports. Everybody is doing their job, their job only, and very well, at that. Maximal flexibility for growth and change has been achieved!

This is the word, so help you Codd.