1.
OneStream ‐ What's
Possible?
Consolidation and Reporting Requirements
Clients are Satisfying Using OneStream
Part I
December 18, 2015
Jay Hampton

2.
Agenda
• Finit Introduction
• Importance of Design
• Requirements Clients Are Satisfying Using
OneStream
• Wrap Up
2

3.
Jay Hampton
jhampton@finitsolutions.com
• Partner and Director of
OneStream Team
• 11 years CPM Experience
(Hyperion and OneStream)
• Assisted over 80 CPM
Clients
About the Presenter

4.
Finit Introduction

5.
Finit Delivers Unmatched Experiences
At Finit, we believe that value and success is not just the
end achievement of a project – we believe that value and
success is achieved through the entire journey and
experience of delivering a solution to a need.
Our values, process and craft guide us in this effort:
• Advocacy & Integrity
• Craftsmanship & Delivery
• Stewardship
We combine our values, process and craft with your goals
and team to deliver more than just a solution: We deliver
an unmatched experience.
Page 5

6.
Our Culture
We employ approaches inside Finit to align our employees
to our values and principles:
• We use employees, not contractors
• We actively and continually seek feedback
• We base employee compensation on customer
satisfaction, not billable hours
• We invest in training and growth in our consultants
• We foster innovation and collaboration
• We are debt free and are committed to the success of
our clients’ programs before the profit of ours
Page 6

7.
Our Services and Solutions
We craft, deliver, and sustain solutions that
improve an organization’s capabilities, controls
and insights in the following areas:
• Financial Close & Consolidation
• Financial Planning
• Profitability & Management Reporting
• Integration and Infrastructure
Page 7

8.
Our Company
• Founded in 2002
• 80 employees in 21 states
• We provide solutions and support during and
after implementations.
• 100 % Project Success Rate Across:
• 235+ Clients (19 OneStream)
• 450+ Projects (25 OneStream)
• All Finit owners are actively involved in Finit’s
operations
Page 8

9.
Some Finit / OneStream Customers

10.
Questions

11.
Importance of Design

12.
Designers Dilemma
Page 12
Viability
Feasibility
Desirability
What you WANT
the solution to
do?
CAN we do that?
Is it technically
possible? Do we
have the right
data? What are
the constraints?
Is the solution
sustainable? Are
we designing
something that
can be
maintained
easily?

13.
Our Design Approach
Page 13

14.
Requirement:
Support Multiple Charts of
Accounts

15.
Multiple CoA Overview
• CoA – Chart of Accounts
• ERP/GL CoA
• Management Reporting CoA
• External Reporting CoA
• Multiple CoA Key Points:
• Multiple CoA
• Local CoA v. Corporate CoA
• Unique base accounts
• Alternative CoA
• External CoA v. Management CoA
• Utilizes the same base accounts but rolls them up differently
• Metadata maintenance is an important consideration – having
Local CoA’s means adding all of those elements and having good
governance and communication.
Page 15

16.
Multiple CoA Possibilities
• Stage stores local GL detail and provides some analysis
options.
• A single cube could be used to store all Chart of
Accounts.
• Adding Local CoA’s as separate cubes inside OneStream.
• If full robust reporting is required at the Local CoA level of detail,
having a separate analytical cube best facilitates that.
• Extend the Corporate CoA to add the majority of the
detail the local users need.
• Having a single Chart of Accounts at a level that can be global
while still providing the majority of local reporting needs can
reduce the need for separate cubes and help with the
governance challenges of multiple cubes.
Page 16

17.
Multiple CoA Approach
Page 17
• Understand and finalize the scope of OneStream related
to local detail.
• Discover and finalize whether a single detailed CoA can
be utilized.
• What requirements / needs are driving the need for the local
CoA detail? Can it be solved through a single global CoA that
contains more granular information?
• Determine the other local detail required beyond
Accounts.
• Are local Cost Centers, Products, Customers, etc. required?
• Design the Cube Approach
• Single cube versus multiple cube.

18.
Requirement:
Multiple Currencies

19.
Multi‐Currency Overview
• Ability to see an entity in multiple currencies or to have
OneStream handle transactional to functional
translations.
• Seeing Actual data at Budget FX Rates is what we refer to
as “Constant Dollar Analysis” which is a separate topic.
• Multi‐Currency Key Points:
• OneStream has pre‐built functionality to support the translation
of an entity into different currencies (i.e. Entity A is functional
currency Euro and it needs to translate into USD).
• Each entity is assigned a currency to facilitate the native
translation. No rules or logic is needed to perform foreign
currency translation in OneStream for local functional currency
to reporting currency.
• For the translation from transactional to functional, OneStream
would need to be setup to perform re‐measurement.
Page 19

20.
Multi‐Currency Possibilities
• Only loading functional currency to OneStream
• Storing data in transactional currency and having
OneStream perform the translation to functional
currency.
• Setting up OneStream to handle multiple currency
“overrides”
• If you have a Functional GBP entity that you need to see
translated to EUR and USD but you want the equity accounts in
both instances to translate at “historical” rates (i.e. not EOM
rates that the rest of the Balance Sheet uses to translate)
• Creating data management jobs to move data to
different scenarios to facilitate comparison between
versions.
Page 20

21.
Multi‐Currency Approach
Page 21
• Review and understand the types of accounts the
transactional currencies will be stored and translated for
(all trial balance, select accounts, etc..).
• Review and understand the functional currency
information for those entities and how that data will be
sourced and loaded relative to the transactional
currency.
• Understand how many reporting currencies are required
and how equity accounts need to be translated
• Understand the logic and re‐measurement translation
logic.

22.
Requirement:
“Automated” Cash Flow

23.
Cash Flow Overview
• Cash Flow Key Points:
• Cash Flow in OneStream starts with tracking Balance Sheet
Movements through the Flow dimension. The Flow dimension
was designed particularly for this purpose.
• The Flow dimension can be configured, but typically stores
Beginning Balance, Activity, FX and Ending Balance for each balance
sheet account.
• Cash Flow accounts are setup to link to the Balance Sheet
accounts / Flow dimension.
• Operating, Investing and Financing line items are pulled from the
Activity members.
• FX Impact on Cash is linked to the FX Flow members.
• Roll‐Forward and Memo items play an important role in
completing the submission of data needed for Cash Flow.
Page 23

24.
Cash Flow Possibilities
• Balance Sheet Movements / Unadjusted Cash Flow
calculated in local currency at the lowest point the
balance sheet exists.
• Roll‐Forwards and Cash Flow Memo Items submitted at a
later time than when the Trial Balance is submitted.
• 2 common Design approaches exist:
• 2D method (Main Reporting View)
• Tracking of Cash Flow line items by data sources (calculated,
adjusted)
• 3D method (Audit View)
• Tracking of Cash Flow line items by Balance Sheet Sub‐totals by data
sources (calculated, adjusted)
Page 24

25.
Cash Flow Approach
Page 25
• Define the level at where the Cash Flow will be initially
calculated
• We recommend this to be base entities in local currency for
proper FX treatment.
• Define the level where Cash Flow will be reported at
• This drives the minimum requirements of where roll‐forward,
cash memo‐items and non‐cash adjustments need to be made.
• Define roll‐forward and adjustment submissions
• Detail the roll‐forward components, submission process and
approach.
• Define the presentation approach (2D / 3D)
• Define the frequency and time periods

26.
Requirement:
Variance / Bridge Analysis

27.
Variance/Bridge Overview
• Explanation of change from one period to another
• Variance/Bridge Key Points:
• OneStream has a pre‐built dimension used to store activity (Flow
Dimension)
• Bridge ‘categories’ can be defined and stored in a custom
dimension and can be added and applied across the accounts
required.
• If bridge detail is calculated / input on parent reporting sub‐
totals, separate accounts will be needed.
• Parent accounts are calculated from children and cannot be input
on.
• Statistical bridge accounts for entry can be created if necessary.
• If input is required, forms or Excel templates can be setup and a
workflow can be entered in.
Page 27

28.
Variance/Bridge Possibilities
• Some organizations use the Bridge categories across
different activities:
• Bridge of information (to Last Year, to Budget, etc..)
• Walk‐Across from Forecast to Next Year Budget target
• Some organizations expand their categories to collect
more information to help understand the assumptions:
• Inflation, Productivity, Market Growth, Price Erosion,
Restructure, etc..
• Some organizations add textual information with bridge
components.
• Validations can be created and set to compare the sum
of the Bridge categories to the true activity. This helps
ensure the bridge actually foots.
Page 28

29.
Variance/Bridge Approach
Page 29
• Review and understand the level of detail bridge
information is submitted (Entity / Account).
• Review and finalize the Bridge submission process:
• Frequency of the submission
• User workflow process and timing
• Review and finalize the Bridge categories and what can
be calculated and what requires input.
• Review and finalize the textual information and
validations that may apply.

30.
Requirement:
Pre‐Seeding Budget

31.
Pre‐Seed Overview
• Creating a starting point for users in a Budget/Forecast
scenario
• Pre‐Seed Key Points:
• The seeding of data can be handled through multiple different
design approaches.
• The main driver on design decisions is the timing of the pre‐seed
and who will be initiating it.
• Data can be seeded either through a workflow process or
through initiating a process to load data.
Page 31

32.
Pre‐Seed Possibilities
• The most common seeding of data performed by
companies is the seeding of Actual data for Forecast (i.e.
3 months of Actual, 9 months of Forecast).
• Some organizations pre‐seed the current forecast with
the prior forecast, while others do more of a ‘zero‐
based’ forecast approach.
• A few companies have combined modeling with seeding
and have seeded data via starting with a base set and
then adding drivers to it.
• Example is seeding Revenue taking current Forecast with sales
growth rates.
Page 32

33.
Pre‐Seed Approach
Page 33
• Review and understand all of the pre‐seed relationships
between the different data scenarios (Actual, Budget,
Forecast, etc..).
• Review and understand the timing of the pre‐seeding
and whether submissions may overlap (i.e. Actual and
Forecast occurring at the same time).
• Review and finalize the design approach and
responsibility for seeding data.

34.
Requirement:
Modeling / Acquisition

35.
Modeling / Acquisition Overview
• Ability to view data with/without Acquisition or some
other activity
• Modeling / Acquisition Key Points:
• The basis of the item to be ‘excluded’ drives the design
approach.
• For example, if acquisitions can be determined by looking at the
Entity only, alternative entity hierarchies could be created to
exclude acquisitions.
• If it can not be defined by some element inside OneStream (i.e.
Entity, Cost Center, etc..) we have to look to understand what
determines the excluded item and how the data can be sourced
and mapped into OneStream.
• The reporting treatment also determines the design
• Should acquisitions be excluded for just a certain time period or for
all of time?
Page 35

36.
Adjustment Overview
Page 36
• Seeing data with / without Journal entries and is similar
to acquisitions
• OneStream has a pre‐built ‘Origin’ dimension that separates
data by the source or origin of where it came from – Import
(from a source system), Forms (from web forms or templates) or
Journals (from Journal entries).
• This dimension can be used to pick any entity and to see data across
all sources or origin or just for one.
• Some clients want to further classify adjustment types and
report with / without certain types of adjustments. Examples
would be US GAAP adjustments, Management Adjustments and
Audit adjustments.
• For this type a classification, a UD dimension is setup as a data type
dimension to track adjustments further.

37.
Modeling / Acquisition Possibilities
• Comparative reporting with / without an Acquisition
• Comparative reporting where an Acquisition is excluded
for its first 12 months and then included.
• Comparative reporting excluding certain types of
adjustments (Non‐GAAP Management)
• Some organizations make ‘add‐back’ adjustments to GAAP
financials to produce Management results and OneStream can
be designed to show with and without those Management, Non‐
GAAP adjustments.
• Comparative reporting excluding certain projects or
initiatives.
Page 37

38.
Modeling / Acquisition Approach
• Our process for this item starts with a deep
understanding of how reporting with / without
acquisitions would be done.
• Is there a time period of when acquisitions are included /
excluded?
• How are acquisitions stored? Entities, profit centers, etc..?
• Understanding the source data and how that affects the
future reporting state ensures the solution can be
utilized.
• Finalize the design and approach.
Page 38

39.
Requirement:
Forecast Process

40.
Forecast Overview
• Forecast Key Points:
• Forecast data can be entered either through a web form inside
OneStream or via Excel templates that pull data from OneStream.
• The items related to seeding apply to this and we have seen 3
approaches:
• Start with Latest Actual + budget for forecast months
• Start with Latest Actual + prior forecast for forecast months
• Start with Latest Actual + no data for forecast months (Zero based)
• The definition of the Rolling Forecast is important
• Is the forecast period always 18 months out (i.e. 3 months of Actual data +
18 months of forecasted periods, 6 months of Actual data + 18 months of
forecasted periods).
• Or is the period always 18 months in total (i.e. 3 months of Actual data + 15
months of forecast periods, 6 months of Actual + 12 months of forecast
periods).
• The level of detail of where Forecast is planned is important to
understand.
Page 40

41.
Forecast Possibilities
Page 41
• Some organizations perform their Forecast collection at
a higher level of detail in the Chart of Accounts as
opposed to the full granularity of the Actual and Budget
data.
• Some organizations combine a Forecast with a Risk and
Opportunity submission. The most typical approach is a
Forecast on quarter months, a risk and opportunities on
non‐quarter months with a risk‐adjusted forecast
created.
• Risk and Opportunities submission can utilize the bridge
categories and typically is collected on just a few accounts (Sales,
Gross Margin, Operating Income, etc..)
• Utilize a rolling 12 or 18 month forecast to provide more
future forecast information.

42.
Forecast Approach
Page 42
• Review and understand the level of detail the Forecast
submission should be collected at (same as actuals or
less).
• Discuss the process options and timing of a Forecast
collection.
• Will the same collection be done always or will a Forecast / R&O
approach be used together on different months?
• Finalize the strategy for seeding Forecast.
• Review and discuss the process and methodology of the
Rolling Forecast.

43.
Requirement:
Driver Based Planning

44.
Driver Based Planning Overview
• Driver Based Planning Key Points:
• Companies that adopt driver based planning either put the
drivers inside their CPM system or keep drivers outside in excel
templates and load the end results.
• Excel based drivers tend to be utilized when non‐licensed planners
are involved or if a large number of unique local drivers exist.
• System based drivers tend to be utilized to drive standardization as
well as when the planners all are CPM users.
• OneStream drivers are calculations of logic and they have the
flexibility to be done globally or locally.
• We combined allocations with this topic and allocations differ by
those that cross entity (allocate corporate costs to entities) or
ones that spread data on an entity (allocate operating expenses
on an entity down to product / customer based on sales).
• The biggest challenge to driver based planning is standardization
and flexibility.
Page 44

45.
Driver Based Planning Possibilities
Page 45
• Some of the most common drivers :
• Revenue (based on Price * Volume * Mix)
• Freight (% of sales or fixed amount)
• % of sales adjustments (pricing givebacks, material
economics)
• Direct costs (standard cost & part)
• Merit increase (based upon growth factor)
• Benefits (based on headcount
• Travel (cost per trip * trips)
• New Depreciation Expense (based on new capital
assets)
• AR / AP (Sales / COGS by customer)

46.
Driver Based Planning Approach
Page 46
• Form an internal team of key stakeholders
• Work to understand different drivers used currently and
where commonalities exist / don’t exist.
• Finalize standardized and local drivers
• Understand requirements for abilities to adjust driver‐
calculated results.
• Understand user base and determine whether drivers
will exist inside OneStream or Excel templates.

47.
Requirement:
Intercompany Matching

48.
Intercompany Overview
• Automatic Intercompany Elimination Key Points:
• First Common Parent
• No ‘Elim’ Entities
• IC dimension stores Trading partners.
• Intercompany Matching Key Points:
• IC Matching Reports allows users to see all IC booked to them
• Can be built into Workflow
Page 48

49.
Intercompany Possibilities
• Early Intercompany Submission
• Some organizations have utilized a preliminary Trial Balance
submission to facilitate Intercompany Matching to be run prior
to the due date of the full Trial Balance. A sample closing
calendar may be:
• Day 3 – Preliminary Trial Balance submission due (including all
Intercompany data with the correct trading partner)
• Day 4 – all users run Intercompany Matching and build action plans
with their counter party
• Day 5 – load final Trial Balance and move through certification steps
• Push Intercompany Matching responsibilities to data
loaders
• Intercompany Matching reports can be attached to the workflow
and run by users as a part of their process
Page 49

50.
Intercompany Approach
• Define Intercompany Accounts and Relationships
• Netted / Gross approach
• Matching accounts and location of plug account
• Define Intercompany Trading Partner basis (Legal Entity,
Profit Center, etc..)
• Finalize elimination requirements
• Process Items:
• Review ability for source systems to map / load to Intercompany
accounts and trading partners and need for a manual template
• Review when Intercompany Submission will exist
• Review responsibilities of data loaders related to Intercompany
during the close process.
Page 50

51.
See you in 2016…..

52.
See you in 2016…..
• Future Webinars:
• OneStream: What’s Possible – Part II
• Deeper dive / demo of topics covered in this webinar
• Splash 2016 in Austin, TX
• http://www.onestreamsoftware.com/splash/
Page 52
Presenter:
Jay Hampton
jhampton@finitsolutions.com
General Questions:
Greg Barrett
gbarrett@finitsolutions.com
Copy of the slides
Email us for a copy of the slides
or link to the recording
insights@finitsolutions.com
Follow us on Twitter for
updates:
@Finit_Solutions