We are continuing Part I of this article with design considerations for a CoA for a high tech manufacturing company. We will refer to this company as HTM in this article. View Part I of this article:http://www.eprentise.com/blog/designing-a-chart-of-accounts/putting-numbers-in-boxes-spring-cleaning-for-charts-of-accounts-part-i/ View the original Blog post: http://www.eprentise.com/blog/designing-a-chart-of-accounts/putting-numbers-in-boxes-spring-cleaning-for-charts-of-accounts-part-ii/ Website: www.eprentise.com Twitter: @eprentise Google+: https://plus.google.com/u/0/+Eprentise/posts Facebook: https://www.facebook.com/eprentise Ensure your data is Complete, Consistent, and Correct by using eprentise software to transform your Oracle® E-Business Suite.

1. tel: 407.591.4950 | toll-free: 1.888.943.5363 | web: www.eprentise.com
Putting Numbers in Boxes:
Spring Cleaning for Charts of
Accounts— Part II
an eprentise white paper

2. Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 2
© 2014 eprentise, LLC. All rights reserved.
eprentise® is a registered trademark of eprentise, LLC.
FlexField Express and FlexField are registered trademarks of Sage Implementations, LLC.
Oracle, Oracle Applications, and E-Business Suite are registered trademarks of Oracle Corporation.
All other company or product names are used for identification only and may be trademarks of their respective owners.
Author: Helene Abrams
Published: February 10, 2009
www.eprentise.com

3. Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 3
Last month, we wrote an article about putting numbers in boxes that presented the current chart of
accounts and design considerations for a local/county government. This month, we are continuing that
article with design considerations for a CoA for a high tech manufacturing company. We will refer to this
company as HTM in this article. HTM has many of the same issues that the county government had, with
segments representing multiple types of data and with different kinds of information within one segment.
This chart is a little more complex because HTM is a global company with different statutory and
regulatory requirements. Trying to get global consensus on a new chart around the world is also very
difficult politically because everyone feels ownership of their current values and they want to continue
doing things in the way that they are used to doing them.
The current accounting flexfield for HTM has nine segments.
Current COA Structure:
CO – company – 3 digits
BU – business unit – 4 digits
DEPT – department – 4 digits
ACCT – account – 4 digits
DETAIL –detail – 4 digits
INTERCO – intercompany – 3 digits
MGTCO – management company – 3 digits
PROJECT – project code – 8 digits
CHANNEL – channel – 2 digits
Current Situation: HTM performs extensive reorganizations every quarter to accommodate department
changes. With department housed in the chart of accounts, these reorganizations include switching the
costs for an individual or group of employees who is transferred to another department. The current chart
limits the quality of analytic reporting, both within Oracle® and with third-party reporting tools. Some
segments are used for multiple data types, and the same data is used across multiple segments.
Designing a Solution
I. Design Guideline: Have one type of data in only one segment.
When the same data is represented in different segments, the values in each of those segments must be
maintained. There is a possibility of inconsistencies between segments in descriptions, and errors can
occur when the user enters a value in one segment and does not enter the corresponding value in the
other segments. The only way to prevent these errors is by using lots of cross-validation rules between
the segments having similar content. Having the same data in different segments also means duplicate
data entry.

4. Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 4
Example 1: CO – MGTCO – INTERCO are always the same, but they use different value sets. CO is used for
balance sheet and P&L, MGTCO is used for reporting regions but does not always contain geographic data,
and INTERCO is used for intercompany transactions.
MGTCO occasionally refers to the management company that pays for an employee rather than a region
that the company would like to report on. For example, in Canada, 60% of the employees might be under
MGTCO 555, but the remainder of employees might be under MGTCO 880, indicating that although they
work in Canada, they are employed and paid for by another country.
Discussion: If three segments are necessary, CO – MGTCO – INTERCO should share a value set. However,
it seems that the MGTCO that pays for an employee would be the cost center (so the payroll would have
an allocation that allocates 60% of the cost to one cost center and the rest of the payroll to a different
cost center). This example is also confusing because the location is mixed up in the MGTCO segment, but
that will be discussed in the next design guideline.
Example 2: There is a legal company created for ABC but ABC also appears in the description for department
values. Note too, that the description for these Departments also includes a building location.
DEPT Value Description
0123 ABC Quality Management Systems BU220
0321 ABC Value of Production BU220
0432 ABC Engineering BU220
0423 ABC Manufacturing Bldg 12 BU220
0424 ABC Process Eng BU220
Discussion: A location description appears in both the DEPT segment and in the MGTCO description. As
is noted later, location is also in the DETAIL segment.
Example 3: Cost center is defined as the concatenation of MGTCO – BUSUNT – DEPT (all in one: eg.
21115570157) for Hyperion reports, and the HR systems add the description in the cost center field. Every
module that uses Cost Center had to be customized.
Discussion: HTM does not have a single segment for the cost center function. In order to track specific
costs for activities or assets, a cost center segment is critical.
II. Design Guideline: Have only one type of data in a segment.
When multiple types of data appear in a single segment, there are two primary issues: the first is that both
types of data might be required for reporting and the user can’t enter two separate values for one
transaction. The second problem occurs when the values are not in a range within that segment, making it
more difficult to do reports, summarize values, and create parent and child hierarchies, often causing the
segment to run out of values for that segment.
Example 4: HTM used the DEPT segment in many different ways: as the HR organization to which an
employee’s expenses are charged, as a job function, for real estate, for supplies purchased for a building, for

5. Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 5
location (as seen in the example 2 above), for local values, and by exception as a “department” as defined in
common usage. Sales Engineers have the same department code across MCO’s. A manager uses the same
department code as the staff because he is doing the same function. Available DEPT codes may run out in
about a year since current practice confines the codes to being numeric, the codes are not reused, codes are
allocated in pre-defined ranges, and each reorganization requires 500-2000 new department codes.
Discussion: If HTM wanted to do analysis on revenue by location, they would have to select individual
departments from a list of over 9,000 departments to see which DEPT values included location. Similarly, it
is difficult to track supplies purchased for performing a job function in a building since both supplies for a
building and job function are contained within the DEPT segment. Reports driven from such dispersed
data are easily corrupted and don’t confer accurate financial information to management.
III. Design Guideline: Use subledgers (HR and Project Accounting) to store data for people,
departments, and projects rather than storing those transactions in the General Ledger.
The General Ledger is supposed to serve as a repository for the aggregated transaction data stored within
each of the subledgers. From the General Ledger, it is possible to drill down into the detail of the
subledgers. The subledgers are designed to carry out detailed transactions and have the supporting
financial data represented by posting to the general ledger. For example, the HR subledger is designed to
accommodate job and assignment changes, costing for different types of HR activity, benefits, and job
functions. It is relatively straightforward within HR to reorganize reporting structures, to move people
between departments, and to allocate their costs to a different entity.
Example 5: HTM is using the accounting flexfield as a substitute for operations normally performed and
recorded in Oracle’s HR module, requiring that costs associated with individuals be moved whenever the
individuals change departments. Quarterly reorganizations such as moving to another business unit, closing
a department, or changing a department description are commonplace in the organization. Due to the loose
interpretation of Department, reorganizations are recorded in the accounting flexfield, requiring an
inefficient manual effort of about 500 person-hours each quarter to change the departmental costs as
people are shifted to different job functions.
Discussion: HTM should carry out the employee transfer processes within the various HR functions and
use the conventional notion of a work group rather than in the Chart of Accounts.
Discussion of other segments:
 CHANNEL is not used.
 PROJECT is the same information used in project accounting, but included in the accounting flexfield
because HTM feels that it is too difficult to make adjustments and get reporting within the Project
Accounting Module.
 DETAIL contains location information.
 BU is a rollup of DEPT values and may not be needed.
 The ACCT segment is not large enough to allow clean ranges for categories of accounts.

6. Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II
Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com | Page 6
Recommended Chart of Accounts
The following structure will allow HTM to track their financials in different ways and have consistency and
room for growth. The segment lengths are estimates, but should be based on the level of detail required
and the extent to which the values in that segment will grow. Rollup groups should be established within
each segment to allow summary reporting based on the range of child values. Just as it is common for the
natural account segment to have a range of values for travel expense accounts or taxes, it is appropriate
that each segment be broken up into categories of data that can be rolled up to a broader category of
information. Locations at the lowest level of detail might include a room in a building, and at the highest
level, it might be a continent. All of these are locations and would allow tracking at whatever level of
detail HTM needed. The Cost Center segment would contain the detail to track specific costs and
revenues. The Company and InterCompany segments should share a single value set so that maintenance
is minimal and when a new company is added, it is consistent between the two segments. The Line of
Business segment would include the different business lines of HTM such as Server Products, Small
Business Products, Display Products, etc.
Curious?
For more information, please call eprentise at 1.888.943.5363 or visit www.eprentise.com.
About eprentise
eprentise provides transformation software products that allow growing companies to make their Oracle® E-Business
Suite (EBS) systems agile enough to support changing business requirements, avoid a reimplementation and lower the
total cost of ownership of enterprise resource planning (ERP). While enabling real-time access to complete, consistent
and correct data across the enterprise, eprentise software is able to consolidate multiple production instances, change
existing configurations such as charts of accounts and calendars, and merge, split or move sets of books, operating
units, legal entities, business groups and inventory organizations.