Real Life Case Studies in Oracle

Applications
April 25, 2011

WHITE PAPER ON CHART OF ACCOUNTS

WHITE PAPER ON CHART OF ACCOUNTS
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
Width

>

Company

Cost Centre Line of Business Accounts

Future

>

>

001

008

003

52396

00000

>

XYZ Corp

Marketing

Chemicals

Advt Exp

Future

Sample Values

Code
Meaning

Sample CoA for a Manufacturing Company

Sample Structure

Segment >
Width

Company Cost Centre Location Accounts

Product

Future

>

>

001

003

122

73100

XPC125

00000

XPC125

Future

Sample Values

Code
Meaning

>

ABC Corp Production Mumbai Material

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 suppliers or customers
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 Oracles 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 companys 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 Dr $700
Company 99 Intercompany Account 04 Dr $550
Company 99 Intercompany Account 01 Cr $1000
Company 99 Intercompany Account 02 Cr $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 ---