• Local versus global
  Address whether a single CoA or multiple CoAs are needed, depending on how the business is run. Whereas a global CoA might mean streamlined consolidation and consistency in reporting, a local CoA may mean fulfilling local statutory requirements through general ledger (GL) only, “local” user productivity, etc.
• Organizational operations
  Analyze the trade-off between flexibility and complexity. Depending on the situation, a flexible global CoA could create unwanted segments for the entity, whereas different CoAs for every legal entity may increase complexity during consolidation.

The CoA design should reflect the organizational structure (i.e., how the business is run). This will increase decision-making capabilities; provide a single source of financial data for financial, operational, and management reporting; and enable increased automation.

• Statutory, management, and operational reporting
  The ledger should be designed to accumulate data in a way that supports your reporting requirements. Understand the final output that is required from this design, including statutory or external reporting and internal management reporting requirements. The design should support legal, business unit, management, and statutory reporting needs.

  Think through local requirements during global design iterations to address statutory and regulatory reporting considerations that affect country-specific CoAs (e.g., what US jurisdictions need to be reported on a national, state, and local tax reporting basis? Are there other industry-specific regulations to be considered? Based on local legal requirements, do we need to use alternate CoAs or country-specific ledgers?).

• Thick versus thin GL
  A thick GL caters not only to financial reporting needs, but also to the management and operational reporting needs of an organization; a thin GL is used only to capture data for financial reporting. Thus, a thick GL requires a larger CoA.

  Optimize GL segments through streamlining and standardization. Enhance the use of other available master data components to reduce the “noise” in the GL and enable a “thin” ledger. If the value of a segment can be derived from another, then it should not be a unique segment.

• Designing the CoA
  Consider the CoA’s ability to enable the organization to make data-driven decisions; provide a single source of financial data for financial, operational, and management reporting; and increase opportunities for automation.
• Ease of access and data security
  The structure should not be too large to demotivate users to enter values. The values should be coded to allow users to identify their meaning. Design values such that it is possible to impose access to certain financial reports or balances.
• Presence of legacy systems and data conversion
  Every system has its own way of capturing data and generating reports. If legacy systems are not phased out during the ERP implementation, you need to consider data conversion efforts, such as if conversion strategy will be able to provide data at the detail required by the ERP if the legacy system captures it at a summary or more detailed level.

All values related to a specific segment should be uniformly defined and considered to be like-type. Specifically, when designing GL account values and natural account segments, consider:

• How can we design account values to align with financial statements and disclosure requirements?
• What are the appropriate account naming and numbering conventions to support the buildout of financial hierarchies for reporting? How many digits should each value be?
• What types of values should comprise our data objects (i.e., alphanumeric versus numeric)?
• Are account values common across the entire chart or specific to a line of business, country, or other technical requirement?
• Should we create specific account values to capture US GAAP, local GAAP, and IFRS® requirements?

• CoA design should be scalable to meet the existing and future needs of all entities and countries. For example, segments should contain enough digits for future value list growth, and the design should be flexible to accommodate reorganizations, acquisitions, and other business changes.
• What are the appropriate account naming and numbering conventions to support the buildout of financial hierarchies for reporting? How many digits should each value be?
• Consider alignment with longer-term IT strategy.

• Hierarchy and rollup
  The grouping and structure of a CoA should be aligned to the business model to enable statutory and reporting requirements. Use number ranges for GL accounts to identify multilevel account hierarchy. CoA values may be arranged into hierarchical, rollup, or parent relationships. This means that values can be summarized and totaled together based on grouping. For example, “total revenue” may be a parent value that summarizes all the values that capture more granular types of revenues.
• Budgeting
  If the ERP will be used as a system to impose budget constraints on transactions, budgeting requirements must be captured during CoA design (i.e., if you budget for expenses for every department for a year and “department” is not a segment in the CoA, then you will not be able to impose budgets on transactions. You cannot budget at a lower level than your CoA).
• Consolidation
  If there is a need for consolidation, depending on the CoA structure of various entities, you may require a different CoA for the consolidation books. If your reporting needs can be met using the existing CoA, the same CoA can be used; otherwise, there may be a need to create a new CoA for the consolidation book and perform mapping between two CoAs to derive accounting for the consolidation books and bring balances therein.