The ERP directorate at Prōject are consistently working with our clients to give best advice around business process design and re-engineering. As well as providing day-to-day Oracle E-Business Suite expert consultancy, Prōject consultants have worked on numerous projects that required significant restructuring to ERP systems and/or business models. These include numerous projects to restructure ERP system configuration following organisational change.
We also have vast experience with Chart of Accounts (CoA) design and redesign, covering many global implementations and upgrades across private and public sectors. It is this vast experience that has led me to document some key CoA design and best practice principles that should be considered when embarking on such a vital phase of an E-Business Suite project. CoA best design principles include consideration across a number of key areas and include:
- All CoA segments should support critical accounting aspects of the business without compromising the integrity and functionality that exists within other applications e.g. it would be unwise to add a segment to the CoA structure to hold customer names. Information in the CoA should not be repeated within other modules, likewise, sub-ledger detail should not be replicated in CoA
- The CoA structure and subsequent segment values should provide the business with reporting opportunities related to such critical business components in a logical and structured manner, without complex intervention or rework
- Each CoA segment should be designed with scalability in mind, ensuring that there is enough room for expansion within each segment to accommodate future values
- Each CoA segment should be flexible to accommodate changes within the business to ensure longevity of use without the need to re-implement
- The Accounting Key FlexField (KFF) should enable an organisation to comply with all relevant legislative, fiscal and taxation requirements and commitments encountered by the business
- Each CoA segment used within the structure should be designed to hold one type of information. Avoid having more than one meaning per segment, where each segment should retain its own dimensions e.g. combining department and location information into one segment is not recommended
- The Accounting KFF structure and resulting account combinations should provide clarity of the transaction with enough granularity for reporting. Detail should not be captured for the sake of it; the CoA design should be driven by clearly defined outputs
- Segments should contain discrete value sets that do not contradict other segments. For example, if a financial report is required by cost centre, the cost centre and natural account qualified segments should still remain independent. Logical and structured use of summary accounts can be deployed to achieve the desired effect of account balances by cost centre using FSG reports. Equally, report filters within the BI Applications will allow balances to be returned by single or grouped cost centres
- Once in use, the Accounting KFF structure cannot easily be changed. Changing segment values will also affect historical reporting and transactional data. Parent segment values, summary accounts and rollup groups can be changed at any time. However, all reporting and security must be impact assessed prior to doing so
- Allowing dynamic inserts is typically enabled for an Accounting KFF, this means that code combinations are created as transactions are entered. This prevents proliferation of code combinations which may never incur transactions. Cross validation rules will be required to avoid the creation of invalid combinations
- The Accounting KFF structure should be optimised for as few segments and combination of characters as possible, giving speed to transactional data entry without compromising flexibility, data integrity and reporting.
- When designing segment values one should avoid using special characters (both parent and child values) since these are more cumbersome for data entry and are more difficult to factor into value ranges compared to non-numeric values. Careful consideration of alpha characters is also advisable, if needed at all
- It is advisable to avoid numeric segment values starting with zero. When exporting data to spreadsheet tools such as Excel, leading zeros can often be removed
- Segment value ranges should fall naturally into summary accounts and rollup group definitions e.g. 5 -> 50 -> 500 -> 5000
- Natural account segment values should be prefixed numerically in accordance to the account type qualifiers so as to be instantly recognisable. A typical structure will include values starting with:
- 1% = Assets Accounts
- 2% = Liability Accounts
- 3% = Ownership/Stockholders Equity
- 4% = Revenue Accounts
- 5-9% = Expense Accounts
- The definition of full and whole numbers for the lowest level of segment values used for transactional recording should be avoided, e.g. a natural account value of 11000 should not be used for transactional data but maybe useful as a parent value
- Segment value lengths should be optimised for data entry
- Segment values should include sensible ranges or gaps for future inserts e.g. increment natural account codes by 10
- A single spare/future segment is recommended. The need for any more may indicate further design consideration is required although it is not uncommon to see two spare segments within a CoA
- Segments that have default values or values that do not always have to be entered are ideally located towards the end of the account structure e.g. Company segment in a business with one legal entity, ledger and operating unit
- When defining parent values, the use of “levels” can offer an alternative search capability for grouping
- Parent values or values defined for summary accounts should not be set to allow posting and budgeting. Posting should occur at the lowest level only
- Appropriate use of data access sets, security rules and cross validation rules should be considered in complimenting the CoA design
- Indexes should be created against segments that are expected to have many distinct values
- Dependent value sets may be required. For example, where account and sub-account segments exist, the sub-account segment values are dependent on values from the account segment and should be filtered for data entry accordingly. This would ideally be reflected within the CoA by using a dependent sub-account value set. Should no dependency exist, the appropriate use of a correctly structured account hierarchy is advantageous
- By using well defined parent-child ranges any newly introduced values will automatically be picked up and inserted into the relevant hierarchies
- Rollup groups can be defined to identify a group of parent values for reporting
- FSGs and other reports should be easily created as a result of CoA design. To reiterate, CoA design should be predominantly driven by outputs
