As a Chief Financial Officer, you need your finance team to process and report financial data effectively. As your business evolves in response to market, regulatory, and strategic challenges, your enterprise structure will change. Departments, cost centers, and countries will be rolled up differently to reflect the way that your legal and operational entities are organized. Your finance team therefore must report on the new structures easily whilst tracking key changes.

This blog focuses on how account hierarchies in Oracle Cloud General Ledger (GL) helps address those business needs.

You can define account hierarchies in GL to address reporting and operational requirements as your business evolves.

Account hierarchies:

  • Are a way of structuring a complex organization into parent-child relationship within Chart of Account segments, referenced as Trees. It is generally used to break down locations, departments, or any other function of the company.
  • Support organizational changes and reporting without upheavals to your detailed operational entities (departments, offices, etc.).
  • Enable multiple parallel and alternative ways of measuring the financial state of the business.
  • Facilitate before and after and what-if analysis of re-organizations.

 

DecorativeAccount hierarchies utilize tree functionality. Trees are hierarchical data models that you configure to organize data, apply business rules, control data access, and improve performance for processes and reports. Use the seeded Accounting Flexfield Tree Structure. Each account hierarchy consists of a tree with one or more versions. Use tree versions to track account hierarchies as they change over time.

 

Figure 1 displays a screenshot example of Manage Trees and Tree Versions UI. It shows a Tree named All Canada Accounts for Tree Structure GL_ACCT_FLEX. The Tree is defined with two Tree versions: version V1B with effective start and end date from Jan 1 2020 to Feb 1 2020, and version V1C with effective start date of March 1, 2010 and no end date.
Figure 1 Example of Tree and Tree Version Definition

For example, an account hierarchy to summarize cost of goods has different accounts for 2022, versus 2021. Business operations change and affect the chart of accounts values. The new 2022 account hierarchy will allow you to restate 2021 and 2022 results.

Figure 2 displays an example of a screenshot of Manage Trees and Tree Versions: Specify Nodes UI. It illustrates the hierarchy for Cost of Goods Sold accounts between top
Figure 2 Example of Tree Version V1C with Nodes Illustrating Hierarchy for Cost of Goods Sold Accounts

 

 

Decorative

Associate chart of accounts values with multiple hierarchies by defining multiple trees. If you define multiple trees, you can create financial reports for different target audiences. For example, you can use different account hierarchies to track cost centers either by geography or line of business.

 

Figure 3 displays an example of a screenshot of Manage Trees and Tree Versions: Specify Nodes UI. It illustrates the hierarchy for Cost Center segment values between top nodes and down several levels to child node cost centert values within the All Canada Accounts Tree.
Figure 3 Example of Tree Version V1C with Nodes Illustrating Hierarchy for Cost Centers

 

Optimize account hierarchies for reporting, inquiry, and allocations

Decorative

Consider hierarchy requirements for financial reporting, inquiry, and allocations. Account hierarchies for these must be published to Essbase and hence are subject to some additional limitations.

 

Best implementation practices

  • Configure your account hierarchies for optimized performance for Reporting (FR Studio, Smart View), Inquiry (Detailed Balances, Account Inspector) and Allocations. General Ledger pre-calculates balances based on account hierarchies. This optimizes reports to run faster, as they don’t need to sum up all child nodes at runtime.
  • You must publish account hierarchies to Oracle Essbase when they are used in financial reporting, inquiry, and allocations. Prior to publishing, ensure you run online audit of each tree successfully. Change tree status to active and run the flatten rows and columns. This way you ensure data validity and improved report performance once trees are published. 
  • You can submit Process Account Hierarchies job to automatically run the required steps to process account hierarchies updates. 
  • Any account hierarchy published to Essbase cannot have a single child value roll up to multiple parents. If you need a single child value roll up to multiple parents, you must define multiple account hierarchies. 
  • If you need multiple account hierarchies, we recommend you define them using multiple trees.
  • General Ledger changes the way that segment value names appear on reports and inquiries if it encounters two values that are the same, even if they are in different COA segments. To ensure that names remain stable over time, we recommend that two versions of each account hierarchy are created upfront.
  • If there is a single version of a hierarchy, each member’s name is the segment value. When a second version of the hierarchy is created, the segment names are no longer unique. Therefore, Essbase changes the names to the fully qualified member name to guarantee uniqueness. If any financial report or Smart View has been built using the unqualified member name (the segment value), it will fail. Hence, best practice is to always define at least two account hierarchy versions. This ensures that the fully qualified member name is always used and therefore, financial reports and Smart View inquiries will not break.
  • Use meaningful names for account hierarchies so your users understand them, such as ‘base line’ versus ‘current’.
  • A single account hierarchy must contain no duplicate members. This means you can’t include a segment value more than once in an account hierarchy.
  • Create multiple hierarchies for different purposes.  For example, the hierarchy for Reporting does not necessarily align with the hierarchy for Allocations. Though note, there is a trade-off. The more account hierarchies you define, the more maintenance there will be. Only add hierarchies if they serve a purpose. If one account hierarchy can serve two purposes, then all the better.
  • Use hierarchy versions to maintain audit history, if desired.

Design account hierarchies needed for Revaluation, Cross-Validation Rules, Chart of Accounts Mapping and Segment Value Security

Account hierarchies you create for reporting or allocations may not be suitable for operational aspects. Operational revaluations, cross-validation rules (CVRs), and chart of accounts (COA) mapping rules will usually require a different account hierarchy.

Decorative

For example: You enforce a cross validation rule that a set of 20 departments is applicable only to a certain company. You then group the 20 departments under a hierarchy node and refer to that hierarchy node in the CVRs. This rule may not apply to your financial reporting and allocations.

Best implementation practices

  • You can use only a single account hierarchy for each segment for the operational features revaluation, CVRs, and COA mapping. 
  • Associate the account hierarchy with a chart of accounts instance. You can only associate one hierarchy with a COA instance. Also, only one hierarchy per segment. 
  • Note that while multiple parents are not supported for published hierarchies, they are supported for unpublished hierarchies (associated with the accounting flexfield segment). This means that hierarchies with multiple parents are supported for the purposes of revaluation, CVRs, and COA mapping.
  • If you change the hierarchy (tree code) assigned to the COA segment, you must redefine existing CVRs and Revaluation. This is because they used the old tree code.  You cannot use a different tree code for the segment for existing CVR and Revaluation. Instead, you can change the roll up of the tree code.
  • You can record the primary account hierarchy along with the COA segment values if you use a rapid implementation spreadsheet.
  • If you use only one hierarchy for Revaluation, Cross-validation rules, and COA Mapping, you may require duplicate members in the hierarchy.  You can only do so for unpublished account hierarchies.
    • For example,  duplicate members are necessary for Revaluation and Cross-validation rules as the same child values roll up to different parent values for multiple purposes.    In this scenario you need to use an unpublished hierarchy as the Tree Code. This means you’re not publishing the account hierarchy to Essbase as it is not needed for reporting, allocations, or inquiry. If unpublished, those hierarchies won’t appear in the list of values of trees. So, when defining and running reports, inquiries, and allocations those trees are not visible.
  • Segment Value Security, however, allows you to select a version from either a published or unpublished hierarchy. 

Learn more with the white paper refer to Oracle Cloud Support Knowledge Base: Oracle Fusion General Ledger Hierarchies: Recommendations and Best Practices (KB159347).

Manage Account Hierarchy Changes

You can manage and visualize account hierarchy changes centrally with Oracle Cloud Enterprise Data Management (EDM). Decide on your COA governance needs. Then collaborate with other reviewers and route changes to approvers within EDM. Once approved the EDM changes are synchronized with Oracle Cloud ERP account hierarchies.

Conclusion

Use GL account hierarchies to support your operational and reporting needs as your business grows. Identify your use cases and map to account hierarchies and related trees. Implement account hierarchies and test your operational processes and reporting. 

Define your COA governance strategy. Use EDM as a powerful tool to manage and track account hierarchy changes. Test and document your governance approach.

Finally, validate that your setup supports the required financial reporting for your business as it evolves.