Chart of accounts

Design considerations

July, 2013

A COA is the basic and the most important building block for any ERP implementation. There are a lot of factors, which must be thought through during the design of a COA. This document talks of these design considerations and aims to enable an organizations management and ERP core team to construct a COA structure, which is both optimal and meets all their business needs.

Chart of Accounts - Design Considerations

Abstract

Abstract
A chart of accounts (COA) is a list of codes (called Accounts), which are tagged (directly i.e., by manually entering, or indirectly i.e., by deriving the value using some logic) in every transaction done in an organization. These transactions in turn create the balances in an organizations book of record, i.e., the ledger. Broadly, a COA contains various accounts, which can be broken into five basic categories of accounts: asset, liability, income, expenses, and owners equity. These categories are further grouped together to derive the balance sheet and the profit and loss statement the two most important financial reports for any organization. This makes the COA, which is the building block for these reports, the most important element to be considered for any Enterprise Resource Planning (ERP) implementation.

Chart of Accounts Design Considerations

Introduction

Introduction
Today, most of the organizations are moving toward integrated systems and a global view for all the data that is being entered in disparate systems. The hugely popular ERP systems provide solution to this need. These systems are tightly integrated, have different modules to cater the function-specific requirements, and have a single ledger where all these transactions converge to give a single place for all their financial reporting needs. To give an example, for a finance function, the payables module captures data of all vendor transactions, and the respective debits and credits are captured and later transferred to the general ledger module. The general ledger is a single ledger, which captures data from various modules. So apart from the payables, the balances from inventory, purchasing, accounts receivables, fixed assets, etc. also come to the same general ledger. This general ledger then becomes the source for the complete financial reporting.

Wikipedia A COA is a created list of the accounts used by a business entity to define each class of items for which money or the equivalent is spent or received. It is used to organize the finances of the entity and to segregate expenditures, revenue, assets, and liabilities in order to give interested parties a better understanding of the financial health of the entity. The list can be numerical, alphabetic, or alphanumeric. The structure and headings of accounts should assist in consistent posting of transactions.

Merriam Webster A list of account names arranged systematically and usually coded numerically or alphabetically or both to form the general framework of the accounting system of a specific business and to establish a scheme of account classification.

However, before all these transaction entries happen, the general ledger has to be structured to capture these balances. One of the basic building blocks for doing this is a COA, which contains various segments. Every segment of a COA caters to a business dimension, which might be a current or a future dimension. .

Chart of Accounts Design Considerations

Problem statement

Problem statement
The objective for this paper is defined in the below statement:

Define a COA and discuss various aspects of its design to be able to have an optimal and efficient COA structure, which caters to the business needs
The objective of this paper is to ponder over different design considerations to capture the business dimensions in a chart of accounts and to arrive as the most optimal and efficient chart of account structure. The paper does NOT, however, suggest any segment or value for a chart of account and only talks about the design considerations which might help in arriving at a desired COA.

Chart of Accounts Design Considerations

Design considerations

Design considerations
While designing a COA, there are various aspects, which need to be thought through. The most basic among them are the COA Structure and the COA Values.

COA structure
A COA majorly captures an organizations business dimensions. An organizations decision to choose an ERP as a system for transaction entry and unified reporting becomes the base of the design consideration for a COA. The current business dimensions will give an idea about segments to be incorporated to capture the current business needs. In addition to this, the organizations vision statement can be taken as a direction to decide on the future applicability of a COA and thus incorporating segments, which may not be relevant right now, but may become relevant in future. It becomes very important to have the top management of an organization in the COA design discussions, as they are the best people to direct on the organizations future and its focus areas. A COA structure should clearly define: The number of segments A statement defining need of each segment Type of values of each segment; i.e., alphanumeric, numeric, or alphabetic Length of each segment Ordering of segments Hierarchies within the segment (levels and parent-child hierarchies)

COA values
Once the COA structure is finalized, each segment must be assigned values, which directly reflect the values, which will provide insight into every business dimension. For example, if department is a segment of COA and is tagged as a cost center segment, the values in this segment shall capture different values of departments which will capture cost from various sources in the organization. The levels and hierarchy for a segment plays a vital role in being able to rollup balances at a parent level. In addition to this, defining parent values with, say, a trailing zero might help in identifying parents just by looking at the value of a segment. For example, IT might be a department parent with values 110 and IT-Services and IT-Supplies might be two child values 111 and 112.
Chart of Accounts Design Considerations 4

Design considerations

Similarly, if a zone-wise profitability is needed to be captured, you might consider having profit centers assigned these zones as their parents. The number of levels decides how many levels of rollups you require. It is important to understand that a COA does not just replicate your current business dimensions. It also requires a consideration of the future needs of the business. This principle applies not just to the structure of a COA, but also while creating hierarchies and adding every individual value in a segment.

Chart of Accounts Design Considerations

Major design considerations

Major design considerations

Following are the major considerations, which might be helpful while designing a COA structure:

1. Organizational structure
a. Local versus global: Does the organization have operations in a single country or in multiple countries? How many legal entities are there? Are there any transactions between different legal entities? Is there a requirement for a consolidated reporting? Is there a need to have a different COA for every entity or a does the business needs single global COA? Answers to these questions will help in deciding if we require a single COA or multiple COAs. Having a global COA might mean streamlined consolidation and consistency in reporting. On the other hand, a local, business-specific COA might COA design considerations mean fulfilling local statutory requirements Organizational structure through General Ledger (GL) only, Local user productivity, etc. Reporting requirements b. Organizational operations: Does each legal entity perform the same type of operation or one legal entity produces material, other provides IT services, and the third provides legal services? In such a case, using a flexible global COA might mean having unwanted segments for many entities and on the other side, having different COAs for every legal entity will result in complexities during consolidated reporting. This trade-off creates a dilemma and requires thorough analysis in finalizing the COA structure.
Ease of access and data security Presence of legacy systems and other application modules Long-term IT strategy Reorganization and scalability Budgeting Consolidation Governance Documentation

2. Reporting requirements
a. Statutory, management, and operational reporting: While defining the COA, it is important to understand what will be the final output that is required from this design. It can be just the statutory or external reporting need like reports for global and local statutory compliance, Generally Accepted Accounting Principles, International Financial Reporting Standards reporting, etc., or it may also require to capture data necessary for internal management reporting like profit-center-wise profitability, cost analysis, utilization, etc. b. Thin versus thick GL: A thin GL is the one that caters only to financial reporting needs of an organization and thus is used only to capture the data needed for this purpose only.

A COA should be created keeping in mind a longterm vision of your organization. Also, once created and implemented, it is a huge effort to change the structure and design of a COA.

Every accounting transaction that is entered in an ERP system uses different values of the COA segments to capture various business dimensions for that transaction. The corresponding debits and credits are recorded in the books of accounts; i.e., the general ledger. The general ledger then becomes the source of information for most of the financial and statutory reporting needs.

A flexible COA with many segments might result in a thick GL and thus more maintenance efforts. On the other hand, a compact COA might not capture every business need.

Chart of Accounts Design Considerations

Major design considerations

On the other hand, a thick GL is the one that not only caters to the financial reporting needs, but also the management and the operational reporting needs of an organization. This would require a larger COA.

3. Ease of access and data security

a. Ease of access: The structure should not be too large to demotivate users to enter values. In addition to this, the values shall be coded in a way that user can identify the meaning of the value just by looking at the coded value or at least infer information, which might reduce errors while entering values. b. Data security: The values for various COA segments shall be defined in such a way that it becomes possible to impose access to certain financial reports and/or balances.

4. Presence of legacy systems and other application modules

a. Data conversion: Every system has its own way of capturing data and generating reports. The same applies to the legacy systems, which might not be phased out during an ERP implementation. In such cases, we need to consider the data conversion efforts also. We should consider the following aspects: i. If legacy system is capturing data at a summary level, will the conversion strategy be able to provide data at the detail, which is required by the ERP? ii. If legacy system is capturing data at a more detailed level, will the conversion strategy be able to provide data at the detail, which is required by the ERP? b. Other application modules: Which all application modules are being implemented? If there is a sub-ledger, which is already capturing a specific detail, we might not require a separate COA segment to capture the same information and thus will refrain from increasing a segment in COA and increase in data redundancy.

5. Long-term IT strategy
If the case is that the current implementation considers implementing only the general ledger module, it is not wise to blindly go and include multiple segments in COA to aide in flexibility. The long-term IT strategy shall be kept in mind and if you can envisage implementation of other subledgers, you should consider excluding segments that caters to reporting needs, which can easily be fulfilled by the sub-ledger reporting.

6. Reorganization and scalability

While defining the COA, make sure that the structure is flexible enough to be able to incorporate reorganization in your organization. In addition, you must ensure that the structure is defined in a way that it is scalable. Addition of new values or hierarchies shall be easy and convenient.

7. Budgeting
If ERP will be used as a system to impose budget constraints on the transactions, then it is very important to have your budgeting requirements captured during a COA design. For instance, if you budget your expenses for every practice for a year and practice is not a segment in the COA, then you will not be able to impose budgets on transactions. A general thumb rule is that you cannot budget at a level lower than your COA.

8. Consolidation
If there is a need for consolidation, then based on the COA structure of the various entities, you might or might not require a different COA for the consolidation books. If reporting needs for the
Chart of Accounts Design Considerations 7

Major design considerations

consolidation book can be met by using an existing COA, we can use the same COA; otherwise, we might need to create a new COA for the consolidation book and do a mapping between two COAs to derive accounting for the consolidation books and bringing balances there.

9. Governance
Once the COA is created with values defined, it is important to have proper controls and process to be in place. Any addition and/or update to the COA shall be done by a single person; i.e., centralized controls shall be imposed. Any request for adding/modifying COA values shall be routed through appropriate approval authorities and processes with the COA controller being the last person who will add the COA value and complete the process. A communication shall be sent to all the stakeholders after any changes are made in the COA structure/values.

10. Documentation
A documentation to capture each design consideration should be maintained and made readily available to various stakeholders old or new to enable them to understand what has been discussed and what the basis for the currently proposed COA structure is. This will ensure lesser iterations into the same discussions and thus a faster process of finalizing the structure.

Chart of Accounts Design Considerations

Conclusion

Conclusion
A COA structure is the most important design element of an ERP implementation. Once designed and implemented, a change in COA structure might be equivalent to a complete reimplementation of the ERP application. The capturing of data, financial and management reporting needs, and consolidation requires right COA design to be in place to get full value out of an ERP implementation. In cases of reimplementation or data migration from legacy systems, the COA design shall also consider the detail at which the data will be made available from the feeder systems. With so many trade-offs on various design considerations and dilemmas associated with finalizing the complete design of a COA structure, a comprehensively designed COA is a key for long-term stability of an ERP Implementation.

Chart of Accounts Design Considerations

About the author

Deepak Saini
Consultant, Oracle Packaged Technologies, Deloitte Consulting LLP With a Masters in Finance, a Bachelors Degree in Computer Science and exposure to information technology, financial services, insurance, brokering, credit rating, and BPO industries, Deepak brings a good blend of functional knowledge, domain expertise, and solution design capabilities. During his five years of experience, he has performed various functional responsibilities around areas like business analysis, requirement gathering, gap analysis, application design, configuration, test script generation, training end users, production support, and documentation skills. Deepak has been involved with various client ERP teams for finalizing COA designs for their organizations and has enabled clients from different industries to implement an optimal COA structure.

About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see www.deloitte.com/us/about for a d etailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting. Copyright 2013 Deloitte Development LLC. All rights reserved. Member of Deloitte Touche Tohmatsu Limited