coa design executive summary

ERP Chart of Account Design Executive Summary

Chart of Account DesignGoals and Benefits

2

Project Mission

Hertz is planning to implement a global instance of Oracle Financials and included in the scope of this project is the design of a new Chart of Accounts. The fundamental objectives for the new Chart of Accounts (COA) is to create an environment where the compilation and analysis of meaningful Hertz-wide information is efficient, data is standardized, and data is granular but yet can be rolled up into hierarchical structures. It will be flexible, scalable to address the required level of detail and will not contain duplicate or redundant data.

Benefits of a Well Designed COA

• Business Transformation – Improved financial analysis, making Hertz’s financial information more transparent; improved visibility into operations; and generated savings by streamlining administrative process.

• Enhanced Controls – Improved internal controls, moving away from investigatory and manual approaches to those that are more preventative and automated.

• Improved Hertz Reporting and Compilation of Data – Improved reporting and tracking capabilities at all levels; enhanced analysis and comparability across business units, management units and fiscal periods.

• Reduced Duplication of Effort – The new COA should decrease time and eliminate the effort associated with the current systemic data work-arounds in use, making accounting and reporting operations more efficient and eliminating most of the mapping/translation tables.

Overview of Program

• Hertz is planning to implement new Oracle financial systems. Defining and standardizing the Accounting Structure, which includes chart of accounts, functions, locations, legal entities and other dimensions, is a necessary pre-requisite to the systems implementation work.

• The existing Accounting Structure reflects an amalgamation of data elements driven by legacy requirements of diverse businesses and their systems. These have evolved over time due to an open governance process and lack of a singular, corporate-wide strategic vision.

• Complex mapping rules and manual interfaces must be maintained to enable legacy systems to share data.

• Aggregating and analyzing information is challenging for Hertz at an enterprise level. Without a commonly defined, lean set of financial code block elements, creating reports from multiple system is cumbersome. There are examples of differences in usage of the Account dimension between US and European operations during planning and forecasting processes.

There are several reasons driving the need to redesign Hertz’s Accounting Structure and other Accounting String elements (also known as the Code Block).

3

Chart of Account DesignDrivers for Change

Overview of Program

4

Guiding Principle Explanation

Align the language with the way management wants to run the business

• The language must support the key business objectives of the organization.

Simplify the set of codes• In legacy systems, many codes provide the same information resulting in

redundancy and inconsistency of values. In the new design, this redundancy is removed.

One code / dimension to answer one business question

• The language enables the capture of data in basic elements that answer 7 fundamental business questions (“who, what, which, when, why, where, how”) Views of data are supported through combinations and of the basic elements.

Non-Intelligent/Non-Hierarchical Codes

• Designing intelligence into a code restricts the number of values which the code can support and increases the amount of data input.

• Hierarchies should not be included in the code block itself . When roll-ups are required, these should be derived by the reporting mechanism and not be embedded in the language. FDM and DRM will support hierarchical structures outside of the actual ERP system.

Support flexible, user-definable rollups

• End-user tools which allow the user to define ad-hoc roll-ups should be provided.

A first key step in designing the Chart of Accounts is to define a set of guiding principles to channel decisions throughout the project. The examples below illustrate the behavior of high performing companies and their approach to Chart of Account design:

Chart of Account DesignGuiding Principles

Guiding Principles

5

Chart of Account DesignGuiding Principles

Guiding Principles

Data

Chart of Accounts

and Hierarchy

Financial Reporting

• US GAAP

• IFRS

• Local GAAP

Performance Reporting

• Planning/budgeting

• EVA

• etc

Tax Reporting

• Planning

• Compliance

• Defense

Treasury Reporting

• Hedging

• Liquidity Planning

Book vs. tax differencesCash vs. accrual differences

External vs. internal differences

Statuto

ry require

ments

• Multi-org structure

• Cost Centers

• Segmentation

• Product

• etc

Transactions will be entered into the system once and will meet the requirements for all reporting. Data integrity, reporting transparency, and single version of the truth will result. In addition, reconciliations will be reduced.

6

Based on our experiences, the following exemplify the leading practices demonstrated at high performing companies:

• Single chart of accounts, used consistently across the entire organization and all systems

• Consistent data definitions and hierarchy structures

• Develop the Chart of Accounts within delivered ERP functionality

• Appropriate data elements to support transaction recording and profitability/cost analysis.

• Capture data at the lowest level required for reporting and analytical purposes in the appropriate application

• Create a scalable solution to allow for acquisitions and other corporate growth

• Use a standard Code Block for all legal entities to facilitate consolidations and eliminations.

• Consider the impact of proposed Code Block on data entry. Minimize key strokes at data entry where possible and have maximum visibility on single window.

• Code block must be easily auditable.

• Keep the transaction system views in the subsidiary ledgers, not in the general ledge

Chart of Account DesignLeading Practices

Leading Practices

Thin vs. Thick General LedgerData Dimensions

Basic Financial(Legal / Statutory)

Basic Financial(Legal / Statutory)

Business Analytics(Management)

Business Analytics(Management)

Thin Thick

Representative Data Structure Elements:

Information Types:

Legal Entity

Natural Account

Cost Center (location – Management Entity)

Intercompany Legal Entity

Transaction Type

Function (COE)

Operating Unit (Airport, Off Airport, Car Share, Advantage)

Customer Segment

Project ID

Product Group / Collections

Asset Class

Future Use

Thick Ledger – Ledger dimensions extended to support detailed analysis and external reporting

Utilized as central data model, staging, and reporting construct

Supports detailed legal, statutory, internal and external reporting and analysis

Thin Ledger – Minimal ledger dimensions to support legal entity and statutory requirements

Minimal data to support “Record to Report” concept

“Mission Critical” operational design

7

Leading Practices

Data Structure Elements:

Legal Entity

Natural Account



Transaction Type Function (COE)

Asset Class

Operating Unit (Airport, Off Airport, Car Share, Advantage)

Customer Segment

Project ID

Product Group / Collection

Future Use

Option 1:

Legal Entity

Natural Account



Future Use

Option 2:

Legal Entity

Natural Account



Transaction Type Asset Class

Function (COE)

Project ID

Product Group / Collection

Option 3:

Legal Entity Natural Account Cost Center (location – Management

Entity)

Intercompany Legal Entity Transaction Type Function (COE) Asset Class Operating Unit (Airport, Off Airport,

Car Share, Advantage) Customer Segment Project ID Product Group / Collection

Thin vs. Thick General LedgerRecommendations

Thin Thick

Leading Practices

8

Chart of Account DesignAccounting Flexfields (General Ledger)

9

• The Oracle Accounting Flexfield (reporting key) is used to post accounting transactions in Oracle GL.

• It is a data model used to capture and analyze business transactions in the Oracle Accounting Ledgers according to business and statutory requirements.

• Comprised of multiple segments, as shown above

• A value set is the list of values for one segment, such as the list of Legal Entities. Segment values are numbers or codes within each segment, such as Legal Entities 001 and 002 or Natural Accounts 4100 and 5100.

• A combination is one full accounting Flexfield with all segment values• Values are stored as numbers, but can/will be translated to alphas in the reporting solution• Example Flexfield string:

001 – Hertz Worldwide

Legal

Entity

Legal

EntityManagement

Entity

Management

EntityNatural

Account

Natural

AccountIntercompanyIntercompany Future

Use

Future

UseFuture

Use

Future

Use

Accounting Flexfield Structure

001.24600.1285.060.55.000000

Technical Architecture

Chart of Account DesignSegments

10

Legal

Entity

Legal

EntityManagement

Entity

Management

EntityBusiness

Line

Business

Line CustomerCustomerProductProduct FunctionFunctionNatural

Account

Natural

Account

Segment Segment Segment Segment

Example Accounting & Reporting Segments

• Segments are individual dimensions that define the characteristics of the reporting key.

• Segments define how you transact and report both fiscally and management reporting purposes.

• Reporting hierarchies can and will be established in each segment by defining Oracle parent-child relationships

• An example of this would be a Natural Account that can be drilled down on to view the accounts that are summarized into that Natural Account.

• The combination of segments can include cross-validation rules. Cross validation rules define whether a value of a particular segment can be combined with specific values of other segments.

• An example of this would be a RAC Management Entity cannot be combined with a specific HERC account

• In Oracle, there are mandatory segments that must be setup to allow accounting transactions to be processed.

• Some of the above segments will not be contained in the GL code block, per se. They will be attributes of the data and derived based on pre-determined relationships and/or hierarchies

Future

Use

Future

Use

Segment Segment Segment Segment


IntercompanyIntercompany Future

Use

Future

Use

Segment Segment

GL GL GL GL GL GL Reporting Reporting Reporting Reporting

XXX . XXXXXX . XXXX . XXXXX . XXX . XX . XXXX

IntercompanyManagement Entity

Legal EntityNatural Account

Future Use

27 characters (7 data fields)

11

Chart of Account DesignFlexfield Structure – Decomposition of Design


100 . 235000 . 4050 . 40505 . 000 . 00 . 0000

Hertz Corporation RAC . Downtown Dallas . Vehicle Maintenance . Car Maintenance . 000 . 00 . 0000

Technical Structure

Example String

Translated

Future Use

Sub Account

12

Chart of Account DesignTarget Architecture


Chart of Account Design Integrated System ArchitectureLeading companies deploy a system architecture that features a seamless integration of all components, from the transaction level detail to consolidated statutory reporting.


13

The new COA design is based on new Oracle ERP technology Hertz will implement in the near future. The functionality the new Oracle ERP introduces allows Hertz to expand the depth of information it can capture and utilize for decision making purposes:

14

• Flexfield String: Segments make up distinct Flexfield strings. Reporting is a matter of combining different segments of the Flexfield string to pull the required data.

• Hierarchies: Each segment can be rolled into a relational structures (hierarchies). Hierarchies enable high and low level reporting. (Legal, Management, Operational, Geographic)

• Maintenance: Each segment has a distinct definition. Requests for new segment values need to be evaluated against the definition to ensure they are in the proper segment. Segment values may be in wide ranges to allow easier hierarchy maintenance.

• Commitment Control: Budgeting is done at multiple levels for multiple audiences. The flexibility of the Flexfield string allows for robust budgeting.

• Accounts: An account structure will be utilized that will include hierarchal structures. Natural Accounts most often are summary level accounts. Sub Accounts are at the lowest levels and are the segment values.

• Standardized Entries: The ERP system will systematically require standardization of data entries into the new segment values.

Chart of Account DesignKey Changes


Chart of Account DesignKey GL FlexfieldsHertz COA design is driven by financial, management and regulatory data requirements. A flexible COA design is necessary to satisfy all requirements.

15

COA Segment

Legal Entity Management Entity Natural Account Intercompany Future

Usage Who owns it? Where (physically or logically) do transactions occur?

What is the nature of the transaction?

With whom did we do business internally?

Reserved for future needs as may be required

Definition / Parameters

• Properly defined Legal Entity for statutory reporting purposes

Measurement and control of a unique set of revenues and/or costs (e.g., locations) Lowest level of detail is Cost Center (e.g. locations)

Measurement of financial transactions of a unique nature (e.g., assets, liabilities, revenues, expenses) Generally used to support the preparation of statutory reports & management reporting

Facilitates intercompany transaction identification and reconciliation

Allows flexibility to adapt to future data needs as may be required

Comments May also represent a non-legal entity if, for all intents and purposes, that organization acts and has the same requirements, e.g., fully balanced set of books, as a Legal Entity May also represent a consolidating entity as required for consolidation purposes

Each Management Entity should have one and only one designated owner Management Entity will generally only relate to P&L accounts for transaction purposes. May be used with balance sheet accounts to facilitate reconciliations and adequate internal controls To be defined at the lowest level at which you want to measure and manage revenues and/or costs

Natural Accounts are typically defined at the minimal level of granularity required to meet consolidated statutory (e.g., US GAAP) reporting requirements Additional granularity may be defined, e.g., local statutory or tax to meet other requirements

Intercompany segment is only relevant when a transaction crosses two or more Legal Entities Intercompany segment will only be populated for intercompany balancing accounts

Although Future segments are rarely ever implemented in practice, it is a leading practice to include them as a risk mitigation factor


Chart of Account DesignKey GL FlexfieldsHertz COA design is driven by financial, management and regulatory data requirements. A flexible COA design is necessary to satisfy all requirements.

16

COA Segment

Business Line Product Function Customer

Usage What part of the business? What was the source of revenue/expense?

What is the nature of the revenue/expense?

Whom was the source of revenue/expense?

Definition / Parameters

• Represents the strategic business function within the organization, regardless of Management Entity structure(s)

Measurement and control of a unique set of revenues and/or costs by Hertz products Facilitates an in-depth understanding of key business drivers

Represents a departmentalized view of Hertz internal role groupings

Segment utilized to identify key customer attributes or logical groupings (programs, demographics, etc.) for management and financial reporting

Comments Quickly and easily identify performance of key business functions Ability to segment performance without increasing the scope of the Management Entity structure Business Line will function as an attribute of locations (cost centers) and can be viewed in the same hierarchal structure

Capacity to report separately on product performance for management and financial reporting Product segments would be fashioned in a hierarchal format for detailed to summarized views of performance

Intended to mirror the current use of Centers of Excellence (COE)Capacity to report separately on Function performance for management and financial reporting Capacity to perform trial balances by function

Customer level detail and specifics to be maintained in the data warehouse Capacity to report separately on demographic and/or promotional performance for management and financial reporting


17

Level 8

Level 7

Level 6

Level 5

Level 4

Level 3

Level 2

Level 1

Level 0

Section

Location

RAC Americas

Country

Region

Zone

Pool

District

Location

RAC Americas

Country

Region

RAC International

Europe

Region

HERC WW

Country

Region

Zone

Pool

District

Section

Location

RAC Other Intl Americas

Country

Pool

District

Section

Location

Zone

Pool

District

Section

RAC International

APAC

Country

Region

Zone

HERC Americas

Section

Location

District

Pool

Management Entity structures vary across organizational and geographic areas of the corporation. The following structures are recommended to bring the various organizations and geographies in order to facilitate a common management structure and language.

Chart of Account DesignManagement Entity – Global Structures


Appendix

18

Appendix

19

Topic/Description Consideration

Thick Versus Thin Ledger • An organization’s reporting requirements and strategy will influence the amount of detail that is stored in the General Ledger

• Assess transaction volumes and batch processing requirements

Security and Data Validation • Security can be configured at the lowest level (I.e., account) or a business unit or legal entity level

• Data validation should be controlled at the source. Rules should be used to validate individual segment or Flexfield values as well as account combinations

• Legacy system interfaces may need to be custom built

Reporting Requirements • Access the needs for standard, canned reports versus ad hoc analysis• Determine the different types of account rollups that will be used for reporting and

analysis• Drill down capability back to transaction level details, including scanned images

provides more detail for analysis• Determine how budget and forecast information will be integrated with actuals

Workflow • Determine which method is the most efficient for journal entries• Consider the use of materiality thresholds and automated approvals and postings• Review features to automate accruals or journal entry• Use automated inter-company processing to manage the flow of data between

entities • Determine process for handling suspense

Before configuring the general ledger, certain key implementation topics must be addressed and the decisions will become inputs to the configuration.

Detailed Design Considerations

Detailed Design Considerations

Definition and Purpose: The Legal Entity for which financial statements are produced. Tax and statutory requirements define the Legal Entity structures

Required in ERP system(s):Required for Hyperion Planning:

YesYes

Proposed Length / Format: 3 / Numeric

Examples: Hertz Global Holdings Inc., Hertz New Zealand Holdings Ltd.

Tracked in ERP: Only one legal entity in ERP per regulatory locations, other entities are tracked as business units / management entities in the ERP ledger

Key Impacts: • Legal Entity will default on all transactions and can be changed as needed

• Legal Entity will be required on all GL entries• Each Legal Entity can be maintained in its own business unit

Benefits: • Ability to report separately on Legal Entities for management, financial, and compliance reporting

• Ability to report in native currency for country-specific reporting requirements and in US dollars for consolidation

• Ability to consolidate legal entities as needed• Secures data by business unit

Segments in the Proposed COA:Legal Entity

Proposed Segments

20

The Management Entity represents the business unit operating structure within Hertz. Management Entity contains the cost center and profit center structures, usually physical locations.

21

• Intended use of Management Entity:

• Consolidation segment of all Hertz cost centers

• Cost centers are best defined as locations (RAC, HERC, etc.). Cost centers in the structure also reside at the corporate level.

• Cost centers (locations) reside in a hierarchal format. The hierarchy will consolidate cost centers into Profit Centers, Pools, Zones, Regions, Countries, etc.

• Current hierarchies differ slightly between Business Units (RAC/HERC) and geographies. Where possible, efforts should be made to enforce congruency.

• Changes to hierarchies structures could result in realignment of management structures

• For specialized or custom management and reporting purposes, remaining segments should be utilized.

• Excluded from Management Entity segment:

• Operating Unit structures built for specialized reporting needs (airport, off airport, etc.)

• Accounts

• Intelligent coding built in for specialized cost center use

• Specific transaction activity (e.g. locations for posting advertising spends)

Chart of Account DesignManagement Entity

Proposed Segments

Segments in the Proposed COA:Management Entity

Definition and Purpose: The Management Entity represents strategic business units within Hertz. Management Entity contains the cost center and profit center structures, usually physical locations, in a hierarchal format.


YesYes


Examples: Corporate cost centers, RAC locations, HERC locations, Advantage, HCM, RAC Car Sales, RAC Car Share, Zones, Pools

Tracked in ERP: Only one Management Entity configuration in ERP system.

Key Impacts: • Management Entity will default on all transactions and can be changed as needed

• Management Entity will be required on all GL entries• Each Management Entity can be maintained in its own business unit

Benefits: • Capacity to report separately on Management Entities for management, financial, and compliance reporting

• Ability to consolidate Management Entities as needed• Secures data by business unit• Reduces need for strategic business unit specific accounts• Reliance on other segments to achieve specialized reporting (e.g.

off airport) rather than introducing the intelligence into the hierarchy

Proposed Segments

22

The Business Line represents the strategic business function within Hertz. Business Line is associated with a physical operating location and allows for performance reporting of specific sets of locations, regardless of Management Entity structures.

23

• Intended use of Business Line:

• Quickly and easily identify performance of key business functions

• Ability to segment performance without increasing the scope of the Management Entity structure

• Business Lines will function as an attribute of locations (cost centers) and can be viewed in the same hierarchal structures

• An example would be viewing performance of off airport locations without having to specifically identify locations deemed as off airport. Views of off airport locations can be viewed at all levels of the Management Entity hierarchy, such as pool, zone and regional performance.

• Forgoes the necessity to group individual locations within the Management Entity hierarchy in order to view specialized rollups

Chart of Account DesignBusiness Line

Proposed Segments

Segments in the Proposed COA:Business Line

Definition and Purpose: Operating Unit is a strategic business function within Hertz. Operating Unit is associated with a physical operating location and allows for performance reporting of specific sets of locations, regardless of Management Entity structures


YesYes


Examples: Airport, Off Airport, Advantage, HES, Leasing, Car Share, Sales

Key Impacts: • Quickly and easily identify performance of key business functions• Ability to segment performance without increasing the scope of the

Management Entity structure• Operating units will function as an attribute of locations (cost

centers) and can be viewed in the same hierarchal structures

Benefits: • Management and performance reporting has the ability to view specific operating/performance segments without individually choosing locations

• Management and performance reporting can view specific performance segments within the define management structure hierarchies (Profit Centers, Zones, Regions, etc.)

Proposed Segments

24

Segments in the Proposed COA:Customer

Definition and Purpose: The Customer segment would be utilized to identify key customer attributes or logical groupings (programs, demographics, etc.) for management and financial reporting.


YesTBD


Examples: Commercial, Discretionary, Government, Replacement, Tour, Construction, Industrial, Fragmented

Key Impacts: • Customer Segment will default on all transactions and can be changed as needed

• Customer Segment will not be required on all GL entries• Customer Segment definitions will be maintained at a corporate

level• Customer level detail and specifics to be housed in the data

warehouse

Benefits: • Capacity to report separately on demographic and/or promotional performance for management and financial reporting

• Customer Segments would be fashioned in a hierarchal format for detailed to summarized views of performance

• Linkages established between Data Warehouse and reporting solution

Proposed Segments

25

Segments in the Proposed COA:Product

Definition and Purpose: The Product segment represents views of Hertz products grouped in logical arrangements to facilitate in-depth understanding of business drivers


NoTBD

Proposed Length / Format: 5 / Alpha Numeric

Examples: Cars, Vans, Air, Cranes, Electrical Material Handling

Key Impacts: • Product Segment will default on all transactions and can be changed as needed

• Product Segment detail will be contained in the Sub Ledger accounting modules

• Product Segment definitions will be maintained at a corporate level

Benefits: • Capacity to report separately on product performance for management and financial reporting

• Product Segments would be fashioned in a hierarchal format for detailed to summarized views of performance

Proposed Segments

26

Segments in the Proposed COA:Function

Definition and Purpose: The Function represents a departmentalized view of Hertz internal role groupings.


YesTBD


Examples: Finance, Human Resources, Technology, Marketing, Sales

Key Impacts: • Function will default on all transactions based on user profile & Account/Management Entity provided

• Function will not be required on all Sub Ledger entries• Function detail will be contained in the Sub Ledger accounting

modules• Function definitions will be maintained at a corporate level

Benefits: • Capacity to report separately on Function revenues/expenses for management and financial reporting

• Capacity to perform trial balance by Function

Proposed Segments

27

Segments in the Proposed COA:Natural Account

Definition and Purpose: The Natural Account is used to transact and report on financial statement classification of a transaction (Asset, Liability, Net Assets, Revenue, Expense)


YesYes


Examples: Current Assets, Liabilities, Shareholders Equity, Revenue, Expenses

Key Impacts: • No intelligence built into accounting hierarchy. All required attributes captured by other dimensions.

• Required GL Segment (along with LE & ME/CC)• Globally defined account reporting segment values across the

company• Simplify naming and number of segment codes for transactions• Allows for posting summary transactions to the GL and maintaining

detail level transactions within the Sub Ledgers

Benefits: • Eliminates the need allocation, transfer, and accrued expenses at the sub-account level.

• Enterprise-level account reporting• Provides an opportunity to organize and rationalize Account

classifications with logical account ranges that are well understood across the enterprise

• Enforces consistency and reduces redundancy • Improved data and reporting quality

Proposed Segments

28

Definition and Purpose: The Future segments are a placeholder to allow the definition of an additional dimension in the future. The values will default to 00 / 000 when not in use.


YesTBD

Proposed Length / Format: 2 & 3 / Numeric

Examples: Could be used for specific compliance related reporting (SOX, Foreign GAAP, IFRS) or for future strategic growth,

Tracked in ERP: Future - Yes

Key Impacts: • It is considered a best practice to define at least one future segment. Oracle segments cannot be added once implemented.

Benefits: • Allows for increased reporting flexibility based on strategic company decisions.

Proposed Segments

29

Segments in the Proposed COA:Future Segment

coa design executive summary

Technology

new design

improved hertz reporting

reporting operations

capture of data

data input

data integrity

redundant data

views of data