Last month, this newsletter had 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.
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.
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.
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.
