Chart of Accounts

Featured Image - Chart of Accounts
Table of Contents


Chart of Accounts (CoA) represents the ‘Accounting Structure’ of an enterprise to assign specific attributes (Segments) to all financial transactions which are helpful to correctly classify, record, and eventually analyse the finance transactional data meaningfully for proactive identification of issues, initiate actions and facilitate right projections. CoA being one of the most critical foundational pillars of the overall ‘Enterprise Structures’, in a way looks like ‘Corporate Astrology’ being one of the important drivers of the overall ‘fortunes’ of any enterprise! CoA is geo, industry, enterprise size and application agnostic spanning across all transaction types and in many cases one of the important ‘Transformation Driver’ across varied engagement types – Implementation (Green Field or Re), Upgrades, Rollouts etc.

Basics and Drivers

In general, at a minimum any financial transaction ideally should identify segmented 3Ws:

Primary drivers determining the CoA Structure are:

  • Industry
  • Accounting Standards
  • Government Regulations
  • Data Analysis

Additional Segments

Extending the minimum requirements, ‘Enterprise Applications’ either mandate or provide a flexibility to have specific Segments as a part of CoA – some examples are:

  • ‘Balancing Segment’ (BSV) – A segment by which the journal entries for the transactions are balanced, and trial balance is generated – Different BSVs in debit and credit are used to identify ‘Intra/Inter-Company’ entries. Hence, BSV becomes mandatory in CoAs of most enterprise applications though this may be named/titled differently.
  • ‘Cost Center’ – Mechanism to identify “Where” of the transaction to relate to a ‘Cost Center’ (Department) – (E.g. Employee Cost of Manufacturing Plant, Quality, Finance, HR, Procurement functions) – Optional Segment.
  • Geo/Product/Service Category – To identify transactions with specific geos or product/service category to help in ‘Segment’ analysis which is a requirement for listed companies across various countries. – Optional Segment.
  • Inter Company – To identify the ‘Trading Partner’ involved in an intra/inter company transaction. Helpful to list, track and eliminate “Inter Company” transactions from external reporting – mandatory if entity transacts within ‘Group’ entities.


While Enterprise Applications provide wide choices to have additional CoA segments in addition to minimum requirements, this will have to be judiciously selected and used considering frequency, ease of identification during transactional entry and need for improved data quality/analysis. E.g. A specific segment value derived using complicated transactional assignment rules instead of direct assignment during transactional entry is indicative of non-suitability for inclusion as a specific CoA Segment!


Much like physical building blocks, CoAs must last long (at least for a reasonable period – 10 Years!). Hence, design of CoA must be futuristic to accommodate changes in businesses/structures/growth over time. Also, CoA must indirectly help users to quickly familiarise and be conversant to select and assign the right account heads to transactions almost with zero errors! 

Some suggested guidelines are:

  • Segment Size – Make sure to accommodate future growth – E.g. Balancing Segments – Presently 2 – Good to consider a segment size of 3 considering future growth as this provides an opportunity to consider up to 999 values from the present level of 99. Too big may be clumsy and too small will run out of limits too soon!
  • Allocate Separate Value Range for distinct account types/subtypes – i.e. Assets, Liabilities, Income, Expenses, Capital/Equity related etc. – Illustratively, if natural account segment has a size of 5 – may be good idea to assign 00001 to 09999 (Income) – 10000 to 29999 (Expenses) – 30000 to 39999 (Assets) – 40000 – 49999 (Liabilities) 50000 – 59999 (Capital/Equity). Also, ensure to design sub-range – E.g. within fixed assets – for land, buildings, plant and machinery etc.
  • Design ‘Parent’ Account Values – Preferably in ‘Alphabets’ – to roll-up account balances of children in the manner required for statutory / internal reporting. Most enterprise applications provide avenues to build multiple account hierarchies for use for different needs.
  • Use ‘Leading Zeros’ and ‘Capitals Only’ to provide a standardised segment length visible to the user and also enforcing a discipline to enter segment values in capitals instead of inadvertent use of mixed case/small case/initial capital.
  • Use standardised pattern in ‘Description of Account Heads’ – All account heads for contribution to various employee benefit schemes must uniformly start with ‘contribution – xxxxx’ (E.g. ‘contribution – Pension Fund’, ‘Contribution – Health Insurance’, ‘Contribution – Accident Insurance’) – The advantage is when searching based on description just entering ‘contribution%’ will retrieve all heads of similar nature which will not be feasible if non-standard account descriptions are used.
  • Use Rhyming and Miming – Segment values for most often used account heads should facilitate easy re-call – e.g. AMC – plant and machinery – 10500, repairs – machinery – 10600, travelling expenses – fare – 11555 etc., are some suggestions for easy remembrance. Positive user perception and adoption significantly contributes to the successful/error free usage of CoA.
  • Specific to Enterprise Applications – Have unique accounts for ‘clearing’ / ‘receiving’ accounts is select applications – E.g. In Oracle applications good to have separate ‘Asset Clearing’ accounts for each asset category. Likewise, in Procurement do not use the same accounts for ‘Receiving’ and ‘Inventory’ accounts. Assigning distinct accounts will facilitate in easy tracking/reconciliation.
  • Only Designated Team/Member(s) to handle any change request instead of free for all – discipline will do a world of good – trained administrators with specifics of CoA policies will help to handle changes in a structured manner to add years to the CoA.
  • Optimise the # of segments – More # of segments does not necessarily mean higher transparency / analytical capability – explore alternate strategies – E.g. In Oracle applications – Receivable transaction sources/types can be used to distinguish the recorded transactions – Before deciding on additional segments examine if this classification will be of help to meet specific expectations.

InspireXT's Services

As a part of various advisory, consulting services (covering Implementation, Rollouts, Upgrades, Extensions) in organisations where enterprise applications are already implemented requirements for re-structuring Chart of Accounts (CoA) many times come up due to various reasons. InspireXT has domain specialists with a fine blend of hands on working with skill sets to examine, discuss with various stakeholders, suggest options and provide required guidance to finalise a revised CoA structure for adoption. Thereafter, InspireXT can provide approach to actualise the new CoA in enterprise applications which involves decisions on ‘Cut-off’ date, transitioning balances seamlessly and user awareness sessions. All in all, InspireXT is well positioned to offer comprehensive services as a part of any revamp of CoA.


Chart of Accounts (CoA) is surely a pivotal piece of lasting value in the entire design of foundational enterprise structures. Touching most of the transactional users daily throughout the life cycle of the Application it is worthwhile to examine all aspects before finalisation of CoA to pave way for easy adoption by users and offering ‘enduring value’ to the enterprise. In some ways, stable and well-structured/administered CoA vouches the success of enterprise applications by providing better financial data quality which in turn facilitates better analysis, decisions based on right facts – much like limited ‘astrology’ based corporate prediction!

More blogs
InspireXT announces strategic partnership with Walpole Partnership, a consultancy formed of CPQ and Customer Experience…
InspireXT, announced the acquisition of Prosera Analytics (“Prosera”), a registered Salesforce partner……

Request for services

Find out more about how we can help your organisation navigate its next. Let us know your areas of interest so that we can serve you better.