putting numbers in boxes: spring cleaning for charts of accounts – part i

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

Putting Numbers in Boxes: Spring Cleaning for Charts of Accounts— Part II

Copyright © 2014 eprentise, LLC. All rights reserved. www.eprentise.com |

© 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



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.

http://eprentise.com/blog/83/225-putting-numbers-in-boxes-spring-cleaning-for-charts-of-accounts-part-i



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



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.



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.

putting numbers in boxes: spring cleaning for charts of accounts – part i

Software