1. Build Flexibility into the Structure

The trick in designing a new COA or changing an existing COA is to always keep in mind that the future will bring change. Whatever structure you design will also need flexibility. This may sound like an impossible goal but is easily achieved by putting values for each segment into ranges that are large enough to accommodate significant growth or change in the future. For example, in Out of Range: Using Logical Ranges, my colleague Helene Abrams describes how a project segment set up in an accounting flexfield with the values 55000 – 55999 might represent a specific type of project. There is room in this structure for at least 999 different projects of that same type, and you can tell just by looking at the number what type of project it is. If the range were 550000 – 559999 there would be room for 9999 projects. If you know the trends in your business, you can define an appropriate number of characters for a segment and range. Don’t hesitate to broaden the range by increasing the number of characters in the segment. What may seem like a lot today, 999, might be wholly inadequate in a few years. Increasing segment values to accommodate growth lets you build flexibility into the COA structure, as long as you keep the total character count at or below 240.

2. Create a Hierarchy and Protect It

When designing the COA think in terms of an outline, hierarchy, or parent/child relationships. Group product lines into categories, and then define the ranges for the categories. This will help you determine where you will need to allocate more characters and where you can have fewer characters. Usually children in the family tree will be more granular and will therefore require more values, but not always. By sketching the COA family tree you will see where you need to build in room for expansion.

Once the COA tree structure is designed and implemented, stick to it. Resist the temptation to share account values with different account types because it’s “easier” to do it that way in the moment. Establish procedures, protocols, and definitions for values and types and make sure that everyone involved understands how to use them and what they mean.

3. Address Politics from the Start

By having a cross-functional team work on the COA design, global buy-in will be all but assured. However, don’t let one group dominate the decision-making process, e.g. finance ends up with 200 characters leaving only 38 for everyone else.

Designing a logical and flexible COA for Oracle E-Business Suite can start with a simple table, created in Excel, like the one below. The detail for each major category such as Company, Location, Department, Account, and Product Family for which data exists is expanded in another tab.

The spreadsheet for the Account type will include fields for the following additional information, for example:

• Range – the range of numbers in which the item falls
• Segment value – the actual number assigned to the item
• Item name or description
• The account type – Revenue, Expense, Asset, Liability, or Owner’s Equity
• If applicable, the old account number or segment value
• The parent account or rollup value
• Whether or not there are any cross validation rules with the Account Value and the Company, Location, Department, or Product Family values

4. Use Numbers Only Randomly

Avoid using intelligent numbers in any scheme you design. For products, where intelligent numbers can help to identify a particular product family or subgroup to a customer, devise a scheme where you have both non-intelligent and intelligent numbers for a particular product. The non-intelligent numbers will be used for internal and financial reports but the intelligent numbers can be used in a customer-facing environment. Also, wherever possible, avoid using alpha characters, except potentially in parent values, because these will create problems in sequencing and sorting data in reports, assigning codes, using ranges, and when creating validation and/or security rules. If you do use letters, use only capital letters for consistency and to facilitate any queries you may need to run.

5. Keep One Type of Data in One Segment

Each segment should have one – and only one – type of data in it. For example, there shouldn’t be a Department segment value such as “HR – Sacramento, CA” if there is also a Location segment in the chart. The location data, Sacramento CA, should be kept only in the Location segment, and not also in the Department segment. It is more difficult to write a rule for a segment that includes multiple types of information, and keeping the data in only its relevant segment helps reduce redundancy.

R12 Features Applicable to the IFRS Transition
Secondary ledgers and Subledger Accounting are welcome additions in R12. Sets of Books in 11i are Ledgers in R12, and Ledgers and Ledger Sets bring along with them a new and different method of performing accounting in EBS. From a single transaction ledger where a transaction is entered only one time, R12 uses accounting rules to populate other related subledgers. In this new light, a company that currently reports according to US GAAP standards is able to set up a secondary ledger specific to IFRS standards. Once the business understands how the current GAAP transactions should be mapped in order to comply with IFRS and is able to implement the mapping in the form of R12 accounting rules, EBS will take care of translating the transactions to the IFRS subledger, and IFRS compliance becomes transparent to the users. Users may continue to enter transactions in the way with which they are familiar: according to US GAAP standards. With each new transaction that is entered, R12’s accounting rules will populate the IFRS secondary ledger with the corresponding IFRS transactions. Of note here is that this can and should be accomplished with a single Chart of Accounts, provided that the Chart is designed with respect to both US GAAP and IFRS reporting standards. If a business takes the time to redesign its Chart of Accounts to accommodate both standards as well as the five guidelines listed above in the article, it will find itself in an excellent position to transition to IFRS in a seamless manner.

Conclusion
Designing a flexible COA that will work as well today as it will in the future when business takes unexpected turns takes a little forethought and sometimes some experience. A well-designed COA along with the new features in R12 make it easy to comply with IFRS standards and to reconcile with the current GAAP standards. A well designed COA should do its job for years to come while ensuring that management has timely access to reports and finance teams can quickly and easily consolidate period-end reports. When COAs are different, the best medicine is a consolidation into a global COA and redesign rather than another work around or spreadsheet.

This article is outlined with the easy tips you might already know up front, and we end with the all too elusive “Go To Special”. If you are working with spreadsheets that contain thousands, or even millions, of rows of data, then the “Go To Special” information will prove to be a helpful tool if you need to change a large or small amount of that data based on any kind of logical behavior. We’ll focus on 7 different tips, none of which involve macros or Visual Basic whatsoever – they are purely ground-level functions and features of Microsoft Excel.  >>SHOW ME!!

Meanwhile in the public sector, the new Common Government-wide Accounting Structure (CGAC), a provision mandating that all federal government agencies (of which there are over one thousand) convert their existing accounting structures to a common chart of accounts, will enter the early adopter stage in the next few years. Although there is no defined deadline for transitioning to CGAC, any number of events triggers the requirement to make the accounting change (e.g., implementing a new financial management system, upgrading major existing systems, or moving to a shared service provider). For most agencies, the mandate will be required by the end of 2010 because many software companies will sunset support for current software releases. As an example, Oracle Corporation has announced that it will not support the most widely-used version (11.5.10) of its flagship enterprise resource management (ERP) system, E-Business Suite (probably the most popular ERP system for federal agencies), in November 2010 under its standard support agreements, forcing a major upgrade to the newer Release 12. On a macro level, both IFRS and CGAC are new ways of doing business that encourage transparency and enable comparisons. They are not simply mechanical sets of rules to be placated with a bolt-on application with the sole purpose of generating financially compliant reports. The purpose of this article is to outline some of the major departures from US GAAP (Generally Acceptable Accounting Principles) by IFRS and CGAC, to analyze how such changes will affect current business practices, and to take a detailed look at how E-Business Suite users will need to change their accounting flexfields in order to comply with the new regulations.  >>MORE

The most significant of these changes is that in R12, there is no concept of Sets of Books. Ledger and Ledger Sets together replace Sets of Books. The data of a Set of Books is contained in a ledger. The management of the set of books (open and closing, reporting, allocating, etc.) is now at the Ledger Set level A ledger and is defined by the 4 Cs: Calendar, Currency, Chart of Accounts, (these should be familiar as the definition of a set of books), and Convention. Convention refers to the Accounting Method (e.g. GAAP, IAS) used.

From a single transaction ledger, you can generate rules that will populate different subledgers. For example, if you have different tax jurisdictions, you would have a ledger that would track the accounting and reporting necessary for each of the jurisdictions. You would only enter the transaction one time, and then populate that transaction to different ledgers depending on the rules that you create. Detailed transaction information is captured in the subledgers and periodically posted (in summary or detail form) to the ledger. Within the ledgers, you define accounting rules to comply with Sarbanes Oxley, providing an audit trail and easier reconciliation. You can balance at the subledger level. Subledger Accounting allows you to define centralized rules and provides multiple accounting representations of a single transaction in multiple currencies. One of the main advantages is to be able to create a single payment transaction for different legal entities or different operating units and create a rule that allows that transaction to be credited and debited correctly without creating overrides and adjusting entries. A ledger owner might be a legal entity or a group of companies in a common legal environment, or a foreign branch. Ledgers are also used to consolidate financial transactions. Accounting entries can account for themselves in ledgers that are prepared under different conventions with different charts of accounts, and value transactions in different currencies. One of the ledgers is the ‘primary’ ledger. A ledger set is a collection of ledgers that you wish to manage as though they were one ledger. Many functions are available across ledgers:

• Open/Close Periods
• Create Journals
• Translate and Revalue Balances
• View Information
• Submit Standard Reports
• Submit Financial Statements

Another major change is the Multi-Org Access Control (MOAC). MOAC allows you to perform functions across operating units without changing responsibilities. A responsibility is no-longer tied to a single operating unit. Instead, from within HR, you can assign a list of operating units to a responsibility and assign security to that operating unit through a security profile. By setting the operating unit to null, you can import all transactions for all operating units through the open interface programs at the same time. You can also create and report on transactions that cross operating units or operate a shared services center with centralized processing.

In R12, the concept of legal entity has been enhanced. A legal entity exists in the outside world and may be regulated by different governing bodies (i.e. country, state, tax authority). A legal entity pays taxes, has bank accounts, and complies with different regulatory agencies. Transactions that occur between and across legal entities are intercompany transactions. Bank accounts are now associated with legal entities rather than with operating units, allowing for a single bank account to serve multiple operating units. Income statements and balance sheets are generated along with tax forms for every legal entity. In HR, there is the Government Reporting Legal Entity (GRLE) which represents the registered legal entity who is the employer in HR.

The CHANGE – TEST – UPGRADE advantage begins by getting the results you want in Release 11. The ideal way to obtain the chart of accounts that best fits your business is to be able to see exactly what your business looks like using the new chart of accounts. A properly ranged chart of accounts reduces the number of cross validation and new sub-ledger rules that your staff needs to write. A changed chart of accounts can save resources by eliminating unused segments or code combinations.

The available software for changing charts of accounts begins by operating in a test environment where you can go from mappings to a fully testable result in hours. Besides ensuring that there are no errors, testing permits you to see the results and change the mappings if the result was not as desired. It is a modeling process that allows you to see “what if” these segments were mapped together, or what if I added another segment to track a new area of the company. The upgrade then becomes as straightforward as possible – no changes to the accounting structure are being made as part of the upgrade.

If you have decided to reimplement, you have probably made the decision to bring over only a small amount of history into Release 12. You’ve made the decision to reimplement because you want to take advantage of the features of 12, and also because your e-Business Suite has not changed to meet your current business. The typical way to load the history into a new implementation is to load the transactions using a loading tool. However, if you are loading from one chart of accounts to another, that load script needs to include the conversion of the first chart of accounts to the second. If you are changing charts of accounts, you are creating a very complex scenario for your developers. They will have to map and translate the accounting for every transaction to the new chart. The testing becomes even more difficult because you must test to see that the data loaded correctly, you must reconcile your new chart of accounts with the old one, and you must test the new chart of accounts in every module. By changing the chart of accounts first, the load becomes a “clean load” with no mapping and translation effort for the migration.

The CHANGE – TEST – UPGRADE method creates a clean audit trail and creates the SOX compliant reports that show the history of the changes for every transaction. You have a baseline of reports that you generate before changing the chart of accounts, you have a listing of everything that has been changed, and you have the same reports that are generated after the chart of accounts change. If the change is done as part of the load process, you lose the audit trail. The changes are effected in Release 11, which is what your staff has worked with before, and allows them to test and reconcile the data to provide a baseline for comparison before the move to Release 12. The upgrade that is required is as “vanilla” as possible – apart from moving the data from 11 to 12, no other changes are being made. The more complicated upgrade functionality that permits changes at the sub-ledger level is not employed, nor will that part of the Release 12 functionality be needed. The complexity of Release 12 makes staying as close to its mainstream as possible a prudent strategy.

The benefits of the CHANGE – TEST – UPGRADE method are many, varied, and substantial. Those benefits can only be obtained by changing your chart of accounts in Release 11, before the upgrade to Release 12.

Designing an accounting flexfield is one of the most difficult processes in an Oracle implementation. A “good” chart of accounts has the following criteria:

1. The segments support important aspects of the business.
2. You are able to report on critical business components with standard reports without resorting to spreadsheets.
3. There is enough room to expand within each segment.
4. FSGs and other reports are easy to create.
5. Summary accounts and rollup groups fall naturally within ranges.
6. Information in the chart of accounts is not repeated from other modules.
7. There is only one type of information in each segment.

>>MORE tips for designing a chart of accounts…

Most of the changes to flexfields in Oracle Apps occurred between Version 10.7 and 11i. These changes included the addition of several APIs for the flexfields and the change of the name FlexBuilder to the Account Generator.

The most significant change is the ability in Release 12 to synchronize the context field value with the reference field value for descriptive flexfields. The example given in the documentation is that generating an expense report would refer to the context field for a country code and that would remain constant and specific to the user. If payment processing is done in another country, the context would not be derived from the payment processor’s country, but by the user who generated the original expense report. However, if the payment processor enters his/her own expense report, then the expense report would be synchronized to the country in which the payment processor resides. If the context field is not synchronized, the context information defaults at the time the record is created, even if the reference field value subsequently changes.

The Release 12 documentation corrects an error from the Release 11 documentation in the key flexfield names. The Release 12 Flexfields Guide correctly refers to the code for the key flexfield for Sales Orders as MKTS and the Owning Application as Oracle Inventory and the code for the Sales Tax Location Flexfield as RLOC, and the owning application as Oracle Receivables. The other changes between Releases 11i and 12 are relatively minor. The documentation for Release 12 has been updated with some formatting changes, changes in referenced document names, and an update of some of the years from 2002 to 2007. Most noticeably, all references to prior versions and upgrades from prior versions have been omitted in the Release 12 documentation.