Assumptions

You are either: -.

• Preparing for a new implementation.
• Presently implementing.
• Have already implemented but could benefit from enhancements and improvements.

You have an approved methodology for implementing your system and each of the steps mentioned here will fall within the phases being used in your implementation methodology.

(Note: Refer to typical Oracle AIM phases of Definition, Operations Analysis, Design. Build, Transition and Production and mention how your recommended approach for designing Charts of Account falls within these phases.)

Objective

To emphasise that building an effective chart of accounts is dependant on using the right “mix” of people, processes and technology.

To give you the techniques and methodologies involved in designing a chart of accounts so that you can maximise your return on investment.

(It’s much more than just having the right technology. Most ERP systems today are technologically sound but people do not use the technology properly and build appropriate processes around it.)

Why the need for an effective Chart of Accounts?

• It is the heart of the system into which all modules and interfaces flow.
  (Being the heart of system means that there should be an appropriate inflow from operations and outflow in terms of reports and information. Just like the human heart the chart of accounts is a system within a system and we have to bear in mind that if one system fails, particularly one of the controlling systems all other systems are likely to shut down)
  
• Ease of Use.
• Flexibility.
• Provides a good foundation for further expansion as well as appropriate storage of current and historical information. (As with a building if there is not an appropriate foundation you will not be able to expand and you might find that the building collapses.)
  
• Provides the basis for timeous management reports and financial statements.

(A good health check on your chart of accounts is to take a look at the state of your management reports and financial statements as well as the processes involved at arriving at these reports. If you are having problems in this area that chances are you have a bad chart of accounts structure.

You should ensure that you don’t get into the spreadsheet factory scenario by ensuring that all you’re GL data sits in the appropriate places.

There are a multitude of systems in which management reports can be designed – OFA,FSG and third party systems. These can only be effectively utilized if you have a well designed Chart of Accounts.)

• To ensure implementation success and continued use of the system.

How to empower your organisation

• These days there is a lot of talk about empowerment and what ERP systems do is allow you to empower your organisation.
• How exactly do such systems allow you to empower your organisation.
• Well, it is by structuring your data in a way that enables management to make informed and timely decisions based on the the structured data or information you obtain.

What happens when you empower your organisation?

What happens when your organisation becomes powerful?

You become like our friend Mr. Schwarzenegger in that firstly everyone notices and takes an interest in what you are doing.

Secondly, you become leaner and meaner which enhances your ability to operate in today’s increasingly competitive environment.

Some common mistakes

(Mistakes that you make during the implementation have a tendency to come back and burn you later.

Since prevention is better than cure it’s a good idea to try and get things right the first time. I wonder whether you have seen any of these in your organization.)

• Gather existing chart of accounts and modify to incorporate Oracle functionality. (This is a common mistake. One of the things that should be borne in mind with ERP systems is that we are moving from 2 dimensional to 3 dimensional levels of analysis so there is no way you should use your old chart of accounts as a starting point for designing your new chart of accounts, rather it should be an information source.)
  
• ONLY the Finance Department designs and understands the chart of accounts. (There is no inter-departmental communication, that is, people are working in their silos. Some people don’t even think of the where they want to go!)
  
• The implementation partner is made responsible for designing the Chart of Accounts. (Implication is ownership problems later on.)
  

• No consideration of impact of country, industry and organisational factors on reporting requirements and Chart of Accounts Structure.
• Past, present and future .
• Inadequate summarisation of data in GL. Replication of same data between sub ledgers or modules. (What we need to see in the general ledger is a summary of what is happening in the other modules.)
  

The eternal paradigm

• We seem to develop a mindset during implementation which blames the computer for all our mistakes and problems.
• We need to bear in mind that the computer is only operating in the way it was programmed to do and ensure that we get our people and processes working well in conjunction with our technology.
• Remember, garbage in garbage out.

Proposed Methodology

(I am taking a top down approach. The theme is that there are a lot of out of system procedures that need to be looked into.)

• Generic Design Issues.
• Issues relating to your country, industry and modular setups.
• Take into account Oracle Specific functionality that may be useful in the design process.
• Continuous Improvement.

Generic Design Issues

• Begin with the end in mind. (This is the second habit of highly effective people)
  
  • “To begin with the end in mind means to start with a clear understanding of your destination. It means you know where you are going so that you better understand where you are now and so that the steps you take are always in the right direction” – Stephen Covey.
• Gather management reports and financial statements or design new ones. Then work backwards to arrive at your Chart of Accounts Layout. (Perform a backward mapping exercise. It’s also good to ask management what pain they are experiencing in their organisation relating to reporting and systems structures to get an indication of what specific areas not your attention. This will ensure that you get executive and management buy in. Example of your first experience in designing financial statements at TA Holdings.)
  
• Consider organisational growth and diversification plans –be proactive, not reactive.
  (Ensure that all parties involved in the COA Design know what is happening when it comes to the organisational infrastructure. Be aware of any changes that may occur or ask the necessary people whether this is likely. I have worked in organisations where only after completing the chart of accounts and system design were we made aware of ongoing restructuring efforts within the organisation.)
  
• Start with a basic structure and then enhance. However, ensure there is a match between level of detail and ability to maintain this – KISS.
• Ensure that you work well with your implementation partner.
• Use all the tools Oracle Provides you with to manage the process – ADI, Workflow,Tutor,Alert. (Take a look at the CD pack that you get from Oracle when you install the software, you will find that there is a lot of additional software available that you were more than likely not aware existed. Some of it has licensing requirements whilst others don’t. I’ll talk about most of these tools during the rest of the presentation. At the moment I would like to point out that Tutor is a very useful tool for designing user manuals and training material that will assist users in their understanding of the Oracle system.)
  
• Develop a set of standards and conventions. (It’s important to ensure that your chart of accounts operates in accordance with a set of rules, standards and conventions. It’s just like driving on the road – if we didn’t have any rules and standards people would be driving all over the place and there would be a lot more accidents. Example of driving from LA to San Diego. What you also need to ensure is that for a global or multinational type rollout that you find out whether there are any standards or design conventions that need to be adhered to.)
  
• Team work within the organisation – particularly important for Multi-site.
  (Ensure that all departments and lines of business (finance, operational and HR) are involved. It seems like common sense but you will be surprised how many times this does not happen.)
  
• Hold workshops.
  (It is imperative that you hold workshops.)
  
  • Ensure users understand the importance of an appropriate design infrastructure.
  • Establish procedures for maintenance and update – Centralised or decentralised approach.
  • Agree on standards and conventions.
  • Ensure that the chart of accounts is signed by all the parties involved – that’s one way to ensure peoples involvement and acceptance.
• Third party review. (Ensure that you get an independent review of your structure. It’s always useful to get a different view since persons involved in the Chart of Accounts might have missed something.)

Country, Industry and Organisation Specific Considerations

(Mention that you are taking a top/down approach.)

1. Country.
2. Type of industry.
3. Organisation – multi-org, number of sites, information types.
4. Modules implemented.
5. 3^rd party Interfaces and systems.

Country Considerations

Check whether localisations and/or statutory accounting requirements affect your chart of accounts. (Italy is one country that has various statutory requirements as to how your chart of accounts should be designed. Germany and Norway require a distinct segment VAT)

Industry Considerations

Manufacturing/Services

Distribution (News)

Projects

• Your analysis structure or what Oracle call’s segments can be structured in the following ways – this illustrates the move to multiple dimensions of analysis, essentially giving you a three dimensional as opposed to two dimensional view.
  
• Each industry also has their unique way of determining profit which should be built into your chart of accounts.
  
• Despite their being segments which are common to particular industries most of your segments should be common e.g. Company, Account, Department/Cost Center.
  

Organisation Type

• A single company with all offices in one country.
• An international company with offices overseas but a single reporting structure.
• A multinational company with subsidiary companies, each with its own reporting and management structures.

Each organisation structure will have a unique impact on the chart of accounts. Ensure that you understand the organisational infrastructure – know what subsidiaries, divisions, branches and warehouses you have. Also know in which manner all of these organisations interact with each other. Inter-company has a profound effect on the chart of accounts structure and you should make sure that you understand the relationships in these areas.

Modular considerations

Which modules are being implemented and how do they impact the Chart of Accounts.

• All financial systems have an operational component as well as a financial and HR component
  
• Each of these modules require certain mandatory accounts and you should find out when designing your chart of accounts what these are. Often people have already captured the chart of accounts and then when the other modules are brought on line they realise that they have left out mandatory Oracle accounts. Two key types of accounts need to be considered
  
  • Mandatory accounts – control accounts or those used for interfacing to the General Ledger as well as
    
  • Take on accounts – temporary accounts for purposes of take on.
    
• Are you using Budgets and at what level of detail are you going to budget? You might be using top down or bottom up budgeting and you should consider the impact that each of these has on the chart of accounts
  
• Also need to ensure that you obtain a summary of the information you require in the general ledger. i.e don’t replicate the information.
  

Third party interfaces and systems

Ensure your Chart of Accounts design considers the impact of third party interfaces and systems.

There are a number of entry points to Oracle Applications, most of the modules have interface tables that you can load your transactions into. One should have a comprehensive understanding of the interface architecture and how this impacts the chart of accounts.

Set of Books Infrastructure

Set of Books consists of your Chart of Accounts, Calendar and Functional Currency.

When each of these three is not the same then you set up your companies in a different set of books.

Even if your organisations do have different chart of accounts you should ensure there is some commonality so that any consolidation efforts are made easier.

Having a separate set of books entails setting up a multi-org structure.

Set of Books Infrastructure – Multi org

Oracle Statement per Appsnet

Oracle Applications strongly recommends that our customers convert to Multi-Org as soon as possible. We make this recommendation to prepare for improvements to performance across the E-Business Suite as well as to prepare for supporting Multi-Org Access Control, an upcoming feature of the E-Business Suite. Read the white paper Release 11i Use of Multiple Organizations in Oracle Applications for more information.

Oracle strongly recommends that you use Multi-org and there are certain steps that you have to run in order for this to be setup. These steps should be the first thing you do when setting up the system. Why, because it sets up the table structures in a certain way and if you don’t enable this option you face the possibility of having to re-implement. If you are on 11.5 you may have to enable multi-org if you have not done so.

Segments

• Definition – an area of analysis within your business.
• Recommend using 5-7 segments with a spare segment for future growth.
• Define each segment name and the order in which it appears in such a way that data capture is facilitated.

Define a segment. Tip : Keep number of segments to 5-7 and ensure that you have a spare segment for future growth.

Value Sets

What is a value set – it basically defines the format of your segment

• Length (Ensure that they are not to long – you need to consider the cumulative effect of no. of segments and value sets. Give an example of having a number of different segments with large value set lengths)
• Numeric and alphanumeric (Recommend using numeric for account and alphanumeric for product.)
• Security

Chart of Accounts Values

• Attach a list of valid values to each segment.
  • Child Values identify the specific components of a segment.
  • Parent Values define a hierarchy or summarisation of child values. (Make sure that you incorporate a hierarchy so that reports can include appropriate summarisation of data. Do you have to do a lot of juggling to get the information to show required levels of detail and/or summarisation. If so your hierarchies have probably not been designed well. Ensure that your hierarchy is not too complex. Include a high level summary account – I give it the number of 9999 which should come to zero. This will show that you have built a correct hierarchy.)
    
  • Ensure each a/c has appropriate categorisation Asset accounts, liability accounts, revenue, expense, owners equity. (This should be done so that information flows correctly into your reporting system, be it FSG,OFA or another 3rd party system)
    

Cross Validation

• Cross-validation rules let you control the combinations of accounts entered for particular segments.
• Example 1 – ensuring that for all income statement accounts a department is specified whilst for balance sheet no department is specified.
• Example 2 – Ensuring that for all revenue accounts a product is captured.
• The advantage is that posting errors can be reduced, however if they are two restrictive then posting errors will not be reduced. (Can affect your integration efforts if too complex, that is, your control accounts may be affected. Should be performed at the end of the implementation once users are familiar with the particular combinations.)

Security Rules

Allows you to create specific views for certain people

Should only be performed towards the end of your implementation when users are familiar with the overall design as well as their responsibilities. Not only does it prevent the users from only viewing certain information when they are capturing but it also prevents them from on line analysis of that information. Example of testing at NDB

Aliases

Allows you to develop names that are familiar to your organisation

Short aliases provide a way to speed entry of frequently used value combinations. This should only be used once the users are familiar with the common combinations they may use.

Statistical Accounts

This is rarely used but can be particularly helpful in organisations which have the requirement to report on statistical information in their financial statements or management accounts.

This information should be manually captured or interfaces into the GL.

• Dedicated Statistical Accounts. (What we normally do is create a range in the chart of accounts just for statistics. If an account cannot possibly have a monetary value then this is applicable)
  
• Shared accounts which contain statistical and monetary information. (You may want to look at combing accounts like sales which can have monetary and physical components attached.)
  

Constant Renewal

This is the 7^th habit of highly effective people

“There will come a time when believe everything is finished. That will be the beginning.”

Louis L’amour – Best selling Author.

• Although certain designs are permanent never be happy with your chart of accounts. Always look for improvements but maintain a balance.
• This applies particularly to large organisations where improvements can be made on cross validation, security rules and aliases.
• Make sure any changes are validated in test and then copied to production.

Chart of Accounts – suggested maintenance procedure

Often no procedures are established for maintaining a chart of accounts. This is one of the week points I have come across in most implementations, no control over who changes what and how to go about it. You should agree on such procedures in your initial workshops.

You can use workflow to automate this procedure which will ensure this is integration with E-mail and Apps itself. Alert can be used to inform users of any changes made at database level.

Identify Required Change to your chart of accounts values (may come through a change in reporting) or users may notice the need to create a new account .

Obtain Authorisation for Change (may be through one authority or in a meeting)depending on the level of complexity the users may not Significance high or low?

Notify Users

Make the change

Notify users

Update documentation

Additional Tips

• Data Loader for loading your data into Oracle (Data loader is a very useful tool for functionally skilled rather than technical people. Make the client responsible for loading their data.)
  
• Coding tips.
  • Ranges and coding.
  • Make sure you provide for growth.
  • Create meaningful patterns within the coding structure.
• Use the Oracle ADI Account Hierarchy editor for mass edits and Big Picture View (Use the account hierarchy editor within Oracle ADI to provide you with a hierarchical view of your chart of accounts and also to perform mass edits using drag and drop)

  

• Alternatively use the Account Hierarchy Manager in E-Business Suite found under GL Super User Responsibility>Setup>Accounts>Manager (Mention Setup Work in terms of Profile Options etc.)
  

  
  

• Use auditing tools to establish whether your setup is correct
  • CRM analysis tool (Set of Books, Chart of Accounts, Flexfield Structure, Calendar, Currency, Errors, References)
  • Demonstration