Documente Academic
Documente Profesional
Documente Cultură
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.
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.
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.
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.
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.
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.
Investment Bankers
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.
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:
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
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
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.
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:
Model Outputs
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.
OR
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.
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