Chart of Accounts White Paper

1 White Paper on Chart of Accounts

WHITE PAPER ON

-

CHART OF ACCOUNTS Kishore Khatri


Introduction to Chart of Accounts

What is a Chart of Account? Chart of Accounts is a list of accounts used by an organization to record financial transactions. The accounts are typically grouped & arranged in the order of their appearance in financial statements. Traditional accounting systems use a single segment (Natural Account, & sometimes cost centre as well) to record the financial information. However with the change of time, the businesses crossed boarders & hence required financial information to be presented in a more detailed manner. Globalization, coupled with statutory requirements, require that the organizations prepare their financial information with multiple dimensions across countries, products & locations. With the introduction of ERP, a multi dimensional chart of accounts was developed.

A typical chart of account in an ERP environment will consist of multiple segments like Company, Division, Location, Cost Centre, Account, Product etc. This allows the organizations to report financial information sliced into various segments. A well designed chart of accounts helps in better statutory compliance & efficient decision making.

Chart of Accounts in Oracle Applications In Oracle Applications, a chart of account is one of the foundations based on which the rest of the system is designed. Chart of Accounts in Oracle Applications is made up of following components:

a. Structure The chart of account structure is the combination of multiple segments arranged in a logical order where each segment has enough width to accommodate the values within. The CoA structure is the basic configuration which cannot be changed once defined. Following are examples of some chart of account structures:

Sample Structure

Sample CoA for a Trading Company

Segment > Company Cost Centre Line of Business Accounts Future Width > 3 3 3 5 5

Sample Values

Code > 001 008 003 52396 00000 Meaning > XYZ Corp Marketing Chemicals Advt Exp Future

Sample Structure

Sample CoA for a Manufacturing Company


Segment > Company Cost Centre Location Accounts Product Future Width > 3 3 3 5 6 5

Sample Values

Code > 001 003 122 73100 XPC125 00000 Meaning > ABC Corp Production Mumbai Material XPC125 Future

b. Segments

Each segment in chart of account represents a dimension required for financial transaction. In the example given above for manufacturing company, there are six segments in the chart of account. Whereas an organization can decide to have any number of segments, Oracle Applications requires it to have a minimum of 3 segments in a CoA (Cost Centre, Natural Account & Balancing). Another 2 segments – Intercompany & Secondary Tracking- can optionally be defined in Oracle.

c. Values Each segment is made up of a list of values. E.g. company segment will list all the companies in an organization; Accounts will list all the natural account codes.

d. Summary Accounts Summary account is a combination of more than one account so that the sum of balances of those accounts becomes the balance of summary account. Hence summary accounts helps in summarizing the balances of some accounts at a single place.

e. Cross Validation Rules Cross validation rules help in restricting using a certain combination of account codes. E.g. balance sheet related accounts should not be used with cost centres.

f. Security Rules Security rules help in restricting the use of specific segment values by specific users or responsibilities E.g. users in company 01 should not be allowed to use the value 02 in company segment.

g. Aliases An account alias is an easily recognized name or label for an account combination. This helps in faster data entry & minimizing errors in selecting segment values.


What is a Good Chart of Account? A good chart of account should have following characteristics:

a. Simple to understand The account structure should be logically ordered & the labels should be self evident so that the data entry users can start using the system with minimum training

b. Minimum segments Maximum information

It is recommended to keep the number of segments to minimum. A lengthy chart of account structure increases the data entry time as well as chances of errors.

c. Expandable

A good chart of account should have provision for accommodating future expansion of business. It should have sufficient provision for defining more segment values, be it for company or account codes. This means that while deciding the number of characters for individual segments, future plans of the company should also be kept in mind. E.g. an organization currently having 6 legal entities may think of having the company segment with a character length of one. This way the segment will only accommodate maximum 9 companies. Hence it is recommended to keep the length as at least 2 characters. So that 99 companies can be accommodated. Also, there should be a provision for adding another segment to the existing chart of account based on any requirement that may arise in future. This can be handled by defining a future segment with default values of say 00000. As & when need for a new segment arises, this segment can be renamed & used.

d. Numbers only – not alphanumeric It is much easier to do data entry & analysis when the codes are all numeric. Having alphanumeric codes for your segments considerably reduces the efficiency of data entry. Any accountant can vouch for the fact that it is much easier to use the number pad on the keyboard than to move from number pad to alphabets to back to number pad. Also during reporting & analysis it is difficult to sort & arrange data when the codes are alphanumeric.

e. One for all

A common CoA structure should cater to requirements of all divisions & subsidiaries of the organization so that there is a single CoA across the business group. In case where the organization is operating out of multiple countries, it mostly requires having a separate set of book for each of those countries. This gives the organization freedom to have a different CoA structure for those countries. However, any difference in CoA structure will pose problems during the consolidation. Hence it is recommended to have a common structure. This not only helps in standardizing processes but also helps in easy consolidation.


f. Less dependency of one segment on another Creating dependency of one segment on another complicates the CoA management. As far as possible, there should not be dependency & all segments should work independently. For building relationships between 2 segments, cross validation rules must be used instead.


Factors to be considered while designing Chart of Accounts structure The designing of chart of accounts structure is a critical process for two reasons. Firstly, it affects all the departments within the organization & secondly, it is a configuration which cannot be revisited on a later date. A chart of account structure, once defined in Oracle Applications, cannot be altered. Due to this reason it is important to give attention to all the factors which could affect the chart of accounts. Some of these could relate to requirements within the organization, some to statutory requirements & some to industrial requirements.

Following are some important factors which should be considered while designing chart of accounts structure:

• Legal Entities When a business group is operating though more than one legal entity, it requires having at-least one trial balance per legal entity. However, in some cases, it may require to have more than one trial balance for a legal entity. E.g. organizations in projects domain have multiple projects running under same legal entity. There projects have their own budget & statutory requirements & hence their own trial balance. It is important to discuss the current legal structure of the organization & also the future plans to ascertain the level on which the trial balance is required to be produced. Oracle provides the feature of balancing segment to identify the level on which the trial balance is to be produced. Mostly this is the first segment in the chart of accounts & is often named as company. System ensures that there is credit for every debit & vice versa for this segment.

• Budgeting The level of budgeting done in an organization provides a guideline to prepare the company, cost centre & natural account segments. Mostly organizations have multiple budgets representing different departments, products or projects. The chart of account structure should be defined so that budgets can be captured at an appropriate lowest level & also that the transactions can be captured at those levels providing easy comparison with the budgets.

• Company Locations In cases where the organizations operate from more than one location say through sales offices, factories, subsidiaries etc, it may be helpful to record the location where a particular financial transaction occurred. It may not be a good idea to have a trial balance for every location but there can be a segment in the CoA to capture the location.

• Supplier/Customer Locations Organizations which need to analyze the financial information based on the supplier’s or customer’s location may require a location segment dedicated to this. However this has very limited application


in terms of usefulness. E.g. software companies cater to clients from all over the world & may like to make strategies based on which customer territory contributed how much to the revenue & hence a customer location is an important segment but for a manufacturing organization this will hold no relevance.

• SBU Sub Business Unit or Operating Unit or Line of Business has been introduced more & more in modern chart of accounts consequent to diversification of services & globalization of operations. Business groups these days are providing services in multiple domains. While it may not be prudent to have a trial balance generated at this level but business would certainly like to know which line of business contributes how much to the cost & revenue. Though this may look purely as management requirement but in certain countries accounts segmental reporting has been mandated & hence maintaining accounts at SBU level makes sense.

• Departments / Cost Centre Almost all charts of accounts have a segment for cost centre. Oracle Applications also requires one of your segments to be marked as Cost Centre. Hence it is required to understand all the departments within the organization & how those incur costs. More often than not these will be useful for budgeting also as every department would like to have their own spending budget.

• Products Some organizations deal in products which are low in volume but high in value. Mostly these organizations would like to analyze their costs & revenue for individual products. Where the organizations are using inventory & manufacturing modules, the relevant direct costs can be captured in the sub-ledger itself. However indirect costs & revenue may still need to be apportioned. This may call to have a product segment in your chart of account. E.g. a manufacturing & trading company producing high value generators would like to have a segment in the chart of account so that the financials provide a full picture on product performance. On the other hand, a supermarket dealing in thousands of product will have no interest in recording every transaction against the individual product & hence will not require having a product segment.

• Projects Similar to product segment, certain organizations have their business models build around project activities. E.g. a property developer may like to have all its cost & revenue against individual projects. Project costing module will certainly help in capturing this information. But again in cases where costs are indirect or are being interfaced through other systems may not travel through projects modules. In such cases, the management may wish to have a project segment in the CoA.

• Modules Oracle applications provide a number of modules to cater to individual needs of various organizations & functions within. While deciding what segments to include in the charts of accounts,


consideration should be given to the modules being used & the data which these modules are capable of capturing. Modules like Payables, Receivables, and Assets etc which are called sub-ledgers maintain all the details pertaining to suppliers, customers & assets respectively. Hence the organization need not have a segment or value in chart of account to record this information in detail. On the other hand, a project organization which is not using Oracle’s Project Costing module may find it useful to have a project segment in the CoA.

• Reports The reports required by an organization can broadly be divided into two parts. Firstly, the reports that are mandated by law & secondly, the reports required by management for analysis & decision making. All these reports provide an excellent guideline to decide what information should be captured in the chart of accounts & hence what segments to be built in. More emphasis should be given to statutory reports & one should ensure that the chart of accounts can help in generating these reports with least possible intervention. Whereas some negotiation can be made on management reports if certain reporting tools like Hyperion are being used. These reporting tools have the capability of building rules & relationship & presenting the data in various dimensions relieving the pressure from chart of account.

• Intercompany In cases where the organization operates through more than one company/division, there are intercompany transactions generated in the course of business. There are various ways to account for these transactions. These may vary based on the local legal requirements or company’s policy. When such transactions are very frequent, organizations may require having an intercompany segment created in the chart of accounts so that the target company code can be selected by the origin company. Oracle application provides an identifier for intercompany segments which help in doing consolidation & elimination.


Chart of Account Design & Maintenance Process As mentioned earlier that the chart of account is the basic foundation for ERP configuration & hence there needs to be well planned process for chart of account definition & maintenance. Following is a broad guideline on how the chart of account should be designed, defined & maintained.

Step 1 : Discuss the factors affecting CoA As the first step towards definition of chart of accounts, all the stakeholders should be identified & then a discussion should be initiated with the stakeholders to understand all the factors that affect the chart of accounts definition. Finance is often mistaken to be the only stakeholder in the chart of accounts definition process. In reality, a chart of accounts affects most of the departments of an organization. Marketing department would like to know the effectiveness of their campaigns & an effective chart of account is a good way to get there. Similarly, projects department may like to contribute to the designing of the chart of accounts to ensure project budgeting is properly handled. Also, having stakeholders from various domains throws more light on the operations of the organization, the industrial requirements & the plans for future – all these factors are critical to a good chart of account. Step 2 : Design Structure Once the discussion is completed & all the factors have been considered, optimum chart of account structure should emerge. This can now be defined in Oracle Applications. It is important to mark balancing segment, cost centre & natural account segment at this stage. Additionally intercompany & secondary tracking segments can also be marked. As discussed earlier, it is important to have enough character length for every segment. Also the display width should be good enough for the users to see the full value while doing the data entry. Step 3 : Define Values Every segment defined in the chart of account will have a value set attached. So the next task should be to enter the list of valid values for every segment. This task in itself requires a lot of planning specially for natural account values. Normally, the natural account values are defined in a hierarchy format having grandparent, parent & child values. This resembles closely to the presentation of accounts in financial statements. Following are few important points to be considered while deciding the natural account values:

• Introduce relationships (Grandparent, Parent & Child) where only child values are allowed to be used for accounting. Parent & Grandparent values have to be used for roll up & reporting only.

• Keep enough spacing between two groups of values so that any future additions can be accommodated.


Step 4 : Define Aliases Aliases help in faster data entry & reduction of errors. It is a short name for a combination of most commonly used values. To define alias, frequently used transactions need to be identified & a proper alias should be given to them. Care should be taken while naming the alias as it should clearly tell which values it represents. An alias not properly named will result in mass errors. Step 5 : Define Summary Accounts Summary Accounts are placeholders where two or more accounting combinations are grouped. Summary accounts are used for easy viewing of summation of balances for a group of account combinations. Not only does it help in faster balance retrieval but also aides in reporting & decision making. Step 6 : Define Intercompany Setup Organizations having more than one company (balancing segments) need to define intercompany setup. By default, all accounting entries in Oracle Applications are balanced by the balancing segment. This means that for every debit for a company there is a credit for the same amount for the same company & hence the trial balance tallies for every company. However when a company transacts with another company & hence the accounting entry has different companies on debit & credit sides, the system uses the intercompany configuration to find out the intercompany accounts & automatically balances such journals. In case, there are a lot of balancing segments & frequent intercompany transactions for an organization, it is a good idea to use a dummy company as an elimination entity. This way all intercompany transactions will be routed through the elimination entity & hence the reconciliation/ reporting becomes much easier. In-fact this is the only way to effectively handle multiple company intercompany transaction i.e. accounting entry where there are multiple companies on debit & credit sides & it is difficult to find out how much one company owes another. E.g. Company 01 Dr 1000 Company 02 Dr 250 Company 03 Cr 700 Company 04 Cr 550 Intercompany Balancing Journals using elimination entity (99): Company 99 – Intercompany Account 03 700 Company 99 – Intercompany Account 04 550 Company 99 – Intercompany Account 01 1000 Company 99 – Intercompany Account 02 250 Step 7 : Define Cross Validation Rules & Security Rules There are certain chart of account combinations which should not be used at all. E.g. there should not be a cost centre associated with asset or liability account. Or a particular bank account should be used only with a particular company. Hence certain accounting combinations should be blocked & this task is


done by Cross Validation Rules. By defining cross validation rules, we can restrict creation of invalid accounting combinations. On the other hand, if certain charts of account values have to be restricted for certain set of users, then security rules have to be used. By defining a security rule & assigning the same to a responsibility, the user of that responsibility is not allowed to use the specific value. E.g. Salary related accounts should only be available to payroll team & not to other users. Both cross validation & security rules need constant maintenance. Every time a new value is added to the chart of account, it should be validated against the existing cross validation rules & security rules so that the new value can be added to the required rule, if needed. Step 8 : Design CoA change management process So far, the configuration part of the chart of account is finished. What remains is the most critical step amongst all – designing the CoA change management process. Chart of account management is a continuous process & the sheer importance of it in the scheme of ERP requires proper controls in place. A well designed chart of account can easily be turned into a disaster if proper change management process is not put in place. If the users are allowed to add/remove/modify values without any standardization & without any approval process, the efforts put in initial design of chart of account will be wasted. A typical chart of account change management process should encompass the following areas:

a. Codes naming convention There should be standardization toward the naming convention used for various values. This includes decisions like whether the description of values will be upper case or proper case etc. The standards should cover all the segments in the chart of account & should provide clear guideline on defining new values. b. Approval process Any change in value should ideally be approved by a centralized body responsible for chart of accounts. This could be a couple of senior members of the corporate finance team or a person each from business & finance. The levels of approval may vary from organization to organization. But the basic idea of checking the implications of any change should be followed while approving. c. Documentation The full initial design as well as any change in the chart of accounts along with the applicable approvals should be documented in a central repository. d. Alerts Another good idea is to have an Oracle alert created to inform a set of users as & when any change in made in chart of account values.


To summarize, Chart of Account is the foundation – the strength of which will decide the strength of the building built over it – the ERP. There is no standard chart of account template which can be adopted by all the organizations & every organization needs to build its own chart of account based on its own experience. But there surely are some basics which go a long way ensuring the effectiveness of chart of account. Time spent on visiting these basics is the time well invested in building a strong connected organization.

--- End ---


White Paper on Chart of Accounts To have a deeper discussion on this topic, please contact: Kishore Khatri, ACA Email: [email protected]

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

Documents

Chart of Accounts White Paper