What are the steps to building a financial model? Explain in sequential manner.

1a. Planning the project

How you plan time and effort for a financial modelling project depends a lot on how you usually handle your
projects. A lot of experts like to use the feature list (of the specification) and assign "person-days" or "person-
hours" to each task or sub-task. One person-hour means that one person works for one hour; consequentially,
if you have two project team members working on a model for 10 hours each, that equals 20 person-hours.

For this, you would need the model's specification. But at the same time, writing the specification is part of the
project plan - it is a chicken/egg situation. Work around this problem by communicating a deadline for the
specification, and making clear the rest of the project's plan will be based on that specification. Do not get
worried: Over time, you will get a feeling how to approach this.

1b. Specification of the financial model

A solid and thorough specification is one cornerstone for a successful financial modelling process. In practice,
you will find this is especially true when working with external clients - much more so if you have been
contracted for a fixed flat fee, where every additional hour of work creates more value to the client without
making you earn more money.

In fact, when you are working with an external client, you should either include the specification in the
contract, or let the contract reference to the specification. It is highly recommended to agree on a final version
of the specification to avoid misunderstandings and unpaid extra-work. At the same time, the specification will
influence the project plan: The feature wish list determines the amount of time you will need to accomplish
your task.

What is often done is to align the specification and the documentation. This will save you time later on in the
modelling process (see below). You could structure your specification like this:

1. A general description of the scope of the financial model. This should not take up more than one page, if at all.
In fact, if you fail to describe the model's scope and purpose in just a few sentences, perhaps you (or your
client) should reconsider what this model is supposed to be used for.
2. A list of the input variables.
3. A description of the assumptions that affect the model structure.
4. A definition of the outputs that the model should generate - similar to the description of the model's scope,
but in more detail. For example, if the model's purpose is to generate a KPI forecast to banks, simply stating
that in the scope description will suffice there, and here, in the output descriptions, you should list in detail
which KPIs are supposed to be in the report.
 Distinguish between inputs and assumptions
As explained above, your specification should contain detailed assumptions. Some of these will affect the
structure of your model - for example the level of granularity in your model. Think of a retailing company that
wants to use a financial model to assess its plan of entering a new country: Should sales, cost etc. be forecast
on a regional level, or should the model be applied on store level? Decisions like these have a huge impact on
the way you construct your financial model and should be done as early as possible, preferably even be part of
the specification document. Making models less complex in the process is almost always an annoying, but
manageable problem - but making them more complex or detailed at a late stage is a huge problem that you
need to avoid.

Other assumptions will be simple input variables that have an influence on your model outputs, but can be
changed without changing the model structure, for example the assumed inflation rate. It is very likely that
many of these inputs will change while the financial model is being built, but that should not affect the
development as such.

When working with external clients, they sometimes may have trouble distinguishing between assumptions
that affect the structure and assumptions that do not. Help them understand the difference so that you do not
get caught up in pointless discussions about mere input values, while decisions that have a structural impact
are postponed or not done properly.

2. Designing and building the financial model

Designing and building the financial model is the actual core phase of the process. If your specification is good
and reflects the users' wishes properly, this phase will be much easier.

1. The specification should lay out the structure of the model in detail. When creating the sheets, make
sure you work with one empty template sheet (which is formatted according to any specifications
given) and use that for every other sheet created.
2. Build the input sheets first, and make sure you have some data to work with. Ask the model users to
provide you with actual data, or if that is not to be sent out, at least virtual, but realistic data.
3. Fill the other sheets with life, that is: formulas. Make sure you start with the basic sheets (such as P&L
and balance sheet). Include checks as you go along to avoid making mistakes which you would
otherwise uncover only much later.
4. Stay in touch with the model users at all times, and discuss the financial model regularly. That way
you make sure that the it meets the expectations and that everyone "is on the same page" regarding
what the model does and what it does not.

3. Testing the financial model

Naming this as a separate phase is more of a habit taken from software developers than a proper reflection of
reality - because a lot of the testing will have happened while building the model. Mostly, the testing as such
occurs in either of two settings:

 While building the model, you will include checks directly in the forms. Some of these checks will be very
generic and will therefore be included early, such as testing a balance sheet's sum of assets vs. sum of equity
and liabilities. Other checks will be more model-specific, and the need for them will not be obvious at the
beginning - therefore, the inclusion of new checks will happen throughout the model building phase. And
whenever one of those checks throws an error, you will naturally instantly look for the cause.
 Some models, but not necessarily all models, will additionally contain complex macros. These are either
essential for the model to function (e.g. in cases where input data must be transformed and complex
calculations are needed that cannot be done with formulas), or rather optional (such as a sensitivity analysis
macro, which would generate an additional output but does not affect the "normal" outputs). These macros
might need separate testing, and these methods (especially for code consistency) would relate to typical
software testing.

But whether your model contains macros or not, the basic way to test your model subsequent to the building
phase is to play with the inputs. The best practice from software testing is that you test every input variable
with values that reflect all possibilities, or at least all possibilites that differ substantially. That means, if you
want to test for different loan interest rates, rates of 6.0% and 6.1% are not substantially different; but instead,
look at your model's output for substantially different loan interest rates such as 0% and 20%. If you have the
time, the most thorough way would be to actually go through your list of input variables and try 3 to 5
different values, if your model allows that many input changes without the recalculation times driving you
crazy.

4. Documentation of the financial model

Like writing the specification, writing the documentation is one particularly boring part of the process. Yet, it
almost always needs to be done. A good documentation is needed to ensure that the model is handled
properly, even by users who were not involved in the development process. Ideally, your specification will
serve as the basis for the user documentation: The better your specification, the more of it you can "recycle" in
the final user guide.

Consider that not all users of the model will be Excel "power users". If you know that could be the case, put
some additional care in your documentation - make sure to explain what a macro is before you explain what
your macros do, and do the same for model checks before you explain how a user can go error-hunting.

The structure of your documentation could look like this:

1. Introduction: The first section of your documentation should explain the scope and the goal of the model. The
user should get an idea what to use the model for and what to expect from it.
2. Assumptions and Inputs: Following the introduction, you should explain the structural assumptions and the
relevant inputs. The user also needs instructions how the inputs can be changed and to
3. Macro Handling: It makes sense to include a separate chapter on macros in the model if they are complex and
require some user proficiency. Depending on the client this may even get technical with some code
explanations. In simpler models with no (or automatic) macros you may drop this section.
4. Outputs: One chapter should be dedicated to the output sheets. Here, you can explain what the sheets show
and how they should be read. This is also the section where you should include the definitions of the KPIs (key
performance indicators).
5. Known Issues: Obviously there should not be any issues with your model when it is final. Nonetheless, there
may be points you will want to highlight to make sure that "user expectation" does not diverge from reality
too far. Typical issues like that could be:
 Extreme elasticity effects: Your model may be accurate for certain input values, like a planned equity ratio
anywhere from 5% to 95%, but may deliver wrong results for ratios of 0% or 100%. Known effects like that
should be documented. Ideally, you would also explain the reason, e.g. if this is due to a calculatory
simplification in order to increase usability of the model.
 Performance issues: Complex models may require a lot of processor power and memory, and
recalculations and macros may take their time. Let the user know if this is the case. If applicable, give
advice on how to improve the model's performance.
 Compatibility issues: It happens rarely, but in case you know your model has problems with certain
versions of Excel (or Office), Windows, locale settings etc., do include that in your documentation.
 OR
1. Historical results and assumptions
Every financial model starts with a company’s historical results. You begin building the
financial model by pulling three years of financial statements and inputting them into
Excel. Next, you reverse engineer the assumptions for the historical period by calculating
things like revenue growth rate, gross margins, variable costs, fixed costs, AP days,
inventory days, and AP days, to name a few. From there you can fill in the assumptions
for the forecast period as hard-codes.

2. Start the income statement

With the forecast assumptions in place, you can calculate the top of the income
statement with revenue, COGS, gross profit, and operating expenses down to EBITDA.
You will have to wait to calculate depreciation, amortization, interest, and taxes.

Start the balance sheet

With the top of the income statement in place, you can start to fill in the balance sheet.
Begin by calculating accounts receivable and inventory, which are both functions of
revenue and COGS, as well as, the AR days and inventory days assumptions. Next, fill in
accounts payable which is a function of COGS and AP days.

4. Build the supporting schedules

Before completing the income statement and balance sheet you have to create a
schedule for capital assets like Property, Plant & Equipment (PP&E), as well as, for debt
and interest. The PP&E schedule will pull from the historical period and add capital
expenditures and subtract depreciation. The debt schedule will also pull from the
historical period and add increases in debt and subtract repayments. Interest will be
based on the average debt balance.

5. Complete the income statement and balance sheet

The information from the supporting schedules completes the income statement and
balance sheet. On the income statement, link depreciation to the PP&E schedule and
interest to the debt schedule. From there you can calculate earnings before tax, taxes,
and net income. On the balance sheet link the closing PP&E balance and closing debt
balance from the schedules. Shareholder’s equity can be completed by pulling forward
last year’s closing balance, adding net income and capital raised, and subtracting
dividends or shares repurchased.
6. Build the cash flow statement
With the income statement and balance sheet complete, you can build the cash flow
statement with the reconciliation method. Start with net income, add back depreciation,
and adjust for changes in non-cash working capital, which results in cash from
operations. Cash used in investing is a function of capital expenditures in the PP&E
schedule, and cash from financing is a function of the assumptions that were laid out
about raising debt and equity.

7. Perform the DCF analysis

When the 3 statement model is completed it’s time to calculate free cash flow
and perform the business valuation. The free cash flow of the business is discounted
back to today at the firm’s cost of capital (its opportunity cost or required rate of
return). We offer a full suite of courses that teach all of the above steps with examples,
templates, and step-by-step instruction. Read more about how to build a DCF model.

8. Add sensitivity analysis and scenarios

Once the DCF analysis and valuation sections are complete, it’s time to
incorporate sensitivity analysis and scenarios into the model. The point of this analysis is
to determine how much the value of the company (or some other metric) will be
impacted by changes in underlying assumptions. This is very useful for assessing the risk
of an investment or for business planning purposes (i.e. does the company need to raise
money if sales volume drops by x percent?).

9. Build charts and graphs

Clear communication of results is something that really separates good from great
financial analysts. The most effective way to show the results of a financial model is
through charts and graphs, which we cover in detail in our advanced Excel course, as well
as many of the individual financial modeling courses. Most executives don’t have the
time or patience to look at the inner workings of the model, so charts are much more
effective.

10. Stress test and audit the model

When the model is done your work is not over. Next, it’s time to start stress-testing
extreme scenarios to see if the model behaves as expected. It’s also important to use the
auditing tools covered in our financial modeling fundamentals course to make sure it’s
accurate and the Excel formulas are all working properly.
What are the practical areas wherein financial model is required to be prepared? Who are usually the
intended end users of the FM?

Financial Models are build by the following –

 Investment Bankers

 Equity Research Analysts

 Credit Analysts

 Risk Analysts

 Data Analysts

 Portfolio Managers

 Investors

 Management/Entrepreneurs
What are the various check and balances which are included in FM? Discuss the approach to include such
checks.

Best Practices in Financial Modeling

Before we examine the building blocks and financial modeling best practices in Excel, it is
important to note that model building is not an iterative process. In fact, models that are
built on the fly without scrutiny or attention to detail are typically prone to errors.

In order to minimize errors when building your financial models, be mindful of the
following five steps:

1. Clarify the business problem

2. Simplify as much as possible
3. Plan your structure
4. Build structural integrity
5. Test the model

Clarify the business problem and intended goal

 What problem is this financial model designed to solve?

 Who are the end users?
 What are users supposed to do with this model?

2. Try to keep the model as simple as possible

 What is the minimum number of inputs and outputs required to build a useful
model?
 Remember that the more assumptions a model has, the more complex it
becomes

3. Plan your model structure

 Plan how the inputs, processing, and outputs will be laid out.
 Try to keep your inputs in one place as possible in order to have a quick overview
of all inputs and their impacts on the model.
4. Protect data integrity

 Utilize Excel tools to protect data integrity, including “data validation” and
“conditional formatting.”
 This limits other users ability to accidentally “break” the model

5. Use test or dummy data

 Ensure that the model is completely functional and works as expected

 Stress test it by putting in scenarios that should cause the model to run of out
cash, grow at a flat rate (no changes) and other scenarios that are easy to sense
check

Model Inputs

When building the inputs of your model, it is important to be mindful of the following
factors:

 Input accuracy
 Reasonable data ranges
 Easy to use
 Easy to understand
 Easy to update data

Your model should be structured so that you should only enter each data once.
Moreover, all inputs should be differentiated from the outputs by using different colors,
highlights, and fonts so they are easily identified. Yellow shading or blue color fonts are
often used to indicate inputs.

Finally, it is important to fully utilize existing Excel tools to ensure data integrity. You
could use data validation, conditional formatting and comments to help you maintain
the integrity of your data and model inputs.

Color coding should be as follows:

 Blue: Inputs, assumptions, and drivers

 Black: Formulas and calculations (references to the same worksheet)
 Green: Calculations and references to other sheets
 Red: References to external links or separate files

Model Processing
 Model processing is about translating inputs into outputs. Hiding calculation cells or
putting too many calculations into a single cell makes models harder to maintain an
audit. Ideally, optimal model processing should be easy to maintain, transparent, and
accurate. In order to build an optimal model, users should:

 Break down complex calculations into several steps;

 Use comments and annotations to explain how the model works;
 Use formatting to ensure formulas are not accidentally overtyped; and
 Calculate final figures on your processing worksheets, then link these figures into
the final workbook sheets

Model Outputs

Financial model outputs include balance sheet forecasts, cash flow

forecasts, DCF valuations, and so on. To learn more about DCF valuations, please see
our Business Valuation Fundamentals course.

Ideally, a model’s output cells should be easy to understand, unambiguous, and provide
key results to aid decision making. In order to build an ideal model, users should:

 Make outputs modular so the end users can choose which outputs they wish to
review. For example, one can keep the balance sheet, income and cashflow
forecast in separate groups or worksheets.
 Consider creating a summary output sheet that allows users to review the key
model outputs without having to go through the entire model.
 Utilize colors to clearly categorize and indicate output formulas and cells.
 Consider protecting your output cells and worksheets to maintain data integrity.

OR

1. A mismatch between the financial model and the business plan: a financial model should resonate
with the overall business strategy
2. Overoptimistic or very pessimistic revenue projections: check out section ‘Revenues’ on how to
forecast sales
3. A funding need that is not adequately explained: make sure you include a breakdown of costs
4. Underlying assumptions that are not clearly defined: you should be able to provide clarification or
proof to the numbers
5. Not enough employees as part of the personnel forecast: do not underestimate the number (and
costs) of employees you need to build a fast-growing company
6. Revenue projections which are not aligned with the market size: by definition revenues cannot be
larger than the size of the market
7. Operational expenses that are being left out: make sure expenses are aligned to your strategy
8. Operational expenses which are misaligned with the forecasted revenues: make sure expenses
resonate with revenues
9. No realistic view of the gross, EBITDA and net margins: when speaking with investors, always be
prepared to answer questions on your current and expected margins
10. Disregarding the importance of working capital: do not underestimate the effect of payment terms on
your funding need
What is a financial model?
A financial model is simply a tool that’s built in Excel to forecast a business’ financial
performance into the future. The forecast is typically based on the company’s historical
performance, assumptions about the future, and requires preparing an income
statement, balance sheet, cash flow statement, and supporting schedules (known as a 3
statement model). From there, more advanced types of models can be built such as
discounted cash flow analysis (DCF model), leveraged-buyout (LBO), mergers and
acquisitions (M&A), and sensitivity analysis.

What is a financial model used for?

The output of a financial model is used for decision making and performing financial
analysis, whether inside or outside of the company. Inside a company, executives will use
financial models to make decisions about:

 Raising capital (debt and/or equity)

 Making acquisitions (businesses and/or assets)
 Growing the business organically (i.e. opening new stores, entering new markets,
etc.)
 Selling or divesting assets and business units
 Budgeting and forecasting (planning for the years ahead)
 Capital allocation (priority of which projects to invest in)
 Valuing a business

Common Financial Modeling Problems

The top 10 most common financial modeling problems are: (1) the balance sheet doesn’t
balance, (2) there are circular references when there shouldn’t be, (3) there are
assumptions/drivers that don’t impact anything in the model, (4) there are multiple
places to input the same assumptions, (5) there are #REF errors in the model, (6) the cash
balance becomes negative, (7) positive and negative signs are mixed up, (8) time periods
are wrong, (9) the modeling doesn’t have realistic assumptions, and (10) hardcodes
and formulas are not properly color coded.

OR

Inactivated Excel Add-ins Features

You will experience a lot of spreadsheet errors if auto calculation is set to

‘manual’ & ‘enable iterative calculation”. Here, you have to ensure common
Excel add-ins, i.e. Analysis ToolPak as many excel formulas depend on it to
work. This feature would help you ensure accurate calculations.

Complex Excel Formulas

You are suggested not to use overly complex formulas. A model integrated with
over-engineered model can bring you applause from your seniors, but might be
very difficult for users to understand. Therefore, simplicity is one key tenet of a
great financial modeling.

Inconsistent Cell Formatting

It is fundamental to ensure all numbers are written in thousands across the

entire spreadsheet, to avoid misspelt naming convention of business units,
projects or assets. And you have to be careful with the addition of conditional
cell formatting to ensure consistency.

Hidden Cells, Rows, Columns or Freeze Panes

You, the financial modeler, should learn to avoid hiding items and freezing
panes to ensure no important elements are overlooked. This would help you
avoid making erroneous changes to the complete worksheet.

Embedded Macros

Not all spreadsheet users have advanced knowledge of VBA code or macros.
Thus, when you are preparing a model for general public associated with your
company, be mindful of the inclusion of macros into the model.
What are the problems faced for preparing a FM for start-ups?

In a startup, we don’t have past data to project for future. Hence, we take industry as proxy

2. In a startup, we have negative cashflow in initial years and formula for debt repayment will be
different than an existing one

3. Many initial values are assumptions based, hence hardcoded rather than dynamic from
previous values