You are on page 1of 13

Chart of accounts

Design considerations

July, 2013

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

liability.e. expenses. 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 can be broken into five basic categories of accounts: asset. a COA contains various accounts. and owner’s equity. by deriving the value using some logic) in every transaction done in an organization. by manually entering.Abstract Abstract A chart of accounts (COA) is a list of codes (called “Accounts”). or indirectly i.e.e. Chart of Accounts Design Considerations 1 ... which is the building block for these reports. i. the ledger. the most important element to be considered for any Enterprise Resource Planning (ERP) implementation. Broadly. which are tagged (directly i. These transactions in turn create the balances in an organization’s book of record. income.

for a finance function. before all these transaction entries happen. also come to the same general ledger. revenue. accounts receivables. which might be a current or a future dimension. The general ledger is a single ledger. Every segment of a COA caters to a business dimension. It is used to organize the finances of the entity and to segregate expenditures. However.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. Chart of Accounts Design Considerations 2 . To give an example. and liabilities in order to give interested parties a better understanding of the financial health of the entity. One of the basic building blocks for doing this is a COA. the payables module captures data of all vendor transactions. the balances from inventory. So apart from the payables. the general ledger has to be structured to capture these balances. and have a single ledger where all these transactions converge to give a single place for all their financial reporting needs. alphabetic. . 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. assets. etc. have different modules to cater the function-specific requirements. This general ledger then becomes the source for the complete financial reporting. which captures data from various modules. The list can be numerical. The structure and headings of accounts should assist in consistent posting of transactions. which contains various segments. and the respective debits and credits are captured and later transferred to the general ledger module. 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. or alphanumeric. purchasing. fixed assets. The hugely popular ERP systems provide solution to this need. These systems are tightly integrated.

The paper does NOT.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. Chart of Accounts Design Considerations 3 . 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. however.

The most basic among them are the “COA Structure” and the “COA Values. 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. say. which will provide insight into every business dimension. which directly reflect the values. which need to be thought through. defining parent values with. · A COA structure should clearly define: · The number of segments · A statement defining need of each segment · Type of values of each segment. but may become relevant in future. alphanumeric. It becomes very important to have the top management of an organization in the COA design discussions.” COA structure A COA majorly captures an organization’s business dimensions. numeric. For example. Chart of Accounts Design Considerations 4 . IT might be a department parent with values 110 and IT-Services and IT-Supplies might be two child values 111 and 112. In addition to this. The levels and hierarchy for a segment plays a vital role in being able to rollup balances at a parent level. there are various aspects. The current business dimensions will give an idea about segments to be incorporated to capture the current business needs. In addition to this. the organization’s vision statement can be taken as a direction to decide on the future applicability of a COA and thus incorporating segments. An organization’s decision to choose an ERP as a system for transaction entry and unified reporting becomes the base of the design consideration for a COA. if department is a segment of COA and is tagged as a cost center segment.. as they are the best people to direct on the organization’s future and its focus areas.Design considerations Design considerations While designing a COA. a trailing ‘zero’ might help in identifying parents just by looking at the value of a segment. the values in this segment shall capture different values of departments which will capture cost from various sources in the organization. i. For example. which may not be relevant right now.e. each segment must be assigned values.

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

the general ledger. a local. · Reporting requirements b. and the third provides legal services? In such a case. etc. This trade-off creates a dilemma and requires thorough analysis in finalizing the COA structure. International Financial Reporting Standards reporting. once created and implemented. It can be just the statutory or external reporting need like reports for global and local statutory compliance. having different COAs for every legal entity will result in complexities during consolidated reporting. 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. 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.Major design considerations Major design considerations Following are the major considerations.e. or it may also require to capture data necessary for internal management reporting like profit-center-wise profitability. Chart of Accounts Design Considerations 6 .. etc. 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. Also. Organizational operations: Does each legal entity perform the same type of operation or one legal entity produces material. Reporting requirements a. business-specific COA might COA design considerations mean fulfilling local statutory requirements · Organizational structure through General Ledger (GL) only. a compact COA might not capture every business need. management. On the other hand. and operational reporting: While defining the COA. utilization. it is a huge effort to change the structure and design of a COA. Generally Accepted Accounting Principles. A COA should be created keeping in mind a longterm vision of your organization. · · · · · · · · 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. A flexible COA with many segments might result in a thick GL and thus more maintenance efforts. which might be helpful while designing a COA structure: 1. cost analysis. b.. using a flexible global COA might mean having unwanted segments for many entities and on the other side. Having a global COA might mean streamlined consolidation and consistency in reporting. etc. it is important to understand what will be the final output that is required from this design. ‘Local’ user productivity. The general ledger then becomes the source of information for most of the financial and statutory reporting needs. i. Statutory. The corresponding debits and credits are recorded in the books of accounts. other provides IT services. On the other hand.

a thick GL is the one that not only caters to the financial reporting needs. 6. Presence of legacy systems and other application modules a. Ease of access and data security a. If legacy system is capturing data at a more detailed level. will the conversion strategy be able to provide data at the detail. In addition.Major design considerations On the other hand. This would require a larger COA. Other application modules: Which all application modules are being implemented? If there is a sub-ledger. If legacy system is capturing data at a summary level. Ease of access: The structure should not be too large to demotivate users to enter values. 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. then it is very important to have your budgeting requirements captured during a COA design. In such cases. 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. b. Reorganization and scalability While defining the COA. Budgeting If ERP will be used as a system to impose budget constraints on the transactions. Data conversion: Every system has its own way of capturing data and generating reports. 3. 8. In addition to this. we need to consider the data conversion efforts also. 4. We should consider the following aspects: i. 7. which can easily be fulfilled by the sub-ledger reporting. then you will not be able to impose budgets on transactions. if you budget your expenses for every practice for a year and practice is not a segment in the COA. 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. you might or might not require a different COA for the consolidation books. which might reduce errors while entering values. it is not wise to blindly go and include multiple segments in COA to aide in flexibility. which is already capturing a specific detail. The same applies to the legacy systems. then based on the COA structure of the various entities. which might not be phased out during an ERP implementation. For instance. Addition of new values or hierarchies shall be easy and convenient. 5. make sure that the structure is flexible enough to be able to incorporate reorganization in your organization. which is required by the ERP? ii. will the conversion strategy be able to provide data at the detail. Long-term IT strategy If the case is that the current implementation considers implementing only the general ledger module. you must ensure that the structure is defined in a way that it is scalable. which is required by the ERP? b. The long-term IT strategy shall be kept in mind and if you can envisage implementation of other subledgers. Consolidation If there is a need for consolidation. but also the management and the operational reporting needs of an organization. you should consider excluding segments that caters to reporting needs. A general thumb rule is that you cannot budget at a level lower than your COA. If reporting needs for the Chart of Accounts Design Considerations 7 .

i. otherwise. centralized controls shall be imposed. 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. we can use the same COA. Chart of Accounts Design Considerations 8 . A communication shall be sent to all the stakeholders after any changes are made in the COA structure/values.. 10. Any addition and/or update to the COA shall be done by a single person. it is important to have proper controls and process to be in place.Major design considerations consolidation book can be met by using an existing COA. Governance Once the COA is created with values defined. This will ensure lesser iterations into the same discussions and thus a faster process of finalizing the structure.e. 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. 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.

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

About the author Deepak Saini Consultant. credit rating. configuration. financial services. gap analysis. 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. insurance. production support. During his five years of experience. Oracle Packaged Technologies. training end users. and solution design capabilities. and BPO industries. and documentation skills. test script generation. he has performed various functional responsibilities around areas like business analysis. application design. a Bachelor’s Degree in Computer Science and exposure to information technology. brokering. domain expertise. . Deloitte Consulting LLP With a Masters in Finance. Deepak brings a good blend of functional knowledge. requirement gathering.

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