BPM-Time Series Analysis PDF

Time Series Analysis
Time Series Analysis - Fundamentals
Please check www.bestpracticemodeling.com for any updates to this document. All copyright in this
document and any derivation of this document is owned by bpmToolbox Pty Ltd, bpmModules Pty Ltd,
BPM Analytical Empowerment Pty Ltd and/or its associated entities.
Copyright bpmToolbox Pty Ltd, bpmModules Pty Ltd, BPM Analytical Empowerment Pty Ltd and
associated entities.
This is a Best Practice Modelling publication. To keep up to date with the ongoing evolution of best
practice modeling practices and technologies, join the Best Practice Modeling Network at
www.bestpracticemodeling.com/network).
Document version: 7.0.0.0
BEST PRACTICE MODELLING (BPM)
Best Practice Modelling (BPM) is a business modeling organization that specialises in the provision of
best practice spreadsheet modeling resources including software, consulting and training services. BPM
is the founding member of the Spreadsheet Standards Review Board (SSRB) and remains committed to
overseeing the ongoing maintenance, development and adoption of the Best Practice Spreadsheet
Modeling Standards. BPM can be contacted as follows:
Website: www.bestpracticemodelling.com
Email: info@bpmglobal.com
www.bestpracticemodelling.com
Table of Contents
Introduction ............................................................................................................. 3
Time Series Modules ................................................................................................. 4
Time Series Components............................................................................................ 5
Periodicities & Time Frames ........................................................................................ 6
Periodicities ..................................................................................................... 6
Time Frames ................................................................................................... 6
Time Series Assumptions ........................................................................................... 7
Period Titles Sets ...................................................................................................... 8
Period Titles Blocks ................................................................................................... 9
Multiple Periodicities ................................................................................................. 10
Periodic Data Conversions ......................................................................................... 12
Throughput Data Conversions ........................................................................... 12
Point-in-Time Data Conversions ......................................................................... 15
Multiple Time Frames ............................................................................................... 18
Rolling Business Planning .......................................................................................... 18
Time Series Scoping ........................................................................................ 18
Hiding Inactive Columns ................................................................................... 19
Inactive Columns Automation............................................................................ 24
Partial Periods ......................................................................................................... 31
www.bestpracticemodelling.com Page 1 of 33
Introduction
Time series analysis is undertaken within a large portion of spreadsheet models, yet in many
cases it is done poorly and becomes the source of many issues. The time series components
of a time series model are effectively the foundation of all other content within the model,
and therefore ensuring that the model contains a robust time series infrastructure is the key
to developing an effective time series model that is easy to develop and maintain as it
becomes more complex.
The best practice concepts regarding the undertaking of time series analysis within
spreadsheet models are discussed in the tenth Spreadsheet Modeling Area of the Best
Practice Spreadsheet Modeling Standards. However, the Standards are necessarily general
and do not therefore provide a detailed discussion of how the time series content within
spreadsheet models is actually built by the model developer.
This document aims to:
1. Provide a systematic approach to the development of the time series infrastructure

within any time series model;
2. Introduce the terminology used to discuss the different components within this time
series infrastructure;
3. Discuss the important considerations that must be borne in mind when developing this
infrastructure; and
4. Provide some examples of how content within a time series model can be developed
within more complex time series structures.
For more information and examples of time series analysis, visit the Best Practice Modeling
website at www.bestpracticemodeling.com.
Time Series Modules
As discussed in the Time Series spreadsheet modeling area of the Best Practice Spreadsheet
Modeling Standards, best practice time series models contain a single set of time series
assumptions which are referenced by the period titles within all time series sheets in the
underlying model. For modular spreadsheet development purposes, this time series content
within a modular spreadsheet model is contained exclusively within a single time series
module, as shown below:
Time Series Module Composition
This module composition diagram does not show the time series sheets in the underlying
spreadsheet, which each contain period titles with calculations based on the time series
assumptions and lookups module components within this time series module. However, it
does demonstrate how the time series infrastructure within a time series module is allowed
for when modularizing a spreadsheet model.
The time series module is unique in a modular spreadsheet because without it the
spreadsheet cannot contain time series sheets and, without time series sheets, many of the
modules within the spreadsheet cannot be inserted. Hence, the time series module sits at
the core of a modular time series model, and effectively governs the viability of the modules
which can be inserted into it e.g. an annual revenue module will not have been designed to
be inserted into a time series model with only monthly time series sheets.
For this reason, the time series module should be the first module inserted into a modular
time series model, and care should be taken when adding modules to the spreadsheet that
the modules being added are compatible with the module components within the time series
module.
Page 4 of 33 www.bestpracticemodelling.com
Time Series Components
On a basic level, the time series infrastructure within a time series model is comprised of
time series assumptions and at least one time series period titles set which provides period
titles to the time series sheets that are based on it. The time series infrastructure may also
contain time series lookup tables if the time series assumptions contain controls or data
validation which require lookup data. A basic example of this infrastructure, containing a
single annual time series period titles set which is used as the basis for a time series
assumptions sheet and a time series outputs sheet, is shown below:
Basic Time Series Infrastructure
The purpose of each of these components is provided in the table below:
Component Purpose
Time Series Assumptions Collects assumptions which are used as the basis for
the time series period titles sets throughout the time
series model.
A time series model should only contain one time
series assumptions component, but may contain
multiple period titles sets.
Period Titles Sets Provides time series period titles to the time series
sheets which are based upon them.
Effectively the period labels across the top of a time
series assumptions sheet or time series outputs sheet.
Time Series Lookup Tables Provides lookup data for controls and/or data
validation which have been included within the time
series assumptions.
The time series assumptions and lookup tables components are discussed in detail in the
Best Practice Spreadsheet Modeling Standards, although the Standards do not discuss the
concept of period titles sets, which is fundamental to developing a robust time series
infrastructure. However, prior to discussing period titles sets, it is important to understand
periodicities and time frames.
Periodicities & Time Frames
Before starting the development of the time series components within a time series model, it
is important to ascertain the periodicity (or periodicities) and time frame (or time frames) of
the model as these characteristics will determine the content to include within each of the
time series components.
Periodicities
In time series analysis, the word periodicity refers to the duration of time within each time
series period within time series sheets. For example, most companies are required to provide
annual reports to their shareholders, and these reports provide financial information on an
annual basis i.e. these financial reports have an annual periodicity. The table below lists
some of the most common periodicities which are included in time series models:
Periodicity Time Series Period Duration
Annual 1 Year
Semi-Annual 6 Months
Quarterly 3 Months
Monthly 1 Month
Weekly 1 Week
There are no set rules governing the determination of the periodicities within time series
models e.g. some spreadsheets may undertake daily or hourly analysis. The important
thing to determine is which periodicity, or periodicities, are required to be included within the
period title set(s) in a time series model before commencing the development of the time
series components.
Time Frames
Having determined the periodicities to be included within a time series model, the model
developer must consider the time frames to be included within the model. In time series
analysis, the phrase time frame refers to the period in time being analyzed within each time
series period within time series sheets, being one of the following:
Time Frame Description
Historical Values from a prior period in time i.e. data based on

actual events.
Forecast Predictions of values in the future.
All Periods A combination of all time frames ranging from the first
time frame to the last time frame in the model.
Budget Estimates of future values for a set period of time to

serve as reference points against which future actual
values can be assessed.
Often prepared as part of a rolling business planning
process.
Also sometimes refers to periods which contain a
combination of actual and forecast values e.g. a
budget year might contain 6 months of actual data
and 6 months of forecast data.
In many cases, time series models contain only one time frame (e.g. a forecast cash flow
model or a current year budget model), so it is not necessary to consider time frames
beyond potentially noting the time frame in the time series assumptions or period title sets
for clarity. However, if a time series model is required to take into account multiple time
frames, it is extremely important to ascertain the required time frames, and the best time
series infrastructure to facilitate these time frames, before commencing the development of
the time series components of the model.
Time frames are particularly relevant to business planning processes, which are often based
around a rolling business planning model i.e. the model is periodically rolled forward as
forecast periods become historical periods. In such models, it is common to use budget
periods as a basis for assessing the ability of the underlying business to meet or exceed its
targets by comparing actual data with previously estimated budget data over time. This
concept will be discussed in detail later in this chapter.
Time Series Assumptions
Having determined the periodicities and time frames to include within a time series model,
the time series infrastructure can be developed, starting with the time series assumptions
component. A time series model should only contain one time series assumptions entry
interface, and this interface should contain all the information and assumptions necessary to
allow model users to understand the time series infrastructure within the underlying
spreadsheet, and enter the date and time assumptions necessary for the model to reflect the
time periods over which data is to be analyzed.
Importantly, model developers should avoid the temptation to build time series components
in a one size fits all mentality, because doing so usually results in either an unnecessarily
complex time series infrastructure or one which is not particularly useful for any specific
purpose. An example of this is the development of time series components which allow
model users to change the periodicity of the model by changing an assumption. This sounds
great in theory, but a detrimental side effect of this functionality is that every formula within
the models time series sheets will have to allow for a potential change in periodicity e.g.
the periodicity of its parent time series sheet changing from monthly to annual. This
additional complexity is very difficult to justify when considering that model users will rarely
change this periodicity assumption once they have started using the model.
The image below shows how the time series assumptions might appear within an annual time
series model:
Example Time Series Assumptions Annual
In the above example, the term of the model is not an assumption because the time series
sheets within the underlying spreadsheet will not automatically expand and contract when
this number is changed. Instead, the term has been included as output constant to ensure
that model users are aware of the duration of the model when looking at the time series
assumptions.
Note also that the time series assumptions in this example include a drop down box which
collects the financial year end assumption from model users. The inclusion of this drop down
box would result in the time series infrastructure in the model also including a time series
lookup tables component containing the names of the months in the year. For more
information on assumptions entry interfaces, see the Assumptions Entry Interfaces
spreadsheet modeling area of the Best Practice Spreadsheet Modelling Standards.
Period Titles Sets
After building the time series assumptions component of the time series infrastructure (and
potentially the time series lookup tables component), the time series period titles sets need
to be developed. A different period titles set is required for each time series sheet structure
that is required within the model, and all time series sheets based on the same period titles
set should have identical period titles.
For example, if a model is required to present both monthly and annual time series data and
this is to be done on separate time series sheets based on their periodicity, the model would
require two period titles sets one for the monthly time series sheets and one for the annual
time series sheets. The time series outputs sheets based on these period titles sets might
appear something like those shown below:
Monthly Period Titles Set Time Series Output Sheet
Annual Period Titles Set Time Series Output Sheet
It is important to understand the relationship between period titles sets and time series
sheets i.e. period title sets form the basis for time series sheets, and every time series
sheet within a time series model must be based on one of the models period titles sets.
Hence, if changes are made to the content within a period titles set (e.g. values or formulas
within the period titles are changed), these changes must be reflected within every time
series sheet that is based upon that period titles set i.e. they must always remain
consistent. In this regard, changing the period titles within one time series sheet and not
putting the same changes through all the other time series sheets based on the same period
titles set is effectively the same as creating a new period titles set based on the amended
time series sheet. Understanding this concept is the key to ensuring the consistency of time
series sheets within time series models.
Period Titles Blocks
The clearest way to develop and analyze period titles sets is to visualize the content within
the period titles rows within each period titles set as a group of adjacent blocks of data, each
containing either a single value or consistent formulas. These blocks, which are referred to
as period titles blocks, may then be analyzed based on their characteristics such as their
periodicity and time frame.
The image below shows an example of a time series sheet based on a period titles set with
an annual periodicity with three time series periods (i.e. years):
Annual Time Series Set Time Series Sheet Example
The period titles blocks within this period titles set can be seen by using different color
shading to highlight its period titles blocks (which are effectively groups of columns within
the period titles set), as shown below:
Shaded Period Titles Blocks
In this example, the period titles set contains 6 period titles rows (rows 5 10) and 3 period
titles blocks, as summarized in the below table:
Block Column(s) Description
1 B Period titles row headings.
2 CI Spacer columns between headings and data.
3 JL Annual time series period titles.
Importantly, every row within each period titles block within the period titles set contains
either a single value (e.g. the value Period Start Date in cell B7) or a consistent formula
(e.g. the period counter formula in the range J10:L10). This is important, because if the
period titles are to be extended or shortened, the relevant period titles blocks can simply be
dragged or deleted from their right edge to effectively increase or decrease the number of
time periods within that period titles block e.g. in the above example the range J5:L10
could be dragged over the range J5:M10 to increase the number of years in the period titles
set from 3 years to 4 years, etc.
In the case of simple period titles sets, such as that in the above example, the analysis of
period titles blocks seems excessively complicated for such a simple task. However, as time
series structures become more complex to allow for multiple periodicities and/or time
frames, an understanding of each of the period titles blocks within each period titles set, and
the relationships between these blocks, is fundamental to developing a robust and reliable
time series infrastructure.
Multiple Periodicities
In many time series models, model users require data to be analyzed over multiple
periodicities, usually to provide a longer-term perspective on the model outputs. For
example, a business planning model might require model users to enter assumptions on a
monthly basis, but display the outputs on both a monthly and annual basis so that model
users can analyze the impacts of monthly assumptions on a year-on-year basis.
The inclusion of multiple periodicities within a time series model requires the model
developer to decide how these periodicities should best be incorporated within the model
time series infrastructure. The most important decision to be made when allowing for
multiple periodicities is whether or not the different periodicities should be located within a
single period titles set, or whether different period titles sets should be used for the different
periodicities in the model.
A common mistake made when developing multiple periodicity models is to develop the time
series infrastructure based on the output preferences of model users without considering the
practical implications of this approach. For example, the period titles set underlying the time
series outputs sheet shown below has been developed in response to model users requesting
annual summations after each 4 quarters on the sheet:
Period Titles Set with Mixed Periodicities
Whilst this period titles set structure might be appealing to model users, it results in many
build complexities which will dramatically increase the time required to build and maintain
the model and it will also greatly increase the risk of errors within the model calculations.
This is primarily because this period titles set structure increases the number of period titles
blocks within the period titles set from 3 period titles blocks (within a basic single periodicity
monthly period titles set) to 6 period titles blocks, as shown by the block shading in the
image below:
Period Titles Blocks with Mixed Periodicities
The obvious problem with this period titles set structure is that the formulas within the
quarterly periodicity columns (i.e. columns J:M and O:R) are no longer within a single
consistent formula block, and neither are the annual summation formulas in columns N and
S. As a result, the model developer needs to either insert independent formulas into these
columns or enter complex formulas which detect the periodicity of each time series column
and adapt accordingly. Furthermore, if the model user requests that the model be extended
to include a third year, there is no quick and easy way to extend the existing period titles
blocks because the quarterly and annual period titles blocks for each year are independent of
each other.
There are many ways of simplifying this structure whilst still achieving the same outputs
required by model users. One such approach might involve locating the quarterly and annual
period title blocks side-by-side instead of mixing them together, as shown below:
Mixed Periodicities Adjacent Period Titles Blocks
This approach ensures that the quarterly and annual calculations are separated and
quarantined within single consistent formula blocks, which makes building and maintaining
the content within the time series sheet much easier. This approach also makes extending
the model relatively easy because period titles blocks, and the content within them, can be
extended by inserting columns and dragging across consistent formulas.
Another approach could involve creating completely separate period titles sets for each
periodicity, which would result in the quarterly and annual data being located on separate
quarterly and annual time series sheets, thereby making maintaining and extending the
model even easier. In any approach, presentation outputs can be prepared which present
this data in any format required by the user without the adverse side effects of using overly-
complicated period titles sets as the foundations for all the model assumptions and outputs.
There are no set rules for determining the best period titles set structure when providing for
multiple periodicities, but consideration should be given to the clarity and user-friendliness of
the structure from a model users perspective whilst also considering any potential
complexities which may arise as a result of the chosen period titles set structure. And it
should always be borne in mind that presentation outputs can always be used to slice and
dice output information without fundamentally affecting the operation or complexity of the
underlying time series model.
Periodic Data Conversions
When time series models contain multiple periodicities, data conversions are almost always
required to present the same data over a different period of time, or at different points in
time. Whilst these data conversions may sometimes involve the downwards conversion of
data from a higher periodicity to a lower periodicity (e.g. annual to monthly), the vast
majority of data conversions are upwards conversions (e.g. monthly to annual). For this
reason, only upwards data conversions will be discussed on this chapter.
Before converting data from one periodicity to another, the model developer must classify
the data to be converted as either throughput data or point-in-time data, as described in
the table below:
Periodic Data Type Description
Throughput Flows across time periods, such that it is required to

be summed during upwards conversions e.g.
revenue, cash flows, etc.
Point-in-Time Measured at specific moments in time, such as the

start or end of a time period e.g. asset closing
balances on a balance sheet.
Understanding the difference between these periodic data types is crucial to correctly
converting data from one periodicity to another, as this classification of data will determine
how the conversion is undertaken.
Throughput Data Conversions
To convert throughput data from a lower periodicity to a higher periodicity (e.g. quarterly to
annual), the throughput data values for each period within the higher periodicity period are
calculated such that the higher periodicity values are summations of their constituent lower
periodicity values. The difficulty in this process is matching the lower periodicity values to
their corresponding higher periodicity summations, and this is done via the use of periodicity
keys.
Periodicity keys are text strings that are created for each column within each period titles set
that contains data to be converted and used as a basis for matching corresponding values
using the SUMIF function.
To demonstrate this process, consider a time series model which contains both quarterly and
annual period titles sets and is required to present quarterly revenue outputs on an annual
basis. In this example, the quarterly revenue outputs have been located on a quarterly time
series output sheet named Rev_Qtrly_TO and the annual revenue outputs have been
located on an annual time series output sheet named Rev_Ann_TO, as shown below:
Quarterly Revenue Outputs
Converted Annual Revenue Outputs
To understand how this conversion has been undertaken, it is necessary to expand the
compacted period titles rows within these time series sheets and analyze how periodicity
keys have been used to allocate the quarterly revenue to the annual time series periods
within the annual time series sheet. This has been done in the diagram below:
Converting Quarterly Throughput Data to Annual
The following steps have been taken to convert the quarterly throughput data (i.e. revenue)
to annual data:
1. A Financial Year row (row 10) has been included in both the quarterly and annual
period titles sets; and
2. A SUMIF function has been used within the conversion formula on the annual time
series output sheet to sum all quarterly values for each category which are located
within the same financial year as that containing the annual converted value.
In this example, the Financial Year is used as the periodicity key i.e. it provides the basis
for the criteria within the SUMIF function which determines which quarterly values are
summed for each annual value.
Converting lower periodicity throughput data to annual data is relatively simple because the
periodicity key is the financial year. However, the periodicity key must be more specific if
throughput data is being converted from one non-annual periodicity to a higher non-annual
periodicity key e.g. monthly to quarterly or quarterly to semi-annual. This is because in
such cases the periodicity key must reflect both the periodicity of the lower periodicity data
being converted as well as the financial year.
The following shows how this process might be undertaken to convert quarterly data to semi-
annual data. To facilitate this, periodicity key rows have been added to both the quarterly
and semi-annual period titles sets to identify the financial year and half number of each
period i.e. the Half Key for each period. This periodicity key has then been used as the
basis for the criteria within the SUMIF function on the semi-annual time series outputs sheet
which presents the converted annual data:
Converting Quarterly Throughput Data to Semi-Annual
The conversion process outlined in these two examples can be used to convert any lower
periodicity throughput data to a higher periodicity, with the only difference between the
different conversions being the periodicity keys which are used to drive the conversion
SUMIF function.
Point-in-Time Data Conversions
All periodic data that is not classified as throughput data should be point-in-time data. The
conversion of point-in-time data from one periodicity to another is simpler than the
conversion of throughput data, because it requires only that data be matched based on a
specific point in time rather than over multiple periods of time.
A common example of point-in-time data within business planning models is the closing
balances of balance sheet items such as assets and liabilities. When converting this data
from a lower periodicity to a higher periodicity (e.g. monthly to annual) only the value of the
balance sheet items at the start or end of each period is relevant, and therefore the
conversion process is based on matching period start or end dates within the period titles
sets containing the different periodicities.
To demonstrate this process, consider a time series model which contains both quarterly and
annual period titles sets and is required to present the quarterly closing asset balances on an
annual basis. In this example, the quarterly closing asset balances have been located on a
quarterly time series output sheet named Assets_Qtrly_TO and the annual closing asset
balances have been located on an annual time series output sheet named Assets_Ann_TO,
as shown below:
Quarterly Closing Asset Balances Outputs
Converted Annual Closing Asset Balances
To understand how this conversion has been undertaken, it is necessary to expand the
compacted period titles rows within these time series sheets and analyze how the period end
dates have been used to allocate the quarterly closing asset balances to the annual time
series periods within the annual time series sheet. This has been done in the diagram below:
Converting Quarterly Point-in-Time Data to Annual
The following steps have been taken to convert the quarterly point-in-time data (i.e. closing
asset balances) to annual data:
1. A Period End Date row (row 9) has been included in both the quarterly and annual
period titles sets; and
2. A SUMIF function has been used within the conversion formula on the annual time
series output sheet to locate the quarterly value for each category within the quarter
with the same period end date as that containing the annual converted value.
The conversion process outlined in this example can be used to convert any periodicity point-
in-time data to another periodicity, irrespective of whether the conversion is upwards or
downwards. This is yet another reason to include period start and end dates in all period
titles sets for each periodicity as recommended by the Best Practice Spreadsheet Modeling
Standards.
Multiple Time Frames
One of the most common and powerful uses of time series analysis is the preparation of
budgets and forecasts and the comparison of these predictions against actual data over time.
This is particularly common in a business planning process, which involves the periodic
assessment of the actual performance of a business against previously set budgets and
forecasts, and is instrumental to the decision making processes and strategies of those
running the business.
In order to facilitate the side-by-side analysis of actual and forecast data, the time series
infrastructure within a time series model must accommodate multiple time frames. This is
not a simple process, as the model developer needs to take into consideration the relevant
time frames when building every element of a time series model. It is also complicated by
the fact that data is often analyzed differently over different time frames e.g. historical
financial information might be collected via the entry of assumptions directly into financial
statement templates, whilst financial forecasts might be constructed based on detailed
assumptions regarding revenue and expense drivers and growth rates, etc.
Given these complexities, and the diverse range of combinations of multiple time frame time
series analysis structures, it is not possible to state specific rules governing the development
of such structures. Instead, an example of a common multiple time frame time series
infrastructure will be discussed, as many of the concepts used in this example will be
applicable to many similar structures.
Rolling Business Planning
Possibly the most common application of multiple time frame time series analysis is the
undertaking of a rolling business planning process. This process is referred to as a rolling
process because the time series model is updated periodically as forecast time periods
become historical time periods i.e. the model is rolled forward to reflect this movement of
data between time frames.
The development of a rolling business planning model is complicated by the fact that
spreadsheets do not automatically expand as more forecast periods are required, and the
process of manually adding and removing time series period columns is a complex one even
in relatively simply time series models. Hence, the model developer must work closely with
model users to ascertain their precise time series requirements before building the rolling
time series infrastructure, because amending it after content has been added to the model
may prove difficult and create a high risk of errors.
Fortunately, there are some handy techniques which can be used to greatly improve the
user-friendliness of rolling time series models whilst also making the model development
process simpler and more efficient. These techniques will be demonstrated throughout the
following example.
Time Series Scoping
Before commencing the development of a rolling time series model, it is important to discuss
and agree the precise time series requirements of the model users, as these requirements
will determine the complexity of the models time series infrastructure. To demonstrate this
scoping process, consider a scenario in which a model user requires an annual time series
model which will analyze 3 categories of revenue over both historical and forecast time
frames. In this model the model user wants to be able to enter historical revenue
assumptions as dollar amounts, but forecast revenue assumptions as annual growth rates.
The model user would also like to compare the historical and forecast revenue on a side-by-
side basis, and roll the model forward each year as historical revenue amounts become
available. Finally, the model must contain 5 years of forecast revenue at all times, and
display a maximum of 3 years of actual revenue.
These time series requirements are detailed and complicated, but not uncommon. The table
below shows how they might be summarized in order to reach agreement with the model
users prior to starting the development of the time series components:
Rolling Time Series Model Example Time Series Scope
Periodicity Annual
Time Frames Historical, Forecast & All Periods
Maximum Visible Actual Years 3
Forecast Years 5
In addition to ascertaining this time series scope, the following limiting assumptions are
made and agreed with the model users:
1. The model must have at least 1 historical year; and
2. The model cannot have more than 7 actual years.
These limitations might appear random, but they are very important in limiting the
complexity of the time series infrastructure, which should always be the objective when
developing time series components i.e. the time series functionalities within a time series
model should contain only the minimum required functionality in order to minimize the
complexity and risk of errors within the model.
In this case, the model users acknowledge that the model will primarily be used to analyze 3
years of historical revenue against 5 years for forecast revenue, and that it is unlikely that
the model will be used for more than 5 years without a comprehensive roll-forward, i.e.
removal of all assumptions, resetting the time period and zero-based data population. The
above limitations reflect these realities, and significantly refine and simplify the scope of the
time series components.
Hiding Inactive Columns
Having ascertained the scope of the time series infrastructure to be included within the
rolling time series model, it is time to start building the time series components i.e. the
time series assumptions, lookups and period titles sets. Before starting this process, it is
important to understand how the inactive columns method can be used to facilitate the
process of rolling a time series model without requiring model users to move or re-enter
assumptions.
The use of inactive columns within rolling time series models is a way of working around the
difficulties, risks and time consuming process required to move or re-enter assumptions into
time series periods after their time periods change when a model is rolled forward. To
demonstrate this issue, consider an annual time series model which contains historical and
forecast revenue assumptions, with 3 years of historical revenue starting from 2010 and 5
years of forecast revenue starting from 2013. In this model, different period titles sets have
been created for the historical time series sheets and the forecast time series sheets to be
used in the model. The historical and forecast revenue assumptions, which are based on
these period titles sets respectively, are shown below:
Historical Revenue Assumptions (No Inactive Columns)
Forecast Revenue Assumptions (No Inactive Columns)
These assumptions entry interfaces work perfectly well when the model user is entering
historical revenue assumptions for the 2010 2012 historical years and forecast revenue
assumptions for the 2013 2017 forecast years. However, at the end of the 2013 year the
model user will almost certainly want to enter historical revenue assumptions for 2013
(rather than forecast revenue growth rates) and enter forecast revenue growth rates for the
2014 2018 years.
Because the time series structure in the above example does not facilitate the rolling of the
model, the model user would be required to change the first financial year within the time
series assumptions from 2010 to 2011 to update the time series sets within the model.
However, the side effect of changing this assumption is that all existing revenue assumptions
become mid-aligned with their time series periods, as shown below:
Updated Historical Assumptions (No Inactive Columns)
Updated Forecast Assumptions (No Inactive Columns)
As a result of changing the first financial year assumption from 2010 to 2011, the historical
assumptions for the 2011 and 2012 years are now located within the 2012 and 2013 time
series columns, and 2014 2017 forecast growth rate assumptions are similarly misaligned.
Additionally, the previous 2012 historical revenue assumptions now appear as 2013
assumptions, and the 2018 forecast growth rate assumptions are now equal to the previous
2017 forecast growth rate assumptions.
To realign these assumptions, the model user will now need to:
1. Copy and paste the 2011 2012 historical revenue assumptions into their correct
columns;
2. Enter new 2013 historical revenue assumptions;
3. Copy and paste (if not completely review) the 2014 2017 forecast revenue
assumptions into their correct columns; and
4. Enter new 2018 forecast revenue assumptions.
This process is not only time-consuming and quite difficult, but it creates a significant risk of
data transfer errors. In reality, a business planning model will have thousands of
assumptions and this process, even if automated with macros, is rarely a reliable option for
rolling forward the model.
Fortunately, there is a way around these issues which prevents the need for model users to
ever need to transfer assumptions when rolling a time series model forward. This is done via
the use of active and inactive columns. Under this approach, the time series period
columns are hidden and unhidden based on whether or not they are required to be
considered by model users i.e. whether or not they are active. Time series columns which
are not relevant because they are either redundant or yet to be used by the time series
analysis are simply hidden (and potentially grouped) from the view of model users, thereby
removing the need to add or remove columns or move assumptions when rolling forward a
time series model.
To demonstrate this, consider the rolling revenue time series model discussed earlier in this
chapter. This model requires both historical and forecast revenue data and will be rolled
forward each year as new historical revenue data becomes available. To facilitate this
process, the period titles blocks within the historical and forecast period titles sets are built
including excess columns which will only be used as the first forecast year is increased over
time and they become relevant to each time frame i.e. when they become active.
The following diagram shows how the active and inactive classification of columns within the
final period titles block of the different period titles sets (i.e. historical, forecast and all
periods) changes as the model is rolled forward each year by increasing the first forecast
year by 1 year:
Active & Inactive Columns by Period Titles Set
In this diagram, shading has been used to differentiate active columns from inactive columns
i.e. within the historical period titles set, only the 2010 2012 years are initially active,
with the 2013 2016 years inactive as they await use in subsequent years after the model
has been rolled forward. Note that the period titles blocks for all three period titles sets (i.e.
historical, forecast and all periods) start in the same column (column J) and that this column
is the same year (2010).
The following process takes place as the model is rolled four times after the initial year:
1. The model initially starts with 3 active historical years (columns J L, years 2010
2012) and 4 inactive historical years (columns M P, years 2013 2016);
2. The model initially starts with 5 active forecast years (columns M Q, years 2013
2017) and 7 inactive forecast years (columns J L and R U, years 2010 2012 and
2018 2021);
3. The model initially starts with 8 active all periods years (columns J Q, years 2010
2017) and 4 inactive all periods years (columns R U, years 2018 2021);
4. In year 2 the model is rolled forward by changing the first forecast period assumption
from 2013 to 2014, and the active columns update accordingly i.e. the previously
active 2010 historical year becomes inactive and the previously inactive 2013 historical
year becomes active, with similar changes taking place within the forecast and all
periods time series sets; and
5. This process continues each year as the first forecast period assumption is changed.
Perhaps the best way to understand this process is to look at an example of how it might be
implemented within a time series model. The image below shows how the time series
assumptions might be collected within this model:
Rolling Time Series Assumptions
Note that model user is provided within a first forecast year assumption (via a drop down
box) which, combined within the first financial year assumption, determines the number of
active historical years/columns within the underlying time series model. Note also that in this
example, the number of forecast years (i.e. 5 year) is not an assumption as the model
assumes that there will always be 5 forecast years.
The images below show how the historical and forecast revenue time series assumptions
sheets might appear for the initial year of use based on these assumptions:
Actual Revenue Assumptions (with Inactive Columns)
Forecast Revenue Assumptions (with Inactive Columns)
Note that both of these time series sheets contain inactive columns i.e. columns M P
(i.e. 2013 2016) within the historical time series sheet and columns J L and R U (i.e.
2010 2012 and 2018 2021) within the forecast time series sheet. These columns have
been made inactive by grouping them and hiding them from the view of model users, but
they remain ready and waiting for use if and when the model is rolled forward.
The images below show these same time series sheets after changing the first forecast year
assumption from 2013 to 2014 i.e. after rolling forward the model 1 year:
Historical Revenue Assumptions (with Inactive Columns) Year 2
Forecast Revenue Assumptions (with Inactive Columns) Year 2
Importantly, even though the model has been rolled forward by 1 year, the assumptions
remain aligned with their time series periods and therefore the model user is not required to
manually transfer assumptions. Furthermore, the newly-active assumptions are clearly
visible (i.e. column M of the historical time series sheet and column R of the forecast time
series sheet). This is because the columns themselves have not changed within these sheets;
only the visibility of different columns has changed based on whether or not they are active
or inactive for the given time series assumptions.
This technique involving the use of active and inactive columns to limit the visible columns
within time series sheets is the key to creating multiple time frame time series models which
can be quickly, easily and safely rolled forward over time. However, for it to be done
properly, the visibility of active and inactive columns needs to be automated. This process is
discussed below.
Inactive Columns Automation
The use of active and inactive columns is the key to creating time series models that can be
rolled forward over time. However, without the visibility and grouping of active and inactive
columns being automated, the model developer is forced to manually update the visibility of
these columns each time the model is rolled forward.
To remove the ongoing need for the model developer to be involved in the model roll-
forward process, the grouping and visibility of inactive columns can be automated by
including Visual Basic macros within the underlying workbook, which respond to changes to
time series assumptions by automatically verifying the visibility and grouping of all time
series columns within all time series sheets.
For these macros to operate, it is first necessary to include an additional row within each
period titles set that distinguishes inactive time series columns. This row is called the Active
Columns Trigger row, and contains formulas returning a value of 1 indicating that the
column is active and a return value of 0 indicating that the column is inactive, as shown in
row 11 of the time series sheet below:
Active Columns Trigger Row Inclusion
In this example, the Active Columns Trigger row is indicating that of the columns in the
period titles block ranging from column J to P, only columns K M are active based on the
underlying time series assumptions. Hence, when the update macro runs and checks the
values in the range J11:P11, it will group and hide column J and the columns N P, as
shown below:
Active Columns Trigger Row Inclusion
Note that all columns containing a value of 0 within the Active Columns Trigger row have
been grouped and hidden allowing model users to easily show and hide these columns
using the compact and expand buttons, but by default hiding the inactive columns from view.
There are many ways that the macro driving this automation could be written, although the
concept is the same:
1. Loop through each worksheet in the workbook;

2. If an Active Columns Trigger row is detected (by checking for a heading in a specific
cell in this case the text Active Columns Trigger cell B11), ungroup and unhide all
columns within period titles blocks (in this example the third period titles block in
columns J:P); then
3. Group and hide all inactive columns within period titles blocks containing inactive
columns.
To do this in a model used for the above example, two macros are required the first to
unhide and ungroup all columns from (and including) column J on worksheets containing the
Active Columns Trigger row (i.e. heading cell), and a second to hide and group the inactive
columns from (and including) column J on these same worksheets. The first of these macros
is shown below:
Inactive Columns Automation Unhide & Ungroup All Columns Macro
Sub Unhide_Ungroup_Worksheet_Time_Series_Columns(objWorksheet As Excel.Worksheet)
'Unhides and ungroups the worksheet time series columns:
'Private declarations:
Dim rgeFirstCell As Excel.Range
Dim rgeLastCell As Excel.Range
Dim rgeAllColumnsRow As Excel.Range
Dim rgeTriggersRow As Excel.Range
Dim rgeHiddenColumns As Excel.Range
Dim rgeTriggerCell As Excel.Range
Dim rgeArea As Excel.Range
Dim lngGroupLevel&
'Private constants:
Const lngActiveColumnsRowNumber& = 11
Const lngFirstColumnNumber& = 10
Const strActiveColumnsTriggerHeading$ = "Active Columns Trigger"
'Unhides and ungroups if Active Columns Trigger heading found:

If CBool(Not objWorksheet Is Nothing) Then
If UCase(CStr(objWorksheet.Cells(lngActiveColumnsRowNumber, 2).Value)) _
= UCase(strActiveColumnsTriggerHeading) Then
Set rgeFirstCell = objWorksheet.Cells( _
lngActiveColumnsRowNumber, lngFirstColumnNumber)
If CBool(Not rgeFirstCell Is Nothing) Then
With objWorksheet.UsedRange
Set rgeAllColumnsRow = Application.Range(rgeFirstCell, _
objWorksheet.Cells(rgeFirstCell.Row, _
.Columns(.Columns.Count).Column))
End With
If CBool(Not rgeAllColumnsRow Is Nothing) Then
rgeAllColumnsRow.EntireColumn.Hidden = False
For lngGroupLevel = 1 To 8
Call rgeAllColumnsRow.Columns.Ungroup
If CBool(Not IsNull(rgeAllColumnsRow.Columns.OutlineLevel)) Then
If CBool(CLng(rgeAllColumnsRow.Columns.OutlineLevel) = 1) Then
Exit For
End If
End If
Next lngGroupLevel
End If
End If
End If
End If
End Sub
The macro to group and hide inactive columns is shown below:
Inactive Columns Automation Group & Hide Inactive Columns Macro
Sub Unhide_Ungroup_Worksheet_Time_Series_Columns(objWorksheet As Excel.Worksheet)
'Unhides and ungroups the worksheet time series columns:
Dim rgeFirstCell As Excel.Range
Dim rgeLastCell As Excel.Range
Dim rgeAllColumnsRow As Excel.Range
Dim rgeTriggersRow As Excel.Range
Dim rgeHiddenColumns As Excel.Range
Dim rgeTriggerCell As Excel.Range
Dim rgeArea As Excel.Range
Dim lngGroupLevel&
'Private constants:
Const lngActiveColumnsRowNumber& = 11
Const lngFirstColumnNumber& = 10
Const strActiveColumnsTriggerHeading$ = "Active Columns Trigger"
'Unhides and ungroups if Active Columns Trigger heading found:

If CBool(Not objWorksheet Is Nothing) Then
If UCase(CStr(objWorksheet.Cells(lngActiveColumnsRowNumber, 2).Value)) _
= UCase(strActiveColumnsTriggerHeading) Then
Set rgeFirstCell = objWorksheet.Cells( _
lngActiveColumnsRowNumber, lngFirstColumnNumber)
If CBool(Not rgeFirstCell Is Nothing) Then
With objWorksheet.UsedRange
Set rgeAllColumnsRow = Application.Range(rgeFirstCell, _
objWorksheet.Cells(rgeFirstCell.Row, _
.Columns(.Columns.Count).Column))
End With
If CBool(Not rgeAllColumnsRow Is Nothing) Then
rgeAllColumnsRow.EntireColumn.Hidden = False
For lngGroupLevel = 1 To 8
Call rgeAllColumnsRow.Columns.Ungroup
If CBool(Not IsNull(rgeAllColumnsRow.Columns.OutlineLevel)) Then
If CBool(CLng(rgeAllColumnsRow.Columns.OutlineLevel) = 1) Then
Exit For
End If
End If
Next lngGroupLevel
End If
End If
End If
End If
End Sub
A looping macro is required which loops through every worksheet within the underlying
workbook and calls the first of the above macros to unhide and ungroup all time series
columns on worksheets containing the Active Columns Trigger row and then, if required, calls
the above macro to group and hide inactive columns.
This macro is shown below:
Inactive Columns Automation Workbook Inactive Columns Refreshing
Sub Refresh_Workbook_Inactive_Time_Series_Columns(Hide As Boolean)
'Hides or unhides the inactive columns throughout this workbook:
Dim lngPriorCalculation As XlCalculation
Dim boolPriorScreenUpdating As Boolean
Dim boolPriorDisplayAlerts As Boolean
Dim objWorksheets As Excel.Sheets
Dim objWorksheet As Excel.Worksheet
Dim lngWorksheetsCount&
Dim lngWorksheetNumber&
'Allows for errors:

On Error Resume Next
'Temporarily removes screen updating and automatic calculation settings:

'NOTE: Calculates to ensure that Active Column Triggers are correct.
With Application
boolPriorScreenUpdating = .ScreenUpdating
boolPriorDisplayAlerts = .DisplayAlerts
lngPriorCalculation = .Calculation
.ScreenUpdating = False
.DisplayAlerts = False
.Calculation = xlCalculationManual
Call .Calculate
End With
'Loops through worksheets, updating columns if found:

Set objWorksheets = ThisWorkbook.Worksheets
If CBool(Not objWorksheets Is Nothing) Then
lngWorksheetsCount = objWorksheets.Count
If CBool(lngWorksheetsCount > 0) Then
Application.StatusBar = "Updating time series columns..."
For Each objWorksheet In objWorksheets
lngWorksheetNumber = lngWorksheetNumber + 1
Application.StatusBar = "Updating time series columns (sheet " & _
CStr(lngWorksheetNumber) & " of " & CStr(lngWorksheetsCount) & "..."
Call Unhide_Ungroup_Worksheet_Time_Series_Columns(objWorksheet)
If Hide Then
Call Group_Hide_Inactive_Worksheet_Time_Series_Columns(objWorksheet)
End If
Next objWorksheet
Application.StatusBar = False
End If
End If
'Restores the prior screen updating and automatic calculation settings:

With Application
.Calculation = lngPriorCalculation
.DisplayAlerts = boolPriorDisplayAlerts
.ScreenUpdating = boolPriorScreenUpdating
End With
'Removes error handling:

Err.Clear
End Sub
Importantly, this procedure needs to be called whenever the time series assumptions are
changed within the underlying model, even if changes are made via controls such as check
boxes and drop down boxes.
In the above example, a check box and button have been added to the time series
assumptions to allow the user to control whether or not the time series columns within the
underlying time series model are automatically updated when the time series assumptions
are changed, as shown below:
Inactive Columns Visibility Automation Controls
In this example, the Automatically hide inactive year columns? check box has been added
to the time series assumptions to allow model users to specify whether or not the grouping
and visibility should be automatically updated whenever changes are made to the time series
assumptions. The cell link of this check box (i.e the cell C15) has been named
CB_TS_Auto_Hide_Inactive_Cols such that the below macro can use its value to determine
whether or not inactive columns are automatically being updated:
Inactive Columns Automation Conditional Inactive Columns Updating
Sub Refresh_Workbook_Inactive_Time_Series_Columns_If_Required()
'Refreshes the workbook inactive columns if required the

'"Automatically hide inactive year columns?" cell link value is TRUE:
Dim objName As Excel.Name
Dim rgeLinkedCell As Excel.Range
'Allows for errors:

'Gets the check box cell link range name:

Set objName = ThisWorkbook.Names("CB_TS_Auto_Hide_Inactive_Cols")
'Calls the update procedure if required:

If CBool(Not objName Is Nothing) Then
Set rgeLinkedCell = objName.RefersToRange
If CBool(Not rgeLinkedCell Is Nothing) Then
If CBool(rgeLinkedCell.Value) Then
Call Refresh_Workbook_Inactive_Time_Series_Columns(True)
End If
End If
End If
'Clears errors:
Err.Clear
End Sub
To automate the calling of this macro, the following code is added to the code module for the
worksheet containing the time series assumptions (in this case a assumptions worksheet
named TS_BA), as shown below:
Inactive Columns Automation Worksheet Change Event Hook
Private Sub Worksheet_Change(ByVal Target As Range)
'Automatically updates the active time series sheet columns if required:

Call Refresh_Workbook_Inactive_Time_Series_Columns_If_Required
End Sub
Additionally, a macro is added to capture a change in the Automatically hide inactive year
columns? check box as shown below:
Inactive Columns Automation Check Box Change Event Capture
Sub Capture_Inactive_Columns_Check_Box_Change()
'Captures the time series "Automatically hide inactive year columns?"

'check box change event:
'NOTE: This macro must be assigned to the check box.
Dim objName As Excel.Name
Dim rgeLinkedCell As Excel.Range
Dim boolHide As Boolean
'Allows for errors:

'Assumes not hiding to start:

boolHide = False
'Gets the check box cell link range name:

Set objName = ThisWorkbook.Names("CB_TS_Auto_Hide_Inactive_Cols")
'Calls the update procedure if required:

If CBool(Not objName Is Nothing) Then
Set rgeLinkedCell = objName.RefersToRange
If CBool(Not rgeLinkedCell Is Nothing) Then
boolHide = rgeLinkedCell.Value
End If
End If
'Runs:
Call Refresh_Workbook_Inactive_Time_Series_Columns(boolHide)
'Clears errors:
Err.Clear
End Sub
This macro is assigned to the Automatically hide inactive year columns? check box so that it
is called whenever model users check or uncheck this control, thereby ensuring that inactive
columns are refreshed accordingly.
Finally, the Show All Time Series Columns button was added to the time series assumptions
to allow model users (and model developers) to manually force the showing of all time series
columns. This is particularly helpful from a model development perspective, because model
development should always be undertaken with all columns visible (even if inactive) to
prevent errors resulting from unseen inactive columns.
The following macro is assigned to the Show All Time Series Columns button to unhide and
ungroup all time series columns:
Inactive Columns Automation Check Box Change Event Capture
Sub Show_All_Time_Series_Columns()
'Shows all the time series sheet columns:

Call Refresh_Workbook_Inactive_Time_Series_Columns(False)
'Alerts:
Call MsgBox("All time series sheet columns are now visible.", vbInformation, ThisWorkbook.Name)
End Sub
The VBA code provided in this example can be used to provide a reliable foundation for the
automation of the visibility of active and inactive columns within any rolling time series
infrastructure, subject to some minor adaptations such as amending range names and the
location of the Active Columns Trigger head cell (which should always be located within the
same cell on all applicable time series sheets in the workbook).
Partial Periods
Some time series models may require the analysis of data over part, but not all, of particular
time series periods. Two common examples of models which need to accommodate partial
periods in this way are:
1. Annual financial models which start part-way through a financial year; and
2. Merger or acquisition models in which the transaction date is not aligned with the end
of a financial reporting period.
The incorporation of partial period time series analysis in such models exponentially
increases the complexity of many of the formulas within their worksheets, which must take
into consideration potential partial period data whenever calculations are based on prior or
subsequent periods.
Partial periods can also be very misleading for model users, especially if the existence of
partial periods is not clearly communicated throughout the model. This issue is demonstrated
by the revenue assumptions entry interface shown below, which collects revenue growth rate
assumptions for each revenue category for each year after 2013:
Partial Periods Revenue Assumptions
From the model users perspective, 2013 appears to be a full year and therefore the 2014
growth rate assumptions have been entered as full year assumptions. However, if the
compacted time series period titles rows (8 13) within this time series sheet are expanded
to view the start and end date of each period, it can be seen that 2013 is in fact a partial
period:
Partial Periods Revenue Assumptions (Expanded Title Rows)
In this example, the model user has assumed a model start date of 1st July 2013 which,
when combined with an assumed December financial year end, results in the first time series
period in the model being only 6 months i.e. a partial period.
By not explicitly communicating the partial nature of the first year in this model, the model
developer has misled the model user into entering annual growth rate assumptions for 2014
based on semi-annual revenue amounts for 2013. As a result, if the 2013 revenue amount
assumptions are in fact semi-annual assumptions, the revenue outputs for the years 2014
2017 will be dramatically underestimated as a result of this confusion.
The image below shows how the risk of this error might be mitigated. The time series period
titles have been edited to display the text (P) at the end of partial years, and a note has
been added to the revenue assumptions warning model users of a potential partial first year:
Partial Periods Amended Revenue Assumptions
Note that, as a result of these changes, the growth rate assumptions in 2014 have been
amended to reflect the required grossing-up of the 2013 partial-year revenue assumptions.
This requirement is yet another reason why the use of partial periods often becomes
extremely complicated from both a model development and use perspective.
A full discussion of the issues and complexities raised by the accommodation of partial
periods within time series models is outside the scope of this document. However, as
demonstrated by the above simple example, model developers should think very carefully
about the implications of facilitating partial periods during every stage of the model
development and usage processes because of the high risk of errors it creates.
The following list provides some broad tips for the development of time series models which
allow for partial periods:
Avoid partial periods within time series models whenever possible;
Include a note within the time series assumptions indicating the occurrence of partial
periods and warning of repercussions;
Include identifiers within time series sheet period titles, such as the appending of the
text (P) or * to partial periods using concatenated text formulas, to clearly identify
partial periods within all time series sheets; and
Include notes within all assumptions and outputs that are impacted by partial periods,
clearly identifying the occurrence of partial period analysis.

Other Best Practice Modelling publications
Standards Standards
Tabulated Listing Commentary & Examples
bpmToolbox Modular Development

User Guide Fundamentals
bpmModules Time Series Analysis

User Guide Fundamentals
www.bestpracticemodeling.com
Best Practice Modelling
Phone: +613 9244 9800
Email: info@bpmglobal.com
www.bestpracticemodelling.com

BPM-Time Series Analysis PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BPM-Time Series Analysis PDF

Uploaded by

Copyright:

Available Formats

Time Series Analysis

Time Series Analysis - Fundamentals

Document version: 7.0.0.0

BEST PRACTICE MODELLING (BPM)

Time Series Modules ................................................................................................. 4

Time Series Components............................................................................................ 5

Periodicities & Time Frames ........................................................................................ 6

Time Frames ................................................................................................... 6

Time Series Assumptions ........................................................................................... 7

Period Titles Sets ...................................................................................................... 8

Period Titles Blocks ................................................................................................... 9

Multiple Periodicities ................................................................................................. 10

Periodic Data Conversions ......................................................................................... 12

Throughput Data Conversions ........................................................................... 12

Point-in-Time Data Conversions ......................................................................... 15

Multiple Time Frames ............................................................................................... 18

Rolling Business Planning .......................................................................................... 18

Time Series Scoping ........................................................................................ 18

Hiding Inactive Columns ................................................................................... 19

Inactive Columns Automation............................................................................ 24

Partial Periods ......................................................................................................... 31

This document aims to:

1. Provide a systematic approach to the development of the time series infrastructure

Time Series Modules

Time Series Module Composition

Time Series Components

Basic Time Series Infrastructure

The purpose of each of these components is provided in the table below:

Periodicities & Time Frames

Periodicity Time Series Period Duration

Time Frame Description

Historical Values from a prior period in time i.e. data based on

Forecast Predictions of values in the future.

Budget Estimates of future values for a set period of time to

Time Series Assumptions

Example Time Series Assumptions Annual

Period Titles Sets

Monthly Period Titles Set Time Series Output Sheet

Annual Period Titles Set Time Series Output Sheet

Period Titles Blocks

Annual Time Series Set Time Series Sheet Example

Shaded Period Titles Blocks

Block Column(s) Description

1 B Period titles row headings.

2 CI Spacer columns between headings and data.

3 JL Annual time series period titles.

Period Titles Set with Mixed Periodicities

Period Titles Blocks with Mixed Periodicities

Mixed Periodicities Adjacent Period Titles Blocks

Periodic Data Conversions

Periodic Data Type Description

Throughput Flows across time periods, such that it is required to

Point-in-Time Measured at specific moments in time, such as the

Throughput Data Conversions

Quarterly Revenue Outputs

Converted Annual Revenue Outputs

Converting Quarterly Throughput Data to Annual

Converting Quarterly Throughput Data to Semi-Annual

Point-in-Time Data Conversions

Quarterly Closing Asset Balances Outputs

Converted Annual Closing Asset Balances

Converting Quarterly Point-in-Time Data to Annual

Multiple Time Frames