Oracle Fusion Edit Key Flexfield Structure page showing a seven-segment chart of accounts: Company, Account, Department, Fund, Analysis, Intercompany and Activity

Designing an Effective Chart of Accounts in Oracle Applications

Leave a Reply

In October 2003 I presented a paper at the South African Oracle User Group (SAOUG) conference called Designing an effective Chart of Accounts structure using Oracle Applications. I had given an earlier version of the presentation at Oracle AppsWorld in San Diego that January. This post summarises what the paper says, and you can download the paper and slides at the end.

The paper was written for Oracle E-Business Suite 11i, so some of the names have changed. A Set of Books is now a ledger, and FSG and ADI have given way to newer reporting and spreadsheet tools. The thinking behind chart of accounts design has hardly changed at all, though. Twenty-odd years and many Oracle Fusion Cloud implementations later, I still see the same mistakes being made.

Why chart of accounts design matters

I described the General Ledger as the heart of the system. Data is pumped into it from Payables, Receivables, Fixed Assets, Payroll and every other subledger, and it flows back out as reports and enquiries. If the chart of accounts that structures that data is wrong, the whole system runs badly. A good design makes data entry easier, gives you room to grow through acquisitions and disposals, and lets you find information again once it is stored.

The paper also offers a simple health check. Look at how your management reports and financial statements are produced. If producing them takes days of spreadsheet work and reorganising data, your chart of accounts is probably poorly designed. I called this the “spreadsheet factory” trap, and it is still common.

Common chart of accounts mistakes

  • Copying the old chart of accounts. Taking the legacy chart, making a few changes and loading it wastes the multi-dimensional analysis a modern ERP system gives you.
  • Leaving it to Finance alone. Operations, HR and other departments need a say, otherwise the design reflects one silo’s view of the business.
  • Handing it to the implementation partner. Partners can guide the design, but the organisation has to own it and maintain it after go-live.
  • Ignoring the outside world. Country, industry and organisational factors all shape reporting requirements, and it pays to look at what similar organisations have done.
  • Forgetting the past and the future. Restructuring, growth and diversification plans need to be known before the design is finished, not after.
  • Replicating subledger detail in the GL. The General Ledger should hold a summary of what happens in the subledgers, not a copy of it.

Behind all of these is what I called the eternal paradigm: blaming the system. The system only does what it has been set up to do, so the answer lies in getting the mix of people, processes and technology right.

A three-step approach to designing the chart

The paper works from the top down. It deliberately puts system functionality last, because most of what makes a chart of accounts design succeed happens outside the system.

1. Generic design issues

  • Begin with the end in mind. Gather the management reports and financial statements you need, or design new ones for the new system, and work backwards to the account structure. Ask management where reporting causes them pain, and fix that.
  • Be proactive about growth and restructuring. I have finished a design only to find out about a restructuring that changed everything.
  • Start simple, then enhance. Only build the complexity you can maintain. One client I audited had a superb design and two people to look after it.
  • Agree standards and conventions, and check whether group or global standards already apply.
  • Hold cross-functional workshops to agree the design, the standards and who maintains the chart, centrally or locally. Get the finished chart of accounts signed off by everyone involved, as this is one of the best ways I know to get ownership.
  • Get a third-party review. People on a project develop mindsets, and a fresh pair of eyes will find what they have missed.

2. Country, industry, organisation and module considerations

Some countries dictate parts of the structure through statutory requirements. Industries need their own segments of analysis: product for a manufacturer, region for a distributor, project type for a project-based business and funding source for government. Most segments, such as company, cost centre and account, are common to all of them.

You also need to understand the organisation’s subsidiaries, divisions and how they trade with each other, because intercompany has a big effect on the design. Each module needs its own control and interface accounts, plus temporary accounts for taking on opening balances. Bottom-up budgeting needs more detail in the chart than top-down budgeting. And every third-party system that interfaces to the ledger needs to be mapped before the chart is finalised.

3. Oracle functionality

  • Set of Books (now the ledger). The chart of accounts, calendar and currency, the “three Cs”. If these are the same across companies, keep them in one ledger with a company segment. If any differ, use separate ledgers but keep the summary accounts common so consolidation stays easy. Oracle Fusion Cloud adds the accounting method as a fourth C.
  • Segments. Oracle allows far more segments than most organisations need, but I recommend five to seven, plus a spare segment for future growth. Order them to make data entry easy.
  • Value sets. Choose the length carefully, as the total code gets long quickly, but don’t make values so short that you run out. Use numeric values wherever you can.
  • Values and hierarchies. Child values take the postings and parent values summarise them. Keep to around five levels of hierarchy, and classify every account as an asset, liability, equity, revenue or expense.
  • Cross-validation rules control which combinations can be used, for example requiring a department on income statement accounts but not on balance sheet accounts. Rules that are too strict stop people capturing data, so bring them in once users know the chart.
  • Security rules restrict which values users can see, enter and report on, for example hiding payroll costs.
  • Aliases give friendly names to account combinations people use a lot. Add them once you know which combinations those are.
  • Statistical accounts hold non-monetary figures, either in a dedicated range or alongside the monetary amounts in the same account.

Constant renewal and maintenance

An ERP implementation is never really finished, and neither is a chart of accounts. Some design decisions are permanent, but cross-validation rules, security rules and aliases can always be improved, as long as the changes don’t come so often that users can’t keep up.

The paper sets out a maintenance procedure to agree in your first workshops: identify the change, get it authorised, decide how significant it is, test significant changes in a test environment, tell users before and after, make the change in production and update the documentation. In too many implementations, nobody controls who changes the chart or how.

Coding tips

  • Group accounts into wide ranges for each of the five account types.
  • Leave gaps between values and ranges so there is room for growth. If you can see a shortage coming, add another character to the segment.
  • Create meaningful patterns in the codes and document them so everyone understands them.
  • Design the chart in a spreadsheet template first, so it follows your conventions and can be loaded electronically. Make the client responsible for loading their own data, with sign-off.
  • Restrict mass-editing tools for hierarchies to a few super users. In 2003 that meant the ADI Account Hierarchy Editor, and the same advice applies to spreadsheet uploads of hierarchies today.

What still holds today

The tools have moved on. Oracle Fusion Cloud gives you segment labels for the balancing, cost centre, natural account and intercompany segments, tree-based account hierarchies, cross-validation combination sets and related value sets. The conclusion of the paper still stands, though. Good chart of accounts design is mostly about having a clear picture of the information the organisation needs, and then implementing it with the right people and processes. The technology is the easy part.

Download the paper and presentation

Designing an Effective Chart of Accounts Structure using Oracle Applications – white paper, SAOUG Conference, October 2003 (PDF)
Designing an Effective Chart of Accounts Structure using Oracle Applications – presentation, SAOUG Conference, October 2003 (PowerPoint)
Chart of Accounts Spreadsheet Template – companion to the white paper (Excel)

You will find my other papers and presentations, including It’s month end, now comes the reconciliation crunch! and Audit Considerations for your 11i Implementation, on the Downloads page.

Related

Related posts

Related articles

Earlier posts