To better manage the transition from U.S. GAAP rules-based to IFRS principles-based financial reporting, U.S. filers who use Oracle E-Business Suite (EBS) should determine how many different Charts of Accounts (COAs) they currently have and begin working on a plan to adopt a single global COA for every business entity and reporting unit. Although regional differences in reporting requirements will likely persist even after a full-scale transition to IFRS, this should not prevent organizations from a brutally honest assessment of the current situation. Whether organizations are running R11i or R12, a common COA will simplify external reporting and internally provide management with better and faster reports. Regardless of how you approach the COA design, keep in mind that the Oracle COA structure needs to contain at least 2 (balancing and account) but no more than 30 segments, the total length of code combinations can be no more than 240 characters, and the account value must be limited to one type, e.g. asset, expense. There are also tools available in R12 that will make this transition even smoother, like Secondary Ledgers, Subledger Accounting and Autoaccounting rules that we discuss near the end of the article. First, here are Chart of Accounts design guidelines that are applicable, no matter what version of EBS your organization is running.

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.