White Paper on Chart of Accounts 1

WHITE PAPER ON

CHART OF ACCOUNTS
- Kishore Khatri
 White Paper on Chart of Accounts 2

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 CoA for a Trading Company

Sample Structure
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 CoA for a Manufacturing Company

Sample Structure
 White Paper on Chart of Accounts 3

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.
 White Paper on Chart of Accounts 4

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.
 White Paper on Chart of Accounts 5

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.
 White Paper on Chart of Accounts 6

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
 White Paper on Chart of Accounts 7

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,
 White Paper on Chart of Accounts 8

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.
 White Paper on Chart of Accounts 9

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.
 White Paper on Chart of Accounts 10

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
 White Paper on Chart of Accounts 11

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.
 White Paper on Chart of Accounts 12

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 13

White Paper on Chart of Accounts

To have a deeper discussion on this topic,

please contact:

Kishore Khatri, ACA

Email: kishorekhatri@gmail.com

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.