Determining the chart of accounts is a pivotal step in the development of any EPM solution, regardless of the product that is being implemented. Finit will be hosting a webinar to discuss various topics that should be considered when deciding on a chart of accounts. With a focus on users in both Finance and IT organizations, this webinar will be useful for anyone preparing to implement a new EPM solution, or redesign an existing application. Join us as we discuss and provide examples of: The importance of the chart of accounts and application dependencies Matching a chart of accounts to the application's purpose and usage The benefits and trade-offs of: Level of detail included in the chart of accounts Naming conventions Design - Functional, Natural, or Hybrid? Downstream impacts on other aspects of the reporting process: Data Integration Cash Flow Other specialized reporting

1. All Things Chart of Accounts
Considerations when developing an application’s
chart of accounts
June 10, 2016
Matt Spencer

2. Why is Finit here?
Page 2
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

3. 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 solutions
that are functional,
usable and efficient
We actively seek
feedback and invest in
training and
professional growth in
our consultants
We use
employees, not
contractors.
Compensation
based on CLIENT
SATISFACTION
A CULTURE OF
INTEGRITY
ADVOCATES OF
YOUR INTERESTS
DRIVEN TO
DELIVER
TAILORS OF
OUR CRAFT

4. Our Partnership with Clients
Slide 4

5. Finit Customer Success
Page 5
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+)

6. Some Finit Customers

7. Questions

8. About the Presenter
Matt Spencer
(mspencer@finit.com)
Experience
8 years with Hyperion suite
7 years in financial reporting for
public and privately held
companies
Certification/Education
BS – Accounting, Finance, University
of Kansas (Rock Chalk!)
Certified Public Accountant
Certified Treasury Professional
HFM Certified
Client Testimonial
Finit 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.

9. • 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

10. • 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

11. 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

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

13. • 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

14. 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?
Design – COA Purpose and Scope

15. External Reporting Accounts (example):
Design – COA Purpose and Scope
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.

16. 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.
• COA considerations for this type of reporting should include:
• How does management primarily view the P&L?
• Can management reporting be handled through alternate structures, or are
additional accounts necessary?
Design – COA Purpose and Scope

17. Global Management Reporting Example:
Alternate Structure Additional Detail
Design – COA Purpose and Scope
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

18. 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.
• COA considerations for this type of reporting should include:
• 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?
Design – COA Purpose and Scope

19. Local ERP Reporting – Example:
Design – COA Purpose and Scope
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

20. 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%.
• COA considerations for this type of reporting should include:
• 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?
Design – COA Purpose and Scope

21. Summary of Combinations:
Design – COA Purpose and Scope
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

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

23. 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

24. • 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

25. 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.

26. Design – Natural, Functional, or Hybrid
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.

27. Design – Natural, Functional, or Hybrid
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).

28. Design – Natural, Functional, or Hybrid
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.

29. Account Naming Conventions

30. 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

31. 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

32. Design –Naming Conventions
• 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

33. Design –Naming Conventions
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.

34. Other Design Considerations

35. • 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

36. 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?

37. • 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

38. • 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

39. • 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

40. • #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

41. • 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

42. • 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

43. Matt Spencer – mspencer@finit.com
answers@finit.com
Questions?

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

45. 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

46. Thank You!