What's Wrong with Your Chart of Accounts and the Solutions you Need to Make it Right
When implementing a financial accounting and reporting system at a nonprofit organization, few would disagree that an optimized Chart of Accounts design is critical to success. Being able to produce accurate compliance reports and meaningful management reports is the point of the exercise. Failing to get it right can add substantially to the workload and effectiveness of both the finance department and the organization as a whole.
Given this fact, most organizations give careful consideration to how to segment and code their accounts to address these requirements, but when evaluating different nonprofit accounting software options, the way that chart gets implemented from technical perspective can be drastically different.
Generally speaking, there are two technical approaches to implementing the chart of accounts in accounting software.
- Linear – The segments of the account code are concatenated into a single string of values with a separator (often a hyphen) between each value. For example, an account may look something like this 10-5850-210-3501 where the first value “10” represents a division, “5850” represents the type of expense (natural account classification), “210” may represent a program or department and “3501” might relate to a specific project. The entire 13-character string represents an account in the linear model and often a single description is available.
- Table-Driven – In the table-driven model, the account segments or dimensions are considered independently and only combined at the point of transaction entry. A single, unduplicated list of valid divisions, a separate list of natural account values, etc. are maintained independently from one another. At transaction entry, the appropriate combinations of codes are assigned to transaction lines based on the nature of the transaction.
JMT strongly recommends the table-driven approach to our clients for a number of practical reasons:
- The table-driven method greatly simplifies maintenance of the Chart of Accounts. New values, for example a new project, can be added to one of the segment tables as needed. It is not necessary to build an entire list of 13-character account codes that include that new value in every anticipated combination. Further, when a project is complete or discontinued, it is relatively simple to deactivate a single project code to prevent coding of new transactions to that code. There are other similar advantages.
- The linear method frequently results in chart of accounts bloat. Nonprofit organizations typically slice and dice their data using a number of different dimensions and when you must concatenate the values together to make a code, you end up with potentially dozens of accounts that all refer to the same type of expense in different contexts. In one organization we helped recently, their list of active account codes was over 80 pages when printed and there were 26 active accounts that were all just ambiguously labeled “Telephone Expense”. To the untrained eye that could not decipher the segment values from memory, there was no easy way to know you were using the right code during data entry. Further, reports can be difficult to read for those same untrained eyes. This ambiguity often results in more frequent corrections since finance team members performing data entry don’t always get clear, immediate feedback when they select an improper code.
- A table-driven chart usually makes aggregate and summary reporting easier. While some linear model-based systems have come up with workarounds to this limitation, linear model report writers often rely on report filtering and account “masking” to exclude accounts and values that you don’t want included in your report. For instance, your report writer might allow you to apply filters at each segment position, but the output is all of the detailed activity or balances only at the 13-character level of detail. Summary amounts, such as total personnel expenses for a department or program, often can only be achieved through subtotals of much more detailed information. Most table-driven systems allow you to query and report in a much more intuitive fashion. If you ask the system to show you “total personnel expenses for a department”, you are able to get that data back at that very specific level of detail. The data is automatically summarized at the level of detail requested. It makes reports easier to produce and more readable for those attempting to use it.
While there is no such thing as the perfect system, we have worked with a large variety of systems that employ both models. At JMT, we feel strongly that the table-driven model generally serves the unique and complicated needs of nonprofit financial reporting more effectively and better addresses the needs of organizations as they evolve.