Finit - All Things Chart of Accounts

All Things Chart of Accounts

Considerations when developing an application’s chart of accounts

June 10, 2016

Matt Spencer

Why is Finit here?

Finit takes pride in being a company of makers and doers; people who dig

in and get their hands dirty

To deliver personalized financial reporting solutions and experiences

…Not Company to Company, but Person to

Person

By listening, questioning, and analyzing

Finit Culture

Slide 3

No debt or external ownership means complete alignment & focus on our client’s needs and vision

We bring a quality of craftsmanship to our designs and execution that lead to solutionsthat are functional, usable and efficient

We actively seek feedback and invest in training and professional growth in our consultants

We use employees, not contractors. Compensationbased on CLIENT SATISFACTION

A CULTURE OF INTEGRITY

ADVOCATES OF YOUR INTERESTS

DRIVEN TO DELIVER

TAILORS OF OUR CRAFT

Our Partnership with Clients

Slide 4

Finit Customer Success

Our values, culture, and approach to becoming a trusted advisor to our

customers has led to

100% customer success

for every Finit client (250+) and for every EPM / CPM project (500+)

Some Finit Customers

Questions

About the Presenter

Matt Spencer([email protected])

Experience

8 years with Hyperion suite7 years in financial reporting for public and privately held companies

Certification/Education

BS – Accounting, Finance, University of Kansas (Rock Chalk!)Certified Public AccountantCertified Treasury ProfessionalHFM Certified

Client TestimonialFinit has a remarkable reputation and no matter who you meet from the company, you can understand where the comments come from. Each of them is knowledgeable in so many aspects and takes the time to make sure the client fully understands the topic. They exceed the bar of professionalism while maintaining an enjoyable atmosphere.

mailto:[email protected]

• A chart of accounts is the account structure an organization uses to produce its financial statements, including the Balance Sheet, Statement of Income, Statement of Cash Flows, and other supplemental reports.

• The chart of accounts developed for an application will impact the types of reporting that application can produce.

• This document is meant to serve as a tool when developing an application’s chart of accounts, determining attributes for the accounts, and understanding how those attributes can impact reporting.

Introduction – The Whats and Whys

• Overview: The importance of the chart of accounts (COA) and project / application dependencies.

• Design Decisions: A look into various approaches to COA design, and considerations for the following:

• The application’s purpose and usage

• How data is viewed for reporting and analysis

• Account naming conventions

• Data sources and integration

• Specialized reporting (cash flow, tax, governmental, etc.)

Introduction – Today’s Menu

Developing the chart of accounts is an essential step in the creation of an application, and can have a significant impact on the following:

• Design and implementation:

• Building metadata

• Writing rules/calculations

• Loading data

• Reconciling data

• Building and testing reports

• Training users

• Functional impacts:

• Range of reporting and analysis capability

• Application size and performance

• User experience

• Data integration

• Maintenance of the application

Overview

Purpose and Scope – What is your COA used for, and what should it include?

• First things first – what is this application used for?

• What kind of reports are produced?

• Supplemental information?

• Analysis and metrics (ratios, etc.)?

• Typically, the scope of a COA will be dependent on the type of reporting that the application will be used to produce:

• External Reporting

• Global Management Reporting

• Local ERP Reporting

• Statutory reporting (Tax, Governmental, Foreign)

• Ultimately, it is the combination of the desired reporting types above that will drive the structure and detail of the COA.

Design – COA Purpose and Scope

External Reporting: Reporting used primarily for producing external financial statements, with limited management reporting and supplemental data.

• This type of reporting is often aligned with statutory reporting requirements, and contains the level of detail to meet those standards. This is usually less detail than other forms of reporting as it is intended mainly to satisfy reporting requirements.

• COA considerations for this type of reporting should include:

• What level of detail is needed for disclosures?

• What support items for the external financial statement line items should be included in the application to support those disclosures?

• Can/should data to populate the statement of cash flows be included in the application?


External Reporting Accounts (example):


BalanceSheet

Assets

CurrentAssets

Cash

CashEquivalents

AccountsReceivable

CurrentSecurities

CurrentReceivables

OtherCurrentAssets

NonCurrentAssets

PPE

NonCurrentSecurities

NonCurrentReceivables

Intangibles

OtherNonCurrentAssets

Liabilities

CurrentLiabilities

AccountsPayable

CurrentLongTermDebt

OtherCurrentLiabilities

NonCurrentLiabilities

NonCurrentLongTermDebt

OtherNonCurrentLiabilities

Equity

RetainedEarnings

RetainedNetIncome

Dividends

OwnersEquity

CommonStock

APIC

OCI

CTA

Pension

AFSSecurities

IncomeStatement

NetIncome

PreTaxIncome

OperatingIncome

GrossMargin

Revenue

COGS

OtherOperatingExpenses

SGA

LeaseExpense

DeprAmort

OtherIncomeExpense

EquityEarnings

InvestmentIncome

InterestIncomeExpense

IncomeTax

CurrentTaxExpense

DeferredTaxExpense

• This COA structure may have additional layers of detail, but is not likely to go down to the GL level of detail. In this example, there is only one account for COGS.

• If data is pulled directly from the GL, or business unit systems, there will need to be some planning for data integration and how accounts will be mapped/grouped from the data source into this structure.

• Various approaches can be utilized to include additional detail if determined necessary.

Global Management Reporting: Reporting used for global internal management purposes that may utilize alternate account structures, functional groupings, or non-GAAP management adjustments. This may require more detail than external reporting, as the data is needed to help manage the business.

• This additional detail can include Gross to Net Sales type items, and adjustment items to reach Non-GAAP EBITDA, or other Non-GAAP presentations of data.

• Developing the account structures for management reporting may require input from various functions of the business, to understand what information adds value to the users.


• How does management primarily view the P&L?

• Can management reporting be handled through alternate structures, or are additional accounts necessary?


Global Management Reporting Example:

Alternate Structure Additional Detail


Net Capital

Working Capital

Cash

CashEquivalents

AccountsReceivable

Inventory

AccountsPayable

Capital Assets

NetPPE

AccumDepr

Investments

CurrentSecurities

NonCurrentSecurities

Debt

CurrentLongTermDebt

NonCurrentLongTermDebt

Other Net Assets/Liabilities

CurrentReceivables

OtherCurrentAssets

NonCurrentReceivables

Intangibles

OtherNonCurrentAssets

OtherCurrentLiabilities

OtherNonCurrentLiabilities

PRETAXNI

GROSSMARGIN

REVENUES

COGS

LABOR

MATERIAL

OVERHEAD

SGA

MARKETING

ENGINEERING

PRODUCTION

FINANCE

Local ERP Reporting: Reporting used to present and analyze data at the general ledger account level.

• Accounts are typically a 1-for-1 match with the general ledger accounts, and will typically follow the same naming conventions.

• This type of reporting often contains enough detail to use alternate hierarchies to group the accounts in either a natural (salaries, SGA, etc.) or a functional (IT, Marketing) structure.

• This type of design typically works best with one ERP.


• How voluminous is the chart of accounts for the local ERP?

• How do users access and use GL level data?

• Is the EPM application a tool that is involved in the account reconciliation process?


Local ERP Reporting – Example:


Revenues Grocery Revenues Product Margin Margin by Product

800001 Revenues - Cereal CerealMargin Cereal Margin

800002 Revenues - Bread 800001 Revenues - Cereal

800003 Revenues - Juice 900001 COGS - Cereal

800004 Revenues - Milk BreadMargin Bread Margin

800005 Revenues - Meat 800002 Revenues - Bread

800006 Revenues - Paper Goods 900002 COGS - Bread

COGS Cost of Goods Sold JuiceMargin Juice Margin

900001 COGS - Cereal 800003 Revenues - Juice

900002 COGS - Bread 900003 COGS - Juice

900003 COGS - Juice MilkMargin Milk Margin

900004 COGS - Milk 800004 Revenues - Milk

900005 COGS - Meat 900004 COGS - Milk

900006 COGS - Paper Goods MeatMargin Meat Margin

800005 Revenues - Meat

900005 COGS - Meat

PaperGoodsMargin Paper Goods Margin

800006 Revenues - Paper Goods

900006 COGS - Paper Goods

DescriptionAccount

Natural Rollup Product Rollup

Account Description

Tax Reporting: Reporting primarily used for meeting tax specific requirements and analysis.

• This type of reporting focuses on providing details beyond external reporting that can fulfill tax-specific reporting needs.

• Some data that can be found in tax reporting includes:

• Local and state deduction accounts

• Tax basis adjustments

• Classification of permanent or temporary tax differences

• Gross vs. Net amounts for intercompany activity

• % Deductible accounts, such as Meals and Entertainment 100% vs. 50% vs. 0%.


• Does the GL contain tax-sensitive details, or will that information need to be gathered from other sources?

• At what frequency are tax items needed?

• Are there special tax calculations that could be facilitated in the application?


Summary of Combinations:


External

Reporting

Global

Management

Reporting

Local ERP

Reporting

Stat/Tax

Reporting

External financial statements x x x

Footnote disclosure detail x x

Non-GAAP reporting rollups x x x

Functional details x x

Management adjustment accounts x x

GL level detail x

Business unit application x x x

Consolidation application x x

Tax-specific detail x

COA Structure – now that you know what data you want to include, how should it be structured?

Design – Level of Detail

Level of COA Detail – Pros and Cons:

Pros Cons

- One source for many types of

information

- Increased application

maintenance

- Alignment with accounts in the

general ledger

- Increased application

complexity and size

- Rules can execute on more

specific intersections - Multiple ledger considerations

- Less maintenance for new

general ledger accounts

- Maintenance of GL to

application maps

- Decreased size and complexity

of the application - Less detail directly accessible

- Consolidated applications do

not need to contain all accounts

- External sources must be

referenced for additional

information

More

Detail

Less

Detail

• When determining the COA for your application, it is important to understand how your organization views and analyzes financial results. Below are some common approaches:

• Natural: This view provides information on the nature of revenues and expenses, such as revenues by product, and expenses by type like salaries or payroll taxes. These revenues and expenses are then typically grouped into larger buckets, where all of COGS and SGA may be combined into an “expenses” bucket. While this may match the ERP, you may also lose the ability to see things like Gross Margin.

• Functional: This view provides a different type of detail and looks at P&L items by functional area (Balance Sheet will almost always be natural). The accounts may be less detailed, but they will be arranged by the functional area generating the activity (Human Resources, Production, Finance, Engineering, etc.).

• Hybrid: This view typically addresses SEC reporting lines, but then provides additional natural detail after that, such as further breakouts of COGS and OPEX type items.

Design – Natural, Functional, or Hybrid


Natural Example:Net Sales

Third Party Sales

Sales - Cereal

Sales - Milk

Sales Discounts and Returns

Sales Discounts

Sales Returns

Expenses

Personnel Expenses

Salaries

Bonus

Payroll Taxes

Travel & Entertainment

Training

Professional Expenses

Consulting

Tax

Legal

Facility Expenses

Rent

Utilities

• In this example, additional detail can be included in the application through the use of a custom dimension to specify function, cost center, or other identifiers.

• The degree of subtotals that are built into the COA will then drive the types of margins and calculations that are addressed through report design.


Functional Example:Net Sales - Remains the same as Natural

COGS

COGS

IC COGS

SGA

Selling Expenses

Field Sales

Sales Support

Commissions

Marketing Expenses

Marketing

Graphic Production

Finance

Accounting

Financial Planning

Internal Audit

Admin

Executive Admin

Office Management

Security

IT

HR

Legal

• In this example, the differentiation between COGS and SGA allows for the calculation of Gross Margin.

• In most cases the Balance Sheet will not differ between the two methods of reporting.


Hybrid Example:GROSSMARGIN

REVENUES

COGS

MATERIAL

60100

60101

LABOR

60200

60201

OVERHEAD

60300

SGA

EMPLOYEECOMP

FIXED

SALARIES

70101

70102

VARIABLE

SALESCOMP

70201

70202

PERFBONUS

70301

70302

• In this example, SEC reporting lines are included, but an increased level of detail is provided. This detail can however lead to cases where a type of activity may show up in multiple places, in this example, salaries in COGS and in SGA.

• This approach can be useful in cases where GL accounts exist for COGS and SGA. This is helpful when you might need to see COGS and SGA separately, but the primary P&L view is really natural (i.e. under SGA you wish to see additional detail like a grouping of all of the salaries).


Design Approach:

• Overall, we tend to design the COA based on the primary way a company looks at their data.

• If a company runs a Functional P&L and that is how they manage their business, we would design the COA to reflect that, and make it simpler and easier to see that as the primary view.

• Alternatively, if the primary focus of their P&L is a Hybrid, it should be designed that way.

• Switching between the different views in the same application can be accommodated through the use of a custom dimension or some other approach.

Account Naming Conventions

Naming Conventions – Alpha vs. Numeric

• When determining the naming convention for accounts in the application, the decisions made on the previous topics will likely impact the choice to use an alpha or numeric naming convention.

• Applications that contain more detail, with accounts pulling directly from the general ledger, may be more likely to incorporate some form of numeric type convention, as that is the style used by many ERPs.

• Applications containing higher-level data with multiple GL accounts summarized into single application accounts may be more likely to use an alpha scheme with descriptive account names.

Design –Naming Conventions


• When using an alpha naming convention, account detail typically will not go down to the general ledger level.

• This approach allows the application to be set up in a way that provides users with an intuitive view of the accounts, especially those that may not be familiar with the GL.

Naming Conventions – Alpha Example:

IncomeStatement

NetIncome

PreTaxIncome

OperatingIncome

GrossMargin

Revenue

COGS

OtherOperatingExpenses

SGA

LeaseExpense

DeprAmort

OtherIncomeExpense

EquityEarnings

InvestmentIncome

InterestIncomeExpense

IncomeTax

CurrentTaxExpense

DeferredTaxExpense


• A numeric chart of accounts typically mirrors the accounts that are used in the general ledger system.

• You will see that there are still alpha parent accounts in this structure as well.

• This naming convention can also lend itself to the creation of rules and member lists that utilize ranges, such as “all accounts that start with a 7” or “any account less than 6000”.

Naming Conventions – Numeric Example:GROSSMARGIN

REVENUES

COGS

MATERIAL

60100

60101

LABOR

60200

60201

OVERHEAD

60300

SGA

EMPLOYEECOMP

FIXED

SALARIES

70101

70102

VARIABLE

SALESCOMP

70201

70202

PERFBONUS

70301

70302

BENEFITS

MEDICAL

70410

DENTAL

70420

VISION

70430

401K

70450


Naming Conventions – Pros and Cons:

Pros: Cons:

Alpha:

- Straight-forward account names can be

easier for application users

- Many-to-one relationships from source

to destination accounts

- Less direct relationship between GL

accounts and the accounts in the

application.

- If use of the GL account changes, the

naming may no longer make sense

Numeric:

- Direct relationship between GL

accounts and accounts in the application.

- More forgiving if any of the GL accounts

are reused for other activity in the future.

- Rules can be written for ranges of

accounts, or driven by numerical

qualities.

- May not make sense in applications that

consolidate multiple GLs.

- Account purpose not easily identified

without referencing the account

description.

Other Design Considerations

• In addition to the standard Balance Sheet and Income Statement, many applications utilize the chart of accounts to meet other reporting requirements, such as:

• Statement of Cash Flows (and accompanying roll forwards)

• Statutory reporting

• Governmental reporting

• It is important to consider these types of items and determine what data can be readily gathered from source systems or users to be incorporated into the chart of accounts.

Design – Specialized Reporting

Design – Data Integration

• The source of the data in your application can influence the chart of accounts that is developed. Items to consider when thinking about the source(s) of your data should include:

• Is the data coming from a single source or multiple sources?

• ERPs and general ledgers

• Fixed asset systems

• Other transactional systems (purchasing cards, bank files, etc.)

• For each of these sources, maps may need to be created to transform the data into a format that can be loaded into the application.

• In applications where data will come from multiple locations:

• Do those locations share the same naming conventions as the GL?

• Can any of these systems provide additional detail that may not be in the current chart of accounts? Is the account dimension the most appropriate location for this additional information, or should a custom dimension be utilized?

• When determining which type of application best suits your business needs, there are some other items to be considered:

• There is a tradeoff on the level of detail in an application. More detail can lead to additional maintenance of the application itself, while less detail can lead to increased maintenance of maps between the general ledger and the application.

• Understand your users comfort level around using the application versus returning to the source system for all detailed requests. Building the information into the application isn’t adding value if the users don’t see it as the first stop for data.

• Nothing is permanent. While changes down the road can be painful, it is not impossible to increase, decrease, or change the structure or detail of information an application.

Design – Other Considerations

• There are several key items that are dependent on the chart of accounts. These areas are likely to be impacted by downstream methodology changes:

• Data integration

• Rules

• Reporting

• Input forms

• Data reconciliation

Dependencies

• The chart of accounts should be addressed early on in the development of an application, as it will have an impact on many other design factors.

• The primary considerations to keep in mind when determining design are:

• Use of the data in the application.

• How the data in the application is reported on and analyzed.

• What level of detail is appropriate for the application’s intended purpose?

• Can the COA be utilized to automate the organizations other required reports such as the cash flow, statutory, and tax reporting?

• Also keep in mind that changes to the chart of accounts design will have downstream impacts on many other aspects of the application.

Summary

• #1 – A company with 1 ERP that needs to report externally, capture local ERP detail, and perform management reporting

• #2 – A company with 50 ERPs that needs to produce external reporting, and some tax reporting.

Use Cases

• Use Case 1 – 1 ERP, external, management, and local ERP reporting.

• Decision: How is the P&L primarily viewed? Is it Functional or Hybrid? How do you line up the internal and external reporting to present all of the necessary data?

• Execution: Build out a GL level (since there is only 1) set of accounts, and use alternate rollups to create external, management, functional, and natural rollup reporting structures.

Use Cases

• Use Case 2 – 50 ERPs, external and tax reporting.

• Decision: How is the P&L primarily viewed? Is it Natural or Functional? How do you align many different ERPs into one COA?

• Execution: Design a summarized COA where users map their local ERPs to this global COA which would only exist in the EPM application. Additional detail from the source ERPs can be used to assign those amounts to a custom dimension to accommodate either Natural or Functional reporting.

Use Cases

Matt Spencer – [email protected]

[email protected]

Questions?



• July 15th – Upgrading to FDMEE: Tips and Tricks to Smooth the Transition. Hosted by Matt Spencer.

Upcoming Webinars

Kscope 2016 – Finit Presenters

•Dennis Hogan•Case Study: Converting a Multi-Cube Solution to a Single Cube Using Hybrid Mode

•Cindy Eichner•Hyperion Planning Design and Build with Smart Push and Map to Reporting•Hyperion Planning Interface: Simplified!

•Scott Sawers•Business Unit Profitability Using Allocations in HFM and Essbase

•Jeff Milller/Erich Ranz•Security and Auditing for the HFM Admin: Are You Getting the Most out of Hyperion Shared Services?

•Mary Chan•Redesigning Multiple HFM Applications for Steamlining Reporting

•Sue Lewis•The Ground Floor Tour of an HFM 11.1.2.4 Upgrade and Redesign Utilizing Exalytics

•Chris Barbieri•HFM Rule Tips for Speed Freaks•Leave No Stone Unturned: Secrets to a Successful HFM Application Review•Thursday Deep Dive: The Rules Circus: Experts Parade the HFM Functions

Thank You!

Finit - All Things Chart of Accounts

Software

Transcript of Finit - All Things Chart of Accounts